> Okay, I'm wowed. As a newbie to all of this, I assumed that any
> compression
> would be futile because it would take too long. I guess I still don't
> understand why you wouldn't allow a cartridge to go to 8k (or even 32k),
> though? Isn't 4k more of an arbitrary limit, nowadays?
I really like the answers so far. Really though, when you ask why stay
under 4K, I ask why even bother with Stella programming at all? Everything
about the Atari 2600 is simply intriguing to me. The fact that it has no
video memory (unless you count the 39 bits of pixel data in the playfield,
ball, sprites, and missiles combined) still blows my mind. And building
something that actually works with the primitive hardware is just such a
cool way to spend my evenings. If I wanted to work without these
constraints, I wouldn't be coding on the Atari. It's just super fun. :)
As far as compression... Well, the compression of data *is* a relatively
lengthy process. With huffman compression you have to basically "inventory"
all of your source data, then create a lookup table (actually a huffman
tree) using that inventory, then build the compressed data using the huffman
tree. Fortunately, that all happens using some tool _outside_ the game ROM.
Decompression is a lot faster and is what needs to be coded into the game
proper. The decompression routine scans through the compressed data which
causes a pointer to jump around the huffman tree until it finds the
corresponding uncompressed data.
The following page builds a visual huffman tree, illustrating how frequent
characters are represented by fewer bits than infrequent ones. It also has
a couple of links to really descriptive articles about huffman encoding.
http://www.ioyu.com/io/javascript/huffman.asp
Ciao!
-Lee
