jdmcs wrote on 2022-02-08, 01:19:

I set the XT-IDE BIOS to D000 before doing this. It's the same image I programmed over lunch.

What Debug Did.PNG

It then tried to boot from C (which didn't exist as I don't have an IDE to CF adapter), then tried to boot from A (though I never heard the floppy drive), then finally the system displayed the error "NO ROM BASIC SYSTEM HALTED".

OK, perfect. This shows your XT-IDE ROM is working 100%. No surprise your PC crashes, you cannot boot a 2nd time when DOS is already loaded.

Can you do the same with your Y2K ROM please? I like to see if there is any output. If yes, we can be very sure that the issue is related to your Main-BIOS...as suggested by you at the beginning 😁

What your Main-BIOS does at the beginning: It scans the ROM area for the "55 AA" header. If found, it initalizes the ROM with the call "call far xxxx:3". This is the same you did with debug. I have no idea why your BIOS doesnt do that but I will take a closer look at it later.
A fix would be to add the "call far D800:3" to your BIOS-code and everything will work fine...I can do that if nothing else works.

EDIT: Just tried your ROM-image with PCem...there it starts the XT-IDE. This is strange. Please perform the Debug-test with your Y2K-ROM. Then we know if the issue is related to your BIOS or not...

What about the checksum of your XT-IDE image? Can you upload a copy please?

jdmcs wrote on 2022-02-08, 00:31:

Since it's probably off-topic, but for the benefit of the doubt, I'll give you the Justin's Notes version: I used the instructions on the Lo-tech Wiki to append the ROM from a Y2K card archived on archive.org to one of Lo-tech's pre-configured BIOS images before flashing it to the XT-CF Lite.

thanks for the info - got it working just fine 😀
hope your issue gets solved quickly!

Can you also try to program this as your Main-BIOS? Dont know if this works. You have to put your XT-IDE to D000 together with this...

Predator99 wrote on 2022-02-08, 07:53:

What about the checksum of your XT-IDE image? Can you upload a copy please?

Edited because I misread your post with the system BIOS to try and indicated the wrong type of chip I need to order...

I can give you the 386 images I was using, because I saved them to disk. I didn't save the AT image yesterday.

I'll have to order flash chips to try the AMI BIOS you posted. I don't have any 27C256's... at least I decided to hold a UTSource order until the 10th, as I am so bad about placing an order for things I need only to realize I forgot something.

It appears as if the 28C64B that I had was on borrowed time: I successfully soldered a new pin onto VCC, but it's only writing to every other 32-bytes now (so 0-1F is still blank/0xFF's, 20-3F is correct, etc.). I ordered some "new" 28C64B's from Amazon today, but given the reviews I'm expecting to receive 100% used pulls... at least it's an FBA item, because given all of the negative reviews, I'm fully expecting to have to return at least one (hopefully not both) of the 5-packs that I ordered due to massive quantities of bent pins.

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

Those images in xtide386.zip looks good meaning they have the checksum byte and they start with pcem. You should, however, use standard 16-bit IDE controller since you have a 386. Any 16-bit multi-I/O card or non-PnP sound card with IDE will be fine. Then configure the XTIDE ROM for that device. The 8-bit XTIDE is fine on AT+ systems if you use it just for transferring data between computers using CF cards. But I would not use it as a primary boot device.

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.

Edit: You seem to have IDE integrated on the motherboard. Great! Definitely use that.

I have another possible explanation. I took a look at that Y2K ROM and there are some problems with it. First it is a 4k binary but only less than 2k is used. That does not cause problems but the ROM identifies to be 16k and that can cause problems. If it gets executed before XTIDE BIOS, then the ROM scan will jump over the XTIDE BIOS since next ROM will be scanned at Y2K ROM + 16k.

I made a quick fix to the Y2K ROM. It is now 2k and identifies itself as such (and has correct checksum).

Edit: Actually the Y2K ROM shouldn't have worked at all since the checksum byte should have been at 16k-1 but since the binary was 4k it had no valid checksum byte. It is possible but unlikely that there just happened to be correct byte where the checksum was expected.

