Early in POST the ROM reads an I/O status port at 0x18, then masks off two status bits and classifies the result. The pass condition is:
> (status & 0x60) == 0x60 → keyboard present/OK
In the ROM this shows up as:
IN AL, 0x18 (read the keyboard/KB‑interface status)
MOV AH, AL (keep an unmasked copy)
AND AL, 0x60 / AND AH, 0x60
compare against 0x60 to decide OK vs error classes (only 0x40 set = one error class; anything else = another)
So the POST isn’t waiting for a PS/2‑style BAT byte (0xAA). It’s simply looking for those two status bits to be set when it polls the keyboard interface.
How your adapter should behave at power‑on
1. Expose a status register at I/O port 0x18.
When the BIOS reads this port during POST, set both bits 5 and 6 = 1 so that read & 0x60 == 0x60. (If you only set bit 6, POST classifies it as an error; if neither is set, it’s another error path.)
2. Don’t flood the machine with scancodes during POST.
There’s a “stuck keys” path if the firmware keeps seeing unwanted key activity right after init. Keep your “data available” path quiet until the system is running.
3. Handle the control pokes.
The ROM twiddles a few control ports (you’ll see OUTs to small I/O ports like 0x3A, 0x07, 0x05, etc.) as part of bring‑up. You don’t need to do much with them beyond accepting the writes; just make sure your status at 0x18 still reports “OK” immediately afterwards.
4. After POST, just behave like a sane keyboard source.