Who wouldn’t want to run a UNIX-like operating system on their NES or Famicom? Although there’s arguably no practical reason for doing so, [decrazyo] has cobbled together a working port of Little Unix (LUnix), which was originally written for the Commodore 64 and 128 by [Daniel Dallmann]. The impetus for this project was initially curiosity, but when [decrazyo] saw that someone had already written a UNIX-like OS for the 6502 processor, it seemed apparent that the NES was too similar to the C64 to not port it.
Much of this is relatively straightforward, as the 6502 MPU in the C64 is nearly identical to the Ricoh 2A03 in the NES, with the latter missing the binary-coded decimal support, which is not a crucial feature. The only significant roadblock was the lack of RAM in the NES. The console has a mere 2 KB of RAM and 2 KB of VRAM, which made it look anemic even next to the C64. Here, a Japan-only accessory came to the rescue: the Famicom Disk System (FDS), which is a proprietary floppy disk-based system that slots into the bottom of the Famicom and was used for games as well as storing saves back in the day.
By using a Famicom with FDS, it was possible to gain an additional 32 kB provided by the FDS, making the userspace utilities available in the shell. The fruits of this labor work well enough that he could also pop it up on an EverDrive cartridge that supports FDS ROMs and boot it up on an unmodified NES. Whether this is cooler than the NES-OS, which we covered previously, is up for debate.
Incidentally, [Maciej Witkowiak] seems to have resumed development on LUnix, with a new release in 2023, so maybe UNIX-on-6502 may see a revival after a few decades of little happening.
This is neat enough that IF I knew how to, I would want to try to make a custom replacement for the FDS with more memory, maybe 128 or 256kb if the hardware could support it (probably not).
Having the extra storage, I would want to try to port a Linux NES emulator and get a game running, or heck see if it would be possible to create a shim similar to WINE that translates an NES ROM blob so it can be run easily in Linux on NES as if it were a native Linux app.
Speaking of NES emulation..
In the 87/88, someone wrote an Famicom emulator for a Sega Master System. Yes, an emulator that ran *on* an 8-Bit console.
https://www.megavisions.net/yuji-naka-created-a-3d-famicom-emulator-for-the-master-system/
I was wondering about the first console game or computer emulator. Someone needs to write a book on the history of emulation from the IBM mainframes to this gem, to the little-known emulators running on Amiga systems, to iNES and Nesticle on PCs, etc…. I feel like emulators and simulators are only known inside the computer industry and the rebel underground.
Pet Em for C64 is pretty early, 1984 or 85. Some BASIC program coded for Commodore PET that used POKE and PEEK to set up screen display did not work properly on C64. Pet Em remapped some of the pokes and peeks to use PET’s memory location.
Hi, I think quite a few had appeared around the mid-80s, I think.
There were TRS-80 emulators early on, for example. PC-Four comes to mind.
https://shorturl.at/fkIRY
Or PC-Ditto for Atari ST, Aladin/MAGIC SAC for Amiga.
Or that mysterious C64 emulator for IBM PC with b/w screen.
All these were from the 80s, still, I believe.
Apple II emulators were also popular, just like CP/M emulators were (Nice22, Z80MU).
CHIP-8 also was being emulated early, I believe. Graphical calculators in the 90s could emulate that and were being used as Gameboy alternatives.
And by the early 90s, things really started to take off, I think.
Not only on PC, but also on other recent platforms of the day. Like Mac (Soft AT, Soft PC, Silhouette etc), Acorn, or those exotic Japanese systems (X68k, FM Towns)..
There were many Apple II and C64 emulators being written then. MSX ones, too.
Even for ancient OS/2 and Windows 3.1x.
https://shorturl.at/bjrs7
https://shorturl.at/awzDF
For C64 platform, there are at least 3 emulators, I believe.
A PET emulator, a VIC20 emulator and an KIM-1 emulator.
An 6502 simulator also existed for Apple II, I think.
https://hackaday.com/2023/11/11/a-mysterious-6502-apple-2-simulator/
In the early 2000s, PDAs got some emulators, too.
Neko Project II for WinCE, Phoenix for PalmOS, some Sega emulators (Pocket Genesis, CE/gg etc) for WinCE/PPC, PCE for WinCE/PPC..
https://shorturl.at/ehUXZ
I just wonder what happened to Symbian.
It used to be as popular as Android is now.
You could actually access more RAM via a common technique known as “bank-switching.” Essentially the NES cart bus itself will never have access to more than 32KB (in the so-called “PRG” side of things), that’s just a hardware limitation, however you can send signals to a device on the cart bus to change “what” is in that 32KB space. This is how larger NES games with more than 32KB of program code were able to function.
You usually will have a certain amount of “fixed” space that can always be dependably referenced, especially for interrupts and whatnot, but otherwise switching in and out e.g. 8KB or 16KB “banks” of memory is totally feasible and was very common. In theory you could address as much memory as you want, depending on what your memory controller is capable of. (But only at whatever size at a time.)
Having said all of that, if any such mechanism could be implemented in this kernel, I have no idea if it would be feasible. At the very least the kernel would have to be built to cooperate with a particular memory controller that would be available. Also, bank-switched space does not easily lend itself to linear access like we experience today in more modern computing and programming. So it’d probably be better suited to a custom OS that’s “aware” of how memory needs to be allocated and accessed.
I love this kind of stuff. Would like to do something similar with a playstation 2. The emotion engine is my favorite chip ever. I think it deserves a custom linux, but I could never do it.
I’ve got some good news for you – PS2Linux. Released by Sony themselves for the Playstation 2.
To expand on that, although the original PS2Linux hardware/software kits are rare and expensive and only worked with specific PS2 models, there are community projects that allow you to run PS2Linux without the specific hardware in the kit as long as you have a modchip or one of the now-well-known memory card or swap exploits. It was (and is) also possible to run an old version of debian (lenny) and there may have been other distros too. There’s been occasional interest in bringing a more modern kernel and newer version of debian to the PS2, but the work is nontrivial, and to my knowledge nobody has done so.
but anyway if you can work around the PS2’s limited RAM you can totally run linux and even Sony’s linux game devkit on it.
Fds also provides 8 bit of gpio on the ram cart
So you can bankswitch another 64k of extra ram and add something like sa1099 for shits and giggles
Just need a pass-through and cable
And you don’t even need a floppy drive, just use fdsstick either wit microsd or 256mb nand,and dynamically stream much quicker.
How large does the fds image format allow
If it’s like atari, atr floppy format technically allows for 16meg floppy disk….
Enough for nes-geos
What about the expansion port on NES (non-japanese models)? Don’t think it was ever officially used for anything, but would it be possible to add ram or maybe keyboard and mouse PS/2 ports through that?
It was being used by modders, internal.
They wired the “audio in” pin to the cartridge connector.
They did it in a way that matched the pinout of the famicom-NES cartridge converters.
Those which were hidden inside early NES titles.
Doing so routed the “audio out” pin of the mappers to the “audio in” of the NES.
Just like it worked with the original Famicom.
For those who don’t know the story behind LUnix – when I discovered it in the late 90s, the main deal about it was that Daniel wrote a native TCP/IP stack code. LUnix could connect to the local network via a SLIP or PPP link. The C64 was not just a dumb serial terminal; it was part of the LAN. This was a few years before Contiki and many years before the ESP8266-based WiFi modems came around. It was the reason that prompted me to join the project and write code for a native C128 mode (accelerated with its MMU) and then port it to Atari (just for fun).
Thanks! That makes sense. Linux is a walking TCP/IP stack, after all.
Btw, does anybody remember the PIC Server? It used SLIP, too.
Here’s a picture, not sure if it’s the original project or not, however.
https://320volt.com/en/pic16f84-eeprom-basit-web-server-assembly-ccs-c/
The whole software ran on an 16F84(!) chip.
The equivalent to the ATMega328 (Arduino Uno chip) of the day.
One could do a custom cart with much more memory, if i understand the NES memory map correctly one can have 32k game ROM and 8k SaveRAM visible under normal circumstances. Now have a small bootloader in some 8k EEPROM/Flash and 512k of SRAM. The custom banker can turn off the EEPROM, switch trough the SRAM in 32k pages and the first 8k are always mapped to the SaveRAM area.
The kernel then needs to fit into these 8k and every loaded program can have 32k to itself, somewhere along the lines it worked on a PDP11 where every program could have 64k to itself, requesting more if needed if i recall correctly.
The PDP-11 memory management was done through 8 Active Page Registers (APR). The LSI-11/pdp11/03 and T-11 had no APRs, probably a few others, but for any 11 with more than 16 physical address lines, each APR translates a fixed 8KiB of virtual address space to an 8K physical address range. Some models had useful status and control bits that allowed dealing with non-resident pages, so it was/is possible to simulate having more physical memory than is installed.
I used to have a q-bus backplane with an F11 pdp11/23 card, a 32KiB quad slot card, an emulex mfm hd/floppy card and a boot ROM (actually, a grid of diodes that the boot code was encoded into by removing the diodes where a 1 was needed). I had RT-11 programs that could directly access up to 40 kilobytes of data from 16 KB of code space. This was very slow because it swapped the non-resident memory to fixed sectors of the hard drive. From FORTRAN IV, a program could create “virtual arrays” that mapped the arrays to files on the hard drive, even further extending the data space, and using code overlays, the program could be larger than physical memory. The swapping of data pages that I had wasn’t a standard feature, but the rest of this was out of the box.
Well done. You can have extra RAM on (western) NES cartridges too, so maybe a non-FDS Unix will be the next step.
What’s also interesting, the Famicom wasn’t just meant to be a random game’s console.
Famicom literally meant “Family Computer”.
To understand this, we have to go to Japan and go back in time a bit.
In Japan, home computers were considered to be more versatile than pure game consoles.
The ability to use diskettes and create content was seen as an improvement.
However, besides MSX nothing really materialized (yes, there was PC-88, Sharp MZ and FM7 etc. But they were more PC-like and more suited for productivity).
That’s were the Famicom came into play.
It was affordable, versatile and capable.
It found its way into the living rooms of most homes.
That’s why it held the status of a kind of home computer.
Many accessories were being made for it, over time.
Same goes for the Super Famicom.
That’s also why many game designers and publishers started out on business computer platforms like the PC-98.
They produced pretty graphic adventures, poker games and visual novel and so on to earn money, so they could enter the very lucrative console market.
Because, that’s were most customers were. On the console. Unlike here in the western hemisphere.
There are parallels to the European computer landscape of the 80s, I believe,
in which home computers and consoles had a good market share.
They were successfully rivaling PCs, still.
The NES/Famicom were outstanding insofar as they were equally being popular around the globe. Including eastern Europe/ex-USSR (-> Dendy).
Ok, except for Brazil, maybe. It loved Segas. MasterSystem and MegaDrive/Genesis.
MasterSystem was also being popular for a while in western Europe, on eye level with NES at its height.
We quite enjoyed the 8-Bit Sonic games, too.
(Speaking under correction)