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