Re: How to write to DOS 3.3 from IIGS

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

In article <4bb4a0$h9g@pith.uoregon.edu>,
Neil Parker <nparker@cie-2.uoregon.edu> wrote:
> 
> 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.

True, but a simple improvent (to the AppleDisk5.25 driver) would be to
allow it to make use of the GS/OS disk caching scheme, even in limited
circumstances.  All that is needed is for each catalog sector to be
cached as it is read (or better still, cache the entire track when it
is first read) and you would significantly reduce the number of seek
operations.

The really major problem with caching a 5.25" disk is that the user
can change it at any time, and GS/OS cannot detect this.

The obvious way of handling this would be to use a timeout: if the
disk hasn't been accessed for at least one second (or even for a
shorter timeout), throw out all of its cache entries.

I'm not sure where this would have to be done - probably in the
AppleDisk5.25 driver itself.  It cannot be put into the DOS 3.3 FST
(even assuming we had access to the source code) because another FST
might try to access the disk, and may get entries cached from the old
disk.

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

The solution used by Apple on MS-DOS disks is quite good - creating a
hidden directory called RESOURCE.FRK and storing the resource forks in
there.

Unfortunately, this isn't an option for DOS 3.3.

I doubt there are any "unused" DOS 3.3 filetypes.  I suggested using
the second "B" and "A" types in my earlier post, but "B" has already
been used by the LISA assembler (with a patched DOS to call it "L")
for source files.  I assume "A" has been used somewhere.

What about filetypes with more than one bit set?  The "BARSBAIT" types
are all powers of two ($40 through $01 and $00; bit 7 is the "locked"
flag).  How would the real DOS 3.3 handle multi-bit file type values?
-- 
David Empson
dempson@actrix.gen.nz
Snail mail: P.O. Box 27-103, Wellington, New Zealand