4. After all screws are out, you need to 'horizontally-twist' the top-body against the bottom-body as there are 6 'hooks' that hold these two parts together; 4 hooks on the backside where the cable is located, and 1 hook on each side.

Ultimately, I'd like to rewrite large chunks of the keymap handling system to be able to support multiple layers with modifiers.

Hi Tezkat,Iím highly interested in your findings & and I hold all my thumbs for your final success!

Thanks to your experiments I have a working version with two layers now, one with qwert as base to work with my usual driver within my usual setup and another one by ScrollLock Switch and LED on with my personal basic Layout directly mapped to work on other computers without drivers. Thatís what I call a big step forward !!!

But still not satisfying. some programmable layers with modifiers would be really cool, but it would also include to map keys according to their Shift or AltGr states, that would be perfect.

A long way to go still I guess, good luck, and donít kill your Teck prematurely!

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...

Two of the screws holding the keyboard together are underneath the sticker. Feel with your finger until you find them.

Ah... thanks so much. I figured it would be something like that, but the back sticker didn't look like it was removable. I guess it isn't actually supposed to be.

Anyways... I've ordered a second TECK so that I'll be free to use my old, now slightly beat up and very no longer under warranty keyboard as a development guinea pig. I did say earlier that the lack of programmability was the only thing really holding me back from buying more. I guess they delivered on that after all... just not the way they intended.

But still not satisfying. some programmable layers with modifiers would be really cool, but it would also include to map keys according to their Shift or AltGr states, that would be perfect.

I'm afraid this is not the responsibility of the keyboard.

Indeed, in the HID protocol, the keyboard transmits only the status of the modifiers'keys and the codes of the pressed keys. With HID, the keyboard does not transmit ASCII characters. The combination of a key with an ASCII character is purely the responsibility of the OS (this is why, during its installation, the OS ask for the country / layout of the keyboard).By looking at the list of the HID keycodes, it is clear that, for example, there is no different codes for '?' or '/' but only one code for both combined (code 0x38 for the [/?] key). So, the keyboard's fimware can not separate them !

One solution would be to make the firmware to interpret itself the status of the modifiers and then to simulate a Alt sequence like, for example: [Alt] pressed + [Numpad 6] pressed + [Numpad 6] released + [Numpad 3] pressed + [Numpad 3] released + [Alt] released, to make the OS interpret a '?' ASCII character... But this is another matter !

But still not satisfying. some programmable layers with modifiers would be really cool, but it would also include to map keys according to their Shift or AltGr states, that would be perfect.

I'm afraid this is not the responsibility of the keyboard.

Indeed, in the HID protocol, the keyboard transmits only the status of the modifiers'keys and the codes of the pressed keys. With HID, the keyboard does not transmit ASCII characters. The combination of a key with an ASCII character is purely the responsibility of the OS (this is why, during its installation, the OS ask for the country / layout of the keyboard).By looking at the list of the HID keycodes, it is clear that, for example, there is no different codes for '?' or '/' but only one code for both combined (code 0x38 for the [/?] key). So, the keyboard's fimware can not separate them !

One solution would be to make the firmware to interpret itself the status of the modifiers and then to simulate a Alt sequence like, for example: [Alt] pressed + [Numpad 6] pressed + [Numpad 6] released + [Numpad 3] pressed + [Numpad 3] released + [Alt] released, to make the OS interpret a '?' ASCII character... But this is another matter !

Exactly, you say it. But that would be what I'd call true programmability. In fact it is what the Ergodox-group and others have achieved for the Teensy++ controller. My dream is, to arrive at that kind of programmability for that Megawin Controller too, for I really like that keyboard and dont want to build one myself. I don't know too much about neither programming USB-Devices nor hacking machine code, so maybe that idea is absurd and out of reach. I am just trying to dream it up. What would it take, besides a profound understanding of how the controller is programmed?

