Another emulator

[DirtyHairy]

Your reasoning is correct, but the counting is off. According to Andrew Tower's notes (at least the way I interpret them), there is a four color clock delay between RESx and the actual reset of the sprite counter to zero. Simlarly, the draw decode is triggered at a counter value of 156 (I am counting full color clocks, not 1/4 clocks) and takes another four clocks until the drawing starts. This can be modelled by setting the counter to 156 when RESx is hit and counting another four cycles for the decode to happend, effectively leading to an offset of four clocks to the right between the pixel where RESx is hit and the actual sprite position. This is also the way things are modelled in the 6502.ts core.

 

According to this reasoning, you would expect sprites to be placed at the fifth pixel if RESx is strobed during hblank. However, this is not how the TIA behaves. I am not sure how the underlying logic works (you could find out by studying the schematics), but if RESx is strobed during hblank, the delay until the counter is reset is reduced to two clocks. The same holds for the decode that is triggered by RESx for the ball; this is also shortened by two clocks. This accounts for the position you are observing on real hardware (and virtually all mature emulators). There is another special case: if the strobe is the last CPU cycle during an extended hblank (caused by a HMOVE), the delays are only shortened by one clock). I guess that some mechanism advances the logic by two 1/4 clocks and takes two color clocks for that (and thus is cut short after one clock in the last case).

 

This is not covered in ATs notes (or I have been unable to find it), and while this is the way it is modelled in the 6502.ts core, I am by no way sure that this is an accurate description of the unterlying gate level logic. It is just a model that describes the observable behavior. However, the important lesson is that there is no "spec" to which the TIA operates. It was propably designed to meet the description in the Programming Guide (which leaves a lot of loose ends), and AT did an excellent job at uncovering most of the underlying mechanics, but there still are some edge cases where you have to run tests on the original hardware (or peer at the schematics in hope for wisdom ).

Edited April 11, 2017 by DirtyHairy

[ThomH]

Your reasoning is correct, but the counting is off. According to Andrew Tower's notes (at least the way I interpret them), there is a four color clock delay between RESx and the actual reset of the sprite counter to zero. Simlarly, the draw decode is triggered at a counter value of 156 (I am counting full color clocks, not 1/4 clocks) and takes another four clocks until the drawing starts. This can be modelled by setting the counter to 156 when RESx is hit and counting another four cycles for the decode to happend, effectively leading to an offset of four clocks to the right between the pixel where RESx is hit and the actual sprite position. This is also the way things are modelled in the 6502.ts core.

 

According to this reasoning, you would expect sprites to be placed at the fifth pixel if RESx is strobed during hblank. However, this is not how the TIA behaves. I am not sure how the underlying logic works (you could find out by studying the schematics), but if RESx is strobed during hblank, the delay until the counter is reset is reduced to two clocks. The same holds for the decode that is triggered by RESx for the ball; this is also shortened by two clocks. This accounts for the position you are observing on real hardware (and virtually all mature emulators). There is another special case: if the strobe is the last CPU cycle during an extended hblank (caused by a HMOVE), the delays are only shortened by one clock). I guess that some mechanism advances the logic by two 1/4 clocks and takes two color clocks for that (and thus is cut short after one clock in the last case).

 

 

Ah, my understanding was that the play field has the same clocking delay. So if you were to hit reset 68 colour cycles after a WSYNC without having issued an HMOVE you'd expect the ball to appear in the second column of the screen, not the fifth (though the CPU will have done another 1.33 cycles of work by then).

 

I have the starts and stops delayed by four cycles (or five for the players), but enabled/player pixel lookups not delayed at all.

 

It's sounding more and more like I may have misread what documentation there is.

 

This is not covered in ATs notes (or I have been unable to find it), and while this is the way it is modelled in the 6502.ts core, I am by no way sure that this is an accurate description of the unterlying gate level logic. It is just a model that describes the observable behavior. However, the important lesson is that there is no "spec" to which the TIA operates. It was propably designed to meet the description in the Programming Guide (which leaves a lot of loose ends), and AT did an excellent job at uncovering most of the underlying mechanics, but there still are some edge cases where you have to run tests on the original hardware (or peer at the schematics in hope for wisdom ).

 

I felt it strongly implied the opposite with "therefore we can say that player grahpics are delayed by 1 CLK (this is why the leftmost possible start position for a RESP0 is pixel 1, not pixel 0. You can HMOVE the player further left though, if necessary.)"; how could you use RESP0 to place a player in pixel 1 if you weren't issuing it in the blank area? If there's no flaw in my logic, I accept that reading too much into a throwaway statement would also be a potential hazard.

 

Also, option three for determining edge-case behaviour: ask an altruistic member of an internet forum. Thanks for everything you've helped with already!

[DirtyHairy]

To be honest: the lines you quote are the only part of ATs notes that I did not manage to make any sense of whatsoever I agree that the model I described differs, but it matches real hardware, and there may be a way that I didn't see to recast this into a form that lines up with ATs notes by redistributing delays.