Drawing Pixels on 2600 TIA

In the 2600, the TIA is drawing the display in real time by sending signals to the television. There was no frame buffer in the TIA. With an emulator, our situation is slightly different. As I want the TIA emulator to work in several different platforms, a cross-platform way of generating the display is needed. My solution is to simply have a 160 “pixel” raster line that the TIA emulator writes to. Whenever a scan-line is finished, or part way through drawing the scan-line if you are doing some type of stepping through the program, the class managing the display will grab this information and use the TIAColors information to build a display appropriate to the platform that is being rendered.

The figure below shows the logic that the TIA uses to determine which of the four colors to place on a pixel. We start with the background color. This would be the background color at the time that the pixel was drawn. As the color registers can be changed in the middle of rendering a line this can be a distinct color at different points along the scan-line.

The order that things are drawn depends on flags in the CTRLPF register. Normally the play-field is drawn right after the background but if bit 1 of the CTRLPF is set then the play-field and ball will be drawn after the players and missiles. Player 1 and the missile associated with that player is drawn before player 0. So if CTRLPF bit 1 is set the drawing order is background, player and missile 1, player and missile 0, play-field and ball. Otherwise the drawing order is background, play-field and ball , player and missile 1, player and missile 0.

This drawing order determines what the final pixel color will be in cases where multiple display objects overlap a given pixel. The 2600 goes even further by tracking the overlaps and setting a series of collision flags that can be tested to see if there were any collision between display objects when the line was being drawn.

This effectively means that we have six things to potentially draw in any given pixel. Three of these --  the ball, missile 0, and missile 1 – are simply a line so they can be grouped into a common class. The two player sprites are not that much more complicated so while they could be a separate class from the ball and missile, making a more complicated player missile graphics class to handle all five of these display objects makes sense.

This leaves us with the play-field. This is my favorite part of the 2600 rasterizer as it is the closest thing you have to traditional bitmap graphics.