Re: How to write to DOS 3.3 from IIGS

[dempson@atlantis.actrix.gen.nz (David Empson)]

In article <4b7rmj$p9@acme.freenet.columbus.oh.us>,
Dave Althoff <dalloff@freenet.columbus.oh.us> wrote:
> 
> 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.

The read-only issue is mainly because Apple wanted a migration tool,
but don't want to support DOS 3.3 any more.  It would have also been
too hard to reasonably support GS/OS features such as forked files,
file types, subdirectories, etc.  The Pascal FST is read-only for
similar reasons.

The lack of speed is mainly due to the lack of ProDOS-style directory
information being stored in one place.  To get information about a
file, the DOS 3.3 FST has to read the catalog entry, the track/sector
list, and the first sector of binary and Applesoft files (to get the
file size and auxiliary type/load address for B files).  T files are
probably worse - the file size is not stored anywhere.

This is most obvious in Finder: when opening a DOS 3.3 disk icon, the
head can be heard seeking back and forth all over the disk, collecting
information about all of the files.  The same probably applies when
trying to do a catalog from a shell or when getting a list of files in
a standard file dialog.

If you just open a file directly (by name from within an application),
it should be reasonably quick.

There could also be delays due to the Apple 5.25 driver, which is
pretty 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.

The DOS 3.3 FST doesn't use block translation.  The AppleDisk5.25
driver supports either ProDOS block mapping or DOS 3.3 sector mapping
(possibly needing a remapping table in the FST to handle software
interleave, like RWTS in DOS 3.3).

> 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.

It would be a better idea to use one of the "unused" file types (the
second 'B' or 'A', perhaps).  A special file structure would be
needed, with the actual file type and auxiliary type stored within the
file.

I think it is mainly a matter of different philosophies.

Apple appears to have decided that a read/write FST should only be
created in situations where the underlying differences in the file
systems are not sufficient to cause confusion to the naive user - the
user should be able to do similar operations on any disk, without
being concerned about the file system.

It sounds like you want something more like a special purpose FST,
which only provides limited functionality (from GS/OS's point of
view).  Such an FST could be used with specially written programs, but
some programs might not be able to handle it.

For example, given a DOS 3.3 FST that didn't bother with collecting
directory information from all over the disk, some programs would fail
to work with the FST if they relied on the file size and auxiliary type
being returned by a GetFileInfo call.

> Just a thought.  Heck, if I knew what I was doing under GS/OS and had the
> time, I might try it myself...

There is nothing stopping you from doing sector-level access to a disk
with DRead and DWrite calls.  Writing a new FST is a harder task,
especially because there is no documentation on how they work or tie
into the GS/OS "kernel".
-- 
David Empson
dempson@actrix.gen.nz
Snail mail: P.O. Box 27-103, Wellington, New Zealand