• Please review our updated Terms and Rules here

Olivetti M24 / AT&T 6300 Keyboard Emulator

Valerio

Experienced Member
Joined
Aug 20, 2017
Messages
131
Location
New York, Rome, London
Hello All,
as I may have mentioned in previous posts, I am the proud owner of an Olivetti M24. An Olivetti M24 was my very first computer - everything computer-related I have ever learnt rests on the foundations that I laid exploring the workings of that intriguing machine when I was a child.
Fast forward many years later I re-acquired an M24 of near-identical configuration (640Kb RAM, dual 360k floppy, no HD, green monochrome display, 102-key ie Type 2 keyboard), which I am very happy with (especially after adding an XT-IDE board from glitchworks). The only problem is that said M24 resides back in Italy, while I spend the vast majority of my working life here in the US. Shipping it over is unthinkable.

So after a bit of thinking I reached the logical conclusion - buy its American cousin, the AT&T PC 6300, here in the US, where it should be in (relatively) good supply. So I did! The 6300 I bought is in very good shape but bare-bones, ie no hd, no keyboard, and no monitor.

To the HD part I will come back later.

The monitor part I solved relatively quickly after a few false starts with VGA cards - I built the simple adapter and connected it to a NEC MultiSync 1990FXp bought off ebay for $40 delivered. The adapter can be improved as is being discussed in another thread - more on this later.

The more immediate problem was the keyboard, which is the topic of the current thread... which I realize is getting a bit long so I'll split it into different posts (I hope this does not break forum rules).
 
So I thought - the M24 Theory of Operation manual has schematics for both the motherboard (incl. the keyboard interface) and the keyboard itself, as well as a description of the communication protocol between the two: why not build an emulator? How hard could it be? :)

Well, not very, but still a bit harder than I originally thought, as it turns out. The main complication is that unlike AT-to-XT converters, in this case we have to deal with TWO asyncronous clock sources, one generated by the AT keyboard, and the other by the M24, which owns the clock generation for the dialogue with its keyboard. After a bit of trial and error I think I got the most robust sequence for the state machine to work.

