Re: How to write to DOS 3.3 from IIGS

[nparker@cie-2.uoregon.edu (Neil Parker)]

My apologies if this article appears twice...I think my news server choked
the first time, but I'm not sure...

In article <4b7rmj$p9@acme.freenet.columbus.oh.us>
dalloff@freenet.columbus.oh.us (Dave Althoff) writes:
>[...munch, crunch, chomp, yum yum...]
>But I have the same problem...on the IIgs, I'm running GS/OS 6.0.1.  And
>the DOS 3.3 FST *stinks*.
>
>a.  It is read-only.
>b.  It is intolerably slow.
>
>Why couldn't a good DOS FST be written?  Ideally, it could even make use
>of a Pronto-DOS style RWTS routine when accessing a 5.25" volume, and save
>that messy block translation stuff for other storage media.

I presume you're referring to this scenario?

     1.  Insert DOS 3.3 disk in 5.25" drive
     2.  Double-click on the Finder's 5.25"-drive icon
     3.  Go to the fridge; fix yourself a snack
     4.  Come back; discover the Finder is still working on opening the window

The problem here isn't an inefficient RWTS.  Even if you had an RWTS ten times
as fast as ProntoDOS, it still wouldn't help much.

The problem is the way DOS 3.3 arranges data on the disk, and the way the
Finder catalogs disks.

The Finder, or any other recent GSOS program, catalogs disks by using
the GSOS call GetDirEntry.  To get the names of all the files in the
directory, you just call GetDirEntry repeatedly (once for each file name)
until it returns an error.

The GetDirEntry call can return all sorts of information about the file,
including the name, the file's size, its type and auxtype, its creation and
modification dates, etc.  The Finder needs to know most of this information
in order to display its directory windows.

But DOS 3.3 disks are not laid out in a way that makes this information easy
to get.  File names and types are stored in the directory, but in order to
find out auxtypes (for those files for which it is defined) and sizes,
GetDirEntry must look in the file's data.  In order to do this, it must
move the drive head away from the catalog track to the track containing the
file's first track/sector list, and then to the file's first data sector
(which might possibly require moving the head again).  Then it must go back
to the catalog track again for the next directory entry, and the whole
process starts all over again.

All that head moving is what causes the repeated "shick, shick" sounds that
you hear while the Finder is grinding away on the DOS 3.3 disk, and what is
responsible for most of the waiting time.  The head movement speed is a
fixed characteristic of the disk drive hardware...even the most efficient
RWTS routine in the world can't make the head move any faster.

The only reasonable (?) way I can think of to speed up the process is to
read the whole disk image (or at least the catalog track) into memory as
soon as the disk is mounted, and refer to the memory copy rather than the
disk copy while cataloging the disk.

But even this probably won't work.  It's not hard to think up scenarios in
which keeping an image of the catalog in memory would cause GetDirEntry to
return wrong (possibly dangerously wrong) information.  The reason is the
same as the reason why the 5.25-inch disk driver doesn't support caching...
it all boils down to the fact that 5.25-inch disk drives have no way to notify
the operating system that a disk has been removed from the drive and
replaced by a different disk.

>                                                             The only real
>problem I can think of is the existence of arbitrary filetypes and forked
>files under GS/OS.  My solution is to write all arbitrary filetypes as
>type B (it isn't brain surgery to change them again...), and possibly
>provide an option for forked files.  Since the primary application I can
>see for such a program is to move TXT, BAS, and BIN files around, the
>easiest solution would be to ignore any attached resources.  Or save them
>in a second file (perhaps append a ".R" to the filename) of type S.

No, file type "S" should not be used for resource forks.  If a DOS 3.3
FST is to support resource forks (and the advisability of this is debatable),
the resource fork should probably use the same file type as the
corresponing data fork, or a whole new file type should be invented.
Remember...there are DOS 3.3 disks out there that use file type "S" for
purposes other than GSOS resource forks, and we don't want the Resource
Manager to go crazy when it sees one of these.

                - Neil Parker
-- 
Neil Parker                       | No cute quote, no cute ASCII art, no cute
nparker@cie-2.uoregon.edu         | disclaimer, no deposit, no return....
nparker@cie.uoregon.edu           | (This space intentionally left blank:
http://cie-2.uoregon.edu/~nparker |                                           )