IKBD-to-USB?

[displaced]

Hi!

I picked up a TOM2 for testing with my STFM and Falcon030. It really is quite something to use a modern, wireless mouse and gamepad with these old machines!

Buuut... If I wanted wireless mice and gamepads with both my ST and Falcon, I'd have to buy 4 TOM2s ... and that still doesn't help with the keyboard.

So after a bit of googling, I came across this thread on here which piqued my interest.

I'm really keen on the idea of a little Raspberry Pi Zero sat inside the ST case alongside a small USB-OTG hub and a couple of USB receivers for keyboard, mouse and gamepad.

I just wondered if anyone else had picked up on that thread and had any further experience with it? I know the code's not quite complete, but I'm happy to hack on the software to see if I can get it to support a bit more of the full functionality.

I've got the Pi Zero arriving tomorrow for a bit of tinkering on the project. I do have one quick question which isn't entirely clear reading through... can the internal keyboard also be connected at the same time as the Pi Zero?

Cheers!
Chris

[1st1]

Just buy a CosmosEx, if you can. Under others, it does that.

[Cyprian]

"Atari Eiffel 3 Interface PS/2" and ps/2 to usb adapter
http://didierm.pagesperso-orange.fr/eiffel-e.htm

[displaced]

Thanks for the info! I’m on the wait-list for a CosmosEx - and I’ll take a look at the Eiffel.

I’d still like to have a play with the Pi Zero method. It arrived today and I’ve got it hooked up to my STFM. Ive our the ikbdemu image on the SD card and it boots. No luck getting keys sent to the ST, even though the Pi’s console shows the HID codes as keys are pressed.

Still wondering though - would it be possible to have the Pi and the stock keyboard connected at the same time?

Cheers,
Chris

[Greenious]

I believe the eiffel is ps/2 only, meaning that only usb mice/kbds with support for the ps/2 protocol works with it.

There are several mouse adapters, most are ps/2 only with the same limitations, but there are atleast one that works with actual usb mice. I believe it's called Jerry.

The IKBD communicates over a "high speed" serial link at the breathtaking speed of 7812.5 bits/s, if you can set you pi0 serial port to that speed it should work. Oh, keep in mind the pi0 is 3.3v, and the atari is 5v. You probably need some kind of buffer chip to fix that, even if the pi0 can handle 5v, I'm not sure the atari believes 3.3v is a 'one'.

You can not connect more keyboards at the same time, not without some kind of switch. I know that some company made such devices at some point, but I am not aware of anywhere you can get it.

[wongck]

but there are atleast one that works with actual usb mice. I believe it's called Jerry.

I am using a MS wireless mouse on a Smally USB mouse adapter on my Falcon. Also tested with a cheapo EUR 1.30 MIC no-brand wireless mouse. Both works, the MIC no-brand wireless mouse was very light so I went back to the MS mouse. For both, fast movements are not tracked properly and lags but OK for general use.
Smally mouse adapter was from http://www.gossuin.be/index.php/shop.

[displaced]

Thanks again!

Like I say, I’ve played a bit with dongles - currently have a TOM2 that works well for gamepads and mice, but it a) doesn’t help with the keyboard, and b) I’d have to buy another 3 of them!

The original thread suggests that the ST can see 3.3V logic, but yes, I’d need to use something to lower the 5V on the RX side of the Pi.

I had a thought this morning - the Pi has 2 UARTs - one’s usually set to handle Bluetooth, but it can be reconfigured to expose its TX/RX on the GPIO header alongside the regular serial pins.

Perhaps I can start by sniffing the data between the ST and the keyboard by connecting the ST to one UART and the keyboard to the other being careful of voltages), and write a bit of code to copy data from one to the other, whilst dumping the traffic that’s seen.

Would be nice if I didn’t have to go to work today!

[Cyprian]

I had a thought this morning - the Pi has 2 UARTs - one’s usually set to handle Bluetooth, but it can be reconfigured to expose its TX/RX on the GPIO header alongside the regular serial pins.

Perhaps I can start by sniffing the data between the ST and the keyboard by connecting the ST to one UART and the keyboard to the other being careful of voltages), and write a bit of code to copy data from one to the other, whilst dumping the traffic that’s seen.

cool idea, would be possible to use Raspberry Pi Zero for that?

[nobox]

Still wondering though - would it be possible to have the Pi and the stock keyboard connected at the same time?
Cheers,
Chris

Should be possible

[nobox]

The IKBD communicates over a "high speed" serial link at the breathtaking speed of 7812.5 bits/s, if you can set you pi0 serial port to that speed it should work..

the ikbdemu image does that for you

Oh, keep in mind the pi0 is 3.3v, and the atari is 5v. You probably need some kind of buffer chip to fix that, even if the pi0 can handle 5v, I'm not sure the atari believes 3.3v is a 'one'.

The atari recognizes the 3.3v serial signal. See https://www.youtube.com/watch?v=VrN7FOLFnlA

[nobox]