In a nutshell, it is based on an Arduino Uno or Nano, and it needs external circuitry to pull down the open-collector lines (it may be possible to just switch the MCU pin mode at the right time and avoid the external circuit, but I think it's safer this way). I used a 74LS07 but in early tests I also used discrete 2N2222's and it worked fine that way as well. It does not require any external library - in early versions I used the PS2KeyAdvanced library but it turned out not to be suitable for what I needed, so I reimplemented the AT protocol from scratch (taking inspiration from said library, which I gratefully acknowledge).

Note: the M24 came with one of two keyboards:
- a "Type 1" keyboard with 83 keys
- a "Type 2" keyboard with 102 keys (similar layout to AT keyboards), also called "deluxe" by the BIOS

This emulator attempts to reproduce the behaviour of the "Type 2" keyboard.

A few interesting points I discovered along the way:
- the M24 keyboard connector also has a 5V pin, which is not used by the M24 keyboard
- the M24 keyboard powers itself through the 12V pin, but it never really needs 12V: it immediately regulates it down to 5V with an LM340A
- the 5V rail that supplies said 5V pin appears to be a bit weak: drawing just 100mA results in the voltage dropping from 5.05V to 4.85V. I will try and investigate this further.
- the M24 keyboard connector also has a /RESET pin (not used by the original keyboard), which is handy for resetting the Arduino upon cold resets of the M24

It is now rather robust (I have yet to see any TX/RX errors with the latest version) and I see no unexplained behaviour. I even added a very basic TTY functionality so you can open a PuTTY session on your modern PC, connect to the Arduino via USB, and the emulator will convert characters sent down the serial line to keystrokes. It's actually more useful than I thought it would be!

So it's all good? Well...
 
Last edited:
There is only one problem left (I think), and this is where I'd welcome any help or suggestion.

I have not been able to understand what the expected behaviour of the original M24 keyboard is upon reset (remember, I do not currently have access to my own original M24 keyboard). As a consequence, in the BIOS POST routine the emulator is not recognized as a "deluxe" (Type 2) keyboard and the system defaults to the 82-key, "Type 1" keyboard. This means that some scancodes are misinterpreted by the BIOS. This is not a huge deal, as they two types are pretty similar. Also, the keyboard type flag can be corrected in software later on rather easily (bit 0 of the byte at 0040:0018 controls the keyboard type).

Similarly, the CUSTOMER.EXE program fails to recognize that there's a keyboard attached. Using SYSTEM.EXE you can force to run keyboard tests anyway but the output is a bit weird, which bring me to my first actual question (btw thanks for reading so far!):

- what should the "keyboard test" section of CUSTOMER.EXE / SYSTEM.EXE look like when connected to a real Type 2 keyboard? Can someone post a screenshot? Mine looks like this:

SYSTEM_KB_TEST.jpg

I dug into the BIOS listing and this is the relevant code (see page 416 of the System Programmer's Guide) - this is executed just after the "beep" (ie after the RAM test and the "RT Clock Pass" message):

Code:
	mov dx,p_kctrl 		; dx = p_kctrl
	mov al,40h 		; remove keyboard reset
	out dx, al

	mov ah,1 			; enable self test
	call kb_cmd_send
	mov word ptr ds:[reset_flag],cx		;; cx is zero here
	xor cx, cx 					
	loop $						; delay

; Flush any keyboard scan code and store AAh if we get it.
kb_flush:
	in al,kb_status		; get 8041 status
	test al,1 			; test output buffer bit
	ja kb_flush_back 	; jump if no character pending
	in al,p_kscan 		; get scan code from data port
	cmp al,0AAh 		; verify keyboard present
	jne kb_flush
	mov word ptr ds : [reset_flag],ax ; keyboard present
kb_flush_back:
	loop kb_flush 		; loop If zero
	xor cx, cx 		; delay
	loop $

;; other memory variables init stuff

; Assume first not Deluxe Keyboard
	and byte ptr ds:[kb_flag_1],(not dlx_kb)

; Send command to request ID code from keyboard.
	mov ah,05H 		; Read keyboard type
	call kb_cmd_send 	; -- send command.
	xor cx, cx 		; set up timeout count
kb_type_wait:
	in al,kb_status 	; get port status
	test al,l 			; data byte available?
	jnz kb_type_read 	; If so, go read it . .
	loop kb_type_wait 	; else wait awhile longer.
	jmp kb_not_dlx 		; timeout, default to non-dlx
kb_type_read:
	in al,p_kscan 		; read ID byte..
	test al,01H 		; deluxe kbd. bit set?
	jz kb_not_dlx

; 01H bit set, so initialize to Deluxe Keyboard.
	or byte ptr ds:[kb_flag_1],dlx_kb
kb_not_dlx:

(single semicolon comments are the original ones. Double semicolon ones are mine)
For reference,

Code:
p_kscan	equ 060h
p_kctrl	equ 061h
kb_status	equ 064h

So there are three distinct parts:
a) "remove keyboard reset", ie release the clock line which, until that point, had been kept low (logic 0). Presumably this is what kept the keyboard LEDs blinking on the original keyboard (the Theory of Operation manual says that clock low for longer than 50ms triggers a reset).
b) "enable self test". This makes the keyboard controller send 0x10 (not 0x01!) to the keyboard. It then waits for 0xAA, which the emulator dutifully sends as soon as it spots the 0x10 from the M24. So far so good (I think).
c) "read keyboard type". This is where things go wrong. The code sends 0x05 to the data port of the keyboard controller (p_kscan), but nothing happens: nothing is sent to the keyboard itself. So the emulator does not know when to send its reply. The next IN operation always returns 0, and the keyboard is assumed to be non-deluxe.

This is where I'm stuck. I have tried several things (eg send another byte after 0xAA), but it made no difference. Incidentally CUSTOMER.EXE / SYSTEM.EXE seem to do the same thing - ie reset via the clock line & send 0x10, several times actually - but I can't get them to recognize that a keyboard is present (let alone which type).

I have now bitten the bullet and bought an AT&T keyboard off eBay so I can try and sniff the exchange, however it's not a "deluxe" type so it may not help me (and it hasn't arrived yet).

Any ideas?

Attached for your reference is the schematic I'm using (dip switches and M24 "sniffer" keyboard connector not implemented yet) and the source code. As always, if you want to experiment, use at your own risk...
 

Attachments

  • olivetti_kb.pdf
    28.7 KB · Views: 28
  • m24kbem090.zip
    7.5 KB · Views: 18
