Before there were AMD Battlestations, there were Dreadnoughts

[notarat]

 

[ZodaEX]

What a beautiful machine! I wonder if there are any updated Linux distros that still run on it.

 

[GiGaBiTe]

None that I know of. You have your choice of ancient Linux distros, like Debian 3 and older and Slackware 9 and older.

The only modern Linux distros I know of that would be close are TinyCore and Damn Small Linux, both requiring a 486DX and 16 MB of RAM.

It might be achievable on that system with some upgrades. Cyrix made a weird hybrid chip called the Cyrix Cx486DLC, which was more or less a 486 in a 386 package. The companion Cyrix Cx487DLC would be needed to have an x86 FPU. Linux can run without an FPU, but it's really slow in emulation.

http://www.cpu-collection.de/?tn=0&l0=co&l1=Cyrix&l2=Cx486+DLC

The deal breaker would be if it supported 16M of RAM or not. There were 4M 30 pin SIMMs, but not all motherboards supported them.

 

[auntjemima]

None that I know of. You have your choice of ancient Linux distros, like Debian 3 and older and Slackware 9 and older.

The only modern Linux distros I know of that would be close are TinyCore and Damn Small Linux, both requiring a 486DX and 16 MB of RAM.

It might be achievable on that system with some upgrades. Cyrix made a weird hybrid chip called the Cyrix Cx486DLC, which was more or less a 486 in a 386 package. The companion Cyrix Cx487DLC would be needed to have an x86 FPU. Linux can run without an FPU, but it's really slow in emulation.

http://www.cpu-collection.de/?tn=0&l0=co&l1=Cyrix&l2=Cx486+DLC

The deal breaker would be if it supported 16M of RAM or not. There were 4M 30 pin SIMMs, but not all motherboards supported them.

Not sure how much memory he has, but he has 8 memory slots there, so he would only need 2M size chips.

And I think he can throw an FPU in that socket above the cpu to avoid the emulation.

 

[auntjemima]

View attachment 505293View attachment 505294View attachment 505295View attachment 505296

This is so cool and I'm sorry I missed it lol

 

[jeffreyp]

View attachment 505293View attachment 505294View attachment 505295View attachment 505296

LoL! Brings back memories. AMD made second tear CPU's at the time. Can't say the same about my 5950x. Overclocking the 386 was removing the 80MHz crystal oscillator (divide by 2 I assume) then progressively replacing the oscillator with a faster one until problems occur. Like won't boot...

 

[toast0]

What the heck is a protect sheet referenced on the 5.25" drive? And why don't I know about them, I was there? Google not very helpful.

 

[Starfalcon]

They were a piece of cardboard that went inside a 5 1/4 flopy disc drive to protect the head from banging around during shipping. Almost all of them were thrown away once someone actually started using the drive. It pretty much looks like a cardboard floppy disk shape.

 

[Axman]

And they say you can't smell a picture...

 

[GiGaBiTe]

Not sure how much memory he has, but he has 8 memory slots there, so he would only need 2M size chips.

No such thing as a 2M 30 pin SIMM. There may have been specialty/proprietary modules, but not in widespread use.

Common sizes for 30 pin SIMMs were 256k, 1M and 4M. Later there were 8M and 16M sticks, but 4, 8 and 16 weren't widely supported. 8M and 16M sticks were almost entirely in the server space, very few consumer boards supported them.

 

[notarat]

Not sure how much memory he has, but he has 8 memory slots there, so he would only need 2M size chips.

And I think he can throw an FPU in that socket above the cpu to avoid the emulation.

It's 1MB of FPM RAM in 128Kb SIMMS

 

[jlbenedict]

Need an old school case like that for an AMD 5xxx rig... then can have the Turbo button used for "PBO" 🤣

 

[OFaceSIG]

I had a AMD 386 DX 40. Was my first "custom" PC. My first machine was a 286 prebuilt.

 

[Absalom]

They were a piece of cardboard that went inside a 5 1/4 flopy disc drive to protect the head from banging around during shipping. Almost all of them were thrown away once someone actually started using the drive. It pretty much looks like a cardboard floppy disk shape.

There were also head cleaner disks that instead of having a magnetic disk had a felt one. I'd have put one of those in there if I was transporting it long distances.

 

[Legendary Gamer]

None that I know of. You have your choice of ancient Linux distros, like Debian 3 and older and Slackware 9 and older.

The only modern Linux distros I know of that would be close are TinyCore and Damn Small Linux, both requiring a 486DX and 16 MB of RAM.

It might be achievable on that system with some upgrades. Cyrix made a weird hybrid chip called the Cyrix Cx486DLC, which was more or less a 486 in a 386 package. The companion Cyrix Cx487DLC would be needed to have an x86 FPU. Linux can run without an FPU, but it's really slow in emulation.

http://www.cpu-collection.de/?tn=0&l0=co&l1=Cyrix&l2=Cx486+DLC

The deal breaker would be if it supported 16M of RAM or not. There were 4M 30 pin SIMMs, but not all motherboards supported them.

I would avoid the old Cyrix stuff if possible. I had used their math co-processor from the same era to bump up my 306DX40's ability to play doom and it introduced all kinds of numerical errors and glitches. I actually moved to the chip you are referring to as a complete platform and it was more headache than it was worth (due to almost no money at the time) I ended up tossing it and replacing it with a 486DX100 AMD rig.

 

[GiGaBiTe]

I would avoid the old Cyrix stuff if possible. I had used their math co-processor from the same era to bump up my 306DX40's ability to play doom and it introduced all kinds of numerical errors and glitches. I actually moved to the chip you are referring to as a complete platform and it was more headache than it was worth (due to almost no money at the time) I ended up tossing it and replacing it with a 486DX100 AMD rig.

