Also, anyone knows what the exact effect of the dots/mm setting in the PS/2 mouse is? It can be set to 1/2/4/8 dots/mm, but does this simply multiply with the amount of mm(in whole mm)? Or does it affect the movement in mm in another way, like affecting the mm counter itself(more/less precise movement (1/0.5/0.25/0.125 mm per dot))?

Edit: Just managed to fix the rough movement by applying the movement reversed: instead of only multiplying the movement in whole mm with the resolution(1/2/4/8 dots/mm), it now applies the dots directly to the mm detection itself(so 0.125mm in the case of 8 is counted as 1 pixel, 0.25mm in the case of 4, 0.5 in the case of 2 and 1.0 in the case of 1 dots/mm resolution).

Now the i430fx BIOS configuration doesn't have such rough movement anymore, but it's still quite sensitive(mostly due to it setting up 8 dots/mm resolution, which is quite fast).

The serial mouse still reports whole mickeys always, which seems like being quite rough as well?

Edit: My latest bugfixes fixes those as well(both PS/2 and serial mice now properly report their movement). 😁

The only thing left is the changes affect the PSP-style mouse input somehow.
Edit: Managed to fix it, together with a x2 speed boost on the PSP input (because the mouse is so slow with only moving 1 inch/second, I've changed it to 2 inches/second).

Eventually wanted to do some fast mouse testing on the XT.
Then noticed it doesn)t POST anymore!
It initializes the video card ROM without issues, but then starts a delay based on the PIT0 timer IRQ and keyboard inout(2 seconds) which never finishes because the timer IRQ is inhibited by the IMR being BFh?
So there's something wrong with the PIC now?

Edit: Hmmm... Interesting. The part of the BIOS is waiting for the BIOS ROM timeout(which is handled by the PIT0 IRQ), but the BIOS disables the IRQ because it's IRQ handler points to the ignore_int at F000:FF23, which ignores and disables said interrupt when it's encountered? Why is there no IRQ0 vector installed?
It should have been installed at F000:E14F...

Edit: It is actually installed at the correct location. But the IRQ handler is somehow triggered by something that's not an actual IRQ? So it looks at the ISR, finds the bit of various IRQs set, then disables said IRQ?
Edit: Hmmm... It tries to handle IRQ2 as the slave PIC, but the slave doesn't have any IRQs(it isn't configured)?
Edit: The issue was with the new improved 8259 PIC emulation. It was thinking that because the ICW2 on the master had the bits of each IR line set and it being the master PIC connected to the CPU, it should let the slave PIC on the connected IR lines(for IR lines 0-2, since the ICW2 was 07h) handle the IRQ, but the slave PIC itself had no idea what IRQ to fire, thus firing IR7 on the slave PIC(which isn't supported on the XT configuration(no software supports it)).
It was missing a check if the specified PIC was actually in cascade mode instead of single mode to prevent this from happening.