Last edited:
Great project, great research, great write-up. My only comment is that the type 2 keyboard was either not offered by AT&T (I've never seen one AT&T-branded), or was so uncommon that it isn't worth attempting to emulate as nothing supported it. A scancode conversion of an AT keyboard to the Type 1 keyboard would be 99.9% sufficient.

For the M24, that may be a different story, but I've never seen or held a Type 2 keyboard, sorry.
 
I have keyboard 1, keyboard 2, ... and keyboard 3.

If you provide me a software which raw accesses the keyboard to read all the codes they can do, then I can test with all of them. Don't forget, keyboard 2 can have mouse connector, and I have the mouse as well. We can also see if there are differences in nationality, all my M24 keyboards are germam, except of one extra keyboard which is swiss.
 
Great project, great research, great write-up. My only comment is that the type 2 keyboard was either not offered by AT&T (I've never seen one AT&T-branded), or was so uncommon that it isn't worth attempting to emulate as nothing supported it. A scancode conversion of an AT keyboard to the Type 1 keyboard would be 99.9% sufficient.

For the M24, that may be a different story, but I've never seen or held a Type 2 keyboard, sorry.

Thank you. It's true, I have never seen a 102-key AT&T 6300 keyboard either. Strange - as far as I recall, the 102-key "Type 2" keyboard for the M24 is far more common than the Type 1 in Italy (I have never seen an M24 Type 1 keyboard in real life, but I have seen many Type 2s).

It should be straightforward to add Type 1 emulation - only a few keys are different (plus the numlock behaviour).
 
I have keyboard 1, keyboard 2, ... and keyboard 3.

If you provide me a software which raw accesses the keyboard to read all the codes they can do, then I can test with all of them. Don't forget, keyboard 2 can have mouse connector, and I have the mouse as well. We can also see if there are differences in nationality, all my M24 keyboards are germam, except of one extra keyboard which is swiss.

I'd love to see a photo of a Type 3! What's it like?

Thanks for the offer! Unfortunately the raw dialogue between the M24 and its keyboard is masked by the 8041 keyboard controller, and is only accessible by eavesdropping on the CLOCK/DATA lines themselves. As for the different national versions, I would expect the scancodes to remain the same, and the localization to be done entirely by the keyboard driver (I think).

One thing that would be useful is to try the Olivetti Customer Test (CUSTOMER.EXE) and select the keyboard test and take a screenshot - as per my previous post, in my case it looks quite weird and I don't know if it's normal. Here is the link if you don't already have the disk: ftp://ftp.oldskool.org/pub/drivers/ATT/6300/6300 disks/A6_CUSTS.ZIP

Over the next few days I will try to put the BIOS keyboard ID code in a small .COM file so it can be executed from the DOS command line - it would be great if you could test that on your keyboard(s) and post the results here.

As for the mouse... yes I did think about it, maybe I will include it in a future version of the emulator!
 
Sorry, I have checked, I thought that I have a keyboard 1, but I haven't, or haven't found it. Currently I have 3 keyboard 2 in different nationalities (ger, swiss, uk/us) and a keyboard 3 (ger). The two german keyboards have the mouse connector and I have 2 mice. But as you will see, all of them could have the mouse port, they are just covered instead of a connector. I don't know if I just can add the port by soldering the connector, or if I would need a different firmware in the keyboard controller. Currently I have no space to setup the M24, my desk is full with other things. I would need some days to finish that project on the desk and reassemble it, before I can setup the M24.

As you can see, there are two different designs of Keyboard 2.

key3ger-m.jpg key2-uk.jpg key2sw.jpg key2ger-m.jpg
Keyboard 3 ger , Keyboard 2 swiss, Keyboard 2 UK/US, Keyboard 2 ger with different design
 
Thanks - that Keyboard 3 has a very interesting layout, I've never seen it before. Could you flip it over and read the model number? I believe Keyboard 2 model number is ANK 2462, so I would expect this one to be different.
 
Yes the keyboard 2 is ANK 2462. The keyboard 3 is ANK 2465. These S0, S1... keys have same functions like some ALT+<key> or CRTL-<key> functions on standard keyboards. I haven't found all of them yetm but I also did forget to note the working ones. It could be seen for example in Checkit keyboard test.
 
SUCCESS!!!!

Several news:

I have received the AT&T keyboard I bought from eBay. It's in very good shape except the "O" key which does not work as it has corroded pcb tracks (I'll try and fix it later).

Interestingly, it's neither a Type 1, nor a Type 2, nor a Type 3. It's a Type 4! The model number on the back is "KBD 302" and the only difference vs Type 1 (apart from the layout of the keys) is that it has an extra "Msg Wndw" key in the numeric keypad. I wonder what it was for? It also has a mouse connector on the back, but I have not tried yet whether it works or not.

ATT_KBD302.jpg

I sniffed the dialogue with the M24 and it turns out the correct response to 0x10 is to send THREE bytes: 0xAA (as we knew), 0xFF, and THEN the keyboard ID byte. With this information I experimented a bit and found the following:

- Sending 0x00 as ID byte is equivalent to "no keyboard attached"

- Sending 0x01 as ID byte identifies the keyboard as Type 2, ie 102-key. SYSTEM.EXE now sees a keyboard connected and calls it "STANDARD KEYBOARD", and prints a correct key layout for testing - here it is:

KB_TYPE2_TEST.jpg

- Sending 0x02 as ID byte identifies the keyboard as Type 1, ie 83-key. SYSTEM.EXE calls it "83 KEY KEYBOARD", and prints a correct key layout for testing - here it is:

KB_TYPE1_TEST.jpg

- Sending 0x03 as ID byte identifies the keyboard as Type 3, ie the keyboard 1ST1 posted photos of (model ANK 2465). SYSTEM.EXE calls it "DATEV KEYBOARD", and prints a correct key layout for testing - here it is:

KB_TYPE3_TEST.jpg

A bit of googling reveals that DATEV is a German data processing company which in the 80s commissioned a special version of the M24 called the Olivetti DVS ("DATEV-Verbund-System"), which came with the special Type 3 keyboard, which seems to be a Type 2 with extra S1...S6 keys and six fewer F-keys (maybe the scancodes are the same). Here is an article about it: https://www.datev-blog.de/2016/07/29/der-datev-pc/ (in German, but automatic translation seems to do a decent job). Some more photos here: https://olivrea.de/olivetti-m24-datev-verbundsystem/ , but with a standard keyboard.

OLIVETTI-Personal-Computer-Datev-Verbund-Typ-DVS.jpg

- Sending 0x04 as ID byte identifies the keyboard as "Type 4", ie the keyboard I bought (model KBD 302). SYSTEM.EXE calls it "84 KEY KEYBOARD", and prints a correct key layout for testing (which includes the extra Msg Wndw key) - here it is:

KB_TYPE4_TEST.jpg

I have not tried ID bytes above 0x04.

With this information and following Trixter's suggestion I have updated the emulator to:
- default to emulate a Type 1 keyboard rather than Type 2. This is because the character pairs on a Type 1 keys match exactly those on a modern US keyboard (eg it has a ; : key, which can be mapped exactly, while a Type 2 has a ; + key, which you can either map to get the ; right or the + right, but not both). RightCTRL + 1 or 2 switches between the two types.
- correctly identify reset pulses via the CLOCK from the M24. If the M24 CLOCK is held low for more than 25ms, it is interpreted as a reset (although the only thing the emulator does then is to - optionally - blink the LEDs, like the original M24 keyboards do).

Latest version attached.

Also here's a photo of the expertly breadboarded prototype :) - I'll try and lay out a decent PCB when I get a moment.

Breadboard_kbem.jpg
 

Attachments

  • m24kbem095.zip
    8.4 KB · Views: 16
I never have seen that type 4 keyboard before. Interesting. But there must be a 5th keyboard, your type 4 keyboard, as compact as it is, reminded me on this 5th one...

See http://www.nightfallcrew.com/23/02/2014/repairing-a-defective-olivetti-m21/

Indeed that's the M21 keyboard, which the Theory of Operation manual lists as equivalent to the Type 1 keyboard - same number/type of keys, just different layout. Btw I tried returning 0x05 or 0x06 as ID bytes to see if SYSTEM.EXE recognises more than four keyboards, but those ID bytes are not recognised - they seem to be equivalent to "no keyboard connected".

For completeness, here is a photo of a Type 1 keyboard (with an Italian layout):

Keyboard1.jpg
 
By the way, that keyboard emulator might be interesting for me. When the design is ready, will it be available for others as well? Will it be an adapter for modern keyboard (AT, PS/2, USB, BT), or will it be connected to another modern PC and to control the M24 via an application?
 
By the way, that keyboard emulator might be interesting for me. When the design is ready, will it be available for others as well? Will it be an adapter for modern keyboard (AT, PS/2, USB, BT), or will it be connected to another modern PC and to control the M24 via an application?

The software is pretty final now I believe - I may add some refinements such as timeout safeguards on the AT clock line and support for the M24 F13-F18 keys (Keyboard 2 only) later, but it's essentially 99% there I think.

The hardware design is also fairly final, it's a pretty simple circuit but there are still a couple of things pending:
- I want to understand why the M24 +5VDC supply is so (relatively) weak at the keyboard connector. It may simply be a case of poor ohmic contact of the 9pin connector, but I haven't had a chance to check
- as a consequence of the above, I have not added a diode between the M24 +5VDC supply and the rest of the circuit, as I fear the diode forward voltage will cause the power supply voltage to drop too far below 5V for the Arduino or the 74LS07. The drawback of this is that it's unsafe to connect a (switched-on) PC to the keyboard emulator circuit via USB if the emulator circuit is connected to an M24 that is switched off (all other configurations are safe).

The emulator should work with any AT or PS/2 keyboard (the latter would require a passive AT-to-PS/2 connector adapter if you build the external circuit with an AT socket as I have done), although I should point out that I have tested it with a grand total of just one AT keyboard. It won't work with a USB keyboard unless the keyboard supports the PS/2 protocol (and you must have the correct physical connector adapter). I don't know what a BT keyboard is.

To clarify - the main purpose of the emulator is to connect a real, physical AT (or PS/2) keyboard to an M24 (or AT&T 6300 or Xerox 6060) without needing a modern PC at all. You CAN, if you want (but you don't have to), also connect a modern PC to the emulator via USB to either a) monitor the scancode traffic between the AT keyboard and the M24, and/or b) use the modern PC to control the M24 via a terminal application like PuTTY as if you had a real physical keyboard connected to the M24. The latter functionality works even without a physical keyboard connected but it's very limited (ASCII characters below 0x7F only, no special functions like cursors, etc).

As for "available for others", both the software and the hardware design are free for anyone to use (at their own risk) - see the GNU GPL for details. If you mean "will you be making and selling these", I'm afraid not - it's really really not my day job :) (and I believe I would have a total worldwide market of less than 5 people :) ). Having said that, I'd like to lay out a PCB for this (physical layout suggestions welcome) when I have time. When I do, the miminum run to get it fabricated will be 10 boards, and I only really need 3, so if anyone wants one of the other 7, pls let me know and I'll post it to you (no charge).
 
