Author
Topic: Truly-Ergonomicís keycodes remapping (Read 71698 times)

Thanks to the recent opportunity to update the firmware of the Truly-Ergonomic keyboard, we can now begin to make personal remappings.

In the 209 firmware, I noticed that there is two tables of internal keycodes. These two tables are visible, for example, at the end of the TrulyErgonomic_209_v2.121127.hex file.Keycodes from address 05AE to address 063D are used when DIP swith #2 is ON (Windows / Linux).Keycodes from address 063E to address 06CD are used when DIP swith #2 is OFF (Mac OS).

I tried to change some Keycodes (Backspace to home raw (instead of Tab), Enter up (instead of Backspace), CTRL in the middle (instead of Enter), and some others) and it works fine ! Great ! (I only needed a simple formula in OpenOffice.org-Calc to recalculate the checksum-byte of each changed firmwareís HEX file linesÖ)

This can make us to quietly wait for the arrival of the Truly-Ergonomicís programing softwareÖ

For exemple, if you want the Right-Ctrl to become a Return key, you search for the Right-Ctrl and Return keycode in the HID doc (these codes are E4 and 28). Then your search for the E4 code in the Truly-Ergonomic keycodes (keycodes have white background in my OpenOffice.org file) and you put '28' instead of the original 'E4' code. The new checksum is then calculated for the modified line. When all your changes are done, you copy-paste the complete lines (with the new checksum) in the Truly-Ergonomic HEX file, over the original lines. Then, you can update the Truly-Ergonomic firmware using your personal HEX fileÖ

Be very carefull to NOT change any other line of the firmware HEX file BUT ONLY the 18 lines of keycodes !!!And DO NOT change the nine first characters of each keycodesíline !

Well ****.I was trying to get the lower left and right international keys to work as control keys.First attempt failed, but everything else worked.Second attempt bricked the keyboard.Shows up as unknown device and the firmware tool does nothing.

Any suggestions before I try to get this thing RMAed with TE?

Update:Wow. Did a diff on the original firmware. Managed to delete 10 random lines from the file. Yay accidental VIM key mash apparently.

Well ****.I was trying to get the lower left and right international keys to work as control keys.First attempt failed, but everything else worked.Second attempt bricked the keyboard.Shows up as unknown device and the firmware tool does nothing.

Any suggestions before I try to get this thing RMAed with TE?

Update:Wow. Did a diff on the original firmware. Managed to delete 10 random lines from the file. Yay accidental VIM key mash apparently.

It's time consuming but not that hard. My error was just brain fart stupid.

I've confirmed that both SPI and basic serial interfaces are not wired into anything. This most likely means that I need someone with surface mount soldering gear to wire in a 2 wire interface so I can re-program this thing.

I saw in the Megawin SDK doc that if the chip is Reset (RST-pin high) while the power is NOT interrupted, then it may restart in ISP mode (In System Programming) if the default Megawin ISP program is used in the chip's ISP memory. There is a (little) chance that Truly-Ergonomic used the default ISP program... MAY BE, it could be the way to by-pass the erroneous firmware and to be able to reflash a correct Firmware. I don't know....

I saw in the Megawin SDK doc that if the chip is Reset (RST-pin high) while the power is NOT interrupted, then it may restart in ISP mode (In System Programming) if the default Megawin ISP program is used in the chip's ISP memory. There is a (little) chance that Truly-Ergonomic used the default ISP program... MAY BE, it could be the way to by-pass the erroneous firmware and to be able to reflash a correct Firmware. I don't know....

Actually there is a very good chance. Their DFU programming software is the same as the one supplied in the SDK ,except with their logo slapped onto it. I'll try this out now. Thanks.

I saw in the Megawin SDK doc that if the chip is Reset (RST-pin high) while the power is NOT interrupted, then it may restart in ISP mode (In System Programming) if the default Megawin ISP program is used in the chip's ISP memory. There is a (little) chance that Truly-Ergonomic used the default ISP program... MAY BE, it could be the way to by-pass the erroneous firmware and to be able to reflash a correct Firmware. I don't know....

So now that I've resurrected my keyboard, on to re-programming this thing.So I'm assuming that the bottom left and right international keys are 87 and 88. The thing is, those codes show up twice in the firmware.

