More XT Keyboard fun... (and success!)

For posterity, here is some additional XT KB info I don't think I've seen elsewhere (but, maybe it is and I just did not understand it) On a enhanced (read, more than 83 keys) XT keyboard, there are some rules for the scancodes associated with: END,HOME, INSERT,DELETE,PGDN, PGUP, and the cursor keys: * If num lock is on, each of these keys is preceded by an extended shift (0xe0, 0x12) * If the key is still being held down and another key is depressed, the extended shift is removed (0xe0, 0x92), even if the new key is also one of the extended keys noted. Also, of general note: * This IBM Model M puts .767ms between scancodes. It does not look like it is needed, but FWIW * clock cycle is .117ms. 80.375uS high, 36.625uS low, except for the first low hold time, which is 100uS. * start bit is set 7.5uS after CLK goes low the first time. * data bit transitions happen 25uS after high to low transition (I am assuming that in the start bit case, the code is easy (bring high), so 7.5uS is just a few instructions. In the latter case, the extra time is needed to determine the data line's state after the high to low transition). * after the last CLK fall, the low is held for 147uS. Data is kept at the same level for 106uS. When attached to this PC clone, the data line is drug low by the PC right after the CLK line goes low for the last time, and then it releases it (and then the KB brings it low after the 106uS mark. * The .767ms is made up up the 147uS of CLK holdoff + 620uS of delay before sending another character. * The Model M startup is very different, since it is autosensing. I've saved a trace and am looking at what it is doing. * On a Clone XT KB I have here, after the reset condition is found, and the CLK line goes high, the KB waits 3ms before sending data. (I assume it uses that time to "reset" the KB) * The clone KB waits 2.5ms between chars * The clone KB doesn't bother setting DATA low until the CLK goes high. Then, 3ms later, it sends reset (0xaa) More minutiae for those who care. My emulation was working fine, but I was leaving DATA high at idle, so I went in tonight I rewrote the code to set it low at idle. Added the 3ms after RESET delay, changed CLK periods to match Model M, added .6mS inter char delay. None appear to be needed, but probably adding them makes thing more robust. I did not add the 107/147uS wait after char finish to IDLE, and I performed all of my DATA transition on CLK rise, instead of midpoint. Jim