TheDickChuck

Thanks for the input fellas. I still need a little clearing up... let me see if I have this much straight: - If I use HMOVE immediately after WSYNC I can expect the black bars to appear. I even see the bars if the HMOVE is pretty close to the scan line start but not right after WSYNC; but unpredictably if I recall. In that case, the move will take place on THAT SAME LINE. - If I use the HMOVE on cycle 70 or 71 of the previous line, then no bars - and all of the shifting will be to the left side- but the effect will show up on the following line. Still unsure about the fact that I have used HMOVE before at times like ~50ish cycles, and I still don't see black bars. And the HMPx registers still have some sort of effects (sometimes?). Is the point that using it at any other time than immediately AFTER wsync or on cycle 70 gives unpredictable (from case to case) results? Are those the only two options one should use? Also, I thought HMOVE was a relative and recursive movement - meaning that if I use HMOVE to offset +1 over and over, then I would expect to see the sprite move. I don't see that, and I don't want to - it stays off of the "natural" position +1. I don't ever call HMCLR either. Is it because my HMOVE always comes right before a new RESPx setting? I haven't had a chance to study your demo yet SpiceWare. Thank you, thank you, thank you.

First, thanks to everyone on the forum - you guys are rockin' the helpful. Hopefully someday soon I can start to help some of you out in return. I thought I understood HMOVE but not so. First, in an effort to avoid the black side bars - I timed the HMOVE to occur on either cycle 73 or 74 as suggested by various sources. I found that didn't work too well. I thought I had licked the problem by simply having the HMOVE occur several lines ahead of when I needed it but well after WSYNC (having this luxury in my design). That seemed to fix it, but no - after moding the code - the blank lines reappear, even though HMOVE is at least a full scan line separated from the sprites. So in the course of exploring, I have codified these questions: - do the HMPx reset automatically after each frame? I was not zeroing them with HMCLR and yet I see no motion despite having an HMPx / HMOVE offset on some sprites. I know the offset is working, because when I take it out, the sprites shift back to the 'regular' positions set by RESPx. I am not resetting the HMPx to zero after/before each frame. - does setting position with RESPx nullify any HMOVE changes, or will newly reset positions still be displayed offset by the same HMPx parameters? - this is another way of asking the same thing; for a given combo of RESPx and HMPx/HMOVE does the order in which the two are applied affect the final position? Let me describe one situation. I was setting my position with RESPx after first setting HMPx to 0 followed by HMOVE. Then, I would try to tweak position using mods to the HMPx line. I would find things like setting 0001 to nudge once to the left would do nothing. Then I tried 0010. nothing. Then I stepped by one to the maximum left shift of 0111 (I only needed to shift one pixel left) and finally the shift kicks in at TWO pixels - not 7. Next I chose a different RESPx position (HMPx = 0) - by inserting a couple of NOPs - then when I start to left shift, the behaviour is normal: 0001 shifts one, 0010 shifts two, etc. I so confused! Obviously I am missing something fundamental. Any input would be very appreciated!!!

Wow thanks for the input. Saw your response to my other thread as well. I had already given up the no-flicker dream. I went ahead and set up two flicker states one with two P0 sprites spaced wide and offset from a pair of two wide P1 sprites. This seems to give enough time to make the GRPx and COLUPx changes for each of those four images and also some playfield asymetry things I need to add now. The second flicker is the same setup - shifted and with the second P1 image zeroed to give me my seven. Looks like... I'll check out your code - it is undoubtedly better than what I have. And thanks again. BTW, is there a way in Stella (emulator) to take a blended snapshot across a timewindow?

Hi, I've seen others' code examples that are utilizing this line. This address seems to be in the zero page area, just after the established registers but before the normal $80 user RAM start. Could someone clarify? - this one threw my Atari world-view out of whack a bit. Is it just a cycle-waster? -DC

Thanks for reply Omegamatrix - yes 8 pixels between sprites is correct. I had been reading a review that reporting spacing based on the 1st pixel - to - 1st pixel difference; my brain was stuck in that place when I wrote this. I did think about a ball/missile construction effort. Seemed overwhelmingly complex - but I guess it would just take a second definition of each sprite: one with three numbers per line that specify the offset (or off) for the ball/m0/m1 from the start position. Have you tried that technique before? Seems like some sprites' scans might be complex enough to require repeated use of one or more of the objects - was thinking that that would be too time sensitive to pull off. I am going to re-examine my images and see if it seems doable. Also, by covering up the copies - is that to say that multiple player sprites invoke multiple missiles as well? I didn't realize that. Honestly, I was about to give up and commit Atari suicide from frustration getting ANY of the RESPx tricks to display - then I realized that for some reason my z26 emulator doesn't seem to display them; Stella does. Does that sound right to you? I was thinking there might be some command line switch to control this, but didn't see anything in the docs I have. One last question - I'm new enough to not know what +DPC is...? Thanks.

Thanks in advance - another victim of the 2600 bug here. I'm addicted. I'm trying to create a logic puzzle game on a 7 by X grid. The pieces are STATIC. I need to display a row of 7 sprites, each separated from the others by 16 pixels, but with changing GRPx graphics and any combo of two COLUPx colors choices for each. Obviously, I get real close to this using interlaced sprite0 and sprite1 set to triple display (medium spacing), and timing the graphics and color changes. But I need to lead off with an extra copy - or end with an extra. I've thought about using immediate spacing with 13/14 sprites and just blanking out every other one - but I don't think I can change the color and graphics fast enough with that. I've looked at a lot of the RESPx code out there - I must confess I don't quite get it yet. I am pretty familiar with the 4/3 cycle differences of the display; I get the delay of presentation until the following scanline; I sort-of get the v-delay trick. I lot of that seems overkill for me though, and most examples are about cramming as many sprites as possible into a line. Anyway - this is sort of what I'd like to produce. The graphics are actually more detailed, I just haven't got them yet - 8 bit detail. Of course, avoiding flicker would be the goal: These lines are 4 pixels (out of 160) wide. Any pointers (pardon the pun) would be much appreciated!