Question/problem about sprite positioning during HBLANK

[Paulo Peccin]

Hey guys,

 

I'm having some problems with correct object positioning in Javatari.

The strange behavior occur when RESxx (RESM1 for instance) is hit during HBLANK. I'm talking about the simplest possible case. No RESxx during HMOVE, no re-triggering, no tricks.

 

For all I know and read about it, if you hit RESxx during HBLANK, well before its end, the objects position counter will be reset to 0 (zero) and the object should be drawn at the leftmost position (pixel 0 for M0, M1 and Ball and pixel 1 for P0 and P1), beginning at the next line (except for Ball that should start in the same line).

 

Isn't that right?

 

But what I get in some games is something different. Lets take Pitfall2 for example. The game uses M1 to hide the HMOVE "comb effect".

It hits RESM1 way before the end of HBLANK, and I would expect M1 to be positioned at pixel 0. But then, AFTER it hits M1, it sets an HMOVE in the next line and moves M1 3 pixels to the left. This suggests the RESM1 would position the object at pixel 3, and then it needs to be moved 3 pixels left to be at the desire position (pixel 0)

 

Enduro, for instance, does a similar thing with the Ball, but after hitting RESBL during HBLANK, it moves the object only 2 pixels left instead of 3.

 

Does someone know what is happening? Is there anything that causes a delay in the counter reset mechanism during HBLANK?

I was expecting this behavior to be more "deterministic", but I don't see a general rule that could work for the 2 examples above.

If I "tune" the emulator to make one game work, the other does not...

 

Can someone experienced in 2600 programming help?

 

Thanks,

Peccin

[SeaGtGruff]

Strobing RESxx during HBLANK doesn't set a sprite's position to pixel 0, it sets it to pixel 2 for the missiles and the ball, and to pixel 3 for the players. The "Stella Programmer's Guide" does say that

Resets to these registers anywhere during horizontal blanking will position objects at the left edge of the screen (color clock 0).

However, that is erroneous.

 

If you want a technical explanation, remember that 1 machine cycle equals 3 color clocks, so depending on which machine cycle you strobe a RESxx register on, the best you can do is position a sprite at some interval of 3 color clocks-- that is, if you strobe it at cycle X and the sprite is positioned at clock Y, then strobing it at cycle X+1 will position the sprite at clock Y+3.

 

Furthermore, the horizontal events (for lack of a better term) are timed by the "horizontal clocks," which run at 4 times the color clock rate; and due to the way the latches of the LFSR counters are driven by the horizontal clock 1 and horizontal clock 2 signals, triggering some event doesn't cause that event to occur until 4 clocks later. So if you strobe a RESxx register at machine cycle X-- which corresponds to color clock 3X-- the sprite's new position becomes 3X+4. For the players, the new position will actually be 3X+5, because they require an extra color clock before the TIA starts to draw them.

 

So suppose you strobe RESM1 at machine cycle 23, which corresponds to color clock 69 (23 times 3). Missile 1 will be positioned at color clock 73 (69 plus 4), or pixel 5 (73 minus 68). If you strobe RESM1 a cycle earlier than that-- i.e., at cycle 22-- missile 1 will be at pixel 2 (5 minus 3). Strobing RESM1 at any other time during HBLANK has the same effect as strobing it at cycle 22-- missile 1 will be at pixel 2. The players will be 1 pixel to the right, or at pixel 3.

 

Edit:

 

I checked the Pitfall II code, and it strobes RESM1 right after strobing HMOVE:

 

STA WSYNC

STA HMOVE

STA RESM1

 

When I tried that, it did position missile 1 at pixel 3 rather than at pixel 2. If I don't strobe HMOVE (i.e., STA WSYNC then STA RESM1), missile 1 is positioned at pixel 2 as expected. So strobing RESM1 right after HMOVE changes the positioning slightly.

Edited January 11, 2013 by SeaGtGruff

[Paulo Peccin]

