So we now know the Foenix computer will have a PS/2 keyboard. We'll need to convert the PS/2 scan codes to something more useful when working in the editors and the terminal.
Since we need to deal with 102-104 keys on a standard AT or PS/2 keyboard, I'm going to propose the following procedure:
The keyboard buffer will be populated when a printable key, cursor keys, Insert, Delete, F-Keys, or Escape are pressed. Modifier keys will not generate keyboard buffer entries by themselves.
The keyboard buffer will contain two bytes for each keypress. The first byte is the modifier status. The second is the scancode.
GETCH will return a 16-bit value in the accumulator. The lower 8 bits are the ASCII value generated by the keystroke (if applicable.) The upper 8 bits are the modifier status. A bit in the upper 8 will also be set if the key pressed is an action key or function key.
The Foenix will also have a 20-pin Commodore keyboard connector. These values will be mapped to scancodes when keystrokes are read into the buffer.
The C= key will be mapped to the Alt key.
Run-Stop maps to the Escape key.
Non-ASCII symbols will map to the PETSCII value. So expect the £ key to generate a \ when using ASCII fonts. ← prints `, etc.
Commodore keyboards do not have End, Page Up, or Page Down keys. They also don't have F9-F12. I'd like suggestions on how to map C= keys to those keys.
The text editor will use PC keyboard conventions, such as:
Home will go to the start of the line.
Insert toggles overwrite mode; it does not insert a space.
Alt and Control are used for editor commands and will not generate PETSCII symbols. We'll come up with some sort of pop-up menu for inserting graphic symbols, colors, and cursor controls in your programs.
How would you handle shift and shift lock? Is "Shift"+"A" an "a" with a shift modifier? Or would it be an "A"?
I'm assuming it would be an "A", so it is handled similar to a "Shift"+"6" being a "^" (not a "6" with a shift modifier).
But there are other like "Tab" that are a valid character ($09), but "Shift"+"Tab" isn't (so it would probably need a "Shift" modifier and a "Tab" character?). Just looking at my keyboard, Tab and Backspace seem to be the two keys that have ASCII codes but are not clearly defined when shifted.
There is also the Caps Lock and the Num Lock to deal with, but those seem reasonably intuitive.
But the big challenge is one I've run into on FPGA and software "emulation" using PS/2 keyboards.
On the original Commodores (and Ohio Scientific C1/C4, Tandy Color Computer, etc.) you have a scanned matrix keyboard.
A lot of games "manually" scan the keyboard. For example, with something like Pong, I may look for the "up arrow" and the "down arrow". I don't look for individual presses of those keys--I just scan the keyboard a few times a second and if one or the other is pressed I moved the paddle appropriately.
PS/2 keyboards are fundamentally different since they are effectively serial devices.
When I press "A", it sends a $1C (the "make" code for the "A" key). When I release the "A" key, it sends a $F0 followed by a $1C (the "break" code for the "A" key).
But you also have typomatic come into play.
If I hold "A" for longer than 500 milliseconds (I believe the default set as part of the keyboard's power up), it will begin sending additional $1Cs at the rate of around 10 times per second. These parameters are the typomatic delay and the typomatic repeat rates.
So if I am playing Pong and press the up arrow, there is typically no easy way to determine that I have intentionally continued to press the arrow for half a second. When you port games that used the scanned matrix keyboards, they might be reading the status of the up and down keys several times per second.
Duplicating the expected behavior is tough. I can snag the scan code, "dummy" a key closure in a emulated matrix, effectively ignore repeats of the make code, and only change the status in the emulated matrix when I receive a "break" code. That is actually what I would describe as the "proper" way to handle putting a PS/2 keyboard into an emulated keyboard matrix.
But that is not the way we are conditioned to expect the keyboard to work when we are doing something like typing. In the old days with most Commodores, you would press "A" and you got a single "A". You could hold it for a minute and still get just a single "A".
But if you press the Space Bar or one of the cursor keys, they actually had their own form of typomatic--there was a delay and then they repeated at some rate. (There were "pokes" that could change the typomatic paramters (although nobody called them typomatic back then) and that could also enable "repeat" for all keys.) (A lot of other machines had something like a "Repeat" key that you would press after pressing the key you wanted to repeat and then you would get the character repeated until you released one of the keys--so far as I know, Commodore never did that.)
"Standard" PS/2 keyboard driver code tends to work great for text applications. For emulation of interactive use on systems with scanned matrix keyboards, this tends to be something that is kind of a "make or break" in it feeling (and acting) like the original.
You can get around a lot of that by using joysticks for game input---but then you get into how are joysticks going to be implemented? Is it going to look like a digital joystick connected to a MOS 6526 CIA? :-)
Actually I had done my own "What would be the perfect 8/16 bit machine?" a while back and they keyboard was a (pun intended) key part of that. The scanned matrix is great for true "real-time" interaction with the user. Joysticks are good, but were often implemented in a similar fashion.
Going back to the the basic premise of what would likely have been done in the 1980s, I think you are right at the time when things were changing and moving towards the separate keyboard. I tend to think a hobbyist machine would have stuck with the scanned matrix, but detached keyboards were nice--they had been a luxury because cable issues and dropped keyboards scattering their keys on the floor tended to be expensive problems. If a vendor had introduced a $15 detached and replaceable keyboard, it would have been gobbled up by the market.
And maybe you just make a clean break from the concept of an emulated scanned matrix keyboard. If so, keyboard game input gets really tough without some way to gain native access to they keyboard.
Thanks,
Jim W4JBM
So I just remembered: the C= keyboard has some keys don't exist on the C64 keyboard: RESTORE, =, ↑, and £ don't exist, as such, on a PC keyboard. The \ key on a PC keyboard sits where the C64's RESTORE key sits, but £ is the same ASCII code. So I suggest we just map £ to the \ key. The ↑ is the same as the PC ^, so we should leave that alone. This leaves =. I'd suggest remapping the C64 + and - keys to the PC standards, _/- and +/=. (So you'll want to physically swap + and - when using that keyboard on the Phoneix.)
That leaves the = key to be used as an extra key, roughly the equivalent of the "Fn" key on laptop keyboards. So my suggestion is to use the = key to toggle modes, giving the user access to an embeded numberic pad (789 UIO JKL, M , .), and cursor keys on the left side of the keyboard:
WASD - arrow keys
Q/E - Home, End
R/F - PgUp, PgDown
Wow!, Okay... You really need to get your hands on one of the those awesome C256 Foenix box dude! lol
Roger that!
Stefany