aitotat wrote on 2022-02-09, 08:24:

I have another possible explanation. I took a look at that Y2K ROM and there are some problems with it. First it is a 4k binary but only less than 2k is used. That does not cause problems but the ROM identifies to be 16k and that can cause problems. If it gets executed before XTIDE BIOS, then the ROM scan will jump over the XTIDE BIOS since next ROM will be scanned at Y2K ROM + 16k.

I made a quick fix to the Y2K ROM. It is now 2k and identifies itself as such (and has correct checksum).

Edit: Actually the Y2K ROM shouldn't have worked at all since the checksum byte should have been at 16k-1 but since the binary was 4k it had no valid checksum byte. It is possible but unlikely that there just happened to be correct byte where the checksum was expected.

interesting... for what it's worth the stock Y2K extension worked fine in a 16kb window alongside XTIDE - Y2K extension located at the last 4kb

it worked with the 2 amstrad systems I tested, 386sx/quadtel and 486slc/amibios - both using it as a NIC bootrom
I will try later the fixed version and use it instead - just in case 😀

I had to try myself (with PCem) and true, if the 4kB Y2K ROM is copied after XTIDE ROM then both will work! The checksum byte could be somewhere else and not at the end of the ROM and it just expects those FFhs until 16k (that would likely be there if no ROMs found after the Y2K ROM). Possible but unlikely since that would make the ROM non working on many systems.

But if the Y2K ROM was copied before XTIDE ROM then it indeed skipped the XTIDE initialization! But Y2K ROM was initialized. I don't know how it passed the checksum test unless the BIOS did no checksum verify at all.

The 2kB modified Y2K ROM did work as expected when it was copied before XTIDE: both initialized.

Also a good idea with the ROM size.

However, in your screenshot I see the message....
Digital Research Technologies, Inc.
DRBIOS 2000 v1.10
....is displayed during inititialization. In jdmcs screenshot I dont see this. Therefore none of the ROMs is executed: Not the XT-IDE and not the Y2K.
This indicates indeed an issue with the main BIOS.

Next problem I notitced (has nothing to do with initialization): IDE Master port is configured to 300h...should be 1F0h

Predator99 wrote on 2022-02-09, 09:45:

[...]
Next problem I notitced (has nothing to do with initialization): IDE Master port is configured to 300h...should be 1F0h

this is normal for jdmcs since he uses a XTIDECF card

keropi wrote on 2022-02-09, 10:00:

this is normal for jdmcs since he uses a XTIDECF card

Yes. I tried the ide_386l.bin on the XF-CF Lite since it had a 32K flash ROM. I think the saved ide_386.bin was the one I used on the XT-IDE Rev. 4, as I only had the one 28C64B.

I was trying to use the defaults on both cards as they did not appear to conflict with the on-board IDE (I think it's at 170h from what xtidecfg auto-detected?).

Also, I was only trying use the Y2K ROM on this computer for debugging in the event that the XT-IDE Universal BIOS was somehow incompatible. Since we're past Y2K, this BIOS isn't having trouble with setting and retaining the year 2022. I'll settle for getting this 386 scanning the XT-IDE BIOS, but I'd like to have it properly scanning for all option ROMs in case I need to use something else in the future (SCSI? network boot?).

And I just looked at the photo of the Y2K card that this ROM is from - I didn't realize that they used a 64K ROM (an SST 29EE512) on it! So when I tried to use this Y2K ROM on my XT-class clone (spoiler alert, the Y2K ROM complained that I didn't have an AT and exited), I did not align the image quite the way I had wanted (I was trying to get it to D000 with the XT-CF Lite at C800, so I was off by 4K).

I took a closer look at your BIOS...just post my Notes here not to loose them 😉

1st I NOPed out the checksum-checks for easier modification. These are
For the Main BIOS:
F000:81BE 7406 JZ 81C6
F000:81C0 BD0900 MOV BP,0009
F000:81C3 E9160C JMP 8DDC

For the Diag-ROM:
F000:937C 754A JNZ 93C8

With this removed I can freely edit everything without getting an error.

