As the uninitiated, soarer's converter sounds like a protocol converter, so you'd have to figure out the protocol and mess with that; a lot of good fun to be had I'm sure.
Other option (as sixty(?) wanted to go for) is to birth the board a new controller- disconnect the lot, reuse the existing matrix (or build your own) and connect that to for instance that teensy, upload some keyboard hid firmware and tweak to fit (and setup some layers perhaps).

dirge wrote:You're much better at this type of thing so would you offer some advice on how I could start getting this http://keyboardporn.com/mx-switch/wyse-wy60-terminal/ converted?

Just need to know how to start, have breadboard, teensy2, female connector for the WYSE. I'll try not to be a massive pain in the arse

I'm going to assume for now that its signalling is something like the two shown on kbdbabel...

It will be quite hard work, I think. The problem is that it runs pretty quickly, so the code on the Teensy would have to keep up. Responding to an interrupt reliably within 17uS is actually quite a challenge, since every other interrupt routine has to finish within that time (mainly this is the USB interrupts). That can only happen reliably if they are written to not block other interrupts. That said, it's not impossible.

It would be far easier to replace the controller though!

Thanks mate, that helps a lot.

Working on the key matrix, following sixty's instructions. I'll take my mess out of your thread now, but I do plan to make one of your converters too

Soarer wrote:Well, it doesn't mean the Teensy isn't damaged, but it seems to be basically OK.

What does hid_listen show when you connect the converter? (Run hid_listen, connect kb to converter, connect converter to usb).

hid_listen only prints out a lot of "R05", with an occasional "R04" every now and then. If I remember correctly, at least, haven't checked in a couple of weeks.

fruktstund wrote:hid_listen only prints out a lot of "R05", with an occasional "R04" every now and then. If I remember correctly, at least, haven't checked in a couple of weeks.

Sorry, I meant when it's first connected... have hid_listen running before you plug it in... it should start with wEE

Just built one of these.

Soarer, you are a genius. I'll take some pics when I've got a project box sorted out.

It's a lousy photo...

Soarer wrote:

fruktstund wrote:hid_listen only prints out a lot of "R05", with an occasional "R04" every now and then. If I remember correctly, at least, haven't checked in a couple of weeks.

Sorry, I meant when it's first connected... have hid_listen running before you plug it in... it should start with wEE

Ah, I see. I'll check as soon as I can!

hoggy wrote:It's a lousy photo...

Nice project box!

Soarer wrote:

hoggy wrote:It's a lousy photo...

Nice project box!

Indeed! Not the smallest, but looks to be the most functionally complete

What I wanted to make was a small lego box, with 3 leds and one of these stickers (to fit) on the top.


...but the box I've got is starting to grow on me.

The converter works better with my siig minitouch than a blue cube.

That's a fine idea to use one of those stickers!

I don't think I ever looked into why the minitouch and blue cube combo isn't a good one... so I'm glad to hear mine works ok with it

New version uploaded which fixes a bug that stopped jump to bootloader functions working on AT90USB1286 (Teensy++ 2.0). Not quite sure why the ATmega32U4 (Teensy 2.0) wasn't affected - it would've been jumping into the middle of the bootloader instead of the beginning!!

Another new version posted, v1.02 - the converter wasn't handling the commands telling it when to enable remote wakeup, and would try to wakeup the computer whenever a key was pressed while it was suspended. Mostly fine, but it is suspended at times during the boot sequence (before BIOS inits it, and then before the OS inits it) when attempting wakeup isn't valid, and pressing a key in those times would cause the converter to get stuck in a 'waking' state which never ended.

As with v1.01, not an essential update unless the problem troubles you!

The next version will include a few fixes for minor errors revealed by using the Command Verifier compliance testing tool. I'm fairly certain that none of them would cause any issues in practice though.

Does the current code base have support for driving LEDs for Caps Lock, Scroll Lock and Num Lock?
If not, then I would like to request that as an optional feature.

There is an ongoing project for using this converter for Bringing the IBM PC XT into the 21st Century, and there is at least one person who would like to install LEDs into his case.

It does

I have made CapsLock an FN1 key, but now I was wondering if I could make some key on the Fn layer into a caps lock toggle.

Is it possible to write a macro which is activated using Fn + LSHIFT + RSHIFT?

Not without remapping one of the shifts in the Fn layer to something which would just be used to trigger the macro. So, for example, remap Fn + RSHIFT to EXSEL, and then macro on LSHIFT + EXSEL. Not ideal perhaps, because then you've lost your Fn + RSHIFT, and you have to press the shifts in the right order.

I would either do it just as a remap (Fn + single key), or have it as a macro in the base layer as LSHIFT + RSHIFT (actually, that would be all layers where you didn't remap the shifts). In the latter case, it helps to also add a second macro that is on RSHIFT + LSHIFT, so that it doesn't matter which order you press them in.

In case it helps understand it, the macro stuff happens distinctly after the remapping stuff, and the layers are part of remapping...



Macro triggering is complex enough already, so I'm reluctant to add more to it by combining those blocks!

Ah, that's a handy chart. I've been experimentally building some other macros to counter an Fn remap so I figured it would work like that.

No sweat though, I'll try to find another combination of keys. Maybe I can repurpose num lock then.

I use the double-shift myself, in the base layer, and find it feels quite logical. But, indeed, Fn + NumLk would also make good sense

There is some logic behind the way it works at the moment - in effect layers just give you a bigger virtual keyboard, and then you can define which keys of that bigger keyboard trigger macros. I admit though, it does fail on modifiers, as in your example.

I could add a bunch more fake HID codes, perhaps called MACRO_1 etc, that you'd use to remap to if you just wanted the keys to trigger macros, so config files remain readable. (You'd still have to write the macro trigger etc). Although it's not really any different to using some of the strange (and unrecognised by Windows) codes such as EXSEL, it would make more codes available for such use. And/or I could allow numeric codes to be used. Either would only need changes to scas (and scdis); the converter itself would already handle them just fine. Still doesn't cope with your example though

