Pantomchap Posted November 6, 2017 Share Posted November 6, 2017 (edited) 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 Quote Link to comment Share on other sites More sharing options...
enthusi Posted November 6, 2017 Share Posted November 6, 2017 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. Quote Link to comment Share on other sites More sharing options...
Kiwi Posted November 7, 2017 Share Posted November 7, 2017 Do WSYNC to start a new line, then waste cycles(Do a loop) until you hit RESP0Then 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 Quote Link to comment Share on other sites More sharing options...
Xenomech Posted January 12, 2018 Share Posted January 12, 2018 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 resetregister (RESP0, RESP1, RESM0, RESM1, RESBL) which are all “strobe”registers (they trigger their function as soon as they are addressed). Thatcauses the object to be positioned wherever the electron bean was in itssweep across the screen when the register was reset. for example, if theelectron beam was 60 color clocks into a scan line when RESP0 was writtento, 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 datain the GP0 register, but if it were drawn, it would show up at 60. Resets tothese registers anywhere during horizontal blanking will position objects atthe left edge of the screen (color clock 0). Since there are 3 color clocks permachine 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 clockintervals across the screen. This “course” positioning is “fine tuned” by theHorizontal Motion, explained in section 8.0. Missiles have an additional positioning command. Writing a “1” to D1 ofthe reset missile-to-player register (RESMP0, RESMP1) disables thatmissiles’ graphics (turns it off) and repositions it horizontally to the centerof 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 befired again. 8.0 Horizontal Motion Horizontal motion allows the programmer to move any of the 5 graphicsobjects relative to their current horizontal position. Each object has a 4 bithorizontal motion register (HMP0, HMP1, HMM0, HMM1, HMBL) that canbe loaded with a value in the range of +7 to -8 (negative values areexpressed in two’s complement from). This motion is not executed until theHMOVE register is written to, at which time all motion registers move theirrespective objects. Objects can be moved repeatedly by simply executingHMOVE. Any object that is not to move must have a 0 in its motionregister. With the horizontal positioning command confined to positioningobjects at 15 color clock intervals, the motion registers fills in the gaps bymoving objects +7 to -8 color clocks. Objects can not be placed at any colorclock position across the screen. All 5 motion registers can be set to zerosimultaneously by writing to the horizontal motion clear register (HMCLR).There are timing constraints for the HMOVE command. The HMOVEcommand must immediately follow a WSYNC (Wait for SYNC) to insure theHMOVE operation occurs during horizontal blanking. This is to allowsufficient time for the motion registers to do their thing before the electronbeam starts drawing the next scan line. Also, for mysterious internalhardware 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). Quote Link to comment Share on other sites More sharing options...
vidak Posted January 21, 2018 Share Posted January 21, 2018 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! Quote Link to comment Share on other sites More sharing options...
StinkerB06 Posted March 18, 2018 Share Posted March 18, 2018 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. Quote Link to comment Share on other sites More sharing options...
DasHeiligeDönerhuhn Posted August 9, 2023 Share Posted August 9, 2023 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? Quote Link to comment Share on other sites More sharing options...
SeaGtGruff Posted August 9, 2023 Share Posted August 9, 2023 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. Quote Link to comment Share on other sites More sharing options...
DasHeiligeDönerhuhn Posted August 10, 2023 Share Posted August 10, 2023 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? Quote Link to comment Share on other sites More sharing options...
alex_79 Posted August 11, 2023 Share Posted August 11, 2023 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). Quote Link to comment Share on other sites More sharing options...
DasHeiligeDönerhuhn Posted August 11, 2023 Share Posted August 11, 2023 HBLANK doesn't exist for that screenwrap? Quote Link to comment Share on other sites More sharing options...
alex_79 Posted August 11, 2023 Share Posted August 11, 2023 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. Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.