In response, to Eckhard: if we decide to use a DOS-like system with 3
character extensions, personally I'd prefer to just sacrifice 11 bytes in
the ROM to store the filename without splitting bits rather than sacrifice
more bytes in ROM for code to encode/decode it. As I think about it, I
doubt many programs are going to need to store more than 117 bytes
considering there are only 128 bytes in the Atari. Most programs that use
the file system will probably have text routines which generally require
at
least 20 bytes of temp RAM. Plus there's stack, controller handling
variables, generic temp variables, etc.
That's only true, if you always want to store one game state per
EEPROM block. But what if you had a puzzle game with a level
editor for example, where each level is 60 bytes large. Then
the three extra bytes would make the difference between storing
one or two levels per block. Remeber that the AtariVox allows
you to read and write any number of bytes at a time (writing
only within a given 64 byte block).
I like Alex' suggestion about using a variable-length file type
prefix with a terminator byte. But maybe we could make the file
name variable-length too? If we use 7-bit ASCII for the characters,
then we could use a byte with bit 7 set high as the terminator.
Maybe we could use the other 7 bits in that byte as a counter for
the file name length.
If the terminator byte was in the first byte of a block, it would
mean that the block is unused. The minimum size for a file name
would be one byte for the file extension and one byte for the
terminator (with a name counter of 0 characters). A name like that
would be difficult for identifying your game save of course.
But if you wanted to use numbered game saves instead of named ones,
you could have a name with two bytes for the extension, one byte
for the terminator and one or two bytes for the save number.
(Since there are only 128 free blocks, one byte for the number
might be enough, but a two byte hex value in ASCII would be
better for human readability.) Then you could have 123 bytes
for your game save, if you need that many.
If you think a file name with an unlimited length would be
difficult for file handling, we could probably agree on a
maximum length.
Also I think Alex is right about there not being much need
for a seperate maintenance cart. There are only 128 blocks
available, and the file system doesn't support files that
use more than one block. So if you wanted to have a RPG
with a large random world map, you'd have to save it into
several files that you have to find and load seperately
anyway. So moving files around on the AtariVox is not
nessessary. And if the EEPROM is full, your game could
let the user select which block to overwrite by letting him
browse through the file names one at a time.
And I think Richard is working on an adapter that lets you
connect your AtariVox to the serial port on your PC. So you'll
probably be able to manage and backup your AtariVox EEPROM there.
Ciao, Eckhard Stolberg
