I notice something interesting on the primary master: it issues a 0xEC command(Identify), but never reads the result after it's IRQ is fired(status register stays 0x48 from the point the IRQ is raised)?

The CD-ROM drive boots and detects without issues on the secondary ATA drive? I also only see the secondary drive accessing the alternate status register, but not on the primary? Is that maybe because of the"Resource Conflict" mentioned before the memory checking starts?

Anyone knows more about it? The PCI IDE is the only actual PCI hardware. All others are plain ISA(everything Dosbox has as well, minus 3D graphics cards and non-SB and only having plain SB2.0 hardware installed. ThenFDC is at it's legacy address(3F0-3F7(3F7 only bit 7)).

Just split the i430fx architecture from the Compaq Deskpro 386 with PS/2 extensions architecture(effectively making it use it's own CMOS RAM and disabling any Compaq-specific extensions to the AT architecture).

So the Compaq's special 1MB-2MB RAM addressing no longer applies(it now applies to all RAM, so A20 affects just A20, not just the 1MB-2MB memory area like the Compaq Deskpro 386 does).
The Compaq Deskpro 386-specific extensions(mainly, the Compaq Relocation registers and status register(the registers at memory address 80C00000h) are now disabled on said architecture (they would also conflict with said architecture and be unable to support both at the same time, mainly due to the low RAM area mapping without remapping it uses (from 640KB to 1MB)).
The same applies to the 80286 memory hole area(15MB-16MB), which is now managed differently, like a real 80286 does(the BIOS ROM being mapped there as well).

After having improved the ATA harddisk Identify command(0xEC) to set the Drive Seek Complete bit when giving it's results, the AMI BIOS no longer complains about it 😁

Now it just still complains about that "Resource Conflict" and "Cache Memory Error". The Resource Conflict is probably some conflict with IDE hard drives?
But what causes such a "Cache Memory Error"? Is it trying to do something special with the caches that needs implementation(and doesn't run well with uncached I/O)?

Edit: After some HDD autoconfiguration, the Windows 95 RTM HDD image boots without visible issues! It also detects the full 128MB RAM! 😁

Just found a little bug in the caching of the final byte (or addressing within that word or dword past the final byte of the ROM) of BIOS ROMs: When the byte past the final byte of the ROM was addressed, the cache would misbehave and return garbage read from memory, instead of properly terminating access to become it's proper other device or hardware when that happens(the next ROM, start of a RAM block or nothing being connected(0xFF response)).

I've implemented a simple define in the memory registration handler that disables the whole caching behaviour used by the MMU and all conntected hardware on the MMIO bus(so all device handlers but the input/output ports(IN/OUT instructions)). It doesn't seem to have any effect on the error message "Cache Memory Error" that's displayed at the end of the POST.

Anyone knows what this error means? What does it imply?

I noticed someting interesting with the i430fx motherboard BIOS. When I try to boot Hiren's boot CD for running diagnostic software, while the primary master and slave are a HDD (containing WIndows 95 RTM and the second hard drive containing a non-OS(probably not related)) and the secondary master/slave are the CD-ROM drives(The CD-ROM is in the secondary master CD-ROM drive), it will fail to boot the bootable CD-ROM, with a MS-DOS 7.1 error saying it can't locate Windows files for some reason? Isn't CD-ROM booting supposed to circumvent this?

Is this a real issue on said machine? Or is this perhaps an issue with UniPCemu's CPU or hardware emulation for some yet unknown reason?

Did find some bugs in the Keyboard controller chip emulation, though(For opcodes F4,F5,F6, which didn't properly give a result code).

OK. Since PC-Doctor 3.0 can't seem to find any CPU errors, I'm trying the other program that's on the disc(Eurosoft PC-Check 5.50) again. It still says "Loading Drive Library..."...

The last protection fault I actually saw is from a read from port 0x64? Should that actually throw a protection fault with that software?

I see one strange thing happening when saving BIOS configuration changes on the i430fx. When saving the changes, it does actually seem to save the changes, but it's supposed to reboot, which it doesn't? It just seems to hang?

The soft/hard reset functionality is already implemented (and it was working afaik), so why does it hang? Does it require triple faulting?

Also, it seems that booting MS-DOS 6.22 from the hard disk image on the primary master tries to read sector 0x3F(the volume boot record) and then aborts the booting process with an error message(the usual please insert a disk with an OS kind of message)? No IRQ is raised as the transfer completes, which it actually does (it seems the volume boot record is fully read by the MBR code?).
Edit: Floppy boots without issues, though? It's just the MS-DOS HDD boot that's failing on the i430fx machine?
Edit: Just confirmed. Windows 9x boots fine on the i430fx. Only normal MS-DOS (6.22 only, didn't check other MS-DOS versions) seems to fail booting(from the IDE HDD on the i430fx)?
Edit: OK. Found the reason why the boot fails. Reading sector at LBA 3Fh from the disk causes the INT 13h function 02h call to return with the carry flag set? So the interrupt 13h function 02h is failing(while it ran without issue when loading the MBR at sector #0)?

Hmmm... The interrupt returns to the interrupted procedure in the boot sector with the carry flag cleared, but the AL register(interrupt 10h function 02h) is cleared? So that would mean it's read 0 sectors from disk, while it should actually be 1 sectors read instead in AL?
Edit: It does actually seem to correctly read the data to the specified location in memory. So it continues executing the volume boot record from the hard disk at 0000:7c00(when arriving there at the second time).
Edit: So, the second time it reaches 0000:7C00, it will execute the boot record, but the boot volume is the hard disk(disk 80h in DL instead of a normal 00h/01h of the floppy disk).

With regards to both, http://rubbermallet.org/disk.html gives a good description of what's happening.

The issue with it is, during the second time it reaching 0000:7c00, while executing the volume boot record(which is the same as a floppy boot sector), the disk is set to disk 80h. Somehow, the int 13h for function 00h(disk reset) with disk 80h seems to weirdly cause the result to set the carry flag, making the code abort and display the error message. That happens at 7.3.4, at address 7C70. Said interrupt will return with the carry flag set, which it shouldn't?

Edit: OK. The call sets SRST. It wasn't set before, so it activates the ATA/ATAPI SRST handling(resetting the drives). That sets the Drive Seek Complete flag and the drive should become busy.
Edit: Changed SRST and soft reset to change the status register back to 0x00 with the default poweron values in the registers when it's finished. (0x80 during busy, then becomes 0x40 once ready to receive a command).
Edit: Restored it to just setting the DSC bit for hard drives resetting(required to POST successfully).
There might be a little bug with jumping over INT instructions when in single-stepping mode using the emulator's internal debugger (Which I'm using to log the INT 13h call).
It's waiting for the interrupt's start EIP instead of the proper after INT EIP when skipped over using the square button.

OK. It does seem to become properly ready(0x50 in the status register from 0x90 during reset)...

That's read at F000:E745.
Edit: It reads the error register(0x00) after that?
Edit: It doesn't perform any reads/writes after that, aborting INT 13h with carry flag set?
Edit: At F000:8D03, it compares the error register to 1, which it doesn't find, thus reporting error and aborting the INT13 with carry set and AH=00h.
Edit: It seems that was the very cause of it being unable to boot MS-DOS: when resetting a drive (as the ATA-1 spec says) the error register should be 01h.

Although I do seem to remember having to make it 00h in some special case with booting debian Bo(some weird error checking when it's bits were set)?

OK. Found the root of the hard reset problem: A20 is somehow disabled when the reset is made, making the CPU fetch the instructions from FFEFFFFF, which are invalid opcodes (unmapped memory)!

Edit: Fixing A20 to be properly reset to their power on defaults when resetting the CPU in any way(depending on the required reset), it will now properly reboot the machine when a reset is requested, properly being able to reboot when saving BIOS settings changes in the i430fx BIOS.

Booting still seems to fail if I try to set the ATAPI drive to not ready when receiving a normal ATA SRST?

Just found another small hardware bug when testing the PC Doctor software on the i430fx hardware. When the PS/2 controller was reset in some ways(other than a initialization), it would set the PS/2 mouse packet rate to 0 packets/second, which is invalid(it should actually be 100 packets/second). So the PS/2 mouse wasn't responding correctly if it was reset(not reporting anything anymore).

The ATA SRST still needs to have the drive stay ready(bit 6 set) when an ATAPI drive receives the SRST (still properly working with Device Reset(command 08h)).

If the BIOS notices that the device has the ready bit cleared, it won't actually send a ATAPI command to re-enable the registers, thus making it hang permanently on reading anything from the CD-ROM's mounted floppy disk image(which is mounted as logical drive #0)?

Just implemented the i440fx chipset based on Bochs' initial values and device IDs. Also implemented the DRAM memory chip detection based on Bochs' algorithm, but using UniPCemu's method of handling it.
It's basically the same as the i430fx chipset, as far as I can see, except the DRAM being populated differently(but having the same read/write effect) and some new PCI device IDs being used. Then just added a handful of new reset values.

That should theoretically be enough to get the i440fx running? So that means that 1GB of RAM can now be used on the i440fx?
Edit: Implemented the missing i440fx 93h register(Turbo Reset Control Register).

I once again look at the coreboot BIOS from Bochs running, but somehow I see it's waiting for the speaker PIT output to go high, while the PIT channel is actually waiting for a reload of the divider to start the timer? It's in mode 0(interrupt on terminal count)?

OK. Looks like that's working properly at least.

Now, just implemented and enabled the port 402h that coreboot always seems to use to log whether Qemu is present or not. This makes it quite a bit clearer what's happening (it's just redirecting said port to the porte9 log file(or whatever it's renamed as in software)):

100:00:33:83.05660: SeaBIOS (version rel-1.7.5-0-ge51488c-20140528_081134-morn.localdomain)
200:00:33:85.02252: No Xen hypervisor found.
300:00:33:94.04604: RamSize: 0x00100000 [cmos]
400:00:33:94.06808: Relocating init from 0x000dfbe9 to 0x0007eb70 (size 70700)
500:00:53:09.08996: CPU Mhz=33
600:00:55:92.02572: === PCI bus & bridge init ===
700:00:55:92.03560: PCI: pci_bios_init_bus_rec bus = 0x0
800:00:55:92.05652: === PCI device probing ===
900:00:55:93.02672: Found 3 PCI devices (max PCI bus is 00)
1000:00:55:93.04440: === PCI new allocation pass #1 ===
1100:00:55:93.05860: PCI: check devices
1200:00:55:94.07816: === PCI new allocation pass #2 ===
1300:00:55:94.08572: PCI: out of I/O address space

So apparently, it's trying to detect the PCI BAR sizes, which somehow seem too much?
Looking at the coreboot source code for that (src/fw/pciinit.c, function pci_bios_get_bar), I see it's using the normal detection method(write all ones, read it back, then and with mask, add 1 and mask again to 32-bits(the last one having no effect on x86, since all is 32-bit?)).
Edit: After checking the behaviour of the BARs, I've noticed 2 things:
1. The required detection of the PCI ROM addresses(PCI address 30h) was missing.
2. The required width of the PCI I/O BARs should actually be 32-bits instead of masked to 16-bits when the registers are updated.

Having fixed this, the coreboot BIOS ROM detects it correctly:

100:00:04:91.05093: SeaBIOS (version rel-1.7.5-0-ge51488c-20140528_081134-morn.localdomain)
200:00:04:93.02043: No Xen hypervisor found.
300:00:05:02.06135: RamSize: 0x00100000 [cmos]
400:00:05:02.08625: Relocating init from 0x000dfbe9 to 0x0007eb70 (size 70700)
500:00:05:19.09430: CPU Mhz=33
600:00:05:20.00327: === PCI bus & bridge init ===
700:00:05:20.01190: PCI: pci_bios_init_bus_rec bus = 0x0
800:00:05:20.03352: === PCI device probing ===
900:00:05:21.00046: Found 3 PCI devices (max PCI bus is 00)
1000:00:05:21.00981: === PCI new allocation pass #1 ===
1100:00:05:21.02888: PCI: check devices
1200:00:05:21.09469: === PCI new allocation pass #2 ===
1300:00:05:22.00196: PCI: IO: c000 - c017
1400:00:05:22.01239: PCI: 32: 0000000080000000 - 00000000fec00000
1500:00:05:22.03384: PCI: map device bdf=00:01.1  bar 0, addr 0000c000, size 00000008 [io]
1600:00:05:22.05249: PCI: map device bdf=00:01.1  bar 2, addr 0000c008, size 00000008 [io]
1700:00:05:22.07204: PCI: map device bdf=00:01.1  bar 1, addr 0000c010, size 00000004 [io]
1800:00:05:22.09117: PCI: map device bdf=00:01.1  bar 3, addr 0000c014, size 00000004 [io]
1900:00:05:23.00413: PCI: init bdf=00:00.0 id=8086:1237
2000:00:05:23.01691: PCI: init bdf=00:01.0 id=8086:7000
2100:00:05:23.02640: PIIX3/PIIX4 init: elcr=00 0c
2200:00:05:23.03771: PCI: init bdf=00:01.1 id=8086:7010
2300:00:05:23.04715: PCI: No VGA devices found
2400:00:05:23.09719: No apic - only the main cpu is present.
2500:00:05:24.02217: Copying PIR from 0x0008fd07 to 0x000f0fa0
2600:00:05:24.06600: Copying MPTABLE from 0x00006db0/769c0 to 0x000f0ec0
2700:00:05:24.08818: WARNING - Unable to allocate resource at smbios_legacy_setup:516!
2800:00:05:25.03929: Scan for VGA option rom

After this bugfix, it seems that it works properly(according to the port 402h log), but the display ROM isn't found(probably because it isn't injected into the ROM?):

100:05:20:26.00096: SeaBIOS (version rel-1.7.5-0-ge51488c-20140528_081134-morn.localdomain)
200:05:20:27.09072: No Xen hypervisor found.
300:05:20:37.01904: RamSize: 0x00100000 [cmos]
400:05:20:37.04240: Relocating init from 0x000dfbe9 to 0x0007eb70 (size 70700)
500:05:20:54.03104: CPU Mhz=33
600:05:20:54.03904: === PCI bus & bridge init ===
700:05:20:54.05024: PCI: pci_bios_init_bus_rec bus = 0x0
800:05:20:54.07104: === PCI device probing ===
900:05:20:55.03824: Found 3 PCI devices (max PCI bus is 00)
1000:05:20:55.04784: === PCI new allocation pass #1 ===
1100:05:20:55.05872: PCI: check devices
1200:05:20:56.02656: === PCI new allocation pass #2 ===
1300:05:20:56.03392: PCI: IO: c000 - c017
1400:05:20:56.04544: PCI: 32: 0000000080000000 - 00000000fec00000
1500:05:20:56.06592: PCI: map device bdf=00:01.1  bar 0, addr 0000c000, size 00000008 [io]
1600:05:20:56.08480: PCI: map device bdf=00:01.1  bar 2, addr 0000c008, size 00000008 [io]
1700:05:20:57.00336: PCI: map device bdf=00:01.1  bar 1, addr 0000c010, size 00000004 [io]
1800:05:20:57.02512: PCI: map device bdf=00:01.1  bar 3, addr 0000c014, size 00000004 [io]
1900:05:20:57.04016: PCI: init bdf=00:00.0 id=8086:1237
2000:05:20:57.05520: PCI: init bdf=00:01.0 id=8086:7000
2100:05:20:57.06480: PIIX3/PIIX4 init: elcr=00 0c
2200:05:20:57.07536: PCI: init bdf=00:01.1 id=8086:7010
2300:05:20:57.08656: PCI: No VGA devices found
2400:05:20:57.09712: No apic - only the main cpu is present.
2500:05:20:58.01728: Copying PIR from 0x0008fd07 to 0x000f0fa0
2600:05:20:58.05824: Copying MPTABLE from 0x00006db0/769c0 to 0x000f0ec0
2700:05:20:58.07808: WARNING - Unable to allocate resource at smbios_legacy_setup:516!
2800:05:20:59.03408: Scan for VGA option rom
2900:06:09:96.06304: PS2 keyboard initialized
3000:06:09:96.06784: Found 1 lpt ports
3100:06:09:96.07424: Found 0 serial ports
3200:06:09:96.08992: ATA controller 1 at 1f0/3f4/0 (irq 14 dev 9)
3300:06:30:41.04496: ata0-0: Generic HDD ATA-0 Hard-Disk (2047 MiBytes)
3400:06:30:41.06544: Searching bootorder for: /pci@i0cf8/*@1,1/drive@0/disk@0
3500:06:30:42.01216: ATA controller 2 at 170/374/0 (irq 15 dev 9)
3600:06:50:93.06704: DVD/CD [ata1-0: Generic CD-ROM ATAPI-4 DVD/CD]
3700:06:50:93.08848: Searching bootorder for: /pci@i0cf8/*@1,1/drive@1/disk@0
3800:06:51:07.09456: DVD/CD [ata1-1: Generic CD-ROM ATAPI-4 DVD/CD]
3900:06:51:08.01664: Searching bootorder for: /pci@i0cf8/*@1,1/drive@1/disk@1
4000:06:51:08.03424: Scan for option roms
4100:06:51:09.08144: Press F12 for boot menu.
4200:07:12:62.07808: Searching bootorder for: HALT
4300:07:12:63.00080: drive 0x000f0e80: PCHS=4161/16/63 translation=none LCHS=1024/16/63 s=4194303
4400:07:13:25.02096: Space available for UMB: c0000-ee800, f0000-f0de0
4500:07:13:25.02768: e820 map has 4 items:
4600:07:13:25.03952:   0: 0000000000000000 - 000000000009fc00 = 1 RAM
4700:07:13:25.05232:   1: 000000000009fc00 - 00000000000a0000 = 2 RESERVED
4800:07:13:25.06672:   2: 00000000000f0000 - 0000000000100000 = 2 RESERVED
4900:07:13:25.07888:   3: 00000000fffc0000 - 0000000100000000 = 2 RESERVED
5000:07:15:27.04240: enter handle_19:
5100:07:15:27.04560:   NULL
5200:07:15:28.03776: Booting from Hard Disk...
5300:07:15:43.03984: Boot failed: not a bootable disk
5400:07:15:43.06032: enter handle_18:
5500:07:15:43.06352:   NULL
5600:07:15:44.04704: Booting from DVD/CD...
5700:07:15:48.01408: Booting from 0000:7c00

Just tried the BIOS ROM for the 86box's "[i440FX] ASUS P/I-P65UP5 (C-P6ND)" machine(just the nd6i0218.awd ROM). It seems to start up partially, displays the processor and then hangs itself(using a jmp to it's own address). This might be a good starting point?
How much of it's chipset is mandatory to boot? The northbridge, 'piix3'(straight adaption of i430fx piix atm) and ps/2 controller are already there. Are the remaining chips(Winbond W83877F Super I/O Chip, Intel 28F001BXT/28F002BXT Flash BIOS and I/O APIC) really necessary to POST and boot?

Edit: These are the POST codes logged:

100:00:07:64.05841: POST Code: C0 Turn off chipset cache
200:00:07:65.03013: Shutdown status: 00
300:00:07:65.03678: POST Code: C1 Memory presence test; OEM specific, test the size of on-board memory
400:00:07:76.06792: POST Code: 0C Initialize keyboard; Detect the type of keyboard controller
500:00:07:94.05641: POST Code: C3
600:00:16:83.07102: POST Code: C5 Early shadow; OEM specific, early shadow enable for fast boot
700:00:16:89.02246: POST Code: 03 Initialize chips; Disable NMI, PIE, AIE, UEI, SQWV.  Disable video, parity checking, DMA.  Reset math coprocessor.  Clear all page registers and CMOS shutdown.  Initialize DMA controller 0 and 1.  Initialize interrupt controllers 0 and 1.
800:00:16:89.02684: POST Code: 04 Test memory refresh toggle
900:00:16:89.03352: POST Code: 05 Blank video, initialize keyboard; Keyboard controller initialization
1000:00:17:09.05130: POST Code: 06
1100:00:17:09.05550: POST Code: 07 Test CMOS interface and battery
1200:00:17:09.05720: Shutdown status: 01
1300:00:17:09.05862: Shutdown status: 02
1400:00:17:09.05994: Shutdown status: 04
1500:00:17:09.06122: Shutdown status: 08
1600:00:17:09.06248: Shutdown status: 10
1700:00:17:09.06398: Shutdown status: 20
1800:00:17:09.06522: Shutdown status: 40
1900:00:17:09.06646: Shutdown status: 80
2000:00:17:09.06782: Shutdown status: 00
2100:00:17:09.07216: POST Code: 08 Set up low memory; Early chipset initialization, memory presence test, OEM chipset routines, clear low 64K memory, test first 64K memory
2200:00:17:09.07576: POST Code: BE Chipset default initialization; Program chipset registers and power-on BIOS defaults.
2300:00:17:10.02140: POST Code: 09 Early cache initialization; Cyrix CPU specific, CPU and cache initialization
2400:00:17:10.03028: POST Code: 0A Set up interrupt vector table; Initialize first 120 interrupt vectors
2500:00:17:10.04562: POST Code: 0B Test CMOS RAM checksum
2600:00:28:95.04742: POST Code: 0C Initialize keyboard; Detect the type of keyboard controller
2700:00:28:95.05248: POST Code: 0D Initialize video interface; Detect CPU clock, read CMOS location 14h to find the type of video in use, detect and initialize video adapter
2800:00:28:95.05770: POST Code: BF Chipset initialization; Reserved
2900:00:28:95.07150: POST Code: 0D Initialize video interface; Detect CPU clock, read CMOS location 14h to find the type of video in use, detect and initialize video adapter
3000:00:36:20.05644: POST Code: 0E Test video memory; Write sign-on message to screen, setup shadow RAM
3100:00:38:21.03168: POST Code: 0F Test DMA controller 0; BIOS checksum test, keyboard detect and initialization
3200:00:38:21.03592: POST Code: 10 Test DMA controller 1
3300:00:38:21.04000: POST Code: 11 Test DMA page registers
3400:00:38:21.04348: POST Code: 12 Reserved
3500:00:38:21.04684: POST Code: 13 Reserved
3600:00:38:21.05080: POST Code: 14 Test timer counter 2

After fixing some more issues(mainly CPU speed issues, where the CPU was too slow, being unable to keep the PIT counter the same during a write-latch test, causing the BIOS to hang itself up because it's thinking that the PIT isn't working properly), it seems to manage to POST some futher.

Now I see it getting to a point where it tries to access some MSR, which my emulation hasn't implemented, thus causing a #GP(0) fault when executing the RDMSR instruction, which the BIOS doesn't seem to like, infinitely retrying to execute said instruction(because the fault handler doesn't affect the instruction flow, thus it returns back to the RDMSR when IRETting back from the exception handler).

It seems to be MSR 119h?

Edit: Just implemeted some missing MSRs(17h and 33h) for the Pentium Pro(required for said BIOS?) and added one to the Pentium Pro pool of MSRs(117h, previously only on the Pentium II CPU emulation). Although no ROM/writable bits had been defined.

It started to boot for the first time 😁
Then it immediately crashes saying that it couldn't use the EBDA? The booting also complained about a 512KB being available on the base memory area?
Edit: For some reason, the 512KB memory hole is enabled in the chipset configuration? (seeing the i430fx DRAM Control register(register 57h) bits 6-7 to 01h?

The BIOS does complain that it can't write the ESCD?
Edit: But it does boot the OS! 😁

I now seem to have some kind of issue with the loading/setting of the Intel 8254 PIT? It doesn't seem to like the values it's returning after writing them for some reason? First it writes FF, latches it(which might have been decreased by a PIT clock), compares it with FF, then it will either error out if it doesn't match(most of the time, hanging up the machine with a jump to self), otherwise write a 00h to the counter, latch it(which might have been decreased by a PIT clock) and compares it to 00h, erroring out if it matches?
This seems a bit weird?
Edit: Just improved the PIT mode 0/1 behaviour to work better. It won't start the PIT counting until after the frequency divider is written by the CPU after the command register is written now. Also, when the frequency divider is completely written(in lo, hi or lo/hi mode), for mode 0 it will immediately load the counter with said value and start to proceed to the correct state for the counting to start again.
This was tripping up both the 14h diagnostics test(for the PC speaker output) and the PIT timer test(which tests timing for 08h PIT clocks). The former having issues with reading back the written value to the PC speaker timer correctly(because it write the count and it wasn't latched by a PIT tick yet when it executed latch commands), while the PIT timer test was failing because the PIT timer wasn't counting down after such a setup with the PIT stuck in the initial state instead of properly being in state 1(the gate check state, which will progress to state 2, which is the counting state).

Having fixed the PIT behaviour, the i440fx motherboard seems to keep succeeding to properly boot the system? 😁
Although the ESCD still can't be updated, according to said BIOS? Perhaps it tries to update something inside the BIOS ROM?

After implementing the APIC registers and it's read-only registers(the LAPIC writable registers being fully writable atm), Windows NT 4.0 tries to disable the PIC(setting the mask registers to 0xFF) and use the APIC/LAPIC instead.
But since the APIC doesn't have anything emulated yet, it will hang the OS which never receives any interrupts anymore.

So i will have to actually do some implementing on the APIC's IRQ lines and interrupt handling.

Just implemeted some basic edge-triggered IRQ support for the APIC.

Edit: Eventually moved the IO APIC to it's proper address. Now Windows NT 4.0 seems to actually try to use it? I see it's using the 8th redirection entry(low dword 48D1h, high dword 1000000h).
Edit: It maps it to interrupt D1h apparently? Is that IRQ8?
Although it eventually hanged because the IRQ wasn't received anymore(IRQ8 that is) because it's never acnowledged?

Just implemeted the pass-through scheme with priorities on the APIC.

So now, the IO APIC will constantly check if it can perhaps send it's unmasked IRQ lines that are raised by the hardware(for now always in edge-triggering mode). The level mode is currently ignoring the inputs.
When it notices that it might be able to send it to the Local APIC, it will try to find the highest prioirity IRQ to send to the Local APIC. If it's able to, it lowers the raised IRQ signal bit and sets the IRR bit of the CPU's Local APIC(essentially the message handling between the Local APIC and the IO APIC).

Then, the Local APIC does nothing more than, once for each instruction, check if it has IRRs that have ISRs unmasked. If so, it finds the highest priority bit that's set and simply fires the IRQ on the CPU(setting the ISR and clearing the IRR along the way).

The only thing the CPU does is sending the B0 command with value 00000000h(32-bit dword) to clear the ISR, after which on the next instruction with CPU interrupts enabled the local APIC will start checking the IRRs and ISRs again until a new interrupt is pending again.