>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.