Wow! You managed to inter-connect pins of such a microscopic thing !!!! Very good job

I have no idea why there is two 87 and 88 codes in the Windows/Linux keycodes...I suppose that the lower right and left buttons correspond to the keycode's positions that already have Ctrl codes (E0 E4) at the same position in the MacOS keycodes (because TE doc say that extrem left and right lower keys are Ctrl keys when DIP switch #2 is Off).

I have no idea why there is two 87 and 88 codes in the Windows/Linux keycodes...I suppose that the lower right and left buttons correspond to the keycode's positions that already have Ctrl codes (E0 E4) at the same position in the MacOS keycodes (because TE doc say that extrem left and right lower keys are Ctrl keys when DIP switch #2 is Off).

Will play around with this later. I ran out of steam last night. Not going to try this again at work either!

Or provided the most basic leads for a two wire interface which is standard on a lot of electronics with firmware. Almost every router I've ever used has a two wire interface just beneath one of the ethernet jacks so you can salvage a bad flash.

Here is the firmware file I ended up with: TrulyErgonomic_209_mod.hex (18.25 kB - downloaded 150 times.)Left Shift -> TabRight Shift -> EnterLeft Control -> Left ShiftRight Control -> Right ShiftLeft International -> Left ControlRight International -> Right Control

So in other words ... TE just took the basic firmware provided and slapped their logo into it. Why am I not surprised.

Not at all.TE took the basic firmware remapping software and just slapped their logo on it.The firmware itself is mostly custom. The SDK provides a default firmware, but that is for basic IO. The chip inside the board is a generic programmable IC. The HID implementation is all theirs, hence why the problems with the keyboard.

I've been talking to others more knowledgeable about HID implementations on #geekhack and will be taking a crack at my own implementation for firmware now that I know where to go. No promises on where I'll get and how fast I'll get there.

I just did this with a 104 model and it worked perfectly. Since I never intend to use it with a Mac, I set the first set of 9 lines to Colemak layout and the second set of 9 lines to QWERTY layout. By flipping DIP switch #2 I can go between the two layouts now.

if my capslock key acts a delete key can I do something to turn it back into a capslock key? I think that's what Tracer is doing with the chips but I am not sure.

And what about the AppsKey? Is that the 5D on the last row of Windows/Linux keycodes?

Thanks a lot for any response. All of this is like ancient hyrulian to me but it's starting to make sense. Davkol mentioned Arduino in another thread and I've been looking that up and suddenly chips don't seem that scary anymore.

Huzzah! I just remapped my TECK 207 firmware! Thanks so much for this guide and the checksum spreadsheet, addwyn.

FWIW, I moved the {[ and ]} keys to the opposite (left) end of their row, put '" and \| at the right end where [{ ]} used to be, and moved /? down where '" used to be. This puts /? and \| in their standard QWERTY locations, and '" is now only one key away (one row up) from standard. I also swapped Tab and Backspace, so now Backspace is adjacent to Delete (where I kept expecting it to be), and I expect this will help reduce inadvertent Tab strikes as well. I've attached my modified .hex file here in case anyone with a model 207 wants to try this remap.

So... I finally decided to try flashing the new firmware update to my 109 and experimenting with hacking the hex files. I'm extremely happy with the results. It didn't take long to figure out which keys went where, and I was pleased to note that things like the left spacebar were easily remappable. Thanks, guys!

Hardware remapping massively increases the value of the TECK in my eyes, as I can finally take my keyboard around and just plug it in to any workstation with no fuss. (After using it for a year with a non-standard key configuration, the default mappings are unacceptable.) As an added bonus, reassigning keys in hardware solved a problem I was having with certain games ignoring scancode maps in the Windows registry.

I'm curious to know where the NumLock layer lives. There's a section of the main keymap that looks like it should deal with that, but editing it doesn't seem to do anything.

