I discuss my progress on my project to write an NES emulator in java. This is largely an educational project. I wanted to learn more about how hardware is emulated, how hardware is tied together in these small computers, and I wanted to learn more about assembly. The source code for the project is open source and is being released here: lambnes google code page
Saturday, March 26, 2011
0.0.1
you may be interested to know that I have released version 0.0.1 of my NES emulator: lambnes. It isn't quite perfect, and it doesn't yet have sound, but it is able to play Balloon Fight pretty accurately.
Subscribe to:
Post Comments (Atom)
Congratulations on getting this far! You should be able to get a whole lot more games working soon.
ReplyDeleteSome things you're going to want to implement, though:
- a file dialog for opening ROMs, since I wasn't able to launch anything from the command line reliably and had to resort to editing the code (and probably some support for unzipped ROMs as well, which is as simple as using a FileInputStream instead of a ZipInputStream based on the extension.)
- the flag for each sprite that flips sprites vertically
- the flag in the PPU that makes the address increment by 32 instead of 1 on reads and writes (this is why Donkey Kong's title screen is messed up)
- It seems that when there are more than 2 sprites on a line, some of them start disappearing? the NES actually supports 8 sprites on a line at once.
- the background is using the wrong palettes, probably because you're not reading the attribute tables correctly (this is a really difficult bit of code to get right so don't worry too much about that)
- Sprite 0 hit doesn't work (Super Mario Bros. won't do anything without it)
- Finally, if you want to get scrolling working, you NEED to look at loopy's The Skinny on NES Scrolling.
http://nesdev.parodius.com/loopyppu.zip
There's really no better reference than this, and without implementing things this way you're never going to be able to properly deal with games that mess with the scrolling in the middle of a frame.
Anyway, good luck with your emulator! This is probably the best part of emulator development right here; after you have the APU and scrolling working what comes next is implementing a myriad of mapper chips (and dealing with broken headers on the ROM files), and then dealing with the hundreds of special cases and edge issues that some games expect to work properly. And there are over 2000 games out there, some of which don't even work on a real NES because they were written for old inaccurate emulators, and some of which use custom hardware in the game itself, so don't ever expect to achieve 100% compatibility.
hey -- I've taken a look at the loopy document, but haven't implemented the code. At all, really. That's one of the features I want to implement for the next release along with some user interface code to make loading files easier. The code for most of that is recent and buggy, as you noticed. I think it mostly works if you put in an absolute path that goes directly to a rom. The file dialog is probably more user friendly than command prompt.
ReplyDeleteI had tried to run Donkey Kong as well, and had noticed that big parts of it were jacked up. For some reason I wasn't able to move very far in that game either as well as the title screen bug that you noticed.
I've implemented sprite0 code, but haven't had a good chance to test it, so it probably doesn't work. Maybe it's a good time to start looking at emulating super mario. It'd probably be a good place to start in debugging my sprite0 code and maybe as I work on scrolling.
Thanks for taking a look at my code. There's still a lot I need to do, but now that I'm actually able to run software to one degree or another I'm probably to the funner part of emulator development. I'll definitely use this list you came up with as I'm trying to keep track of what doesn't work for the next release.
It looks like the command line argument that is expected is actually the folder where the ROM zip files are located.
ReplyDeleteyes -- thanks. I've corrected it in local code. I was just passing around the file name and kind of assuming where the file was located. It wasn't a bad assumption the way I typically use it, but a poor assumption for the way the command line is supposed to work.
ReplyDelete