Re: [stella] AtariVox EEPROM file format

Subject: Re: [stella] AtariVox EEPROM file format
From: "Lee Fastenau" <stella@xxxxxxxxxxxxxxx>
Date: Tue, 30 Nov 2004 15:04:32 -0700
> > Since only 37 out of 64 possible values are represented in those 6 bits, 
> > you
> > can use the 2 most significant bits to signal the end of a filename or the
> > beginning of the file extension (assuming ext is always 3 characters).
> I think a file-type prefix with a fixed length and position would be
> better, because it makes it easier for a program to find it's own
> saved files.

Good point.

> > Or if an agreed-upon lookup table for common characters can be created, a
> > flavor of Huffman compression can potentially shrink the filenames even
> > more.  Especially since there's elbow room to play with in those 6 bits.
> > The downside, naturally, is more code to de/compress filenames, but
> > someone... perhaps say... Mr. Jentzsch might be able to drum up an
> > uber-tight de/compressor just for this purpose. :)
> Paul doesn't really like compressed file names at all, because
> of the extra ROM and RAM usage that would be required for each
> game.

It is a bit of overhead for only a 2 or 3 byte savings.
> And Huffman encoding would mean that file names with uncommon
> characters would end up being longer. That's not a good thing
> to have in a file system where all files are a fixed 128 bytes
> long. If you can't be sure how much space the file name, that
> the user inputs, is going to take, then you can't really use
> the extra bytes, that you potentially might save, for your data.

That "elbow room" I mentioned earlier should keep characters from being represented by more than 6 bits, so 8.3 filenames could have a definitive maximum byte size.

> Ciao, Eckhard Stolberg

What about a nice compact (not "compressed") 4-character name represented by 24 bits (3 bytes) plus one file type byte for a total of four bytes?  I think 4 characters is plenty to uniquely identify a file.  Simple, small, easy to read, easy to display.  Naturally, we'd need to establish a Stella Filetypes clearinghouse or some sort of governing body to manage the filetypes... all 256 of them. :)

Ah, and in the unlikely event that we run out of filetypes, we could check if the first character of the filename is >36.  If so, then subtract 36 from the character and add 256 to the filetype.  This would give us 512 filetypes.  In fact, the first character could ALWAYS be alpha so that we'll have 512 filetypes available from the get-go...

Or is that getting overly complex again?


Current Thread