Well, somewhere directly after that(probably first DMA I/O port being accessed and faulting because of the TSS blocking the ports by default(all cleared entries afaik)), it starts the Virtual 8086 monitor, which somehow goes REALLY WRONG and somehow corrupts some/most registers with invalid values(I see most registers filled with large 32-bit quantities, sometimes even as early as entering the monitor from Virtual 8086 mode(Directly after the interrupt has completed???). It's executing a ridiculously large loop of 0x2XXXXXXX entires for some odd reason(ECX contains the value 0x2XXXXXXX(XXXXXXXX being some random-like number))? It's using a LOOP instruction to count down using that counter, locking the Virtual 8086 monitor into a big loop that will finish in a long long period(the CPU running at 16MHz, so not so many loops/second).
The INSB is done either by MS-DOS or one of the drivers(don't know about the Compaq Deskpro 386 accessing that port?). I know segment 2AAh contains the EMM386.SYS driver of Windows 3.0(which should have already completed it's basic setup, having already run the VIDE-CDD.SYS device driver). The next program that should run to the old config.sys(just upgraded it to MS-DOS 6.22 for easier configuration switching(without having to convert my 2GB back and forth between it's small sfdimg disk image format(only 100MB) and it's full static image format(flat disk image)).
I did notice some oddities with the FDC when trying to install MS-DOS 6.22(using a simple "SYS c:" and copying the remaining files manually to the C:\MSDOS directory using WinImage): at odd moments, the IBM AT BIOS seems to not detect the FDC as being ready anymore(requiring multiple (R)etries to transfer the OS to the hard disk image). Eventually it succeeds copying the system files, though. Immediately after that, I've modified my config.sys and autoexec.bat to add a simple boot menu allowing me to switch between IBM XT, AT and Compaq Deskpro 386 configurations(instead of having to continuously change the harddisk image itself to do that:S ). So far it seems to be working without many problems(although it seems to have large hard disk delays for some odd reason now, but that could be due to the hard disk emulation itself.
I've adjusted the FDC a bit to allow improved detection of the 40-track vs 80-track drives(keeping a virtual head to detect track 0 with seperate, which doesn't move past 40 tracks or 80 tracks depending on the disk image). That way the seek-to-track48 and backtrack-to-track 0 will properly detect the 40-track drives(40 track drives give track0 at physical track 0/reported track 8, while 80-track drives will give track 0 at track 0(as it does move past track 40 when executing the pulses). But oddly enough, the AT BIOS seems to issue the SEEK to track 48 and then completely gives up? The SEEKING bit in the MSR is set properly(cleared when completed seeking to the FDC's idea of track 48), but when it's completing the seek(the same way as a recalibrate, roughly, but can be in two directions: towards higher cylinders or lower cylinders, using virtual step pulses(timer timing out each simulated 'pulse')) the IBM AT BIOS has already given the 601-Diskette error?
Looking at the config.sys/autoexec.bat, I notice that the point it's going wrong seems to be the MS-DOS 6.22 mouse.com executing? It's called as "mouse /Y"? The program after that is MSCDEX for CD-ROM support, but it doesn't get that far it seems? Or it's something within MS-DOS itself(IO.SYS/MSDOS.SYS) that's going wrong?
I've also added a slight delay when issuing the hard disk IRQs(of 2us, compared to the ATAPI 20us(also when finishing an ATAPI command)) to allow the driver/BIOS to set some flag before checking the response from the hard disk, but I still see the HDD BIOS(XT-IDE Universal BIOS) waiting for the disk IRQ when it's seems to have completed the Read Multiple(up to 0x80 sectors) command? This seems to happen at least directly after detecting the hard disks(It's reporting them correctly after the ATA IDENTIFY command has been issued)?