Sudoku possible?
Entry posted by Jacob Rose
425 views
Someone asked if Sudoku was available for the 2600.
is there a sudoku game for the atari 2600.
I hadn't heard of one, so, wondering if it's feasible at all...
Memory: Sudoku only uses digits 1-9, plus the blank. Unfortunately, that's two too many to make the memory required really small - if it were 1-7 plus blank it would only require 4 bits to store, so you could represent the digits as nybbles and maybe even load the graphics based on the unique pair of digits. Sadly, representing 10 digits requires 5 bits, so it's probably not worthwhile to use anything less than a byte to represent each. 81/128 bytes of RAM down the drain, but that's not the end of the world unless we have to do it twice...
Graphics: Sudoku is a 9x9 grid of digits. Each digit can be drawn in as few as three pixels across by five down. With a one-pixel gap between digits (i.e. four pixels for 8 of the 9 digits, and 3 for the last one), that's a total of 35 pixels, 12 fewer than the largest graphic possible, so you should be able to add six more and display the lines between the 3x3 regions of the larger grid, with space on both sides (total of 41 pixels). Vertically, if you have one pixel's space between rows and draw lines between 3x3 regions, that's 8 * 6 + 5 + 6 = 59 scanlines. So, it should be possible to write a kernel that displays such a graphic.
The display kernel has to pull in the numbers from memory at the same time they're being displayed, which would be the real trick. We'd need to interlace the display to do that, if we could prepare an entire row in one scanline's worth of processing. 9! is 362880, so there is probably no way to leverage the fact that no number can be repeated in any given row in Sudoku...if we only had a 1MB ROM! 
Maybe we could divide the symbols into an upper and lower set, and store the "case" in one nybble, and the subset in the other, so that we could pick from 2^9 (81) kernels, each of which was specific for a given set of "up" and "down" digit subsets (i.e., blank-7 and 8-9 plus any extra characters we'd like to have, like a cursor for instance), to allow us to load pairs of digits simultaneously (and only requiring 82 bytes instead of 81 if we only used nybbles instead of using just one bit). Then picking the right kernel becomes a task to do when we're not drawing anything (which would be a lot of the time). We'd have no problem buffering each row's kernel offset for just 9 rows, but after jumping to it, would we be able to buffer the 41-bit map for the next line's VDEL sprite image?
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
10 Comments
Recommended Comments