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.
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.
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.
Ciao, Eckhard Stolberg
