If you were in the market for a games console in 1990, the chances are that the object of your desire was either a Super Nintendo with its 16-bit 6502 derivative, or the Sega Megadrive, sold as the Genesis in North America, with its Motorola 68000. Both machines featured impressive graphics and sound for their time, but they remain firmly in the 16-bit era. Which makes it a surprise to see LinuxMD. It’s Linux, for the Sega Megadrive, with the latest mainline kernel.
The Motorola 68000 series of chips was the first porting target for Linux, and is still maintained in 2026. This build runs from an SD card in a modern Megadrive storage peripheral, and is reported to run on the original hardware. The lowly 68000 in the Sega doesn’t have a memory management unit required for the full Linux experience, so what’s really running here is a kernel compiled with the -nommu option. That in itself is a feat, on this architecture. On it you get smolutils, a cut down coreutils, and that seems to be it.
We like this project, for pushing both console and kernel to the limit, even though we see that maybe it’s not the most practical Linux machine. Meanwhile though, this isn’t the only UNIX-like OS for this console.
Image: Evan-Amos, Public domain.
Sega does what nintendon’t.
Also in 1990 the Super Nintendo wasn’t released yet (North American release on august 23, 1991, worldwide release throughout 1992), although the Japanese Super Famicom was released at the end of 1990 (november 21). By that time the Mega Drive had been out for over two years in Japan (october 1988).
Also, I think, the Sega MD/Genesis did originally rival the Famicom/NES rather than the SFC/SNES.
Other rivals of the era were (for example) the NEC PC Engine/TurboGrafix-16 or Sega MasterSystem.
The MasterSystem (and earlier Sega Mark III and SG-1000) was Segas original answer to the Famicom/NES.
In Europe and Brazil, the MasterSystem did rather well.
In early 90s, the SMS II was quite common, on eye level with the NES.
It and its game collection was seen in stores and in catalogues of mail order companies.
That being said, home computers such as C64, ZX Spectrum or A500 were still common in parts of Europe before 1994 or so (MSX in other places too).
They were used by the older generations, still, who missed out on then-current consoles such as NES, Genesis/MD or Super Nintendo.
It says that in 1990, that the super Nintendo or mega drive were probably the object of your desire, which although the super Nintendo had yet to be released, due to its early announcement and show asking in magazines, TV spots, demonstrations at tech shows etc, it was still indeed for many people globally, the object of their desire in 1990.
Running a mainline Linux kernel on a Motorola 68000 architecture with the nommu option is an incredible feat of optimization. Pushing vintage hardware to its absolute structural limit always gives great insights into low-level rendering. I look at similar device constraints when testing high-speed mobile game assets and tracking layout performance metrics over at https://geometrydashpro.net
Welp, I guess my whole RAM-hacking arc is officially postponed!
I was deep in my theoretical lore of how to get a massive RAM upgrade for the Mega Drive – the kind that’s totally overkill but, like, cute enough to be cool. Thinking about hooking up 5V SRAM and trying to sneak about 10MB of memory by messing with those unused address spaces (you know, where the Sega CD/32X bits usually hang out). It was supposed to be a total glow-up for the console! In all that I forgot that PSRAM is a thing and it’s pretty cheap (unlike 5v SRAM)
My backup plan involved getting the PiStorm to handwave the memory mapping away. But alas, the PiStorm doesn’t handle all the bus signals so no go there on a Megadrive.
But seriously, gotta shoutout to fifteenhex! Taking the time to make something this wild actually work is straight-up legendary. Maybe once all my other cute (and highly ambitious) coding projects are finished -like, when that actually happens – I’ll get around to it! Don’t wait up for me.
In regards to Pistorm bus signals, you should check out the Atari section of the Pistorm Discord where they’ve added those bus signals (which atari also needed)
Cool! A memory upgrade makes sense to 68010 users, maybe.
Because some games (Sonic 3?) use deompression of data and run out on memory if an 68010 is used.
Having slightly more memory could make those games run on a MegaDrive with the 68010 upgrade.
SEGA DOES WHAT NINTENDON’T
You just know somebody is going to see this and take it as a challenge, but I think it’s genuinely true in this case. Directly porting Linux to the SNES’s 65C816 CPU seems impossible due to its lack of necessary features like 32-bit registers (which yes, the 68000 on the Genesis/MD has).
You could still get Linux running on the SNES through emulation of a RISC-V core; people have managed to get it running on the Commodore 64(!) using this method, and since the SNES’s CPU is a 16-bit successor to the 6502, that might be a good starting point.
Of course, there were a lot of SNES cartridges that enhancement chips, including some that added an additional CPU(!), so it wouldn’t be completely out of line to take advantage of one of those chips; unfortunately, that CPU was either the famous SuperFX chip (as used in StarFox, etc) or just another 65C816 clocked at a higher speed (Super Mario RPG and a few others). Neither is particularly helpful here.
Hi! I think the 68010 would be a better choice for *nix since it allows for virtual memory and an MMU (68451).
The plain 68000 is a relic of the 1970s and already was dated by the point it sold in high volumes.
The younger 65C816 notably was used in the Macintosh’s in-house rival, the Apple IIGS.
Surprisingly, its performance wasn’t too bad compared to 68000.
Btw, one difference between SNES and MD is that the former has an overall more intelligent chipset (comparable to the Amiga), while the MD has more raw CPU power.
The MD video chip notably supports parallax scrolling, though.
That’s why Sonic games worked so well on the MegaDrive/Genesis.
Also, the MD can use the remainings of the MasterSystem.
The Z80 CPU as a sound co-pro, the old PSG for extra music channels..
So, the 68010 in the Genesis/Mega Drive is something that some people have attempted before as a modification, but it didn’t have full compatability with the games. For example, Sonic 3 (& Knuckles) did some dirty tricks with stack frames to get the most out of the platform, and the stack frame format was changed in the 68010, so those tricks just corrupt things instead.
As for SNES/SFC coprocessors, one of the very last games to come out in Japan for the Super Famicom was “Hayazashi Nidan Morita Shogi 2”, which actually had an entire ARMv3 processor in the cartridge to make the computer-controlled opponent not take hours to make a move. At this point you’d basically be wiring a Pi Zero to a SNES cart and saying the SNES runs Linux…
To be fair, chess games not seldomly came with their own CPU, to provide a strong AI.
There’s that chess card for C64, for example, “The Final Chess Card”.
It comes with an 6502 style processor.
https://www.c64-wiki.de/wiki/The_Final_Chesscard
Or The ChessMachine (by TASC), an PC bus card with 128KB, 512KB or 1 MB RAM and an ARMv2 processor.
https://en.wikipedia.org/wiki/ChessMachine
https://www.youtube.com/watch?v=5qA5jtL_01U
That’s not cheating, but part of a long going tradition.
Because serious chess players have standards, too.
They need an opponent they’re being challenged by.
I guess that also applies to the strategic game played by the SFC game.
I didn’t know about that last “Morita Shogi” game for the SFC.. interesting.
But yeah, even if the ARMv3 processor in that cartridge has direct access to the SFC’s memory bus, and even if it was possible to compile a version of linux for it, it would feel a bit “cheaty” to use that compared to the Genesis/MD solution.
Though I’d still call that a lot more legit than grafting on a modern microcontroller or SBC like a Pi or ESP32, and a much more interesting (if obviously still completely impractical) project.
(also, as an aside which in no way diminishes what’s been accomplished here: this Genesis/MD project still isn’t really capable of running on “stock” hardware of the era, since it depends on the Everdrive cartridge to provide SD card read/write storage, as well as the Everdrive’s extra RAM and the custom mapper to access it.)
The 68010 is undoubtedly a better choice than the original 68k for various other flavors of *nix, like you say, but I don’t think Linux can take advantage of any of its new features, since the kernel doesn’t support the 68451 MMU.
Of course, for all I know it might be possible to add that support… if someone as crazy as the author of this project put their mind to it. But its architecture is very different and arguably rather awkward compared to what Motorola adopted for the 68020/68851 and everything else that came after.