Last edited:
I am interested to have one board, would you also provide a programmed Arfiuno? (I don't think I don't have the equipement to do that)

Do you also plan to emulate the Olivetti keyboard mouse via a PS/2 mouse? (would be great!)
 
I am interested to have one board, would you also provide a programmed Arfiuno? (I don't think I don't have the equipement to do that)

Programming an Arduino does not require any special equipment - you only need a USB Mini (not Micro) cable (e.g. this: https://www.ebay.com/itm/222456479832 ), the Arduino IDE (download for free from https://www.arduino.cc/en/Main/Software ) and the drivers for the USB COM interface (a bit trickier - these seem to work ok with the cheap Chinese clones that use the CH340 chip: https://sparks.gogo.co.nz/ch340.html ). Chinese clones cost less than $3: https://www.ebay.com/itm/381374550571 . I have quite a few lying around, I can send an already-programmed one to you, but I'd encourage you to have the setup to program it so you can update / customise the firmware if you want.

Do you also plan to emulate the Olivetti keyboard mouse via a PS/2 mouse? (would be great!)

I have not gotten there yet! I although I have already bought on eBay a Logitech mouse that should be equivalent to the Olivetti one, so I can start experimenting... Although in reality it's not hard to find a serial (RS-232) mouse that can be connected to the serial port of the M24, that would work just as well in most situations (but won't do the M24 neat trick of emulating cursor key presses when the mouse is moved).
 
Back
Top