Re: [hatari-devel] Proposal: use Atari keyboard with Hatari

[ Thread Index | Date Index | More Archives ]

Hi Eero and Vincent


Yes, using SDL locking primitives is a good idea ! I'll have to add logic though to so we know when a packet starts and ends. There is code for that in EmuTOS's aciavecs.S so that will help me.

No there is nothing to recover from a glitch at the moment. The glitch can happen between (1) the keyboard and the ST, or (2) between the Atari and the PC.  I could catch them both but to report (1) I would have to have some protocol, as transmitting raw bytes won't work anymore. I would have to transmit 2 bytes (one for the status/error, the other for the data) for every IKBD byte to transmit rather than one , so tranmitting at 9600bps won't be enough anymore, and at 19200bps we may have even more (2) glitches. So I'm keen to ignore (1) glitches and only address (2), which I can fake in the emulated acia.

I'll push things to branch on my cloned repo and improve things as per the above later (since I bought a new synthesizer today, I have other plans for tonight ^^). I'm not sure how to produce patch files, git has so many options for it :/


Thanks :) Yes I saw that CONF_SERIAL_IKBD in EmuTOS but I didn't understand why it was used for !

By the way, during the Atari Days Nançy 2020, AD showed an Atari Mega STE keyboard connected to a Raspberry PI running Hatari, there was an Arduino in the middle adapting the IKBD's serial line into USB keyboard. Indeed, if the Arduino can poll at 7812.5 baud then we can use that, rather than having a ST between the Atari keyboard and the PC. I have an unused Arduino here, so that's a nice next project idea :)


Le 09/01/2021 à 19:16, Eero Tamminen a écrit :


On 1/9/21 7:38 PM, Vincent Barrilliot wrote:
It has the following limitations:

* I haven't disabled the PC's keyboard and mouse handling. So you can use both the PC and the Atari keyboard mouse. But if you use both at the same time, multiple-byte IKBD packets will get corrupt and can lead to unexpected effects in the TOS.

Could (SDL2) locking primitives be used to avoid
them getting mixed?

(That's at least something that would need to be
fixed before there's any chance of it getting to

* I added a config switch but it's hardcoded, there is no UI to configure it.

That's fine.  There are also other things in
Hatari that can be enabled only from command line.

* The serial port handling is linux-specific.

* There is no error handling of what happens on the serial port.

Does it recover if there's a temporary glitch?

I have some questions:

1 What's your view on this change ? Any chance you would ever accept to merge that in hatari ? I think using keyboard/mouse is ok because you can hardly loose data in case something goes wrong. It's not like using a DMA device through a serial line with all the trouble that Nicolas mentioned.

It seems a bit marginal, so I don't know, but send
a patch so that we we see how much changes it

2 I would like to add configuration. I found that there is a good looking pythonui in addition to the SDL one. Why is that ? Is one of them going to be retired / would I need to support both ?

As Python UI docs says, it's not going to replace
the SDL UI (and neither is Mac GUI), both have
their own pros & cons.

3 It works on linux only. I think I can make it work with anything that support struct termios (like the RS-232 emulation does). Should I refactor to make this RS232 more reusable (it currently uses some static variables) or it's better to keep the external ikbd stuff a completely a separate implementation ?

If it can use any external serial device, it
might have wider usage.  What the others think?

    - Eero

Mail converted by MHonArc 2.6.19+