newRPL: [UPDATED April 27-2017] Firmware for testing available for download

[Han]

(02-28-2017 07:55 PM)Claudio L. Wrote:  

(02-27-2017 04:37 PM)Han Wrote:  This would break backward compatibility, and it seems it would also make it more difficult to use in a program. I agree the string makes it easier to visualize the keycodes, but it seems that in doing so we may have added an extra layer of complexity to parsing the keycodes from a programming standpoint. Having the string be of standard width would help, though (e.g. "7..D" should probably be "7. .D" or something similar so that users can always assume that the keycodes are always some fixed position within the string)

Did you ever need to parse the keycodes in numeric format before? I never had to, and especially considering keyboard will mostly be handled by the forms engine. As far as I can think of, all you'll need is to compare the string with another string to see if the key pressed is the key you expected, something like:

Code:


0 WAIT
CASE
DUP "3" SAME THEN ... END
DUP "7..D" SAME THEN ... END
...

That would work perfectly fine for a routine that checks each individual combination (lots of unnecessary tests in a general case). It was fairly common in the HP48 series to break up the testing based on the shift planes (and then the actual key). I vaguely recall that many parameterized outer loops had key handlers that broke up the cases based on the shifts. Testing by shift planes reduces the number of tests in the general-case and worst-case scenarios. It also helps organize the key definitions (by shift planes) better than a simple list that may or may not be organized.

Whatever your choice, I still think a fixed format where every character (or every two) represents some bit of information. Then users can choose to a single CASE block, or break it up into shift planes by using the fact that the keycodes are in a fixed format. My recommendation for codes (slight alteration of yours):

"XYYZ"

X = KEY = A-Z, 0-9, *, -, +, ., u (up), d (down), l (left), r (right), b (backspace), e (enter), s (space), o (on) -- please note upper vs lower case
YY = SHIFT = two characters; first is shift combination, second is hold or not hold (a = alpha, l = left shift, L = alpha left shift, r = right shift, R = alpha right shift, H = hold)
Z = MODS = keep as you already described

On-hold would be: "o H "
Right shift B would be: "Br "
Alpha B would be: "Ba "
Right shift (hold) B would be: "BrH "
Alpha right shift B would be: "BR "
Alpha right shift (hold) B released would be: "BRHU"

You can even reduce YY into a single character if you opt to have A for alpha hold, and then use \( \alpha \) and \( \beta \) for alpha left hold and alpha right hold respectively, and use O for on-hold --> "oO "

Lastly, I don't recommend using "." for both the key and for the separation of the codes even though it is not possible to confuse the two.