Well, either the BIOS takes different code path on that mobo vs PCem, or there is some sort of issue preventing correct operation of the XT-IDE cards and the ROMs aren't detected at boot.
Things to try:
- Setting the HDD parametrs to Not Installed. I have vague recollection of some old BIOS not working correctly when I tried to input CHS values larger than 504MiB limit. But I don't remember the details now.
- Enabling shadowing for the system and video ROMs. Now that the BIOS has been dumped with correct checksum it shouldn't break anything, and will offer some performance boost in DOS (but not games).
- Trying different video card (if OP has any). It's a long shot, but maybe some weird behaviour of video ROM confuses BIOS. Worth a try unless it requires money being spent.
- A different host for the XTIDE ROM - like a network card with ROM socket. That I would even spend money on. I can recommend 3Com Etherlink III series 3C509B - I have one with AT28C64B EEPROM on it and it works. Might require configuration via software, but that can be run from a floppy.

Predator99 wrote on 2022-02-10, 10:35:

Unlikely...but maybe jdmcs can check: debug d c000:0 q […]
Show full quote

Unlikely...but maybe jdmcs can check:
debug
d c000:0
q

I decrypted the whole image and the only text I see is:
386sx-BIOS (C) 1989 American Megatrends Inc.
(C) 1991 Emerson Computer Corp.

The BIOS-ID string is still unvisible...maybe it uses another encryption method. Dont know why AMI did this. Maybe they liked to prevent somebody steals the BIOS and just enters another manufcacturer name...easy patch 😀

Looks like the VGA BIOS is at C000:

Just don't dare put this Oak VGA card in an IBM, it's not for it...

I actually bought a better video card for this computer earlier in the week. I'll try it when it comes in.

Also, I'm still waiting on 28C64B's, so I can't yet try anything else on the XT-IDE. But I will consider finding a 3COM NIC for hosting the XT-IDE BIOS.

What's the speed rating of your EEPROMs? I've been using 150ns part in my 3Com. The reason I'm suggesting a network card for hosting the ROM is because I suspect your mobo ISA might be a bit quirky, like some 286 mobos were. I don't see a whole lot of buffer chips or terminating resistor packs on it. It would only take one bit glitch during the checksum calculation to reject the extension and not load it, and I don't think the host cards you currently have actually do anything to help with that, like add extra wait states. The assumption is the system will be slow enough not to need it, or modern enough to be properly designed. 286 era mobos are somewhat in the middle of that though...

If you wish I can create a small executable to test your setup for glitches I mentioned. It would just run a loop and test the checksum for a given memory address to see if always matches. Unlike visual inspection in debug that would work at full CPU/bus speed, which might be a factor.
Also, do try to test the ROM cards in both first and last of the ISA slots. Sometimes signal integrity is considerably better on one of the ends, usually the end near the driver chips (so next to PSU connector in your case) but not always.

I hope you fellow Vogons didn't think I had forgotten about you... but I received the "New" AT28C64B's from Amazon (and they were every bit of a hot mess as the reviews indicated). Four were not blank and one arrived with a broken GND pin. Any other year, and I would have already started the return process. But I digress.

Predator99 wrote on 2022-02-09, 06:14:

Ok, will take a look later. Can you try to start the y2k Rom with the debug method?

The plot thickens - I didn't have to:

All I did was write the Y2KDR.BIN file I downloaded from archive.org to an AT28C64B using my TL866A, and insert it into the XT-IDE card configured for D000. And in the same slot I had been trying to use. I didn't even do anything about the issues with the ROM dump that some folks noticed.

jdmcs wrote on 2022-02-12, 20:24:

I received the "New" AT28C64B's from Amazon (and they were every bit of a hot mess as the reviews indicated). Four were not blank and one arrived with a broken GND pin.

Welcome to chip shortage, 2022 edition. Fakes and "recycled" chips were always an issue, but lately it's been the norm and not exception, unless you're buying from big distributors and can afford their prices while waiting weeks for restocking.
Anyway, I forgot to ask, what capture method are you using to produce these nice screenshots?

