Session 4: The TIA

[+Andrew Davie]

Last session we were introduced to the link between the 6502 and the TIA. Specifically, how every cycle of 6502 time corresponds to three colour clocks of TIA time.

 

The TIA determines the colour of each pixel based on its current 'state', which contains information about the colour, position, size and shape of objects such as background, playfield, sprites (2), missiles (2) and ball. As soon as the TIA completes a scanline (228 cycles, consisting of 160 colour clocks of pixels, and 68 colour clocks of horizontal blank), it begins drawing the next scanline. Unless there is some change to the TIA's internal 'state' during a scanline, then each scanline will be absolutely identical.

 

Consequently, the absolute simplest way to 'draw' 262 lines for a NTSC frame is to just WAIT for 262 (lines) x 76 (cycles per line) 6502 cycles. After that time, the TIA will have sent 262 identical lines to the TV. There are other things that we'd need to do to add appropriate control signals to the frame, so that the TV would correctly synch to the frame - but the essential point here is that we can leave the TIA alone and let it do its stuff. Without our intervention, once the TIA is started it will keep sending scanlines (all the same!) to the TV. And all we have to do to draw n scanlines is wait n x 76 cycles.

 

It's time to have a little introduction to the 6502.

 

The CPU of the '2600, the 6502, is an 8-bit processor. Basically this means that it is designed to work with numbers 8-binary-bits at a time. An 8-bit binary number has 8 0's or 1's in it, and can represent a decimal number from 0 to 255. Here's a quick low-down on binary...

 

In our decimal system, each digit 'position' has an intrinsic value. The units position (far right) has a value of 1, the tens position has a value of 10, the hundreds position has a value of one hundred, the thousands position has a value of 1000, etc. This seems silly and obvious - but it's also the same as saying the units position has a value of 10^0 (where ^ means to the power of), the tens position has a value of 10^1, the hundreds position has a value of 10^2, etc. In fact, it's clear to see that position number 'n' (counting right to left, from n=0 as the right-most digit) has a value of 10^n.

 

That's true of ANY number system, where the 10 is replaced by the 'base'. For example, hexadecimal is just like decimal, except instead of counting 10 digits (0 to 9) we count 16 digits (0 to 15, commonly written 0 1 2 3 4 5 6 7 8 9 A B C D E F - thus 'F' is actually a hex digit with decimal value 15 - which again, is 1 x 10^1 + 5 x 10^0 ). So in hexadecimal (or hex, for short), the digit positions are 16^n. There's no difference between hex, decimal, binary, etc., in terms of the interpretation of a number in that number system. Consider the binary number 01100101 - this is (reading right to left)... 1 x 2^0 + 0 x 2^1 + 1 x 2^2 + 0 x 2^3 + 0 x 2^4 + 1x2^5 + 1x2^6 + 1x2^7. In decimal, the value is 101. So, %01100101 = 101 where the % represents a binary number. Hexadecimal numbers are prefixed with a $.We'll get used to using binary, decimal and hex interchangeably - after all they are just different ways of writing the same thing. When I'm talking about numbers in various bases, I'll include the appropriate prefix when not base-10.

 

So now it should be easy to understand WHY an 8-bit binary number can represent decimal values from 0 to 255 - the largest binary number with 8 bits would be %11111111 - which is 1 x 2^7 + 1 x 2^6 + .... + 1 x 2^0.

 

The 6502 is able to shift 8-bit numbers to and from various locations in memory (referred to as addresses) - each memory location is *UNIQUELY* identified by a memory address, which is just like your house street address, or your post-box number. The processor is able to access memory locations and retrieve 8-bit values from, or store 8-bit values to those locations.

 

The processor itself has just three 'registers'. These are internal memory/storage locations. These three registers (named 'A', 'X', and 'Y') are used for manipulating the 8-bit values retrieved from memory locations and for performing whatever calculations are necessary to make your program do its thing.

 

What can you do with just three registers? Not much... but a hell of a lot of not much adds up to something! Just like with the TV frame generation, a lot of work is left for the programmer. The 6502 cannot multiply or divide. It can only increment, decrement, add and subtract, and it can only work with 8-bit numbers! It can load data from one memory location, do one of those operations on it (if required) and store the data back to memory (possibly in another location). And out of that capability comes all the games we've ever seen on the '2600. Amazing, innit?

 

At this stage it is probably a good idea for you to start looking for some books on 6502 programming - because that's the ONLY option when programming '2600. Due to the severe time, RAM and ROM constraints, every cycle is precious, every bit is sacred. Only the human mind is currently capable of writing programs as efficiently as required for '2600 development.

 

 

That was a bit of a diversion - let's get back to the TIA and how the TIA and 6502 can be used together to draw exactly 262 lines on the TV. Our first task is simply to 'wait' for 76 cycles, times 262 lines.

 

The simplest way to just 'wait' on the 6502 is just to execute a 'nop' instruction. 'nop' stands for no-operation, and it takes exactly two cycles to execute. So if we had 38 'nop's one after the other, the 6502 would finish executing the last one exactly 76 cycles after it started the first. And assuming the first 'nop' started at the beginning of the scanline, then the TIA (which is doing its magic at the same time) would have just finished the last colour clock of the scanline at the same time as the last nop finished. In other words, the very next scanline would then start as our 6502 was about to execute the instruction after the last nop, and the TIA was just about to start the horizontal retrace period (which, as we have learned, is 68 colour clocks long).

 