I once had a try with the atari keyboard: Made it pc-usb kompatible over an arduino with my code and than connected it with the raspberry ikbdemu. was kind of funny to sniff the kbd data while normaly using the atari.

[joska]

I've got the Pi Zero arriving tomorrow for a bit of tinkering on the project. I do have one quick question which isn't entirely clear reading through... can the internal keyboard also be connected at the same time as the Pi Zero?

This is what CosmosEx does. Take a look at the CosmosEs sources to see how this is implemented. You could even extract the necessary bits from these sources to build your Pi-to-IKBD.

[displaced]

Ah thanks guys!

Good shout on the CosmosEx code - I’ll take a look!

I’ve since discovered that although the Pi Zero does have 2 UARTs, only one is accessible at a time via the GPIO header.

I’ve got a USB UART so I can do some testing with that.

I did wonder if I could get away with one UART and simply connecting it inline with the keyboard’s TX line. But that’d only work to an extent. The ST can write to the keyboard controller, switching it between different reporting modes, so without also listening to the keyboard’s TX, the Pi would have no idea what mode to send commands back in.

To be honest, even if this is unlikely to be successful or if it’s beyond my skills, it’s good fun to tinker!

[joska]

If you want to use both the original keyboard and the USB2IKBD keyboard at the same time, you have to separate the original keyboard completely from the ST. The reason for this is that the IKBD protocol transmits packets, and only keypress/release packets are single bytes. All the other are multiple bytes. So you would need to buffer complete packets before you send them to the ST, otherwise you would mix data from both keyboards and create invalid packets.

You will have to do the same in the other direction too, packets from the ST must be buffered and sent to both the original keyboard and your USB2IKBD code. The state of both keyboards must be kept in sync.

You can also improve it's functionality by interpreting the packets and decide not to forward them to they original keyboard. E.g. if you have an Atari without RTC the clock-stuff can be handled by your implementation alone, using the Pi's clock instead.

The IKBD protocol is simple, so this is not very complicated stuff. But it needs a lot of testing.

[displaced]

Thanks, joska

That makes sense - I couldn’t see how just mixing serial lines could work really.

I’m going to start this evening by connecting the ST TX/RX to a USB UART interface and the keyboard to the Pi’s on-board serial port.

Then I’ll just do a bit of python to copy data between the interfaces so I can watch bytes fly past. Seems like a reasonable first step!

(oh, and the clock stuff is a great idea - the Pi Zero has WiFi, so I could get it to set the clock from an NTP server)

[joska]

(oh, and the clock stuff is a great idea - the Pi Zero has WiFi, so I could get it to set the clock from an NTP server)

Please note that TOS will only use the keyboard clock on machines with no RTC. E.g. it will only be used on ST and STE, not Mega ST/STE, TT or Falcon.

And if you add another USB UART to your Pi you can connect it to your Atari's serialport as well and set up SLIP or PPP on the Pi.

[Greenious]

It's not hard to write a small program that sets whatever clock you got from the NTP set ikdb one. But yes, TOS prioritise the various RTC's present in certain models.

btw, how fast is the ram in Raspberry Pi? I suddenly got this crazy idea of having it replacing and emulate ST-ram, a Pi zero is like 5 euros, and you could use it's remaining cpu power to run a sprite-engine, blitter and possibly other stuff...

[Cyprian]

btw, how fast is the ram in Raspberry Pi? I suddenly got this crazy idea of having it replacing and emulate ST-ram, a Pi zero is like 5 euros, and you could use it's remaining cpu power to run a sprite-engine, blitter and possibly other stuff...

+1

[displaced]

Ok - I've had a successful couple of hours (sadly I didn't have much time tonight).

I've taken 5V and GND from the ST's IKBD to a breadboard's power and ground rails. Then, 5V and GND to a 5V-happy USB UART, and TX/RX from IKBD also to the USB UART.

USB UART is plugged into a USB hub, which is hanging off the Pi Zero via an OTG cable.

A bit of Python successfully reads bytes being sent by the ST (although what it's reporting doesn't quite make sense according to the IKBD protocol docs... might need to tweak the port settings).

The 5V/GND rails are also linked to the HV-side of a TTL level converter, and also to the keyboard's connector.

Just need to hook the TX/RX of the keyboard to the 5V side of the level converter, then the 3.3V side to the Pi's TX/RX GPIO pins. Then I should have my serial tap in place for both directions.

I'm going to call it a night now. Plus, I've got a Pi Hat arriving tomorrow with two UARTs. That'll make it a bit neater.