One interesting (and rather annoying) feature that I discovered is that the behaviour of the Fn layer is partially based on the key assignments rather than the physical keys, at least with respect to the keys to the left and right of Fn. On my 109, those are Windows and PrintScreen, for instance. Changing the mapping of either key prevents them from being used to access their function layer (CapsLock and NumLock respectively). However, installing a new Windows or PrintScreen key elsewhere will mean that Fn-(new key) accesses CapsLock or NumLock. That doesn't seem to be the case for the function row Fn layer, though. Comparing the 109 and 209 versions offers hints as to which portions of the firmware might control some of this behaviour, but they're pretty deep in the executable segments. I wouldn't want to risk fiddling with that without taking a lot more time to figure out the disassembled code...

I have done it! Finally my Truly Keyboard works like it should. And finally the keys are always the same (the modifiers), no matter which user is using the computer. That makes it a lot of easier. I did quite a lot of changes. Some cyclic changes, modifiers to my preferred positions and some specifics for the keyboard layout I am using (Neo 2).

Is somebody already writting a web gui which creates a hex file to download? Not that I need it, but it would be easier for others. Nobody wants to wait for the company any more.

I located the position of numpad management (Keycodes conversion when Num-Lock is ON) in the TrulyErgonomic_209_v2.121127.hex file.This is not a table but a piece of code ! For each key involved in the numpad, there is a keycode allowing to identify the initial key and, a little further, the keycode that is to be returned for this key when Num-Lock is ONÖThis piece of code is located between address 084B and 08EC (I saw thatís the same in the TrulyErgonomic_207_v2.121127.hex file. I have not looked into the other firmware files) :

For exemple, if you changed the layout of your TE keyboard to COLEMAK, the Keypad-1 should be on the [N] key (instead of the [J] key). Therefore you sould override the [J]ís keycode (red framed "0D") by the [N]ís keycode ("11"). As a result, your TE keyboard will send a [Keypad 1] to the host when the [N] key is typed while Num-Lock is ON (and not when the [J] key is typed)

Be very careful ! As this is a piece of code, DO NOT modify ANY OTHER VALUE except the keycodes (I framed by red or green in this picture) and the lines' checksum bytes (the two digits at the end of each line) !

Be very careful ! As this is a piece of code, DO NOT modify ANY OTHER VALUE except the keycodes (I framed by red or green in this picture) and the lines' checksum bytes (the two digits at the end of each line) !

Thank you addwyn. That makes the keyboard even better, because I can remap the numpad like it is in the Neo2 layout.

Am I right if I assume that I have to calculate the checksum in the same way as for the keyremapping in your spreadsheet?

And where did you find the algorithm for the checksum? Is this a standard documented for the Megawin chips?

I am asking this, because I want to also edit the keycodes of the Fn keys.

And I want to, as I have had it before with a Xmodmap file, add XF86Forward and XF86Backward to the to lower right keys of the keyboard, as all the Thinkpad keyboards have it. But as USB HID ID number this is (WWW Forward) \x0225 and (WWW Back) \x0224 which is to big to fit in the 16 bit space for one key.

Besides the main keymap tables that we know about, I've been able to find three other data tables.

One is right at the beginning of the hex file and lives in x10CC-x1159 (109) or x10DC-x1169 (209). It's identical in both versions, and mostly seems to contain data used by functions responsible for the USB I/O.

The second one lives at x1627-x165F (109) or x1637-x166F (209) and is used by the external interrupt handler to manage port I/O. Don't touch it.

The last one lives at x0CC5-x0D9E (109 version) or x0CD5-x0DAE (209 version), and is slightly different between models. Among other things, it contains the HID codes for the Fn-(F key) layer.

Note that these are all HID Usage Page 0C codes, not the Page 07 codes that the normal keyboard keys use. I'd only recommend substitutions with other media HID keycodes of similar size.

0195 (network browser) and 01AE (keyboard layout) are formatted to look like they might do something, but any keys that might be associated with these are hard coded to do something else in the main function in the main function. Interestingly, the Calculator entry is also included with the 109 firmware even though Fn-F5 is hard coded to act as Insert.

Fn-Escape and the keys to the left, right, and below the Fn key are hard coded in a big, sprawling function (which starts at x007e in all versions of the firmware), as are the Fn-5 and Fn-6 combinations and a bunch of DIP switch related stuff. You guys already found the function that handles the NumLock layer (which starts at x07AF in my 109 firmware and 0x07EB in the 209 one).

