Custom keyboard codepage for DOS

[RickNel]

I've hooked the switch matrix of an old ANSI serial terminal up to an Intel PS/2 keyboard controller, and need to make custom translations from the resulting scancodes to standard PS/2 ANSI input. Its for a terminal simulation project I described in the "Other" genre, which may not be frequented by many programmers.

I know about ANSI.SYS translate commands, but it seems kind of brute-force to run a separate boot-time command for each individual key combo, so I'm looking for advice on how to create a non-standard codepage that can be loaded with one command at boot. If a custom codepage handles the one-for-one key combo translations, I can use ANSI.SYS for the ansi escape sequences on the various special function keys.

If there is no "official" way to customize a codepage, I suppose I could consider hacking into one of the standard codepages with a debugger and making 100+ changes - though that does not appeal. I can work with Assembler if necessary, but would prefer an application-level customizing tool if such a thing should exist.

Any advice welcome..

Rick

 

[patscc]

A TSR ?
patscc

 

[Ole Juul]

I described in the "Other" genre, which may not be frequented by many programmers.

It's all the same forum and all posts are equally visible in the list. It doesn't matter where you post in that regard.

I know about ANSI.SYS translate commands, but it seems kind of brute-force to run a separate boot-time command for each individual key combo,

You're probably way above me on this since I'm not a programmer, but that statement doesn't make any sense to me. It takes DOS a split second to read a file and "brute force" doesn't exactly come to mind when it comes to writing ANSI escape sequences. Here is a quick example of what a whole remapping looks like. A few minutes typing if you have a block/cut/write function on your editor. I put it here for you. Put "call keyplus" in your autoexec.bat to automate the process. Like I say, I'm not a programmer so this is probably way too simple and I'm missing the point. Sorry, if that's the case.

PS: I see that minitelnet (Mark Morley) uses a similar system. Perhaps check that out.

 

[RickNel]

Well thanks OJ for that example - though (being typed I guess in a Linux file) it showed up in Notepad with some character substitutions. Irony?

My case will be a little more complicated as my originating keyboard is generating some scancodes that, via the keyboard control chip, do not deliver standard ASCII codes for the first byte of the pair. I'll need to use hex.

I remembered to check out Simtel and have found an old DOS utility, ScanCode Show, to display raw scancodes untranslated as delivered via Int16, so that will help me build the necessary table. That can't be finished till I repair all the tracks broken by decayed de-bounce capacitors. So far, at least I have verified that a valid (though incorrect) character can be displayed and autotyped, so the hardware connection works in principle.

The other complication is I may need to translate shift and control versions of each keycode, as they will be used not only for display characters but for program control through the terminal - eg WordStar's ^K, ^W etc etc. I won't need to worry about Alt, thankfully.

I've found on Simtel a program called keyswp12 which includes a translation table editor and a TSR to run custom tables. I'm sure ansi.sys will work, but I'll try both so see which best fits the purpose.

BTW I did not mean to suggest that contributors to the "Other" forum were brutes, nor that programmers were a higher species (I am a rank amateur)

Rick

 

[Maverick1978]

Well thanks OJ for that example - though (being typed I guess in a Linux file) it showed up in Notepad with some character substitutions. Irony?

Use Notepad++

You can thank me later

 

[Ole Juul]

Well thanks OJ for that example - though (being typed I guess in a Linux file) it showed up in Notepad with some character substitutions. Irony?

Actually I use DOS for most writing. I strongly recommend it. Linux is not very compatible with DOS and I don't think MS-Windows is either - as I guess you just found out.

I've found on Simtel a program called keyswp12 which includes a translation table editor and a TSR to run custom tables. I'm sure ansi.sys will work, but I'll try both so see which best fits the purpose.

Isn't Simtel great. That's where the real OS actually resides.

 

[MikeS]

Wouldn't it be simpler in the long run to just rewire the keyboard matrix? I've done a few of those in my time...

I also use several commercial programmable matrix > PS/2 encoders, but they're not cheap and the ones I use only go up to 12x12.

 

[RickNel]

Wouldn't it be simpler in the long run to just rewire the keyboard matrix?

One of my aims is to leave any original vintage component as intact as possible - so minimise hardware hacks on the terminal keyboard itself. Another aim is do as little soldering as possible. Taking both aims, it seemed simpler for me to use the existing 24-pin header on the terminal keyboard and just solder up a 24-line straight-through adapter with a 24-pin header plug on the keyboard end, other end soldered to the row/column address fingers of the edge connector on a salvaged PS/2 keyboard control unit. A DOS system sees a PS/2 keyboard and reads the scancodes agnostically.

