Some of you emulator authors might be interested in this. It's an execution log of the nestest test ROM (see http://wiki.nesdev.com/w/index.php/Emulator_tests) with bus cycles included, generated with Nintendulator. So basically the same as the nestest.log that's making rounds, but more detailed. I also removed the PPU cycle counters and included a CPU cycle count instead.

Let me know if you spot any errors in it (I hope I implemented the logging correctly).

It would make sure the emulator is updating the clock at the right time. I know for a fact mine isn't - everything happens in the right order, but some events are on the wrong side of a clock increment, overlapping with the bus cycle before or after and leaving a gap on the other side.

Yes, I know, I'm basically saying I'm a terrible programmer, but that's all the more reason for an automated test.

One interesting think would be generating another log, but using a NMI test ROM. I don't remember of its name, it just displays an "E" in the screen, but the middle "-" must be ok. If the NMI timing (or PPU timing?) is wrong, the "E" is glitched.

I made a revision of the log, it now includes also the data that is being read/written. I removed the disassembly so that comparing the data is easier. Sorry, but still no CPU clocks on every line (feel free to make a small tool to mangle the data that way, and share the results if you want )

NOTE: The log assumes that RAM has been initialized to 0 (there are at least a few cycles that read from uninitialized stack areas).

I noticed that blargg's CPU tests are not good candidates for these types of logs because they have a bunch of hardware dependencies in them. For example they poll $2002 in the beginning which makes the cycle counter and the shown bus data values useless if $2002 reads aren't implemented. Maybe it'd be useful to compile versions of those tests that start at a known address and don't access external hardware (except memory, of course). Such tests would also be easier to run through Visual6502/Visual2A03.

Zepper wrote:

One interesting think would be generating another log, but using a NMI test ROM. I don't remember of its name, it just displays an "E" in the screen, but the middle "-" must be ok. If the NMI timing (or PPU timing?) is wrong, the "E" is glitched.

Any chance?

I think CPU logs of PPU tests would be of limited value, because it'd be hard to notice any problems in PPU emulation from them. And having such logs might only be encouraging people to make Nintendulator emulators rather than NES emulators.

If you're going to go to the trouble of logging every bus cycle, it would be worth using a test ROM that covered all the page-crossing and dummy read cases. I know blargg's tests do, but they're designed to be verified by the code itself and depend on the PPU or APU, as you said.

If you're going to go to the trouble of logging every bus cycle, it would be worth using a test ROM that covered all the page-crossing and dummy read cases. I know blargg's tests do, but they're designed to be verified by the code itself and depend on the PPU or APU, as you said.

If you're going to go to the trouble of logging every bus cycle, it would be worth using a test ROM that covered all the page-crossing and dummy read cases. I know blargg's tests do, but they're designed to be verified by the code itself and depend on the PPU or APU, as you said.

Do we have a CPU-only ROM that does this already?

I'm not aware of such a ROM. Recompiling blargg's test ROMs with some small changes would probably be the best option. Really the only thing that would probably have to be removed would be the $2002 reads, since hardware register writes don't affect timing.

I'm not aware of such a ROM. Recompiling blargg's test ROMs with some small changes would probably be the best option. Really the only thing that would probably have to be removed would be the $2002 reads, since hardware register writes don't affect timing.

The dummy read test ROMs use clear-on-read flags on the PPU/APU as part of the test. They fail (or worse, lock up) when run on a CPU-only emulator. The timing test ROMs also rely on APU reads.

I was thinking of writing a simple test ROM myself, but I'm probably not qualified for the task.

Oh yeah, I was thinking of different ROMs. Anyways, writing test ROMs that don't have to actually verify the results (just exercise the different scenarios) should be fairly easy. Although many of the dummy read scenarios are probably already covered by the normal tests (when used with bus cycle logs).

Who is online

Users browsing this forum: No registered users and 11 guests

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot post attachments in this forum