IRR is cleared when the line drops.

Any idea how Windows and Linux detect the IRQ of hardware? UniPCemu does actually raise the IRQ(and IRR), but according to QEMU, it's not cleared unless fired to the CPU?
Windows 95 refuses to detect the UART IRQ(saying the IIR=1), the Sound Blaster raises it, but isn't found as well.
Any idea on the cause?

Edit: Just changed the parallel IR line mechanism to clear IRR when a IR line is dropped. Although other parallel IR lines can then raise it back up again on the next CPU instruction(e.g. other parallel line gets acnowledged and ran, which will become active instead). So that'll have the effect of parallel lines raised together will cause a sort of priority loop(lower numbered lines first) in which each of them will cause IRR to rise in turn(with the hardware notified so it knows it's activated it's parallel line). So in the case of 2 parallel IR devices, when both raise IR, first the first one is acnowledged and loaded(the hardware knows this). Then, once it's handling thr first one(executing it's IRQ handler), the second one is loaded and notified of that. Then, once the first finishes, it's notified that it's the one that's finished(the one whose IRQ handler was fired). Then the second one fires, which upon finish will notify that it's the one that finished. So with 2 parallel devices, that will jump activity between the two(in some crude multitasking way_.

superfury wrote on 2020-04-21, 21:21:

but according to QEMU, it's not cleared unless fired to the CPU?

This isn't true, check again.

crazyc wrote on 2020-04-21, 22:00:

superfury wrote on 2020-04-21, 21:21:

but according to QEMU, it's not cleared unless fired to the CPU?

This isn't true, check again.

That's what I see happening:
https://raw.githubusercontent.com/qemu/qemu/m … hw/intc/i8259.c

Function pic_set_irq, case /* edge-triggered*/ (which it should be in a PC-compatible)?

It clearly sets it but doesn't clear it?

Looking at the Sound Blaster detection, I see it has the Interrupt Mask Register set to 0xAC. So interrupts 0(PIT), 1(Keyboard), 4(COM1, which has a serial mouse) and 6(Floppy) are enabled. All others are disabled.
Is that perhaps the cause of the problem of the misdetection? It means that IRQs 2(Secondary PIC), 3(COM2), 5(Sound Blaster) and 7(LPT1) are disabled during the detection.

Edit: OK. Before reboot, IRQ5 and 7 are disabled(all others enabled)... Then the primary PIC is set to A8 and secondary to 3C. So All interrupts except IRQ 3,5,7 and 10-13 are enabled.

I can manually reconfigure the Sound Blaster to use IRQ5 and LPT1 to use IRQ7, which are UniPCemu's settings. But automatic detection somehow fails for those two devices?

But since both COM1 and COM2 aren't detected automatically, something else must be the cause (at least the IMR isn't the cause of the problem)?

superfury wrote on 2020-04-21, 22:05:

That's what I see happening: https://raw.githubusercontent.com/qemu/qemu/m … hw/intc/i8259.c […]
Show full quote

That's what I see happening:
https://raw.githubusercontent.com/qemu/qemu/m … hw/intc/i8259.c

Function pic_set_irq, case /* edge-triggered*/ (which it should be in a PC-compatible)?

It clearly sets it but doesn't clear it?

Fair enough, it clears last_irr instead of irr. It's likely wrong though as this thread shows, https://lists.libreplanet.org/archive/html/qe … 9/msg01245.html and bochs https://github.com/lubomyr/bochs/blob/25ec358 … dev/pic.cc#L628 . (I can guarantee it's wrong as there's a bunch of things in mame from various architectures that would break if irr isn't cleared, qemu gets away with it because pc operating systems don't abuse the 8259)

Just found a small PIC bug: when ICW4 was to be sent to the PIC, it would skip it's progress(like the ICW4 was written) and write the OCW1 instead(the Interrupt Mask Register). So that improves the writing of the IMR and OCW4 a bit now.

Edit: Now, during Sound Blaster detection, IMR is 0xAC, thus interrupts 0, 1, 4 and 6 are allowed?

Edit: OK. When requesting the extra info from the modem using Windows 95(using the modem control panel options), I see the client sending a byte over the loopback adapter, which is returned immediately now, and properly raising an IRQ with the reason for it to be a byte ready to be read.

Something interesting happens, though: I see it writing a byte to the UART write data port(2F8h) while the loopback mode is enabled. But when the data is read back from the data port, the modem control register is cleared?
Is it perhaps using some trickery to detect if there's a peripheral connected?

OK. I see the modem control register chaging as follows:
0
B
A
1A
- Write 0 to the data holding register
- IR is raised.
- IR is registered and put in IRR.
- Interrupt cause is registered and set in the IIR.
2
- Data register is read with input buffer being emptied. This clears the IIR back to 1.
- IRQ is raised because IRR was set? IIR is 1 at this point.

This is the case each time. So it's writing to the data holding register in loopback mode, then reading it without loopback mode?

I also see it reading the modem status, then the line status(which is 0x60), finally to end with a read to the data buffer(2f8) which has nothing in it?

Edit: OK. Directly after the IRQ is being raised from the loopback data write (IRR still set, IIR set accordingly), it reads the value 0x61 from the line status register.
It then resets the modem control loopback bit using the modem control register, to switch it back to normal mode.
It then reads the interrupt ID register, which is 0x04, since the IRQ is raised.
It's then finishes by reading the data port multiple times?

It almost looks like it's ignoring the data port being filled or not entirely (completely ignoring the line status register)? It also looks like it's reading the IIR register when no IRQs are actually pending. I only see the IRQ being raised once during the entire thing.

One strange thing also is that Visual Studio debugger reports the COMport being used for port 2f8 as being 3(the COM4 to be exact)? But only 2 UARTs are allocated and used?