I ended up finding the application it's intended to run, ELKS, the most interesting part. ELKS (“Embedded Linux Kernel Subset”) is apparently a very, very old fork of Linux from the 1990's that targets 16-bit real-mode x86 systems with no MMU (e.g. 8086) rather than 32-bit protected mode x86 (80386 and later). It's fascinating in a similar way to how, say, ancient religious schisms are. It's still actively maintained even!
I can't pick these up for a few reasons (#dayjob and other hobby projects that I don't have enough time/energy to work on properly!), but here's a couple of thoughts that've been percolating for a while that didn't make the last topic:
- If I were a 19-year old (and odd) college student thinking about starting something like this again (I picked up the idea from Alan Cox and did the early versions suuuuch a long time ago now!), I'd have targeted the Pi Pico, and been absolutely estatic when the RP2350/Pico 2 came out.
You could make a pretty interesting 80/early-90's workstation using a couple of rp2350's (one for frontend, the other to run the hacked-up Linux) w/additional SRAM and Flash.
- One can use a 386+ as a memory mapper/protection unit while still running everything the rest of the system in real/v86 mode, in blissful ignorance that it's running on a 32-bit system.
There's a few RISC-V single-chip computers that put the Raspberry-Pi's products to shame. I'm evaluating the Bouffalo Labs BL808 and the Sophgo SG2000 for an upcoming project. They have MMUs and enough integrated RAM to run a mainline POSIX operating system. Both have multiple asymmetric cores that allow one to run a full Linux OS, one to run an RTOS or bare metal, and one for low-power tasks to run while suspended.
They're basically as capable as a Pi Zero, but work in a Pi Pico form factor. Check out the Ox64 and Oz64 boards from Pine64 or the Duo series from Milk-V.
The Sophgo chip might be increasingly difficult to put your hands on. Putting them on the entity list was one of the last things the Biden admin did.
Obviously not the same thing, it's not "real" Linux, but a similar goal of getting "something like Unix on hardware that has no business running it".
I have mad respect for these kinds of projects. Writing software on powerful hardware is easy, that's what I do for a living, but people squeezing the life out of the NES and C64 are on another level of intelligence and dedication that I'm not sure I'll ever be able to match.
But then he received a lot of comments saying that it's not real Linux, so he made NES86 to run ELKS and made another video https://www.youtube.com/watch?v=OooHTDMUSGY. It's a bit funny since ELKS does not consider itself Linux anymore, just a "Linux-like OS", so maybe we'll have a third iteration of this project eventually ;)
Totally. I will only accept Genuine Linux™. I propose this slacker get at least uClinux[0] running before I grant my approval.
You know, I actually saw that video when it was new, didn't realize it was the same dude!
It's extremely cool stuff, it doesn't feel like even an approximation of Unix should be possible on the NES.
Yeah. I consider ELKS somewhat closer to xenix86 and PC/IX than to Linux in concept, at least nowadays. In any case, it's a very interesting project (and so is this NES86 one).
Always has been.
(meme picture goes here)
It's an honor to get a reply from the ELKS inventor! In your own assessment, how much would you say does ELKS have in common with the Linux of back in the day? I've read you say something along the lines of "many of the structures are similar to pre-SMP Linux", but I wonder how much of Linux-of-back-then translated well to x86's segmented memory model without MMU and privilege levels of any kind, and how much of it required significant reimagining. I imagine segmentation instead of paging alone means that the mm layer is probably its entirely own design?
By the way, there used to be some few MMUs for pre-286 x86 CPUs back in the day. It was all extremely custom stuff as far as I can tell. The one I'm mostly familiar with was for 80186, and made entirely out of 74xx style logic chips and a bit of SRAM. It supported page-granular mapping and protection across multiple (hardware-defined) process address spaces + kernel, and even I/O space protection (though original SINIX, the system that used it, did not seem to end up turning on I/O protection for some reason). No on-demand paging though, i.e. page faults had to resolve to killing the process instead of resolving the fault, as the pipelined design of even 8088 CPUs already made restarting instructions entirely unpractical.[1]
It would have been fun to see ELKS support such things, though I don't have the time and energy left to look into that nowadays (especially given that those super-bespoke MMUs were never very common, and are virtually extinct today). I also guess that the more interesting MMUs, i.e. the ones that do have page-granular mapping, also wouldn't fit very well with ELKS in the first place, as it's (presumably) entirely written for segmentation.
[1] There is the famous Silicon Valley lore of a workstation manufacturer running two 68000 CPUs in lock step to work around similar limitations, one CPU running behind the other one so it can be used to "restart" the faulting instruction, but that's a story for another day.
Thanks! It was a long time ago(tm) so my memory's dim (maybe even so-dim), but yeah the MM (and console) code were pretty much original. The VFS and filesystem code were cut down from contemporary Linux quite a bit.
Never had any hardware with those exotic MMU's, so working with them never crossed my radar.
Paging MMUs are still useful, one could just tell the memory allocator to place user space programs at 4K, or even 64K, boundaries.
I realized last night (almost 30 years late!) that I should've implemented a BIOS-type interface (or modified EMS) to do memory mapping and then had a few different handlers (memory swapping, 286 and 386 LOADALLs, 386 v86 mode, etc) to choose from without messing with ELKS itself too much.
Working on ELKS now has the great advantage that the emulated 8088 PC is now faster than the computers anyone had back in the 90's, and all of that emulation can easily fit in CPU caches.
That was Apollo which was Massachusetts not Silicon Valley.
The 90s were a time when hypotheticals such as this were hotly debated by nerdy children at recess. I am very satisfied to see this project to come to fruition.
NES86 uses a mapper configuration that is theoretically valid but generally not supported by emulators nor flash cartridges.
I suppose the next step to take this project to its logical conclusion would be to make an actual cartridge of it that works on a stock NES. Alternatively, add another level by running this in a browser JS NES emulator.
Is there already a good short term for this sort of "testing the limits of Turing-completeness in practice" exercise? Here are two other well-known attempts:
"Cartridge that works on a stock NES" is muddied waters now, since a cartridge can contain a full computer that feeds data directly to the PPU bus, while the main NES CPU mostly runs idle.
Wait, mappers can do ALU-like work beyond mapping the ROMs in cartridges?
Always has been
A few period games, like Star Fox and Yoshi's Island, include a RISC processor and a frame buffer, rendering the graphics in the cartridge before transferring the output to the PPU.
Edit: The original SNES version of DOOM itself ran this way.
Intermediate step would be trying this on an analogue pocket - claimed to be basically cycle accurate. I'm a bit busy right now, but I might give it a go; if so I'll comment here.
Having previously programmed both an NES emulator and an IBM PC emulator, I can say that this is quite an achievement. The IBM PC is much harder to emulate than the NES. This emulator is written in 6502 assembly. So the person wrote an emulator for the 8086 in 6502 assembly.
You might enjoy another project, which uses a RISCV32 emulator on 6502 to boot actual Linux (not ELKS) on a C64: https://github.com/onnokort/semu-c64
It takes about a week to boot, but it's fun.
Wow, this is trippy. I can see how 0-page would really help with the 8088 emulator, but I never imagined running ELKS on a 6502 ;)
I ended up finding the application it's intended to run, ELKS, the most interesting part. ELKS (“Embedded Linux Kernel Subset”) is apparently a very, very old fork of Linux from the 1990's that targets 16-bit real-mode x86 systems with no MMU (e.g. 8086) rather than 32-bit protected mode x86 (80386 and later). It's fascinating in a similar way to how, say, ancient religious schisms are. It's still actively maintained even!
Pretty recent (44 days ago) HN discussion on ELKS: https://news.ycombinator.com/item?id=42596983 - it's doing really well and can even run DOOM! (just not on an NES :) )
I can't pick these up for a few reasons (#dayjob and other hobby projects that I don't have enough time/energy to work on properly!), but here's a couple of thoughts that've been percolating for a while that didn't make the last topic:
- If I were a 19-year old (and odd) college student thinking about starting something like this again (I picked up the idea from Alan Cox and did the early versions suuuuch a long time ago now!), I'd have targeted the Pi Pico, and been absolutely estatic when the RP2350/Pico 2 came out.
You could make a pretty interesting 80/early-90's workstation using a couple of rp2350's (one for frontend, the other to run the hacked-up Linux) w/additional SRAM and Flash.
- One can use a 386+ as a memory mapper/protection unit while still running everything the rest of the system in real/v86 mode, in blissful ignorance that it's running on a 32-bit system.
There's a few RISC-V single-chip computers that put the Raspberry-Pi's products to shame. I'm evaluating the Bouffalo Labs BL808 and the Sophgo SG2000 for an upcoming project. They have MMUs and enough integrated RAM to run a mainline POSIX operating system. Both have multiple asymmetric cores that allow one to run a full Linux OS, one to run an RTOS or bare metal, and one for low-power tasks to run while suspended.
They're basically as capable as a Pi Zero, but work in a Pi Pico form factor. Check out the Ox64 and Oz64 boards from Pine64 or the Duo series from Milk-V.
The Sophgo chip might be increasingly difficult to put your hands on. Putting them on the entity list was one of the last things the Biden admin did.
https://www.federalregister.gov/documents/2025/01/16/2025-00...
Kind of reminds me of Lunix http://www.lunix.c64.org/
Obviously not the same thing, it's not "real" Linux, but a similar goal of getting "something like Unix on hardware that has no business running it".
I have mad respect for these kinds of projects. Writing software on powerful hardware is easy, that's what I do for a living, but people squeezing the life out of the NES and C64 are on another level of intelligence and dedication that I'm not sure I'll ever be able to match.
That's actually exactly what the author of NES86 did at first: he ported Lunix to the NES - https://www.youtube.com/watch?v=SVqN_FixG0M (repo https://github.com/decrazyo/lng-fds).
But then he received a lot of comments saying that it's not real Linux, so he made NES86 to run ELKS and made another video https://www.youtube.com/watch?v=OooHTDMUSGY. It's a bit funny since ELKS does not consider itself Linux anymore, just a "Linux-like OS", so maybe we'll have a third iteration of this project eventually ;)
Totally. I will only accept Genuine Linux™. I propose this slacker get at least uClinux[0] running before I grant my approval.
(Please note the sarcasm in the above comment.)
[0] https://web.archive.org/web/20181113230737/http://www.uclinu...
You know, I actually saw that video when it was new, didn't realize it was the same dude!
It's extremely cool stuff, it doesn't feel like even an approximation of Unix should be possible on the NES.
Yeah. I consider ELKS somewhat closer to xenix86 and PC/IX than to Linux in concept, at least nowadays. In any case, it's a very interesting project (and so is this NES86 one).
Always has been.
(meme picture goes here)
It's an honor to get a reply from the ELKS inventor! In your own assessment, how much would you say does ELKS have in common with the Linux of back in the day? I've read you say something along the lines of "many of the structures are similar to pre-SMP Linux", but I wonder how much of Linux-of-back-then translated well to x86's segmented memory model without MMU and privilege levels of any kind, and how much of it required significant reimagining. I imagine segmentation instead of paging alone means that the mm layer is probably its entirely own design?
By the way, there used to be some few MMUs for pre-286 x86 CPUs back in the day. It was all extremely custom stuff as far as I can tell. The one I'm mostly familiar with was for 80186, and made entirely out of 74xx style logic chips and a bit of SRAM. It supported page-granular mapping and protection across multiple (hardware-defined) process address spaces + kernel, and even I/O space protection (though original SINIX, the system that used it, did not seem to end up turning on I/O protection for some reason). No on-demand paging though, i.e. page faults had to resolve to killing the process instead of resolving the fault, as the pipelined design of even 8088 CPUs already made restarting instructions entirely unpractical.[1]
It would have been fun to see ELKS support such things, though I don't have the time and energy left to look into that nowadays (especially given that those super-bespoke MMUs were never very common, and are virtually extinct today). I also guess that the more interesting MMUs, i.e. the ones that do have page-granular mapping, also wouldn't fit very well with ELKS in the first place, as it's (presumably) entirely written for segmentation.
[1] There is the famous Silicon Valley lore of a workstation manufacturer running two 68000 CPUs in lock step to work around similar limitations, one CPU running behind the other one so it can be used to "restart" the faulting instruction, but that's a story for another day.
Thanks! It was a long time ago(tm) so my memory's dim (maybe even so-dim), but yeah the MM (and console) code were pretty much original. The VFS and filesystem code were cut down from contemporary Linux quite a bit.
Never had any hardware with those exotic MMU's, so working with them never crossed my radar.
Paging MMUs are still useful, one could just tell the memory allocator to place user space programs at 4K, or even 64K, boundaries.
I realized last night (almost 30 years late!) that I should've implemented a BIOS-type interface (or modified EMS) to do memory mapping and then had a few different handlers (memory swapping, 286 and 386 LOADALLs, 386 v86 mode, etc) to choose from without messing with ELKS itself too much.
Working on ELKS now has the great advantage that the emulated 8088 PC is now faster than the computers anyone had back in the 90's, and all of that emulation can easily fit in CPU caches.
That was Apollo which was Massachusetts not Silicon Valley.
The 90s were a time when hypotheticals such as this were hotly debated by nerdy children at recess. I am very satisfied to see this project to come to fruition.
NES86 uses a mapper configuration that is theoretically valid but generally not supported by emulators nor flash cartridges.
I suppose the next step to take this project to its logical conclusion would be to make an actual cartridge of it that works on a stock NES. Alternatively, add another level by running this in a browser JS NES emulator.
Is there already a good short term for this sort of "testing the limits of Turing-completeness in practice" exercise? Here are two other well-known attempts:
https://news.ycombinator.com/item?id=41600756
https://news.ycombinator.com/item?id=37878851
"Cartridge that works on a stock NES" is muddied waters now, since a cartridge can contain a full computer that feeds data directly to the PPU bus, while the main NES CPU mostly runs idle.
See "DOOM on NES": https://www.youtube.com/watch?v=FzVN9kIUNxw
or Reverse emulating the NES to give it SUPER POWERS https://www.youtube.com/watch?v=ar9WRwCiSr0
True, but this runs on the main CPU, although it does appear to make use of a hardware multiplier in the MMC5:
https://www.nesdev.org/wiki/MMC5#Unsigned_8x8_to_16_Multipli...
Wait, mappers can do ALU-like work beyond mapping the ROMs in cartridges?
Always has been
A few period games, like Star Fox and Yoshi's Island, include a RISC processor and a frame buffer, rendering the graphics in the cartridge before transferring the output to the PPU.
Edit: The original SNES version of DOOM itself ran this way.
Intermediate step would be trying this on an analogue pocket - claimed to be basically cycle accurate. I'm a bit busy right now, but I might give it a go; if so I'll comment here.
Having previously programmed both an NES emulator and an IBM PC emulator, I can say that this is quite an achievement. The IBM PC is much harder to emulate than the NES. This emulator is written in 6502 assembly. So the person wrote an emulator for the 8086 in 6502 assembly.
You might enjoy another project, which uses a RISCV32 emulator on 6502 to boot actual Linux (not ELKS) on a C64: https://github.com/onnokort/semu-c64
It takes about a week to boot, but it's fun.
Wow, this is trippy. I can see how 0-page would really help with the 8088 emulator, but I never imagined running ELKS on a 6502 ;)
Highly recommend watching the video linked in the readme: https://youtu.be/OooHTDMUSGY
It is very well produced, funny and informative.
Importantly, this means we can port the PlayStation 3 emulator or mine Bitcoin on the NES.
Let's play a game of Tetris... at 30 seconds per frame :D
"Brain, what do you want to do tonight? The same thing we do every night, Pinky - try to take over the world!"
This is the most vile and nefarious act of evil genius I've witnessed in ages!
Will it run Alley Cat?