potatohead's Blog

In my (limitted) experience 2600 kernels don't have to be time sinks. IIRC for Skeleton I spent a bunch of time trying to figure out how to convert the maze to something a 2600 kernel could display. Then there was some time getting the actual kernel working, i.e. figuring out the timing constraints. Later, I spent time doing some space optimization and squeezing in additional features.

 

For Leprechaun, again I had to spend some time figuring out how to store the level & player data in RAM/ROM so the kernel could efficiently use it. That then leads to actually creating the kernel. Again, I might try to add some optimizations or features, but this one is fairly tight already.

 

But in both cases the kernel is less than half of the story. Coding the rest of the gameplay code for Leprechaun is taking easily several times what the kernel did.

 

Now, for some games kernel related coding may take more time, especially if you are continually adding more features, changing the kernel data structures or optimizing. But I still don't think it's going to take 50% of the time.

 

Now the 7800 doesn't have a display kernel like the 2600, the MARIA GPU handles that part. (Well, there are uses for a psuedo kernel, like reading paddles, but they aren't as complex as a 2600 kernel.) But instead, you have a display list creation kernel, which takes the game data structures and creates the display lists which the MARIA GPU parses into the actual display. But this 7800 kernel doesn't have the timing constraints that a 2600 kernel lives & dies by. No chasing the raster here. So, again, most of the coding time is spent on gameplay logic.

I'll agree with Eric and say that the kernel is probably the trickiest (and most fun!) part of a 2600 game to write, but it usually isn't the biggest time sink. The biggest time sink is all the game logic and other parts.

I'll agree with Eric and say that the kernel is probably the trickiest (and most fun!) part of a 2600 game to write, but it usually isn't the biggest time sink.  The biggest time sink is all the game logic and other parts.

 

Thanks guys!

 

I was kind of thinking outloud --didn't expect an answer really. Glad you both commented. Later when I re-read this stuff, it's going to spark some ideas. In that vein, I find your perspective valuable. It puts options on the table now, that would not have otherwise been discussed. Thanks again!

I'll agree with Eric and say that the kernel is probably the trickiest (and most fun!) part of a 2600 game to write, but it usually isn't the biggest time sink.  The biggest time sink is all the game logic and other parts.

 

Kernels can be hard or easy, quick or slow to write, and rewarding or not, probably in just about any combination. Along with the kernel, some games require a "pre-kernel" which runs each frame and prepares data for the kernel to use. Something like Ms. Pacman, for example, probably uses a pre-kernel to determine which sprites are in which zones and how they should flicker.

 

The real challenge for a 2600 game is often not just designing a kernel that works, but designing a kernel whose data structures can be manipulated with acceptable speed by the game itself. Interestingly, this is where I got tripped up in the first 2600 game I started to write (since abandoned, but I may pick it up sometime). The game was to be an implementation of Columns (similar to Salu's Acid Drop, but better) in which there is a 6x20 grid that fills up with gems. The gems come in six different colors, and getting three or more gems in a row vertically, horizontally, will cause them to disappear; any gems over them will then fall down, possibly triggering further reactions.

 

The kernel itself looks pretty good, especially for a first attempt (the scan line count is way off, because I had no facility for measuring it--this was years before any emulators were on the market). The gems appear with nice color shading and the kernel supports sixteen colors of gems which may be solid or shaded. The plan was to use solid black for non-gems, six colors for gems, and then have "brighter" versions of those colors for exploding gems, and make the remaining three colors show shades of grey, used to further animate the exploding gems. All that's implemented and works great.

 

The problem is that the data is stored sorta goofy. The upper-left gem's color is stored in bits 0, 2, 4, and 6 of address $C0. The gem to its right is stored in bits 1, 3, 5, and 7 of that byte. The next gem is in bits 0, 2, 4, and 6 of address $D4 [i.e. twenty bytes after the first one]. Then bits 1, 3, 5, and 7 of that byte. Then $E8 [bits 0, 2, 4, and 6; then 1, 3, 5, and 7]. The next row starts at $C1, etc.

 

Not the worst way to store things, perhaps, but I was unable to figure any good and fast way to do the checks for adjacent dots being the same color. Perhaps I should revisit that, because I've learned a few tricks since then.