The HMOVE Shuffle

[+Karl G]

A couple of questions regarding HMOVE:

 

• The Stella Programmer's Guide says not to alter any motion registers for 24 cycles after a HMOVE. Is this number correct? I'm just wondering if people have done experiments to see if the actual number differs at all from what's in this venerable document.
• If you don't alter the motion registers at all, I assume there does not need to be a delay to perform another HMOVE right after one completes?

 

[+Karl G]

From my experimentation, it doesn't look like a HMOVE right after another one works as expected. I suppose the 24 cycle prohibition also applies to using HNOVE in general, and not just to using the HM* registers?

[Thomas Jentzsch]

Yes, HMOVE does only work around the end and beginning of a scanline. 

 

https://www.biglist.com/lists/stella/archives/199804/msg00198.html

[+Karl G]

1 hour ago, Thomas Jentzsch said:

Yes, HMOVE does only work around the end and beginning of a scanline. 

 

https://www.biglist.com/lists/stella/archives/199804/msg00198.html

That's the table I was using. I thought having $80 in the HM* registers, and hitting HMOVE e.g. at cycle 75 and again at cycle 2 would move the objects 16 color clocks to the right, but it didn't seem to work that way in practice. It's not really a problem; I've already adjusted my code to do the positioning the "traditional" way.

[Thomas Jentzsch]

AFAIK you can only move +/-8 pixel scanline no matter what you do.

[+Karl G]

41 minutes ago, Thomas Jentzsch said:

AFAIK you can only move +/-8 pixel scanline no matter what you do.

Now I'm confused. The +/-8 pixels should be per HMOVE, right? Like for kernels that hit HMOVE every scanline, it keeps moving in that increment every time. I was just hoping that I could do a second HMOVE right after the first one, e.g.:

 

    lda #$80                            ; 2     (66)
    sta HMP0                            ; 3     (69)
    sta HMP1                            ; 3     (72)
    sta HMOVE                           ; 3     (75)
    sta HMOVE                           ; 3     (2)

I would have thought that this would have moved the players 16 clocks to the right 8 clocks at a time with each HMOVE, but it didn't seem to work that way in practice.

[Thomas Jentzsch]

 

6 minutes ago, Karl G said:

The +/-8 pixels should be per HMOVE, right?

No, this is per scanline.

[+Karl G]

6 minutes ago, Thomas Jentzsch said:

 

No, this is per scanline.

Aha! Okay: now that makes a lot more sense. Thank you. 

[alex_79]

To get an idea on why there's such a limitation, here is a (oversimplified and not accurate ?) description of how TIA handles sprite positioning:

 

Each sprite has its own position counter, which runs only during the visible part of the scanline (for 160 TIA cycles, from 68 to 228), while it's "paused" during HBlank (TIA cycles 0 to 67).

When the counter wraps around, the corresponding sprite is drawn, and the counter takes exactly 160 TIA clocks to wrap around, so the sprite normally appears in the same position on every scanline.

 

Strobing RESxx immediately resets the position counter, making the current position the "new" one for the sprite from now on.

HMOVE is different, as it doesn't change the position counter immediately to a new value, but instead sends extra clock pulses (up to 15 of them) to the counter, one every 4 TIA cycles (or 1.33 CPU cycles). The problem is that if those extra pulses occur in the visible part of the scanline, the interaction with the "normal" pulses to the position counter produces unpredictable results, which differ between different consoles, and even on the same console (e.g. depending on temperature).

The only way to have reliable results is to send those extra pulses when the "normal" ones are not occurring, that is during the Horizontal Blank.

This is why you can't move more pixels per scanline: there's no time to reliably feed more pulses to the counters.

 

This is also the reason for the HMOVE timing limitation: only strobing the register at CPU cycle 73 to 3 ensures that you have enough time during HBLANK for all the possible 15 pulses to the position counters. HMOVE strobes that occurs later than cycle 3, but still in HBLANK can only be used for certain HMxx values, corresponding to fewer pulses, but that's not very useful in practice (To know how many pulses correspond to a HMxx value, invert bit 7 and take the high nybble. E.g. a HMxx value of "$70" produces 15 pulses, while "$80" results in no pulses).

 

Finally, that's where the "do not mess with the position registers for 24 cycles after HMOVE" in the Stella guide comes from: you should ensure that HMOVE operations are completed before altering the registers, else you won't get the intended results.

 

 

Edited April 14, 2021 by alex_79