XT-IDE rev 4 and a 32 MB CF

The 5160 has a 32 MB CF card as D: now. The XT-IDE rev 4 went together without any trouble, the solder joints are fine, and the card came up on the first boot once the address switches were set. What I did not expect is the 5271. The same card would not run its option ROM there at all until the machine had warmed up, and the one time it did run, it froze.

The 5271 in this story is not a stock 3270 PC, whatever the model number says. All the 3270 hardware is out of it, the IBM 6320984 display adapter and the host connect card both, and I run it as a plain XT. For every dump below, the bus held a VGA card, a serial card, the WD1002A-WX1 MFM controller, the floppy controller, the Inboard 386/PC and the XT-IDE. Nothing else in there wants D000h.

What XTIDECFG actually changes

The official XTIDE site was timing out, so r638 came off the minuszerodegrees mirror instead (direct zip). I ran XTIDECFG under DOSBox-X 2026.06.02 on the Mac, macOS ARM with SDL2, rather than on the machine, which saves a lot of chip swapping. I tried to drive the menus with AUTOTYPE and it drifted on the longer key sequences, so I finished the picks by hand.

Stock ide_386.bin arrives set up for an ordinary AT controller: 16-bit device type, base 1F0h, control block 3F0h, IRQ 14, two IDE controllers. None of that suits an XT-IDE card. Picking the “XTIDE rev 2 or modded rev 1” profile filled in 300h and 308h and turned interrupts off by itself, and I dropped the controller count to 1 by hand. That comes to six bytes in the image:

0x48   02 -> 01   IDE controllers, 2 to 1
0x4E   F0 -> 00   base low
0x4F   01 -> 03   base high, 01F0h becomes 0300h
0x50   F0 -> 08   control block low, 03F0h becomes 0308h
0x52   00 -> 0A   device type, XTIDE rev 2 or modded rev 1
0x53   0E -> 00   IRQ 14 to interrupts off

0x51 was already 03 and stays there. Stock is 7566 bytes and the saved image is 8192. The declared size byte at 0x02 is 0x10, sixteen 512-byte blocks. The checksum byte at 0x1FFF came out 0x1A, which makes the whole image sum to zero mod 256. XTIDECFG also wrote 0x1FFD = 1A and 0x1FFE = E6, which cancel between themselves and so leave the checksum alone. I have not worked out what those two are for. md5 of the configured 386 image is db1d826432570944f6d92688a2efc0af.

The XT+ build did not go through XTIDECFG at all. Once I had checked that patching by hand reproduced the XTIDECFG output byte for byte, apart from those two neutral bytes, I patched ide_xtp.bin directly. Stock xtp already had 0x48 = 01, 0x4E and 0x4F = 00 03, and 0x53 = 00, so only three bytes needed changing: 0x50 = 08, 0x51 = 03, 0x52 = 0A. Padded 6629 bytes out to 8192, checksum byte 0xC3, zeros at 0x1FFD and 0x1FFE. I loaded the result back into XTIDECFG under DOSBox-X afterwards and it read it as XTIDE r2 at 300h and 308h.

The T48 runs firmware 00.1.35, which is newer than minipro 0.7.4 expects, so it warns on every operation. Profile is AT28C64B, the plain one rather than AT28C64B(Non-Standard). The chip read back 8192 bytes of FF before the first write, so it arrived blank. Both burns passed minipro’s own verify and an independent read-back whose md5 matched the source file. I left write protect off, no -P, so in-system reflash through the SW2 WR switch is still available.

One thing will trip you up if you follow an older guide. r638 added a Juko D16-X entry at index 3 in the controller list, so “XTIDE rev 2 or modded rev 1” is the sixth item in the menu now instead of the fifth.

I forgot to set the switches

I soldered the card up and put it straight in the machine without setting SW1 or SW2 from my notes. SW1 was still all off, which decodes base 000h. The card did nothing at all and the machine booted to C: exactly as it always does, so there was no symptom to chase, just no D:. The settings that work are in the table above, off the rev 4 jumper and switch tables.

The 301 the machine was throwing around the same time was a keyboard connection problem and had nothing to do with the card, so I spent a while chasing ghosts.

The 5271 reads a different ROM every dump

The card started out in the 5271, so the chip started out carrying ide_386.bin. A DEBUG dump of D000:0 came back with 33 of the 64 bytes wrong. Dumping the same 64 bytes again gave a different set of wrong bytes.

