Hmmm... What happens if software writes the 8042 output port and the buffer is filled due to incoming data? Or is that prohibited from happening? Can that cause a loss of interrupt?

- superfury: From what I see in the disassembled and commented IBM AT and PS/2 8042 firmwares on halicery (you need to use the Wayback Machine now since the site is now gone), commands are not processed until IBF is clear (ie. there is no incoming data to be read).

Battler wrote on 2023-09-18, 18:55:

- superfury: From what I see in the disassembled and commented IBM AT and PS/2 8042 firmwares on halicery (you need to use the Wayback Machine now since the site is now gone), commands are not processed until IBF is clear (ie. there is no incoming data to be read).

OK. Just prevented the input buffer from being handled and emptied while the output buffer is filled with a command to execute. So the CPU needs to read it (lowering it's IRQ) from port 60h before the input buffer starts to be handled during the next 12 clock tick(s) after.

And it looks like I typo'd above, I meant, until OBF is clear. Basically, there's two conditions for a command to be processed: IBF set and OBF clear, ie. there must be a byte in the input buffer and nothing in the output buffer.

Battler wrote on 2023-09-19, 14:49:

And it looks like I typo'd above, I meant, until OBF is clear. Basically, there's two conditions for a command to be processed: IBF set and OBF clear, ie. there must be a byte in the input buffer and nothing in the output buffer.

Does that apply to all commands? What about their parameters?

- 8042 command byte
- byte to first ps/2 output buffer parameter
- byte to second ps/2 output buffer parameter
- security string byte
- output port parameter
- vram write parameter

I've currently applied it to all of the above. I only didn't apply it to the normal first/second ps/2 port outputs (they aren't a 8042 command anyways, other than the 8042 escape for the second ps/2 port that is).

Or is it only applicable to the first/second ps/2 output buffer and the output port parameters?
Does it apply to the 8042 command byte itself as well?

OK. Just found a bug in the 8042, where it encounters a 8042 with full input buffer trying to set A20 on the i440fx (trying to flash the BIOS ROM). That now failed because the 8042 ignored the write to the 8042 output port because the input buffer was full (so it didn't properly abort, clearing the buffer in a half kind of way (clearing the write flag that indicates the write be handled when it shouldn't).

Seeing that fixed now, the BIOS does some initialization. Then I see it tries to write the buffer (but the input buffer is full, so it's blocked). Then, once the 8042 output buffer is actually cleared during POST (about when starting the RAM counting on the display), it's processed and sets A20 high. After that it seems to behave normally.

It always applies - if the input buffer is not full, then the keyboard controller has not received a byte, and if the output buffer is full, then there's a byte pending for the host to read. A command that wants one of more parameters is processed after every byte - if it wants more bytes, it repeats the same wait for all of them.

This also means that the host must make sure to wait for IBF to be cleared (which indicates the firmware running on the 8042 has accepted the byte previously sent by the host) and read any sent bytes (so OBF is cleared, if at all set) before sending anything.