My idea was to remove the diagnostic-ROM (1st half) and put the XT-IDE BIOS in instead. However, this seems not to be possible because some parts of the diagnostic-ROM are used by the Main-ROM, i.e. the output of the configuration table that is displayed before boot.

I was surprised I cannot find every string that is displayed on the screen inside the file. I.e. the text "Emerson Computer" seems not to be included in the file.

The trick is that it is encrypted. No idea why AMI did this? This small code at F042 decrypts one byte after one and prints every single letter.

So the bytes at E73C
90 B8 A8 92 BA etc (nonsense)
are converted to
33 38 36 73 78 etc... this is "386sx" which is printed.
Maybe I will write a small tool (if it doesnt exist so far...) which decrypts the whole image and reveals hidden text 😀

I am not 100% sure (difficult to test in PCem) but I think this is the part that scans for option ROMs:

Predator99 wrote on 2022-02-09, 22:30:

I am not 100% sure (difficult to test in PCem) but I think this is the part that scans for option ROMs:

It sort of is, but seems incomplete. Perhaps just not all code fits on the screen? For one, there is a check at 0xF5DF that limits the scan range but we don't know what DX is, so check that. Second, the code as it is shown will keep scanning the addresses in 0x800 increments - or, if it finds the signature, using the extension size. Then it just checks if the flag in CX was set. Any single extension, even something already in BIOS ROM chip, can set the flag. Neither the address of the extension is stored, nor the count. So there should be another piece right below the JCXZ, I guess a jump, that would be the code that actually executes the extensions. Investigate that.

Indeed, its only a part of the code where you can see the "55 AA" is checked and the size at [0002] is read. I didnt find the part where it is executed so far. Should be a "CALL FAR xxxx:3".

But I am almost sure option ROMs are supported by the BIOS...see the screenshot at the top of the page. However, maybe PCem has some special way to include the XT-IDE. As far as I know there is no way to add other option ROMs in PCem.

Here it is called from

F000:F578 CB RETF
F000:F579 58 POP AX
F000:F57A 2428 AND AL,28
F000:F57C 3C20 CMP AL,20
F000:F57E 753E JNZ F5BE
F000:F580 BAED01 MOV DX,01ED
F000:F583 B000 MOV AL,00
F000:F585 EE OUT DX,AL
F000:F586 EB00 JMP F588
F000:F588 EB00 JMP F58A
F000:F58A BAEF01 MOV DX,01EF
F000:F58D EC IN AL,DX
F000:F58E 24F4 AND AL,F4
F000:F590 0C04 OR AL,04
F000:F592 8AD8 MOV BL,AL
F000:F594 EE OUT DX,AL
F000:F595 EB00 JMP F597
F000:F597 EB00 JMP F599
F000:F599 BA00C0 MOV DX,C000
F000:F59C 8EC2 MOV ES,DX
F000:F59E 8EDA MOV DS,DX
F000:F5A0 B6C4 MOV DH,C4
F000:F5A2 B700 MOV BH,00
F000:F5A4 E81A00 CALL F5C1
F000:F5A7 49 DEC CX
F000:F5A8 7414 JZ F5BE
F000:F5AA B701 MOV BH,01
F000:F5AC 8EC2 MOV ES,DX
F000:F5AE 8CD8 MOV AX,DS
F000:F5B0 3BC2 CMP AX,DX
F000:F5B2 B6C8 MOV DH,C8
F000:F5B4 7705 JA F5BB
F000:F5B6 E80800 CALL F5C1
F000:F5B9 EB03 JMP F5BE
F000:F5BB E82A00 CALL F5E8
F000:F5BE 1F POP DS
F000:F5BF 07 POP ES
F000:F5C0 C3 RET

