Transcription

Your support is greatly appreciated! https://www.patreon.com/8blit

Welcome to 8Blit a channel covering all the tips tricks and everything in between for programming your own games for the Atari 2600 from 1977. Every great game needs precise timing and creativity to make the most of the system’s Hardware pushing it to its limits. This is practically a requirement for games on the Atari 2600 given the scarcity of resources you need to exploit all the resources you can just to draw a single frame. In this episode we talk about kernels just not the kind you top with butter. That’s all coming up on this episode of 8-Blit

If you’re ever told to be home when the street lights came on you just might like this channel. We explore the technology and history of arguably the most iconic game console ever made. It’s a flashback to when things were simple, wall-to-wall shag carpeting was a thing, and your TV would crackle life with a surge of electricity eventually settling into a constant hum… and your friends would come by to play Atari.

Click on the Subscribe button to join the community stay up to date with new videos and get access to tutorials and a ton of code examples. If you’d like to help out with producing more videos capturing the Intrepid Spirit of Atari from the 70s right through the 80s then please consider become a patron. Every little bit helps to keep us creating more great videos. More information on that in the video description.

So what exactly is a kernel? At its core a kernel is really just that the core of something. Something to which everything else grows. Like a seed it’s often the heart of the operating system running low-level code that interfaces directly with the memory CPU disks and other Hardware. Windows Linux and even Commodore starting, with their pet in 1977 used the term to describe the nucleus of their operating system. I think the first use of the term was with the rc4000 multi-programming system from 1969. If you know more about this I’d love to hear about it in the comments below. In the context of the Atari 2600 we often refer to the very inner loop of our games as the kernel, This is where we utilize the TIA, chip or television interface adapter, to draw each frame one scan line at a time, one machine cycle at a time, placing our player missile and ball Graphics as well as our play field, and often changing the background color as well to add a sense of texture and depth. I heard that Joe decuir, one of the designers of the classic game combat for the Atari 2600 called the kernel VOUT. I haven’t been able to find him mentioning that in his own words so if you happen to know which interview this was feel free to share it with the class. I’d love to watch it.

The kernel draws what we see on the screen. We’ve covered the different timings of the screen a couple times before so we’ll skim past this a little to focus mainly on the horizontal blank and play field portions this time. One scan line is only 76 machine cycles Long and can be thought of as two intervals. Horizontal blank is the interval when the Electron Beam is redirected from the end of one scan line to the beginning of the next. This takes about 22.6 machine Cycles. The play field lasts for the remaining 53.3 machine Cycles. This gives us our total 76 machine Cycles, give or take a rounding error. This means that we have only 22 machine Cycles to prepare our graphic registers before the Electron Beam begins drawing the screen again. If we want to draw the first four play field pixels you need to store the bits into the pf0 register before the beam starts to draw them since a store instruction can take three or more machine Cycles to complete. That means we actually have to write to the pf0 register on machine cycle 19. same goes for pf1 and pf2, you need to prepare those registers before they are drawn as well. If we use a mirrored play field we have the next 36 machine Cycles to perform other tasks like preparing the graphic registers for the next scan line. If we used an asymmetrical play field then we need to repeat what we did for the first half of the screen all over again. We have very few machine Cycles to do anything else and the timing is very tight. This makes the kernel the most important part of your game it will determine what you can and cannot do in your game depending on what you can fit into each scan line.

Well we’ve been focusing a lot on the scan line, a kernel doesn’t have to be limited to just one in fact you can refer to a kernel that only uses one scan line as a one-line kernel or 1LK. What this means is that for every inner loop of your kernel it’s going to draw a single scan line. This will usually give you the highest resolution for both player and play field Graphics but it doesn’t leave much room for anything else. You’ll have to scrimp and save your cycles and limit features of your play field. Perhaps limit your player Graphics to a single color and limit the number of objects on a single scan line. Switching to a two-line kernel however frees up about 76 machine Cycles at the expense of some resolution. Either your player Graphics or your play field, or both. Since the player and play field Graphics both keep repeating the previous scanlines Graphics unless you change them the resolution will be more chunky. One example of a two-line kernel is to draw the player one graphic and then prepare the registers for the player zero graphic for the next scan line. Then on the second scan line we draw player 0 as well as the Playfield graphics. Let’s have a look at some code to see how that might look.

