REALLY dumb question. How do I move sprites horizontally?

[Pantomchap]

I'm back here after some months. I have a very basic understanding of the 2600 and I've made a few demo thingies with sprites that can move up and down but I never found out how to move sprites horizontally. What do I use?

 

Thanks.

Edited November 6, 2017 by Pantomchap

[enthusi]

You can (re)set the sprites to the current position of the clock within a rasterline via register. 'Just' make sure you count the cycles well. You finetune this with another register. There are very nice examples out there how to properly time this for a dynamical positioning.

[Kiwi]

Do WSYNC to start a new line, then waste cycles(Do a loop) until you hit RESP0
Then enter a number to HMP0 for fine position your sprite. Then do a WSYNC, then HMOVE to apply the movement.

There's a subroutine that help you with that.

SetHorizPos
	sta WSYNC	; start a new line
        bit 0		; waste 3 cycles
	sec		; set carry flag
DivideLoop
	sbc #15		; subtract 15
	bcs DivideLoop	; branch until negative
	eor #7		; calculate fine offset
	asl
	asl
	asl
	asl
	sta RESP0,x	; fix coarse position
	sta HMP0,x	; set fine offset
	rts		; return to caller

register x is for what object(0-4) you want to position, example, 0 is for player0, 4 is for ball. Then 'a' for your object's x position.

example:

 	lda CutterM1X
	ldx #3
	jsr SetHorizPos
	sta WSYNC
	sta HMOVE
	sleep 22

[Xenomech]

When it comes to programming for the Atari 2600, I think it's safe to say that there definitely are no dumb questions -- even the simplest thing can be extremely difficult to figure out.

 

 

Just for reference, here's a quote from the Stella Programmer's Guide:

 

7.0 Horizontal Positioning

The horizontal position of each object is set by writing to its’ associated reset
register (RESP0, RESP1, RESM0, RESM1, RESBL) which are all “strobe”
registers (they trigger their function as soon as they are addressed). That
causes the object to be positioned wherever the electron bean was in its
sweep across the screen when the register was reset. for example, if the
electron beam was 60 color clocks into a scan line when RESP0 was written
to, player 0 would be positioned 60 color clocks "in” on the next scan line.
Whether or not P0 is actually drawn on the screen is a function of the data
in the GP0 register, but if it were drawn, it would show up at 60. Resets to
these registers anywhere during horizontal blanking will position objects at
the left edge of the screen (color clock 0). Since there are 3 color clocks per
machine cycle, and it can take up to 5 machine cycles to write the register,
the programmer is confined to positioning the objects at 15 color clock
intervals across the screen. This “course” positioning is “fine tuned” by the
Horizontal Motion, explained in section 8.0.

Missiles have an additional positioning command. Writing a “1” to D1 of
the reset missile-to-player register (RESMP0, RESMP1) disables that
missiles’ graphics (turns it off) and repositions it horizontally to the center
of its’ associated player. Until a “0” is written to the register, the missiles’
horizontal position is locked to the center of its’ player in preparation to be
fired again.

8.0 Horizontal Motion

Horizontal motion allows the programmer to move any of the 5 graphics
objects relative to their current horizontal position. Each object has a 4 bit
horizontal motion register (HMP0, HMP1, HMM0, HMM1, HMBL) that can
be loaded with a value in the range of +7 to -8 (negative values are
expressed in two’s complement from). This motion is not executed until the
HMOVE register is written to, at which time all motion registers move their
respective objects. Objects can be moved repeatedly by simply executing
HMOVE. Any object that is not to move must have a 0 in its motion
register. With the horizontal positioning command confined to positioning
objects at 15 color clock intervals, the motion registers fills in the gaps by
moving objects +7 to -8 color clocks. Objects can not be placed at any color
clock position across the screen. All 5 motion registers can be set to zero
simultaneously by writing to the horizontal motion clear register (HMCLR).

There are timing constraints for the HMOVE command. The HMOVE
command must immediately follow a WSYNC (Wait for SYNC) to insure the
HMOVE operation occurs during horizontal blanking. This is to allow
sufficient time for the motion registers to do their thing before the electron
beam starts drawing the next scan line. Also, for mysterious internal
hardware considerations, the motion registers should not be modified for at

least 24 machine cycles after an HMOVE command.

 

 

Really, the simplest and most straight-forward way to implement horizontal movement is to implement the SetHorizPos subroutine that Kiwi mentioned above. Lots of people use that subroutine (or a variation thereof).

[vidak]

You should check out SpiceWare's Collect Tutorial HERE.

 

The routine listed has a few variations - you can also fiddle with it.

 

From my understanding, RESPX needs to be set at cycle 23.

 

The way HMOVE works on the Atari 2600 is that it will automatically draw the Player Graphics at whatever horizontal location you set it.

 

So after you do a HMOVE, and when you finally draw GRP0 or GRP1 at the right VERTICAL position, the 2600 will be waiting for you to STA GRP0 and will automatically draw GRP0 at the right horizontal position.

It's a little bit like magic!

[StinkerB06]

The TIA chip has 4-bit adaptive-differential registers for oddball horizontal movement of the sprites, missiles, and ball. That means you can only move to the right up to 8 pixel clocks, or to the left up to 7 pixel clocks.

[DasHeiligeDönerhuhn]

If I were to move a sprite 7 clock ticks to the right on one scanline and then call HMOVE with the same HMxx register configuration, would it move the sprite another 7 pixels to the right? and how long can I chain that if possible?

[SeaGtGruff]

Yes, it would keep moving the sprite by the same amount unless you set the movement register to a different value. You can keep moving the sprite forever that way, as long as you keep strobing HMOVE. So if you want to move the sprite, say, 70 pixels to the right, you can strobe HMOVE for 10 lines, then stop.

[DasHeiligeDönerhuhn]

What happens if I move it off the screen?

And also, negative values move it to the left and positive ones to the right, right?

[alex_79]

On 8/10/2023 at 11:28 AM, DasHeiligeDönerhuhn said:

What happens if I move it off the screen?

It wraps around.  There's not "off the screen" position.

On 8/10/2023 at 11:28 AM, DasHeiligeDönerhuhn said:

And also, negative values move it to the left and positive ones to the right, right?

No, check the "Stella Programmer's Guide" for the HMxx values.

If you strobe HMOVE as intended at the beginning of the line, and you consider only the high nybble stored into HMxx register as a signed value (-8 to +7), then negative values move to the right and positive to the left. If you use an "early HMOVE" (that is, you strobe it on cycle 73 or 74 of the previous scanline), the movement is always to the left. You need to invert bit 7 in this case to have a corrispondece between the high nybble of HMxx and the number of pixels of the movement (0 to 15).

[DasHeiligeDönerhuhn]

HBLANK doesn't exist for that screenwrap?

[alex_79]

2 hours ago, DasHeiligeDönerhuhn said:

HBLANK doesn't exist for that screenwrap?

No. The sprites are always only in the 160 pixels "visible" area of the scanline.