Trouble Rendering ATARI-2600 Sprite When Negative HMP0 Values Are Applied

[qcarver]

 

Hello. Per Stella manual, when a byte is stored in the TIA HMP0 register, a fine position adjustment is applied to the coarse beam position. The manual says the value can be anywhere from -8 to 7 (in binary 1000 to 0111). As such the binary is read as twos-compliment.

 

The issue is I am having trouble getting the Sprite to render when any of the negative fine position values are applied (those are: 1000, 1001, 1010, 1011, 1100, 1101, 1110, 1111). In this demo, observe the diagonal lines rendered for Sprite 0 as the result of positive HMOVE shifts by raster line. However, notice also that when the value applied is negative the sprite disappears and there is nothing on that scan line. Also here for comparison and sanity-check I added another Sprite (Sprite 1) which renders as a straight line the length of the screen b/c no fine position is applied.

 

The code of the visible lines loop is as follows:

ScanLoop
    REPEAT 10   ; wait to 
      nop       ;   get beam 
    REPEND      ;       arbitrarily near center
        
    ; All we do here is ++ the hi nibble in the Accumulator
    ; and apply it to HMP0 to adjust the fine position.
    ; QUESTION FOR READER: WHY DOESN'T THE SPRITE RENDER WHEN
    ; THE VALUE EQUATES TO A NEGATIVE VALUE (-8...-1?)

    clc
    adc #%00010000  ; Add (UI) '1' to high nibble in A

    sta HMCLR   ; Due diligence - clear all Motion values
    sta HMP0    ; Set fine P0 Sprite pos to incremented value (*)
    sta RESP0   ;   set coarse position of P0 Sprite
    sta RESP1   ; Set coarse position (only) of P1 Sprite
    sta WSYNC   ; Wait for next scanline
    sta HMOVE   ; Apply fine tweak
    stx COLUBK  ; Set the background color
        
    dex     ; decrement the scanline
    bne ScanLoop
    ;(*)PS: Tried putting HMP0 after RESP's, didn't help

 

The project is for this code is here on teh githubs, and the project on the online Atari emulator 8bitworkshop is here.

 

As I understand, if a solution is provided, then the Sprite on the left will render on every line w/o break with the dot position two's complement bit-pattern.

Edited December 11, 2022 by qcarver
change a value (-7 to -8)

[Thomas Jentzsch]

37 minutes ago, qcarver said:

Per Stella manual, when a byte is stored in the TIA HMP0 register, a fine position adjustment is applied to the coarse beam position. The manual says the value can be anywhere from -8 to 7 (in binary 1000 to 0111)

You misread the manual. The resulting movement can be anything from -8 to +7. The values you need are between $80 and $70 (note the bits which are used here!). 

[+Dave C]

The struggle to grok HMOVE is real.

FWIW I find this table calming to look at (HMOVE value vs what cycle you strobe the register => how much shifting happens)

 http://www.qotile.net/minidig/code/hmove.txt

[qcarver]

6 hours ago, Thomas Jentzsch said:

You misread the manual. The resulting movement can be anything from -8 to +7. The values you need are between $80 and $70 (note the bits which are used here!). 

I mentioned that I am incrementing only the high nibble right? so 0 in the low nibble is implied. For example (-8 -> %1000 0000 -> $80 and also 7 -> %0111 0000 -> $70). I'm not sure that your feedback is helpful. Is there something I missed? Thank you.

Edited December 12, 2022 by qcarver
punctuation

[qcarver]

5 hours ago, Dave C said:

The struggle to grok HMOVE is real.

FWIW I find this table calming to look at (HMOVE value vs what cycle you strobe the register => how much shifting happens)

 http://www.qotile.net/minidig/code/hmove.txt

Thanks for the feedback. Not sure how to read this table really. Does it explain why a negative value in my HMOV inhibits the sprite from being drawn? Thanks

[Thomas Jentzsch]

After seeing your code, I realize that your problem is mainly RESP0 related. You are doing a RESPx for both sprites in each scanline. This usually prevents the first sprite copy from being drawn, IF the sprite changes position.

 

