After increasing the speed of the 80286 CPU to 8MHz instead of 6MHz, both revision 2 and revision 3 of the IBM PC AT BIOS error out during the POST(single beep).

Anyone knows what can cause MS-DOS 5.0(a) to spout out Divide error/overflow messages besides the CPU being too fast? The CPU can't be very much faster(it's the documented cycle counts with 3 or 6 memory cycles added for each byte(3), aligned word(3) and unaligned word(6) that's accessed in memory. At 6MHz, the count compared to the DMA Refresh rate ends up in the 0% to +10% range(CX being about 50h lower than the reference value) on the revision 2 IBM AT BIOS. 8MHz doesn't seem to veryify it's expected range, for some reason? The MMU cycles for prefetch and normal MMU accesses are simply added to the documented values. The prefetch itself substracts those memory cycles(like with the 8086/8088), but reads data at 3 cycles per byte instead of the 4 cycles used with the 808X.

I've just tested the latest build (using XT-IDE AT and IBM AT BIOS w/ my 20MB primary and 8GB secondary hdd image). The divide overflow at dir still persists?

The same can be said about the divide error when starting the Day of the Tentacle demo setup:

The divide by zero error handler isn't started by any DIV instruction (according to the Visual Studio Community 2015's debugger breakpoint)? Anyone knows what might cause this strange behaviour? No divide errors of any kind happen on the 808X and NEC V20/V30 emulation.

After debugging the it shows that the divide interrupt is called by a hardware IRQ? It's executed at C600:141D, which is the XT-IDE AT BIOS. Also some other locations get this 'IRQ' called, but it seems something is wrong in the interrupt controller? Since interrupt 0h is only possible with IRQ0 and IRQ8 with a base address having been set to vector 00h on the interrupt controller?

Edit: Looking at the PIC, it seems that for some reason, the IRQ0 is stuck as being used, causing the PIC to keep reporting the IRQ as used, but the PIC results in interrupt 00h because the cause of the interrupt cannot be found. So the cause is actually the PIC that's doing something wrong.

This is the current code of the PIC emulation(interrupts are triggered with a low to high transition of the interrupt pin(edge triggered)):
https://bitbucket.org/superfury/unipcemu/src/ … pit.c?at=master

raiseIRQ and lowerIRQ apply changes in the IR lines (parallel IR lines, with the high 4 bits identifying the parallel line(for parallel shared IR lines) and the low 4 bits identifying the IR line to modify).

Anyone can see what's going wrong here?

Edit: Managed to fix it by improving the 8042 timing(in cycles) processing and improving the PIC:
https://bitbucket.org/superfury/unipcemu/src/ … 042.c?at=master
https://bitbucket.org/superfury/unipcemu/src/ … pic.c?at=master

Now input works again. Also no more divide errors seem to occur:) It was a problem with the PIC, which didn't recognized the interrupts acnowledged anymore when it starts to process them(because the hardware cleared it's IR line). Parallel IR lines are now handled a bit better.

The only problem left is that now, input is staggering slow(keyboard input), probably because of the heavy 8042 processing that's done now?

Edit: After adjusting the 8042 processing, the keyboard works at normal speed once again, although it's still wrong according to the IBM AT BIOS.