I've just managed to finish the tests where it's failing in UniPCemu (test number 9 to be exact is where it's failing).
I really think that the weird 5E/5Fh 64KB segment (so memory area 5E0000-5FFFFF) is something weird for it to be addressing always.
Perhaps it has something to do with the ROM shadowing it's performing? It seems to match a slightly different scheme compared to the other tests (the other tests set different bits in their error variables (bit 0 to be exact), while this tests sets bit 1 in those instead). Those error bits being different aren't just for the normal tests (the writing and reading back data from memory and checking for errors). That applies to the bits for the I/O memory check of the PPI chip of the XT as well.
That test is a very suspicious one, probably the one that causes the weird error in UniPCemu at least?
Edit: OK. Managed to get all of those tests (up to test number 15) of the Init function disassembled and documented so far.
Although the I/O to port A0h is still suspicious, the remaining tests after test 9 are just reading of various ROMs and adjusting interrupt vectors to itself (hooking them).
Thus:
test1: display initial labels
test2: test processor flags register
test3: validate running in real mode
test4: detect if driver is already loaded
test5: parse command line
test6: various waitstate parameter checks
test7: some 640KB memory test
test8: setup protected mode IDTR storage and some small memory storage
test9: extended memory checks and ROM(as well as RAM emulating ROM) checks.
test10: seems to copy the BIOS ROM to 5F0000 and perform some interrupt hooking logic on the IVT.
test11: setup speed setting
test12: performs EGA ROM shadowing
test13: install disk speed interrupt handler
test14: install IRQ1 handler
test15: install #UD handler
Edit: Managed to get most of the driver disassembled and documented somewhat (at least the parts that matter).
Afaik the only unknown function in the driver is some print string function at address BABE (LOL). You'd almost think that's intentional 🤣
The 5Eh 64KB segment (so at 5E0000h in physical memory) seems to be the most interesting.
Especially when you notice that 5F0000h seems to have something to do with the BIOS ROM part in test 9 (according to it's GDT when performing the copying using INT15h). That would probably make 5E0000 the base of the EGA ROM before it's remapped?
Edit: Making a memory dump and looking at those error flags, at 34978 in the memory dump (B8C:90B8 (14978 in linear memory) as seem from the emulator, which is displaced by 128KB reserved RAM (for the ROM shadowing) upwards), it reveals the error data stored in the error variables: condition 02h (which means it's the 5E/5F 64K area that's faulting) and erroring bits 00000004h in it's 32-bit read/write errors.
That's a weird place for it to be faulting? The memory should be mapped in (due to the port A0 being 0 while testing the memory area). So it shouldn't fault?
Edit: OK. So it's writing the patterns to memory (fist all ones, then all even bits (01010101b), then all zeroes. But in all cases, the memory somehow keeps being stuck at all-ones? Even though the memory should actually be there? Hmmm...
Edit: OK. So the memory is unmapped for some reason.
Even in that case, looking further it's just enabling the NMI interrupts to take place using port A0h on the XT.