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 3
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 fixed. E.g.


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 program.
- 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 time.
- Searching for a single byte is faster. (But not so the user would notice.)

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
the search.

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 a
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.

Alex Herbert

Current Thread