• Please review our updated Terms and Rules here

8 bit IDE (XTA) Replacement Project

J

JayesonLS

Experienced Member
Joined
Nov 18, 2020
Messages
106
I've recently started work on a solid state replacement for 8 bit IDE hard drives. It is looking like it will be a substantial undertaking so I thought I would share progress here as I go. And if I am lucky, maybe some other folks will jump on board to help with the development.

I bumped this project to the top of my queue since it seems most needed out of the projects I have in mind. That, and I am terrified that my working drives I need for reference could die at any moment.

At the moment, I am focussed on understanding the technical requirements better. I have been analyzing my ST05X IDE card. I disassembled the BIOS with Ghidra and understand much of what it is doing. I am now in the process of creating a 386 protected mode tool (based on TNDY.COM) for logging all port access. This is to understand the access protocols better. This work is shared here: https://github.com/JayesonLS/8bit-ide-analysis

My current plan is to first emulate the drive(s) in PCem. PCem emulation isn't low level enough to test the planned circuit/logic. It will however allow me to get the register protocols down. PCem already has an emulation for the original IBM Xebec controller. This is likely most of the way there. I was half expecting it to work with the ST05X BIOS without modification. The ST05X BIOS does detect a drive but it is not accessible. Once the ST05X is working, then in theory I could configure emulation of other XTA PC's (Tandy's, etc.) and make sure those all work.

After that is done, then figure out the hardware. A decent amount of firmware to write also. In addition to the ST05X, I have a Tandy TL/2 to test on. And then if that all works out, look at making the IBM edge connector work. I do have a PS/1 and a PS/3 Model 30, with one working hard drive between them. Hopefully it hangs in there long enough.

The hardware is looking like it will involve a CPLD, microcontroller, SD card, a pin header/power connector on one end, and the IBM edge connector on the other end. I was originally hoping to just use an SPLD and keep the entire design through-hole and programmable with a TL866. Unfortunately, the BIOS code does 6 register writes in rapid succession. On the original controllers, these were stored directly into the sector RAM. I don't know of any suitable microcontroller that allows writing to its RAM in this way. The IBM connector includes IOCTL so that could be used to slow the PC down. Unfortunately, the "standard" 40 pin connector does not. So I think the next best option will be to hold the 31+ bits of essential data in a CPLD.
 
For those interested, here is a some knowledge I have gleaned so far. The most important detail is that XTA essentially just moves the XT MFM hard drive controller onto the drive. So it is very different to 16 bit IDE (ATA) which are based on AT MFM controllers. While XTA is not explicitly documented anywhere I can find, XT MFM controllers are very well documented. I’ll share a bunch of relevant links below.

Drive size selection on XTA is very limited. It retains the two bit drive size specification from XT MFM. That is only 4 possible sizes. The ST05X only supports 3 unique drive sizes: 20MB, 30MB and 40MB. I suspect these sizes are not entirely consistent across different BIOSes. I would be surprised if any support > 40 MB. The Seagate ST351A/X drive has quite a number of possible jumper configurations. So a general purpose replacement will likely also have complicated jumper settings. And be limited to 40MB in size.

XTA does not support ATA style master/slave. That is, it does not support two drives on the same interface. Cards/PCs supporting two drives implement two interfaces. In practice, this just ends up being a second select line. That is why some PC’s use two connectors with two wires swapped on the second connector. An unused pin is being used to carry the second select line. It also means that supporting two drives uses double the number of IO ports in the system. Not a big deal since an XTA interface uses less than half the ports of an ATA interface.

I was originally thinking of putting two connectors in the drive replacement so it would behave like two 40mb drives. It would complicate the implementation a lot though in trying to keep the two virtual drives behaving completely independently. It would also complicate things a bit if there were two drives on the same SD card.

Some links:
Stack Exchange question which links to some controller IC docs. I did not find these super useful: https://electronics.stackexchange.c...can-i-find-xt-ide-8bit-ide-xta-specifications
Russian language page linked to from the Stack Exchange question. This is where I learned that 8 bit IDE is essentially XT MFM. Also has a pinout: http://wiki.sensi.org/dokuwiki/doku.php?id=hddxt

WD XT MFM controller documentation - very detailed: https://ibm.retropc.se/manuals/Western Digital/WD1002S-WX2 - OEM Manual.pdf

Pinouts of both “standard” and IBM connectors: https://ardent-tool.com/misc/IBM_HD_pinouts.html

PS/2 Model 25 tech reference manual which has a little more info and confirmation of the IBM pinouts: https://ardent-tool.com/docs/pdf/PS2_Model_25_Technical_Reference_Jun87.pdf

- Jayeson
 
  • Like
Reactions: tsb
Interesting project!

I have been thinking about something similar for a while, but have not been able to put nearly as much time into it.
Wouldn't it be possible to use one of the beefier STM32 controllers and let it handle everything in software in an interrupt-based fashion?
I figured that a Cortex M with >100 MHz should be able to bit-bang a 4.77 MHz bus, but I could be mistaken.
The integrated USB host support on some of these controllers would make them particularly interesting for this kind of use case.
 
I got to wondering whether the IBM drives are the standard XTA with a custom connector. After a little digging, I think that is not the case. The IBM drives with the edge connector are a different implementation of 8 bit IDE.

The IBM connector has an additional address line as well as the IOCNTL signal. This suggests a different implementation although it could be that they are unused. So I did some disassembly on the PS/2 Model 30 286 BIOS and the routines I found are not consistent with XTA. One routine polls port 322 with a timeout, waiting for bit 2 to be set. Port 322 on XTA is for the drive size bits and it does not make sense to wait for a single size bit to be set. Also, there are routines to read port 324. On XTA this would be for the second drive. However on the IBM, this all decoded for the one drive. Also, on XTA, access patterns for are the same for the respective ranges of 320-323 and 324-327. In the IBM BIOS, it is not like this at all.

So the IBM looks to be something different. Maybe it is more like ATA. Or maybe IBM came up with something new. It would certainly be possible - the XT MFM / XTA protocols are a little goofy IMO - no doubt necessitated by the optimising the design of the controller hardware.

If anyone has any additional knowledge, I would be keen to hear it. With no documentation of the protocols, I think the only approach is to reverse engineer the BIOS. This would be a lot of work.
 
Benedikt said:
Interesting project!

Wouldn't it be possible to use one of the beefier STM32 controllers and let it handle everything in software in an interrupt-based fashion?
I figured that a Cortex M with >100 MHz should be able to bit-bang a 4.77 MHz bus, but I could be mistaken.
The integrated USB host support on some of these controllers would make them particularly interesting for this kind of use case.
Click to expand...

I have looked at using fast ARM controllers on an 8 bit computer bus (< 2MHz) before and it looked like maybe it could be fast enough, although probably not. I never got around to trying it. One gotcha is that while the core may be very fast, the external IO rate may not be nearly so fast. That said, it is probably fast enough to read bytes out of some simpler marshalling hardware that just buffers one byte. The down side is that those controllers are not through hole unless a dev board is used. A good idea that warrants some more thought.
 
JayesonLS said:
I have looked at using fast ARM controllers on an 8 bit computer bus (< 2MHz) before and it looked like maybe it could be fast enough, although probably not. I never got around to trying it. One gotcha is that while the core may be very fast, the external IO rate may not be nearly so fast. That said, it is probably fast enough to read bytes out of some simpler marshalling hardware that just buffers one byte. The down side is that those controllers are not through hole unless a dev board is used. A good idea that warrants some more thought.
Click to expand...

My gut feeling is that something like the STM32 on a Blue Pill should be able to keep up with this. Possibly not with interrupts, apparently the pin-triggered ones have fairly high latency, but they can poll like gangbusters, and they also have a DMA engine that might do the needful. (Presumably you'll also want to implement DMA for data transfer, an XT BIOS will probably expect it.)

Of course with Pi Zeros costing five bucks maybe it isn't worth bothering with something as lowly as that.
 
The Blue Pill boards with their 72 MHz Cortex M3 STM8F103C8T6 are also what I initially had in mind, but they might be a tad bit slow and you would then be limited to SD cards. Being able to use USB flash drives, perhaps combined with a USB slot bracket, would be quite nice.
 
Eudimorphodon said:
My gut feeling is that something like the STM32 on a Blue Pill should be able to keep up with this. Possibly not with interrupts, apparently the pin-triggered ones have fairly high latency, but they can poll like gangbusters, and they also have a DMA engine that might do the needful. (Presumably you'll also want to implement DMA for data transfer, an XT BIOS will probably expect it.)
Click to expand...

I did a bit of investigation and it does not look to me like a Blue Pill is not close to being fast enough to directly service the ISA bus. At 8.33MHz, we get at best 8 guaranteed cycles of a 72MHz STM32. The GPIO ports are sampled at 1/2 the clock rate, so that adds 2 cycles of latency. To service an ISA bus read, we would have some fraction of the 6 remaining cycles to read the GPIO register, branch on the decoded address, then set up the data on the ISA bus. And that is before taking into account the effect of the latency of the polling loop. The performance seems to be about an order of magnitude off.

That would suggest a 1GHz core would be able to it. However it is my understanding that the GPIO registers are not internal to CPU core and can not be read nearly as fast as a CPU register or data in the L1 cache. Instead they are handled as an uncached read.

I an not even confident at this point that an STM32 could store off the 6 command bytes as they are written to the XTA controller. The data is only present on the bus for part of the bus cycle so the loop time of the polling loop must be <= that time. And that is before taking into account other latencies in the external logic and the GPIO port sampling.
 
You are aware that an 8088/8086 bus cycle is four clock cycles and that data (in the case of a read or write) isn’t sampled until the third cycle, correct? Not saying that it’s going to make it *that* much easier, you’re still only going to get two 8088 clock ticks to interpret the address bus and return the expected register value in the case of reads, that’s kind of intimidating , but for writes you could always toss a latch in there to loosen up the timing requirements. Effectively you need to poll at 2mhz, not 8mhz… with conditions.
 
Chuck(G) said:
If I needed an XTA emulator, I'd build on one of the existing ATA emulators, such as this one using an RPi zero. Doubtless there are others not using a GHz MPU to do the work... :)
Click to expand...

I was not aware of this project. It is interesting. I can not locate any of the source materials: they do not appear to be released yet. I can not tell whether the implementation boots an OS on the Pi or runs custom firmware. Booting as OS is not what I had in mind - you run into issues with the Pi booting slower than the PC and the Pi getting ungraceful shutdowns.

It does probably remove the need to design the circuit and layout a PCB. Although that is the part I enjoy the most. I was looking forward to designing a form factor that could be properly mounted in a 3.5" bay by way of a common style of 2.5" to 3.5" adapter bracket. Starting with this Pi project would still require much rework of the FPGA logic and the Pi code but perhaps it does reduce the work some. It would be hard to move forward with the project still in alpha and the source materials unpublished.

I am not aware of any other hard drive replacement projects that are suitable. I am certainly open to suggestions. The FreHD, while not directly applicable, does set the bar high on component optimization. Just a GAL22V10, serial to parallel bidirectional buffer and an 8 bit micro. Data is clocked directly from the SD card to the serial buffer when applicable. Very clever IMO. I shall endeavour to be as efficient.

Just before hitting send I did some searching and found the SCSI2SD project. While not directly applicable, it uses an interesting microcontroller/programmable logic combo IC from Cypress. It is a somewhat expensive and unique part to base a design around. But plenty of logic, CPU and 5v support all in one device is very appealing.
 
Eudimorphodon said:
You are aware that an 8088/8086 bus cycle is four clock cycles and that data (in the case of a read or write) isn’t sampled until the third cycle, correct?
Click to expand...

I was thinking that I should hook up a scope with the ST05X card on a fast PC to see what the worst case signal timing looked like. I will do that sometime soon as I think it will be instructive.
 
JayesonLS said:
Just before hitting send I did some searching and found the SCSI2SD project. While not directly applicable, it uses an interesting microcontroller/programmable logic combo IC from Cypress. It is a somewhat expensive and unique part to base a design around. But plenty of logic, CPU and 5v support all in one device is very appealing.
Click to expand...

Some of the Cypress PSoC devkits are pretty cheap. There's at least one floppy flux sampler built on one with nothing more than a header installed.
 
JayesonLS said:
I was thinking that I should hook up a scope with the ST05X card on a fast PC to see what the worst case signal timing looked like. I will do that sometime soon as I think it will be instructive.
Click to expand...

I will definitely be keeping an eye on this thread. I have several vague project ideas on my brainstorm list that would benefit from finding a cheap microcontroller that’s fast enough to do direct port I/O with an old-tymey CPU bus without a lot of glue. In my junk box I have a stash of Blue Pills I bought for experimenting with but they are a big leap in complexity compared to the AVR8s I’ve been using. One nice thing about the AVRs is they can do byte I/O at full clock speed in assembly; ARMs are a lot more… asynchronous.
 
You must log in or register to reply here.
Back
Top