Wich rom do you recommend me for starting testing a emulator project

depends how far you are
if you just starting, one of the simple diplay picture roms like the zelda screen simulator
if you much more advanced than maybe the nestress rom

i dont know if you are writing everything your self or using an already finished cpu core. but this is how i did it when i started writing my own emulator.

I wrote my CPU core alonge with a basic PPU that emulated NMI on VBlank (no graphics), and tried different mapper0 games. As the games should run without the cpu giving any error. it is important though to set the VBlank bit and give a NMI if bit7 of 2000 is set. cause many games check this when they are starting (basicly waiting 1-2 frames, before they continue). many of the very old nes games that dont use any scrolling at all is usaly very easy to emulate as those dont use any "dirty" ticks to get things done. (i.e Mario bros, Donkey kong, Popeye)

When you got a working CPU core you should move onto getting the PPU to render some graphics. the BG tiles are best to start with as most of the screen consist of BG tiles. dont bother with the attribute bytes to begin with as those are not needed to se if you render the tile correctly, they will just change the color of the tile, but the pattern will be the same. When you got a working BG renderer you can move onto scrolling or sprites.

(basicly how i did it anyway)
-Eshin

Good question. You can start by a *cough* commercial *cough* image *ahem* (like SMB1), or the homebrew ones (most of them are posted on NESdev site). My tip: write your own cpu core, develop a disassembler to see where the game hangs (error), do your best. Remember that you can write something very basic, but must be accurate somewhat - gfx helps, sound too, but this one isn't required for now. Don't bother for IRQs. Try to emulate the NES I/O registers correctly... take a break... restart... that's it.

My tip: write your own cpu core, develop a disassembler to see where the game hangs (error), do your best.

I've written a few CPU cores and had the idea to test them by running them in parallel with someone else's CPU core. The verifier runs the other CPU core first and logs writes and reads (and save the result of the read), then runs mine with memory functions which veriy that the same reads/writes occur. It compares all registers after each instruction and stops in the C++ debugger when there's a difference. It's been really useful for finding bugs, in *both* CPU cores :)

It's really useful to write code in independent modules. It's easier to keep track of what's going on, and it allows each to be tested independently. If I were writing a disassembler I'd make it in a separate module and not clutter my CPU up with it. Have the CPU module return a special result when it encounters an unhandled instruction and then disassemble from the program counter. I get a headache trying to deal with programs that are tangled up like the wire mess behind my entertainment system.

But comparing logs depends on your I/O registers working properly.

Uh... yes, I did that. It has generated a huge LOG file within the 2 CPUs, but not in parallel - one game was loaded, LOGged, the cpu core switched & run again. I could trap a bug in my RTI/RTS mnemonics emulation.

But comparing logs depends on your I/O registers working properly.

The way I described, it doesn't matter how the I/O system is implemented or whether it works properly. All that's compared is the operation of each CPU core in the environment.

For example, I run the control CPU core for one instruction and it makes a memory read then a write. The memory read is made like normal, then the address and value are logged. The memory write is performed as normal, and the address and data written are logged. Then I run the CPU under test. Its memory accesses go to special functions which only verify that the address matches the one in the log (and in the same order the accesses were originally made). For a memory read it returns the original value read (i.e. doesn't access the emulated hardware again). For a memory write it verifies that the same data value is being written. After running the CPU under test, it verifies that the same number of memory events occurred, then compares all registers and the cycle count.

Thus, it doesn't matter how well the hardware is emulated (though, if it's emulated very poorly, the code being executed might not do anything interesting, and thus might not exercise much of the CPU emulators).