• Please review our updated Terms and Rules here

XT-IDE rev 4 Development

glitch

Veteran Member
Joined
Feb 1, 2010
Messages
5,051
Location
Central VA
I've been working on revision 4 of the Hargle/N8VEM open source XT-IDE design. It started off with the following changes, mostly suggested by users here and on IRC:

  • Better parts numbering (U1 is top left, U2 to its right, et c.)
  • Thicker/more consistent silkscreen (some board houses produced illegible/broken silkscreen on some labels and symbols)
  • Larger pads around some of the jumper headers
  • Better pin 1 indication for ICs
  • Rotate IC part number text (e.g. 74LS688) to match typical orientation on ICs
  • Change bypass cap values to match parts kit (changed to C instead of a uF value)

I also added better test points with labels on both the front and the back to make the Slot 8 Support mod board easier to install, and routed *CARDSEL through the last DIP position on the I/O address switches. The status LED got flipped so that I can use some right-angle LEDs I've got in stock on personal builds, too.

During the process, I ran into Alan Hightower (eeguru) at VCF East, who is working on the NetPi-IDE Raspberry Pi interface. He'd ran into a timing problem with how the high byte is latched on the XT-IDE and had to work around it with his FPGA design. He described the problem to me, which seemed to be a race condition on the read side of things: when *IOR de-asserted from the ISA bus, a sufficiently fast ATA device, like his NetPi-IDE board, would present invalid data to the high byte latch before it could de-assert and latch the data. This is due to the propagation delay in the logic on the original Hargle/N8VEM design, which I think is worth keeping as it preserves BIOS compatibility with the older BIOSes. The solution is to slow down the *IOR signal a little. I hooked up the HP 1650A logic analyzer to take a look:

nZ7tc4f.gif


IORISA is the *IOR strobe essentially directly off of the ISA bus. IORIDE is the same signal after passing through four sections of a 74LS04 inverter, this adds around 20 nS of gate delay. HI RD is the latch strobe to U1, the high byte read latch that stores the upper 8 bits of the ATA device's output data during a read, so we can grab it later. As seen in the timing diagram, where HI RD used to lag IORISA by 10 nS, it now leads by 10 nS due to the 20 nS delay chain. This means the latch stores its value 10 nS before the ATA device stops outputting valid data, which is well within the spec for even the 74LS573 latch (the kits typically come with 74F573 latches, because I have a supply of them).

I decided to go ahead and check out the write timing as well, though it hadn't been pointed out as a problem:

1QFmEME.gif


IOWIDE is the *IOW signal essentially directly off of the ISA bus. HI WR is the latch strobe for storing the upper byte before doing a 16-bit write to the ATA device. HI OUT is the delayed "2 signal" from the XT-IDE logic (I've since relabeled it *HI_BYTE_OUT on the schematic, which I think is clearer). It was delayed by running it through two sections of a 74LS04 inverter and one section of a 74LS32 OR gate, with one input of the OR gate tied to ground. As seen in the timing diagram, *HI_BYTE_OUT now de-asserts 10 nS after the *IOW line, ensuring that data is presented to the ATA device for 10 nS past the end of the ATA write operation. I'm not sure if many (or any) ATA devices are this picky about the timing, but correcting it at the same time as making other rev 4 changes didn't require any spare gates.

All of this was breadboarded on an old XT-IDE rev 3 prototype board from the initial rev 3 design, with a 74LS04 dead-bugged onto the circuit board and wired in. I made the read delay chain modifications and had some more prototypes run. Alan has one of them, which he used to confirm that the read timing was fixed. I modified a second with a socket for the 74LS04 so that I could test faster devices, as well as adding in the high byte output delay. I tested 74S04, 74LS04, 7404, and 74F04 devices, to make sure that whatever got stuck in there by someone assembling an XT-IDE would provide sufficient delay. All provided sufficient delay, the 7404 was the only measurable difference, providing around 25 nS instead of 20 nS, which is fine.

I've ordered production boards for the XT-IDE rev 4, since I'm almost out of XT-IDE rev 3 boards from the last run. They'll look approximately like this:

vQ81TIj.png


YSe1V0u.png


Those are from the earlier prototype order, since then I've switched the OSHW logo to a copper/solder mask relief, and moved the identification text back toward the OSHW logo. There have been some routing tweaks as well, but nothing major, other than adding in the hi byte output delay. Probably the biggest change people will notice is the extra 74LS04, and the switch to custom IC silkscreen legends from the stupid defaults included in newer KiCad releases. I'd stuck with the older KiCad 2.x style IC silkscreens on the rev 3 board because I thought the pin 1 designations were really, truly awful on KiCad 4.x default libraries.
 
Last edited:
James Pierce also noticed the same and added a similar fix to his boards. I noticed it when testing a memory mapped port of JR-IDE to ISA. I think it will make many more ATA devices work with the board.

Thanks for your hard work!
 
Two more wishes:
- A 16 BIT AT version also would be welcome.
- Enable/Disable Olivetti M24 / AT&T 6300 compatibiliy mode by jumper for the 8 bit version - or even better: special M24 16 bit version ...
 
Two more wishes:
- A 16 BIT AT version also would be welcome.

Just use a regular 16 bit IDE controller with the XT-IDE Universal BIOS housed in a free ROM socket (network card are great for this). Works perfectly.
 
Yes, the lo-tech 8-bit MUX honours the timing spec in both directions as well.
 
Thanks, everyone! Again, there's no reason to upgrade from an earlier board if your board is doing what you need -- these changes just increase ATA device compatibility, which seems to already be pretty good. If you were planning on doing a Slot 8 Support modification, the rev 4 makes that slightly easier.

Two more wishes:
- A 16 BIT AT version also would be welcome.
- Enable/Disable Olivetti M24 / AT&T 6300 compatibiliy mode by jumper for the 8 bit version - or even better: special M24 16 bit version ...

As mentioned, you can use a regular 16-bit ISA IDE card if your machine has a 16-bit ISA bus, with the XUB on a network card or something else with a ROM socket (you could even use an XT-IDE board with only the ROM parts populated).

I'm not sure what you mean by M24/6300 compatibility mode. Part of the reason that the Compatibility/Chuck Mod mode jumpers were retained (rather than doing a permanent Chuck Mod) was to keep the board compatible with M24/6300 systems. Is there something more required? I don't have one to test with.
 
Just use a regular 16 bit IDE controller with the XT-IDE Universal BIOS housed in a free ROM socket (network card are great for this). Works perfectly.

Yes, possible, but with disadvantages:
a) needs an regular 16 bit IDE controller. Hard to get...
b) needs a free ROM socket
 
