Keyboard Concepts - how to encode the keys outside of the ASCII sequence. What are the best ideas for CP/M?

[cj7hawk]

Hi All,

Well, I suppose sooner or later I was going to have to consider this, and it's time is now. Working with wordstar, and wondering how to get things like cursor keys working with the keyboard rather than having to use the left-side keyboard?

Having gone with ADM-3A for the screen, the cursor keys I naturally mapped to the ADM-3A combinatins - that is, I added up and right to the already existing BS and LF mappings for the cursor, which produces some neat results, like being able to move the cursor around the screen with just the keyboard...

Except Wordstar hates it. Left replaces backspace, which means I can set Backspace to $7F, which is rubout and down works, but it's a nightmare, and if I do that, of course it breaks the CCP, because now Backspace is a character, not a rubout, and it really left me wondering two things.

1) Are there any optimal solutions or established keycodes to return for things like numeric pad options, cursor keys, etc? Thinks like Insert / Delete / Printscreen / home / end / pageup/down etc.

2) Is there any way to get Wordstar to recognize these? Outside of encoding the wordstar options? And even then, is it a good or a bad idea?

3) ( because I can't count ) - Was there ever an established way to translate keys under CP/M - eg, so I could run a small config utility that would adjust the keys for CCP/Wordstar/Spreadsheet/Whatever before running it?

Thanks for any input on this -

David

 

[durgadas311]

Two examples of this that I have experience with. The Heathkit H89, which has an embedded H19 terminal, has a numeric keypad that supports a couple different sets of codes (as well as a row of function keys). These keys send ESC sequences when pressed, and the exact ESC sequences depend on what mode the terminal has been placed in. So, certain applications will put the keypad in a special mode so that it can be used with that software. I'm not sure whether Wordstar is capable of decoding ESC sequences, so it may require that the BIOS conin routine do that, and then do something like return codes with the high bit set and then Wordstar (etc) are configured to recognize those 8-bit key codes.

The second example is from the Kaypro, which emulates an ADM 3A for the screen. The Kaypro keypad and cursor keys send a special 8-bit code when pressed, and the BIOS uses a translation table to convert those into ASM 3A cursor control codes and standard numeric codes for the numeric keypad. The BIOS translation table may be altered to translate those keys differently, thus allowing for alternate uses. If the translations return 8-bit codes, then the application(s) using them must be capable of handling 8-bit codes.

Basically, you have two choices for the special key codes, one is to return codes with the 8th bit set and the other is to return control codes (in the 01-1F range that are not otherwise used). There may be some applications out there that aggressively clear the 8th bit on input, so that option may not always work. Be aware that CP/M uses more than just Backspace (08) and CR/LF (0D/0A) for commandline input (BDOS function 10), but typically those functions are performed using the Ctrl+Letter keys on the keyboard.

 

[daver2]

Of course, the Ctrl+Letter keys (depending upon where the conversion is actually done) translates into codes in the range 01-1F. 00 being Ctrl+@ (generally).

Dave

 

[skate323k137]

Yeah, wordstar expects crtl-[Alpha] characters for navigation. I ended up coding that into my adapter code for my rc2014 but the keyboard encoding is really being done by an Arduino Nano.

 

[durgadas311]

Of course, the Ctrl+Letter keys (depending upon where the conversion is actually done) translates into codes in the range 01-1F. 00 being Ctrl+@ (generally).

Dave

Correct, I was assuming a certain level of historical knowledge. Modern keyboards throw a wrench into that, since "Ctrl" is now a first-class citizen of the meta keys. The original computer keyboard (sic. ASR-33 teletype) did not even allow you to press any other keys while holding "Ctrl" down - only A-Z, @, [, \, ], ^, _. All other keys were mechanically locked out.

 

[cj7hawk]

Two examples of this that I have experience with. The Heathkit H89, which has an embedded H19 terminal, has a numeric keypad that supports a couple different sets of codes (as well as a row of function keys). These keys send ESC sequences when pressed, and the exact ESC sequences depend on what mode the terminal has been placed in. So, certain applications will put the keypad in a special mode so that it can be used with that software. I'm not sure whether Wordstar is capable of decoding ESC sequences, so it may require that the BIOS conin routine do that, and then do something like return codes with the high bit set and then Wordstar (etc) are configured to recognize those 8-bit key codes.

The second example is from the Kaypro, which emulates an ADM 3A for the screen. The Kaypro keypad and cursor keys send a special 8-bit code when pressed, and the BIOS uses a translation table to convert those into ASM 3A cursor control codes and standard numeric codes for the numeric keypad. The BIOS translation table may be altered to translate those keys differently, thus allowing for alternate uses. If the translations return 8-bit codes, then the application(s) using them must be capable of handling 8-bit codes.

Basically, you have two choices for the special key codes, one is to return codes with the 8th bit set and the other is to return control codes (in the 01-1F range that are not otherwise used). There may be some applications out there that aggressively clear the 8th bit on input, so that option may not always work. Be aware that CP/M uses more than just Backspace (08) and CR/LF (0D/0A) for commandline input (BDOS function 10), but typically those functions are performed using the Ctrl+Letter keys on the keyboard.

Most of the ADM-3A codes have no collisions of consequence with anything else in the CCP ( they just enter new lines) and escape sequences aren't good for keyboard encoding so if Kaypro went with the same decision too, it seems as though it might be a good for me to keep with it as well. Not to mention anything specifically written for the Kaypro might work on my machine and use those keys.

I can install drivers to address things, but it's a big chunk of memory for what could be addressed, as you put it, with a 32 byte table (ouch!... Maybe a 20 byte table... Every byte counts) in CONIN and then maybe implement a batch style system so I can have the loader for a program load in any key translations which will check against a vector table and translate for each program that needs it. Seems an elegant enough solution. Also lets someone user-define things later and all I need to do is work out a good mapping beyond what the ADM-3A already has for the typical extra keys on a keyboard... Number pad can be sent as numeric or control codes. It doesn't matter if I send through an 8th bit as long as the BIOS recognizes it, so I have a little thinking to do yet about how I want to build the keyboard encoded - though at the moment, I figure I'll use RS232 as the protocol, since it's going into a console port anyway... and I can always put a switch on the keyboard so it can change modes as a backup solution, but would prefer to have it software settable.

I was originally thinking that the keypress would send the code for the key being pressed down, and send bit 8 when it was depressed, so that keys could be stateful a bit like the AT keyboard differences. I do need to include the capability for the keyboard to translate to a matrix like on the Osborne 1 so that the Spectrum can "scan" it via address lines and the data lines when in compatible mode. But some options seem to be mutually exclusive and two solutions is never a good solution if one can fit. Also, I didn't want to send data back to the keyboard since I wanted the keyboard port to be able to operate with a dumb terminal - ie, console is reflected to it.

Much to think about. Thank you for the thoughts - they are truly helpful.

David

 

[cj7hawk]

OK, so I installed a small translation table, added 80 to the control keys and sent them through... Then I test for 80, and if from 80 to 8F, I run them through a small translation table, so all I need is for something to adjust the translation table then run the program I need, a bit like a batch file... The cursor keys work really well then in WS and move around conveniently. I also changed out my cursor for an inverted block so it's easy to spot, and clear what character is beneath it.

By using codes above 80, I can drop them back to the ADM-3A codes by default, or if I translate them, it only translates the arrow key, and not the control character that represents the same ADM-3A code, and seems to work well under wordstar, and doesn't obliterate CtrlK which the ADM-3A uses.

I figure I can use codes above that for press/depress codes, and then just filter them out at the CONIN routine without too much work or code space.

I'm not sure how elegant this solution is, but it works well under Wordstar, should be changeable with each program and I can write some small executables ( or a single one with options, since I might as well use up the entire allocation ) to change the translation then launch the desired program... Then on exit, it resets back to the ADM-3A default.

Thanks again for the input -
David