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?