The last post in this thread has code you can download - CP/M 3.0 that supports flash drive and hard disk and IDEutil.com that formats it as well as other things - so jump past everything and go straight there if you want software downloads.
The posts below describe the software coding effort, so if you're interested in that, read on. It starts off saying the code isn't done, but it is now. Just wasn't when I started. :-)
=======================================================================================================================
I've been kicking around an IDE interface for about six weeks now, so I decided to do a little show and tell.
But this is a work in progress, not a fait accompli. So it's not ready for prime time yet.
Still, maybe you'll find it interesting to watch me unroll this ball of twine. Start the popcorn...
I purchased a couple of John Monahan's IDE boards from S100computers.com. I built them, plugged 'em into a slot, powered up and watched for smoke. No smoke, so that's good. What good luck!
Ran Monahan's test code, and it immediately complained that no drives were present. What bad luck.
So I wrote a little port I/O program to hit the board and let me watch test signals. It asserted all the right signals on the board, and I could see proper access. What good luck!
I decided it might be best to write Monahan to see if he had any suggestions. But he said he was super-busy, and didn't have time to respond. What bad luck.
My first stab was to add some code to output status at strategic places in Monahan's test program, but after a while, decided to re-write some of it in C. For one thing, the re-write would help me understand what the code was doing, and for another thing, some stuff is a little easier for me to do in C than in assembler. My goal is to understand the flow, and to find out what's wrong. When I learn that, I'll update the assembly program so that it works in the Altair.
Once I've done that, transferring the interface code into CP/M BIOS isn't terribly difficult, because the test I/O code is almost exactly what's in BIOS. The only bridge left to cross (or burn) is available memory, 'cause the interface code will increase the size of BIOS. We won't benefit from a big old disk drive if the resulting operating system only has 10Kb TPA.
What I found was the hardware and software interface Monahan chose is an implementation of an interface described by Peter Faasse, with documentation maintained by Wesley Moore. The hardware and software Monahan uses is virtually identical to what is described by Faasse. Others have chosen to use this mechanism on various other platforms too. So that helps when trying to troubleshoot the system - There's not a total vacuum of information on the subject.
- How to connect an IDE disk to a microcontroller using an 8255, by Peter Faasse
So here's what I've got. My updated IDEutil code - the assembly language utility - shows the IDE interface returns status of 0x50 after initialization. It isn't able to retrieve the disk identification string, but it can at least retrieve valid status after initialization. What good luck!
The reason I know that's good is because my IDEtest program - written in C - gives the same status when it runs. That's what we want, because the two bits set that form the 0x50 status are saying that the last command was successful and that the disk is ready. The C program also successfully retrieves the disk identification string, telling me the drive name, firmware revision and number of cylinders, sectors and heads. Even more good luck!
If you look through the IDEtest program, you'll see I included a bunch of configurable delays. My initial thought was I might need to set those to some specific values. I still kind of think that. But I ended up setting them all with a fairly large delay and dialing them back, ultimately setting them all to zero and the program still works. So I'm not sure yet what that means, whether there are some additional delays in the compiled binary that aren't expressed in source - stuff like the inevitable delays caused by stack operations - or if it's something else. I'll probably compile the C code to assembler and then link in the hand-assembled functions of the low-level routines to rule that out.
I'll keep you posted on this thread.