Re: BASIC OS for the PC

linked-list filesystems like FAT are great in that they allow full sectors
to be used for data.  They also make it easier to seek within a file- even
though FAT doesnt support reverse search, it's relatively trivial to find a
specific position within a file no matter the current position.

Another method would be to maintain a BAM as well as a linked list on a
per-file basis.  This would be helpful in that sparse files could be
possible, which would be great when dealing with random access;  the middle
of a file won't have to be created to place a record near the end, and the
whole file wouldn't even need to be allocated.

Have a look at other 8-bit systems and how they handled their filesystems-
apples had an interesting way of doing filesystems without sector linking
in their original DOS release, using the link list method I mentioned.
Their later DOS expanded on that by increasing the linked lists to a tree
format (a linked list of linked lists), that works remarkably well even at
1MHz.  It's a big shame what they did with filename limtations though.
That however is a directory format issue; I really like their metadata
format. :)


On Tue, Dec 20, 2016 at 8:37 AM, Michał Pleban <lists@michau.name> wrote:

> Hello!
>
> Baltissen, GJPAA (Ruud) wrote:
>
> > So far I developed my own file system (FS), but one based on Commodore's
> > one with BAM and linking bytes in every disk sector. I added my own
> > things like a time stamp and not using two bytes as link but four to
> > overcome the 16 MB limit of Commodore's two-bytes link system.
>
> Two things which are quite annoying in that kind of filesystem:
>
> * The sectors not hold odd number of bytes - in case of Commodore, 254
> instead of 256.
>
> * It is difficult to implement file seek operation - you need to read
> every sector in a file up to the desired location to seek (unless you
> implement more sophisticated moechanisms like REL files).
>
> For these reasons, I think FAT is much better filesystem.
>
> > All my old IBM PC/XTs have at least 256 KB of RAM so I decided not to
> > limit myself to 64 KB (or less) as the C64 does but to use the RAM more
> > in the way the C128 or a CBM-II does: 64 KB for the program and 64 KB
> > for the data. The next step in the future is evident: using more than 64
> > KB for both parts of course. The length of variables won't be limited to
> > just two characters and I think 16 chars is reasonable.
>
> You can do the same as the CBM-II 256: first 64 kB bank for the program,
> second for string variables, third for numeric variables, and fourth for
> arrays.
>
> > Commodore stores variables in programs by storing the complete name.
> > Another idea I have is to replace the name by three bytes: one token and
> > two bytes. These two bytes point directly to the data.
>
> And what happens when a variable gets deleted? Is there a garbage
> collection in the variable area? If yes, then the addresses of the
> variables after the deleted one will be changed. You will then need to
> change these addresses in the program code as well. Looks complicated.
>
> > I also have been playing with my own DOS. The look and feel should be
> > like MSDOS so I won't alienate people right from the start. But other
> > things will be completely different. I assume that you are all familiar
> > with the DOS commands DIR, TIME and DATE. In MSDOS these commands are
> > incorporated in COMMAND.COM. In my case they are separate programs like
> > DEBUG and CHKDSK.
>
> Well then, don't forget things like DEL, REN, TYPE and so on - they are
> quite useful too ;-)
>
> Regards,
> Michau.
>
>        Message was sent through the cbm-hackers mailing list
>


       Message was sent through the cbm-hackers mailing list