Winner, winner, chicken dinner!

Apparently the issue was with how I was programming the BIOS, but I don't think I did anything that someone else might not try: I was using the xtidecfg program to write images to the XT-IDE, and I was using Lo-tech's flash program to write images to the XT-CF lite. I even tried that as soon as I had the "new" chips, and that image didn't actually boot.

But I got suspicious when the Y2KDR.bin file did work, and that's when I tried writing the ide_386.bin image using the TL866A, and it worked, too. Just the one I had saved was configured for the XT-IDE only, so what you see above is a reconfigured ide_386.bin to use the on-board IDE instead. And I didn't even have to set the HDD type to None in Setup.

So it looks like something was getting corrupted while xtidecfg was writing the 28C64B, or shortly afterwards. Sure would be nice if it had a verify option to check what it just wrote... maybe now that I have a few 28C64B's, maybe I'll try writing another with xtidecfg and then use the MiniPro software to see what is different between the two.

Also, I should probably note that the Lo-tech flash utility still continues to not identify the flash chip on the XT-CF. The MiniPro software correctly identifies the chip. Maybe the weird thing about this Emerson PC isn't its AMI BIOS, but whatever about its ISA bus is preventing these flash utilities from doing their job... or maybe these flash utilities just don't work so well on a 386.

Deunan wrote on 2022-02-12, 20:44:

Anyway, I forgot to ask, what capture method are you using to produce these nice screenshots?

I have the VGA output going to my VisionAV-HD capture card, and I'm just using the included Vision Window program to capture a still image of the screen.

Deunan wrote on 2022-02-11, 09:42:

What's the speed rating of your EEPROMs?

The new EEPROMS I got are marked 150ns. They have obviously been remarked (it's so obvious I don't need acetone to confirm), so there's no telling if they actually are 150ns parts...

The old EEPROM was also 150ns. It looks like it might have been an original Atmel part and not a remark.

Deunan wrote on 2022-02-11, 09:42:

The reason I'm suggesting a network card for hosting the ROM is because I suspect your mobo ISA might be a bit quirky, like some 286 mobos were. I don't see a whole lot of buffer chips or terminating resistor packs on it. It would only take one bit glitch during the checksum calculation to reject the extension and not load it, and I don't think the host cards you currently have actually do anything to help with that, like add extra wait states. The assumption is the system will be slow enough not to need it, or modern enough to be properly designed. 286 era mobos are somewhat in the middle of that though...

I'd rather have a 16-bit network card if I'm going to use the on-board 16-bit IDE. I have a few on my eBay Watch List, just waiting for pay day. I'll probably get a 3COM 3C509, as I remember those to be reliable and the software is readily available. Plus I've always liked the Parallel Tasking logo on the main chip.

Deunan wrote on 2022-02-11, 09:42:

If you wish I can create a small executable to test your setup for glitches I mentioned. It would just run a loop and test the checksum for a given memory address to see if always matches. Unlike visual inspection in debug that would work at full CPU/bus speed, which might be a factor.

Sure, we could rule that out. Would be nice to know if there is some underlying issue.

Deunan wrote on 2022-02-11, 09:42:

Also, do try to test the ROM cards in both first and last of the ISA slots. Sometimes signal integrity is considerably better on one of the ends, usually the end near the driver chips (so next to PSU connector in your case) but not always.

I didn't have to try a different slot. I've been putting the XT-IDE in the 8-bit slot closest to the power connector, except for the few times I tried the 16-bit slot right beside the power connector.

To catch up on things that I was asked to try...

aitotat wrote on 2022-02-09, 06:15:

But that is not why the XTIDE ROM is not detected. Do you use EEPROMs without software data protection or did you disable SDP when flashing with xtidecfg.com? If that is the case, then you need to enable the write protect jumper or DIP switch on the XTIDE card. Any write attempt to the ROM will corrupt it if SDP or write protect jumper is not used. And a single corrupted byte will invalidate the checksum byte so the ROM is not detected.

