Re: Apple II IDE interface

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

Stephane Guillard <stephane.guillard@steria.com> wrote:

> > A ProDOS block driver (preferably in ROM on the card, to avoid having to
> > load any patches) would allow the card to work automatically with
> > ProDOS-8, GS/OS and Apple II Pascal 1.3, with the catch that you are
> > limited to two 32 MB partitions, as you mentioned.
> 
> You're right, but...
> - I want to be able to R/W the HD in a PC (to make CD backups of my
> 42195742592431592354 floppies around)

OK, but I was thinking of more widespread applications, where the drive
is reformatted as ProDOS.  If you are only going to access FAT-formatted
drives, then there isn't any point writing a ProDOS driver, but a
SmartPort driver would still be useful (and it requires that the card
also provide a ProDOS driver, though it might not have to do anything).

Even a GS/OS driver would be of limited use for an MS-DOS formatted hard
drive, because the GS/OS MS-DOS FST is rather primitive.  It might allow
the drive to work with Peter Watson's command line tools (and associated
NDA).

For the sort of application you are proposing, the most appropriate
solution is a dedicated application which accesses the hardware directly
(or perhaps through an appropriate firmware driver provided by the
card).

> - having a ProDOS (or UCSD or CP/M) driver is not contradictory to my
> approach, each of them will be stored in partitions, the driver will
> do the mappings.

Having the driver in a partition is no use unless you have firmware on
the card which loads it, but you can't load it, because there isn't
anywhere (in ProDOS and DOS 3.3, at least) where you can load a driver
without causing compatibility problems.

The whole reason for ProDOS having drivers in ROM on the I/O card is
that it doesn't get in the way of memory allocation by applications.

GS/OS already has a mechanism for loading disk-based drivers, so there
is no need to invent a new one.  (If you want to boot from a particular
card, it must provide a ProDOS and/or SmartPort block driver, and it
requries a boot partition with the ProDOS file system.)

I don't know how CP/M might work, but Pascal does support drivers loaded
from a boot floppy.  You would need a ProDOS driver in firmware to
support booting Pascal from the IDE card.

Running anything which has to be loaded into RAM will severely limit
compatibility for DOS 3.3 and ProDOS.

> This could be done at least w/ two approaches :
> - having a single FAT partition, accessed at the same time either on a
> per-file basis, or on an emulated volume basis (emulated volume = FAT
> file containing a virtual volume, which could be ProDOS, CPM or
> DOS3.3)
> - having a partition type for flat file access FAT partitions, another
> type for CP/M, another type for DOS3.3 virtual floppies etc. BUT
> sticking with MBR partition scheme, and relying on FAT inside the
> virtual volume partitions, so that you can still use/edit the contents
> w/ other platforms.

This could be handled through a firmware abstraction layer.

> By the way, what is SmartPort ?

In this context, SmartPort refers to the firmware interface provided by
several I/O cards which supports much more flexibility than the ProDOS
block driver.

The ProDOS driver is limited to two volumes per slot, with a maximum of
32 MB per volume.  (In some cases it is possible to increase the limit
to four volumes per slot.)

A standard SmartPort driver is limited to 127 volumes per slot, with a
maximum of 2^24 blocks (8 GB) per volume, though ProDOS-8 can only
handle 32 MB.  An extended SmartPort driver (only supported on the IIgs)
can support a maximum of 2^32 blocks per volume.

Some examples of cards with SmartPort interfaces:

- Apple IIc and IIgs slot 5 firmware (built in).
- UniDisk 3.5 controller card for the IIe/II+ ("Liron").
- SuperDrive controller card.
- Apple II memory expansion card, and clones such as the RamFactor.
- Apple's SCSI cards.  (The RamFast doesn't have a SmartPort driver.)

In theory, the SmartPort firmware can support character devices as well
as block devices, but I've never encountered one.

The term "SmartPort" also applies to the disk controller port on the IIc
and IIgs (and on the UniDisk 3.5 and SuperDrive cards), and to the
protocol used to communicate with intelligent devices over this port,
such as the UniDisk 3.5.  The firmware interface is independent of the
hardware which shares its name (as demonstrated by the fact that SCSI
cards and memory expansion cards can use the same firmware interface).

> > I suspect that having either a ProDOS driver or a SmartPort driver
> > would require adding some RAM to the card, so the firmware can store
> > information about the partitions detected on the drive(s).
> 
> This can be stored in the II RAM somewhere, isn't it ?

Nope.  There isn't enough RAM available to keep track of significant
amounts of information without breaking compatibility with something.

All of Apple's complex disk controller cards (SCSI, SuperDrive) have a
fair to large amount of RAM on the card to keep track of private data
such as partition tables.

> All DOSes for the Apple do things that way.

ProDOS-8 doesn't know anything about "partitions".  All it knows how to
deal with are numbered volumes.  The only information it retains in
memory for a firwmare driver is the driver entry point, unit number and
four flag bits which are used to identify features supported by the
driver.  (In the case of a card with a SmartPort driver, ProDOS also
keeps track of the mapping between fake unit numbers and the actual
SmartPort unit number.)

Any information about how to map from a unit number to a physical
address on the hard drive must be maintained by the driver, which is in
firmware on the card, and this data is stored in RAM on the card.

The same goes for older hard drive controller cards which supported
multiple volumes for DOS 3.3.  The card itself is responsible for
keeping track of how to map from volume numbers to physical addresses on
the volume.  It cannot keep this information in the computer's main
memory.

Pascal has a little more flexibility, but it will usually operate like
ProDOS.

If CP/M kept track of anything to do with volume mapping, it would have
to be hidden inside the BIOS.  The BDOS doesn't know about anything
other than logical drive numbers (A:, B:, etc).

In the case of GS/OS, the SCSI drivers (which run in RAM) _do_ keep the
partitioning information in main memory.  They can do this because the
IIgs has a memory manager, which allows system software and application
to allocate memory without stepping on each other.  Any such data must
be kept outside banks 0 and 1 (IIe main and auxiliary memory) while
ProDOS-8 is active, since ProDOS-8 application (or ProDOS-8 itself) own
the entire bottom 128K.

> I already use "screeen memory holes" associated to the slot in which the
> board sits to put things like current cylinder, head, sector.

I don't think any disk controller cards use the screen holes for
anything important, because badly behaved applications can and do
overwrite the screen holes.  If the firwmare is depending on the values
being preserved between calls, then it is risking loss of data on
volumes.

They tend to be used for things like operating parameters for serial I/O
and 80-column cards.  If the parameters are lost, it isn't a major
problem - the card just misbehaves, causing a mess on the screen or
interfering with serial I/O.

There is no problem using them for temporary storage for the duration of
an I/O call.