godzillajoe, on Sun Apr 1, 2007 7:19 PM, said:
OK in looking at the code, can someone explain how this works
PFData0 ;H 4 5 6 7
.byte $00,$f0,$00,$A0,$A0,$E0,$A0,$A0
PFData1 ;EL 7 6 5 4 3 2 1 0
.byte $00,$FF,$00,$77,$44,$64,$44,$74
PFData2 ;LO 0 1 2 3 4 5 6 7
.byte $00,$FF,$00,$EE,$A2,$A2,$A2,$E2
How do you get 'H' from $00,$f0,$00,$A0,$A0,$E0,$A0,$A0 ?
and the otther letters?
Have a look at the block of comments above the definitions of the letters (beginning at line 347) for an explanation of how the bits in each byte map to the playfield pixels on the screen.
If you convert the playfield data to binary, you can actually visualize the playfield graphics. Each "1" bit is a lit pixel, and each "0" bit is an unlit pixel (background-colored, in this case black).
The "H", converted to binary, one byte per line:
$00: 00000000
$f0: 11110000
$00: 00000000
$A0: 10100000
$A0: 10100000
$E0: 11100000
$A0: 10100000
$A0: 10100000
See how that looks like an "H" with a solid horizontal line above it? It's even more H-like if I draw the 1 bits as the letter X and the 0 bits as spaces:
XXXX
X X
X X
XXX
X X
X X
Now, the PF0 register is only 4 bits wide... only the leftmost 4 bits of each byte are used (notice the 4 right-hand bits are all 0's in all 8 lines). This is what's meant by the "4 5 6 7" in the comment. Also, the bits are displayed backwards relative to how they appear in the binary conversion... but it doesn't really matter for our purposes: the letter "H" is horizontally symmetrical, so you can easily recognize it in the binary dump.
Also, the data is stored upside-down in ROM (more on this later). The letter "H" looks the same either way...
Now for PF1, the "EL". I'll convert each byte to binary, and include the X's-and-spaces on the same line:
$00: 00000000 |
$FF: 11111111 | XXXXXXXX
$00: 00000000 |
$77: 01110111 | XXX XXX
$44: 01000100 | X X
$64: 01100100 | XX X
$44: 01000100 | X X
$74: 01110100 | XXX X
See? It's an upside-down "EL" with a horizontal line above it... This data is going to be stored in the PF1 register, which is 8 bits wide (all 8 bits are displayed, unlike PF0). The bits in PF1 are also displayed in order from left to right (also unlike PF0: remember, I said it was "backwards").
You can work out the PF2 data yourself, at this point... PF2 is 8 bits wide like PF1, but its bits are in reverse order like PF0. You should end up with an upside-down and backwards "LO".
The playfield is 20 bits (pixels) wide: 4 bits from PF0 plus 8 each from PF1/PF2. It gets displayed twice per scanline (by the hardware, not by your program), which is why the word "HELLO" shows up in two columns. This is a doubled playfield... in a mirrored playfield, the right-hand copy of PF0/1/2 gets displayed backwards compared to the left copy; in a doubled playfield, they're displayed in the same order). It would be possible to display "HELLO OLLEH" on each line by changing the value stored in CTRLPF (actually, the E's and L's would be backwards, so it would look like a mirror image... hence the name "mirrored").
Why is the data upside-down in the ROM? Well, on the 6502, it's quicker/easier to count down in a loop than it is it count up. Without going into too much detail: if you're counting up, you have to compare your register against the ending value each time. If you start at the ending value and count down, you don't need to compare against 0, because the 6502's Z (zero) flag will already be set when the counter reaches 0, saving you the need to do a compare.
Hope this helps...