In this kernel we’re going to use PF count to track which scan line we’re on and use the X register to track which play field segment we’re drawing. This will be used to load the shape from our Playfield data tables. We start off by checking if the first two bits of our scan line counter PF count is 1-1. This will occur every fourth scan line. We do this by and’ing PF count with the binary three. If the result is zero that means it’s been four scan lines so we increase the X register to move on to the next play field segment. If it’s not zero then it will continue drawing the current segment. We then load the player zero graphic and its color, then wait for wsync to move on to the beginning of the next scan line. This is the end of the first line of our two-line kernel and we’ve only used 45 machine cycles. It may seem like we still have a lot more Cycles to use but this is only the first iteration in our kernel Loop. The second time around we’ll use 59 machine Cycles because the first line starts again before our Loop is complete for the second line. We start right after wsync so we’ll store the graphic into the graphic player zero and set the color so it’s ready for when the TIA starts drawing it to the screen. Then we load and store the Playfield segments directly into the Playfield registers. Finally we load our player one graphic and its color, then wait for the W sync to move on to the beginning of the next scan line. This ends our second line of our two-line kernel where we’ve used up 56 machine Cycles before we move back to the first line. This time the first line starts by storing the graphic player one register and setting the player one color. We end our Loop by decrementing the scan line count of PF count and then jumping back up to the start of our Loop. This adds 16 machine Cycles to the 45 cycles for the rest of the first line in the kernel. This gives us enough time to draw our Playfield along with two little robots with multiple colors

One thing to note however, because we’re drawing our two robots each on a different scan line they don’t line up if we move them close together. Luckily the designers of the Atari 2600 gave us a handy feature that allows us to delay drawing one player graphic until the other player graphic is drawn. In our case we delay the drawing of player 0 until player one is drawn. We do this by setting D0 of The VDEL register. Code examples of a one-line kernel and this two-line kernel can be found on our GitHub. A link is available in the video description.

While you can choose to implement a one line two line or three line kernel or more. You’re not limited to just that one kernel for your entire frame. Many games will use multiple kernels for different sections of the frame. For example you can use one kernel for the timer or score of the top of your frame then another for your energy or life meter. Your entire play field can be encapsulated within a kernel or you can split that up into more kernels as well. Each responsible for drawing a different portion. Then at the bottom of your frame under the play field you can add another for the name of your company or a copyright message. What’s more, all of those kernels can use a different number of scan lines. So while one area has chunkier Graphics another can be higher resolution. If we have a look at Pitfall made by David crane of Activision in 1982 we can identify several different kernels used to build the frame.

When I said several, I’m mean nine unique kernels. Not including the areas of the frame to display the score the lives and time remaining, as well as the animated copyright message at the bottom of the screen.

Let’s start at the top of the screen.

The first kernel draws the leaves branches and the top of the Vine. The second kernel draws another part of the vine and gets other objects positioned on the screen for the next kernel. Which brings us to the third kernel where we draw Harry and the swinging Vine. The fourth kernel draws Harry and the end of the Vine. The fifth draws Harry the top of the holes and the top of the objects on the ground like the logs, snake, and gold. The sixth finishes drawing the bottom of the objects on the ground. The seventh draws the ground and the top of the ladder and Harry climbing down the ladder. The eighth draws Harry the latter and the wall, and lastly the ninth kernel draws Harry, the ladder, the wall, and the Scorpion. It’s all about timing and making the most of the resources we have at hand. Creative use of multiple kernels after drawing only portions of Harry and other objects at a time. Using time from the previous kernel to reposition graphics and preparation for the next. Obviously this is a particularly Advanced kernel but it does go to show that you don’t need to draw everything all at once, and you can craft your frame in different ways to minimize your cycles and maximize your creativity.

If you found the video interesting I’d appreciate it if you’d hit that like button and share this episode. It really helps us out. If you haven’t already done so please consider subscribing to the channel and hit that Bell to make sure you’re notified when a new video comes out. If you’d like to help support the development of the Channel please consider becoming a patron. I’ll link to that in the description as well. Join us on social media. You can connect with us on Instagram, Facebook, and occasionally on Twitter.

That’s all for now, thanks for watching and I’ll catch you later.

Back to top of page