SEWALL@UCONNVM.BITNET (03/24/88)
Re: COPY DISK /W FORMAT - I did find the hardcopy documentation
(I filed it where it's supposed to go; what a strange place to
find it 8-). If I owned a 3.5 inch drive, I would have found
out without asking.
Howcome, a 3.5 can't be formatted track by track as part of the
copy process the way a 5.25 disk can be?
---------------------
Disclaimer: I like my opinions better than my employer's anyway...
(subject to change without notice; void where prohibited)
ARPA: sewall%uconnvm.bitnet@mitvma.mit.edu Murphy A. Sewall
BITNET: SEWALL@UCONNVM School of Business Admin.
UUCP: ...ihnp4!psuvax1!UCONNVM.BITNET!SEWALL University of Connecticutjetzer@studsys.mu.edu (jetzer) (03/24/88)
In article <8803232132.aa28005@SMOKE.BRL.ARPA>, SEWALL@UCONNVM.BITNET writes: > Re: COPY DISK /W FORMAT - I did find the hardcopy documentation [ ... ] > > Howcome, a 3.5 can't be formatted track by track as part of the > copy process the way a 5.25 disk can be? ProDOS was designed to be used with "smart controllers." One thing that makes a controller "smart" is that it has the ability to format a disk that it controls. (There are only 4 functions a controller can do: read, write, format, and status.) In this way, ProDOS can copy *any* size volume, without knowing (or even caring) about how large it is, what kind of media it uses, etc. Furthermore, devices other than Disk ][s can be accessed only by block number, as opposed to track and sector (think about a RAMdisk, which has no tracks or sectors). This is what makes ProDOS device independent. The Disk ][ interface is not smart, in that it can't format by itself. It needs an outside program (the controller is actually part of the ProDOS file) to control the read, write, and status. Since the format code is too large (and infrequently used) to be included as part of ProDOS, it requires a separate program (referred to as 'formatter' or 'builder' in the technical notes) to format. Many programs, when seeing a Disk ][ device type on the global page, will use their own (often non-Apple) formatter to format the 5.25" media. These programs can then format the Disk ][ in any way it wants, since there is only one type of Disk ][ (as far as controlling the device). So to sum it up, the Disk ][ media is formatted while a copy is in progress because it *can* be formatted track by track. The program sees the id byte for a Disk ][, and it *knows* its a Disk ][. Any other type of storage device could be *any* other type of storage device, and can be formatted only by its controller. These disks cannot be accessed by track and sectors, only by block numbers. Even if the disks could be accessed by track and sector, the code needed to format *every type of device* would be prohibitively large, and would defeat the idea of device independence.