XT/AT/PS2/Terminal to USB Converter with NKRO

[Soarer]

Where you use crazy chords, I would use Fn.  I'm also not a fan of toggles, hence using 1 and 2 instead.  So given that a SELECT is what I thought (except toggling seems to be required), is it not possible to assign arbitrary commands to key combinations, such that Fn+1 would execute a select?

The crazy chord was just an example There must be millions of ways you could put these pieces together... but one thing you can't do currently is get my FN codes to do anything other than I've described above.

Don't forget the toggle can toggle the very key that does the toggling! So if qwerty was your base mode you might have a layer with FN1 + 1 assigned to SELECT1, to get you to colemak. In your colemak mode FN1 + 2 could be assigned to SELECT1 to take you back to qwerty. Settings later in the file override earlier settings (if they're trying to set the same thing), so maybe something like this would work for you...

Code: [Select]

remapblock
    LCTRL FN1 # whatever key you want, obviously!
endblock

layerblock
    FN1 1
endblock

remapblock
layer 1
    1 SELECT1
    2 FAKE_01 # do nothing
endblock

ifselect 1

include colemak.sc

remapblock
layer 1
    1 FAKE_01 # do nothing
    2 SELECT1
endblock

Course, if you've got enough spare keys to remap, you could do it without the layer stuff.

[Soarer]

Oh yeah, forgot to mention - SELECT_0 can be used to reset all toggles to off.

So you could do it as macros I guess. Remap Fn+1 to something unused (e.g. FAKE_01), then have a macro that triggers on that, and executes:
PRESS SELECT_0
PRESS SELECT_1

Maybe one day I'll put in a specific macro command to do that in one step, but don't hold your breath!

[Soarer]

This new update sounds very awesome.  We need someone to help port it over to use on Phantom  :-)

Currently got about a dozen items on my to-do list, and making this sort of thing possible, somehow, is quite high on the list. I really can't say at the moment how quickly I'll be able get to it though.

[alaricljs]

Well, there's people willing to help if you want to share the load  

[Soarer]

Has anyone had a go at compiling the tools for Linux or MacOSX?

(Linux I could try sometime, but not Mac).

[theferenc]

I can try it on Mac later today or tomorrow, if you want. I'll be trying Linux, as well, since that's where my Model F is currently connected, and I'd prefer to just do it there.

Just to check, before I flash, are the "slow" fixes still in the latest version?

[Soarer]

I can try it on Mac later today or tomorrow, if you want. I'll be trying Linux, as well, since that's where my Model F is currently connected, and I'd prefer to just do it there.

Either would be great! Linux is probably the one I'm more worried about, in case different distros need different runes to get the rawhid stuff working.

Just to check, before I flash, are the "slow" fixes still in the latest version?

Yup.

[Soarer]

Lego!

[Soarer]

I call the bastardized version of usage page 7 HID codes that the converter uses internally HIDX. It's an amalgamation of page 7 codes, plus MEDIA (page 12), SYSTEM (page 1), FN, SELECT and FAKE. I'm not happy with FAKE, now that it's visible to users. I'm thinking of changing it so there's a set of names that are better suited to making readable remappings for - for example, the ten keys on the lhs of a 122-key 'board could be called LF1 to LF10 (Left Function).

So... just a heads up that some things are likely to change in the config files before I call it version 1.0!

[litster]

This new update sounds very awesome.  We need someone to help port it over to use on Phantom  :-)

Currently got about a dozen items on my to-do list, and making this sort of thing possible, somehow, is quite high on the list. I really can't say at the moment how quickly I'll be able get to it though.

Good to hear that this is on your to-do list!

[mkawa]

i can port this to phantom, i just need some pointers on how to get simulavr running for teensy code (using the package in the ubuntu oneiric repos). basically, it looks impossible as the man page doesn't list atmega32 as a supported arch at all. so, either this is true and i need to order a teensy to play with before my phantom kits come, or it's not true and i need the incantation to get it to work.

i also have a mac i can work on if there's a newer/better simulavr i can work with on that.

[Soarer]

I haven't used the simulator at all, just a combination of debug print output, extra LEDs, test signal outputs, and an oscilloscope. If it supports AT90USB162 (Teensy 1.0) or AT90USB1286 (Teensy++), they're close enough for you to be able to familiarise yourself with the tools and the CPU architecture (reading/writing ports and pins etc).

