Newsgroups: comp.sys.apple2
Path: news.weeg.uiowa.edu!news.uiowa.edu!hobbes.physics.uiowa.edu!math.ohio-state.edu!wupost!waikato!comp.vuw.ac.nz!actrix.gen.nz!dempson
From: dempson@swell.actrix.gen.nz (David Empson)
Subject: Re: Reply to Question???
Organization: Actrix Information Exchange
Date: Thu, 2 Dec 1993 13:29:05 GMT
Message-ID: <CHEtGI.Jp6@actrix.gen.nz>
References: <754702827.AA01642@drharry.UUCP> <2di4sn$6gr@news.ysu.edu>
Sender: dempson@actrix.gen.nz (David Empson)
Lines: 63

In article <2di4sn$6gr@news.ysu.edu> ag471@yfn.ysu.edu (Eric S. Ford) writes:
> 
> Any block device having its own ROM is addressed, by ProDOS, with a
> 'block read' request and the device executes and returns the data.
> ProDos doesn't need any format info for such devices.  For disks, in
> particular the 5.25 disks, there is a built-in driver in ProDos which
> responds to the 'block read' request.

Yes, and it is only used for 5.25" drives.  ProDOS-8 also has a
built-in driver for the /RAM disk that occupies the auxiliary 64k
memory in a 128k IIe, IIc or a IIgs.

> I believe the 3.5 drives (particularly the UniDisk 3.5) has onboard
> ROM and is accessed by 'block read'.

Not directly.  This is how it works:

ProDOS checks the ROM in the $Cn00-$CnFF space of each slot to locate
disk devices.  It identifies a disk by checking for particular ID
bytes near the start of the ROM.  The same ID bytes are used by the
Apple II's autostart boot code to locate a disk device to boot from.

When a device which looks like a disk drive is located, ProDOS checks
the byte at $CnFF.  If it contains a zero, then this is a 5.25" drive,
and ProDOS uses its built-in driver.  If it contains $FF, then it is
an old 13-sector disk controller, which isn't supported by ProDOS.

Any other value indicates that this is a ProDOS-aware device with a
ROM-based driver.  The byte at $CnFF specifies the location at which
the driver starts (on the $Cn page).  The bytes at $CnFC-$CnFE provide
additional information about the device, such as the number of drives,
whether it is read only or read/write, and (optionally) the disk size.

Whenever ProDOS needs to do a block access to the drive, it calls this
device driver.  ProDOS tells the driver whether it wants to do a
STATUS, READ, WRITE or FORMAT operation, and specifies a unit number,
memory location, and block number.  The gory details are handled by
the ROM-based driver, which returns an error code to ProDOS when it
has finished the operation.


In the case of a UniDisk 3.5, the above code is on the 3.5" drive
interface card (UniDisk 3.5 Interface, SuperDrive Interface, or
IIc/IIc+/IIgs disk port).  The code in the interface card translates
the ProDOS call into a "SmartPort" call, and passes it to the UniDisk
to be processed.

Other types of 3.5" drive (the Apple 3.5 Drive and the SuperDrive) do
not contain a microprocessor.  The data is read or written directly by
the computer, under control of the interface card.

In either case, ProDOS is unaware of how the block is read or written
- all it knows is that it asks for a block, and it gets given one (or
an error).


There are some changes to this mechanism for ProDOS-8 2.0 and later,
if a SmartPort device is involved (i.e. RAM card, SCSI card, 3.5"
drive interface card, PC Transporter, and probably a few others).
-- 
David Empson                                                               
dempson@swell.actrix.gen.nz                                                
Snail mail: P.O. Box 27-103, Wellington, New Zealand