Re: [stella] AtariVox EEPROM file format
Subject: Re: [stella] AtariVox EEPROM file format|
From: "Alex Herbert" <herbs64@xxxxxxxxxxx>
Date: Sun, 28 Nov 2004 04:26:28 -0000
Other systems that Alex suggested are: a DOS-like filename with the extra
byte ascii sequence that indicates the file type.
I suggested adding 4 characters to the filename (3 bytes more than using a
type byte). Seaching would be easier/faster if the type prefixes the
user-definable part of the filename rather than sticking it on the end like
DOS. The length of the type part of the filename would not have to be
I prefer text to codes because:
- No list of codes has to be maintained.
- The programmer doesn't have to bother getting a code allocated for his
- It's human readable - memory management code can display the file types
without needing to decode them.
- With codes, if memory management software is to display file types in a
meaningful way, it would have to include some sort of definitions list and
would have to be updated as new codes are defined.
- 8-bit codes limit the number of file types to 255 - text allows more.
The advantage of type codes over text:
- 8 char filename + 1 byte type code = 119 bytes of block free for data. 12
character filename = 116 bytes free for data.
- Searching for a text file type requires a few instructions more than
searching for a single byte. (Plus a few bytes for the search string.)
- Comparing text takes a variable amount of time (depending on how many
characters match) whereas checking a single byte will always take the same
- Searching for a single byte is faster. (But not so the user would
Or using just an 8 byte filename, but using the high 1 or 2 bits as a file
type indicator. This saves a byte of NVRAM, but complicates and lengthens
I suggested this after you said that you'd rather leave more space for data
rather than add 4 characters to the filename. I was pointing out that there
are unused bits in the filename which could be used rather than wasting a
byte for the file type code. :-P
The other issue is: should programs be able to delete other program's file
types? Alex thinks they should, but I think they shouldn't. I think that
there should be a 4k program (that can run on the Supercharger) that can
maintain the memory and delete/move/etc files. But not everyone may have
supercharger. Yet I don't really want to have to use extra space in my
program to include the ability to delete other program's files.
Delete and/or overwrite files from other programs. All the program needs to
do is allow the user to save to any block.
There is no need for a separate file manager program/cartridge. There is no
need to quit the current program and lose your data just to run the file
manager because the memory is full.