nesdev.org

Hi,

I've ported my OS called ados to the NES, there's plenty of code for further development and as it was written for x86 it compiles with cc65 (http://www.cc65.org)

Features are 5.2Kb binary now, task management, screen device, some elf code, kmemcpy, kmemset, kmalloc, kprint.

The plain x86 code is at https://sf.net/projects/ados-os/ and the NES port at https://sourceforge.net/projects/ados-os-nes/

The plain version has a MBR bootloader and device code directory among other things which can be included in the kernel.
I will work more on the device (e.g. a ramdisk) and latches code for more NESsy stuff and maybe some hardware hacks.

A C64 port may be made out of it too.

Best Regards,
erana

I couldn't find a demo.nes binary to check out what your work could do. Does such a thing exist?

Also, I hope you continue with your lisp project so we get a more accessible game programming language on the beloved NES

where can I find the nes file?
I always wanted to run an OS on my Famicom!

To answer you questions about a valid .nes file :

You have to link the binary object files with ld65 for that, while I only use cl65 :

'ld65 -t nes -o kernel.nes *.s' should work.

Note that I didn't provide a main function. You can start the kernel with a main function but it isn't necessary. The above command also works for a binary with main function.

The explanation of this is a valid .nes file with the right offsets to load on e.g. a NES emulator.

This should answer you question.

About neslisp, I am still working on it. You can even load that program in ados-nes and make a lisp machine for the nes. The problem at this time of writing however is memory area overflows because of bad code without the C keyword const. If you fix this in neslisp it should work.

Further on I want to provide some small Smalltalk kernel inside ados-nes. FYI.

Have fun!
erana

erana wrote:To answer you questions about a valid .nes file

I think the point was that most people just want to try the ROM, not build it themselves. So you'd make yourself and others a favor if you included the ROM somewhere, or linked to it.

You have to build it as it is unusable except for coding extra functionality. The compiler is at http://www.cc65.org

FYI, another way (if you exclude bootnes.s out of the Makefilei, older ados-nes versions do not include it) to generate a valid emulator ROM file:
If you're on UNIX, Linux or Cygwin on Windows and want a ROM.nes file :

save this perl script to gen.nes.pl :

#!/usr/bin/perl
use IO::File;

if ($ARGV < 1) {
print "Usage : gen.nes.pl <filename>";
}

open(FH, $ARGV[0] + ".nes");
for (my $i = 0; $i < 8000; $i++)
{
print FH "\0";
}
close(FH);

print "Written 8000 zeroes header file, please cat (" . $ARGV[0] . ".nes)";

1;
EOF

Then do 'chmod +x gen.nes.pl', then run 'perl gen.nes.pl os.nes' then run 'cat kernel.bin >> os.nes'
(this includes the ROM offset on bus address 0x8000 so your emulator loads from that address, in this case for a rom file it is just a file address, emulators provide more that that you know
Load 'os.nes' in your emulator to test.

erana

I feel obliged to point out that an easier way to get a file containing 8000 zeroes on *n*x is dd if=/dev/zero bs=8000 count=1 of=target.nes

I think you would benefit from building some bootable demo rom of the OS if only because source distributions are not a great way to distribute NES software. This is mostly as a result of different ways of building NES games that don't really conform to much of a standard (assembler differences, etc). For the same reason a lot of projects tend to just include the assembler and build script with the project, even though it's not great practice.

lidnariq wrote:I feel obliged to point out that an easier way to get a file containing 8000 zeroes on *n*x is dd if=/dev/zero bs=8000 count=1 of=target.nes

You can use this which is better, there's even a dd command in cygwin.

Am I the only one wondering what use is this for ?

What is, exactly, an OS in the first place ?

My impression is that it's a program that can run one or multiple programs, that interacts with system calls and that can handles crashes or errors in programs (as opposed to run them natively). I might be wrong though, as I am really not knowledgeable about this. I've never seen the interest of an OS in embedded applications, when you can program things straight away.

Are Cisco routers and the I/O processor on a Wii game console "embedded"? They both run IOS (not to be confused with Apple's).

@ Bregalad

How about surfing the web? reading a PDF file? making a Text file? Viewing JPG files? ....
I feel that OS is just a selection menu! So my multicartridges have OS!

Well, modern OS sure looks like selection menus, but in fact they of course do a lot more work in the background.

If you remember the "good old days" when you had only DOS, there was no selection menu, just a command line, yet there still was an OS (even if it was doing much less than what a modern OS does).

One of the main uses of an OS is to allow for multiple programs to run at the same time : For instance, you can open Firefox and Notepad++ at the same time (and in addition your OS will display what those programs does in the screen, in addition of displaying a task bar, etc...) and all these programs of them will "run" without seeing eachother, something not possible on a system without an OS).

However in some embedded applications and in the good old DOS there was only a command line and a single program running (non multitasking OS) which makes me not understand why the OS is useful in the 1st place. Of course I know it is useful but I don't know why, so I can only speculate.

My guess is that it can abstract hardware details (so you don't have to code your application for all motherboards in the world, all graphics card in the world, etc...), and it can help to recover errors (like a segfault). On the Commodore 64 (which is debatable whenever it has an OS or not), if you would do an error you'd see weird colours on the screen and the computer simply crashed, you'd have to reboot it to return it to normal. With DOS this normally wouldn't be the case any longer.

Which leads me to the following question : What is an OS for the NES of any use ? There's no need to recover from errors, and no need to abstract hardware details as a game engine revolves around them basically. So in a normal NES game, the game engine "replaces" the OS.

What is an OS for the NES of any use ? There's no need to recover from errors, and no need to abstract hardware details as a game engine revolves around them basically. So in a normal NES game, the game engine "replaces" the OS

How about this :
With a proper OS maybe it is possible to connect a keyboard to the NES and start coding the game on the console and then run the code directly on the real hardware!

Bregalad wrote: the computer simply crashed, you'd have to reboot it to return it to normal. With DOS this normally wouldn't be the case any longer.

Are you saying DOS would handle a crashing program? I would have to disagree. Real mode DOS let the applications have full control of the system. You often would have to hit CTRL-ALT-DEL after the system froze. It is possible that a program could detect an error and print a message and exit properly, but that is just as possible on something like the C64.