sprite evaluation and blarggs sprite overflow test

[mattmatteh]

i got most of blarggs test to pass, still stuck on sprite over flow test 3.timing.

i was following the sprite evaluation on the wiki (quietust' wiki) and it says cycles 64 - 255 is the evaluation of 64 sprites. read on even cycles and write on odd cycles. that is 64 * 2 = 128 cycles. however 255 - 64 != 128.

first i was ignoring the even/odd cycle thing and doing all sprites 64 - 128 and failed 3.timing error number 4; then i changed my code to evaluate with the even/odd cycles so that it evaluates 64 - 192. now i fail blarggs test 3.timing error 12.

quietust, i think you said you wrote the sprite information? did i read something wrong ?

also, did you have the test roms you used, i think you said before you might post them ?

thanks

matt

[Quietust]

You forgot to count the extra 6 cycles used by each sprite found. Also, further cycles are spent simply "thrashing" until the end of the visible scanline, as described on the wiki.

Also, the test ROMs I used did little more than display numbers on the screen corresponding to carefully timed reads from $2004 - without knowing exactly what sprite data is being used (and understanding the underlying logic), the output is not particularly meaningful.

[mattmatteh]

is that 2 * 3 for the remaining sprite bytes if in range?

i realize that your test were for reverse engineering the ppu, so they would be different from blarggs. i was thinking that they displayed ppu info. how do yours work? if the read nes displayed the reads, then an emulator should display the same reads ? is this the way you determined the sprite evaluation?

thanks

matt

[Quietust]

Yes, 2*3 - two cycles per byte (1 to read, 1 to write).

My test program merely read $2004 at every possible cycle it could during 3 adjacent scanlines (since I couldn't get all of the results from the same scanline) and then just dumped the raw hexadecimal numbers to the screen. I basically took those numbers and cross-referenced them with the expected contents of SPR-RAM to figure out all of those access patterns.

If I can find a copy of the ROM with 'usable' test data, I'll see about posting it. Also, it pretty much goes without saying that you'll need to be performing cycle-accurate PPU emulation (either synchronous or catch-up) in order for this to produce the correct results.

[mattmatteh]

right now it is cycle catch up. i wanted to get it working first, then add optimizations. that way when i add some optimizations i dont loose accuracy.

thanks

matt