8 pixel back-n-forth sprite shift

[+rbairos]

Hello, doing some work shifting sprite back and forth each line, 
but am I correct in thinking the maximum back-n-forth shift is 7 pixels?

That is, I do quite a bit of rendering throughout the line, and near the end I need to shift things forward or backward 8 pixels for the next line.
I realize HMP0,1 only allow +8 through -7,  so am I out of luck?

Thanks,
Rob.
 

[DirtyHairy]

You need to do a late HMOVE: if you strobe HMOVE at the correct cycle at the end of the line, all extra cycles sent by the TIA will fall into HBLANK (causing a reliable movement to the left) but the latch that triggers the extended HBLANK will be reset --- this gives you between 0 and 15 clocks of movement to the left. From the top of my head, doing a "STA HMOVE" during cycle 71 or 72 should work fine. The left shift achieved this way is determined by the high nibble of HMx with the highest bit inverted --- i.e. HMP0 = $00 will give you 8 pixels movement to the left, and HMP0 = $70 will give you 15 pixels movement to the left.

Edited September 2, 2019 by DirtyHairy

[+rbairos]

Okay amazing tip.  I need to review my kernel to see if I can fit this in.

[+rbairos]

So cycle 71 (HMPx == 0) does the trick to shift back 8 pixels.

Funnily enough, if its at 72,  the counter does tick left 8 pixels, but then shifts back to original position.
 

[DirtyHairy]

I wonder... I think this is a one-off error  My counting starts with cycle 1, but maybe your counting starts with cycle 0. If you are one cycle too late, the extended hmove latch will not be cleared, and you end up with an ordinary HMOVE --- you get eight pulses together with eight pixels movement to the right from the extended hblank, which amounts to zero pixels movement.

 

If you strobe HMOVE too early, you will get extra pulses during the visible part of the scanline where they either coincide with or fill the gap between regular pulses, depending on the generation of the TIA. This is the main reason for the differences between different console generations.

[+rbairos]

I'll have to verify, but was using stella to note the cycle clock.
But in the case where it does work (72, or 71 base 0), should I expect it to work on most systems then?
Aiming for heavy-sixer, and FB2 mod.

Thanks,
Rob.
 

[DirtyHairy]

Stella starts counting with cycle 0. It seems that using the earlier cycle (71 if you start counting with 1) is unstable on some Jr. machines: 

Afaik, using the latest possible cycle (72) should be fine. While this trick is not part of the standard repertoire of VCS development, it is not that exotic either; there are many ROMs out there that use it. In particular, it is required to create a 96 pixel flickerblinds bitmap.

[+SpiceWare]

When using HMOVE this way I use cycle 73 or 74 based on research by Bradford Mott. If hit on cycle 72 the movement would only be -7.

[DirtyHairy]

28 minutes ago, SpiceWare said:

When using HMOVE this way I use cycle 73 or 74 based on research by Bradford Mott. If hit on cycle 72 the movement would only be -7.

I am talking about the cycle where STA HMOVE starts, not about the actual access, that‘s the reason for the discrepancy ?

[+rbairos]

So I got a kernel working with this method.
Works on stella emulator, light sixer, even the Flashback 2.
I should be able to try out Colecovision adapter soonish.