I'll probably give you libraries that include everything except the except the left hand block in the diagram a couple of posts ago. So you'll feed it key up and key down events, ask it for LED status, call its task function... and that's about it. It's almost a drop-in replacement for the PJRC sample usb_keyboard code. My code uses Timer 0, but that's about it as far as resources goes I think. Amongst other things, I use that to maintain a 32-bit millisecond tick counter, which is probably useful to you.

You'll need to scan the matrix, debounce, and translate matrix codes into HIDX codes.

[Soarer]

Built myself a neat converter today :-)

A while back I spotted some console hack dongles on sale for only $10, that have ATmega32U4 chips in them. I bought two, but unfortunately one was DOA. Oh well. The other one works fine. There's a schematic for it.



It started off looking like this inside...



Then I...
Removed the card socket.
Removed the 3.3V regulator and replaced it with a bit of wire, so that everything was running at 5V.
Soldered some thin single core wire to two pins on the chip for data and clock, and two SD card socket pads for power and ground.
Used hot glue to (hopefully) keep them from coming loose.
Cut the trailing socket from a PS/2-USB adapter (a crappy Belkin that kept reconnecting).
Put some heatshrink on near the end of it to stop it pulling out of the case.
Joined it up to the single core wires, with heatshrink on each connection.
Filed a hole in the case for the cable exit.









And ended up with this...



:-)

[SmallFry]

SWEET! Nice package to keep your converter in!
Since it uses Atmel's stuff to program it, is it compatible with the Teensy programming utility if you reflash the Bootloader?

[Soarer]

Thanks! Still one thing left to do... drill a hole in the case so I can reset it for flashing without taking it apart. Just pondering on exactly how I'll do it - thinking about gluing a flat piece of plastic onto the reset switch, so that it fills the gap between the switch and the case. Hmm. Anyway, the spot to drill is neatly marked by the cross of the 'T' in 'portable' :-D

[alaricljs]

How much does the case flex in that spot?  You might not need a hole, just fill the gap with a chunk of plastic and squeeze it to actuate the button.

[Soarer]

Since it uses Atmel's stuff to program it, is it compatible with the Teensy programming utility if you reflash the Bootloader?