I was using EEPROMS that were erased using the TL886A. I believe that there is no SDP when they are blank. However, I do not know if xtidecfg enables SDP after writing. (I do know that the MiniPro software defaults to enabling SDP, and I was using its default setting.) EDIT: I forgot: xtidecfg also defaults to enabling SDP.

aitotat wrote on 2022-02-10, 05:39:

Have you tried with different VGA card? Maybe the VGA BIOS reports wrong size or does something strange. Very unlikely but something to try.

Try, yes.

Success, no. (The fact that the eBay Seller put "Tested" in quotes should have been a Red Alert. Back to the eBay Seller that card goes...)

I guess my upgrade to a Tseng Labs ET4000-based graphics card will have to wait for another day.

Deunan wrote on 2022-02-10, 23:41:

Things to try:
- Setting the HDD parametrs to Not Installed. I have vague recollection of some old BIOS not working correctly when I tried to input CHS values larger than 504MiB limit. But I don't remember the details now.
- Enabling shadowing for the system and video ROMs. Now that the BIOS has been dumped with correct checksum it shouldn't break anything, and will offer some performance boost in DOS (but not games).

The cold boot memory test is much faster now with shadowing enabled, which is good because this computer is about to get another 4MB of memory. And I've been able to do more debugging in less time!

The BIOS gets angry if you have a hard drive plugged into the on-board IDE port, and either have on-board IDE disabled, or have the HDD type set to none. My Vibra 16 does have an IDE port (which I currently have disabled), maybe I'll disable the on-board IDE and enable that IDE in its place to get around that BIOS POST error.

I'll try to code some tester for you in a day or two, unless something derails my schedule. Now that you have the ROMs working, I bet the issue was the programming, not reading. This might have been a waste of time for you but I actually found this discovery quite useful. I always use external programmers and network cards as hosts so I have no actual experience with the XT-IDE PCBs. Now I know what to expect.

BTW that bad graphics card, that looks like a bad memory chip. If these are socketed, try swapping them around - if it's just bad contact it'll go away, if bad chip it'll change the pattern. It might be possible to figure out which chip it is and replace it. Soldered ones are obviously more problematic but also fixable.

EDIT: Oh, I see your BIOS doesn't like not detected HDDs connected. I suggested to set it to none because sometimes the CHS parameters of big HDDs (or CF cards) prevent BIOS from booting, or cause other issues. And you don't need anything there when using XT-IDE ROM. If, for some reason, your sytems now sees 2 HDDs (one from BIOS, one from XT-IDE), then there's an option to remove duplicates in the config. I had such an issue once so that's how I know 😀

Stop the press! I just used xtidecfg to write a BIOS in-system, and it booted from it!

The only thing I did differently was that before hitting ENTER at the reboot prompt, I reached inside the computer and flipped the WR switch to OFF (write protect).

And I just used the TL866A to confirm that the contents of the chip exactly match the file on my floppy disk.

So either:

• I just got lucky. (I'm not playing the lottery tonight, I don't feel that lucky.)
• xtidecfg isn't sending the SDP command even though that selection is enabled.
• Something weird happens on the ISA bus even during a warm reboot.

As one last test, I programmed a chip using the TL866A, verifying that it said that it had enabled SDP. I then put that chip into the XT-IDE, flipped WR back to ON (write enable), and tried several warm reboots and power cycles. The XT-IDE BIOS loaded each time, which would seem to indicate that either I gave up too early, or that xtidecfg isn't actually enabling SDP.

Or, I guess that I still could have gotten lucky that whatever is glitching during a write didn't happen that time. Some of what now appears to be failed writes did appear to be correct, so maybe some of the attempts had a very small number of errors. Though I think one of my earlier posts did show what now appears to be a significantly-failed write.

Unfortunately, I'm about to break one of the contacts in the IC socket on my XT-IDE due to removing and re-inserting chips, so I'm going to stop trying things for the weekend so I can get some retro enjoyment out of this computer.

Slightly OT:

Deunan wrote on 2022-02-12, 22:20:

