Live data from Hacker News

New Linux port for the Nintendo 64

lore.kernel.org

141–150 of 205 posts

Re: New Linux port for the Nintendo 64

#141

Earlier quoted context omitted.

I would argue that a microkernel would be a good fit because: "Traditional operating system functions, such as device drivers, protocol stacks and file systems, are typically removed from the microkernel itself and are instead run in user space." - https://en.wikipedia.org/wiki/Microkernel You want to throw out as many functionality as possible to get your kernel down in size to fit into e.g. 1 MiB of memory.

Those operating system functions still need to exist and still consume RAM. It doesn't matter whether they run in userspace or kernel space. If you don't need those functions, you can remove them from kernel space in a monolithic kernel. It's possible to build Linux without TCP/IP support and with no on-disk filesystems.

Yes, it is possible to strip out subsystems from the linux kernel, but there are limits. For example: https://weeraman.com/building-a-tiny-linux-kernel-8c07579ae7...

They achieved a compressed linux kernel size of just 749 kB which additionally requires at least 12 MB of RAM to boot. This is very impressive, but there a constrained systems with 1 MB or less of memory.

Re: New Linux port for the Nintendo 64

#142
post #69

Earlier quoted context omitted.

IIRC from a talk a few years ago, Xorg can be stripped down to around 600KB, so you could probably have a minimal X environment.

TinyCore (on the frontpage a while ago) fits an OS with a FLTK/FLWM desktop in 16 MB of storage⁰, but it requires a bare minimum of 46 MB of RAM to boot (regardless of swap space, which it recommends along with 128 MB of RAM).¹ OTOH KnightOS² (not Linux) has a rudimentary (obviously not Xorg) GUI that IIUC runs on TI-73 series graphing calculators with 25 KB of RAM. ⁰ http://tinycorelinux.net/welcome.html ¹ http://ti…

Tiny X existed and Basic Linux ran in those specs:

https://distro.ibiblio.org/baslinux/

Re: New Linux port for the Nintendo 64

#144
The cartridge port on the N64 exposes a 32 bit address bus, Theoretically there's nothing stopping someone from cramming a gig of SRAM inside a cartridge to increase the memory from 8mb. It's directly addressable by the cpu, even if it's not the RDRAM bus.

Everyone here saying 8mb too small, well just add more ram.

Re: New Linux port for the Nintendo 64

#145
post #116

Earlier quoted context omitted.

It was very barebones. FVWM was the window manager I used, running on SLS Linux with a 0.99.xx kernel.

I used fvwm as my main environment back then. It was really good. You can still see its influence in Raspbian and other desktops like that. I actually had a gig with SLS Soft Landing back in the day. It wasn't unrelated to the stuff I was doing with uucp at the time. That was important then, but totally not at all today, lol. I am assuming you are making a bit of a jest, because things have moved along in the past ma…

I used to do a ton of stuff with UUCP back in the day. Fun times. I had about a 5 other systems calling into mine for UUCP mail.

You are right. Linux has evolved tremendously over the past ~30 years. Those early times were fun though...

Re: New Linux port for the Nintendo 64

#147

This is, of course, cool. No doubt. I have an EverDrive 64 and I’ll probably test this out later today or tomorrow. I am skeptical that this would be the preferred way to port emulators or graphical games. You’re not getting a budget SGI workstation out of this, because the OS kernel itself is only a small part. The N64 is built around a chip called the Reality Control Processor, or RCP. This contains the RSP, stripp…

I don't think anyone is claiming that the N64 is finally unleashed with this, or anything. It will knock down an entry barrier for some people, though, and there's no harm in that at all.

> I don't think anyone is claiming that the N64 is finally unleashed with this, or anything.

Just trying to temper people’s expectations.

> It will knock down an entry barrier for some people, though, and there's no harm in that at all.

To be honest—I don’t think this is lowering the barrier of entry to N64 development much. Those are the expectations I’m trying to temper here. If you want to develop for N64, you’re going to go through a lot of fuss getting an EverDrive 64 or a similar alternative, setting up an accurate emulator like CEN64 (the popular emulators are not suitable for development), getting toolchains running on your development system, etc.

I think some people have equated “Linux has been ported to system X” as “development for system X is now solved”, when Linux is only a small part of the solution, and for smaller systems (like the N64, which has only 4 MB RAM base), Linux is probably not your kernel of choice anyway.

The Nintendo 64 development scene would definitely benefit from more people pitching in and doing tools development. This is a good time to do it, there are a lot of gaps ready to be filled, and the number of people doing N64 development has increased quite a bit over the past couple years.

Re: New Linux port for the Nintendo 64

#148

Earlier quoted context omitted.

The kernel is small, because all the extra stuff is outside the kernel. It's still stuff that exists and consumes RAM.

No, because e.g. the monolithic linux kernel is filled with many things that you do not need (but others do) in very constrained environments. If you have a very small microkernel, then you can very explicitly only install the software in user space that you need, without having them pre-installed via kernel.

Really, the term "micro" is about size, not functionality.

The fact is, the Linux kernel can be compiled with features to suit constrained environments. It is just that these features are determined at build time, not run time.

Re: New Linux port for the Nintendo 64

#149
post #148

Earlier quoted context omitted.

No, because e.g. the monolithic linux kernel is filled with many things that you do not need (but others do) in very constrained environments. If you have a very small microkernel, then you can very explicitly only install the software in user space that you need, without having them pre-installed via kernel.

Really, the term "micro" is about size, not functionality. The fact is, the Linux kernel can be compiled with features to suit constrained environments. It is just that these features are determined at build time, not run time.

Yes, that is true but there are limits as I've explained here: https://news.ycombinator.com/item?id=25544271

Also quite interesting this question already came up on Quora https://www.quora.com/What-is-the-smallest-in-size-Linux-ker... and also on many other websites: https://superuser.com/a/370588

Re: New Linux port for the Nintendo 64

#150

Earlier quoted context omitted.

Deja-vu I suppose https://www.theverge.com/2016/6/22/12008286/sony-ps3-linux-o...

If you're building a hardware and have to ship it with an OS, Linux is the obvious choice for most... but the GPL licensing makes it very difficult for a lot others. There's a reason a lot of open source in recent years have avoided GPL as a plague and opted for BSD or MIT or Apache licenses.

> Linux is the obvious choice for most... but the GPL licensing makes it very difficult for a lot others

Linux stayed on GPL2 instead of upgrading to GPL3 precisely to allow others freely using Linux in their commercial devices. In other words: they made the intentional choice of making it legally easy to embed Linux in proprietary hardware products (aka. Tivoization, which GPL2 allows but GPL3 forbids)

Post reply on HN