Keyboard layout support

[erkinalp]

Keyboard layout is hardcoded as QWERTY on zx128 code. I want to add Turkish F layout, but it does not fit.

[EtchedPixels]

does not fit in what sense ?

[erkinalp]

Routines are hard coded according to map size. Turkish script has more letters than English script of Latin alphabet. Accented letters are outside ASCII range. So it overflows. I plan to use CP857 as Turkish encoding in order not to break assumptions in the module. I do not have a real HW keyboard controller used in a ZX128 board. Is it safe to extend map definition in size?
Keyboard layout is defined in https://github.com/EtchedPixels/FUZIX/blob/master/Kernel/platform-zx128/devtty.c .

[EtchedPixels]

I'm still a bit confused. The spectrum keyboard matrix is only 5 rows x 8, and limited to a physical 40 keys. Changing the keymap is easy enough but given the hardware physically only supports 40 buttons.

If you've got a different set of I/O ports and map size then your platform can use a bigger keyboard map (several platforms use differing sizes including the NC100, Amstrad PCW and the Dragon port).

The rest of the kernel only sees the ascii type codes.

I would try and keep the same basic key up/down map that they all use because at some point that will want exposing to applications so people can write games or GUIs that want to read the keyboard state themselves.

[erkinalp]

Scancodes would serve this job better. Others will also want to customise keyboard map.

[EtchedPixels]

The Unix API is a byte stream and ascii (or it could be UTF8 unicode). Nothing in the video driver understands utf-8 but the change ought to be small. You'd just have to work out how to manage the font mapping efficiently.

A GUI might have different needs, and we could in theory then add a mode where we returned row/column pairs instead (and let the user space do the translations as it wanted).

[EtchedPixels]

keyboard bitmap reporting API added. UTF-8 in the keyboard driver of a Turkish machine actually looks to be fairly easy to. Make the map table 16bit UCS2 values not 8bits/char and then write 1-2 bytes according to the unicode value.

So I don't think there is an imput problem here having looked in detail. Similarly on output your vt output routine would need to assemble unicode sequences.

[erkinalp]

Changing the keymap is easy enough but given the hardware physically only supports 40 buttons.
ZX Spectrum 128 definitely has more than forty keys on its keyboard.

[EtchedPixels]

Spectrum has 40 keys. The 128 appears to have more but they are wired in the keyboard matrix to press two buttons at once. I've actually implemented minimal unicode input support and some special encodings for byte sized keycodes to cover £ € ½.

Doing it more generally you'd just need to change your keyboard driver to generate utf-8 codes not byte ones and then queue the utf-8.

[erkinalp]

14 Oca 2015 20:37 tarihinde "EtchedPixels" notifications@github.com yazdı:

Spectrum has 40 keys. The 128 appears to have more but they are wired in
the keyboard matrix to press two buttons at once.

So sad. It means we would have no means to have N-key rollover on ZX
Spectrum. Maybe up to three keys at once. I will have to consider this when
designing the Turkish keymap.

[erkinalp]

FYI, Turkish F layout is something like this:
https://upload.wikimedia.org/wikipedia/commons/5/5d/KB_Turkey_f.svg
Ç, Ğ, İ, ı, Ü, Ö, Ş are considered separate letters from their unaccented ones in Turkish. I am planning to experiment a key reduction exercise to fit on Spectrum and the like.