Building an XT-IDE V2 board

Hi
So I am finally getting around to building one of these XT-IDE V2 PCBs. I found one issue that sort of bugs me though.

I built the board using the schematic, PCB layout, the wiki, etc. Everything seemed to go well and no release of magic smoke.

However I noticed some data corruption on boot with my IDE hard drive. The hard drive worked just fine with the XT-IDE V1 boards (both of them).

Even the prototype boards work fine with the drive so I am sort of puzzled.

I am using an old but working XT-IDE ROM (v 0.10) and configured both the XT-IDE V2 and XT-IDE V1 in nearly identical form except for the location of the ROM. However moving the ROM around in memory did not have any obvious effect AFAIK.

Pulling out my few remaining gray hairs, I trying to figure out what is the problem. I do all the obvious stuff like reheat all the solder joints, check all the chips in the tester, ring out the circuit against the schematic, etc. Still occasional corruption with no obvious reason.

By pulling every chip except those absolutely required I was able to isolate the problem to the actual IDE drive latching circuitry. The ROM seems to work fine no matter what. The UART circuitry is gone so I dig into the IDE circuitry more closely.

Everything in the IDE circuitry seems to check out. I am stumped so I resort to chip swapping to further isolate the problem.

Then I noticed that I used 74ALS245 bus transceiver rather than the recommended 74LS245. My XT-IDE V1 boards use the 74F245 transceivers and they work great. Swap out the 74ALS245 for either a 74F245 or a 74LS245 and the XT-IDE V2 board work great just like the XT-IDE V1s and the prototype boards.

WTF! Happy day! I found the problem! Yay! Not so happy is why this *is* a problem. I swap out the 74ALS245s for other 74ALS245s and they all have the same bad behavior. All the 74ASL245s check out on the chip tester.

I guess I was thinking or just assumed that 74ALSxxx was basically interchangeable for 74LSxxx. ALS is Advanced Low Power Schottky and I thought was just LS only better in every conceivable way. Well, with one little exception... IT DOESN'T WORK!

Ideas? I realize the 74ALS245 is a significantly faster part than the 74LS245 but then so is the 74F245 and it works fine. I am surprised and bit disturbed this is making any noticeable difference.

Take it for what it's worth. Obviously there is a fairly significant difference. I am going to dig into the datasheets and see if I can figure out what is the issue. Intuitively, I think 74LS parts would be more compatible with the IBM PC I am using. Nearly everything else in the test unit is 74LS or similar technology. Also it is a fairly slow and gentle machine at only 4.77 MHz

Thanks and have a nice day!

Andrew Lynch

Great detective work! I haven't build an XT-IDE yet (on the to-do list) but I wonder if anyone else is having this problem with the 74ALS245 ?

Andrew, were you able to ascertain whether the corruption was happening on reads, or on writes - I'm guessing that it affected reads?

I've built several XT-IDE rev 2 boards with 74ALS245s as I have a few tubes of them, no problems so far. Several other components are ALS series devices as well. I test the boards in an IBM PS/2 Model 30 as well as an industrial PC built around an AMD K6-2 at 366 MHz.

Is it possible that you're picking up added board capacitance/resistance from flux residue or something? I assemble with an organic core flux that washes clean with water, but it's highly capacitive if you don't clean it -- I've had that generate all sorts of random problems with digital logic, even low speed S-100 stuff.

Hi
I chip off all the excess flux with a toothpick during the post-solder inspection. My suspicion is the 74ALS245 is causing problems not because of the logic on the XT-IDE V2 but with the original IBM PC (5150) I am using to test it in. The PC is clocked very slow at 4.77 MHz and uses mostly old chip technologies. I suspect the 5150 ISA bus is ringing with the faster rise times of the ALS logic vs the LS or F logic. I see a similar situation when I put any card on a bus extender board. It doesn't take much to really screw things up. Probably later PCs had better bus design and more noise immune. Still it is disconcerting. I suspect if I moved this to a more modern PC the problem would disappear. I will have to try it to test the theory.

