It depends on the device at the other end of the serial connection, but in general yes - UARTs can send and receive simultaneously (this is what "full duplex" means).

Well, it's full-duplex now. It's now transferring two parallel signals for each UART. One for sending and one for receiving. The transmitter holder is essentially emptied into the transmitter register(setting LSR bit 5). Loading it clears said bit and bit 6(THR and TSR not empty). That happens on the T0 clock(which repeats while nothing is there to send(until LSR bit 5 is cleared). Then it starts n clocks(e.g. 11 clocks) in T1 state(transferring to hardware), which transfers to T2 state(finished transfer), which sets LSR bit 6 if bit 5 equals 1(meaning there's nothing left to transfer). T2 also writes the shift register to the connected peripheral. T2 transfers back to T0.

Receiving works the samw, with a small hack. It also loops T0, until something is there to receive and LSR bit 0 is cleared(Data Holding Register is empty). It then transfers to T1 for n clocks, and finally T2 which moves the received data from the T0 cycle to the Data Holding Register and sets LSR bit 0. It then transfers back to T0.

Is that correct behaviour?

Oddly enough, all diagnostics software(CheckIt Diagnostics, Arachne) still fails somehow. Checkit still seems to fail on the I/O of most of the registers(connected to a serial modem on COM2)? Arachne miniterm can dial out and login to my UniPCemu SLIP server just fine, then load slipper. But internet doesn't work(it does work with the same setup on Dosbox).

There are oddly only a few I/O registers that seem to work according to CheckIt. According to it, the Data register(which seems to read/write port 2F8 just fine, when Input/Output is done).

https://bitbucket.org/superfury/unipcemu/src/ … art.c?at=master

Just implemented the loopback mode, which immediately moved output to input without shift register etc.(with interrupts). It also changes MCR to report on the LSR when updating hardware lines.

Now all CheckIt tests pass, except the Modem Status and Modem Control Registers?

After some more testing and improvements according to documentation, now all tests from CheckIt! Diagnostics pass, except for the Modem Status testing? The Error Summary screen says:

1Test Modem Status.....(etc.)..FAILED
2    [Int] Expected F0h, received F4h.

Something's weird about what I read about the Ringing signal. It's supposed to be active low, so when the modem is ringing, it pulls the RI] output low(logical 0). That gets inverted in the reporting of the Modem Status Register, setting bit 6 in the Modem Status Register.

Now, the weird part is: bit 2 gets set each time the ringing stops(bit 6 goes from 1 to 0). And interrupts(which are based on the MSR bit 6 instead instead it seems) is also triggered when the ringing stops(using inverse logic, but instead of on the RI input, it's based on the MSR bit 6, thus raising an interrupt each time the ringing stops)?

How does this work in software?

Edit: Just changed the UART to act as above described. I've also changed the modem to (on a incoming signal) toggle the RING line on and off (in 3 second intervals) and take it off-hook(when Auto-answer is enabled) when it's toggled off(and still connected to the other side) after the set amound of times(so e.g. 3 rings toggled off) instead of when it toggles on.

Edit: Just improved Loopback mode to not use the normal outputs for the four signal lines. It now uses the bits from the Modem Control Register.

Edit: Looking at the values read from the Modem Status Register, I don't see any 0xF4 value being read at any time? What does that "[Int]" part of the message mean?

Now running The Modem Doctor on the serial modem. So far fixed the result codes being reported to actually read the S-register values correctly, although very slow at 2400 baud(and CPU running at 11% speed at 3KIPS).