• Please review our updated Terms and Rules here

AT to XT Keyboard Converter

I've got an Arduino Uno. I wonder how hard it would be to implement the same converter logic on it. (I've also got a Netduino Plus, but that would be overkill)
 
thanks! i will have to take a peak, maybe make a ASM version for avr.

do to timing, i don't think the overhead of 'c' will be ok with it.
 
Seperate issue, how much work to make this work with a Tandy 1000 series of computers. I don't think it would be much, just changing the scan codes. Any thoughts?
 
hargle said:
I believe this is the current schematic and board diagram. it's all andrew's work, and this is his site, so I claim no responsibility. ;)
Click to expand...
Unfortunately, in that diagram, the pin numbering on the large DIN connectors is incorrect.
From memory, the software that Andrew used did not allow him to renumber the connectors.
AT2XTKB_correction_large_DIN.jpg
 
My kit (built) arrived yesterday. I tested it with a 5150 and everything works fine. The Irish/UK keyboard has a slightly different key arrangement than a US keyboard, ~ # and a few others. I know that in my PS/1 there was a command in autoexec.bat or config.sys to load codepage 850 (DOS 4.01)

EDIT: I'll check the PS/1 later.
 
Last edited:
I'm trying to use a 12f683 with the latest code (don't have a 629 kicking around), but i'm having problems... on my logic analyzer i'm seeing the codes come out of the keyboard but i'm not getting any output from the pic at all. i had to change a couple of register file names to get the code to compile - ADCON to ADCON0, CMCON to CMCON0 etc. i changed the device include to p12f683, disabled the clock calibration, set the clock to internal osc, 4mhz, and i set the 683's analog pins to digital i/o by clearing ansel. to test that the chip is working i even temporarily modified the code just to blink some leds, and that was ok. any other ideas why it wouldn't work? i figure i'm missing something silly related to a new peripheral or setup sequence on the 683 that wasn't on the 629
 
crap. sorry, it is working... i just had my analyzer triggering incorrectly so it wasn't capturing enough samples to show me the output! i'm now using it to hook up a keyboard to a symbol ppt4140 that can only use an xt keyboard (and i didn't have one). thanks so much guys for this awesome utility!!
 
I'd be interested in adding XT-KB support to my AVR GCC-based PS2Encoder project, but I'm wondering if there's an XT machine available for loan in the SE IA area, or someone with a logic analyzer, some HW skills, and an XT willing to help test. I have AT receive already implemented, just need to write up a C version of the XT out code.

Jim
 
Found a XT machine to test with, and am almost done with initial development (PS2 code is from another project, so is working fine). A few questions on the XT protocol:

On the PS/2 protocol, when the host send CLK=L anytime during the transmission from the KB, the KB should switch to receive mode. I know XT doesn't send command to the KB, but is there any possibility that CLK=L would occur from the host during a transmission from the KB? If so, does it mean (after 6mS) that I should implement some diagnostic mode on the KB?

When CLK goes high at the end of a transmission, I see a few references that indicated a DATA=L condition for 62uS means "lock the KB". Is that true? If so, how does one get out of that condition?
 
For the XT keyboard to send data to the host, both the data and clock lines must be high--if the host buffer is overfull, it will lower either or both to shut the keyboard up. That's what's meant by "lock".

If they host pulls the clock line low for 20 msec or more, this can be interpreted as a RESET command. The usual procedure is to respond with a hex "AA" to signal that diagnostics passed.

Autoswitching AT-XT keyboards can get a little strange with the keyboard responding with a bad-parity AT ACK after reset. An AT host will send a "RESEND" command and the keyboard will respond with a correct parity "ACK". An XT host will, of course, send nothing and the keyboard will assume that XT mode is to be used. This one tripped me up the first time around.
 
Chuck(G) said:
For the XT keyboard to send data to the host, both the data and clock lines must be high--if the host buffer is overfull, it will lower either or both to shut the keyboard up. That's what's meant by "lock".
Click to expand...
NOted that both must be high to send. My question is about interbyte behavior. For instance, if I have sent the pseudo start (0) and the start bit (1) and am getting ready to send the LSB and I find the CLK is held low when I raise it to set up the LSB, should I care?
If they host pulls the clock line low for 20 msec or more, this can be interpreted as a RESET command. The usual procedure is to respond with a hex "AA" to signal that diagnostics passed.
Click to expand...
OK, I will add that.

Sounds like I need to find an autoswitching PS/2 KB. My PS/2 code, which I have been using for a while, probably does not handle that correctly.

Jim
 
For those who like C and AVR, there's a new version PS2Encoder firmware that includes XT KB operation. Regrettably, it turns out my resurrected SLT/286 is AT, and so is my Commodore Colt, so I evidently don't have a XT-based machine to test against yet.

The code can probably be compiled for any ATMEGA, but it's set up for M88/168/328 right now. There's a bit under the hood, as PS2Encoder does serial and parallel as well. Anyway, the code is at:

http://www.go4retro.com/downloads/PS2Encoder/PS2Encoder_v0.7.0.zip
 
brain said:
NOted that both must be high to send. My question is about interbyte behavior. For instance, if I have sent the pseudo start (0) and the start bit (1) and am getting ready to send the LSB and I find the CLK is held low when I raise it to set up the LSB, should I care?
Click to expand...

Inter-bit shouldn't matter--it's never come up AFAIK. If the host says it's ready to accept a byte, I think you're safe to send the whole thing. My clock pulses are 50 microseconds long, which seems to work fine.
 
Been tweaking the code. I added XT host mode, in case someone wants to do XT to AT direction.

A couple of items:

http://kbdbabel.sourceforge.net/doc/kbd_signaling_pcxt_ps2_adb.pdf shows the clock period of 100uS. Are you saying that your clock period is 50uS, or each high level is 50uS (100uS cycle)?

Another place: http://www.cs.cmu.edu/afs/cs/usr/jmcm/www/info/key2.txt

Notes 2000bps, which is 500uS clock cycle. Seems long to me.

Currently, my code sets the data line on clock rise (~50uS from clock fall), while it looks like your code does it halfway in between. I don't have an XT keyboard to analyze, but my PS/2 KB routinesalso transition on CLK change. Still, I don't seem to have any issues doing the transition this way, so I am curious how important it is to change in the middle of the half cycle...

Do you have a human readable translation map? I wanted to check my mappings.
 
50 uS high, 50 uS low - 100 uS total.

Probably doesn't matter all that much, since the PC just uses a 9 bit shift register to receive data--and the holdoff is automatic when the 9th bit is shifted in. I'd be surprised if you couldn't drive an XT with a 1MHz bitrate, assuming that you controlled ringing on the cable.

It's been so long since I constructed the table, that I don't have any of my work from building it. I may have constructed it from an online source or the 5170 Techref. At any rate, take a look at the XTTRANS.INC file in the source code (much earlier in this thread). That's organized as AT-to-XT translation. XT-to-AT to me is a mess because of fewer keys on the XT than the AT, meaning that some multi-key strokes will be needed for stuff such as F11 and F12, right-Alt and right-Ctrl, etc.
 
You must log in or register to reply here.
Back
Top