F000:F5C1 33C9 XOR CX,CX
F000:F5C3 813E000055AA CMP WORD PTR [0000],AA55
F000:F5C9 52 PUSH DX
F000:F5CA BA8000 MOV DX,0080
F000:F5CD 7509 JNZ F5D8
F000:F5CF B1FF MOV CL,FF
F000:F5D1 8A160200 MOV DL,[0002]
F000:F5D5 C1 DB C1
F000:F5D6 E205 LOOP F5DD
F000:F5D8 8CD8 MOV AX,DS
F000:F5DA 03C2 ADD AX,DX
F000:F5DC 8ED8 MOV DS,AX
F000:F5DE 5A POP DX
F000:F5DF 3BC2 CMP AX,DX
F000:F5E1 72E0 JB F5C3
F000:F5E3 E302 JCXZ F5E7
F000:F5E5 EB01 JMP F5E8
F000:F5E7 C3 RET
F000:F5E8 1E PUSH DS
F000:F5E9 52 PUSH DX
F000:F5EA 51 PUSH CX
F000:F5EB BAEE01 MOV DX,01EE
F000:F5EE 8AC7 MOV AL,BH
F000:F5F0 EE OUT DX,AL
F000:F5F1 EB00 JMP F5F3

This code only tests range 0xC000-0xC400, and then (depending what was found and how big) 0xC400-0xC800. That looks like video ROM detection and init to me, the actual init is further down below F5F1. Note the code does "weird" I/O access to ports 0x1EE-0x1FF. This is (according to RBIL) "Headland HL21 & Acer M5105 chipsets - SYSTEM CONTROL". Could be RAM remapping, shadowing setup, or extra waitstates.

BTW you can do a far jump without CALL, for example by setting up the stack yourself and doing RETF. I don't see any benefits of that in this kind of code but who knows. It's not very optimal (and I'm not talking about the weird short jumps, these are deliberate delays for the I/O operations).

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

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 😀

I can look at the BIOS code as well, though I'm not sure how much free time I'll have. And to answer OPs early question, yes it is possible to have a 286 chipset (especially if it's not one of the early ones) with 386SX. The pinout is different but the bus itself is mostly compatible if you ignore things like NA signal (which most mobos do anyway).

UPDATE: Just gave it a quick glance, that BIOS is weird. One of the first things it does after a cold boot is check EGA/VGA video memory for a signature, and if found it'll pass execution to there. Is that part of the diagnostics stuff? I don't recall seeing that in other BIOSes with diagnostic ROMs. It also seems to have some sort of security or integrity checks built in that don't make much sense to me.

UPDATE 2: So the extensions ROMs are being executed at 0x96E2, first BIOS outputs 0x80 code and then enters loop that scans from 0xC800 to 0xE000. The procedure called is at 0x8FF3, it will check for 0xAA55 signature, then analyze the size byte and calculate checksum (which should be zero). If checksum is OK it'll call the ROM with code like this:

1901D  STI
2901E  PUSH ES
3901F  PUSH BX
49020  PUSH BP
5
69021  PUSH CS           ; return segment
79022  PUSH 0x9029       ; return offset
89025  PUSH DS
99026  PUSH 3
109028  RETF
11
129029  CLI
13902A  CLD
14902B  POP BP
15902C  POP BX
16902D  POP ES

Well, that's assuming this does get executed since I only did code analysis, not actual runs. I suppose it can be tested by modying that part with something like label: HLT; JMP label and seeing if it freezes or not. I mean the scanning loop, not the testing/calling procedure itself - that should work because it's also used to execute video ROM extension earlier in the boot sequence.

Very good, Deunan! ROM scanning is indeed Code 80 as also confirmed by my POST-card manual:

Error Code – 80
AMI (80)Keyboard test started, clearing output buffer, checking for stuck key, About to
issue keyboard reset command. About to give control to optional ROM in segment
C800 to DE00.

So I replaced the "MOV AL, 80" with "EB FE - Jump to own adress" and it hangs in PCem after the memory counts. Therefore this code is indeed executed and option ROMs should work...

1F000:96E2 B080          MOV	AL,80                              
2F000:96E4 E680          OUT	80,AL                              
3F000:96E6 BB00C8        MOV	BX,C800                            
4F000:96E9 E807F9        CALL	8FF3                               
5F000:96EC 81FB00E0      CMP	BX,E000                            
6F000:96F0 72F7          JB	96E9