Before there were AMD Battlestations, there were Dreadnoughts

notarat

2[H]4U
Joined
Mar 28, 2010
Messages
2,427
Compress_20220830_113753_3294.jpg
Compress_20220830_113650_0830.jpg
Compress_20220830_113654_4182.jpg
Compress_20220830_113649_9511.jpg
 

Attachments

  • Compress_20220830_113648_8879.jpg
    Compress_20220830_113648_8879.jpg
    537.3 KB · Views: 0
  • Compress_20220830_113647_7872.jpg
    Compress_20220830_113647_7872.jpg
    474.1 KB · Views: 0
  • Compress_20220830_113646_6493.jpg
    Compress_20220830_113646_6493.jpg
    663 KB · Views: 0
  • Compress_20220830_113643_3967.jpg
    Compress_20220830_113643_3967.jpg
    670.6 KB · Views: 0

ZodaEX

Supreme [H]ardness
Joined
Sep 17, 2004
Messages
4,536
What a beautiful machine! I wonder if there are any updated Linux distros that still run on it.
 

GiGaBiTe

2[H]4U
Joined
Apr 26, 2013
Messages
2,399
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

[H]ard DCOTM x2
Joined
Mar 1, 2014
Messages
11,146
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.
 

toast0

2[H]4U
Joined
Jan 26, 2010
Messages
2,159
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

[H]ard|Gawd
Joined
Jan 7, 2020
Messages
1,062
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.
 

Attachments

  • 493259_36c008bff0864c7aba6e0fd31b4a6346~mv2.jpg
    493259_36c008bff0864c7aba6e0fd31b4a6346~mv2.jpg
    14.6 KB · Views: 0

GiGaBiTe

2[H]4U
Joined
Apr 26, 2013
Messages
2,399
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

2[H]4U
Joined
Mar 28, 2010
Messages
2,427
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

[H]ard|Gawd
Joined
May 22, 2005
Messages
1,889
Need an old school case like that for an AMD 5xxx rig... then can have the Turbo button used for "PBO" 🤣
 

OFaceSIG

2[H]4U
Joined
Aug 31, 2009
Messages
3,561
I had a AMD 386 DX 40. Was my first "custom" PC. My first machine was a 286 prebuilt.
 

Absalom

[H]ard|Gawd
Joined
Oct 3, 2007
Messages
1,075
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

[H]ard|Gawd
Joined
Jan 14, 2012
Messages
1,116
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

2[H]4U
Joined
Apr 26, 2013
Messages
2,399
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

[H]ard|Gawd
Joined
Jan 14, 2012
Messages
1,116
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

2[H]4U
Joined
Apr 26, 2013
Messages
2,399
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.
 
Top