Hi All,
I posted this in the #nesdev channel, but I think it got lost in the noise. I don't know what the rules surrounding modifying the wiki are, but I believe this sort of thing would be a fine addition. Basically, the evaluation process as described in the wiki was hard to verify an emulator against. You could be 90% sure that you're doing it right, but no real way to verify that.
So I went ahead and generated what I believe are the 3 most useful contexts the evaluation can run in:
- 1 sprite on the raster. This would help to verify that the empty sprite slots do indeed contain sprite #63's y-coordinate, then $ff for the rest of the fields.
- 8 sprites on the raster. This verifies that the buggy behavior kicks in and is simulated properly, as well as writes being turned into reads.
- 9 sprites on the raster. This verifies that after the 9th sprite is found, the buggy behavior ceases.
I have these logs hosted here. The file "OAM - Simulation Cases" describes the context that the evaluation process is running in.
Using the logs referenced above, I was able to verify very rapidly that my emulator matches the expected output. However I did note that V:261 did give different patterns, so I'll need to investigate that more before I make logs for that line.
PS: The logs were generated using Visual2C02.
I posted this in the #nesdev channel, but I think it got lost in the noise. I don't know what the rules surrounding modifying the wiki are, but I believe this sort of thing would be a fine addition. Basically, the evaluation process as described in the wiki was hard to verify an emulator against. You could be 90% sure that you're doing it right, but no real way to verify that.
So I went ahead and generated what I believe are the 3 most useful contexts the evaluation can run in:
- 1 sprite on the raster. This would help to verify that the empty sprite slots do indeed contain sprite #63's y-coordinate, then $ff for the rest of the fields.
- 8 sprites on the raster. This verifies that the buggy behavior kicks in and is simulated properly, as well as writes being turned into reads.
- 9 sprites on the raster. This verifies that after the 9th sprite is found, the buggy behavior ceases.
I have these logs hosted here. The file "OAM - Simulation Cases" describes the context that the evaluation process is running in.
Using the logs referenced above, I was able to verify very rapidly that my emulator matches the expected output. However I did note that V:261 did give different patterns, so I'll need to investigate that more before I make logs for that line.
PS: The logs were generated using Visual2C02.