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.
MS/xxxxxxxxx
MSQ/xxxxxxxx
MUSEQ/xxxxxx
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
