Help with Glitch Works xt-ide rev 4A

[dmuntz]

I assembled the GW rev 4A board from the kit, and it worked great with the supplied BIOS (1.1.5), booted from an MS-DOS CF created on another xt-ide board running 2.0.0b3. My other xt-ide cards are running 2.0.0b3 R618 with the 32k ide_xtl.bin. I used the GW card at both 0x300 and 0x3E0 (reconfig'd with idecfg for the 1.1.5 build) . I'd like to get the GW card working with 32k 2.0.0b3.

First attempt: 32k, 2.0.0b3: IBM 5150, after post, says ROM D000 (or D000 ROM...). I thought maybe I had somehow managed to not get the checksum byte in the image, so I went back and made sure by running xtidecfg on a fresh 2.0.0.b3 R618, and flashing it in the machine, but got the same result (confirmed flashing worked by checking the contents of the 27C256 with a separate programmer). At this point, I'm thinking maybe it's a problem with my kit assembly impacting use of the 32k EEPROM. But I can still test 8k...

Second attempt: 8k, 2.0.0b3: set for fast mode. xt-ide BIOS comes up and runs, but can't find the CF card (no master or slave detected).

Third attempt: 8k, 2.0.0b3: set for compatibility mode: BIOS comes up and runs, finds the CF card, starts to load MS-DOS ("Starting MS-DOS"), but hangs here. Keep in mind that this same CF card successfully boots under 1.1.5 on the GW card, and under 2.0.0b3 R618 on my other card.

Any thoughts on either the 32k or 8k issues? Anyone running a 2.x.x build on the GW rev 4A board? I did solder pins for jumpers onto the board, despite a warning that the holes were a bit small, however the pins fit through fine and I made sure the solder flowed to both sides.

 

[Krille]

I assembled the GW rev 4A board from the kit, and it worked great with the supplied BIOS (1.1.5), booted from an MS-DOS CF created on another xt-ide board running 2.0.0b3.

Just because it boots successfully doesn't mean the drive geometry used by the BIOS is compatible with the geometry on the disk.

My other xt-ide cards are running 2.0.0b3 R618 with the 32k ide_xtl.bin. I used the GW card at both 0x300 and 0x3E0 (reconfig'd with idecfg for the 1.1.5 build) . I'd like to get the GW card working with 32k 2.0.0b3.

Note that there are newer versions available. As always, I recommend using the latest.

First attempt: 32k, 2.0.0b3: IBM 5150, after post, says ROM D000 (or D000 ROM...). I thought maybe I had somehow managed to not get the checksum byte in the image, so I went back and made sure by running xtidecfg on a fresh 2.0.0.b3 R618, and flashing it in the machine, but got the same result (confirmed flashing worked by checking the contents of the 27C256 with a separate programmer). At this point, I'm thinking maybe it's a problem with my kit assembly impacting use of the 32k EEPROM. But I can still test 8k...

Make sure there's not a conflict with some other device/ROM in that memory range.

Second attempt: 8k, 2.0.0b3: set for fast mode. xt-ide BIOS comes up and runs, but can't find the CF card (no master or slave detected).

Did you move the jumper as well as change the device type in XTIDECFG?

Third attempt: 8k, 2.0.0b3: set for compatibility mode: BIOS comes up and runs, finds the CF card, starts to load MS-DOS ("Starting MS-DOS"), but hangs here. Keep in mind that this same CF card successfully boots under 1.1.5 on the GW card, and under 2.0.0b3 R618 on my other card.

Yeah, this likely hangs because of different drive geometries. You must redo the partition and format dance when you change the XUB version, and especially so when changing between versions as far apart as these.

Any thoughts on either the 32k or 8k issues? Anyone running a 2.x.x build on the GW rev 4A board? I did solder pins for jumpers onto the board, despite a warning that the holes were a bit small, however the pins fit through fine and I made sure the solder flowed to both sides.

If you did move the jumper for the high speed test then it's possible there's a problem with the jumper pins. Perhaps you need to do a continuity test on them.

 

[dmuntz]

Fixed the 32k issue by reflowing the EEPROM socket--seemed a likely candidate given the error. For good measure, also rechecked all of the other solder joints, and didn't see any other problems, including the jumpers for hi-speed (I put the jumper pins in individually w/o the plastic "joiner" and then slipped the joiner over them so I could see that the solder flowed through. Also did a continuity test on the switches and jumpers.

> Just because it boots successfully doesn't mean the drive geometry used by the BIOS is compatible with the geometry on the disk.

The same CF card boots and runs FreeDOS successfully on the GW 1.1.5 build, and on a different xt-ide board running 2.0.0b3 R618. Perhaps I'm missing something, but I'm taking that to mean that the geometry is okay independent of the xt-ide version (in this particular instance). This is on the same IBM 5150 (but not both xtide cards in the machine at the same time). I still get the same behavior as before with 2.0.0b3 R618 on the GW card: in compatibility mode it freezes at "Starting MS-DOS" and in hi-speed mode it doesn't detect the CF card at all, but now I can get that behavior with an 8k or 32k EEPROM.

I also have a scope available if there are any test points on the board that would be useful to observe. No ISA breakout board, but I can poke at the xt-ide card.

 

[Malc]

The same CF card boots and runs FreeDOS successfully on the GW 1.1.5 build, and on a different xt-ide board running 2.0.0b3 R618

Expected if you originally setup the CF card on the GW 1.1.5 build and then upgraded to XUB R618 and using the same CF card.

Though i got to admit i'm a little confused, You mention the GW XTIDE and " Different XTIDE ", What Different XTIDE ?

What size CF cards are you using ?

See Modem7's website for info on setting up the GW R4 XTIDE it may help, http://minuszerodegrees.net/xtide/rev_4/XT-IDE Rev 4 - general.htm

 

[dmuntz]

I got an xt-ide card in an old pc I picked up some time ago. Dug it out and started playing with it. It was from "blue lava" and I recently ordered another from them. Then I found out glitch did the original, so I ordered the kit via their tindie page (loving the DS1742W replacements btw!).

For booting, I've been using 64MB cards. I have a 256MB that isn't bootable, but I've used it as a slave occasionally for moving data.

I've been heavily relying on Modem7's site.

 

[Malc]

On the GW card in Compatibility mode you must configure the XUB r618 and choose Controller type as XTIDE rev 1 using XTIDECFG.com.

If you then move the jumpers to HI Speed mode you must reconfigure the XUB and choose controller type XTIDE rev 2 or modded rev 1

You just as well use the latest revision of the XUB r622, When flashing the EEprom make sure you are using the correct eeprom type, 2864 (8 kiB) or 28256 (32 kiB) and all the jumpers / switches are set correctly on the GW card.

 

[dmuntz]

Turns out, BOTH of the 74LS245 chips that came in the parts kit from GW were bad. Not sure why the card works with 1.1.5, but replacing both chips (not just 1) gets the _new_ card working with R622, slow and fast.

How did I find this out? I ordered a second bare card and assembled it with the old chips (all were socketed), and the new board behaved the exact same way. Note that all the chips have always been socketed (I'm paranoid about soldering directly to ICs if I can avoid it), so it's more than likely the 245 chips were bad from the start. It's interesting that they work well enough with 1.1.5, but fail with 2.0.0b3 regardless of rev1/rev2 and speed setting. Unfortunately, the original card is somewhat the worse for wear since I did multiple resolderings and reuse of parts, but the 2nd card now appears to be completely functional with a pair of 245s from amazon. Might have to order another bare board now that I have duplicates of almost all of the parts.

 

[glitch]

Huh, pretty weird! Those come new from IIRC Mouser (if not Mouser then Digi-Key, Allied, etc.). We had issues in the past with defective 74F573s from Jameco, to the point that we stopped ordering from them, but haven't had any issues with this batch of '245s. I believe we'd ordered QTY 1000 on that batch!

What machine are you using these in?

 

[Krille]

Interesting! Could this be the reason why so many people are supposedly having problems with anything newer than XUB 1.1.5?

 

[Malc]

Interesting! Could this be the reason why so many people are supposedly having problems with anything newer than XUB 1.1.5?

No it's not high on my list of reasons, Though Unfortunately it happens to the best of suppliers, Some bad / Borderline IC's will get through on occasions and sent out to customers though i've found this to be rare, But i don't build as much as Glitch does. Anything could have happened subsequent handling, static damage etc etc.

 

[glitch]

Interesting! Could this be the reason why so many people are supposedly having problems with anything newer than XUB 1.1.5?

Very unlikely. I think that v1.1.5 is just more tolerant of marginal systems, for whatever reason.

 

[dmuntz]

Huh, pretty weird! Those come new from IIRC Mouser (if not Mouser then Digi-Key, Allied, etc.). We had issues in the past with defective 74F573s from Jameco, to the point that we stopped ordering from them, but haven't had any issues with this batch of '245s. I believe we'd ordered QTY 1000 on that batch!

What machine are you using these in?

I've used them in 3 different IBM 5150s, and with a Supermicro S2DGU (Pentium II Xeon, 450mHz, 5 PCI, 2 ISA). Yeah, I'd normally trust Digi-Key and Mouser (way, way) over Amazon, but I was able to get one kit that had almost all of the chips I wanted to swap, plus free next-day shipping.

> Interesting! Could this be the reason why so many people are supposedly having problems with anything newer than XUB 1.1.5?

Oh? If this might be an issue, for the record the original chips were Motorola, and the replacements are TI. I'll drop in an edit or follow-up with the actual numbers on the chips later.

Edit:
working chips are TI: 14XLD6K E4 (E4 underlined) SN74LS245N
"marginal" chips are: MC74ACT245N XXAD9321

 

[hornbetw]

74LS and 74ACT chips have slightly different timing. You might be picking up noise on the ACT that the LS isn't fast enough to respond too.

Tom

 

[dmuntz]

74LS and 74ACT chips have slightly different timing. You might be picking up noise on the ACT that the LS isn't fast enough to respond too.

Tom

If anyone has a tweak to the circuit to try to test this, I can give it a shot since I can reliably reproduce the problem

 

[glitch]

74LS and 74ACT chips have slightly different timing. You might be picking up noise on the ACT that the LS isn't fast enough to respond too.

Tom

That is a pretty likely culprit -- my guess as well but I have no actual data to back that up. Weird that the v1.1.5 XUB doesn't care though! The EEPROM sits directly on the ISA bus, its data lines aren't buffered through the '245s. So, it's got to be something related to the actual IDE interface.

 

[Malc]

I use HC and HCT series in my R4 cards, No problems with v1.1.5 or later.

 

[Chromedome45]

I have had issues too with the LS245 on the Rev 4 board. One just went out and I don't know why. I did replace it and now all is well. Kind of strange it doing that. It was the Top most LS245 that went. Luckily I had it docketed.

I did verify the chip was bad with my Retro Chip Tester. Definitely a piece test equipment to have. Especially if your dealing with older tech like we are. Link if interested. https://8bit-museum.de/sonstiges/hardware-projekte/hardware-projekte-chip-tester-english/ It comes as 2 boards and you have to order all the components to build it.
From Digi-Key or Mouser.

Just be advised it may take 2 to 3 weeks to get the 2 circuit boards from Germany.