ADFS floppy disk drivers for A5000
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.
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
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.
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.
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.