(edit: Added screenshot. The first two bytes are received immediately after releasing the ST's RESET button. The stream of bytes after the line-break appear as soon as the desktop appears)

Screenshot 2019-02-14 at 00.30.14.png

[nobox]

the first two bytes usually are $80 $01 and are meaning reset for the IKBD device.
Maybe you have got a signed/unsigned prob here ? the values from ST are unsigned.

[tzok]

First few bytes depend on a TOS version. TOS 2.06 synchronizes clock with IKBD, older TOSes doesn't do that (unless some software is loaded).

[displaced]

Cool -- I'll look into it when I'm home.

I noticed that the baud rate is dropping the .5 once set -- so it's actually running at 7812. However what I receive is reliable and repeatable, so perhaps the missing .5 isn't an issue.

The ST's running TOS 1.02 and I'm booting direct to desktop. I've pulled the flash drive from my HxC just to be sure I'm going to a 'pure' GEM desktop.

I'll do some digging on the signed/unsigned part. However, but does the fact that I'm receiving 0x00 indicate something else is up? I mean, wouldn't 0x00 be the same, signed or unsigned? It's been a while since I did such low-level stuff, so I'm more than happy to be corrected

Thanks!

[nobox]

Maybe you Need some casting. I dont know, what types are port.read and in_byte, but maybe the prob is in the value assignment.

A $80 can be interpreted as a -127 decimal, and if yout try to put that in an unsigned variable, maybe ist assigned as 0. poo happens sometimes.

Try a direct print of port.read, does the value Change then ?

dont know much about python, i normally use Java and c, but I know, the first Bytes a Atari ST sends to its Keyboard have to be $80 $01

[displaced]

Pleased to say it's working nicely!

I think the USB UART was misbehaving. The dual-UART Pi Hat arrived -- fitted it, wired everything up, and my original code gave the expected $80 $01!

I completed wiring the rest of the kit up -- so starting with the Level Converter:

• Pi UART-A TX/RX to Chan1 TXI/RXO on the 3.3V side
• Pi UART-B TX/RX to Chan2 TXI/RXO on the 3.3V side
• ST KBD Port TX/RX to Chan1 RXI/TXO on the 5V side
• Keyboard KBD Connector TX/RX to Chan2 RXI/TXO on the 5V side

Then, fed 5V and GND from the ST to rails on breadboard - provides reference levels for the converter and also took 5V from there to power the Pi via GPIO pins 2 and 6. Finally, took 3.3V and GND from each of the UART ports to another set of rails on the breadboard and used that for the level converter's 3.3V side.

Finally, the Python code was updated to spawn two threads:

• Thread 1 reads from the ST-side UART-A and writes all incoming bytes to the Keyboard-side UART-B
• Thread 2 reads from the Keyboard-side UART-B and writes all incoming bytes to the ST-side UART-A

Best of all, the UART hat has TX/RX LEDs for both ports, so every keypress and mouse movement brings some blinky lights!!

I can now sit and watch bytes fly between the two devices. Regular ST keyboard, mouse and joystick works normally.

So, still to do:

• Adapt the breadboard layout onto some veroboard.
• Write a python representation of the IKBD protocol, and translate HID events for injection into the stream

So yeah -- plenty of coding to do!

I'm interested to see if there's any noticeable lag with python reading the HID events and generating the IKBD packets. I'm probably too old and my reflexes too janky now to seriously need to worry about wireless + HID + python-induced lag. I'm working on the basis that it'll probably be fine

Here's a quick pic of the setup!

IMG_2298.jpg

[displaced]

Ok, so the script now properly identifies all documented commands which the ST can send to the keyboard controller.

At the moment, all the command implementations simply pass the command as-is to the keyboard, but I've now got stub routines for each IKBD command which I can use to make sure the USB keyboard, mouse and joystick have their behaviour interpreted the same way that the real controller would do.

I need to do the same for the different types of keyboard responses. For the most part, I'll probably just let the real controller's command responses pass through back to the ST. That way, software will see what it's expecting to see, and I'll be able to tweak my implementation of the input handling to bring it inline with what it should be doing.

Regarding the RTC stuff -- my UK 520STFM, TOS 1.02 does not ask the keyboard RTC for the time during a 'clean' bootup (no AUTO programs, no ACCs, etc.)

Edit

Here's some transcripts of a couple of bootups. First column identifies the source of data. Second column is the raw byte value. OK indicates that the byte was successfully passed through to the other device.

Commands are named, with any arguments listed in [ ] after their name.

Gonna see if I can quickly hook up some HID keyboard injection before sleep.

Code: Select all

# Immediately after reset pressed
KB SEND      00      OK
KB SEND      f1      OK
ST SEND      80      OK
ST SEND      01      COMMAND   RESET []      OK
KB SEND      f1      OK

# Just as the GEM Desktop appears
ST SEND      08      COMMAND   SET_RELATIVE_MOUSE_POSITION_REPORTING []      OK
ST SEND      0b      OK
ST SEND      01      OK
ST SEND      01      COMMAND   SET_MOUSE_THRESHOLD [1, 1]      OK
ST SEND      10      COMMAND   SET_Y0_AT_TOP []      OK
ST SEND      07      OK
ST SEND      00      COMMAND   SET_MOUSE_BUTTON_ACTION [0]      OK

# Another reset...
KB SEND      00      OK
KB SEND      f1      OK
ST SEND      80      OK
ST SEND      01      COMMAND   RESET []      OK
KB SEND      f1      OK

# HxC Emulator Manager loads
ST SEND      14      COMMAND   SET_JOYSTICK_EVENT_REPORTING []      OK
ST SEND      00      OK