Has anyone ever tested if you can hook up an old laptop keyboard to your computer with Soarers adapter?
If that would be possible it would be super cool!

*edit: Findecanors comment makes sense ^^ I guess it's not that easy making one yourself? I'm not an electronics expert so my knowledge is pretty standard.

If a keyboard has a ribbon cable, then you can bet that the controller is not part of it. You would need a controller, not a protocol converter.

I happen to have another (weird) question: will there ever be support for a few extra Fn keys connected directly to one of the free Teensy ports?

I'm thinking about adding an extra Fn key but I would like to avoid messing around with the keyboard's matrix. Connecting an external switch would mean that I'd just need to connect it between +5V + a resistor and ground, and it would even allow me to make it a foot switch.

Any thoughts on how complicated this is? I could understand that you wouldn't like to debounce the switch, but then again it's just an Fn key which is non-printable...

JBert wrote:I happen to have another (weird) question: will there ever be support for a few extra Fn keys connected directly to one of the free Teensy ports?

I'm thinking about adding an extra Fn key but I would like to avoid messing around with the keyboard's matrix. Connecting an external switch would mean that I'd just need to connect it between +5V + a resistor and ground, and it would even allow me to make it a foot switch.

Any thoughts on how complicated this is? I could understand that you wouldn't like to debounce the switch, but then again it's just an Fn key which is non-printable...

No answer?


I actually noticed another thing: it seems that the DELETE remap code creates a key which doesn't repeat (i.e. the BREAK code is sent immediately after the MAKE code).
Here's the output from HID Listen:

Code: Select all

r3A +39
r3A
r3A
r3A
r3A
r3A
r3A
r3A
r3A r53 +63
rD3 -63
rBA -39

Extracts from the config in which I mapped it:

Code: Select all

remapblock
layer 0
# snip
   CAPS_LOCK FN1 # need to map the FN key into the base layer (0)
endblock

# define that FN1 accesses layer 1
layerblock
   FN1 1
endblock

# the layer itself is just some remaps tagged with the layer number
remapblock
layer 1
# snip
   TAB DELETE
endblock

JBert wrote:No answer?

Sorry! I saw your post before, but then forgot about it

I don't think I'll add anything like that soon. I really want to work on controllers for a bit, when I get round to having any time! Perhaps after that, I might add something.

JBert wrote:I actually noticed another thing: it seems that the DELETE remap code creates a key which doesn't repeat (i.e. the BREAK code is sent immediately after the MAKE code).

I dunno, it doesn't look like it's the remap... the release code (rD3) is coming in before the USB key is released (-63), and the layer/remapping code can't add in events. Not sure what's going on there!

Soarer wrote:

JBert wrote:I actually noticed another thing: it seems that the DELETE remap code creates a key which doesn't repeat (i.e. the BREAK code is sent immediately after the MAKE code).

I dunno, it doesn't look like it's the remap... the release code (rD3) is coming in before the USB key is released (-63), and the layer/remapping code can't add in events. Not sure what's going on there!

Whoah, that's strange. I can't get output using DELETE, even with just:
remapblock
layer 0
TAB DELETE
endblock

Ahem Ignore that Autohotkey was blocking my deletes

Woah, today it somehow works?!?

Code: Select all

r3A +39
r3A
r3A
r3A r53 +63
r53
r53
r53
r53 rD3 -63
rBA -39

I also noticed that the output above is not for TAB but PAD_PERIOD (since my model F PC has no delete key, I also remapped it to DELETE when I press the Fn key).

Sorry if I sent you on a wild goose chase poring over the code for errors. Maybe it was some weird initialization thing? I do remember that I unplugged and re-plugged the USB side of the Teensy while my PC was on.

I'm going to do some further testing... Thanks for looking at it.

Don't worry, I didn't spend too long on it. I added some debug printing to the macro output stage to check what was finally being sent, and it looked fine. Will leave it in if it doesn't cause problems - more debug is always useful - so not really a waste of time

Unrelated, but I did find that using the scrd tool left the config interface inoperable, I must've broken it at some point

Hey Soarer!
I recently acquired a liberty keyboard and it has this connecter:
http://www.kbdbabel.org/conn/kbd_connector_liberty.png

The weird thing is that the 12V and GRND from the image don't match with the socket I have on my keyboard (because it is written on the PCB). I have no clue though what S.P., LRXD and LTXD mean.



So based on that it looks more like this connecter:
http://www.kbdbabel.org/conn/kbd_connector_hp150.png

I was wondering, how can I find out what the data and clock cables are, and is it even possible to hook something up that demands 12V? Thanks