Re: How to write to DOS 3.3 from IIGS

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

In article <DJyHq6.CBH@actrix.gen.nz> dempson@atlantis.actrix.gen.nz (David
Empson) writes:
>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.

The problem with this is that moving the head to a different track on
the disk can be *slow*...we run into the danger of kicking out the cached
data prematurely due to head movement delay.

The solution to this is probably to use the heartbeat interrupt for the
timing instead of the system clock.  Interrupts will be disabled during
most disk accesses, so the tick counter won't update during them.

But this has problems of its own:  a program that breaks The Rules by
locking out interrupts for long periods of time could wreak major havok
on the disk.


Actually, according to the manual, the 5.25-inch driver already does
something like this--if the disk hasn't been accessed in over a second,
it reports a disk-switched error to the FST.  I don't know whether it
uses the tick counter or the system clock to do this.

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

Exactly.  Caching support is always handled by the driver.  The FST can
request it by setting a flag in the driver parameter list.

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

Most DOS 3.3 routines handle file types by asking the file manager for
one particular file type (for example, BLOAD always asks for a file of
type $04).  The comparison is done by chopping off the high bit of the
file type (the "locked" bit) and using a CMP instruction on what's left.
So there's no problem here.

The CATALOG command figures out file types by counting bit-shift
instructions.  I don't remember whether it keeps going until the first 1
bit is shifted out, or the last 1 bit, but in either case the result is
that a more-than-one-bit file type will print as one of the existing types.
Other than that, I don't see any problems.

I've always wondered if this is what the DOS 3.3 FST ERS was referring
to when it mentioned a file type "E"?

               - Neil Parker
-- 
Neil Parker, nparker@{cie-2,cie}.uoregon.edu, http://cie-2.uoregon.edu/~nparker

     "Evolution is vastly overrated."  -- Ambassador Delenn, _Babylon_5_