The image should begin 55 AA 10 E9 FB 03 58 55. The two dumps disagree with each other at offset 2, and neither matches:

dump A   55 AE A3 E9 ...

dump B   55 AE 10 E9 FB 97 58 55 42 3E 2B 32 4E 3D 58 E8
         49 36 4A 04 86 6E EB 76 77 B4 73 61 3E 62 42 CD
         4F 53 20 59 C3 8B 36 5C 3D 2D 16 60 76 36 3B 51
         20 D1 32 30 36 36 2D CD 36 2D F3 39 C9 FF 53 92

Counting which data line each wrong bit landed on, across all 33 bad bytes in dump B:

D0 12    D1 16    D2 14    D3  9
D4 17    D5 14    D6 17    D7 14

So nothing is stuck, and nothing is close to stuck. I also checked whether I was reading real ROM data from the wrong address. Single-bit flips on A0 through A12, each of those lines forced low, and each forced high all scored at or below a straight read. A scan of every offset in the 8 KB put the best match at 31 of 64 bytes correct, at offset 0, which is the straight read again. The bytes are not displaced, they are wrong, and they are wrong differently each time I look.

Temperature was the only thing that changed

For a long stretch I could not get the ROM to come up on the 5271 at all. Then one boot it did, and the only thing different was that the machine had been on for a while and was warmer. I changed nothing else.

That is the whole shape of the fault, and it runs the opposite way round to how I read it at the time. Cold, the checksum fails, so the BIOS skips the option ROM without executing a byte of it, and the machine boots DOS normally with DEBUG working fine. Warm, the checksum passes, the code in the chip finally runs, and the machine freezes and does nothing further. Before it froze it got as far as finding the card:

Master at 300h: Hitachi XXM2.3.0
Slave  at 300h: not found

Every boot where I thought the card was behaving was a boot where none of its code had run.

I have measured nothing on the Inboard itself. There is no scope capture, and I have not read or changed its wait state or clock settings. From reading rather than from the bench, the 386/PC has no switches or jumpers, carries 1 MB of 32-bit memory behind an 8-bit I/O bus, shadows ROM under control of I/O port 670h bit 0, takes wait states through ports 670h and 674h, and reserves 128 KB at 5E0000 to 5FFFFF for shadowing. All of that gets set up by a DOS driver loaded out of CONFIG.SYS, which runs after POST, so whatever state the board is in while the BIOS scans for option ROMs is its power-on default.

Someone on classic-computing.de ran a similar combination, a 5160 with an Inboard 386/PC and an XT-IDE, so a different motherboard from mine with the same accelerator. They needed ide_xtp.bin rather than a 386 build to get a banner at all, and even then they saw corrupted boot sectors and mismatched FAT tables whenever anything was written. Their card behaved once the Inboard came out.

Two variables changed at the same time

So I moved the card to the 5160 and burned the hand-patched ide_xtp.bin instead. It worked on the first boot. The ROM runs, prints its banner, finds the CF as master at 300h and boots C: on its own without me pressing anything. Partitioned and formatted, and the FAT looks right.

That is the working D: I wanted, and it is also a useless experiment, because I swapped the machine and the ROM build in one step. The clean test is the chip that works now, unchanged, back in the 5271. If it runs there, the 386 build was the whole story. If it reads garbage again, the problem is in that machine and the Inboard is the thing to start measuring.

I should be straight about why the card was in the 5271 to begin with. I wanted a CF card working somewhere, and that machine was the one on the bench. The Inboard was never the project. Now it has made itself into one, and I have to pick: work out what the Inboard is doing to an 8-bit option ROM, with a scope on the bus this time, or take it out and put the 5271 back to being a 3270.

Still open

Put the XT+ chip back in the 5271 with the Inboard still fitted and see whether it runs.

Copy a few MB to D: on the 5160, run CHKDSK, reboot and run it again. The failure other people report is silent FAT damage that only appears after writes, so formatting cleanly right after partitioning does not tell me much.

Decide what the 5271 is for. Chase the Inboard properly, or pull it and restore the machine to a 3270.

Find out what XTIDECFG is doing with 0x1FFD and 0x1FFE.

If the Inboard ever comes out of the 5271, that board is a stock 8088 and would want ide_xt.bin, because the XT+ build uses 186 instructions.