> Obviously, at the time of the 80486, DDR didn’t exist, so SDRAM is a natural fit.
Neither are a fit, SDRAM was a Pentium/K-6 standard (PC66); the DIMMs ran faster than a non-OC'ed 486 bus, which ran at half the clock of the CPU. 486 "natural fit" would be FPM or EDO, if you wanted to be era-correct.
There were probably some off the wall 486 motherboards back then that supported SDR (post-1993...), but those would have been towards the very end of the 486 consumer life cycle. These did exist in the 486 era, where they had the option to run (or had an embedded) 386 using FPM while there was an open 486 socket and the option, but not requirement to run EDO.
Anyway, this is someone's project, so they can do whatever the heck they want.
nand2mario · 44m ago
Author here.
You’re right—EDO or FPM would be correct for the era. But as others have noted, DDR3 is fundamentally different from early 1990s memory, and it simply won’t run at the very low clock speeds of a 486. SDRAM, on the other hand, behaves in a way that’s much more comparable to the memory used back then.
TehCorwiz · 3h ago
Doesn’t DDR just stand for Double-Data-Rate? So you implemented basic DDR on top is sdram. Not a bad approach, just wanted to point it out.
robinsonb5 · 2h ago
It does, yes. But the DDR RAM available on the target board is DDR3 which is actually quite inconvenient for retro projects for a number of reasons.
Quite apart from the increased complexity, the most important difference is that there's a minimum speed as well as a maximum speed for modern DDR RAM, which means there's usually quite a narrow window of achievable clock rates when getting an FPGA to talk to DDR3.
I suspect that's why the author chose to use the DDR for video: It's usually easy to keep plain old SDRAM in lockstep with a soft-CPU, since you can run it at anything between 133MHz (sometimes even more) and walking pace, so there's no need to deal with messy-and-latency-inducing clock domain crossing.
Streaming video data in bursts into a dual-clock FIFO and consuming it on the pixel clock is a much more natural fit.
nand2mario · 39m ago
Yes, for exactly the reason. SDRAM is much easier to work with in retro computing than DDR.
accrual · 22m ago
My first DDR system, an Athlon XP, feels like a very different beast than my 440BX with SDRAM despite being only a couple years newer. :)
SomeHacker44 · 3h ago
Silly question. Are there any 486-compatible small CPUs that could be embedded into a project instead of using an FPGA? Given that AMD, Intel and others have the ability to make 486-compatible processors currently, I would have thought you could just buy a CPU or SoC to run 486 code.
privatelypublic · 2h ago
Define "486-compatible." As far as I know even intel's newest cpus can run 486 era 16-bit stuff in hardware.
But, a plain answer: Via Eden boards. still use north/southbridge architecture, and are from the mid 2000's.
It's just modern Windows/Linux that have discontinued the ability. Or, perhaps you have 16/32 and 32/64 and are unable to do 16bit on 64bit machines- which still boils down to "operating system."
By far the biggest issue though is that even the Via Eden processor is significantly faster than a 486- and lots of software (especially games) from that era used no-op instruction loops for timing and timers. This results in games like The Incredible Machine's level timer running out in half a second or less.
zokier · 2h ago
Vortex86 is probably the closest thing to what you are looking for.
vascocosta · 2h ago
Any idea when Pixel86 is going to be available again or how/where to get an ITX-Llama system?
I miss Intel's Quark chips. Tiny, cheap, and Pentium enough.
toast0 · 1h ago
Didn't they have the F00F bug? (Thanks, I keep misremembering) How much more Pentium do you want?
oakwhiz · 1h ago
No, the Quarks did not have the f00f bug, that would have been funny though.
accrual · 21m ago
I believe the F00F bug was patched out pretty quickly in the Pentium's B2 stepping. Nevertheless, some OSs still have mitigations if they detect an affected CPU (e.g. OpenBSD).
epcoa · 16m ago
It wasn’t even discovered until 1997, so no that wasn’t exactly early in the Pentium lifecycle at all.
fabiensanglard · 3h ago
486? If it has VLB, it can play DOOM well!
accrual · 19m ago
Indeed! I have a 486 DX4-100 that is my favorite DOOM system. It has an S3 805 VLB card currently, fast enough. Do you have a favorite VLB card for the 486 or DOOM?
lightedman · 1h ago
I would love to see ancient tech fabbed out on modern processes.
What's the smallest SOC you could design to run DOOM? What power envelope would that consume (exclusing display/speakers/etc.) At that size and (optimized) transistor count, what speeds could we realistically achieve?
What would a massively-multicore (gpu-style with multi-hundreds or more of cores) one of these run like?
Every time I see a project like this, these thoughts run through my head.
accrual · 11m ago
That is a cool idea for sure. It's fun to imagine where the original x86 platform ({80,2,3,4}86) would have gone if it hadn't been remade with the Pentium (superscaler).
system2 · 2h ago
When you say "credit-card-sized," I expect the thickness to be as thin as a credit card, too. Isn't the Raspberry Pi credit card sized too?
devinbernosky · 2h ago
so this will run half life 2 if I'm not mistaken?
accrual · 17m ago
Half-Life 2 was but a twinkle in Valve's eye when the 486 arch was introduced in 1989. ;)
Neither are a fit, SDRAM was a Pentium/K-6 standard (PC66); the DIMMs ran faster than a non-OC'ed 486 bus, which ran at half the clock of the CPU. 486 "natural fit" would be FPM or EDO, if you wanted to be era-correct.
There were probably some off the wall 486 motherboards back then that supported SDR (post-1993...), but those would have been towards the very end of the 486 consumer life cycle. These did exist in the 486 era, where they had the option to run (or had an embedded) 386 using FPM while there was an open 486 socket and the option, but not requirement to run EDO.
Anyway, this is someone's project, so they can do whatever the heck they want.
Quite apart from the increased complexity, the most important difference is that there's a minimum speed as well as a maximum speed for modern DDR RAM, which means there's usually quite a narrow window of achievable clock rates when getting an FPGA to talk to DDR3.
I suspect that's why the author chose to use the DDR for video: It's usually easy to keep plain old SDRAM in lockstep with a soft-CPU, since you can run it at anything between 133MHz (sometimes even more) and walking pace, so there's no need to deal with messy-and-latency-inducing clock domain crossing.
Streaming video data in bursts into a dual-clock FIFO and consuming it on the pixel clock is a much more natural fit.
But, a plain answer: Via Eden boards. still use north/southbridge architecture, and are from the mid 2000's.
It's just modern Windows/Linux that have discontinued the ability. Or, perhaps you have 16/32 and 32/64 and are unable to do 16bit on 64bit machines- which still boils down to "operating system."
By far the biggest issue though is that even the Via Eden processor is significantly faster than a 486- and lots of software (especially games) from that era used no-op instruction loops for timing and timers. This results in games like The Incredible Machine's level timer running out in half a second or less.
https://classic.sipeed.com/tangconsole
https://archive.is/UD0vH
What's the smallest SOC you could design to run DOOM? What power envelope would that consume (exclusing display/speakers/etc.) At that size and (optimized) transistor count, what speeds could we realistically achieve?
What would a massively-multicore (gpu-style with multi-hundreds or more of cores) one of these run like?
Every time I see a project like this, these thoughts run through my head.