Though it was famously started by Linus Torvalds as “a (free) operating system (just a hobby, won’t be big and professional like gnu) for 386(486) AT clones“, the Linux kernel and surrounding operating system ecosystems have been ported to numerous architectures beyond their x86 roots. It’s therefore not unusual to hear of new ports for unsupported platforms, but it is extremely unexpected to hear of one when the platform is a games console from the mid-1990s. But that’s what [Lauri Kasanen] has done, announcing a fresh Linux port for the Nintendo 64.
This isn’t a Linux from 1996 either. The port builds on an up-to-date kernel version 5.10 with his N64 branch and a tantalising possibility that it might be incorporated into the main Linux source for the MIPS-64 processor architecture. That’s right, the Nintendo 64 could be an officially supported Linux platform.
It would be stretching the story a long way to call this any kind of distro, for what he’s produced is a bootloader that loads the kernel and creates a terminal with busybox loaded. With this on your flashcart you won’t be replacing that Raspberry Pi any time soon, so why other than [Lauri]’s “because I can” would you be interested in it? He supplies the answer and it lies in the emulation scene, because having a Linux for the platform makes it so much easier to port other software to it. If this tickles your fancy you can see the source in his GitHub repository, and we’re certainly looking forward to what the community will do with it.
We are more used to seeing the N64 as a subject for case-modding, whether it be as a handheld or a an all-in-one console.
Via Phoronix, and thanks [David Beckershoff] for the tip.
Header image: Evan-Amos, Public domain.
Wow, modern Linux in 4MB RAM on a 64-bit processor! Man that’s tight!
It used to run fine on 66 MCPS Intel 486 with 512 kb of RAM so it got very bloated over last 20 years.
512KB? I doubt that very much.
Me too. ELKS would run on that. Old Minix 2.0 distro might run on that, but Linux needed so damn close to 4MB that if your BIOS did something funny with ROM caching (Seized all UMB) it wouldn’t work.
I remember a review in Byte, maybe it was 1984, for an 8088 computer intended for Unix. Had all of 512K. And really expensive.
Linux got by with small amounts of memory by swap space. An odd situation when hard drives were 240megs.
Text only Linux could get by with less, I think in 2000 it could be 4 megs. But even then, some of the installers were graphic and needed more RAM.
I can’t remember if that 486SLC in 2000 had 4 or 8 megs, but it had a 240meg hard drive. I did the istall and realized I needed a better computer.
Yes there was Sco Xenix for 8086, there was a release for PC/XT but other ports to non-PC x86 such as those based on S100 bus, or not on x86 at all like some 68000 systems. There were a few others you see talked up in the press of the day but many of them didn’t come to much.
Earliest linux kernels, pre 1.x.x you could bring up on a bare 2MB, but then you couldn’t do anything much. At that point it was considered very alpha, development only.
I would presume that since this was based off the MIPS branch of linux that it takes advantage of the trimmed and pruned versions of a more modern linux for low RAM routers to fit into 4MB RAM.
Likewise… back in the day, Slackware 3.6 used to have special instructions for installation on a IBM compatible PC with 4MB RAM… it required a machine with two floppy drives, one which was going to be your “root” disk for the installation environment, and the other was to be formatted as swap space.
That was on the i386 platform, so 32-bit. You haven’t seen slow until you see a 386 SX/25MHz paging out to swap on a 5.25″ floppy.
Admittedly, I’d be very surprised if they were running a n64 ABI on that Nintendo 64, more likely o32, n32 seems a long shot as I think only glibc supports it and that’d chew too much RAM. Not sure if musl has been ported to the other ABIs yet, and last I checked, µclibc’s support for n32 was patchy at best.
(Yes, full disclaimer: I used to be a Gentoo Linux dev on their MIPS team, so whilst no expert, I’ve had a bit of contact with this architecture and still have one Cobalt Qube 2 and a couple of SGI boxes kicking around.)
So what does this mean? Can you break it down into simple terms what this means for the N64? I’m not very techy. (Kinda but not to this degree)
Having extracted the squashfs from the shared linux image, the binaries are apparently N32.
It did. I also worked with it, and also 3.9. It stayed in support until they moved towards 9 and later versions.
Requires 4MB memory expansion, so 8MB minimum.
Allegedly N64 firmware is capable of initializing up to 16MB of ram, and some people back in the day claimed to have soldered additional ram (its daisy chained Rambus). That mod would probably come in handy here.
Even 16MB is tight by today’s standards. You’re not going to be firing up X for a game of GLQuake on this gnat!
Quake ran just fine on 16MB ram in the DOS days. Shouldnt be a problem if this has the ability to make kernel XIP from cartridge.
I believe I ran it on 8MB under DOS and one didn’t have to do severe TSR and driver pruning to get it launched so it was probably okay with ~7.5MB unused RAM. I don’t think it ran on 6MB… I had a 6MB second system at the time, and there were a couple of things, DN3D was one, that claimed to need 8MB but ran on 6. Maybe Descent was the other, pretty sure it wasn’t Quake though.
Super Easy, Barely an Inconvenience.
Wow… Nice
I like for study
I actually think something like this has a possibility of being practical, in very, very limited situations.
N64 and others are an extremely stable platfom regardless of that they’re physically running on, the emulators are designed to emulate one console, that by definition isn’t changed or updated.
If you have an application that fits in that small of a processor, emulation might be the truest write once/run anywhere, beyond what VMs that use native hardware virtualization stuff can do.
Just grab a Dreamcast, it has had native BSD support for decades now with decent networking on top.
Except that it will not currently run in any officially released emulator, per the author’s own comments in the linux-mips mailing list thread that he had the patch in. Even the changes he made in a local copy of cen64 won’t let it run stable.
I have a few games that ran on 16mb of memory, so it is possible to run other games, but the controls will be weird. But will this help the emulation community on running N64 smoother and more accurate? Some games look or sound weird with emulation but this could help that. Just saying, don’t know much emulation and stuff.
How are they getting around the lockout chips on the N64?
Originally you had to use a donor CIC chip from a real game on the Everdrive but in recent years they reverse engineered it and made a clone
I stumbled across a mentioning, that said a mips 64 worked in the N64. Rather than developing my own evaluation board or buying one, I thought, it has a jtag interface, so why not buy one cheap and use it as an evaluation board. So, has anybody any experience with N64 and jtag?