Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10 5/3/83; site bbncca.ARPA
Path: utzoo!linus!bbncca!sdyer
From: sdyer@bbncca.ARPA (Steve Dyer)
Newsgroups: net.micro.6809
Subject: Radio Shack Floppy Disk Interface
Message-ID: <428@bbncca.ARPA>
Date: Sun, 1-Jan-84 18:03:12 EST
Article-I.D.: bbncca.428
Posted: Sun Jan  1 18:03:12 1984
Date-Received: Mon, 2-Jan-84 02:25:56 EST
Organization: Bolt, Beranek and Newman, Cambridge, Ma.
Lines: 60

I just got a copy of the Radio Shack service manual for the
Color Computer Disk Interface, catalog number 26-3022, and it
is quite helpful, but a bit surprising (shocking?) as well.
The device uses the WD1793 FDC chip, along with a separate
control register for device selection.  Since the FDC chip is well
characterized (see the Western Digital spec sheets), I am
only including the additional control register bit layout:

	      /	Bit 0 = drive select 0
	     |	Bit 1 = drive select 1
	    /	Bit 2 = drive select 2
	FF40    Bit 3 = motor on
	    \   Bit 4 = start precompensation
	     |  Bit 5 = double density enable
	     |  Bit 6 = drive select 3 (or side select a la Frank Hogg Flex)
	      \ Bit 7 = halt enable

	FF48    1793 status/command register
	FF49    1793 track register
	FF4A    1793 sector register
	FF4B    1793 data register

The shocking part comes from the way the CPU reads data to/from the
disks.  Have you noticed the loss of characters from the keyboard
when OS-9 accesses the disks?  I always thought it was because the
keyboard was not being polled sufficiently often.  Sort of, but read
this quote from the service manual:

"To allow the CPU to keep up with the double density interface, the
data request line from the WD1793 is gated with halt enable from the
control register.  The resulting signal is used to control the processor
halt input.  The interrupt request from the WD1793 is gated with the
double density enable signal from the control register and this line
is used to generate a non-maskable interrupt to the CPU.

"With the HALT/NMI logic, a disk read operation will operate as follows:
first, the CPU loads the FDC command register with the desired read
operation.  Next the double density enable and halt enable control bits,
D5 and D7, are set.  The CPU is then immediately halted until the data
register contains the first byte of data.  When this data is received,
the data request line of the WD1793 goes high removing the CPU from the
halt state.  The CPU then loads the byte of data from the WD1793 and stores
it in memory.  After the WD1793 data register has been accessed, the data
request line goes low and the CPU is again halted.  This halt and load
process continues until the WD1793 generates an interrupt to indicate that
the read command has been completed.  This interrupt clears the halt enable
control bit, D7, and breaks the CPU out of the tight read and store loop.
A write operation is similar with the exception that the halt occurs after
a data byte has been loaded into the data register."

Talk about cycle stealing!  The CPU isn't even running during the time the
keyboard data is lost.  This design is quite elegant for an operating
system like TRSDOS, and it certainly simplifies the read/write inner loop
for the disk driver, but what a loss in a multi-tasking system like OS-9!
I wonder if the desired latency could have been achieved using NMI or
FIRQ, while keeping the CPU running to service other tasks?
-- 
/Steve Dyer
decvax!bbncca!sdyer
sdyer@bbncca