I'd have to look at sample source code of how other keyboard designers achieved it (wasn't included in the ergodox firmware last time I looked), but I'd expect that sending an Alt-Numpad sequence--or any sequential macro in general--would be a relatively complex bit of programming requiring a rewrite of not just the keymapping but the timer controls and keyboard I/O. That's well beyond the scope of what I had planned to do.

On the other hand, it shouldn't be particularly difficult to add modifier info to a layer map (e.g. press Fn-F1 and it sends Ctrl-C). Note, however, that that could potentially cause unexpected behaviour when two keys with different modifiers are pressed quickly enough to register as simultaneous (or when actual modifier keys have also been pressed). Although the USB HID spec lists codes for the basic modifier keys (left and right Shift, Ctrl, Alt, and "GUI"--which refers to the Windows/Option/Meta keys), these are only used internally by the keyboard and not sent to the PC. That info is instead sent as an 8-bit array that reports which modifiers are currently in use.

For the record, there is actually an example of this type of remap in the default TECK firmware: Fn-6 remaps to Ctrl-Break, overriding whatever other modifiers you have pressed at the time.

I'd have to look at sample source code of how other keyboard designers achieved it (wasn't included in the ergodox firmware last time I looked), but I'd expect that sending an Alt-Numpad sequence--or any sequential macro in general--would be a relatively complex bit of programming requiring a rewrite of not just the keymapping but the timer controls and keyboard I/O. That's well beyond the scope of what I had planned to do.

As far as I understand, it is probably not precisely the same thing as it is more about PS2 signals to USB via different controllers but maybe it helps some. All at least implement layer structures to organize keycodes.

For the record, there is actually an example of this type of remap in the default TECK firmware: Fn-6 remaps to Ctrl-Break, overriding whatever other modifiers you have pressed at the time.

Yes, TE refers to it since recently on their homepage: ĽPause/BreakPressing Fn 5% is equivalent as Windows key Pause which in turn opens "Windows System Properties".Pressing Fn 6^ is equivalent as Ctrl Break.ę

Also they deleted any hints of their intention to release any kind of reprogramming software, I think this project of TE is definitely dead now.

On the other hand, it shouldn't be particularly difficult to add modifier info to a layer map (e.g. press Fn-F1 and it sends Ctrl-C).[...]For the record, there is actually an example of this type of remap in the default TECK firmware: Fn-6 remaps to Ctrl-Break, overriding whatever other modifiers you have pressed at the time.

I agree. I don't know if we can really talk about remapping in this case but perhaps, instead, about adding some layers (eg: Alt-Space send Tab) or about customising functions (eg: FN-LeftArrow send BrowserBack)... Indeed, this kind of "programmability" could be done without too much difficulty (but still a bit of work!).

I agree. I don't know if we can really talk about remapping in this case but perhaps, instead, about adding some layers (eg: Alt-Space send Tab) or about customising functions (eg: FN-LeftArrow send BrowserBack)... Indeed, this kind of "programmability" could be done without too much difficulty (but still a bit of work!).

Well, I am quite happy with what you and Tezkat have achieved till now, it's a major improvement for the usability of the TECK, so many thanks to both of you!Still I want to see the TECK becoming one day fully programmable as mentioned before, so I'll gladly go for anything you or anybody else hopefully will dig up about customizing it in the future.

I agree. I don't know if we can really talk about remapping in this case but perhaps, instead, about adding some layers (eg: Alt-Space send Tab) or about customising functions (eg: FN-LeftArrow send BrowserBack)... Indeed, this kind of "programmability" could be done without too much difficulty (but still a bit of work!).

Hmm... I personally don't believe that altering the behaviour of things like Alt-Space should ever be the responsibility of the keyboard firmware. It's doable, sure, but somewhat complicated and much better suited for OS-side customization.

Anyways, my new TECK has arrived, so the old one is in full lab rat mode. It's kinda slow going working with uncommented, unlabled assembly code when your only debugging platform is a keyboard you need to rip open to reset, but I'm gradually gutting and rewriting all of the original keymapping routines. So far, I've implemented rudimentary support for temporary modifier key access to layers (of the Fn-Something sends SomethingElse type). Next, I plan to build a four layer design with with built-in support for Ctrl/Shift/Alt/GUI pre-modified keys.