I thought about rewiring the switch matrix on the keyboard, but it seemed to involve much greater complexity. There is no correlation with PS/2 keyboard row/column pairs, and most of the Shift/Key combinations were mapped differently. So the only viable approach seemed to be to just secure 8/16 scannability and re-map in software.

In any case I need software mapping from about a dozen specific function keys to ANSI escape sequences emulating the serial terminal functions.

Mike, I'm curious - how many new connections have you needed to make for a full switch matrix re-wire from a pre-AT keyboard to a PS/2 controller? I guessed around 200?

Rick

 

[MikeS]

I understand about keeping the keyboard original, even if it is the only original piece left in there ;-)
I just think you're going to run into trouble with the multiple keys (shift, CTL, etc.).

I'll be interested to see if you can do it just using (x)ANSI.sys as OJ suggests; that'd be the easiest way for sure.

I guess worst case it'd take twice as many connections as there are keys; pretty quick with a wiring pencil.

Some pictures below of a couple of keyboards I modified years ago that are still kicking around; one I encoded myself using diodes (not quite the same as what you want to do) and the other with a custom wired matrix.

Here's what I use these days:
http://www.hagstromelectronics.com/products/ke24.html

There's also Jim Brain's C=key interface, although I'm not sure what its current status is:
http://www.go4retro.com/products/ckey/

 

[RickNel]

I just think you're going to run into trouble with the multiple keys (shift, CTL, etc.).

Yes, it wll depend on whether the controller will translate non-PS/2 row/column combinations into scancodes that can be re-mapped in software. The datasheet on the controller does not indicate how much intelligence is applied to scanned key combos - I'm hoping it is dumb enough to pass everything through for software handling.

Your re-wire example seems to be on a keyboard where the key contacts are separate from the matrix circuit. On the Soroc, the keys are soldered onto the PCB with the matrix circuit, so I would have to cut almost all traces at all points to eliminate the original circuit before attaching new wires.

I have to complete repairs on some corroded traces and caps before I can verify exactly what signals the controller is generating from the scanned key combinations.

The separate controller units you mention are beyond my scope, I think, though interesting to consider.

Rick

 

[MikeS]

It was a long time ago, but as I recall I started out trying to use existing traces and cutting the rest, and finally decided it would be quicker and easier to just remove the pcb altogether.

With your keyboard you would have to cut the traces; quick work with a Dremel tool but yes, a software solution would certainly be preferable even if you have to rewire two or three keys.

Good luck!

 

[RickNel]

Mike - you are right (AGAIN ).

I verified the keyboard hardware, fixed some corroded traces with circuit pen. Had to improvise a new contact switch for the space bar - the corrosive gel leaked by the original CRT had eaten one contact away completely. Then I hooked up the keyboard code- displaying utility and fired up with the keyboard plugged into the PS/2 port of a laptop, so I had both keyboards connected. The displayed codes bore no discernible relation to the row/column positions and many keys generated no displayed code at all.

With more research I discovered why. Intel has expunged all reference to the 83C51KB controller from its online resources. The available hardware datasheet says nothing about firmware, but identifies a 4K ROM space in the controller chip.

After various keyword combinations, Google eventually found a very old Intel forum reply from an Intel "support" person telling another guy why he could not do what I want to do. PC PS/2 keyboard input drivers do not derive the scancodes from row/column addresses. They derive them from a single-value "Key location" code (a Microsoft standard, apparently), which is generated inside the keyboard controller chip from row/column addresses. There is no standard correlation between addresses and "key location" numbers. Each keyboard OEM created its own table to suit any variations in key functions, address matrices, or other design considerations. These proprietary tables were burned into the 83C51KB ROM as part of the OEM's wholesale order (min 2000). To reverse-engineer such a table seems more trouble than re-wiring the key matrix to match the known key locations of the keyboard from which the controller is lifted (in my case, a Honeywell). The controller chip performs many other useful functions that would be a pain to replicate in a generic microcontroller.

So I've started re-mapping, by colour-coding each bus point and labelling the key locations(see picture).



On some test connections, I've found that transformer winding wire is ideal for tacking between existing solder points on the switches, with a taste of fresh solder to re-flow. It's compact, conducts little heat away from the joint, and the insulation burns off automatically as I solder. I get good connections without any bulky melting plastic or manual stripping.

Only about 200 solder points and 200 trace cuts to go - just as well I'm not in a hurry.

After I get a full set of "key locations" reported to the OS, I'll still need to remap function keys and non-alphabetic keys using either ansi.sys or keyswp12.

Rick