Subject: Re: [stella] AtariVox EEPROM file format|
From: "Eckhard Stolberg" <Eckhard_Stolberg@xxxxxx>
Date: Sun, 28 Nov 2004 15:04:28 +0100
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.