Sorry, missed your edit... No, it's not compatible with the Teensy utility, and you can't load the Teensy bootloader onto it (or anything else for that matter, since you can't get the Teensy bootloader off a Teensy!). Atmel Flip works fine though, the 'problem' is just that the bootloader takes up more space than the Teensy one.

[mkawa]

I haven't used the simulator at all, just a combination of debug print output, extra LEDs, test signal outputs, and an oscilloscope. If it supports AT90USB162 (Teensy 1.0) or AT90USB1286 (Teensy++), they're close enough for you to be able to familiarise yourself with the tools and the CPU architecture (reading/writing ports and pins etc).

I'll probably give you libraries that include everything except the except the left hand block in the diagram a couple of posts ago. So you'll feed it key up and key down events, ask it for LED status, call its task function... and that's about it. It's almost a drop-in replacement for the PJRC sample usb_keyboard code. My code uses Timer 0, but that's about it as far as resources goes I think. Amongst other things, I use that to maintain a 32-bit millisecond tick counter, which is probably useful to you.

You'll need to scan the matrix, debounce, and translate matrix codes into HIDX codes.

ok message received -- it sounds like simulators are pretty hopeless. this will have to wait until i have a teensy in hand.

[Soarer]

How much does the case flex in that spot?  You might not need a hole, just fill the gap with a chunk of plastic and squeeze it to actuate the button.

Hardly any flex, surprisingly, but it might _just_ work... with a very firm squeeze!

The other alternative is to figure out how to reboot to the loader from firmware, and then trigger it from a key combo, or by sending it some rawhid on the config interface.

[Soarer]

ok message received -- it sounds like simulators are pretty hopeless. this will have to wait until i have a teensy in hand.

Dunno about hopeless, but I always find using them a mixed bag. It's nice to be able to step through code and check that it's doing what you intended, but on the other hand, you end up spending a fair bit of time working out how to simulate the external inputs. For example, for a keyboard controller, it would be fine to simulate the matrix scan code, but not so good at the debouncing code - you'd need to record some bouncing signals and replay them to the simulator, at the simulator's speed, and take into account how the matrix scanning interacts with it.

[mkawa]

agreed. i was hoping there was a nice debugging toolkit that would let me do these things, but it sounds like most people working on teensy and duino projects just end up firing the actual boards up on their builds. (it's a good thing the code is all rather simple!)

i'll check back in in a bit when we have phantom boards and teensies in hand

[Soarer]

The other alternative is to figure out how to reboot to the loader from firmware, and then trigger it from a key combo, or by sending it some rawhid on the config interface.

Hmm. This looks quite easy, actually, but which address to jump to depends on the bootloader.

Jumping To The Bootloader - PJRC
USB DFU Bootloader Datasheet (pdf) - Atmel Corporation

It would be nice to determine which bottyloader is present in code, rather than having specific builds. Hmm.

[drteming]

Newbie here.  Just got a terminal 1390572 last week.  Cleaned it up and did a full bolt mod and built a converter per Soarer's instructions.  I am typing this on the behemoth.  What a hoot.  Here's some pics of the converter.

In the box.


In action.


Thank you, Soarer!

[Soarer]

Thank you for posting pics - I love seeing a nice tidy build!

[fohat.digs]

Oh that is beautiful. I am doing something similar when I have some spare time, and you just raised the bar on my expectations.

Very nice box.

[theferenc]

Soarer, do you want compilation feedback via PM or in the thread?

[Soarer]

Aha, cool! Probably here, in case others might want to try as well.

Unless it's embarassing...

[theferenc]

I don't think it's embarrassing, no. This is all on Linux (RHEL 6).

I was able to get 2 of the tools (scas and scdis) to compile, after futzing around with them for a while. I'll PM you with the exact fixes I had to make. I can't get the other two (scwr and scrd) to compile. I'm pretty sure it's due to a missing usb.h file on RHEL. I'm going to keep trying to make them work, though.

To make these completely cross platform, there will need to be some conditional compilation, depending on platform. I've added the necessary code to the two files I was able to make compile, but not in a cross platform fashion. Everything is just hard coded. I'll add the macros to make it work on at least windows and linux, and I'll try and get mac done this weekend, then send everything back to you.

Anyone else able to get it to work?

[Soarer]

Hmm. This looks quite easy, actually, but which address to jump to depends on the bootloader.

Jumping To The Bootloader - PJRC
USB DFU Bootloader Datasheet (pdf) - Atmel Corporation

It would be nice to determine which bottyloader is present in code, rather than having specific builds. Hmm.

Knocked together some code that should work for nearly all Atmel AVR chips (except xmega), and with any bootloader :-)

Not tested it much yet... would be a good use of a simulator!

[Soarer]

I don't think it's embarrassing, no. This is all on Linux (RHEL 6).

I was able to get 2 of the tools (scas and scdis) to compile, after futzing around with them for a while. I'll PM you with the exact fixes I had to make. I can't get the other two (scwr and scrd) to compile. I'm pretty sure it's due to a missing usb.h file on RHEL. I'm going to keep trying to make them work, though.

To make these completely cross platform, there will need to be some conditional compilation, depending on platform. I've added the necessary code to the two files I was able to make compile, but not in a cross platform fashion. Everything is just hard coded. I'll add the macros to make it work on at least windows and linux, and I'll try and get mac done this weekend, then send everything back to you.

Thanks for putting the time in! I'll plug my Linux (Mint, Debian) box back in so I can have a look see if it's got a usb.h on it.

[Soarer]

I'll plug my Linux (Mint, Debian) box back in so I can have a look see if it's got a usb.h on it.

Got scrd and scwr working on Mint! Needed libusb-0.1-4 and libusb-dev installing to get the required files. To keep it simple I used the PJRC Makefile, and changed my source files from C++ to C (to avoid any g++ vs gcc complications), which then only needed a few minor follow-up changes.

[RC-1140]

Hey Soarer,
at first: thank you very much for creating such a fantastic converter software. I use it all the time, for multiple keyboards. But now I was thinking about using it in an embedded project. And since I'm a cheapskate I don't want to order 6 more teensy's from pjrc. Would your precompiled hex file work on an ATMega 32U4 connected in the same way as a teensy, or does the bootloader do anything crazy, so teensy code doesn't run on ATMegas? Too sad that your code is too big to fit an ATMega 16U4...

RC-1140

[Soarer]

It should work fine on any 32U4, as long as you can get it in there! The dongle I adapted has the Atmel bootloader on it, and that works OK.

I might be able to trim my code down to 16KB, but I'm not sure if I could get it down to 12KB to leave room for the bigass Atmel bootloader :-(
And of course, I'm not sure I can keep it under 16KB as I add new features.

The other issue is RAM - the 16U4 might only have enough for basic functionality (i.e. no layers or macros).

[RC-1140]

Actually even this would be great, as I'm currently using 0.996 anyway. This might be an interesting idea: having some kind of a "light" version. Maybe this would be interesting for anybody wanting to use it in some kind of an embedded project. (Noncommercial of course)

But I don't think RAM would be an issue on the Atmega16U4, if I read the datasheet right, the only difference between the 32U4 and the 16U4 is the Flash. Both have 2,5kB SRAM and 1kB EEPROM, and the same layout of Ports/Pins.

I would really appreciate if you did this one day.

RC-1140

[Soarer]

The trouble is, I'm not sure why it helps much - the '32U4 chip is about 5EUR, and the '16U4 is about 4EUR - so there's not much reason on the basis of price. The other 16KB chip with USB, the AT90USB162 used in the original Teensy, is getting more expensive (relatively). There are a number of Teensy-like boards out there using the '162, but they aren't generally much cheaper than the Teensy 2.0, if at all.

The '16U4 has 1.25KB SRAM and 512 bytes EEPROM. The current build uses 1174 bytes of SRAM, and that's without counting stack space. More than half of that is related to layers and macros though.

How about the '32U2? It doesn't have enough SRAM or USB endpoints for the latest version, but 0.996 should run fine on it already, I think. It's about the same price as the '16U4.

[Soarer]

In other news, I just added Jump to Bootloader support for the next release, with two ways of triggering it - a macro command so it can be done from the keyboard, and a utility so it can be done from the host PC.

[RC-1140]

Yeah, of course that little price difference doesn't justify the extra work you would have with it. It was just a small idea I had,because I will have access to many dev boards with an 16U4 soon, and I thought I could use them, so I don't have to buy Teensy's from the US anymore. Apparently the easiest will be to get the dev boards, get some 32U4s and solder them in.

Thanks anyway!
RC-1140

[Soarer]

I will have a look in case there's some easy memory saving that can be done, but otherwise I should pander to the masses... get the converter and tools up to v1.0 standard, make a library of my USB stuff, make a controller version, make a model F controller version, ... :-)

(OK, the last one is just because _I_ want to!)

[Soarer]

Well, I managed to reduce the size by about 2KB. (Stupid makefile forcing inclusion of vfprintf and vfscanf!)
So down to about 14.25KB for the latest (unreleased) build.
There's still about 0.5KB used by malloc and free that I could get rid of, but I'm pretty sure that wasn't there in 0.996 anyway.

So I think it might fit, but not with the default Atmel bootloader in place. Perhaps LUFA has one that's 2KB or less? Or, you could use one of your dev boards to ISP the others, and do away with the bootloader altogether.

I'm not sure yet, but I think I'd rather make it a cut down version of the latest code (cut down to fit in 1.25KB SRAM, and get under 14KB FLASH). That means you could still have the config stuff for basic remaps and macros. But not have layers, or macros that trigger on key release.

[SmallFry]

Will you ever open source your code? I know I've asked before, but can't recall off hand.

[Soarer]

Will you ever open source your code? I know I've asked before, but can't recall off hand.

I really don't know if or when. Once done it cannot be undone - last time I started thinking about it I got bogged down in trying to decide what license to use (and I still don't really like any of them). All I can honestly say is that it might happen eventually, but it's not at all high up on my to-do list.

