> >By using 6 bits per character and two high bits to terminate the
> filename,
> >you could free up two bytes.
>
> But using the system we are proposing, if situation comes up where it's
> critical that a program get two extra bytes (which I think is very
> unlikely), you do have the option of shortening the program filename
> length
> to get those bytes.
Actually... it's very VERY unlikely that the filename will occupy space
that's needed for other save data. If the filename is to be stored in the
Atari's RAM, then that's X bytes of RAM you don't have for other data.
> >Also, I don't think 4 characters is too limiting for users. If you
> >consider input and display challenges not to mention RAM requirements, it
> >may be more reasonable. I can see two-character initials plus
> >two-character version number being "easy enough" to remember. But that's
> >just me. :)
>
> I think it really needs to have 8. People using my music program could
> realistically end up storing a lot of music files on there. It will be
> important to have the ability to name them descriptively.
>
> -paul
It looks like the proposed standard file size is 128 bytes. If you store
the filename at the beginning (or end) of the Atari's RAM, then the save
function could simply iterate through and save all 128 bytes of RAM... short
and sweet. The loader could then read only the chunk(s) it needs or even
the entire RAM state (as long as the loader itself doesn't require a RAM
counter or some such).
-Lee