Thanks and have a nice day!

Andrew Lynch

Would be interesting to know if it works in a later machine. My 'dispensable' Pentium system I use for testing boards is much more forgiving than the 5160.

One thing I did notice on the data sheets is the lack of hold time - just 2ns on the ALS (compared to at least 15ns on the LS). Might sound insignificant, but these are the kinds of timing differences that prevented the 8-to-16-bit MUX working in my CPLD implementation (numbers according to the ISE timing simulation).

I guess the ringing theory could be tested by strapping small bypassing caps on the ISA bus side of the ALS?

Hi

I suspect it will make an improvement on a newer computer. I will have to dig out (excavate?) the original test station.

During the original XT-IDE V1 and V2 prototyping work I used a later Pentium II 233 type machine. It had no issues with any timing or glitching at all even on a bus extender. However putting even a known good 100% solid XT-IDE V1 on a the 5150 with a bus extender and it has the data corruption problem. Put the board directly in the bus slot and it is back to 100% solid.

I am guessing the 5150's timing is kind of dodgy. In some ways it is a good test station since it is probably a really bad case if not worst case for compatibility. Many things are changed when IBM switched from the 5150 to the 5160. I've always felt the XT was a much better and more solid computer in comparison.

Thanks and have a nice day!

Andrew Lynch

pearce_jj said:

Andrew, were you able to ascertain whether the corruption was happening on reads, or on writes - I'm guessing that it affected reads?

Click to expand...

Reads. Basically you can tell it is a problem immediately when it cannot correctly identify (garbles) the drive ATA identify string during autodetect. Also the board refuses to boot and often gives the dread "Missing Operating System" message or something to that effect. Basically it is dead on arrival.

Replace the 74ALS245 with a 74LS245 or 74F245 and all is well again. It is a night or day sort of difference.

Thanks and have a nice day!

Andrew Lynch

pearce_jj said:

One thing I did notice on the data sheets is the lack of hold time - just 2ns on the ALS (compared to at least 15ns on the LS). Might sound insignificant, but these are the kinds of timing differences that prevented the 8-to-16-bit MUX working in my CPLD implementation (numbers according to the ISE timing simulation).

Click to expand...

Hi
That could easily explain it as well. The bus ringing theory is just that -- a theory. There may be other phenomenon at work which is the real problem.

I know some engineers who swear by 74ALS family chips but there is no denial they are much faster and use a *lot* less power. They are a lot closer to their CMOS counterparts than the original 74LS family in my opinion.

Thanks and have a nice day!

Andrew Lynch

Huh, I'd have thought the industrial chassis would have been a "worst case" scenario for ISA bus -- unterminated passive backplane with a CPU daughtercard in ISA form factor. I'll dig out a 5150 this weekend and test.

lynchaj said:

Reads. Basically you can tell it is a problem immediately when it cannot correctly identify (garbles) the drive ATA identify string during autodetect. Also the board refuses to boot and often gives the dread "Missing Operating System" message or something to that effect. Basically it is dead on arrival.

Click to expand...

I had exactly that problem with one of the XT-IDE rev 1 boards I built. It turned out to be a bad 74LS573 latch. The latch tested fine and in fact is still in use as the address mux latch on one of my 8085 projects.

Were EEPROM reads/writes affected by the 74ALS245? Also, if you're still using a really old BIOS, I've had random problems with pre-Universal BIOS and old versions of DOS. MS-DOS 3.30 and IBM PC-DOS 3.30 /will not/ format disks with pre-Universal BIOSes for me. Formatting the drive elsewhere will get it booting, but I've had random lockups and data corruption that weren't reproducable with newer BIOSes.

glitch said:

Huh, I'd have thought the industrial chassis would have been a "worst case" scenario for ISA bus -- unterminated passive backplane with a CPU daughtercard in ISA form factor. I'll dig out a 5150 this weekend and test.