[litster]

Which IBM keyboard would be best to use for this project if I want to keep it small and have NKRO?

[Soarer]

The AT (84-key). It's not 'small', but there's only about an extra inch on the RHS compared to a TKL, so you can still have your mouse close.

[litster]

Right, the AT.  But it would be hard to get one now.  Could I do this on a Phantom, without changing your source code, by rewiring the Phantom rows and columns to what your teensy firmware expects?

[Soarer]

Hard, but far from impossible. You just have to keep looking, and be prepared to pay whatever the going rate is.

Errr, no. This is a converter, not a controller. Until I make it a controller too. Or more likely, make it so that you can make it a controller. Who is the software bod for the Phantom?

I've brutally reduced my to-do list for v1.0, so that I can move on to other things like controllers. Anything not directly related to making a stable version for config files etc. has been postponed. But still, it will happen when it happens.

[litster]

Ah, I get it now.  The Phantom firmware we have now came from PrinsValium.  His code is based on the Teensy's keyboard sample code.  It has 6KRO over USB.

Another question.  Could your converter work in this way?

Filco in PS/2 mode -> Soarer's Converter -> PC USB port == NKRO over USB?

[Soarer]

OK. I'll talk to him when I'm ready to make plans for controller stuff.

[Soarer]

Another question.  Could your converter work in this way?

