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 <firstname.lastname@example.org> 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 listReceived on 2016-12-20 16:00:02
Archive generated by hypermail 2.2.0.