>> If you want a line-by-line breakdown and/or the HMOVE table, ask and ye
>> shall receive.
>
>YES YES YES YES YES YES YES YES YES YES YES YES YES YES YES YES YES YES
>
>That would be great, thank you.
The "HMOVE format" is a way of storing the fine and coarse coordinates for
an object. The low nibble (the coarse value) is how many times to do a
5-cycle delay loop - this gives you 15-pixel precision, which is what
you've got in the Kana demo. The high nibble is the fine position - the
way this works is that you write a number from -7 to 7 (looking only at the
top four bits of the byte) to HMP0, with negative numbers meaning move
right and positive numbers meaning move left. That motion does not
actually happen until you do a HMOVE. Here's the table - don't worry about
how it was generated for now. (This table also takes into account the
mysterious 5-pixel delay that I'll explain later.)
HorzTable ;this must not cross a page boundary
.byte $00,$F0,$E0,$D0,$C0,$B0,$A0,$90
.byte $71,$61,$51,$41,$31,$21,$11,$01,$F1,$E1,$D1,$C1,$B1,$A1,$91
.byte $72,$62,$52,$42,$32,$22,$12,$02,$F2,$E2,$D2,$C2,$B2,$A2,$92
.byte $73,$63,$53,$43,$33,$23,$13,$03,$F3,$E3,$D3,$C3,$B3,$A3,$93
.byte $74,$64,$54,$44,$34,$24,$14,$04,$F4,$E4,$D4,$C4,$B4,$A4,$94
.byte $75,$65,$55,$45,$35,$25,$15,$05,$F5,$E5,$D5,$C5,$B5,$A5,$95
.byte $76,$66,$56,$46,$36,$26,$16,$06,$F6,$E6,$D6,$C6,$B6,$A6,$96
.byte $77,$67,$57,$47,$37,$27,$17,$07,$F7,$E7,$D7,$C7,$B7,$A7,$97
.byte $78,$68,$58,$48,$38,$28,$18,$08,$F8,$E8,$D8,$C8,$B8,$A8,$98
.byte $79,$69,$59,$49,$39,$29,$19,$09,$F9,$E9,$D9,$C9,$B9,$A9,$99
.byte $7A,$6A,$5A,$4A,$3A,$2A,$1A,$0A,$FA,$EA,$DA,$CA,$BA,$AA,$9A
The routine is pretty simple. As an example, let's assume Player0Pos is
33, meaning we want Player 0 to be displayed at pixel 33 of the screen,
counting from zero.
>sta WSYNC ;begin scanline
>ldx Player0Pos ;+3 3
Those should be obvious. X=33=$21.
>lda HorzTable,X ;+4 7
This gets the HorzTable value for the specified X-coordinate - this'd be
offset $21 of that table, which is $D2.
>sta HMP0 ;+3 10
We write the fine position value to HMP0. The TIA just ignores the low
four bits of the byte, and keeps the upper four in register HMP0. The
number is $D, which in a 4-bit field would be -3. It does not do anything
with the -3 at this point.
>and #$0F ;+2 12
Clear out the top 4 bits. Now the accumulator has the coarse positioning -
the number of times we want to do the delay loop. In our example, it's 2.
>tax ;+2 14
Put it into X because we can't do DEA. <mumble> lousy processor...
>P0 dex ;+2 16
>bpl P0 ;when branch not taken: +2 (18 + x*5)
This will take 4 cycles, plus 5 cycles times X. In our example, it turns
into:
DEX ;+2 16, X now =1
BPL ;+3 19 because branch taken
DEX ;+2 21, X now =0
BPL ;+3 24 because branch taken (zero counts as positive for BPL)
DEX ;+2 26, X now = -1 = $FF
BPL ;+2 28, because branch NOT taken.
>sta RESP0 ;(21 + x*5)
This takes 3 cycles, so we've completed 31 cycles at this point. 31 cycles
* 3 pixels/cycle = 93 pixels from WSYNC. Since the horizontal blanking
time is 68 pixels, the sprite should begin displaying at pixel 93-68 = 25.
BUT, for some reason, the TIA displays players 5 pixels later than it
should, so the sprite will actually begin at pixel 30. This 5 pixels is
accounted for in the table - you can just pretend it doesn't exist.
>sta WSYNC
Begin the next scanline.
>sta HMOVE
This activates the motion we did way back with the STA HMP0. (I know it
seems like it's been forever, but it's actually been about 55
microseconds.) Since we stored a -3 to HMP0, the TIA moves the sprite 3
pixels to the right, to pixel 33, right where we wanted it! It will stay
at pixel 33 until you move it somewhere else. It won't display anything
unless and until you write a nonzero value to GRP0 and COLUP0.
This works for players. Not to confuse you further, but the "mystery 5
pixel delay" is only 4 pixels for missiles and the ball, so you need to
change the lda horztable,X to lda horztable+1,X . Just warning you. :)
<whew! Where do I apply for the Pulitzers? :) >
>It was funny, but looking at this sprite demo of mine with the zipping
>Kana gave me a number of ideas for games. For example, a random
>pachinko game. The pin sprites zip about at various speeds until you press
>the fire button and then yourplayfield is set. It could use P0 and P1
>on the same scan line and even multiple copies on some lines, and the ball
>could be the.... well the ball. You could use missle sprites to make the
>holes, or playfield graphics.
Common knowledge. Any graphical mess can be turned into a game. See the
Playstation, N64, and many PC games. :)
--
Archives (includes files) at http://www.biglist.com/lists/stella/archives/
Unsub & more at http://www.biglist.com/lists/stella/stella.html
