wow. I should definitely start on the software side first then. If we can show some signs of life there, we're in business.
How experienced are you in dos debug? We can pretty much get a feel for functionality with just a few in and out commands.
------
So the next question is this:
Let's say this part of the project goes really well, and we're functional in a week or two. Do we attempt to add DMA capabilities? That is the ultimate goal of something like this, but it will require additional parts and some reworking of the way we're handling the 16 bit data to accomplish it.
Do we make some PCBs as a PIO only card and do another rev later, or is it worth it to wait? How much of a performance gain could we get with DMA vs. PIO? Is it worth the work involved?
Ok, that was more than 1 question.
Hi Hargle! Well as you said this is speculation for now. The design is relying on IDE PIO mode to keep the circuit's control logic simple. I believe the key to DMA support is the correct placement of registers in the IO address. I think the registers have to be adjacent IO addresses or something like that. The XT-IDE design will not support DMA "as is" because the HI-LO registers are separated by 8 addresses. At least in theory, the circuit could be modified but it would require additional "glue" logic to implement.
IDE PIO mode performance is not great that is for sure but on the systems this project is targeting like 5150's and clones we are not talking about high speed systems to begin with. PIO mode becomes much more of a limiting factor on fast CPUs which spend their time waiting for the hard drive to respond. Generally speaking that's not the case with a 4.77 MHz PC running a single threaded DOS. DMA mode is faster but the difference is not as dramatic in practical terms as it is on the newer machines.
My suggestion is to get to a working prototype and some initial software in place so we can get some real data if and how well the PIO mode actually performs on the target systems. It may be acceptable as is or it may be so bad it is worth fixing. We can compare it to other IDE controllers for the XT ISA bus and get some idea of the merits of pursuing higher levels of performance.
The practical issues of complexity versus cost will weigh in the decision process too. Adding features means adding parts. Add too many parts and the board density goes too high for commonly available parts and low cost double layer PCBs. PCB trace routing becomes more complex and time consuming. Once we cross a certain threshold for complexity, programmable parts like GALs become the only practical solution to keep part count and cost low. As I think you've seen already, using programmable logic represents its own set of unique problems such as requiring special tools, programmers, software, etc.
I am somewhat familiar with the use of monitors like MSDOS DEBUG so the manual manipulation of IO registers from the command line is not an issue. I wrote a RAM monitor for the N8VEM SBC with similar functionality. It is for Z80 but the concept is identical. I bought an ISA bus extender do some limited functionality testing on the board with the intention of determining whether the IO ports are responding, chip selects are triggering, the ROM is appearing in the memory map etc. However, once the hardware is working reliably, then it is all software and that is where your talents really get to shine!
Thanks and have a nice day!
Andrew Lynch
PS, as usual the prototype is going to be similiar to the schematic but different from the PCB layout. We'll need to discuss implementation details as I've made several adjustments to accomodate the prototype board and other components. Nothing too dramatic but enough to be visually noticeable.