Thank you for answering.

 

Yes, I know all that. Javatari already works and positions the sprites correctly for the great great majority of the games.

 

You said that if you hit RESM1, for example, during HBLANK it will be positioned at pixel 2. Yes, that is what I knew and had tuned the emulator for.

However, as I mentioned in the OP, Pitfall2 does not work that way, It hits RESM1 during VBLANK and then it moves M1 3 pixels left, but it ends positioned at pixel 0. So the RESM1 hit during VBLANK in this case positioned M1 at pixel 3 instead of 2!

Do you know an explanation for that?

 

Thanks,

Peccin

[Paulo Peccin]

Oh, I see you have edited your answer.

Yes, that is what I was thinking too... If you hit RESxx after an HMOVE it delays the position 1 clock further... But is that the general rule? How close to HMOVE the hit to RESxx must occur to show this behavior? Anywhere after HMOVE?

 

The most detailed explanation I ever found to objects horizontal positioning is this: http://www.atarihq.c...IA_HW_Notes.txt

 

According to this, every time you hit RESxx it takes 4 pixel clocks for the object counter to get reset. Even for player objects. The exception is that player objects delay 1 more pixel to START drawing in every copy, not to really reset the counter. So it gives the +5 pixels for players and +4 pixels for missiles and ball.

 

I don't like the idea of clock-to-position tables. Javatari implements the objects with real counters, scan counters and so, like the real hardware.

 

So, what I don't understand to start with, is just WHY the above rule (4 clocks to reset the counter) does not work that way during HBLANK. If it really worked that way, it should ALWAYS take 4 clocks to reset the counter. So, if you hit RESxx way before the end of HBLANK (lets say at cpu clock 3), this would give much more than enough time for the object counter to get reset to 0, and this would position the sprite at pixel 0, not 2!!!

Don't you agree? :-)

 

Knowing that the observed behavior show that they get positioned at pixel 2, I just cant explain why.

Maybe it has something to do with the "clock stuffing" performed by HMOVE altering the way the counters get reset, but that would not explain why objects get positioned at pixel 2 even when you do NOT hit HMOVE.

 

Any thoughts? :-)

 

Thank you very much,

Peccin

[SeaGtGruff]

I don't know the specifics of why there's a 1-pixel difference, without examining the schematics to see if I can work that part out. But the general advice in the programming guide is not to change the HMxx registers within 24 cycles after strobing HMOVE. However, this isn't changing the HMxx registers, it's strobing a RESxx register after HMOVE, so it isn't exactly the same thing-- but the reason may be related in some way. I suspect that David Crane may have initially used an HMM1 value to move it 2 pixels to the left, then changed it to 3 pixels to the left after seeing that missile 1 was ending up 1 pixel to the right of where he wanted it-- unless he already knew that missile 1 would end up 1 pixel "off" due to the exact sequence in which he was strobing WSYNC, HMOVE, and RESM1 (which is possible, since he undoubtedly knew quite a bit about the TIA at the technical level).

[Paulo Peccin]

Yes, probably developers of games "fine tune" the values used to get the desired result, even when they can't explain exactly why.

You know, that's the real hard part of developing an emulator for a machine like the 2600. You have to discover the rules behind everything, so the emulator will always respond as expected for all possible cases, past and future!

You cannot simple "tune" the behavior until you get what one game or the another expect. There will always be a combination you have not seen happening.

 

 

Thank you for the insights!

 

Anybody reading this know the reasons behind the "RESxx during HBLANK = pixel 2" and "if after HMOVE then +1" rules?

 

Regards,

Peccin

[SeaGtGruff]

I have a TIA spreadsheet I've been working on (off and on)-- simulating the logic gates, latches, etc., with a spreadsheet-- and I'll see if I can simulate strobing the RESxx registers immediately after strobing HMOVE on cycle 3 (i.e., right after strobing WSYNC). It may take a little while, though, so don't hold your breath!