First post, by superfury
UniPCemu has it assigned to IRQ5(shared on XT, not shared on AT and up), but somehow the Windows 95 hardware detection and boot-time auto mode thinks it's nonexistent(no IRQ logged to detlog.txt, while the hardware properties IRQ entry in auto mode has it weirdly set to IRQ3???).
Weirdly enough, the detlog.txt says about the UARTs for COM1 and COM2 IIR=1 and "assuming 3" or "assuming 4"? Anyone knows what that means? The UART should be raising/lowering the IR3/4 of the master PIC properly?
UART code: https://bitbucket.org/superfury/unipcemu/src/ … hardware/uart.c
See the lowerirq/raiseirq calls and their calling functions for their functionality.
Is there an issue with the IIR register?
As for the Sound Blaster:
https://bitbucket.org/superfury/unipcemu/src/ … /soundblaster.c
Also the lowerirq(by reading the status register at 22Eh, the case 0xE) and raiseirq(which also sets a flag in the soundblaster telling the 0xE read to lower the IRQ).
If required, the special PIC emulation(supporting parallel IR lines, mainly for the XT):
https://bitbucket.org/superfury/unipcemu/src/ … /hardware/pic.c
The parameter to raiseirq/lowerirq is a 2-nibble packed value. The low nibble is the IR line(0-15). The high nibble is the shared line number for that IR-line(e.g. Sound Blaster uses shared line 0x3, as far as I remember LPT3 uses shared line 0x2(currently unused by said hardware) and the ATA controller on the XT uses shared line 0x1 as far as I remember). So for the Sound Blaster that's 0x35 combined(three other devices use 0x25, 0x15 and 0x05).
It uses a special protocol(a simple handler messaging protocol: a acnowledgeirq and finishirq to tell the connected shared lines(if registered) that it's starting said shared IR line and sending it to the CPU as an interrupt) between the PIC and connected peripheral on said line. Perhaps you can compare it to my own version of some kind of special PCI-like bus signal being emulated. 🤣