Super Cars / $2004 reads

[blargg]

This is loop is 10 clocks, also a multiple of 5:

Code: Select all

loop:   bit 0     ; 3
        cmp $2004 ; 4
        bne loop  ; 3

[lft]

This is loop is 10 clocks, also a multiple of 5:

Code: Select all

loop:   bit 0     ; 3
        cmp $2004 ; 4
        bne loop  ; 3

That's true, but it takes 10 cycles between every read, so it will require more sprites in order to guarantee a hit, compared to my loop. But we'd have to draw a timing diagram for the PAL case to find out if it crosses the 8-sprite limit or not, and that means work...

[Disch]

I don't see why having there be an integer number of dots between polls is benefitial. It doesn't matter that 3.2 isn't an even number -- it's still best to have the smallest gap between polls. That gives you the best chance of hitting a window of any size.

The only number that would be bad is a multiple of 8 (in which case if you miss one sprite, you'll miss all of them because you'll hit each sprite at the same point). Since 22.4 (3.2 * 7) is not divisible by 8, I don't see a problem.

Because the PAL CPU is slower, you'll probably need at least 1 more sprite to get steady results. Then again blargg is apparently getting steady results with only 3 sprites when I calculated you'd need 5 sprites -- so perhaps I'm being overly cautious.

I'm quite sure that even in a worst case scenario, though, using all 8 sprites and the normal 7 CPU cycle loop will work just fine even on PAL.

[blargg]

Then again blargg is apparently getting steady results with only 3 sprites when I calculated you'd need 5 sprites -- so perhaps I'm being overly cautious.

Three sprites at the end pass for all cases. This is at the end of evaluation. The --##- line shows which bytes are the key (#) and not (-). The R line shows when the $2004 reads occur. Slide it around and one always falls on a #.

Code: Select all

   v-----evaluation-------vv------rendering-------v
...YYTTAAXXYYTTAAXXYYTTAAXXYTAXXXXXYTAXXXXXYTAXXXXXYFFFFFFFYFFFFFFFYF...
...--######--######--######-#######-#######-#######------------------...
 R                    R                    R

[Disch]

Rendering doesn't occur immediately after evalutaion of those sprites, though. Especially not if only 3 sprites on the line are found. There'd be a gap between when sprite 63 is evaluated and when the first in-range data is fetched.

Though I'm sure it still syncs up in a similar fashion.

[Bregalad]

What you all says applies with the marker byte on X Pos + Attribute + Tile #, or with it only on Tile # ?