Mega65 symbols transferred to TI-functions

[NuClear235]

Could You please add option, where will be default functions and characters from Mega65 keyboard translated to TI system? Shift + 2 (") will do C= + P and write ". DEL will do C= + S and do DELETE... And so...

[tonedef71]

@NuClear235 It sounds like you want specific keystrokes of the MEGA65 to map to specific key combinations of the TI-99/4A.
I can see how that capability would make it easier for MEGA65 owners to operate the Mega99 core.

Your keyboard mapping suggestions, as I understand them:

MEGA65     | Mega99   | Result
=================================
Shift + 2  | Fctn + P | (")
---------------------------------
Del        | Fctn + S | (delete)
           | Fctn + 1 |
---------------------------------
and so on...
---------------------------------

[zeldin]

This is not as straightforward as one might expect. So let's say that you want shift+2 mapped to fctn+p. In order to press shift+2 you first have to press down shift and then 2. When shift is pressed down, this does not yet match your chord, so no mapping is done and the "shift" wire going towards the TMS9901 is asserted. Then when the "2" key is pressed, the "shift" signal has to be deasserted, and the "fctn" and "p" signals have to be asserted. But the TMS9900 can not poll all the keyboard signals at once, it has to get them one at a time from the TMS9901. So if "shift" is deasserted and "fctn" and "p" are asserted all at the same time, it could happen that the TMS9900 has already checked the "shift" and "fcnt" lines before the press of the "2" key was detected, and found that "shift" was pressed but not "fctn", and then checks the "p" line afterwards, to find that "p" is pressed. In this case, the registered keystroke would be shift+p, not fctn+p. In order for this to work the "shift" signal would have to be deasserted and "fctn" asserted first, and then there would have to be a wait with neither "2" or "p" asserted until the "shift" and "fctn" lines have both been scanned by the TMS9900, and then finally "p" asserted. A similar problem occurs when releasing the keys. A simpler solution to get what you want could be to just replace the keymap in the console GROMs. That way you can easily get " on shift+2, but you would not be able to remap any keys outside the matrix hooked up to the TMS9901, so it would not be possible to map the DEL key in this way for example.

[tonedef71]

I think that some FPGA retro-computer designs have had to build-in a custom microprocessor to offload and perform special processing (e.g. video signal scaling) so that the original specs of the legacy components built via the FPGA are uninhibited and uncompromised; going a route like that that sounds like some considerable rework to me.

A simpler solution to get what you want could be to just replace the keymap in the console GROMs. That way you can easily get " on shift+2, but you would not be able to remap any keys outside the matrix hooked up to the TMS9901, so it would not be possible to map the DEL key in this way for example.

@zeldin Your solution sounds good to me, since ultimately, the goal is to achieve the desired output (quotation marks entered via the MEGA65 yield as quotation marks on the Mega99), whether it be done by a keyboard remapping or a re-translation.

I think then for deleting a character, the quirky TI-99 behavior (of moving the cursor back to the character to delete and then invoking the Delete sequence to erase that character) could be preserved but be executed more naturally by the MEGA65 keyboard (cursor left followed by INST/DEL). I haven't done much typing yet in Mega99; perhaps it already works this way?

[zeldin]

Well, I mean I do have the OpenRISC softcore where I could do processing if needed. But that would mean severing the HW connection between the keys and the TMS9901, and doing keymapping in software. So I think in that case it would be a special mode which only handles "typing" and no N-key rollover or stuff like that. For games you would have to switch out of that mode probably.

[tonedef71]

Well, I mean I do have the OpenRISC softcore where I could do processing if needed.

@zeldin 😮 You never cease to amaze! 😀

... that would mean severing the HW connection between the keys and the TMS9901, and doing keymapping in software. So I think in that case it would be a special mode which only handles "typing" and no N-key rollover or stuff like that. For games you would have to switch out of that mode probably.

That sounds like a sensible compromise.

[NuClear235]

Nice ideas. Thanx all for any progress. Switching between special mode and native mode could be made by the hotkey. To be easy accesible. Best will be CAPS LOCK in upper line next to NO SCROLL key. So will by visible with integrated LED in what mode you are now…

[zeldin]

CAPS LOCK is already in use as ALPHA LOCK (the actual capslock function :smile:). I really wanted to use SHIFT LOCK for that, but it turned out to be impossible because SHIFT LOCK can not be distinguished from the left SHIFT key on the MEGA65, these two are tied together like on a C64. Even so, if CAPS LOCK had been available I would have used it for the turbo function instead.