I think this is a fantastic idea. While I dont have any specific skills to contribute, I'll definitely contribute my enthusiasm and "can-do" attitude! ;-D I'll send out "positive vibes" at you guys while i'm meditating. And I'll create voodoo dolls of your opponents and stick them with pins.
I can also do the 'vision thing' really well, if you guys need to brainstorm at some point in the process ;)
By focusing only on the controller, it will allow for the building in of almost, if not all, wanted features
yes, a custom controller would enable many modding projects.
such as heavily modifying an ibm model f :D
Capacitive switches may require special electronics though.
Thanks. AIKON was the new name. Couldn't remember that. Here's another page in english:
http://www.otd.kr/bbs/board.php?bo_table=aikon_manual&wr_id=10
Atmel's AT90USB chip
As far as a keyboard controller is concerned, if anyone is interested in my work thus far, I'll post the code. It's based on Atmel's AT90USB chip, which I've found pretty straightforward to learn to use.
Is that the same chip used in the "Teensy++" development board? (I think so, but I'm not quite sure.)
The AT90USB1286 and AT90USB646 have an USB interface for applications communicating with a USB host. The AT90USB1287 and AT90USB647 comply with the USB On-The-Go (OTG) standard for use as Dual Role Devices (DRD) in applications operating as either host or function device. The USB host capability is key to embedded devices needing to communicate without PC intervention.
The AT90USB1286 and AT90USB1287 have 128 KBytes of In-System Programmable (ISP) Flash, 8 KBytes of RAM and 4 KBytes of EEPROM. The AT90USB646 and AT90USB647 are identical but with half the memory size. All devices have an on-chip bootloader that allows ISP through the USB bus providing unrivalled flexibility from development phase to field update.
I've been carrying around vague notions of using a Teensy or Teensy++ as a hardware key remapper.
(wouldn't it be cool if you could get counters from keyboards for number of key presses, as you can for backlight hours from the service menu of LCD monitors)
Sounds pretty awesome. Any way you can decouple the key map from the key layout? If you use standard codes to represent the layout, you could make generic map files that hopefully wouldn't require a recompile & firmware upload.
How do you feel about listening for character sequences for switching to a certain map?
US: QWERTY, Dvorak, Colemak, Dvorak (left handed), Dvorak (right handed), Dvorak variants?
Germany: QWERTZ, International Dvorak, Colemak?
I once had an old programmable keyboard where you could reassign buttons with a certain key sequence. Program + key + program + other key (or something like that) would flip them and permanently store the flip. (Too bad that keyboard was domes, and it used volatile storage that would perish with the battery.)
Anyway. Beyond certain sets of keymaps, you may be able to get clever with how you activate features. If SL+SL rotates the layout, maybe SL+SL+left Ctrl swaps control and caps lock. I'm just trying to think of doing this in ways that don't require firmware builds/flashes, although I guess dip switches would be fine.
Ever use vi/vim?
It would be awesome if I could easily program a "normal mode" for some of the development tools I have that would be portable between computers, because it's integrated into my keyboard! Emacs users might like a sticky control key feature.
And, um, on the DL, MMO guys might like it if macro playback could have humanizing randomization added. As in, realistic and non-constant (but random) delays between keys in the macro sequence.
In between would be good too, but I think the idea is to do lots of custom modding, up to and including bypassing crappy controllers
As a result, my firmware now runs on the same hardware as the one used by RUMP and Dulcimer when built for the M.
Before getting excited about programmability, I would like to remind everyone of this unfortunate case that we must avoid:
http://www.engadget.com/2009/08/04/apple-keyboard-gets-hacked-like-a-ripe-papaya-perp-caught-on-vi/
I don't have a lot of background in device programming, but I have been thinking about how to ensure the firmware doesn't get updated if somebody gains root on the computer it's hooked up to. I'm thinking, it needs some sort of hardware switch that switches it on to 'programming mode' and would not allow the use of keyboard until it's switched back to 'normal mode' again.
Because, if someone can get to the hardware, they can do a lot more real damage anyway.
We might also need a public key certification to ensure that the firmware people download from some site is not malicious.
The reason is two known problems:
1. unauthorized firmware update by compromised host computer.
2. I recall a wide spread problem with programmable Anykey boards where people forget to turn off programming mode and caused confusion. Some IT department to ban those keyboards altogether.
My wish list is Bluetooth.
Bluetooth HID specification is simply a wrapper of the USB specification, so it shouldn't be hard to hook up a Bluetooth chip if I knew how... Anyone got a clue how to do that?
Bluetooth keyboards are simply not feasible for small scale marketing because it needs FCC approval. (Although some Bluetooth chipsets are approved, supposedly simplify the process.) An example is Filco's wireless keyboard simply deemed not feasible for marketing in the U.S.
When you brew your own, you don't need FCC's approval stamp and that's a major plus for me.
welcome Mnemonix! we will surely appreciate any experience or code you want to share
Before getting excited about programmability, I would like to remind everyone of this unfortunate case that we must avoid:
http://www.engadget.com/2009/08/04/apple-keyboard-gets-hacked-like-a-ripe-papaya-perp-caught-on-vi/
So it's possible that I could flash your firmware onto my "Rump" controller board? If so then I'll definitely considering testing this new firmware.
What's microcontroller to do with ghosting? I thought that's all done in the external circuitry.
As I have a couple-three of the IBM 122-key terminal 'M' type keyboards, I have thought of this sort of thing for some time now...
The hardware is based on the Atmel AVR ATMEGA16 or ATMEGA32 microcontroller (most probably, some other AVRs would be possible, too).So I guess you want to use the V-USB firmware platform (http://www.obdev.at/products/vusb/index.html) to run things on?
I don't have a lot of background in device programming, but I have been thinking about how to ensure the firmware doesn't get updated if somebody gains root on the computer it's hooked up to. I'm thinking, it needs some sort of hardware switch that switches it on to 'programming mode' and would not allow the use of keyboard until it's switched back to 'normal mode' again.This is probably the safest way. Most µC boot loaders already do this, for examples see the AIKON and Teensy boards.
We might also need a public key certification to ensure that the firmware people download from some site is not malicious.I don't know whether public key certificates are really needed. After all, always check everything you download from the Internet. Even drivers might be infected, so you have to make sure you trust the web page you got it from.
What's microcontroller to do with ghosting? I thought that's all done in the external circuitry.That's not entirely right: the key matrix causes ghosting due to a "short circuit". Adding diodes resolves it.
By the way, I'm still reading about USB 3.0 specs... seems like it allows for bigger packet size, meaning possible N-key rollover for USB 3.0. But I'm not sure if that applies to HID.USB HID already has arbitrary packet sizes because the device tells the USB host what kind of packets it sends.
Oh, I'm in the San Francisco Bay Area, too, perhaps we can have a keyboard geeks meetup event! show and tell.
So I guess you want to use the V-USB firmware platform (http://www.obdev.at/products/vusb/index.html) to run things on?
What about Atmel's USB-supported chips? Do these cost more, do these have real hardware support for USB and could they work better?
I haven't figured out the differences. Just asking if you had more information by chance.
From what I gathered, one problem with V-USB is that it hasn't been successfully ported to Arduino dev env and the like, meaning it requires a programmer. It's also picky about clock speed. Otherwise, I think it would work just fine, and cheap.
Geekey?
Geekey?
Just need a name, and I can set up a site for the project.I had "Rubicon" in mind.
Geekey?Oh dear, that sounds interesting as well.
The source code for my keyboard controller firmware is available now:
If you would like to contribute anything to this project, then you are, of course, very welcome to do so!
The Teensy miniature AVR development board is now available through Adafruit for $20.Show Image(http://adafruit.com/images/medium/teensyparts_MED.jpg)
http://www.adafruit.com/index.php?main_page=product_info&cPath=16&products_id=199
"[...] a complete USB-based microcontoller development system. Only a standard Mini-B USB cable (sold separately) is needed to connect to a PC or Macintosh"
The Teensy miniature AVR development board is now available through Adafruit for $20.Too bad the Teensy++ isn't available from there... But the Teensy is at least a start.
http://adafruit.com/images/medium/teensyparts_MED.jpg
http://www.adafruit.com/index.php?main_page=product_info&cPath=16&products_id=199
"[...] a complete USB-based microcontoller development system. Only a standard Mini-B USB cable (sold separately) is needed to connect to a PC or Macintosh"
The Teensy miniature AVR development board is now available through Adafruit for $20.
Hey, these are sweet! More expensive than doing it yourself, but definitely worth them given the work that you can save. Only I would prefer a full-size B-type USB connecter on a keyboard because of mechanical stability, but maybe that's just me.The ATmega32U4 indeed runs Atmel's own USB stack and should have hardware support for USB. You could still use V-USB if you wanted do (although it would be a waste of the chip and even pointless on the Teensy). Another interesting thing is that this chip readily handles the voltages needed for USB, whereas general-purpose AVR chips need external circuitry.
From what I can see, an initial port of my code to Teensy would be trivial to do as it is an ATMEGA32 with USB--or at least I assume that the ATMEGA32U4 is not much different from a ATMEGA32...
For a full port, the glue code for USB would need to be rewritten to replace V-USB by native USB support. The Teensy does, however, offer only 25 I/O pins. That's enough, e.g., for a 16x8 keyboard matrix, but add LEDs and config jumpers, and you are running out of I/O pins. On the other hand, shift registers could be used to reclaim some the the pins.
Does anyone know if the AT90USB646 as used on the Teensy++ is similar to the ATMEGA controllers? Or is it very different?
If a chip provides built-in usb support: will it be possibe to run a ps/2 protocol over the usb lines? It would be great if ps/2 support could be added for passive adapters.
You could mod the Teensy board to have an extra port on the keyboard side (like IBM's SDL plug) which still means you'd have to make your own PS/2 implementation.
I think rather then trying to shoehorn a dev board into the project, its best to just build from the ground up.
You could still use V-USB if you wanted do (although it would be a waste of the chip and even pointless on the Teensy).
I think rather then trying to shoehorn a dev board into the project, its best to just build from the ground up.
Exactly. V-USB would be quite useless on that platform, which is a good thing.
OK. But wouldn't the final controller be an amalgamation of some devboard + connectors + maybe a few extra components anyway? The final PCB should, of course, not look like that, but be a streamlined, compact product. For a quick start and to see what's needed, however, a cheap devboard like Teensy(++) seems very appealing to me. OTOH, I also don't have a lot of experience in hardware development... :wink:
Independent of the concrete platform, I wonder how to solve a problem that I ran into, though: Virtually every keyboard model seems to use its own connectors for the flat cables running from the PCB to the keyboard matrix and the LEDs. There's a wide variaty of connectors, and I've learned that those FFCs are especially hard to obtain for private projects (need to buy lots of 1000, won't sell to private persons, etc.).
And--apart from the problem how to get at the FFCs--how are keyboards going to be connected to the controller?
don't avrs have built-in pull-up resistors on the i/o pins?
Most micro's have some form of weak pullup on some port pins. Tho these tend to be quite high value (and thereby quite susceptible to induced noise when you have long traces as on a keyboard PCB).
After that, it will have a standardized interface, and I invision people creating adapter boards for the standard keyboards (eg model M, Filco, Cherry, etc) as these tend to also have a fairly standard interface to the controller.
it sounds like we need a list of candidate microcontrollers :)
although this won't stop the software guys: the architecture and algorithms can be developed and tested while hardware is being worked out.
And, I agree, just because there are development boards available for some specific MCU should not be the reason for choosing it. But I don't have an overview over the MCU market, so I cannot give any recommendations here.
I say we just slap an 8 core Parallax Propeller in there and call it good =P.
XD thanks, i feel less crazy now for having thought that
edit: if most/all of the candidates can be programmed in C, then moving between platforms would be a *lot* easier
I say we just slap an 8 core Parallax Propeller in there and call it good =P.
- Parallax : Propeller
- Cyprus : Lots of semi specific keyboard uCs.
- Microchip : 24HJ/18F
- Atmel : Fairly large range
- Freescale : Coldfire
- TI : MSP430
btw, i don't know about you guys, but ever since mnemonix published his controller software as open source, i'm itching to order an avr development board :p
But for me the most important of all aspects is that development must be possible using solely open source tools. I would not buy and install Windows for running some proprietary compiler or crappy IDE, especially not for a fun project (= no payment). Even if nobody would have to pay for Windows and the development tools, the whole project would still not be free really because it would depend on closed-source tools and on at least two companies (MS, who make terrible operating systems, and the MCU company, who could cripple the devtools anytime for sqeezing some $$$). This might be acceptable for commercial use, but certainly not for an open source project.
Therefore, I think we should rule out any platform for which there is no open source toolchain, even if the hardware is a perfect match. I also think it must be possible to program in C; I don't have a problem with assembler languages, but C is waaaay easier and still fast.
I think a free/open source C compiler is a must no matter what platform is chosen. Once the boot loader is in place (which requires some sort of programmer) the end user should be able to write, compile, and upload code to the controller without the need of any specialized tools.
There is at least some kind of gcc support for all of these. There is even an llvm backend for Atmels.
Maybe someone here could comment on how well the gcc versions perform on the various platforms? (I know the one for Atmel chips works quite well .)
likewise...
the mysteriously strong-enough weak pullup resistors are still in the back of my mind :)
<$30 for a 5"x10" board
not bad :) is that one layer or two?
Awesome. I wanna see how you wire the board (I'm really a newbie hobbyist when it comes to electronics stuff) Can you show me a picture of the flip side?
Gcc support for the MSP430, Atmel is pretty mature, the coldfire versions were ok last time I used them, and the PIC24 series support was poor at best (even the commercial compilers were pretty new and buggy last time I used them about a year ago). The 8 bit PIC (12F/16F families) have much better support, but are somewhat lacking in the system resources department.
Pics are very cheap and easy to find I believe, that's a good thing, but Atmels are very common to, right? And if they also have good gcc support, I'd say they seem to be nice candidates.
i backtracked a couple pages
but you are saying that right now this WORKS???
EDIT i used to use some KDE-based diagram software that i really liked, if you happen to be on linux
Mnemonix
If you care to post the schematic, I can get that into a colour-shaded form (Colour blocks for pin groupings etc), pretty quickly. Probably into a downloadable PCB layout as well (I work for an electronics Retailer... handy sometimes!)
I do have an older copy of Eagle somewhere, but I am using Win7 (If there is a *nix binary, I don't have it), so not sure if it works. But I'll dig it out and see what happens.
and yeah i do think this is pretty amazing, it went from idea to something that works pretty fast, makes me wonder if i will ever have a hardware colemak keyboard just to have
If you care to post the schematic, I can get that into a colour-shaded form (Colour blocks for pin groupings etc), pretty quickly. Probably into a downloadable PCB layout as well (I work for an electronics Retailer... handy sometimes!)
I do have an older copy of Eagle somewhere, but I am using Win7 (If there is a *nix binary, I don't have it), so not sure if it works. But I'll dig it out and see what happens.
But keep in mind that this circuit does not support the trackpoint yetWhat kind of trackpoint support do you plan (most if not all come as a ps/2 device)?
What kind of trackpoint support do you plan (most if not all come as a ps/2 device)?
Thanks. AIKON was the new name. Couldn't remember that. Here's another page in english:
http://www.otd.kr/bbs/board.php?bo_table=aikon_manual&wr_id=10
I say we just slap an 8 core Parallax Propeller in there and call it good =P.
Thanks. AIKON was the new name. Couldn't remember that. Here's another page in english:
http://www.otd.kr/bbs/board.php?bo_table=aikon_manual&wr_id=10
The manual page is not completed yet.
The full circuit is also available, -
http://www.otd.kr/data/file/pj_LIMKB/1964092542_24157b90_Aikon28LIMKB29-SMD_Schematic.PNG
means, you can always build your own with relatively little budget - maybe under $5. (Anyway it needs ISP loader but it costs under 10$ if you try Serial port one. USB version is bit more expensive I think)
Aikon is totally reconfigurable and firmwares are still in progress.
The first thing I noticed was the statement that client software for the keyboard doesn't work on 64-bit Windows. Client software?
Well, it is true that if the keyboard is programmable, it probably is desired to program it from the computer, and this is a special function which requires additional software. But that makes me think the keyboard might not be an exact plug-in replacement for an ordinary USB keyboard.
EDIT: Ah, I see. It's designed to be used with any keyboard, so because different keyboards have different matrices, it has to be programmed to start with.
great! :D
the circuit is surprisingly simple.
edit: no pull-up resistors on this one either, guys. do we really not need them, or are they just being omitted for clarity because the circuit is all digital logic?
Aikon uses internal pull-up registers integrated in AtMega chip.
Super-simple version, Thanks to Aqua.
Client only needs for configure its matrix.(means you need 32-bit XP(or vista) machine for its configuration NOTE : ONLY IN CONFIGURATION STEP)
Ah, these circuits look familiar to me. :) Looks a lot like what is used in Rump or Dulcimer. I guess then there are not too many ways to do this right on an AVR. ;)
It won't work for an M4, though (19x9 matrix, but apparently AIKON offers 18x8 only).
Isn't AIKON going a lot into the direction that Talis had in mind when starting this thread?
Oh, so I couldn't even configure that thing. :(
Do they have source code for download somewhere? I tried downloading their 1.0.4 Beta firmware to have a look, but failed for the following reason:
Huh? Sorry, no Korean here... ;)
They should really translate their site to English to get a broader audience; I've never stumbled across that project while googling for related stuff.
OOPS? I can download it normally.. That message is "Invalid operation".
anyway it's not offered as open source and we bought the V-USB license (so it's not need to be distributed as GPL).
I'm really sorry about that but I'm second author of the its firmware and client and original author doesn't want its source be opened.
I'm still trying to make another version of keyboard controller (PS/2, supports true N-key rollover / or also offered with blocking algorithm, 4-layer selected by dip switch, 17*8 matrix). This will be opened to you guys. I promise.
esc :key11
alt :key18, :key811
shift :key15, :key85
capslock :key14 do
toggle_led 1 # toggle first LED from on to off or vice versa
end
# shortcut for normal acting letter keys
q :key23
w :key24
e :key25
# or you can really remap things
# first create a new layer and key to activate it
create_layer :fn
fn :key31 do
toggle_led_while_down 2
end
# now do some complicated mapping for this key
set :key42 do |key|
# ever seen programmers dvorak?
key = :! # no modifiers
key.shift = :1 # shift key is down
key.shift.alt = :print_screen # shift and alt down
# fn key is down (and we are in the fn layer)
key.fn = :ctrl, :alt, :delete
end
thank you :)
we've been discussing whether the internal pull-up resistors are strong enough. apparently, they are :D
I'd just like to go through the formal process of requirements gathering -> selection -> development to make sure nothing is missed. It may turn out that some other device better meets the requirements, or some trade off between them.
I'd like for anyone with any form of requirement to start adding them on the project page
I'd like for anyone with any form of requirement to start adding them on the project page.Where? I don't see anything special on this mod's wiki page.
Where?
i'll be working from the other end, using a teensy avr dev board and modifying mnemonix code to develop a capacitive-matrix version of the controller
Cool! Did you order the older or the ++ version?
And do you think it will be hard interfacing with a capacitive matrix? What extra parts would you need for this?
i ordered the regular less expensive version, with 22 contacts... and also ordered an rgb led :)
i'm pretty sure it will require an oscillator, to generate an em field on the pads... possibly an op-amp to read the signal back (don't know how strong the signal is yet)... then either use on the on-chip adc or figure out some fast, simple way to measure the field strength.
calibration will be an interesting area :)
This is probably the best place to start : http://www.cypress.com/?docID=2192
My thought is that keyboards lend themselves naturally to an event-based model. You call each key an 'event' and define an action to be executed when that event happens. The actions come from a nice clean API of stuff the keyboard can do. An example:
I gather our little microcontroller isn't going to have enough memory/power to process something like this on the fly, but it would be trivial to generate whatever format was needed from a description like this (including binary formats). Using this single representation, you could generate mappings for various controllers, or xmodmap files, or whatever else.
So anyway, I have no idea if this is helpful or just redundant, since I haven't really seen how existing keyboard programming models work...
As for getting what I generate onto the board, someone suggested putting some kind of microSD reader or something on the controller. That sounds good to me. Create a config like above, generate microcontroller code, put on microSD card, hit a button on bottom of keyboard to make it read new settings... something like that.
Could you make a QIDO-type adapter with this (preferably USB-to-USB these days, but there are of course other options)?
A custom "QICO" would only work when your keyboard doesn't contain an USB hub, otherwise it might be hard but possible to make it with only bit-stuffing.
The USB controller thing is worse I guess. However, even if the current PS/2-to-USB adapters are of varying quality I think I could live with using one. So a PS/2-to-USB piece would do the job. I could then just hook up any USB boards with one of those crappy USB-to-PS/2 thingys and plug that into the converter and it'd work well enough for my uses. I also have a lot of PS/2 boards so in fact it'd be very useful in that respect!
However, couldn't the USB controller inside the USB keyboard handle all the USB device stuff and the converter only intercept the scan codes and let the rest pass through?
Sure, the QIDO people know about Colemak from several people and they may well be on their way to making a QICO... if they think it'll pay off. But did you see the price tag on that QIDO? Making your own might cost as much but then at least I'd have the new knowledge and pride to show for it!
I'm glad to introduce my project - ps2avr.
It's available now at
https://sourceforge.net/projects/ps2avr/
It is hard to tell from the videos (for me it is, at least): which keyboard do you use your firmware with?
Hardware (core):
- capacitive switch support
Is it even clear how a capacitive keyboard normally operates?
I would suggest a simple eeprom (couple of MBs)for the layout storing instead of SD because
1. SD is totally overkill for this purpose
2. AFAIK it has a restrictive license and the developer may have to sign an NDA to get the full spec. Not exactly in the spirit of open source.
uC family decision next.
Is it even clear how a capacitive keyboard normally operates? Not really to me at least. I am under the impression that there is more than one way of doing it...
I would suggest a simple eeprom (couple of MBs)for the layout storing instead of SD because
1. SD is totally overkill for this purpose
2. AFAIK it has a restrictive license and the developer may have to sign an NDA to get the full spec. Not exactly in the spirit of open source.
EDIT: BTW there is no AVR chip other then XMEGA (fairly new series) that has enough I/O pins for a 19x9 matrix + other things if we decide to use V-USB.
There is always the USB AVR series though.
Some do not want the external programming software. Just a text editor to edit the layout, write it to SD and re-insert it into the controller. Also, if you use on-keyboard programming you can remove the SD to backup or edit your layout. So I think the main reason for SD is software-less data exchange.
I'm in EEPROM camp but having both can't hurt. The NDA you mention can collide with the open source requirement but maybe the full spec isn't necessary?
Msiegel is doing some research on this area for his Model F mod. Maybe he has found a good method already?
Some do not want the external programming software. Just a text editor to edit the layout, write it to SD and re-insert it into the controller. Also, if you use on-keyboard programming you can remove the SD to backup or edit your layout. So I think the main reason for SD is software-less data exchange.
The USB AVR series would be great, but they are not available in DIL packages (or are they?). But if there were cheap devboards for these...
Good work, inornate. Is this your own project you mentioned on page 8?
Exactly. anyway AVR-based projects are really hard to support 19*9 matrix without additional hardware supports - because of its number of available pins :( The best available is 19*8. I think.
Maybe we can use MUX to increase its ability to handle more matrix but I'm not sure that additional hardware only for one extra column, is a good solution.
i'm using the $20 Teensy dev board, with ATMEGA32U4 :)
Exactly. anyway AVR-based projects are really hard to support 19*9 matrix without additional hardware supports - because of its number of available pins :( The best available is 19*8. I think.
Maybe we can use MUX to increase its ability to handle more matrix but I'm not sure that additional hardware only for one extra column, is a good solution.
In the end it's a matter of additional cost and PCB space. Alternatively, we could just use a bigger MCU with more I/O pins.
BTW if we need to keep the PCB small we may have to design it modular like arduino and its shields.
With bluetooth, SD(or eeprom), a BIG mcu and all other requested stuff it would probably fail to fit in any of the current keyboard cases :)
Any suggestions for a collaborative spreadsheet? Has Google something here?
As of now, anyone can edit.Didn't realize this would start immediately. :-) Sorry for deleting that word I couldn't remember having written.
Matrix:2030-USB rev:197
/* 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 */
/* 0 */ Row: 7L, --, 7J, 7M, --, --, --, --, 7K, 1N, 5L, 6C, --, 5H, 5F, --, --, --
/* 1 */ Row: 1O, --, --, --, --, 6N, --, --, --, 4G, --, 5K, 5J, 5I, 5E, 5D, 5C, 5B
/* 2 */ Row: 6E, --, 7C, --, --, --, --, --, 6L, 1M, 4M, --, 1H, 4H, 4F, 1E, --, 1A
/* 3 */ Row: 1G, --, --, 3O, --, 6A, --, 6O, 6K, 1K, 2M, 1J, 2N, 2H, 2F, 1C, 1B, 2A
/* 4 */ Row: --, --, --, --, 6J, --, 4N, --, 5O, 5M, 4L, 4K, 4J, 4I, 4E, 4D, 4C, 4B
/* 5 */ Row: --, --, --, --, 7A, 1F, --, 7O, 6M, 1L, 2L, 2K, 2J, 2I, 2E, 2D, 2C, 2B
/* 6 */ Row: --, 7B, --, --, 6D, --, 4A, --, 2O, 2G, 3M, 1I, 3N, 3H, 3F, 1D, 4O, 3A
/* 7 */ Row: --, --, --, --, --, --, --, --, 6B, --, 3L, 3K, 3J, 3I, 3E, 3D, 3C, 3B
KeyMap:US base:Common default rev:205
/* Row 3 */
Key:2A Map:`_and_~ tl:"~" bl:"`"
Key:2B Map:1_and_! tl:"!" bl:"1"
Key:2C Map:2_and_@ tl:"@" bl:"2"
Key:2D Map:3_and_# tl:"#" bl:"3"
Key:2E Map:4_and_$ tl:"$" bl:"4"
Key:2F Map:5_and_% tl:"%" bl:"5"
Key:2H Map:6_and_^ tl:"^" bl:"6"
Key:2I Map:7_and_& tl:"&" bl:"7"
Key:2J Map:8_and_* tl:"*" bl:"8"
Key:2K Map:9_and_( tl:"(" bl:"9"
Key:2L Map:0_and_) tl:")" bl:"0"
Key:2M Map:-_and_Underscore tl:"__" bl:"-"
Key:2N Map:=_and_+ tl:"+" bl:":"
/* Row 3 */
Key:3B Map:q_and_Q tl:"Q"
Key:3C Map:w_and_W tl:"W"
Key:3D Map:e_and_E tl:"E"
Key:3E Map:r_and_R tl:"R"
Key:3F Map:t_and_T tl:"T"
Key:3H Map:y_and_Y tl:"Y"
Key:3I Map:u_and_U tl:"U"
Key:3J Map:i_and_I tl:"I"
Key:3K Map:o_and_O tl:"O"
Key:3L Map:p_and_P tl:"P"
Key:3M Map:[_and_{ tl:"{" bl:"["
Key:3N Map:]_and_} tl:"}" bl:"]"
/* Row 4 */
Key:4B Map:a_and_A tl:"A"
Key:4C Map:s_and_S tl:"S"
Key:4D Map:d_and_D tl:"D"
Key:4E Map:f_and_F tl:"F"
Key:4F Map:g_and_G tl:"G"
Key:4H Map:h_and_H tl:"H"
Key:4I Map:j_and_J tl:"J"
Key:4J Map:k_and_K tl:"K"
Key:4K Map:l_and_L tl:"L"
Key:4L Map:;_and_\: tl:":" bl:";"
Key:4M Map:\'_and_\" tl:"\"" bl:"'"
/* Row 5 */
Key:5B Map:z_and_Z tl:"Z"
Key:5C Map:x_and_X tl:"X"
Key:5D Map:c_and_C tl:"C"
Key:5E Map:v_and_V tl:"V"
Key:5F Map:b_and_B tl:"B"
Key:5H Map:n_and_N tl:"N"
Key:5I Map:m_and_M tl:"M"
Key:5J Map:,_and_\< tl:"<" bl:","
Key:5K Map:._and_\> tl:">" bl:"."
Key:5L Map:/_and_? tl:"?" bl:"/"
Key:5M Map:\_and_| tl:"|" bl:"\\"
KeyMap:pDV base:US rev:57
/* Row 2 */
Key:2A Map:4_and_$ bl:"$"
Map:`_and_~ tl:"~"
Key:2B Map:7_and_& bl:"&"
Map:5_and_% tl:"%"
Key:2C Map:[_and_{ bl:"["
Map:7_and_& tl:"7"
Key:2D Map:[_and_{ bl:"{"
Map:5_and_% tl:"5"
Key:2E Map:]_and_} bl:"}"
Map:3_and_# tl:"3"
Key:2F Map:9_and_( bl:"("
Map:1_and_! tl:"1"
Key:2H Map:=_and_+ bl:"=
Map:9_and_( tl:"9"
Key:2I Map:8_and_* bl:"*"
Map:0_and_) tl:"0"
Key:2J Map:0_and_) bl:")"
Map:2_and_@ tl:"2"
Key:2K Map:=_and_+ bl:"+"
Map:4_and_$ tl:"4"
Key:2L Map:]_and_} bl:]"
Map:6_and_^ tl:"6"
Key:2M Map:1_and_! bl:"!"
Map:8_and_* tl:"8"
Key:2N Map:3_and_# bl:"#"
Map:`_and_~ tl:"'"
/* Row 3 */
Key:3B Map:;_and_\: tl:":" bl:";"
Key:3C Map:,_and_\< tl:"<" bl:","
Key:3D Map:._and_\> tl:">" bl:"."
Key:3E Map:p_and_P tl:"P"
Key:3F Map:y_and_Y tl:"Y"
Key:3H Map:f_and_F tl:"F"
Key:3I Map:g_and_G tl:"G"
Key:3J Map:c_and_C tl:"C"
Key:3K Map:r_and_R tl:"R"
Key:3L Map:l_and_L tl:"L"
Key:3M Map:/_and_? tl:"?" bl:"/"
Key:3N Map:2_and_@ tl:"@"
Map:6_and_^ bl:"^"
/* Row 4 */
Key:4C Map:o_and_O tl:"O"
Key:4D Map:e_and_E tl:"E"
Key:4E Map:u_and_U tl:"U"
Key:4F Map:i_and_I tl:"I"
Key:4H Map:d_and_D tl:"D"
Key:4I Map:h_and_H tl:"H"
Key:4J Map:t_and_T tl:"T"
Key:4K Map:n_and_N tl:"N"
Key:4L Map:s_and_S tl:"S"
Key:4M Map:-_and_Underscore tl:"__" bl:"-"
/* Row 5 */
Key:5B Map:\'_and_\" tl:"\"" bl:"\'"
Key:5C Map:q_and_Q tl:"Q"
Key:5D Map:j_and_J tl:"J"
Key:5E Map:k_and_K tl:"K"
Key:5F Map:x_and_X tl:"X"
Key:5H Map:b_and_B tl:"B"
Key:5J Map:w_and_W tl:"W"
Key:5K Map:v_and_V tl:"V"
Key:5L Map:z_and_Z tl:"Z"
Thanks.
OK, who at Geekhack is gonna go 2nd? I'd volunteer but I'm in the 25% of the Geekhack population that isn't in IT. I don't even have a beard.Show Image(http://www.douglasderda.com/blog/wp-content/uploads/2008/12/achristmasstory.jpg)
Interesting...
Some site or wiki page showing the schematics plus the link to the firmware code? Or update the first page :)
Also...
Aren't most USB adapters sucky? I mean about unable to push several keys at once.
Anyway, it IBM keyboards are 2kro. It could be nice to replace the original controller by a N-key rollover capable (http://geekhack.org/showwiki.php?title=Do+I+need+N-key+rollover) one.
Ok, I just finished reading through all the posts in this thread. Maybe should have done that _before_ I posted. ;)
I know I'm late to the game, but I have to say... Mnemonix, awesome job with your controller board and firmware! If I had access to this a while ago, I probably would have never decided to try to do it myself. I'm also very excited about the Teensy++. With that, I see no need to build my own controller board.
Mnemonix, there's a lot of overlap between our projects. I would like to borrow some of your ideas for my firmware, if you don't have any objections. For example, I have been planning to add some method of programming the keyboard without re-flashing the firmware, but I wasn't sure how to go about it. Looks like you have that feature already.
It seems from reading your posts that you have a lot of experience with this kind of development. I'd like to pick your brain on a few things, as this is my first foray into MCU development. I have a lot of ideas - would you consider collaborating? Or have you moved on from this project?
Anyway, it IBM keyboards are 2kro. It could be nice to replace the original controller by a N-key rollover capable (http://geekhack.org/showwiki.php?title=Do+I+need+N-key+rollover) one.Forget about it. You need to alter the matrix before you can use an NKRO controller, something which isn't possible seeing how the matrix is printed on non-sticky mylar sheets.
I haven't moved from the project, but I have less time to work on it -- and it is working for me already anyway, so there's not much left to do from my perspective.
Weren't you originally wishing to implement trackpoint/trackball support?
Your IBM M4-1 has one so I hope I didn't just miss mention of support.
Thank you for sharing your kbupgrade by the way. :)
chimera15,
You can find my source code at http://github.com/humblehacker/keyboard. If you're not familiar with git, you can download a tarball or zipfile from http://github.com/humblehacker/keyboard/downloads. Choose the one labeled 'teensy-test.'
chimera15,
If you want to try to use my firmware, I'll be happy to help you get it going. I do have it compiled and running on my Teensy++ 2.0. What keyboard do you have in mind for it?
You need a C compiler to compile it - avr-gcc to be exact. There are different packages for each OS. WinAVR (http://winavr.sourceforge.net) for Windows and CrossPack (http://www.obdev.at/products/crosspack/index.html) for Mac. You'll have to use your favorite package manager to install avr-gcc on Linux.
You can find my source code at http://github.com/humblehacker/keyboard. If you're not familiar with git, you can download a tarball or zipfile from http://github.com/humblehacker/keyboard/downloads. Choose the one labeled 'teensy-test.'
I'm going to try to build a scratchbuild with it, with this layout:
http://geekhack.org/showwiki.php?title=Island:10454 (http://geekhack.org/showwiki.php?title=Island:10454)
Is it possible to create the two function keys like I describe with this programming?
I'm installing winavr, is that all I need?
Alright, I've installed winavr, and downloaded the zip file.....now what. lol
I guess this project is dead -- tho I really hope there are some guys out there working on it.
But I'd be happy to be part of a restart of this project.
Could you tell some more details about the controller, hardware specifically?
I already have a working codebase for AVR with a USB HID nkro stack.
I can release it as open-source if necessary. I don't have much time to end this project, so if it can help, let me know.