Re: FS layout docs

From: Jim Brain (
Date: 2007-12-28 04:01:07

B. Degnan wrote:
>> As for the FS, I think it should be supported, but I don't know that 
>> it should be the only one supported.  I think FAT should be supported 
>> as well, for folks who want to mount their CF and then pick it up and 
>> pop it into their PC.
>> However, beyond the use of IDE partition tables, I can;t find a doc 
>> that explains the FS layout.  Without it, it will be very hard to 
>> implement.
> What would the doc(s) be called? Is it possible that there are CBM 
> service docs with this info.  I am not sure what you mean exactly 
> (machine code or schematics).
> Bill
I mean, on the ide64 website, I cannot find a document that explains the 
IDE64 native filesystem format.  I have downloaded the IDEDOS source 
code, but it could take quite a bit of time to reverse engineer the FS 
format from the source.

Thus, without that document explaining the disk format, it will require 
going through the source code to re-implement it.

On a separate note, but to get it on the list, here is an idea for a 
CBM-DOS compatible FS that can handle more than 16MB partitions.

Normally, a 16MB partition maximum size is due to 256 tracks * 256 
sectors * 256 bytes/sector.  Adding more bytes for Tracks or Sectors 
causes much grief and requires changing the physical layout of the 
sectors for directories and T&S linking.

Still, if we treat the initial T&S of the file as a pointer to the VP, 
and the VP has a small BAM that hold just HI words of the T&S, then you 
can use the normal T&S of the sector layout as a new "pointer" to the 
next sector.

The direntry hold an initial T&S of X:Y, where X >1.  To open the file, 
DOS goes to the VP area, where the file BAM is located.  The first 4 
bytes are a reference to the next absolute sector.  The next 4 bytes are 
the starting sector of the file.  DOS then goes there, opens the file, 
records the T&S in the file and loads the data.  If the client requests 
the next sector, the T&S from the first sector is used as a "pointer" to 
the VP BAM to find the next sector.

The disadvantage is that the approach uses 6 bytes per sector (the 2 
bytes in the sector + 4 bytes in the BAM) for linking as opposed to 2 in 
the original DOS.  We can better, using 4 bytes per sector + 2 bytes:

Start as before, going to the first sector, but record 2 bytes in RAM 
for this channel the "pointer" (would start at 0x0000).  When the system 
asks for the next sector, increment the "pointer", dereference that 
location in the VP BAM to get one word of the next T&S and use the 
actual T&S of the current sector to get the other word.  Probably it's 
best to put the HI word in the T&S area, and the low WORD in the VP BAM, 
since you can't use Track 0 (that is used to denote last track and the 
sector indicates the number of valid bytes in the track), but maybe 
there is a way around that.

Obviously, this would not work for truly random access, where the CBM 
client asks for an arbitrary T&S.  But, routines that use the file-based 
DOS routines would work, and a lot of the existing CBM layout should 
continue to work.

Of course, the idea may be totally offbase, but I thought I would throw 
it out in case it helps.


Jim Brain, Brain Innovations                                      (X) 
Dabbling in WWW, Embedded Systems, Old CBM computers, and Good Times! 

       Message was sent through the cbm-hackers mailing list

Archive generated by hypermail pre-2.1.8.