I still haven't quite figured out how the media page special function keys are implemented on the TECK. The important stuff is mostly handled by the USB interrupts rather than the keymappers, and I don't really know what else the associated data table is for, so support for things like custom browser control keys is still a long ways off.

but I'm gradually gutting and rewriting all of the original keymapping routines. So far, I've implemented rudimentary support for temporary modifier key access to layers (of the Fn-Something sends SomethingElse type). Next, I plan to build a four layer design with with built-in support for Ctrl/Shift/Alt/GUI pre-modified keys.

Wow, this sounds great! I'm looking forward to see that when you're done.

Only thing I figured out so far with my own clumsy experiments is, that the NumLock Key[53] cannot be mapped into that big keytable. It must reside somewhere else. Other keys (that don't even show up there, like Europe 1[32]) or ScrollLock and Break [48] can be placed and moved, with NumLock that does't work.

Only thing I figured out so far with my own clumsy experiments is, that the NumLock Key[53] cannot be mapped into that big keytable. It must reside somewhere else. Other keys (that don't even show up there, like Europe 1[32]) or ScrollLock and Break [48] can be placed and moved, with NumLock that does't work.

As of v2 of the firmware, the TECK uses a custom internal NumLock code (HID restricted code 0xEE) that isn't passed to the PC (or any other connected keyboards) and is only used to toggle the state of the NumLock on the TECK itself. As mentioned previously, all of that functionality is hardcoded into the keymappers instead of being sensibly implemented using layers.

As far as I know (though admittedly I failed to check last time I pulled out all my keycaps), there are only 3 LEDs on the TECK. Port 4.0 is however used internally by the firmware in a way very similar to the *Lock key indicators. I haven't yet taken the time to track it down, but it seems to have something to do with the keyboard being okay for input.

A big THANK YOU to the active geeks hacking this keyboard.I actually like the keyboard quite a lot. I think it should have got other keys under the thumbs but this is off-topic.

I'm an heavy user of autohotkey for many years and do a lot of things with it. The only problem with AutoHotkey is that it won't work with VMWarePlayer and the likes. Anyhow, with AutoHotkey, I created a kind of second layer that gives me a numpad under my right hand when with my left thumb, I press the Enter key.This is pretty cool as I don't have to move my hand to press the NumLock key. I could also add around my numpad symbols that I always use with numbers (like '.', '/', '\', ',', '-' and enter).

I found a really neat freeware that creates a second layer for your keyboard. This beauty is named TouchCursor found at http://touchcursor.sourceforge.net/I did set the activator to be the left spacebar but it can be any key (on my regular keyboard, I did set it to the spacebar).My layer activated by the left spacebar puts under my 2 hands all navigation stuffs and all characters usually reached by the Alt-Gr key (which I find difficult to reach on the TE):j leftk downl righti uph pgupn pgdnu homeo endm del; enters altd ctrlf shiftx ctrl-xc ctrl-cv ctrl-vz ctrl-za ctrl-a...and a few other.

The best thing is that it works even with VMWare.

I'm going to ask the author to allow more layout so I could have a second layout for the numpad and have it thumb activated.

I'll probably change slightly my TE firmware to remap a few keys and will be looking forward for all your discoveries.

I also think that making a soft that creates or modify the firmware would be really good for everyone but fully understand that people would be scared of developping this and risking to brick other's keyboard...

While I always appreciate a good hex hack I need to ask: why aren't you just remapping the keys on the OS side?

For instance I use the Programmer Dvorak layout (on Mac, Win and Linux) and I wanted to swap a couple keys, plus adding my own palette of Unicode symbols to AltGr combinations. It didn't take long. There are visual layout editors for Mac and Windows, and you can edit the config files by hand on Linux.

So why are you hacking the firmware in the first place? Are you trying to tell apart two keys that produce the same scancode? (didn't look like that, sorry if I missed it) Because apart from that, I can't see why any other change can't be done, better and safer, in the OS. Even if you needed to work with legacy apps or games that look at the raw scancodes, I'm positive there are drivers or even user-space utilities to remap them.

While I always appreciate a good hex hack I need to ask: why aren't you just remapping the keys on the OS side?

Sure there are many ways of making a keyboard do what you expect it to do.

When I am using a non-standard keyboard like the Truly Ergonomic with a non-standand layout and that keyboard is supposed to be fully progammable then Iíd prefer to program it once, so it works with my layout with the standard language settings for every OS on any machine I plug it in. Especially handy on systems where I donít have admin rights and am not allowed to install drivers or change configs.

I am using a highly optimized layout to work with the standard German language settings with thumbs shift and a third layer for all special characters. (http://www.adnw.de/index.php?n=Main.OptimierungF%C3%BCrDieGeradeTastaturMitDaumen-Shift) (Sorry, German only). With the above hex hack I get at least part of that, exept the special characters layer which I still have to provide by software solutions or modifications of the standard language settings. So I am still dreaming of getting full programmability as it can be achieved with the Teensy controller for example used in the Ergo Dox project. It could also be done with the Megawin controller used by the TE, but I lack the skills to do it. Truly Ergonomic was promising full programmability but never delivered so far. The hex hack is a big step in the right direction though, improving the general usability of the TECK.

While I always appreciate a good hex hack I need to ask: why aren't you just remapping the keys on the OS side?

I'd rather change the layout on the keyboard itself that way I can take the keyboard to various machines and have the layout I want, without needing to change anything on that machine's OS. I work with 4 different OSes on a regular basis, so changing layouts in the OS will be different for each OS. And there are machines that I can't change the OS, because I'm not the only one that work on them.

Also, I have found that layout changes in OS do not always make it across to other machines if I'm remoted into them, for various API reasons.

So, if you just want to have a Space on your left thumb and a Keyboard Lang 1 (Hangul/English) on your right thumb, I suggest that you edit the primary keycode table (see first post; the base addresses in v3/209 are 072B for PC and 07BB for Mac mode) to replace 2C with 90 and 65 with 2C, and leave DIP #3 alone (since you no longer have an App key, it will not have any effect).

However, if you think wasting a DIP switch is a waste or if you want to make your new behavior configurable, you can additionally replace 65s in the above code with 90s, so setting DIP #3 to ON will turn your Hangul key into an additional space.

I have been analyzing/hand-decompiling the v3/209 firmware, and what I have seen leads me to believe that this version nearly has macro programmability.

In the routine that handles new keypresses (the interesting part starts at 0322h), there is a call to a subroutine at 0B69h, which traverses a data structure assumed to be located at code/constants memory at address 2800h; but the stock firmware image does not have anything there. However, there is code that receives a 4K block over USB and flashes it at that address.

Studying the code at 0B69h (the routine that searches for a macro) and 043D (plays macro) reveals the layout of this block, which is roughly as follows.

At 2800h, we have a bit array of 20h bytes. A 0 in the bit N at address 2800+K indicates that the key with code N+8*K has macros. A 1 means to not bother looking for macros for this keycode.

At 2820h, there is a byte containing the number of macro bindings.

Immediately following at 2821h, macro bindings are located. Each binding is a 5-byte structure containing: the keycode, the modifiers bitmask (0x1 Ctrl, 0x2 Shift, 0x4 Alt; left and right not differentiated), a 2-byte absolute pointer to the macro body, and a byte-sized flag of unclear nature. Bindings with the same keycode (differing only by modifiers) must be stored contiguously.

Macro bodies also reside in the code/constants memory. The first byte is the number of events. Then, each event follows as a 10-byte structure: first 8 bytes of a HID report, then 2 bytes that specify in the low 12 bits the delay following this event, and the high 4 bytes are reserved for flags. The high bit flag specifies that after this event an empty HID report should be sent (all zeros, meaning release all keys).

Now for the sad part I said ďnearly hasĒ because of two things. Firstly, they arenít (yet?) distributing a macro programming application. Secondly, in the macro playing code, there seems to be a the firmware puts 8 bytes in the USB transmit queue, but then tells the hardware to transmit 9. I donít know what will happen in such conditions; the hardware might just freeze requiring a reset.

And, there are no traces of any on-the-fly macro programming. Meaning, it will be a standalone application, probably Windows. And since they are going the macro route, it seems that we geeks will have to resort to hex-hacking the firmware for basic key shuffling/relabeling.

However, you need to understand that the switch function is to conflate keys, not to differentiate them. The left thumb key is ďbornĒ with the App keycode, and the code above turns it into an additional Space.

So, if you just want to have a Space on your left thumb and a Keyboard Lang 1 (Hangul/English) on your right thumb, I suggest that you edit the primary keycode table (see first post; the base addresses in v3/209 are 072B for PC and 07BB for Mac mode) to replace 2C with 90 and 65 with 2C, and leave DIP #3 alone (since you no longer have an App key, it will not have any effect).

However, if you think wasting a DIP switch is a waste or if you want to make your new behavior configurable, you can additionally replace 65s in the above code with 90s, so setting DIP #3 to ON will turn your Hangul key into an additional space.

So, if you just want to have a Space on your left thumb and a Keyboard Lang 1 (Hangul/English) on your right thumb, I suggest that you edit the primary keycode table (see first post; the base addresses in v3/209 are 072B for PC and 07BB for Mac mode) to replace 2C with 90 and 65 with 2C, and leave DIP #3 alone (since you no longer have an App key, it will not have any effect).

This is exactly what I did with my Dvorak layout, to map backspace to the left spacebar.

Teaser: Iím doing a series of presumably low-risk code changes to the firmware. (Itís all untested yet, I will make the results available as a downloadable .hex file after I actually flash it and confirm that it works. If you apply any of the changes detailed here, flash at your own risk.)

First, you may have noticed that the set of media keys (those that are sent by Fn+F1ÖF12 and Fn+Del) is wider than actually supported by the stock firmware. There is the 0C.1AE usage (AL Keyboard Layout) before the main array of Home|Email|Ö|Vol+|Eject, and five more after: 0C.B7 Stop, 0C.196 AL Internet Browser, 01.82 System Sleep, 01.81 System Power Down, 01.83 System Wake Up.

I strongly consider the latter three keys harmful (as keyboard keys). Additionally, since they are in a different HID usage page (01 General Desktop, as opposed to media keys in 0C Consumer), supporting them requires a whopping 29 bytes in the HID report descriptor (the data structure that tells the USB host about the mapping between keycodes on the wire and standard HID usage codes). By dropping these, we can extend the 0C part of the report descriptor, in two meaningful ways. First, we can pad the one-byte usages (Fn+F7 through Fn+Del and the unused Stop) to full 2-byte width, making them more customizable; this takes up 8 of the available bytes. The remaining 21 bytes allow for 7 more media keys. (And, luckily, the firmware internally represents media keys as usages 07.E8 and above, for a total of 24; we hit the space limit just one short of that.)

For the adventurous, hereís the changed portion (against v3/209)::100D94000115012517750895010AAE010A23020AF7:100DA4008A010A21020A94010A92010A83010AB6FD:100DB400000ACD000AB5000AE2000AEA000AE900C6:100DC4000AB8000AB7000A96010A99010A85010ABD:100DD4009E010A9F010AA0010AB0010A91018160E3

The code that actually generates HID reports for these keys is the function at 0A76Ö0B68. On entry, it expects an internal code (0xE8Ö0xFA) at address 0x47. First it checks that the value is indeed in range; if not, writes 0x01 0x00 to addresses 0x48 0x49 and returns. Then there is a computed jump into a jump table that, depending on the value, transfers control into several little branches, all alike:

What changes is the values written into #48 and #49; they represent the indexes into the usage lists in the HID report descriptor. Here is the correspondence between the input value and this second byte of the report:

in #47

E8

E9

EA

Ö

F7

F8

F9

FA

other

out #48

01

01

01

Ö

01

02

02

02

01

out #49

01

02

03

Ö

10

10

11

12

00

Since we removed the 02 report (which dealt with power management keys) and extended the 01 report (media keys), we will need to generate out values of 01 01 for E8 up to 01 18 for FE; and the simplest way is to just set #49 to #47 minus 0xE7 (after checking that #47 is at least 0xE8).

We still donít have any way to actually send these added media keys, but weíve laid the groundwork. Additionally, we have saved 219 bytes of code space. We will put it to good use in a future hack.

Now, a bit of a public survey.

Have you noticed that pressing Fn affects keys you are holding down? E.g. hold down Caps Lock, press Fn; observe an Ins keypress is generated. (No, media keys donít behave this way; only Esc, Caps, Num, 5%, 6^, ❖ and International-4 if you donít turn it into a second Del with DIP #1.)

Does anyone actually press keys like this? I.e. is this a feature worth keeping? (If so, it actually mandates keycode-based Fn implementation rather than depending on physical key index.)

In todayís installment, we will deal with the numeric keypad (NumLock mode), making it more configurable and revisiting the ergonomics of the keypad placement.

The data flow is as follows. The keyboard matrix consists of 18 columns, with up to 8 keys in each, allowing for a theoretical maximum of 144 keys (of which TECK uses only 88). The physical key index is the column number multiplied by 8, plus the index of key in the column. Hereís the layout as I believe it to be. (It has remnants of the Megawin reference keyboard design in some positions, incl. keypad codes; these are not used anywhere in the TECK firmware unless the wiring is physically modified.)

Col00

Intl4 (Del)

Euro2 (ī®)

`~

Col01

Col02

A

2@

Tab

❖

1!

Q

Z

Col03

RBlank

Caps

Space

LCtrl

RCtrl

Col04

→

App

↑

Col05

LAlt

Num

RAlt

Col06

LShift

RShift

Col07

Fn

LBlank

Col08

Col09

W

F1

PgDn

F2

PgUp

Esc

X

S

Col10

F3

Del

F4

Col11

D

3#

E

8*

I

K

,<

C

Col12

G

4$

T

5%

R

F

B

V

Col13

J

6^

U

7&

Y

H

M

N

Col14

\|

F5

Enter

F6

=+

]}

⌫

←

Col15

[{

F7

-_

F8

9(

O

.>

L

Col16

'"

F9

↓

F10

0)

;:

P

/?

Col17

F11

End

F12

Home

Anyway, the key index (stored in data variable at #3B) is used with the PC and Mac keycode tables to yield a keycode (stored at #3C), which is then checked against 16 values, and if any matches, the corresponding keypad keycode is substituted instead. This all happens in the routine at 084BĖ095F.

The code that does the translation starts at 08AB and goes all the way through 094C, occupying 162 bytes. This gives me an ideaÖ

The code to take a key index from #3B, fetch a keycode from a table and store it into the adjacent variable #3C takes 9 bytes; I also add a zero-check so that one table fits both PC and Mac modes, for a total of 11. Then Iím left with 151 bytes of free code space which will nicely accommodate the num_keycodes table. Iíll need to LJMP over it:

Now letís see what this has gained us. Firstly, we are no longer keycode-dependent; we can remap both PC and Mac layouts and the numpad will stay its place. Secondly, we are not limited to 16 keys; if our heart so desires, we can add another keypad for the left hand, or add KP(, KP), KP=, and generally the whole block of keypad usage codes from B0 to DD. I wonít go into this, but I want to reconsider the placement.

The idea of embedded keypad comes from notebooks/laptops. Who was the first to come up with the idea that 7-8-9 stay in their usual place and other keypad keys are arranged around that I donít know; but this has carried over to Truly Ergonomic without an ergonomics review.

When you use the keypad on a conventional keyboard, the home row position is 4-5-6; KP5 even has a tactile bump on it. However, on TECK in stock configuration, the home row produces 1-2-3; 4-5-6 are entered from the top row; and to type 7-8-9, you have to reach into the digit row.

I therefore propose that the keypad be shifted one row down. While we are at it, also move KP- and KP+ from their intuitive but remote place in the top right corner to somewhere around the main grid.

Before

After

789 -+456/123*0 .

/*-789+4560123.

I have mixed feelings about the zero. If you are a left-spacer, you may want to put zero on the right space, as thatís where it is on the traditional keypad, under the right thumb. I myself am a right-spacer so I put zero on the remaining finger on the home row, as it is statistically the single most used digit.

Great work on the firmware hacking! I'm super-excited about these developments and looking forward to permanently swapping the Ctrl and Alt keys for good!

I just did a quick search for an Intel Hex Checksum checker to help make sure that people are getting the correct checksums at the end of the records that they modify, and came up with some good links:

The code to take a key index from #3B, fetch a keycode from a table and store it into the adjacent variable #3C takes 9 bytes; I also add a zero-check so that one table fits both PC and Mac modes, for a total of 11. Then Iím left with 151 bytes of free code space which will nicely accommodate the num_keycodes table.[Ö]Firstly, we are no longer keycode-dependent; we can remap both PC and Mac layouts and the numpad will stay its place. Secondly, we are not limited to 16 keys

Wow ! Thatís a great idea. Your code is concise effective and is giving much more flexibility than the original one. 151 bytes freed to store a 144 bytes num_keycodes table without modifying any other piece of firmware. Thatís cool !I think Iíll give it a try soonÖ

There are two perl scripts for checking Intel Hex files and one dissassembler program for creating 8051 Assembly from a hex file.

Yes, I actually started by using Dis51 to generate a listing file. (It has a quirk: when outputting in listing format (-l), it accepts both decimal and hex entry point values; but in plain disassembly, only decimal. And you do need to specify quite a few entry points, first for the interrupts, and then for each switch statement that happens to compile to a jump table. There are three of these, in the original v3/209.)

Plain disassembly proved to be nearly useless for modifications as, firstly, reassembly does not preserve the original .hex file section order nor even function addresses; and secondly, you just have to see the bytes of machine code if you want to fit in the original code size.

As for checksums, the spreadsheets in this topic and the Wikipedia article describe the algorithm just fine.

My workflow is: I have a master listing (obtained by disassembling the original .hex, annotated with the pseudo-C decompilation, with routine entry points renamed to sensible names and each variable briefly described at the top of file ó address, size, data type, tentative name, and a list of functions where assigned and/or read). I modify a copy of that listing, first in pseudo-C, then in assembly, then in machine code. Then I do a diff of the modified listing against the master, and hand-type the differing bytes into a spreadsheet not unlike those posted in this thread. In that spreadsheet, I have a column that concatenates the source columns and the generated checksum into a single string. By copying cells from that column, I can generate the whole .hex or a portion of it.

To verify that I donít screw up when reassembling, I check that the listing obtained by disassembling the modified .hex is equivalent to the listing with my modifications (up to renaming of the labels).

I am tempted to make the annotated master listing available somewhere for other geekhackers, but wonder what TrulyErgonomicís lawyers might think of that. (Not that I did anything that another person couldnít; but it did take me a couple weeksí worth of evenings.)

Also, is there anyone out here who succeeded (or definitely failed, for that matter) in flashing the keyboard under Linux (without dual-booting into Windows)?

I am in the works to replace the Fn key translation with a table-based lookup. (This way, I can move Fn to an easily accessible key and have a non-modal keypad (active when Fn is down, dismissed when I release Fn).) This has proved to be a not-so-low-risk hack, as I’m deleting lots of existing code, moving some code around, and otherwise messing with dangerous things :] Will report back when I get something working.

Meanwhile, a web-based keycode table editor. Assumes a sufficiently modern browser (current Firefox or Chrom{e|ium} should be OK), a font with decent Unicode coverage (for compact key labels) and a non-microscopic display (I’m fitting whole two keyboards there, after all).

What do you think are the chances to arrive at a modifier activated third layer for special characters? Or is this too far off yet?

This can be more easily achieved with your operating systemís facilities ó XKB on X.org/GNU/Linux, MSKLC on Windows, and I believe thereís some solution for Mac, too. They mostly hijack your right Alt (or Option on Mac, or a modifier key of your choice on X) to give you two more character layers (in addition to normal and shifted, you get AltGr+ and Shift+AltGr+ layers).

The only advantage of implementing this at firmware level that I can think of is that it might work everywhere you plug in your keyboard, without reconfiguration of the operating system (as long as it supports HID devices that report page 0x10 (Unicode) usages).

I generally donít lug my keyboard between computers I am not allowed to reconfigure, so this benefit does not appeal to me.

The only advantage of implementing this at firmware level that I can think of is that it might work everywhere you plug in your keyboard, without reconfiguration of the operating system (as long as it supports HID devices that report page 0x10 (Unicode) usages).

Yes, I did this with MSKLC for Window and it works fine, but having an so called ďprogrammableĒ keyboard it really would be nice to plug it into any machine and have my layout without fiddling with the standard Layout settings.

btw: found a little error in your layout editor: the key for L should produce HID-code 0F not 1F (if I remember it right)

Yes, I did this with MSKLC for Window and it works fine, but having an so called ďprogrammableĒ keyboard it really would be nice to plug it into any machine and have my layout without fiddling with the standard Layout settings.

Yes, but itís really complicated to do in firmware, and every time you want to tweak your layout, you will have to reflash the firmware. For me, the reboot into Windows is so disconcerting, I havenít yet even tested any of my changes I wrote about here.

Yes, Fn works for me. I just hit Fn+F8 (play/pause) and my music stopped playing. I donít care about Num Lock so I didnít even bind it. Iíve got a small external numpad on the right as I donít use a mouse (RollerMouse from Contour Design here).

I am in the works to replace the Fn key translation with a table-based lookup.

OK, I got it done, tentatively. Meaning, I flashed it, it does report keys pressed, the reports arenít complete and utter garbage, and it doesnít freeze after a few presses (All of the above happened during debugging. Luckily, the code that reboots the keyboard in ISP mode was not affected, so I was able to reflash it without doing a hard reset which is complicated on this keyboard.)

Features:

Fn and Num Lock translation is now completely table-based and independent of the main layer. That is, if you move the Del key to bottom right and put Pause on the top right key, Eject will stay on Fn+Pause, not move with Del. The additional two layers can also be customized, up to every single key. Fn takes precedence over Num ó if Num is on and Fn is down, the keys are interpreted according to the Fn layer.

Media keys are no longer confined to the Fn layer. You can have them in the main or Num layers, too. Keycodes E8h through FEh correspond to 23 different media keys (up from original 14 total).

Non-synchronized Num Lock has been extended to cover Num Lock-sensitive keys independent of the LED state. That is, if you press a key with keycode 59h (Keypad 1) through 63h (Keypad Dot) and the keyboard thinks your OS-level Num Lock is off, it will turn it on first, and turn off later when you stop typing. (In stock firmware, this behavior is tied to internal Num Lock status. But see Known bugs.)

Special pseudokeys Win+Pause and Ctrl+Break have been preserved. Keycodes ADh and AEh, respectively.

PC/Mac switch has been preserved. New keytables also have two versions each.

Other DIP switches (Henkan→Delete, Apps→Space, Euro2→Yen) no longer do anything. Ability to configure three keys was nice at the release of TECK, but is redundant when you can configure the whole thing.

Special keycode CFh (originally used for middle GUI key in Mac mode) was removed. It was necessary for differentiating between middle GUI which turns into Scroll Lock with Fn, and left GUI which doesnít. With layer-based Fn translation, it is no longer relevant.