I've thus far been unable to figure out which functions are responsible for that F key function layer. There are several that access those data blocks, but with my rather limited experience in programming such devices, their behaviour is not as obvious as the other keymapping routines in the firmware.

And where did you find the algorithm for the checksum? Is this a standard documented for the Megawin chips?

I am asking this, because I want to also edit the keycodes of the Fn keys.

The hex files are a standard format. The Megawin CPU in the TECK is basically just an 8051 processor with some extra stuff like USB support built in. Most 8051 IDEs will have tools to disassemble and analyze the hex files.

Then it's just a matter of figuring out where the data lives, since disassemblers have no practical way of telling the difference between code and data. Sometimes it's obvious. For instance, the data block right at the top of the hex files is mostly plaintext device information. (You can read "Truly Ergonomic Computer Keyboard" and other USB device info there.) Comparing the firmwares of two models with known differences is a good starting point for where to look.

Anyways... after a few days of trying to make sense of the firmware, I decided to be a little more adventurous. For my first baby steps into hacking the code, I set up my keyboard to toggle between the Windows and Mac code pages based on Scroll Lock instead of the DIP switch. My TECK now has two full layers complete with a convenient LED to tell me which one I'm using. It's just a few bytes changed, but my keyboard is now so much more awesome than before!

Anyways... after a few days of trying to make sense of the firmware, I decided to be a little more adventurous. For my first baby steps into hacking the code, I set up my keyboard to toggle between the Windows and Mac code pages based on Scroll Lock instead of the DIP switch. My TECK now has two full layers complete with a convenient LED to tell me which one I'm using. It's just a few bytes changed, but my keyboard is now so much more awesome than before!

[/quote]

Could you tell us how you did it?

I am asking because Iím looking for a possibility to add at least one (better two) switchable additional Layers to the keyboard, so Iíd be independent of any drivers. I am running a german Neo-derivate Layout, I need three layers at least. So what you did there sounds really interesting.

My hex files no longer resemble the originals since everything's in a different order now. But if you really really want to play with it...

There are two places where the firmware decides which layout to use.

In the 109 firmware, this occurs at locations x07DF and x0901.In the 209 firmware, it occurs at locations x081B and x0C2D.

The instruction in question reads 30 E9 07, which is an 8051 opcode for "Jump 7 bytes if the Port 4.1 (DIP Switch #2) bit is clear". The string only occurs at the two points in question, so you can simply search for it rather than hunting for the address.

Because the Caps/Num/Scroll locks are implemented with a pin controlling their LEDs, it's actually a fairly simple matter of changing the bit you're checking.

I recommend using Scroll Lock, as that won't mess up anything else. (Seriously... who uses Scroll Lock for anything these days?) As noted earlier in this thread, the NumLock keypad is hard coded into the key processing function, and disabling that would require significantly more surgery on the code.

Note that the bits in question are high when the lock in question is toggled off and low when it's on. (It's the reverse case for the DIP switches; a bit set to 1 means "on" as expected.) Also note that the "off" position of the DIP switch defaults to the Mac keyboard layout. If you want the Windows layout to be the default, change the jump instruction from 30 (JNB) to 20 (JB).

So my version reads 20 B7 07 (Jump 7 bytes if Scroll Lock is off).

Obviously, you'd have to redo checksums and stuff as usual.

I would also recommend adding Scroll Lock (47 hex) to a conveniently accessible button on both layouts, as by default it's only available via Fn-(top middle key).

Adding a third layer for NumLock is a non-trivial change that requires completely rewriting several of the key processing functions. It actually doesn't look like it would be super difficult to do, but at that point it's way beyond simple hex file hacking. Unfortunately, implementing temporary modifier access to a layer (e.g. with the Fn key or perhaps some other private internal keycode for a layer modifier) would probably be a lot of work, as it requires changing major aspects of how the keyboard operates.

WARNING: Modifying the executable portions of your firmware is a potentially brickable offence! Hack the code at your own risk!

I recommend using Scroll Lock, as that won't mess up anything else. (Seriously... who uses Scroll Lock for anything these days?) As noted earlier in this thread, the NumLock keypad is hard coded into the key processing function, and disabling that would require significantly more surgery on the code.

