> 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.
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.
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.
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.
I left it open as to if it was a hardware or OS level item that prevents 16bit. Because I don't know, and don't care to dig that rabbit hole.
Also- DOSBox is an emulator vs VMs are hardware, no? I suspect A VM won't fix the "no-op loop for timing" issue- with modern processors' lowest clock being 600-800Mhz before it gets C6/C7'd, 30 years of IPC improvement, and the possibility of the CPU itself optimizing such loops (I'm unsure for various reasons): I expect the UX of "just limit how many scheduler slices it gets" to be nasty.
There is a branch of Via (?) in china making enhanced 486 system on a chip "586" systems. I'm on mobile so I don't have the name handy but I'm still hopeful these get cheap enough to enter the hobby space more.
Out of curiosity, how much of the 138K LUTs (as well as other resources like BRAM) are in use here? I wonder if there's much room to add fancy peripherals, or perhaps "growing" the CPU to achieve better IPC.
It currently uses 44% of the LUTs and 59% of the BRAMs (out of 340 × 2 KB blocks). The chip itself is fairly large and inexpensive, though performance leans toward the lower side.
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.
> I would love to see ancient tech fabbed out on modern processes.
> What's the smallest SOC you could design to run DOOM?
Depending on your definition of "modern", more than you think has been done. Intel's Quark were basically 486/Pentium hybrids but fabbed on a fairly modern (at the time) process. While Quark is no longer available as a standalone product, a derivative is part of every modern Intel processor in the form of the Intel ME system co-processor, and it's likely that a number of other Intel products (network cards, QAT accelerators, the ARC GPUs, etc) use them as system controllers as well (Quark essentially came into existence as a "formalization" of the multiple "micro-x86" implementations inside Intel being used as embedded controllers for various non-CPU products).
> What would a massively-multicore (gpu-style with multi-hundreds or more of cores) one of these run like?
This is close to what the original Xeon Phi was. Essentially 60-ish Pentium cores, with modern SMT and 512-bit vector units added. It worked ... OK? If the software development story had been better (e.g. actual first-class support in GCC) I think they could have been a much bigger success, but the need for ICC back in the ICC-costs-real-money days and initially very expensive hardware certainly held them back. At times I do miss some of their behavior.
Arguably a number of the RISC-V-based "AI accelerators" on the market are basically new spins on the same idea: a bunch of small cores, plus large vector/tensor units.
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).
> x86 vs. ARM. Working with ao486 deepened my respect for x86’s complexity. John Crawford’s 1990 paper “The i486 CPU: Executing Instructions in One Clock Cycle” is a great read; it argues convincingly against scrapping x86 for a new RISC ISA given the software base (10K+ apps then). Compatibility was the right bet, but the baggage is real. By contrast, last year’s ARM7‑based GBATang felt refreshingly simple: fixed‑length 32‑bit instructions, saner addressing, and competitive performance. You can’t have your cake and eat it.
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.
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?
The Edison is a modern System On Module about the size of an SD card but about 3x the thickness of one. It's far more capable: dual 64-bit Silvermont Atom cores, Super scalar out of order. And an additional Quark core as a system monitor, running an independent RTOS. There's also 4GB eMMC, 1GB RAM, WiFi, and Bluetooth on the module. Its quite a remarkable curiosity.
Ten years ago, Intel tried to catch up to ARM in tablets and smartphones, but it was already too late, and this entire segment of Intel was cancelled within a year or two.
> Looks like an opportunity for a cluster in a picture frame. Did you get them?
Are you kidding? Of course I got them! :-)
It was actually better than that: they were in bulk boxes of five, there were at least eight such boxes. I took two, just to have one to play with and to get them out of the elements (they were on shelf that's partially protected on one side by a metal storage shed, but the shelf is just standing outdoors)..
I stopped by the local makerspace a day or two later, to let them know. I don't know what became of them.
My boxes got shoved to the back of the project queue and it's been about a year now. I just got them out about a week ago, looking into building the new firmware images.
These Intel Galileo dev kits are quite a bit bigger than a typical Arduino. They have the standard dual row inline headers of an Arduino (I think its pin-compatible), but lots more IO. There's Ethernet, for instance. Nearly the size of a Pico-ITX form factor.
Those were actually a 486 microarchitecture with some Pentium instructions added. If you look at the documentation for them, it's obvious that they copy-pasted the 486's and search-and-replaced.
Yes, they did have the bug with the lock prefix. IOT people at Microsoft got NT booting on the Quark and we ran into that problem. I wound up writing a small tool to patch out all the lock prefixes.
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).
It wasn’t even discovered until 1997, so no that wasn’t exactly early in the Pentium lifecycle at all. There were multiple models and millions of devices affected.
I'd pay a decent price for a non-emulated 486 on a credit card sized board, or in a cute little case, with useful peripherals. Something like those Aliexpress mini pocket 386 computers, but 486 is significantly more useful for gaming.
> 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.
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.
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.
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.
In Windows, once you're in long mode, there's no 16-bit available to you. You can instead take the DOSBox or other VM route.
Linux isn't really relevant given the time frame.
I left it open as to if it was a hardware or OS level item that prevents 16bit. Because I don't know, and don't care to dig that rabbit hole.
Also- DOSBox is an emulator vs VMs are hardware, no? I suspect A VM won't fix the "no-op loop for timing" issue- with modern processors' lowest clock being 600-800Mhz before it gets C6/C7'd, 30 years of IPC improvement, and the possibility of the CPU itself optimizing such loops (I'm unsure for various reasons): I expect the UX of "just limit how many scheduler slices it gets" to be nasty.
DOSBox is an emulator.
https://en.wikipedia.org/wiki/DOSBox#Hardware_emulation
Intel did have a product like that but it's been discontinued: https://en.wikipedia.org/wiki/Intel_Quark
AMD even had two of them. Their own: https://en.wikipedia.org/wiki/AMD_%C3%89lan and based on the Cyrix x586 after they acquired them: https://en.wikipedia.org/wiki/Geode_(processor)
They weren't even that bad considering the little power they needed.
Vortex86 is probably the closest thing to what you are looking for.
Any idea when Pixel86 is going to be available again or how/where to get an ITX-Llama system?
Pre-orders:
https://retrodreams.ca/
Review - https://www.youtube.com/watch?v=L9UdU89DDvY
Thanks!
It says this however:
"Expected to ship to customers in February 2025."
I wonder if a typo or if batch 2 is already gone too...
Do people buy these things? It seems to me that shops touching Vortex86 always struggle to move them.
They have a contact us form, or discord.
There used to be single-chip x86 systems, but I don't know if they went all the way up to 486. You'd see them in early low power portables.
I'm guessing the ITX-Llama is far less affordable next to reusing a "generic" FPGA retrogaming board.
There is a branch of Via (?) in china making enhanced 486 system on a chip "586" systems. I'm on mobile so I don't have the name handy but I'm still hopeful these get cheap enough to enter the hobby space more.
Out of curiosity, how much of the 138K LUTs (as well as other resources like BRAM) are in use here? I wonder if there's much room to add fancy peripherals, or perhaps "growing" the CPU to achieve better IPC.
It currently uses 44% of the LUTs and 59% of the BRAMs (out of 340 × 2 KB blocks). The chip itself is fairly large and inexpensive, though performance leans toward the lower side.
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.
> I would love to see ancient tech fabbed out on modern processes.
> What's the smallest SOC you could design to run DOOM?
Depending on your definition of "modern", more than you think has been done. Intel's Quark were basically 486/Pentium hybrids but fabbed on a fairly modern (at the time) process. While Quark is no longer available as a standalone product, a derivative is part of every modern Intel processor in the form of the Intel ME system co-processor, and it's likely that a number of other Intel products (network cards, QAT accelerators, the ARC GPUs, etc) use them as system controllers as well (Quark essentially came into existence as a "formalization" of the multiple "micro-x86" implementations inside Intel being used as embedded controllers for various non-CPU products).
> What would a massively-multicore (gpu-style with multi-hundreds or more of cores) one of these run like?
This is close to what the original Xeon Phi was. Essentially 60-ish Pentium cores, with modern SMT and 512-bit vector units added. It worked ... OK? If the software development story had been better (e.g. actual first-class support in GCC) I think they could have been a much bigger success, but the need for ICC back in the ICC-costs-real-money days and initially very expensive hardware certainly held them back. At times I do miss some of their behavior.
Arguably a number of the RISC-V-based "AI accelerators" on the market are basically new spins on the same idea: a bunch of small cores, plus large vector/tensor units.
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).
From the reflections section:
> x86 vs. ARM. Working with ao486 deepened my respect for x86’s complexity. John Crawford’s 1990 paper “The i486 CPU: Executing Instructions in One Clock Cycle” is a great read; it argues convincingly against scrapping x86 for a new RISC ISA given the software base (10K+ apps then). Compatibility was the right bet, but the baggage is real. By contrast, last year’s ARM7‑based GBATang felt refreshingly simple: fixed‑length 32‑bit instructions, saner addressing, and competitive performance. You can’t have your cake and eat it.
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.
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.
Yes, for exactly the reason. SDRAM is much easier to work with in retro computing than DDR.
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. :)
I had that with a Geforce2. Or was Athlon 2000. Wait, Athlon 2000 at 1666 MHZ, really fast until the capacitors on a Gigayte motherboard blew up.
[dead]
I hadn't heard of this board before, here's a link to a page on the manufacturer's site:
https://classic.sipeed.com/tangconsole
A review of sorts - https://youtu.be/ScwZwfS53dE
Ah that’s nice. Affordable FPGAs are always welcome.
https://archive.is/UD0vH
486? If it has VLB, it can play DOOM well!
Also there's FastDoom at Github:
https://github.com/viti95/FastDoom
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?
This is my favorite build to run DOOM: https://fabiensanglard.net/2168/epilogue/
I miss Intel's Quark chips. Tiny, cheap, and Pentium enough.
I found 10 Intel Galileo dev kits, new in box, left at our local recycling center on the "Free: Take Me Home" shelf.
And just today, I received the Intel Edison dev kit that I'd purchased on eBay.
The Galileo is a Quark X1000 SoC, two P54C cores. In-order, original 32-bit Pentium.
https://en.m.wikipedia.org/wiki/Intel_Galileo
.
The Edison is a modern System On Module about the size of an SD card but about 3x the thickness of one. It's far more capable: dual 64-bit Silvermont Atom cores, Super scalar out of order. And an additional Quark core as a system monitor, running an independent RTOS. There's also 4GB eMMC, 1GB RAM, WiFi, and Bluetooth on the module. Its quite a remarkable curiosity.
Ten years ago, Intel tried to catch up to ARM in tablets and smartphones, but it was already too late, and this entire segment of Intel was cancelled within a year or two.
https://en.m.wikipedia.org/wiki/Intel_Edison
Next up is building more recent Linux images for these via the Yocto Project and the now cancelled Intel Board Support Packages (BSP).
If you like low power tiny systems, there's a strange amount of fun to be had.
> I found 10 Intel Galileo dev kits, new in box, left at our local recycling center on the "Free: Take Me Home" shelf.
Looks like an opportunity for a cluster in a picture frame. Did you get them?
I have one, a 4 RPI Zero W cluster in an Ikea picture frame:
https://x.com/0xDEADBEEFCAFE/status/1163378341610688513
> Looks like an opportunity for a cluster in a picture frame. Did you get them?
Are you kidding? Of course I got them! :-)
It was actually better than that: they were in bulk boxes of five, there were at least eight such boxes. I took two, just to have one to play with and to get them out of the elements (they were on shelf that's partially protected on one side by a metal storage shed, but the shelf is just standing outdoors)..
I stopped by the local makerspace a day or two later, to let them know. I don't know what became of them.
My boxes got shoved to the back of the project queue and it's been about a year now. I just got them out about a week ago, looking into building the new firmware images.
These Intel Galileo dev kits are quite a bit bigger than a typical Arduino. They have the standard dual row inline headers of an Arduino (I think its pin-compatible), but lots more IO. There's Ethernet, for instance. Nearly the size of a Pico-ITX form factor.
https://en.m.wikipedia.org/wiki/Pico-ITX
Those were actually a 486 microarchitecture with some Pentium instructions added. If you look at the documentation for them, it's obvious that they copy-pasted the 486's and search-and-replaced.
Didn't they have the F00F bug? (Thanks, I keep misremembering) How much more Pentium do you want?
No, the Quarks did not have the f00f bug, that would have been funny though.
Didn't they have issues with `LOCK CMPXCHG`(not the 8B)? This is out of my depth and I am not sure, but it sounds similar to the f00f bug.
1: https://en.wikipedia.org/wiki/Intel_Quark#Segfault_bug
Yes, they did have the bug with the lock prefix. IOT people at Microsoft got NT booting on the Quark and we ran into that problem. I wound up writing a small tool to patch out all the lock prefixes.
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).
It wasn’t even discovered until 1997, so no that wasn’t exactly early in the Pentium lifecycle at all. There were multiple models and millions of devices affected.
I'd pay a decent price for a non-emulated 486 on a credit card sized board, or in a cute little case, with useful peripherals. Something like those Aliexpress mini pocket 386 computers, but 486 is significantly more useful for gaming.
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?
rpi are, and always have been a little bigger (and much taller) than credit cards. more like altoids tin
so this will run half life 2 if I'm not mistaken?
For those not aware, this is a reference to an audience comment at the HL2 E3 2003 presentation: https://www.youtube.com/watch?v=4ddJ1OKV63Q&t=200s
Half-Life 2 was but a twinkle in Valve's eye when the 486 arch was introduced in 1989. ;)
Could maybe run HL1. Maybe.
Nop, HL1 uses the Quake engine that requires a fast FPU. The minimum CPU for any kind of decent performance is a Pentium.
some og binaries with software rendering would probably slide show it along nicely
Now put it, together with some other useful boards, into a good non-plastic Amiga 600-sized wedge/keyboard case.