Subject: Re: [stella] MultiSpriteDemo update (source+binary)|
From: emooney@xxxxxxxxxxxxxxxx (Erik Mooney)
Date: Sat, 05 Apr 1997 23:34:47 GMT
>It's tricky, but I think I've figured it out. First, it makes the X-coord >zero if it's out of range (not between zero and 159.) Then, it takes the >fine and coarse values in base-16 of the number (which are simply the high >and low nibbles). To convert base-16 FC to base-15 FC, you add the F and C >values and put that in F; if that's >15, you subtract 15 from F and add one >to C. (Trust me, this works mathematically, though it's difficult to >explain.) The rest of the code cleans up and puts the F and C values >together into one register. I substituted this routine in place of my old FC-convert routines (of the old-fashioned repeatedly-subtract-15 variety), and it worked fine.. except that the new routine displayed the object nine pixels farther left than my old routine. Simply delaying an extra three cycles when positioning before hitting RESP0 worked, though. To position using this routine: load the coarse value into Y, wait 19 cycles after WSYNC, do a DEY/BNE loop, and then hit RESP0. Then, write the fine value to HMP0 and HMOVE it. This doesn't look like it'd work, though - the 19 cycle delay plus 2 for DEY plus 2 for BNE plus 3 for STA RESP0 lands at cycle 26, which is pixel 78, or the tenth pixel from the left edge of the screen. HMP0 can move this at most seven pixels further left, to pixel 3... yet the routine correctly displayed an object in the leftmost column of the screen when I fed 0 to the FC-convert routine. I suspect that even though STA RESP0 takes three cycles, the write hits Stella at the end of the second cycle and it responds accordingly. I'll experiment further tonight. -- Archives available at http://www.biglist.com/lists/stella/archives/ E-mail UNSUBSCRIBE in the body to stella-request@xxxxxxxxxxx to be removed.