Reviewing everything, it seemed like the issue was related to the boot sectors, because the computers would post, but fail when they tried to load the OS.

Playing around with the 286, thought I'd try making a boot disk on that computer using its own drive to make the boot disk would change anything. Maybe it's drive alignment. It's not drive alignment. Turns out the computer won't boot DOS 7.1 / Win98se. The computer boots Dos 6.22 fine & stable. Maybe this is related to the fact that it needs /MACHINE:1 parameter to make himem.sys work. Maybe. In hindsight, all of the preformatted hard drives that I have been trying in that computer had DOS 7.1 on them, so that clears that up. The 286 does not like off the shelf DOS 7.1. Maybe there's a msdos.sys parameter that will fix it.

Now I could get the computer to boot from floppy but I still could not get any drive overlay software to install on that computer so I took the 6.22 boot floppy to the 386sx to set up a preconfigured drive. While I was there, I thought I'd try booting off the DOS 6.22 disk on the 386 to see if that made any difference. It promptly corrupted the EZ drive installation. So boot sector virus. Had to find a copy of f-prot for DOS. Had to set the system dates back to July 2006 so that f-prot would run. Takes about 3 minutes for the 386sx -16 to start f-prot from CF. "Stoned.E" virus, still kick'n it 1988 style. Got it on 3 CFs and 2 floppy disks. All cleared up. Well except for the gateway that lost its boot sector, but that's a problem for tomorrow.

Anyway, surprisingly that didn't change much. Removing the virus didn't fix the drive overlay installation issues on the 286. I was able to get a drive prepped on the 386sx with EZ drive 9.09w and the 286 is all good for now. I'll go back and investigate why DOS 7.1 won't run on this computer tomorrow.

The JC2050b 386sx motherboard is very fussy with both the Chips BIOS and MrBIOS. If it doesn't like a storage device, it won't it won't boot from floppy if the BIOS has the drive configured in any manner, regardless of the geometry. It even locks hard in the config screen if I ask MRBIOS to auto populate the geometry. That's how it is with most large storage devices. Curiously, not all large storage devices. For example, I found a 4GB CF (detected C7769 H16 S63), that doesn't make it crash immediately. The computer will boot from a floppy without any rom extensions when the drive is installed, even with 7769 cylinders. I can partition the drive to the full size and start to format the 4GB drive. That's as far as I get. The computer always locks while calculating free space. So there's probably still the same issue. The large geometry is causing an overflow somewhere, but this particular 4GB devices's geometry just doesn't immediately overwrite a critical spot in memory, so it takes a while to crash. I tried setting the drive size smaller. Tried disabling translation in the bios. Tried clearing the large landing zone number. Tried adding Xtide UB, but no luck either. Only works with the SIIG option rom.

Looking at the SIIG autodetection more closely, it does Extended CHS mapping. (8.4GB limit) I'm able to use large storage devices on this system if I let the SIIG bios create an Extended CHS mapping for the device, and then use that to boot EZ Drive. Kind of convoluted.

So right now, I have a C4064 H16 S63 device installed, MRBIOS & XTIDE both try to use that geometry and both lock up. But the SIIG sees it as C1016 H64 S63 and must patch whatever is causing the overflows. And then EZ Drive takes over and switches everything back to C4064 H16 S63 . And everything runs stable

Maybe I can make this work with XtideUB if I create a custom BIOS config that forces the uses Cylinders < 1025 and then install EZ drive on top of that. Maybe tomorrow.