sdyer@bbncca.ARPA (Steve Dyer) (01/02/84)
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
mason@utcsrgv.UUCP (Dave Mason) (01/02/84)
Thanks to Steve Dyer for the info about how the Disk controller works.
This is not a unique approach. I have an S-100 system with a Versafloppy II
disk controller. To read/write with this, every time you reference the
data register, the controller inserts wait states until the data is actually
available.
By my calculations, there is about 22 usec per byte (for a 8" DD floppy), so
I very much doubt that any useful work could be done and still service the
interrupts on time. The standard solution to this is to store the sector
in a hardware buffer & copy the whole thing when available, saving on the
order of about 20 usec/byte, which adds up to significant wasted time in
the transfer of a complete sector. Obviously this would increase the
cost of the disk controller more than the Radio Shack marketers would accept.
--
-- Dave Mason, U. Toronto CSRG,
{utzoo,linus,cornell,watmath,ihnp4,allegra,floyd,decwrl,
decvax,uw-beaver,ubc-vision}!utcsrgv!masontjt@kobold.UUCP (T.J.Teixeira) (01/03/84)
I believe Zenith/Heathkit uses a similar technique (i.e. halting the
CPU between each data byte transferred) for their soft-sectored floppy
controllers (H-37) for the H-89, at least for double-density. The
latency requirements are so tight that there is not even time to read a
ready flag from a device register, let alone handle an interrupt. I
believe that for single-density, the H-89/H37 is able to read a status
register.
--
Tom Teixeira, Massachusetts Computer Corporation. Westford MA
...!{ihnp4,harpo,decvax,ucbcad,tektronix}!masscomp!tjt (617) 692-6200jpm@bnl.UUCP (John McNamee) (01/06/84)
If you remember at all times that the CoCo was never meant to be the ultimate OS-9 Box and was really designed for the home, you will understand why the floppy disk system was setup the way it is (and why the RS232 port is a bit banger). To do anything better really would have required DMA. I have my doubts that the CoCo could handle it at all, but even if it could, it would have added greatly to the price of the disk subsystem. I am not even sure if Radio Shack would have come out with a 64K machine unless Frank Hogg had shown them how. Dont expect them to do fast disks on the CoCo when they can't do it on the Model 16. John McNamee ..!decvax!philabs!sbcs!bnl!jpm jpm@BNL.Arpa
andree@uokvax.UUCP (01/13/84)
#R:bbncca:-42800:uokvax:3500026:000:133 uokvax!andree Jan 11 21:29:00 1984 True, they didn't put fast disks on the model 16, but the did the 2000 up right. (The thing FLIES - a truly nice 8086 box!). <mike