However, in your case, the RESP0 happens close to while the sprite is already being drawn. If the sprite was moved far enough to the left, then the RESP0 happens after the sprite got drawn and you can see the sprite where it should be. If it comes too late, then you cannot see the first copy (in your case there is only one) of the sprite. And then there is a situation, when the sprite does not move between rows. I am not sure why this happens.

 

Anyway, the root cause is, that you use RESP0 in scanlines where you want the sprite to be drawn. This should be avoided.

[glurk]

I'm mostly an 8-bit guy, but my understanding is that when you strobe RESP0, it draws the sprite IMMEDIATELY, wherever the electron beam is at that time.  So it can't possibly draw it offset to the left, because the beam is moving ever-rightward & downward...

 

But it still can be useful to place a sprite with ~15px accuracy with a loosely timed RESP0, or with ~3px accuracy with a precisely timed one (in certain circumstances).

 

And I don't know how/if the HMP0 values affect that, maybe rightward offsets do work (?!)

[Thomas Jentzsch]

10 minutes ago, glurk said:

I'm mostly an 8-bit guy, but my understanding is that when you strobe RESP0, it draws the sprite IMMEDIATELY, wherever the electron beam is at that time. 

This not correct. The sprite gets positioned at the spot of the electron beam immediately, but it is not drawn immediately. The first copy is skipped.

10 minutes ago, glurk said:

So it can't possibly draw it offset to the left, because the beam is moving ever-rightward & downward...

The offset results from the the HMOVE at the beginning of the scanline.

10 minutes ago, glurk said:

But it still can be useful to place a sprite with ~15px accuracy with a loosely timed RESP0, or with ~3px accuracy with a precisely timed one (in certain circumstances).

Correct.

10 minutes ago, glurk said:

And I don't know how/if the HMP0 values affect that, maybe rightward offsets do work (?!)

Yes, up to 7 pixel to the left and 8 pixels to the right.

[Ecernosoft]

On 12/11/2022 at 12:53 PM, qcarver said:

 

Hello. Per Stella manual, when a byte is stored in the TIA HMP0 register, a fine position adjustment is applied to the coarse beam position. The manual says the value can be anywhere from -8 to 7 (in binary 1000 to 0111). As such the binary is read as twos-compliment.

 

The issue is I am having trouble getting the Sprite to render when any of the negative fine position values are applied (those are: 1000, 1001, 1010, 1011, 1100, 1101, 1110, 1111). In this demo, observe the diagonal lines rendered for Sprite 0 as the result of positive HMOVE shifts by raster line. However, notice also that when the value applied is negative the sprite disappears and there is nothing on that scan line. Also here for comparison and sanity-check I added another Sprite (Sprite 1) which renders as a straight line the length of the screen b/c no fine position is applied.

 

The code of the visible lines loop is as follows:

ScanLoop
    REPEAT 10   ; wait to 
      nop       ;   get beam 
    REPEND      ;       arbitrarily near center
        
    ; All we do here is ++ the hi nibble in the Accumulator
    ; and apply it to HMP0 to adjust the fine position.
    ; QUESTION FOR READER: WHY DOESN'T THE SPRITE RENDER WHEN
    ; THE VALUE EQUATES TO A NEGATIVE VALUE (-8...-1?)

    clc
    adc #%00010000  ; Add (UI) '1' to high nibble in A

    sta HMCLR   ; Due diligence - clear all Motion values
    sta HMP0    ; Set fine P0 Sprite pos to incremented value (*)
    sta RESP0   ;   set coarse position of P0 Sprite
    sta RESP1   ; Set coarse position (only) of P1 Sprite
    sta WSYNC   ; Wait for next scanline
    sta HMOVE   ; Apply fine tweak
    stx COLUBK  ; Set the background color
        
    dex     ; decrement the scanline
    bne ScanLoop
    ;(*)PS: Tried putting HMP0 after RESP's, didn't help

 

The project is for this code is here on teh githubs, and the project on the online Atari emulator 8bitworkshop is here.

 

As I understand, if a solution is provided, then the Sprite on the left will render on every line w/o break with the dot position two's complement bit-pattern.

Finally! Someone else who uses 8bitworkshop.

 

please remember that in 8bitworkshop that sound is broken on 2600. Remember if you want sound to test it on another emulator.

just a reminder.