I had exactly that problem with one of the XT-IDE rev 1 boards I built. It turned out to be a bad 74LS573 latch. The latch tested fine and in fact is still in use as the address mux latch on one of my 8085 projects.

Click to expand...

Hi
Personally I've found the XT-IDE design to be very robust. Even the original wire-wrapped prototypes were 100% rock solid. I've never had an issue with them until this discovery. All of my early boards used 74LS and later added some 74F parts. This was the first time I used a 74ALS part on an XT-IDE AFAIK.

Initially I suspected the 573 latches as well. I think these are HCT573 (IIRC) so I ran them through the chip tester, replaced them all with new chips, swapped with older 74LS573's etc all to no effect. I also swapped out the IDE cable (40 and 80 conductor), the IDE drive, experimented with master/slave/CSEL/single jumper settings, etc. Basically spent two days trying various things to find out what and why this was happening.

Swapping the 74ALS245 with a 74LS245 or 74F245 clears up the problem everytime. Putting it back in replicates the problem 100%. I am pretty confident the transceiver is the issue but exactly why is not clear. Bus ringing and/or timing issues are my main suspects though.

Given the early nature of the 5150 ISA bus and the hurried IBM PC 5150 design, I think it is entirely possible it would have problems that were addressed in later models. In my observation, ISA busses generally got better and cleaner as the later models came out. The initial PCs were pretty crappy and were essentially a variant of IBM's 8085 based word processor adapted to use the 8088 CPU. (I forget the model number but it is suspiciously PC-like except for the 8" floppy drives) I recall working on them a lot when they came out and was a bit distressed at how much variation existed between one "stock" IBM PC and the next.

Were EEPROM reads/writes affected by the 74ALS245? Also, if you're still using a really old BIOS, I've had random problems with pre-Universal BIOS and old versions of DOS. MS-DOS 3.30 and IBM PC-DOS 3.30 /will not/ format disks with pre-Universal BIOSes for me. Formatting the drive elsewhere will get it booting, but I've had random lockups and data corruption that weren't reproducable with newer BIOSes.

Click to expand...

No, the EEPROM (EPROM in my case) datalines are directly connected to the ISA bus and they don't go through the transceiver. Only the IDE latching circuitry and the UART go through the transceiver. The XT-IDE boot ROM is essentially are completely separate circuit added to the XT-IDE latching circuitry. Basically two boards on one PCB. The intent was to separate the functions to aid in debugging. Whether that was a good idea or not only history will tell.

I hope this helps! Thanks and have a nice day!

Andrew Lynch

In my CPLD logic I found that the latch timing was by far the most difficult bit - actually I never fully solved it (and neither did the other CPLD based design), hence moving to 8-bit transfer mode. The issue is that we're using the same signal to latch the data and control the drive, whereas we should (somehow) latch the data before we remove the drive on the drive read strobe line. Hence, results can vary as some devices don't hold data long enough.

There is one other minor issue in the XT-IDE v1 and v2 - CSEL should be directly tied to Gnd on the board (there is a 10k PU in the device). This is why devices always identify themselves as slave with CSEL enabled, since with the jumper set either way the level at the drive will be >2.4V.

pearce_jj said:

In my CPLD logic I found that the latch timing was by far the most difficult bit - actually I never fully solved it (and neither did the other CPLD based design), hence moving to 8-bit transfer mode. The issue is that we're using the same signal to latch the data and control the drive, whereas we should (somehow) latch the data before we remove the drive on the drive read strobe line. Hence, results can vary as some devices don't hold data long enough.

There is one other minor issue in the XT-IDE v1 and v2 - CSEL should be directly tied to Gnd on the board (there is a 10k PU in the device). This is why devices always identify themselves as slave with CSEL enabled, since with the jumper set either way the level at the drive will be >2.4V.

Click to expand...

Hi

