What ROMs should I use when writing an emulator

[albailey]

I've noticed that a lot of people mention a particular game to verify that a particular feature of their emulator is working.

Is there a list or checklist for this anywhere?

I am thinking each mapper has a particular rom that works best at excercising all that mapper's features, but many roms might only use a subset of a mapper's capabilities.

Also, is there is a particular order people tend to test/develop against?

For example, my emulator is in its infancy and doesnt even have sprite support written, but thankfully I was able to run nestest to hammer out all the bugs in my CPU.

I imagine I next one I will tackle is Blargg's Official_6502_test (although to get that one, I will need basic scrolling and MMC1 support)

PS: Writing and working on this emulator is turning out to be a lot of fun.

Thanks,
Al

[Disch]

I've noticed that a lot of people mention a particular game to verify that a particular feature of their emulator is working.

Is there a list or checklist for this anywhere?

I believe there's a small list of "problem games" on the wiki somewhere. Other than that, I'm not aware of any real list other than random postings on the forum.

I am thinking each mapper has a particular rom that works best at excercising all that mapper's features, but many roms might only use a subset of a mapper's capabilities.

I tried to make mention of games with possible mapper issues in these mapper docs </plug> (note that RHDN seems to be having server trouble at the moment, so you might have trouble downloading). I think the wiki probably mentions such games as well.

Also, is there is a particular order people tend to test/develop against?

You can do it in any order, really. The only thing is that to test a particular aspect of the system, you might need to rely on other parts of the system, first. For example you can't very well test NMIs if you don't have a functioning CPU -- so in that case you'd have to make sure your CPU is good before working on NMI details.

But other than that, any order is fine. I generally tried to focus on native NES issues first before working on any mappers. So like...

- CPU
- PPU and video output
- NMI
- Joypad
- CPU Timing and CPU/PPU interation
- Sprite 0 hit
- Sprite overflow
- $2004 read during rendering trickery
- APU and audio output
- Frame IRQs
- DMC stolen cycles
- DMC IRQs
- then start with mappers and/or other input devices.

One thing to note is that the CPU should be nailed as soon as possible

For example, my emulator is in its infancy and doesnt even have sprite support written, but thankfully I was able to run nestest to hammer out all the bugs in my CPU.

CPU is very very important because it can be difficult to tell a CPU bug from any other kind of bug... like say, a sprite bug... or even a file loading bug, or anything else. If a sprite is glitched and you go dig through your sprite code for hours (or days! or even weeks/months!) only to find that your sprite code is fine, and the bug was in your CPU.

So get the CPU down first... then it will be easier to properly identify and attack bugs further down the line.

I imagine I next one I will tackle is Blargg's Official_6502_test (although to get that one, I will need basic scrolling and MMC1 support)

If nestest.nes passes, you should be fine for most commercial games. I wouldn't worry about adding MMC1 support and whatnot just to try this ROM -- I'd wait until you would normally choose to add that stuff and try the ROM when it's conveinient to do so.

PS: Writing and working on this emulator is turning out to be a lot of fun.

Isn't it though? I had a lot of fun with mine, too. =D

[Dwedit]

Simple mappers aren't very hard to do, so mapper number doesn't really matter.

I hear the easiest game to get working is Balloon Fight.

Otherwise, just play various games on it.
Some games can be used as simple tests to see if you're doing it right or not. A very badly implemented MMC3 mapper will crash on Kick Master for instance.