Atari 2600 Programming for Newbies

NTSC/PAL/SECAM

Remember that it also depends on what system we're running on! If we're doing a PAL kernel, then we will see a different color than if we're doing a NTSC or SECAM kernel. The bizarre consequence of this is that if we change the number of scanlines our kernel generates, the COLORS of everything also change. That's because (if we are running on an emulator or plug a ROM into a console) we are essentially switching between NTSC/PAL/SECAM systems, and as noted these systems send different color information to the TV! It's weird, but the bottom line is that when you choose colors, you choose them for the particular TV standard you are writing your ROM to run on. If you change to a different TV system, then you will also need to rework all the colors of all the objects in your game.

A, X, and Y Registers

Let's go back to our kernel and have a bit of a look at what it's doing to achieve that rainbow effect. There's remarkably little code in there for such a pretty effect.

As we've learned, the 6502 has just three 'registers'. These are named A, X, and Y—and allow us to shift bytes to and from memory—and perform some simple modifications to these bytes. In particular, the X and Y registers are known as 'index registers', and these have very little capability (they can be loaded, saved, incremented and decremented). The accumulator (A) is our workhorse register, and it is this register used to do just about all the grunt-work like addition, subtraction, and bit manipulation.

Our simple kernel, though, uses the X register to step a color value from 0 (at the start), writing the color value to the TIA background color register (COLUBK), incrementing X by one each scanline. First (outside the repeat) we have 'ldx #0'. This instruction moves the numeric value 0 into the X register. ld is an abbreviation for 'load', and we have lda, ldx, ldy. st is the similar abbreviation for store, and we have stx sty sta. Inside our repeat structure, we have 'stx COLUBK'. As noted, this will copy the current contents of the x register into the memory location 9 (which is, of course, the TIA register COLUBK). The TIA will then *immediately* use the value we wrote as the background color sent to the TV. Next we have an instruction 'inx'. This increments the current value of the X register by one. Likewise, we have an 'iny' instruction, which increments the y register. But, alas, we don't have an 'ina' instruction to increment the accumulator (!). We are also able to decrement (by 1) the x and y registers with 'dex' and 'dey'.

The operation of our kernel should be pretty obvious, now. The X register is initialized with 0, and every scanline it is written to the background color register, and incremented. So the background color shows, scanline by scanline, the color range that the '2600 is capable of. In actual fact, you could throw another 'inx' in there and see what happens. Or even change the 'inx' to 'dex'—what do you think will happen? As an aside, it was actually possible to blow up one early home computer by playing around with registers like this (I kid you not!)—but you can't possibly damage your '2600 (or emulator!) doing this. Have fun, experiment.

WSYNC

Now you've had a little introduction to the COLUBK register, I'd just like to touch briefly on the difference apparent between the WSYNC register and the COLUBK register. The former (WSYNC) was a strobe—you could simply 'touch' it (by writing any value) and it would instantly halt the 6502. Didn't matter what value you wrote, the effect was the same. The latter register (COLUBK) was used to send an actual VALUE to the TIA (in this case, the value for the color for the background)—and the value written was very much important. In fact, this value is stored internally by the TIA and it keeps using the value it has internally as the background color until it changes.

Initialize the TIA Registers

If you think about the consequences of this, then, the TIA has at least one internal memory location which is in an unknown state (at least by us) when the machine first powers on. We'd probably see black—which happens to be value 0 on all machines), but you never know. I believe it is wise to initialize the TIA registers to known-states when your kernel first starts—so there are no surprises on weird machines or emulators. We have done nothing, so far, to initialize the TIA—or the 6502, for that matter—and I think we'll probably have a brief look at system startup code in a session real-soon-now.

Until then, have a play with the picture-drawing section, and see what happens when you write different values to the COLUBK register. You might even like to change it several times in succession and see what happens. Here's something to try (with a bit of head-scratching, you should be able to figure all this out by now)…

               ; 192 scanlines of picture... 



                ldx #0 

                ldy #0 

                REPEAT 192; scanlines 



                    nop

                    nop

                    nop

                    nop

                    nop

                    nop

                    nop

                    nop

                    nop

                    nop

                     

                    inx 

                    stx COLUBK 



                    nop 

                    nop 

                    nop 



                    dey 

                    sty COLUBK 



                    sta WSYNC 



                REPEND

One caution: as the above code is wrapped inside a repeat structure which creates 192 copies of the enclosed code, we're actually running short of ROM space! With the above code installed, there's only 10 bytes free in our entire ROM! Clearly, using REPEAT in this sort of situation is wasteful, and the code should be written as a loop. We covered looping for scanline draw early on—but because both X and Y registers are in use at the moment, it's a bit more tricky.

So for now, we'll just have to accept that we can't add any more code—but at least you can see what effect adding/removing cycles can have on the existing code.

Here's a screenshot:

Here's the .bin file to use with an emulator:

kernel_11.bin