BTW that bad graphics card, that looks like a bad memory chip. If these are socketed, try swapping them around - if it's just bad contact it'll go away, if bad chip it'll change the pattern. It might be possible to figure out which chip it is and replace it. Soldered ones are obviously more problematic but also fixable.

Oh, I probably know which chip on that graphics card is bad...

If that were the only issue, I might have tried some debugging. But that video card crossed a line:

Even if there is something quirky weird with my Emerson Elite, that video card was in poor shape, and not worth risking the seller trying to claim that I had attempted to repair it and that is why it failed.

If anyone is wondering, the display became unreadable when it switched to the video mode that the System BIOS uses. I was not able to use it for any testing, though I think I've seen enough to show that would have come to the same conclusion as the original video card.

Bad news is that I can't get the IDE port on the Vibra 16 to play nicely. xtidecfg never detects it, and even when I manually configured it in xtidecfg with the same settings as I jumpered, the XT-IDE BIOS never detected the HDD on that port.

Good news is the XT-IDE BIOS takes the place of EZ-BIOS. I never liked Dynamic Drive Overlays anyways. (Still limited to 8.4GB, as I have to keep the HDD jumpered in its 4092 cylinder limit mode to make the System BIOS happy. But hay, no extra software needed now!)

Baby steps.

Here's the app, it's a very simple one but should do the job. It finds a ROM extension by the signature, makes sure the size byte is sane and then runs 1024 passes of checksum calculation. This might take a minute or two on slower machines. The app will abort earlier if something isn't right, and will show the count of passes it tried. It takes one parameter - the segment from which it should start scanning, if ommited (or invalid) it'll start with C800 to skip the video ROM.

Example: BIOSEXT D000

This will start scanning from D000 segment up. To check the video ROM simply use C000. Scan ends at first found extension or F000 since even if the BIOS has it's own extension, like a diagnostic module, it often has a bad checksum - but BIOS doesn't care because it's a trusted code I guess and/or it passed BIOS self-check earlier.

Keep in mind extension ROMs need to be aligned to 2KiB pages, and the parameter passed will be aligned too if necessary. It is possible to have 128k size extensions but I've never seen one so this app, being 16-bit code, is limited to 64k ones. It should run on anything really, 8086+ and DOS2+. Assuming there are no bugs, I only tested it in emulator due to lack of time.

Deunan wrote on 2022-02-14, 14:24:

Here's the app, it's a very simple one but should do the job. It finds a ROM extension by the signature, makes sure the size byt […]
Show full quote

Here's the app, it's a very simple one but should do the job. It finds a ROM extension by the signature, makes sure the size byte is sane and then runs 1024 passes of checksum calculation. This might take a minute or two on slower machines. The app will abort earlier if something isn't right, and will show the count of passes it tried. It takes one parameter - the segment from which it should start scanning, if ommited (or invalid) it'll start with C800 to skip the video ROM.

Example: BIOSEXT D000

This will start scanning from D000 segment up. To check the video ROM simply use C000. Scan ends at first found extension or F000 since even if the BIOS has it's own extension, like a diagnostic module, it often has a bad checksum - but BIOS doesn't care because it's a trusted code I guess and/or it passed BIOS self-check earlier.

Keep in mind extension ROMs need to be aligned to 2KiB pages, and the parameter passed will be aligned too if necessary. It is possible to have 128k size extensions but I've never seen one so this app, being 16-bit code, is limited to 64k ones. It should run on anything really, 8086+ and DOS2+. Assuming there are no bugs, I only tested it in emulator due to lack of time.

I ran the utility on both the VGA and the XT-IDE BIOSes, with shadowing disabled, several times each. No problems were detected.

So it looks like the issue might have been the xtidecfg program not actually enabling SDP, the XT-IDE BIOS being corrupted during the reboot, thus the checksum failed. Too bad the AMI BIOS doesn't print an error message for that like it does for other errors (hello, "Keyboard Not Found. Press F1 to Run Setup.")... I suppose a bug report to the XT-IDE team may be in order.