Yes, possible, but with disadvantages:
a) needs an regular 16 bit IDE controller. Hard to get...
b) needs a free ROM socket

You can also use a 16-bit IDE channel on a sound card, if you have one with real IDE on it (some cards have a manufacturer-specific header that only works with a handful of CD drives). I could certainly lay out a 16-bit IDE board, there's not much more than some buffers and decode logic to it, but the board would probably be $15-20 for the bare board due to the larger number of gold-plated edge contacts and size increase. At that point, you might as well buy a vintage 16-bit IDE board -- if people are having a hard time finding these, I have several to go through, test, and sell. Most are multi-IO, too, so you get floppy and often serial/parallel.

If there's enough interest in a 16-bit IDE card with ROM socket, I'll add it to the list of things to be laid out and run, but it just seems that they're way too common/cheap currently to really justify spending the time and money on running boards.

W.R.T. the ROM socket, a network card is, as mentioned, a popular option, since most people want Ethernet on their vintage PCs nowadays anyway. You can also use an XT-IDE board with only the ROM circuitry populated, which has the added benefit of being able to program its own EEPROM. If anyone is having a hard time finding a 16-bit controller/ROM board combination, PM me and I'd be happy to put something together from my surplus parts!
 
Yes, possible, but with disadvantages:
a) needs an regular 16 bit IDE controller. Hard to get...
b) needs a free ROM socket

A - Hard to get? Really? Searching for "ISA IDE Controller" results in at least 66 results, with prices varying from $5 up to $60, but most seem to be around $20. Not necessarily plentiful, but certainly not hard to get.

B - Just about any NIC card has a ROM slot that can be used, but any card that allows for a ROM chip to be used would work. This can vary from Sound Cards to networks cards to even a free ROM socket on the motherboard, but personally I'd just stick with the NIC, because the added ability to get a vintage machine on the web via DOS TCP/IP can come in very handy.
 
A - Hard to get? Really? Searching for "ISA IDE Controller" results in at least 66 results, with prices varying from $5 up to $60, but most seem to be around $20. Not necessarily plentiful, but certainly not hard to get.

Do keep in mind that they're cheap/easy to get in the United States -- overseas shipping is an instant $15-25 penalty for something the size of an ISA card.
 
Do keep in mind that they're cheap/easy to get in the United States -- overseas shipping is an instant $15-25 penalty for something the size of an ISA card.

Fair point, but then that means the shipping on a community made 16bit ISA card would also be increased if it were coming from the USA. On top of that, of the 66 listings on ebay, there were about 15 or 20 that were european listings, Bulgaria and Ukraine for some reason has quite a few. My point was that they are not hard to get, even if the cost to get them maybe higher in other countries.
 
Around here, you can have 16-bit IDE/FDC/LPT/COM/GAME cards for pennies.
3c509 NICs with ROM sockets are very cheap as well.

But I can see one reason to have a 16-bit counterpart to XT-IDE: most of those multi-I/O cards are hardwired for primary IDE address and IRQ 14, some allow for secondary IDE address but still IRQ 14.
Now, if you have a 286 box with an MFM HDD, and you want to leave the original HDD, adding an IDE HDD/DOM/CF as the second drive, you need a controller that can co-exist with the original one.

Such controllers do exist, and they aren't rare nor expensive - you can find them on many late-ISA sound cards.

So, no need for a 16-bit XT-IDE for me, but who knows, perhaps it would appeal to those who are too lazy to search and experiment with piles of various old sound cards?
 
As one of the the great great gandfathers of this project, I am supremely happy that it lives on. I may have to pick one up myself!
 
As one of the the great great gandfathers of this project, I am supremely happy that it lives on. I may have to pick one up myself!

I'll be happy to send you one for free :) We owe it to you, without your initial work on the first version, it likely would've taken much longer to have such a nice solution available to hobbyists at a fair price.

Rev 4 preserves the original register map, so your BIOS should still work with it in compatibility mode!
 
Great to hear about the rev 4 development! Pls retain compatibility with the Olivetti M24!

Thank you!

My design will never break compatibility with the Olivetti M24/AT&T 6300, retaining compatibility with the original Hargle/N8VEM design is important, in my opinion.

Finally got an estimated delivery time from the shipper -- boards should be in next Tuesday, 2017-09-05!
 
Back
Top