2600 101: My First Program

Shortly we'll be ready to begin programming. Or rather I'll be ready to begin programming, and you should be at a stage where you're ready to follow along.

But, first, a few words about 6502 (actually 6507, but who's counting) assembly. I really urge you to take a look at "Assembly in One Step", but if you're not going to do that (or you already have and could use a review) here's what you need to know before looking at programs: There are three all important memory things (aka "registers") on this chip: the Accumulator (usually called A) that can hold 8 bits of information, and is involved in all the math the chip does, and X and Y each of which can also hold 1 byte of information. Some of the chip instructions can also access the pitiful 128 bytes of memory you get directly, but this is a bit slower. Also, you can't directly copy the value at a memory location ("address") to another memory location...instead, you need to first put it into one of the registers (putting a value into a register from memory is called "Loading") and then take it out of the register and put it into memory (called "Storing"). 6502 Assembly is then a bunch of these little commands that do tidbits like basic math functions, memory juggling, and program flow control. (At any given moment, the "instruction pointer" is pointing at an address in memory, where the next command to execute is located. It generally goes forward through memory, unless it reaches a branch (a small hop, usually based on checking if a condition is true) or a jump (a potentially bigger jump). You can also "Jump to Subroutine", and then "Return" (which uses this little thing called a stack) but many atari games will avoid doing that, at least in "time critical" parts, since it's slower than just putting the instructions right there, and it uses 2 bytes of memory for each level of jump you do. (Actually, subroutines can greatly add to the structure and readability of a program, but I'm not too good with them, so the examples here won't use them.)

Oh, by the way, you need to kind of know "hex notation", which is base 16 with the digits 0 through F (as opposed to base 10, which goes from 0 through 9. Base 16 is just like Base 10 if you have 6 extra fingers.) And to make matters worse, we usually record negative numbers in something called "two's complement notation"...you have to understand this. That's all I'm going to say about hex here, 'cause I'm lazy.

Andrew Davie points out that another potentially confusing thing you need to learn about are the "addressing modes". Most of the instructions do stuff with memory locations, and most of those memory locations can be expressed in different ways. (Not all instructions support all of the following modes)
mode name example what it does
Absolute addressing lda $2000 load a byte from location hexadecimal 2000 (8192 decimal)
Zero-page addressing lda $80 load a byte from location $80 (128 decimal). This is the first byte of RAM
Absolute indexed addressing lda $2000,x load a byte from location hexadecimal 2000 + x, where x is the 8-bit value in the X register
Indirect indexed, y lda (0),y load a byte from location formed by the two bytes at 0,1 (in low, high format) added to the 8-bit value in the Y register
There are even more modes than that, but this gives you the general idea.

Andrew Davie also wrote the following: Registers are 8-bit only. Loading and storing from anywhere is also 8-bit only. Addresses are 8 or 16 bits. 8-bit addresses are also known as 'zero page' because the high-byte of the (imaginary) 16-bit address for these is always 0. Accesssing 16-bit locations in other areas of memory (ie: not zero page) is done through pairs of bytes in low, high format. Indexing is the process of adding the contents of an index register (x or y) to an 8-or-16 bit address, and grabbing a byte from that location - which may also turn out to be either 8 or 16 bits. :)

In case you haven't guessed, the previous paragraphs were a brutally short summary of the 6502 and Assembly language in general. Now here's a similar hatchet job on the 2600 and its TIA (television interface adaptor) chip, a summary of the Stella Player's Guide you should have at least skimmed:

The 2600 has, graphically speaking, 5 "things" to play with: 2 "players", which can be semi-detailed graphical things like men or dragons or tanks or what not, 2 "missiles", each being a square associated with a player, and a "ball", which is a bit like a missile, but associated with the playfield. (Playfield?? You ask. I'm getting to that.) And there's the playfield, 20 pixels across (and as many as you want down) that can be the background or foreground of your game.

Also, of course, the Atari has ways of dealing with joysticks and sounds and what not, but we're not going to tackle all that yet. And there is even a (very small) set of things the TIA does that makes your life easier, like keeping track of what things are overlapping other things, so you know if the bullet has hit a man or if the man has bumped into a wall.

So, remember all that talk about scanlines on Into The Breach? Here's where it really comes into play. Before each scanline is drawn, you have to determine if a missile or ball is "on" for this line, and turn it on if so. You also have to determine if the "player" is on this line, and if so, what line of graphics should be drawn on this line to represent the player. All that's reasonably tough to do quickly...so quickly, we're not going to worry about it for our first test program. (And you may notice that most Atari games seem to have more characters than 2 players, 2 bullets, and an extra thingy...what's happening there is that these graphic "things" are being reused as the program loops through and draws the screen.)

Our first test program is called "Thin Red Line". It got its very start in Nick Bensema's How to Draw a Playfield, though his routine used that JSR (jump to subroutine)/RTS (return from subroutine) stuff, and I've made some other changes as well with an eye towards making as simple a program as possible. (You can follow that link to the original code Nick wrote if you're curious...it is a nice visual display.) I made at least three major mistakes when I first wrote Thin Red Line, 2 of which Thomas Jentzsch helped me correct. (The other one I got on my own).

Sidebar: Two's Complement Notation
Ok, let me try to explain this. In Two's Complement, the leftmost bit is 1 when the number is negative, otherwise 0. To get the negative of any number, flip all the bits (1 to 0, 0 to 1) and then add 1, ignoring the sign. So with 4 bits, 2 is "0010"; flip that and it's "1101", add 1 you get "1110". Note that if you flip bits and add one again, you get back to the original "0010"

It seemed odd to me that the "biggest" value you could get in 4 bytes ("1111") would be 15, but it's -1, but think of a new car's speedometer going backwards. If would go from 0000 to 9999--seems like the biggest number, but really it's "-1". Well, if that (really weird) car's speedometer was in binary, it would roll back to "1111" instead. And the decimal car would then go to 9998, and our binary car goes back to 1110. It's a little weird but it works.
My idea was to make a line by turning on one of the missile graphics, and never turning it off. (Thus saving me from having to figure out when to turn it on and off to get the height of it correct). I also decided to get the line moving...the Atari makes it very easy to move any of its "things" horizontally. Each "thing" has a memory location you can set from 7 to -8 (positive moves to the left, negative to the right...which might be the opposite of what you expect! ) that represents that thing's Horizontal Speed. Then you execute a special command called HMOVE, which moves all 5 of the things at whatever its horizontal speed is at. Anything that has a 0 in its horizontal speed register stays still of course. And there are some other gotchas there, which I'll try to explain in the code. (Actually, all 3 of my initial mistakes involved that HMOVE, so while the idea is simple, the implementation gets complex.)

I'm going to give you the short, uncommented version first, so when you see the commented version that follows you don't get too scared by its immensity:
; thin red line by Kirk Israel

	processor 6502
	include vcs.h
	org $F000
Start
	sei
	cld
	ldx #$FF
	txs
	lda #0
ClearMem
	sta 0,X
	dex
	bne ClearMem
	lda #$00
	sta COLUBK
	lda #33
	sta COLUP0
MainLoop
	lda  #2
	sta  VSYNC
	sta  WSYNC
	sta  WSYNC
	sta  WSYNC
	lda  #43
	sta  TIM64T
	lda #0
	sta  VSYNC

WaitForVblankEnd
	lda INTIM
	bne WaitForVblankEnd
	ldy #191

	sta WSYNC
	sta VBLANK
	lda #$F0
	sta HMM0

	sta WSYNC
	sta HMOVE
ScanLoop
	sta WSYNC
	lda #2
	sta ENAM0
	dey
	bne ScanLoop

	lda #2
	sta WSYNC
	sta VBLANK
	ldx #30
OverScanWait
	sta WSYNC
	dex
	bne OverScanWait
	jmp  MainLoop

	org $FFFC
	.word Start
	.word Start

See, was that so bad? Of course you probably can't follow a word of it, so here is the fully explained version. You really should read through it, reading other people's code is a difficult but crucial learning technique, and this is about as heavily commented as you'll ever get.
; thin red line by Kirk Israel
;
;	(anything after a ; is treated as a comment and
;	ignored by DASM)
;
;	 First we have to tell DASM that we're
;	 coding to the 6502:
;

	processor 6502

;
;	then we have to include the "vcs.h" file
;	that includes all the "convenience names"
;	for all the special atari memory locations...
;
	include vcs.h

;
;	now tell DASM where in the memory to place
;	all the code that follows...$F000 is the preferred
; 	spot where it goes to make an atari program
;	(so "org" isn't a 6502 or atari specific command...
;	it's an "assembler directive" that's
;	giving directions to the program that's going to
;	turn our code into binary bits)
;

	org $F000

;
;	Notice everything we've done so far is "indented"
;	Anything that's not indented, DASM treats as a "label"
;	Labels make our lives easier...they say "wherever the
;	next bit of code ends up sitting in physical memory,
;	remember that location as 'labelname'.  That way we
;	can give commands lke "JMP labelname" rather than
;	"JMP $F012" or what not.
;	So we'll call the start of our program "Start".
;	Inspired genius, that.  Clever students will have
;	figured out that since we just told DASM "put the
;	next command at $F000", and then "Call the next memory
;	location 'Start':, we've implicitly said that
;	"Start is $F000"
;

Start

;
;	The next bit of code is pretty standard. When the Atari
;	starts up, all its memory is random scrambled. So the first
;	thing we run is "SEI" "CLD" and "TXS".
;	Look these up if you want,
;	for now know that they're just good things to cleanse
;	the palette...

	sei	 ;Disable Any Interrupts (hey! comments can go on the side!)
	cld  	 ; Clear BCD math bit.
	ldx #$FF ; set X to the top of the memory we have,
	txs	 ; ...and set the stack pointer to what X is...i.e. #$FF aka 255

;
;	Now the following is another pretty standard bit of code to start
;	your program with..it makes a brief delay when your
;	atari program starts, and if you're a hot shot you could consider
;	zeroing out only the memory locations you care about, but
;	for now we're gonna start at the top of memory, walk our way
;	down, and put zeros in all of that.
;
;	One thing you may notice is that a lot of atari programming
;	involves starting at a number, and counting your way down
;	to zero, rather than starting at zero and counting your
;	way up. That's because when you're using a Register to
;	hold your counter, it's faster/easier to compare that
;	value to zero than to compare it to the target value
;	you want to stop at.
;
;	So X is going to hold the starting memory location
;	(top of memory, $#FF)...in fact, it's already set to
;	$FF from the previous instruction, so we're not going to
;	bother to set it again...you see that kind of shortcut all
;	the time in people's code, and sometimes it can be confusing,
;	but Atari programs have to be *tight*. The "A"ccumulator is
;	going to hold what we put into each memory location (i.e. zero)

	lda #0		;Put Zero into A (X is at $FF)
ClearMem
	sta 0,X		;Now, this may not mean what you think...
	dex		;decrement X (decrease X by one)
	bne ClearMem	;if the last command resulted in something
			;that's "N"ot "Equal" to Zero, branch back
			;to "ClearMem"
;
;	Ok...a word of explanation about "sta 0,X"
;	You might assume that that said "store zero into the memory
;	location pointed to by X..." but rather, it's saying
;	"store whatever's in the accumulator at the location pointed
;	to by (X plus zero)"
;
;	So why does the command do that?  Why isn't there just a
;	"STA X" command? (Go ahead and make the change if you want,
;	DASM will give you an unhelpful error message when you go
;	to assemble.) Here's one explanation, and it has to do with
;	some handwaving I've been doing...memory goes from $0000-$FFFF
;	but those first two hex digits represent the "page" you're dealing
;	with.  $0000-$00FF is the "zero page", $0100-$01FF is the first
;	page, etc.  A lot of the 6502 commands take up less memory
;	when you use the special mode that deals with the zero page,
;	where a lot of the action in atari land takes place.
;  (some of those values are the special 'named ones' vcs.h names
;  for us, that make the Atari's TIA chip do special stuff.
;  Most of the rest you can use for your variables.)
;	...sooooo, STA $#nnnn would tell it to grab the next two bytes
;	for a full 4 byte address, but this mode only grabs the one
;	value from the zero page
;

;
;	Now we can finally get into some more interesting
;	stuff.  First lets make the background black
;	(Technically we don't have to do this, since $00=black,
;	and we've already set all that memory to zero.
;	But one easy experiment might be to try different two
;	digit hex values here, and see some different colors
;
       lda #$00		;load value into A ("it's a black thing")
       sta COLUBK	;put the value of A into the background color register

;
;	Do the same basic thing for missile zero...
;	(except missiles are the same color as their associated
;	player, so we're setting the player's color instead
;

       lda #33
       sta COLUP0

;
;	Now we start our main loop
;	like most Atari programs, we'll have distinct
;	times of Vertical Sync, Vertical Blank,
;	Horizontal blank/screen draw, and then Overscan
;
;	So every time we return control to Mainloop.
;	we're doing another television frame of our humble demo
;	And inside mainloop, we'll keep looping through the
;	section labeled Scanloop...once for each scanline
;

MainLoop
;*********************** VERTICAL SYNC HANDLER
;
;	If you read your Stella Programmer's Guide,
;	you'll learn that bit "D1" of VSYNC needs to be
;	set to 1 to turn on the VSYNC, and then later
;	you set the same bit to zero to turn it off.
;	bits are numbered from right to left, starting
;	with zero...that means VSYNC needs to be set with something
;	like 00000010 , or any other pattern where "D1" (i.e. second
;	bit from the right) is set to 1.  00000010 in binary
;	is two in decimal, so let's just do that:
;
	lda  #2
	sta  VSYNC	; Sync it up you damn dirty television!
			; and that vsync on needs to be held for three scanlines...
			; count with me here,
	sta  WSYNC	; one... (our program waited for the first scanline to finish...)
	sta  WSYNC 	; two... (btw, it doesn't matter what we put in WSYNC, it could be anything)
	sta  WSYNC	; three...

;	We blew off that time of those three scanlines, though theoretically we could have
;	done some logic there...but most programs will definately want the vertical blank time
;	that follows...
;	you might want to do a lot of things in those 37 lines...so many
;	things that you might become like Dirty Harry: "Did I use up 36 scanlines,
;	or 37? Well, to tell you the truth, in all this excitement, I've kinda lost track
;	myself."  So here's what we do...The Atari has some Timers built in.  You set these
;	with a value, and it counts down...then when you're done thinking, you kill time
;	until that timer has clicked to zero, and then you move on.
;
;	So how much time will those 37 scan lines take?
;	Each scanline takes 76 cycles (which are the same thing our clock is geared to)
;	37*76 = 2812 (no matter what Nick Bensema tries to tell us...his "How to Draw
;	A Playfield" is good in a lot of other ways though..to quote the comments from
;	that:
;		 We must also subtract the five cycles it will take to set the
;		 timer, and the three cycles it will take to STA WSYNC to the next
;		 line.  Plus the checking loop is only accurate to six cycles, making
; 		a total of fourteen cycles we have to waste.
;
;	So, we need to burn 2812-14=2798 cycles.  Now, there are a couple of different
;	timers we can use, and Nick says the one we usually use to make it work out right
;	is TIM64T, which ticks down one every 64 cycles.  2798 / 64 = 43.something,
;	but we have to play conservative and round down.
;

	lda  #43	;load 43 (decimal) in the accumulator
	sta  TIM64T	;and store that in the timer

	lda #0		;Zero out the VSYNC
	sta  VSYNC 	; 'cause that time is over

;
;	So RIGHT HERE we can do a ton of game logic, and we don't have
;	to worry too much about how many instructions we're doing,
;	as long as it's less than 37 scanlines worth (if it's not
;	less, your program is a little screwed, and you need to
;   write better time-tighter code, or put the code in the
;   overscan or elsewhere.
;
;*********************** VERTICAL BLANK WAIT-ER
WaitForVblankEnd
	lda INTIM	;load timer...
	bne WaitForVblankEnd	;killing time if the timer's not yet zero

	ldy #191 	;Y is going to hold how many lines we have to do
			;...we're going to count scanlines here. theoretically
			; since this example is ass simple, we could just repeat
			; the timer trick, but often its important to know
			; just what scan line we're at.
	sta WSYNC
	sta VBLANK

			;End the VBLANK period with the zero
			;(since we already have a zero in "A"...or else
			;the BNE wouldn't have let us get here! Atari
			;is full of double use crap like that, and you
			;should comment when you do those tricks)
			;We do a WSYNC just before that so we don't turn on
			;the image in the middle of a line...an error that
			;would be visible if the background color wasn't black.

	;HMM0 is the "horizontal movement register" for Missile 0
	;we're gonna put in a -1 in the left 4 bits ("left nibble",
	; use the geeky term for it)...it's important
	;to note that it's the left 4 bits that metters, what's in the
	;right just doesn't matter, hence the number is #$X0, where
	;X is a digit from 0-F.  In two's complement notation, -1
	;is F if we're only dealing with a single byte.
	;
	; Are you having fun yet?
	;

	lda #$F0	; -1 in the left nibble, who cares in the right
	sta HMM0	; stick that in the missile mover

	sta WSYNC	;wait for one more line, so we know things line up
	sta HMOVE 	;and activate that movement
			;note...for godawful reasons, you must do HMOVE
			;right after a damn WSYNC. I might be wasting a scanline
			;with this, come to think of it

;*********************** Scan line Loop
ScanLoop

	sta WSYNC 	;Wait for the previous line to finish
	lda #2		;now sticking a 2 in ENAM0 (i.e. bit D1) will enable Missile 0
	sta ENAM0	;we could've done this just once for the whole program
			;since we never turn it off, but i decided to do it again and
			;again, since usually we'd have to put smarter logic in
			; each horizontal blank
			;
			;so at some point in here, after 68 clock cycles to be exact,
			;TIA will start drawing the line...all the missiles and players
			;and what not better be ready...unless we *really* know what
			;we're doing.

	dey		;subtract one off the line counter thingy
	bne ScanLoop	;and repeat if we're not finished with all the scanlines.

	lda #2		;#2 for the VBLANK...
	sta WSYNC  	;Finish this final scanline.
	sta VBLANK 	; Make TIA output invisible for the overscan,
			; (and keep it that way for the vsync and vblank)
;***************************** OVERSCAN CALCULATIONS
;
;I'm just gonna count off the 30 lines of the overscan.
;You could do more program code if you wanted to.


	ldx #30		;store 30
OverScanWait
	 sta WSYNC
	 dex
	 bne OverScanWait

	jmp  MainLoop      ;Continue this loop forver! Back to the code for the vsync etc


; OK, last little bit of crap to take care of.
; there are two special memory locations, $FFFC and $FFFE
; When the atari starts up, a "reset" is done (which has nothing to do with
; the reset switch on the console!) When this happens, the 6502 looks at
; memory location $FFFC (and by extension its neighbor $FFFD, since it's
; seaching for both bytes of a full memory address)  and then goes to the
; location pointed to by $FFFC/$FFFD...so our first .word Start tells DASM
; to put the binary data that we labeled "Start" at the location we established
; with org.  And then we do it again for $FFFE/$FFFF, which is for a special
; event called a BRK which you don't have to worry about now.

	org $FFFC
	.word Start
	.word Start


Whoo! Now, what three mistakes could I have possibly made? (All of these were corrected in the code you see above.)
  1. I didn't read the SPG well enough, and kind of missed that WSYNC has to immediately precede HMOVE (Thanks Thomas)
  2. I didn't read the SPG well enough and was just trying to fiddle with the rightmost bits of HMM0 (Thanks again Thomas)
  3. I was kind of stupid, and tried to do an HMOVE right after the WSYNC for every scanline, not every tv picture frame! That's one I caught myself when what should've been a nice vertical line was broken up into a bunch of little jumpy bits.
You might want to go ahead and figure out how to change the speed of the line, as well as the color.

PS...it turns out I made FOUR mistakes...the fourth was I didn't do that additional WSYNC before turning off the VBLANK, so when I change the background todifferent colors you only see half of the top line. Thanks, yet again, Thomas.

Next: Kernal Clink
Introduction - The Development Environment - Into The Breach - My First Program -
Kernal Clink - The Joy of Sticks - Happy Face - PlayerBufferStuffer