Filco in PS/2 mode -> Soarer's Converter -> PC USB port == NKRO over USB?

Yes.

(I missed seeing the edit again!)

[drteming]

Well, I worked up the courage to delve into Soarer's 0.997 firmware.  My last foray into any sort of programming was in 1988 during high school using Pascal so I'm a bit behind the times.  Interestingly, we used IBM PS/2's with model M keyboards.  Anyway, I wasn't happy with the default mapping of the keys on my terminal 1390572.  With a little patience and persistence, I figured how to use hid_listen and found the key syntax in the hid_tokens.cpp file (opens with notepad) located in the source code of Soarer's sctools "common" subfolder.  

I use the number pad a lot in my work so I remapped the terminal pad to be exactly like a standard model M, and for the heck of it, I remapped Cmd13-Cmd24 to media keys.  The code is as follows.

Code: [Select]

[FONT=Courier New]ifset set3
remapblock
EUROPE_1 BACKSLASH # the key to the lower left of Field Exit/Enter

ESC NUM_LOCK # This block remaps the number pad
NUM_LOCK PAD_SLASH # to be identical to a regular model M
SCROLL_LOCK PAD_ASTERIX #
PAD_ASTERIX PAD_PLUS # Field - to + key
PAD_MINUS PAD_PLUS # Blank to + key
FAKE_19 PAD_MINUS # The top right key of the number pad
PAD_PLUS PAD_ENTER

FAKE_08 ESC # This block remaps the function keys
FAKE_09 DELETE # on the left side of the keyboard
FAKE_10 PRINTSCREEN
FAKE_11 SCROLL_LOCK
FAKE_12 PAUSE
FAKE_13 F1 # Help
FAKE_14 UNASSIGNED
FAKE_15 UNASSIGNED
FAKE_16 LGUI # Windows key
FAKE_17 APP # Menu Key

F13 MEDIA_WWW_HOME # Function/Cmd keys 13-24, my preference
F14 MEDIA_WWW_SEARCH
F15 MEDIA_MAIL
F16 MEDIA_MY_COMPUTER
F17 MEDIA_CALCULATOR
F18 MEDIA_PLAY_PAUSE
F19 MEDIA_STOP
F20 MEDIA_PREV_TRACK
F21 MEDIA_NEXT_TRACK
F22 MEDIA_VOLUME_UP
F23 MEDIA_VOLUME_DOWN
F24 MEDIA_MUTE

EUROPE_2 LSHIFT # The < > key to the right of left shift
LANG_4 UNASSIGNED # The key in the middle of the arrow keys
endblock
[/FONT]
Copy and paste the above code into notepad and save it as a .cs file.  Then use Soarer's sctools to convert and load it into the Teensy converter.  Of course, feel free to change the mapping to your liking.

This is only for the default 122 key model M terminal keyboard.  YMMV.  Hope this helps a fellow newbie.

[wcass]

..., make a model F controller version, ... :-)

(OK, the last one is just because _I_ want to!)

if you are serious about this, i'ld like to talk to you about a project i'm working on. some discussion is here:
http://geekhack.org/showthread.php?28021-a-modern-Model-F