ADFS floppy disk drivers for Perth/Brisbane
===========================================

Objectives
----------

The objective of this project is to produce an enhanced version of the
current ADFS (version 2.06) to include both the old 1772 FDC drivers and new
drivers for the FDC included within the 82C710 Universal Peripheral
Controller.

The new version will retain the existing interface specification to FileCore
and in addition will support the proposed MultiFS formatting subsystem for
use with both the 82C710 driver and the original 1770 driver.

Structure
---------

It is intended to retain in almost unmodified form the existing 1772 drivers
so as to ensure minimum development and debug time.  All global entry points
will test the value of a machine identifier handle, obtained from RiscOS at
initialisation time, and branch either to the 1772 or 82C710 drivers.

The new 82C710 drivers will not share subroutines with the existing drivers
as almost every aspect of device operation is different.  Where similarities
exist the code will be copied, resulting in a larger but faster driver.

The 82C710 FileCore interface will support the following FileCore DiscOps:

  Verify - foreground and background
  Read Sectors - foreground and background
  Write Sectors - foreground and background
  Seek
  Restore
  Step In
  Step Out

The following DiscOps will not be implemented:

  Read track - no functional equivalent, returns with bad command
  Write track - replaced by MultiFS formatting subsystem

All the existing FileCore miscellaneous entries will be supported.  All
current disk formats will be able to be read, however it will not be
possible to generate L format disks reliably.  D and E format disks will be
formatted with some slight differences due to limitations in the controller.
A new 1.6Mbyte new map format will be supported at 500Kbps.  The driver will
allow the controller to be placed into 1Mbps mode, but due to hardware
limitations this mode will be non-functional


Driver Operation
----------------

The driver will convert FileCore DiscOps into an internal Disk Command Block
(DCB) that will be processed by the Command Interpreter.  All DCB's will be
processed in the background, thereby removing the distinction between
foreground and background operations.  The DCB will maintain a field
indicating the state of the command, that can be polled, and will provide
a place for the address of a routine to be called upon command completion. 
The DCB's can be queued and sorted by the driver to ensure minimum head
movement and maximum decoupling between the driver and the filesystem.

An added advantage of DCB's is that various device specific commands can be
issued by applications and processed by the driver without the need for the
application to deal directly with IRQ's/FIQ's or talk to the hardware.

At the lower level the command interpreter will invoke hardware specific
routines to complete the DCB's, which may well require the execution of
several controller commands such as motor spin up, seek, head settling and
data transfer.  The sequencing of these commands will be under the control
of a finite state system.  The function of this system is to ensure the
orderly and timely scheduling of commands without the necessity of entering
busy "spin loops" while the processor is awaiting a timeout - such as motor
spinup or head settling.

The state system will keep the DCB informed of command progress by sending
messages to an event handler.  The handler will be allocated appropriate to
the command when the DCB is submitted.  The function of these messages is to
tell the DCB when it is safe to issue a read, if a command has timed out or
an error has occurred.

To ensure all commands correctly time out the 100Hz ticker clock will be
hooked.

At initialisation time the driver will determine all drives present by
checking for a track 0 indication.  Drives will logically be numbered
sequentially even if they are physically drives 0 and 3 say.


Disk Change and Motor SpinUp
----------------------------

There will be some minor differences in the way the new driver handles motor
startup and disk changed.  To improve performance the new driver will assume
that the drive is up to speed 1 second after enabling the motors or after 4
index pulses have been seen (min 3 revolutions).  3.5" drives come upto
speed in 500mS, while 5.25" drives require 1 second.  3 disk revolutions
require at least 600mS and ensure 3.5" disks are upto speed, many 5.25"
drives mask index pulses until the motor is up to speed.

Disk change support will be increased to the level of reporting an error
to a command that completes with a disk changed status.  To prevent the
annoying buzz that results from polling disk changed the driver will not
attempt to reset the status until at least 1 index pulse has been seen. 
This will ensure that another disk has been inserted.  In addition detection
of disk change will enforce another motor startup period since many 3.5"
drives stop the drive motor when the disk is removed.  Currently disk
removal/re-insertion can potentially cause read/write failures.


Future Enhancements
-------------------

The provision of a well defined Disk Command Block and state machine control
will allow simple upgrading to new controllers.  In addition this approach
allows software emulation of older devices.  Enhancement of FileCore will
allow multiple pending disk read/write operations on several drives,
potentially allowing overlap of settling time on one drive with data
transfer on another.