This adaptability is due primarily to its extreme similarity with the old Western Digital WD100x series of hard disk controllers. In fact, except for a difference in data-bus width and some bit-reassignments in one of the control registers, the two systems are identical.
For a complete treatment of the IDE interface and an example of interfacing IDE devices to a machine with an 8-bit data bus, see issues 56, 63, 64, and 66 of The Computer Journal.
For the record, the only changes made were:
In the process of making the changes, the old explicit seek code had to be eliminated, but since IDE drives perform implicit seeks on all commands, no functionality was lost.
If you are interested in building an IDE host adapter for your favorite 8-bit machine, you can obtain a system-independent control chip and general schematic from:
Wayne Sung / wsung@jessica.stanford.edu
Here are some pictures of my ``Q10IDE'' IDE host adapter for the QX-10.
The GIDE, by Tilmann Reh, is an IDE interface designed to be installed between the Z80 CPU and its socket in nearly any Z80-based computer. Where space prohibits ``under-the-Z80'' installation, the GIDE may be attached to a (short!) ribbon cable which is connected to the CPU socket with a 40-pin IDC DIP plug. If the CPU is soldered into the computer's main board, an additional socket may be (carefully!) soldered to the CPU and the GIDE board connected via ribbon cable as mentioned above.
Because of my involvement in the general 8-bit IDE project, Tilmann (through Herb Johnson) sent me the bare PCB and pre-programmed GALs for the GIDE for evaluation. Lately, I was able to collect the rest of the parts required to complete the board. I hope to present an account of my experiences with it.
Total construction time was about 90 minutes. Outside of having to deal with a couple of through-holes filling with solder prematurely, everything went smoothly. The GIDE provides for a battery-backed real-time clock and although I didn't have the 72421 clock chip, I installed all the supporting components for it anyway.
To do preliminary testing, I installed the GIDE under the CPU of an Applied Engineering Z80+ card (MicroSoft SoftCard clone). It booted and ran OK, so the GIDE board wasn't causing a problem. I hooked up the IDE hard disk I'd been running on my Epson QX-10 and whipped up a small code fragment under C. B. Falconer's DDTZ to send the IDE IDENTIFY command to the drive and read back the ID record.
It worked! Well, actually I noticed an odd glitch that turned out to be a fault of the Z80+'s design. Seems Applied Engineering omitted the Z80's MREQ* and IORQ* signals from their Apple-][ bus-access logic. Thus there is no way to distinguish between an I/O cycle and a memory cycle!
The GIDE re-routes the Z80 RD* signal so that RD* is not asserted on the CPU socket when reading from the GIDE, but no such protection was given to the WR* signal. When I wrote to the IDE task file registers, I was also scribbling on system memory!
To remedy this problem, I cut the RD* and WR* traces leading from the Z80+ CPU socket, took a 74LS32 quad 2-input positive OR gate and carefully bent its pins completely backward, clipped off the narrow ends of the pins and hot-glued the chip to the solder-side of the Z80+. I soldered wire-wrap wire to make appropriate power and ground connections. I attached the CPU socket's MREQ* line to one input of two of the OR gates in the chip. I attached RD* and WR* to the other input of each of the OR gates. I then attached the output of the OR gates back to the remaining WR* and RD* circuitry using conveniently-located through-holes. I covered the protruding chip and wiring with some non-conductive adhesive tape.
No more scribbled memory!
I've now started experimenting with GIDE on my Davidge DSB 4/6 (DSB 4000, rev. B) single-board computer. When I initially installed the board, the machine couldn't boot--the boot drive just sat chattering over track 0. I know that I chose an appropriate base address, so something else must be amiss.
It turns out that there was bus contention for the RD* signal. The GIDE's masked read signal (RDQ*) doesn't assume a high-impedance state--it's always either high or low. The Davidge DSB 4/6 relies exclusively on the Z80DMAC to do disk I/O. As such, the Z80 CPU's RD* signal goes to high-Z and the DMAC drives the line. With the GIDE in place, the DMAC and the GIDE were fighting over the RD* signal. Hence the problem.
One solution to this would be to lift the DMAC's RD* pin and attach it by flying lead to the GIDE's CPU socket. I opted for a more radical solution. As I don't need the masked read (RDQ*) signal, I simply cut its trace on the GIDE PCB (leading from pin 13 of the GAL16V8 to pin 21 of the piggy-back connector) and soldered in a jumper in J3 that connects position ``A'' directly to position ``B.'' This modification returns the CPU's RD* signal to its customary place in the Z80 control bus.
With the GIDE thus modified, the Davidge boots up just fine!
As soon as I can procure a cheap, small-capacity (40MB or less) IDE hard disk, I will be able to proceed with testing and the eventual development of an IDE BIOS extension for the Davidge DSB 4/6.
GIDE update: 20 November 1995
Back at the beginning of November, I managed to acquire, quite inexpensively, a Conner CP-3024 20MB IDE hard disk. This was fortuitous as I have the OEM manual for this drive (Conner sent it to me when I still had the CP-3022 drive, but the two drives were dissimilar enough that the manual didn't help me with the CP-3022).
Now that I had the actual drive to accompany the manual, I set it up to run on my Epson QX-10. The first thing I learned was how FAST it was compared to the CP-3022 (and the CP-342 I had been using since I fried the CP-3022). I looked at the data returned by my ID program and saw that the CP-3024 had a 16-sector buffer whereas the CP-3022 and CP-342 only have a 1-sector buffer.
The second thing I learned was that the geometry reported by the CP-3024 is not the one it actually uses. (The geometry reported by the CP-3022, in contrast, was the actual geometry that it used for regular access.) Since I had the OEM manual, it was apparent that the CP-3024 was reporting its physical geometry. Some more digging through the OEM manual indicated that the CP-3024 powered up in ``translation mode'' of 615 cylinders, 4 heads, 17 sectors per track.
What does this have to do with GIDE, since I can't use it on the Epson QX-10? With the Conner CP-3024 set up on the QX-10, I was able to move my Conner CP-342 to my Davidge DSB 4/6 single-board computer which is where I have the GIDE installed. If you recall, I had to modify the GIDE so it could reside in the Davidge (cut RDQ* and jumper position ``A'' to ``B'' on solder-jumper J3). I mounted the CP-342 in the Davidge's case, attached power and interface cables, and powered up.
It works just great! I had eariler re-compiled my ID and sector dump programs to run with the GIDE (changed a couple of #define statements) and it read everything correctly. I re-compiled my program that fills IDE disk sectors with E5h bytes for the GIDE and was preparing to ``zero-out'' the drive for further experimentation on the Davidge machine when I discovered another interesting behavior.
When the requested sector address is valid, the activity LED on the GIDE (and attached to the drive) flashes brightly. If an invalid sector address is specified, the LED flashes very weakly, almost invisibly. I used this behavior with my sector dump program to determine the operational geometry of the CP-342 drive: 981 cylinders, 5 heads, 17 sectors per track. The drive reports 806 cylinders, 4 heads, 26 sectors per track when queried with the ID program, however. Apparently, the ID record shows the physical geometry of the disk, but the drive powers up using the other geometry.
Obviously, determining the operating geometry by watching the LED is tedious, time-consuming, and error-prone (the LED behavior may not be the same on another manufacturer's drive). I realized that I should write a utility to experimentally determine the drive's operating geometry. In about 30 minutes I'd written a little program (in Z80 assembly language) to do just that.
The program simply starts counting up through the heads, then the sectors, then the cylinders, reading one sector. It counts up until it gets an ``IDNF -- ID Not Found'' error, at which time it knows it has found the maximum of the particular coordinate. Being a bit lazy and impatient, I wrote it to run under a debugger (I was using C.B. Falconer's ``DDTZ'') so I could simply load registers with the results and examine them. Eventually, I hope to make a more robust, generalized version of it.
The software confirmed the operating geometry I'd determined by watching the LED.
That's where things stand right now. The GIDE (as modified) works very well in the Davidge DSB 4000 single-board computer with the Conner CP-342 drive. Time and space constraints prevent me from doing much more with it until mid-December. Over the Christmas break, I hope to at least begin writing a hard-disk BIOS extension for the Davidge/GIDE system.
GIDE Upate: 25 Dec 1995:
I finally managed to find some of the HCT-series logic that the GIDE board calls for and replaced the LS parts I had been using. At the same time, I was able to get the Seiko/Epson 72421 RTC module that the GIDE has space for. It was all available from Jameco, although they are closing out their HCT-series parts. (At least the prices were good--I got the HCT646 chips for $0.99 each!)
I put the RTC in the GIDE and hacked a battery for it (3.6V lithium). I now have a real-time clock in my Davidge DSB 4000 single-board machine. I put off hacking on the IDE side of things to hack on the RTC stuff. Using Tilmann Reh's supplied example code, I wrote a program to read the time either once or as a running clock (ala TD.COM). I was starting to think about how to do a proper "set" function when I wimped out.
I brought up NZCOM/ZDDOS/etc. on the Davidge.
I looked back through the CardZ180 OEM notes. I found and cleared the CZ flag and removed the special "CPR-stash" routine from the patch area. Now I had a generic version of NZCOM. At first, I brought it up (with ZDDOS) just fine and used ZSCONFIG to make sure that the clock functions were disabled.
I quickly hacked up a ZSDOS/DateStamper clock driver for the Davidge. Since I had to use the special NZBIO.ZRL that saves the index and alternate registers, I had an extra 128 bytes to play with. I simply loaded the clock driver (101 bytes) in the extra space and used ZSCONFIG to point ZDDOS' clock driver entry point at it. That worked marvelously until I got around to installing the !!!TIME&.DAT file on the boot disk.
It was then that I discovered that the NZDOS segment gets used as soon as it's loaded. With the datestamp file on the disk, the last few operations of NZCOM failed and hung since the CardZ180 OEM version of ZDDOS was trying to call the clock driver (FFF5h) before it had been loaded! Fortunately, I had just learned that the highest address used by the Davidge floppy-disk BIOS was FF16h, giving me plenty of room to stuff my clock driver in place at cold boot.
I re-arranged my clock driver so that the entry point would fall at FFF5h and added code to move the driver into place. On cold boot, the "turn-key" CCP command runs my clock loader, which sets up the clock driver. My loader, in turn, stuffs the CCP command buffer with "NZCOM" and jumps to the CCP--causing the CCP to now load NZCOM and bring up Z-System with a fully-functioning clock!
At the same time, I had managed to massage my GIDE IDE geometry seeker (experimentally determines the operating geometry of the IDE drive) into a stand-alone form. Not long thereafter, I changed the base port address and successfully assembled it for use with the Q10IDE interface for the Epson QX-10.
I am pleased to announce that I have succeeded in writing a BIOS extension to support the GIDE on the Davidge DSB 4/6 single-board computer with floppy-disk BIOS FD-4000 v1.3. The BIOS also includes a clock driver to support ZDDOS/DateStamper with the GIDE real-time clock module.
The BIOS extension is intended to execute upon cold boot as the default CCP command. The loader portion determines if the current system has enough high memory to allow the hard disk BIOS module to load and if so, relocates the code and jumps to the "cold boot" routine which finishes the required initializations and transfers control to the CCP. As part of the initialization, it stuffs a new command into the CCP command buffer before control is transferred. This way, any turnkey operations may be maintained with the hard disk BIOS in place.
At first, I tried to get the hard-disk BIOS (HBIOS) and the floppy-disk BIOS (FBIOS) to share the uninitialized data (udata) areas used by the disk blocking/deblocking code. Unfortunately this didn't work very well. It worked OK as long I accessed only the hard disk or only the floppies, but file transfers from floppy to hard disk and vice versa failed if the file was larger than some threshold size.
Eventually, I decided to abandon that approach and defined a duplicate set of udata areas for the exclusive use of the HBIOS. In this form, everything works correctly.
While I was at it, I made it possible to re-map drive letters to an arbitrary drive. This allows the hard disk to become drive A: after the HBIOS is loaded. For my Conner CP-342, I simply made each head a different logical drive (it powers up as 981 cylinders, 5 heads, 17 sectors/track) to get 5 full 8MB logical drives. For simplicity's sake, I'm using 8K allocation units, which I believe to be an acceptable trade-off between internal fragmentation and allocation vector space requirements.
The HBIOS' size requires that a 62K CP/M system be built. Initially, a bootable floppy disk was required to remain in the first floppy disk drive (regardless of whether or not it remains drive A:) for warm-boots to re-load the CCP/BDOS. I've since written an ``IDEGEN'' utility to write the CP/M image out to the reserved tracks of the hard disk and added hard-disk warm-boot code to the HBIOS.
I've been running this BIOS without any problems for several months now and believe it to be very stable. I tried to make it generic enough that it would require little modification to be implemented on other machines.
I eventually intend to make it possible for the system to cold-boot from the hard disk. The additional BIOS code is straightforward, but it will require that I burn a new boot EPROM for the machine.
tcj@psyber.com
This interface is being developed by long-time CoCo user Jim Hathaway. I became involved in it when he asked for help with trouble-shooting his early experimental versions.
For full history and latest developments, check out the Color Computer IDE Project Home Page!
I don't have a CoCo myself, but I've wanted to play with one (and OS-9!) for some time. I learned quite a bit about the CoCo and M6809 CPU through assisting with this project.
The schematic should serve as a general guide-line for any 6809 IDE interfacing project. It should be noted that the current design permits ignoring the upper half of the IDE data register to simplify OS-9 device-driver design.
This interface and accompanying driver software was developed by Scott A. Christensen. He asked me to put it on my web pages, so here it is. (I'm sorry it took so long, Scott--I finally scratched out enough time to make the update.)
The first text file contains a
general description and ASCII-art schematic.
The second text file contains
driver source code (in C) with embedded ASCII-art schematic.
Enjoy!
Copyright © 1995 John D. Baker,
jdbaker@NoSpAm!blkbox.com
Transmission of this document, in whole or in part, via the
Microsoft Network requires license. License is available to Microsoft
Corporation for an annual fee of US$15,000 plus US$5.00 per machine
connected to the Microsoft Network. Appearance of this document on
any machine so connected constitutes agreement to these terms. ``Appearance''
means that this document has been transferred to local storage of said
connected machine, regardless of whether its contents are rendered on
a display device. Please send notice of violation of this licence
agreement to John D. Baker.