Completely false. Why? Because Doom is a purely integer based engine, it doesn't use x87 floating point code at all. The problems you experienced were entirely caused by hardware problems on your system, not by the Cyrix FPU. The game doesn't care if you have a 387/486DX or just a plain 386/486SX, because it doesn't use the FPU.

If I were to guess what problem you were experiencing, it would probably have been due to missing cache coherency circuitry. Some Cyrix 386 and all Cyrix 486DLC/SLC chips had internal L1 cache on them, something which the original Intel parts did not have. This resulted in earlier 386 motherboards not having cache coherency circuitry, which is required for L1 cache to not function properly. When the cache can't be kept coherent, the CPU will run fine until it tries to use its L1 cache. Once it starts trying to use stale cache entries, it sends the stack pointer off into la-la land and makes the system unstable, lock up or crash.

Cyrix later fixed this problem in their Cx486DRx2, which was a clock doubled version. On the older DLC/SLC chips, there was a special interposer required that sat between the socket and the CPU, which contained the cache control circuitry. This board was often included with CPU upgrades at the time for obvious reasons. They're pretty hard to find today, because later 386 boards included the cache control circuitry, as they required it when boards started having on board CPU cache.

 

[Legendary Gamer]

Completely false. Why? Because Doom is a purely integer based engine, it doesn't use x87 floating point code at all. The problems you experienced were entirely caused by hardware problems on your system, not by the Cyrix FPU. The game doesn't care if you have a 387/486DX or just a plain 386/486SX, because it doesn't use the FPU.

If I were to guess what problem you were experiencing, it would probably have been due to missing cache coherency circuitry. Some Cyrix 386 and all Cyrix 486DLC/SLC chips had internal L1 cache on them, something which the original Intel parts did not have. This resulted in earlier 386 motherboards not having cache coherency circuitry, which is required for L1 cache to not function properly. When the cache can't be kept coherent, the CPU will run fine until it tries to use its L1 cache. Once it starts trying to use stale cache entries, it sends the stack pointer off into la-la land and makes the system unstable, lock up or crash.

Cyrix later fixed this problem in their Cx486DRx2, which was a clock doubled version. On the older DLC/SLC chips, there was a special interposer required that sat between the socket and the CPU, which contained the cache control circuitry. This board was often included with CPU upgrades at the time for obvious reasons. They're pretty hard to find today, because later 386 boards included the cache control circuitry, as they required it when boards started having on board CPU cache.

It might not use the math co processor at all in Doom, however, the inclusion of the Cyrix part in my 386 introduced an entire host of issues.

Feelings:
Anything that was non Intel or AMD had serious compatibility issues in DOS and Windows Programs.

No Math Co-Processor Doom is sluggish and functional but drops frames in certain scenarios (on Ultra Violence)

Math Co-processor from Cyrix added = I gained a couple FPS in the game, it was noticeable because my FPS was in the single digits. Game is playable but has graphical issues and artifacts and that wasn't the only program I experienced it in. (Maybe it was offloading other stuff from the CPU in the background?)

Very similar situation on the (Cyrix) "486" model. I couldn't even really call it an upgrade given how many issues it introduced. In many ways the 386 felt faster, but in some applications it was way better. IIRC it could run MW 2 in 3D with a Voodoo 1 Card but it ran like shit.

AMD DX4/100 Was butter smooth on games after that I migrated to a NextGen Board and Processor

My NexGen 120 "Pentium" competitor, was pretty darn fast, don't think they had math co processors in those until the 133 Mhz version. Pretty certain AMD bought that company shortly after they came out.

The only time I ever touched a Cyrix processor again was when I was dropping in the "Pentium" overdrive processors from Cyrix/VIA into my family's PCs to keep them rolling for a few more years OR if I was building a cheap system to use as another LAN station. Those were pretty darn good value items. They worked really well.

No worries my friend, I can be wrong, it's ancient history anyway.

 

[GiGaBiTe]

It might not use the math co processor at all in Doom, however, the inclusion of the Cyrix part in my 386 introduced an entire host of issues.

Was the 386DX also a Cyrix part? Mixing and matching 386 and 387 vendors wasn't a great idea and could cause issues, though the 387s were supposed to work with any 386.

Feelings:
Anything that was non Intel or AMD had serious compatibility issues in DOS and Windows Programs.

You didn't have to feel it, it was well known. Cyrix later on had lots of trouble with their CPUs not working properly due to bugs in their designs, especially their 586 and 6x86. They spun a fair few mask revisions to fix bugs, and even had to disable advertised features, like branch prediction because of them making the CPU unstable.

There's a thread over on Vogons where some people have tested various mask revisions of Cyrix CPUs and seeing which disabled features that can be re-enabled without compromising the stability of the CPU. Unlike Intel, who usually burns off or cuts out features in hardware, Cyrix just disabled the buggy features in the microcode. This means that some features can be re-enabled by poking around in the registers on the CPU.

No Math Co-Processor Doom is sluggish and functional but drops frames in certain scenarios (on Ultra Violence)

Math Co-processor from Cyrix added = I gained a couple FPS in the game, it was noticeable because my FPS was in the single digits. Game is playable but has graphical issues and artifacts and that wasn't the only program I experienced it in. (Maybe it was offloading other stuff from the CPU in the background?)

If any bit of code running on the system was doing x87 emulation, it would significantly slow the system down. Having a real x87 would fix that and remove that burden from the host CPU. x86 was VERY slow emulating floating point math, it would cause major performance issues, even if it were just a few instructions, especially division.

 

[Legendary Gamer]

I was mixing and matching parts on a budget. I'm sure that caused an issue.

 

[regk]

I love the classics! you haven't lived till you have had to change jumper settings for your hardware, kids today just click a mouse lol!