Argh, stupid mailer.. ah well.. here's a resend of that
message that got completely garbled. Direct private replies
to emooney@xxxxxxxxxxxxxxxxxxxxxxx, because that's where I'll
be. (I'm on spring break this week)
>LF805: DEY ;14
> BPL LF805 ;20
> NOP ;2 ;loop totals 36 cycles
>
> STA RESP0 ;P0 at pixel 108?
> STA RESP1 ;P1 at pixel 117?
> LDA #$F0 ;shift P0 one posn to the right (109?)
>;If the TIA only processes RESP0 every 15 pixels as has been stated,
>;then the above numbers would not make sense to me. P0 would end up
>;at 121, and P1 would be 120... ???
I'm pretty sure the TIA processes a write to RESP0 as soon as it
gets it (when the instruction completes), but it can take up to
five cycles (fifteen pixels) to write the register. A standard
STA RESP0 takes three cycles, but STA allows indexed indirect
addressing, which takes five. In this case, the players end up
at pixels 109 and 117 as stated in your comments.
I suspect the _real_ reason for HMP0, though, is that a DEY/BNE
loop takes five cycles (fifteen pixels) per iteration, making it
easy to use such a loop and HMxx to position an object at any
position.
>LF825: LDY $93 ; (61) +3 ;current line
> LDA ($F9),Y ; p0 p1 (64) +5 ;indirect indexed
> STA GRP0 ; F9 (69) +3
> STA WSYNC ; Cycle count begins
> LDA ($F7),Y ; (0) +5
> STA GRP1 ; F7 (5) +3
> LDA ($F5),Y ; (8) +5
> STA GRP0 ; F5 (13) +3
> LDA ($F3),Y ; (16) +5
> STA $94 ; (21) +3
> LDA ($F1),Y ; (24) +5
> TAX ; (29) +2 ;preload X
> LDA ($EF),Y ; (31) +5
> TAY ; (36) +2 ;and Y
> LDA $94 ; (38) +3 ;and A
> STA GRP1 ; F3 (41) +3 ;reload GRP at
>pixel ;123?
> STX GRP0 ; F1 (44) +3
> STY GRP1 ; EF (47) +3 ;reload GRP at
>pixel ;141?
> STA GRP0 ; F3 (50) +3
> DEC $93 ; (53) +5
> BPL LF825 ; Branch taken, so (58) +3
> ; End six-digit loop
Is this right: $EF = ones digit, $F1 = tens digit, $F3 = hundreds
digit, ... , $F9 = hundred-thousands digit? And the digits begin
at pixels 109, 117, 125, 133, 141, and 149 (cycles 36, 39, 41, 44,
47, and 49.) Writes to registers take effect when the instruction
completes, so your "Reload GRP1 at 123" actually executes at 132,
in time for the hundreds digit... the next STX GRP0 finishes at
141, just in time for the tens digit, and your "Reload GRP1 at
141" takes effect at 150, apparently one pixel too late, but my
guess is that the leftmost bit of the displayed byte is always 0
(to provide at least a one-pixel gap between digits) so it still
works.
I see what's going on here, especially the tricky STA $94 and
then loading it again because we need to use A to load the other
bytes because LDX and LDY don't permit indexed indirect addressing.
I don't quite understand what the last STA GRP0 is for, though
(at cycle (50)+3 ) .. it completes at cycle 53 = pixel 159, which
is after the score is done displaying on that line. I also
don't see how the STA GRP0 at cycle (69)+3 helps either.. it looks
like its preloading GRP0 for the hundred-thousands digit on the
next scanline (its executing before WSYNC), but GRP0 gets
rewritten with the thousands digit ($F5) at cycle (13)+3, pixel
48 of the next line.. that's within horizontal blank, before the
hundred-thousands digit gets displayed.
I'm pretty sure the last digit of Defender's score is always 0..
it doesn't look like it's hardcoded to display 0, though. I
forget at the moment if it displays a hundred-thousands digit
(the code would seem to indicate it doesn't), and I don't feel
like playing the game that long just to see =) Other games like
Missile Command and Millipede display six unrestricted digits,
though, so it's gotta be possible.
One more thing - you list BPL as taking three cycles if the
branch is taken.. my 6502 reference says conditional branches
take 4 cycles, though...? PC Atari's debugger adds nine pixels
for a taken branch, so I guess it is three, but I'd like to
know for sure.
>;//
>;Wow. The above loop just drew the score with no cycles to spare.
>;//
That says it all =) I'll try disassembling a couple other games
and see if I can figure anything else out.
--
Archives available at http://www.biglist.com/lists/stella/archives/
E-mail UNSUBSCRIBE in the body to stella-request@xxxxxxxxxxx to be removed.
