[Enchancement] Add functionality to new (ISO) encodings

[adiee5]

Since we added new encodings to cx16, it may be also nice to give them some kind of functionality. I mean, some stuff just work OOB, such as printing text, data interchange, saving text files etc., because they work the same way as ISO-15. However, there could be other stuff added to the ROM to support them even further, such as file(name) io and keyboard support. i already covered iso-16 input in #329 , but other things also should be discussed.

[mooinglemur]

Data interchange on 8-bit systems between encodings is a headache, and I don't think the effort here is worth the complexity much beyond what we've already done with keyboard layouts. The additional charsets and being able to reach them via the keyboard was essentially free of conflict and additional complexity with other code or parts of the KERNAL, and that's the main reason they were accepted readily.

The filesystem code is all locale-agnostic and locale-unaware, except for the mappings between ISO-8859-15 and UCS-2 (and the corresponding HostFS conversions between ISO-8859-15 and UTF-8), and I'm not too interested in introducing a new ambiguity in translation between ISO and UCS-2/UTF-8 in the file layer, nor additional complexity to handle those cases.

[adiee5]

Yeah, sounds reasonable. I guess lack of support in File IO is not that big of a deal and we can live without it. Ascii-only filenames are a good practice even on modern platforms anyways.

Since everything else works, maybe we could discuss how we should design layouts for non-latin scripts (cyrillic for now, but I'm also working on a katakana charset now). There are few options:

• Implement some way of switching layouts or extend the layout specs to implement some kind of new table type that would indicate a layout in "Switch in" mode (by tabe type i mean this byte that has bits corresponding to iso ctrl shift etc.)
• Latin normally, non-latin under ALT (not so fun experience typing)
• Non-latin normally, latin under ALT (idk if this wouldn't be going to affect the usability of software)
• Maybe there is a better idea, but idk

[adiee5]

Ok, I think i didn't explain too well what i meant in the first option i wrote, so let me explain.

In the first point, I actually made 2 separate exclusive suggestions on how we could handle it:

1. In this method, user choses in MENU 2 layouts he'd like to be able to switch between. Then, the kernal keyboard handler, when it hears a specific button combination (up to debate), it switches to the second layout provided by the user.
2. Layout has predefined tables for both latin and non-latin. If user presses a language shift button or a key combination, the layout will be in some kind of "Shift IN" mode. I know, that the Table ID does have a free bit that could be used to define tables for "Shift IN", sadly there doesn't seem to be any kind of attribute table for the entire layout, where could be stored information, that this layout relies on Shift-in (so we can't for example repurpose Caps-Lock be the language change button for those layouts).

[mooinglemur]

• I think the first point might be worth investigating, a keymap toggle combo, but there's no obvious combo to use for this.
• The bank that contains keyboard layouts is quite full. I don't think we have room in it to add any additional ones without some sort of refactor or by using another bank. It's not a trivial change.

I was under the impression that the additional glyph sets were added mainly for display. I wasn't aware you had adding layouts/full input methods for them in mind. This is a much bigger task.

[adiee5]

• The bank that contains keyboard layouts is quite full. I don't think we have room in it to add any additional ones without some sort of refactor or by using another bank. It's not a trivial change.

I wasn't aware of that, thanks for the info

I was under the impression that the additional glyph sets were added mainly for display.

I mean, this on its own is like 75% of the work needed for the full support. Input is just the remainder.

I wasn't aware you had adding layouts/full input methods for them in mind. This is a much bigger task.

Don't worry, I'll handle the burden of actually designing the layouts.

[adiee5]

a keymap toggle combo

Hmm

alt+capslock maybe?

Windows, Gnome, Android and probably many other Environments use win+space for this, but since I've yet to see any kind of cx16 software (whether ROM or User software) actually react to this button (and because I think Emulator does not capture this button), that's a no-go. I think alt+space may be a no-go too, because I think that's handled inside the layout itself (the 0:$A000 space), not directly by kernal (and it's likely it's already mapped to nbsp anyway).

Let me know what do you think