In article <dmanzer-0209961351500001@ts107.vcr.wis.net> dmanzer@wimsey.com
(War Lib'y Canada) writes:
>I'm working on a custom (ie, low-cost) PC-based file server for
>Apple II. (Details for the project were posted here this
>spring, with reference to ProDos).
>
>To make this work with DOS 3.3 I want to patch RWTS (read/write
>track/sector), using some of the unused space inside DOS 3.3
>commonly used for patches. There would be one config byte
>allocated such that Bit Number = Slot Number; 0 = Disk ][ card,
>1 = custom H/D card.
>
>Then when RWTS is called it jumps to the patch, which determines
>if a floppy disk or the hard drive is being addressed. For a
>floppy, control returns to RWTS as normal; H/D access uses a
>special entry point in the custom card's firmware, passing the
>addressed sector as a parameter.
>
>Does this seem like a reasonable approach? Any comments (or, even
>better, any hard info?) I'm using Don Worth's _Beneath Apple DOS_
>which is helpful. I also need to deal with write protect, either
>by disabling this in DOS or by controlling it from the IBM (I'm
>using a parallel printer port on that end).
Sounds reasonable enough. I've seen at least one "slinky"-style memory
expansion card that does something similar--when it detects DOS 3.3, it
sticks a JMP to its own firmware at $BD00 (the 48K RWTS entry point). Then,
if it discovers that the RWTS call wasn't meant for it, it passes control
back to RWTS.
If you're going to patch DOS 3.3, make sure you have the latest edition of
_Beneath_Apple_DOS_. Some of the areas listed as "unused" in the first
edition were later used by Apple in their ongoing desperate attempts to fix
the notorious APPEND bug. (This isn't a problem if you're using the
original DOS 3.3 System Master with the white Diskware label, but it will
be if you're using the newer system master with the brownish-grey lined
label.)
One approach that seems to have been popular with DOS 3.3 patchers is to
disable the INIT command, which frees up vast expanses of space inside
RWTS. But if you disable or replace INIT, beware--INIT or whatever you
replace it with *must* be marked as being able to create new files (even if
the command is disabled, it's create-new-files bit must still be set).
- 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 | )