[Coco] FAT vs. FAT

[Joel Ewy]

Willard Goosey wrote:
>> Date: Mon, 29 Jan 2007 11:22:49 -0600
>> From: Joel Ewy <jcewy at swbell.net>
>>     
>> The whole thing would be simplified if I could just write individual
>> files on a DOS formatted floppy on the PC and read them on the CoCo,
>> or vice-versa.
>>
>>     
> os9.exe & the toc/fromc package under DOS, the pcdos program under
> NitrOS9.  Toolshed + fdutils under Linux.
>
>   
It's not that I can't figure out how to do it.  I'd just like to spend
less time fiddling with it.  And conceptually I like the idea of trying
to treat CoCo FAT and DOS FAT as two special cases of a generalized FAT
system.
> You're running Windoze?  Sorry, Bill Gates doesn't want you to go
> there today.
>
>   
And Ubuntu Linux, and Xubuntu Linux, (x86 and PPC) and Damn Small Linux,
And RedHat 8.1, and MacOS 6-9, and Debian m68K, And Amiga OS 1.3 and
2.04, and RS-DOS, and NitrOS-9, and OS-9 68k.  And that's just the ones
that are set up and running.  I don't use my Apple 2cs very much, or my
2GSes, or my Commodore 64 or 128, or the Kaypro, or the Osborne, or the
Morrow, not to mention the TI/99 or the Timex/Sinclair 1000.  So I'm not
really dependent on Winders.  But if I didn't keep it around, how would
I play Civ III and Il-2 Sturmovik?  Not sure Wine's quite up to that yet.
>> Ok, so I know that there are similarities, and significant differences
>> between the DECB FAT file structure and the MS-DOS FAT file structure. 
>> 256 vs. 512 byte sectors is one difference.  Numbers of sectors per
>> track, and tracks per disk, and sectors per allocation unit, et cetera. 
>>     
>
> ...number of bits/FAT entry, number of FATs, which track they're
> stored on...
>
>   
>> My guess is that the main challenge for doing such a thing on the CoCo
>> would be ensuring that there is sufficient RAM for the data structures
>> needed to implement a more generalized FAT system, and more importantly,
>> wedging those data structures into BASIC's not-so-easily modified memory
>> map.
>>     
>
> Muck with the DECB filesystem and you'll break every program that does
> its own manipulations on the disk... Which is probably most DECB
> programs because DECB's so limited in what it can do itself.
>
>   
I'm not talking about changing the DECB filesystem, but changing the
DECB filesystem code -- which, as you point out, most programs ignore
anyway -- to be capable of accessing a superset of the FAT system it now
understands.  If you leave the jump table unmolested, even the programs
that currently do use DECB to access the disk should still work, when
working with ordinary CoCo disks.  Now, it may well not be feasible to
cram all this extra code in there...
>> In OS-9 a more generalized FAT
>> file manager that could also handle both CoCo FAT and MS-DOS disks would
>> be much easier to implement, I think, at least in that you don't have to
>> worry about stepping on BASIC's data structures.
>>
>>     
> There are, however, fairly strict limits on the size of an OS-9
> kernel.
>
>   
That's a serious concern.  But you could always have a boot disk for
doing file transfers, for when you know you're going to be doing it a
lot, and then a file with msd and some device descriptors merged
together that you could load in a pinch for those unexpected file
transfer chores.
>> Thoughts, ideas? (aside from "Get DriveWire".  :)  One of these days I
>> will.)
>>     
>
> As someone who's spent most of the day trying to get a computer to
> read just one foreign disk format.... good luck.  
>
> I suggest you start by digging up the technical docs on the DOS FAT.
> Once you grok it, then you can start coding.
>
> Willard
>