Is the latch timing issue specific to the CPLD design or inherent with XT-IDE in general? I've never liked the 8 bit only approach since it eliminates so many 16 bit IDE devices such as hard drives, CD-ROMs, LS-120, ZIP drives, etc. Basically everything other than CF adapters and some truely ancient hard drives. Yes, the 8 bit only is much simpler to implement but not worth it IMO.

Yes, I've seen that slave drive identification with CSEL. The XT-IDE V1 had a jumper and we went to the pull down (?) resistor. It could be replaced with a patch wire and be direct to ground instead (0 ohm resistor).

Thanks and have a nice day!

Andrew Lynch

Yes, R6 on the V2 should be 0R.

I don't know why it was so difficult to implement a reliable latch on the CPLD compared to the discrete logic, especially since the latch command line actually has one extra gate delay than the IDE command line on the XTIDE (in U5 on the V2).

Also just to be clear, I'm in no way criticising the XT-IDE design that we all know and love - I'm not sure how it could work particularly any differently. I'm just observing that it looks to me that there is a potential timing issue and that that might be the root cause of why some drives don't work with it.

Hi

I get it. It is not criticism but technical discussion. For an 8 bit bus, IDE is going to be a compromise and some drives are not going to work. That's pretty much a given. All we can reasonably do is find out who the offenders are and minimize their impact.

Probably the most compatible solution I've seen is Max's/Sergey's PPIDE. However barring a 16 bit bus there has to be some kind of latching mechanism necessary and that means the timing is not quite exactly per the IDE specification almost regardless of implementation.

Ironically, the IDE interface on a 16 bit ISA is *really* trivial to implement. Basically just IO decoders and that's it.

Thanks and have a nice day!

Andrew Lynch

Well, that is unless we revert to 256 byte sectors and just assume drive geometry is 16GB exactly, so permitting the maximum 8GB accessible (and obviously transferring two physical sectors for every one in the BIOS). This approach I'm taking with my TRS-80 IDE board, but that was an easier decision since the OS is expecting 256-byte sectors.

pearce_jj said:

Well, that is unless we revert to 256 byte sectors and just assume drive geometry is 16GB exactly, so permitting the maximum 8GB accessible (and obviously transferring two physical sectors for every one in the BIOS). This approach I'm taking with my TRS-80 IDE board, but that was an easier decision since the OS is expecting 256-byte sectors.

Click to expand...

One of the things I really preffer with the XT-IDE is that you can access the HDDs used on more recent computers and use it as a means to transfer huge amounts of files to the XT, fast. Or eventually if something skrews up, then you can yet again fix it by editing the contnents of the HDD on a more recent computer.

About the race condition, didn't we find out that a 80-line IDE cable worked much better than a 40-line IDE cable? How does the signal latency compare for the two?

per said:

One of the things I really preffer with the XT-IDE is that you can access the HDDs used on more recent computers and use it as a means to transfer huge amounts of files to the XT, fast. Or eventually if something skrews up, then you can yet again fix it by editing the contnents of the HDD on a more recent computer.

About the race condition, didn't we find out that a 80-line IDE cable worked much better than a 40-line IDE cable? How does the signal latency compare for the two?

Click to expand...

Hi Per

Yes, the current XT-IDE design allows transparent swapping with other IDE controllers with no sector translation funkiness. It is very handy for IDE devices like LS120, ZIP, etc.

I tried the 80 conductor cable and it does help with some drives as we saw before. It made no difference with my recent testing though. The 80 conductor cable has better signal grounding so that much will improve. It depends on the age of the drive mostly as to how effective it is.

Thanks and have a nice day!

Andrew Lynch

Hi Andrew, I just wondered if you ever tried adding small caps to the ISA bus side of the ALS component, say 50pF, to tame it's rise time?

Hi
No, I just replaced the 74ALS245 part. In my testing I found that other than 74ALS practically everything worked including 74LS, 74HCT, 74HC, 74F, etc. 74ALS parts are uncommon enough to just record it in the build notes. Thanks and have a nice day!

Andrew Lynch