Any more complete examples of drawing playfields?

[godzillajoe]

I'm trying to understand this stuff.

 

Does anyone have some complete ready to compile source code that maybe displays something simple like

 

H E L L O

 

or

 

H

 

E

 

L

 

L

 

O

 

as a play field so I can take a look at it.

 

Seems like some of the stuff in the tutorial doesn't exist anymore, dead links and such

 

The more source code I can look at the easier it will be for me to understand it

 

Thanks!

[SeaGtGruff]

I'm trying to understand this stuff.

 

Does anyone have some complete ready to compile source code that maybe displays something simple like

 

H E L L O

 

or

 

H

 

E

 

L

 

L

 

O

 

as a play field so I can take a look at it.

 

Seems like some of the stuff in the tutorial doesn't exist anymore, dead links and such

 

The more source code I can look at the easier it will be for me to understand it

 

Thanks!

Sure, I'll post an example for that. And anyone else, jump in, the more examples the better!

 

Michael

[Thomas Jentzsch]

Did you try this?

 

http://www.io.com/~nickb/atari/doc/nbtia_1.asm

[godzillajoe]

I did not. Thanks. I'll check it out!

[godzillajoe]

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?

Edited April 1, 2007 by godzillajoe

[Urchlay]

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

[godzillajoe]

OK thanks, I think I get it!

 

Will experiment a bit tomorrow and see if I can get it to correctly display my name or some such thing instead of HELLO

[Nukey Shay]

BTW the development program TIA Playfield Painter can be used to create your playfield data text file. Example source codes to use the data are also on the same page.

 

Also, PF0 only uses half of the byte (referred to as a nybble). With some slight modification to the code, you could combine both data tables for this register...and place Screen_PF3 data into the "low nybble" of Screen_PF0 data.

 

Original:

		LDX #192; 192 Scanlines to Display
Draw_Picture
	LDA Screen_PF0-1,X
	STA PF0
	LDA Screen_PF1-1,X
	STA PF1
	LDA Screen_PF2-1,X
	STA PF2
	SLEEP 4
	LDA Screen_PF3-1,X
	STA PF0
	LDA Screen_PF4-1,X
	STA PF1
	LDA Screen_PF5-1,X
	STA PF2
	STA WSYNC
	DEX
	BNE Draw_Picture

 

 

Combined:

		LDX #192; 192 Scanlines to Display
Draw_Picture
	LDA Screen_PF0-1,X
	STA PF0
	LDY Screen_PF1-1,X;use Y instead
	STY PF1				  ;""
	LDY Screen_PF2-1,X;""
	STY PF2				  ;""
	ASL
	ASL
	ASL
	ASL
	STA PF0
	LDA Screen_PF4-1,X
	STA PF1
	LDA Screen_PF5-1,X
	STA PF2
	STA WSYNC
	DEX
	BNE Draw_Picture

[SeaGtGruff]

Well, I think you've already got the idea, but here's the program I wrote, which contains a lot of comments to try to explain everything. I actually just removed a bunch of comments, so you can imagine how many there used to be. Hopefully the continuity of the remaining comments didn't get screwed up.

 

Michael

Hello_1.txt

Hello_1.asm.bin

[godzillajoe]

OK I get it

 

So in honor the Sox opening day, I modified it to this

 

[SeaGtGruff]

OK I get it

 

So in honor the Sox opening day, I modified it to this

 

I don't know what kind of playfield you used, but with that particular screen, you can just use a symmetrical non-reflected playfield, and just store PF0, PF1, and PF2, since the right side of the playfield is identical to the left side.

 

Michael

[godzillajoe]

I just screwed around with the code that Thomas linked, changing the HELLO that it displays to mine just to get an idea of how this stuff is done.

 

I'll take a look at your example tomorrow and see what that does and maybe even understand it. Or ask lots more stupid questions

 

BTW anyone know why when I load the bin in through the supercharger the bg color is yellow and not black? And after a while, it starts freaking out and flashing.

 

 

 

Oh well, not too worried about that right now

Edited April 2, 2007 by godzillajoe