How do we tell the 6502 to execute a 'nop'? Simply typing nop on a line by itself (with at least one leading space) in the source code is all we have to do. The assembler will convert this mnemonic into the actual binary value of the nop instruction. For example...

 

 
; sample code



   NOP

   nop



; end of sample code

 

The above code shows two nop instructions - the assembler is case-insensitive. Comments are preceeded by semicolons, and occupy the rest of a line after the ; Opcodes (instructions) are mnemonics - typically 3 letters - and must not start at the beginning of a line! We can have only one opcode on each line. An assembler would convert the above code into a binary file containing two bytes - both $EA (remember, a $ prefix indicates a hexadecimal number) = 234 decimal. When the 6502 retrieves an opcode of $EA, it simply pauses for 2 cycles, and then executes the next instruction. The code sequence above would pause the processor for 4 cycles (which is 12 pixels of TIA time, right?!)

 

But there are better ways to wait 76 cycles! After all, 38 'nop's would cost us 38 bytes of precious ROM - and if we had to do that 262 times (without looping), that would be 9432 bytes - more than double the space we have for our ENTIRE game!

 

The TIA is so closely tied to the 6502 that it has the ability to stop and start the 6502 at will. Funnily enough, at the 6502's will! More correctly, the 6502 has the ability to tell the TIA to stop it (the 6502), and since the TIA automatically re-starts the 6502 at the beginning of every scanline, the very next thing the 6502 knows after telling the TIA to stop the CPU is that the TIA is at the beginning of the very next scanline. In fact, this is the way to synchronise the TIA and 6502 if you're unsure where you're at - simply halt the CPU through the TIA, and next thing you know you're synchronised. It's like a time-warp, or a frozen sleep - you're simply not aware of time passing - you say 'halt' and then continue on as if no halt has happened. It has, but the 6502 doesn't know it.

 

This CPU-halt is achieved by writing any value to a TIA 'register' called WSYNC. Before we get into reading and writing values to and from 'registers' and 'memory', and what that all means, we'll need to have a look at the memory architecture of the '2600 - and how the 6502 interacts with memory, including RAM and ROM.

 

We'll start to explore the memory map (architecture) and the 6502's interaction with memory and hardware, in our next installment.

[+5-11under]

Andrew,

Thanks for what you've written so far. I'm looking forward to more.

5-11under

[PackratVG]

I don't know how you do it Andrew. You're incredible and keep up the good work. People have been asking for something like this for ages and no one has been dedicated enough to even really try. I'm sure that this will make it to print form one way or another in the future. Thanks so much!

 

Jarett

[MegaManFan]

I've learned more in one day of reading this thread about 2600 programming than I knew about it in a whole year, and he's only just gotten started. Surprisingly, it doesn't seem quite as overwhelming now as I at first thought! The +hard+ part would be actually coming up with an original game concept that people would want to play.

[Robert M]

Just one small comment on this lesson:

 

The processor itself has just three 'registers'. These are internal memory/storage locations. These three registers (named 'A', 'X', and 'Y') are used for manipulating the 8-bit values retrieved from memory locations and for performing whatever calculations are necessary to make your program do its thing.  

 

I don't know if this muddies the water for newbies, but I like to think of the 6502 as having 6 registers: A, X, Y, PC, SP, ST. A, X, Y are the ones Andrew already mentioned.

 

PC: Is a 16-bit register its points to the next address the processor is going to fetch an instruction byte from. It is automatically incremented by the processor during execution. As a programmer you can change PC with branch and jump instructions.

 

SP: Is an 8-bit stack pointer. From the CPUs point of view the stack is located from $0100 to $01FF. In the 2600 this maps to the 128 bytes of RAM in the PIA. Note that the same 128-bytes of RAM appear in the memory map of the CPU: $0080 - $00FF, $0180-$01FF, etc. The SP register is modified when instructions push or pull data from the stack. The stack grows downward in memory as items are added so it is generally initialized to $FF. You can set the SP from the X register using TXS. You can figure out how much data is on the stack by using TSX to transfer SP to X and find the difference from the value you initialized it to.

 

ST: Is the processor status register. When the CPU performs operations on data in A, X, or Y it sets or resets bits in ST to indicate mathematical properties of the result of the operation. A whole tutorial would be needed to explain how to understand the status flags and use them in your code for optimum efficiency. One thing worth noting here is you can push the ST register onto the stack to save the result of an operation, perform a different operation and then pop the old result off the stack to look at it. This can be handy. Also, as I stated earlier the 128 bytes of RAM repeat through the address space. The TIA registers do this as well. In short, you can point the SP register at the TIA registers and then write to the TIA by pushing data onto the stack. This technique was intended by the designers of the Atari 2600. Many registers in the TIA use bit 2 to control the register function. Bit 2 maps to the Z-bit in the ST register, so you can test for a condition and then push the ST onto the stack. The result of the operation will turn the function in the TIA on or off without you needing to look at it. Very efficient.

 

Okay I'll shut up now. Thanks for putting these lessons together Andrew.

 

Regards,

 

ST: Is the

[StanJr]

Wow. I actually understood EVERYTHING Andrew wrote up there. And I'm a buffoon. If I can understand it, anyone can. This is a dangerous thing. If I start understanding this stuff, I may actually begin to think I can program for the 2600. Very scary.

 

I cannot say enough about how great this is. My complete kudos to Andrew. Amazing. I'm actually excited about reading more!

[Susuwatari]

Try not to let it get over your head. While I can understand enough to do a simple graphic and controller demos, trying to program a new game that doesn't look crap takes a lot of work and lot of time.