Note that the bits in question are high when the lock in question is toggled off and low when it's on. (It's the reverse case for the DIP switches; a bit set to 1 means "on" as expected.) Also note that the "off" position of the DIP switch defaults to the Mac keyboard layout. If you want the Windows layout to be the default, change the jump instruction from 30 (JNB) to 20 (JB).

So my version reads 20 B7 07 (Jump 7 bytes if Scroll Lock is off).

Does this mean I have to change both occurences of this piece of code or do I have to decide which one to change? or must I keep it in one layer in the original form (30 B9 07) and the other to jump back as (20 B7 07)? I guess the latter is the case. I think I got it.

Adding a third layer for NumLock is a non-trivial change that requires completely rewriting several of the key processing functions. It actually doesn't look like it would be super difficult to do, but at that point it's way beyond simple hex file hacking. Unfortunately, implementing temporary modifier access to a layer (e.g. with the Fn key or perhaps some other private internal keycode for a layer modifier) would probably be a lot of work, as it requires changing major aspects of how the keyboard operates.

Thatís a clever proposal, thanks for hinting it out! I already figured that hacking the NumLock Layer wouldnít be a too good idea.What I want to do is having an extra layer for all special characters ?![]... as I am used to have it now. Since German has als this extra Umlaut characters this fills comfortably one layer of the TECK, so I need an easy accessible extra layer. Speeds up typing.Your detailed answer encourages to really try it. Thanks a stack.

I recommend using Scroll Lock, as that won't mess up anything else. (Seriously... who uses Scroll Lock for anything these days?) As noted earlier in this thread, the NumLock keypad is hard coded into the key processing function, and disabling that would require significantly more surgery on the code.

Note that the bits in question are high when the lock in question is toggled off and low when it's on. (It's the reverse case for the DIP switches; a bit set to 1 means "on" as expected.) Also note that the "off" position of the DIP switch defaults to the Mac keyboard layout. If you want the Windows layout to be the default, change the jump instruction from 30 (JNB) to 20 (JB).

So my version reads 20 B7 07 (Jump 7 bytes if Scroll Lock is off).

Does this mean I have to change both occurences of this piece of code or do I have to decide which one to change? or must I keep it in one layer in the original form (30 B9 07) and the other to jump back as (20 B7 07)? I guess the latter is the case. I think I got it.

Oh no...

In case I wasn't clear, you have to change both occurances to the same thing. (One is in a preprocessor function that sets up special internal keycodes for the Fn-F key layer, the other is the main keymap processor that adds keypresses to the output buffer.) Behaviour might be unpredictable if you only change one.

In case I wasn't clear, you have to change both occurances to the same thing. (One is in a preprocessor function that sets up special internal keycodes for the Fn-F key layer, the other is the main keymap processor that adds keypresses to the output buffer.) Behaviour might be unpredictable if you only change one.

FWIW, I moved the {[ and ]} keys to the opposite (left) end of their row, put '" and \| at the right end where [{ ]} used to be, and moved /? down where '" used to be. This puts /? and \| in their standard QWERTY locations, and '" is now only one key away (one row up) from standard. I also swapped Tab and Backspace, so now Backspace is adjacent to Delete (where I kept expecting it to be), and I expect this will help reduce inadvertent Tab strikes as well. I've attached my modified .hex file here in case anyone with a model 207 wants to try this remap. (Attachment Link)

So... I've become a bit more daring with regards to hacking my keyboard. Ultimately, I'd like to rewrite large chunks of the keymap handling system to be able to support multiple layers with modifiers.

I had a few successes with early experiments. Some of them soft bricked the keyboard to the point that none of the keys worked, but the USB handling remained intact, so reflashing the firmware fixed everything.

Eventually, I got a little bit too ambitious and decided to try moving the original data tables so I wouldn't have to worry about constantly editing their addresses. I guess I missed some references, because that instabricked the keyboard.

I was expecting to be able to just unscrew everything, open it up, short the CPU to reset in ISP mode, and be back on my way. Yeah... not so easy, it turns out.

Both sides of the case seem to be bolted together in the middle (which is unfortunately close to where the CPU is). I couldn't figure out how to release them. In the end, I had to more or less break the top off to get at the chip and reset it.

For those of you who've managed to get the case open... is there some trick to doing it? I'd rather not damage the poor keyboard any more than necessary...