You don't need to be able to delineate between 6KRO, 11KRO, 17KRO, and NKRO. They don't matter, because we only have so many fingers. So it's 2KRO, vs. everything else.
(7g compared to a filco or das)
I'm a Model M user.
Let's see I want to make music with my keyboard, or whatever insane application...
Are there some keyboard controller replacement to making it full NKRO?
It's possible to make NKRO over USB with non-standard drivers?
That's what I said.
Except for that technologically superior crap.
Anyway...
Why not change the entire board? I mean having the original mechanical part, but replacing the board with the contacts on it.
That way it's possible to have the best of both worlds, right? :D
Anyway, I don't see why can't be improved. Maybe I don't understand how Model M works...
See the discussion part of this mod as well (http://geekhack.org/showwiki.php?title=Island:6731&do=comments) for why modding a Model M to Nkey is just not gonna happen.
Anyway...
Why not change the entire board? I mean having the original mechanical part, but replacing the board with the contacts on it.
That way it's possible to have the best of both worlds, right? :D
Anyway, I don't see why can't be improved. Maybe I don't understand how Model M works...
Anyway, to introduce myself, I'm working on a gaming mod fer 101 and 122 key IBM Model M keyboards.
The first step is documenting modifying the things to be USB keyboards without dropping simultaneous keypresses. Towards this end I've been working on a ps2 signal->USB converter that can handle either 101 or 122 key M's without promulgating that BS 'max 6 keys plus modifiers' tripe. That only applies to keyboards in boot mode - neither linux nor macs, nor 'dose forces that fer HID devices, the HID USB spec even describes how keyboards are supposed to implement their descriptors once a USB aware OS is booted. /endgripe
The next part, however is dealing with the ghosting inherent to matrix keyboards... much pain here resides. Thus I am currently hacking around with replacing bottom matrices, trying to read resistances to better than 1% while retaining the original matrix, etc...
'Yeah, I'll release my code under an open license, but... it's not cleaned up yet' (how many times have we heard that one before?)
So, I've used a number of the ideas from this site, so I think this is where I'll hang out and feed back my smaller tricks/ideas back into the community.
Wish me luck. :)
Well, you could stick a Microsoft Sidewinder X4 keyboard (http://www.tomsguide.com/us/Microsoft-SideWinder-X4-Keyboard,review-1508-2.html) membrane and controller into a Model M2 buckling spring assembly and get some keys. Still not true N-key but good enough.Show Image(http://media.bestofmicro.com/Microsoft-SideWinder-X4-Gaming-Keyboard,U-X-239577-13.jpg)
Bare in mind that the controller also has to support NKRO, it isn't sufficient to just have diodes.
If you're interested in 122-key buckling spring keyboards, I'd just get a Model F one and do a cable swap to make it PS/2 compatible. That way you have NKRO without modding the circuitry and nicer feeling switches too...
drj, you obviously know your stuff! Go for it!!
The Filco's that are called NKRO are NKRO in all the testing I've done. I don't know how to determine what mode they are in but I would think only mode 2. If there's a quick easy test I can try it.
Whoops, Model M is 2 key rollover. ASX blows it up. I blame it on memory ghosting.
The Microsoft explanation ain't bad. And more importantly you can test key combos NEEDED IN A SPECIFIC GAME (http://www.microsoft.com/appliedsciences/AntiGhostingExplained.mspx).
Not just games. The Model M blocks CAPS+SHIFT+s which is a ***** if like me, you use CAPS as CTRL and have the old CTRL keys mapped to other stuff.
Good thing Emacs doesn't normally use CTRL+shift combinations.
Very interesting. Have you tried using the keypad?
I'm not sure what kind of magic is being used but the keypad works well on my Model M for gaming.
Yup, totally - the ghosting detection can easily not support nkro, even with diodes - mind, they don't have to detect a problem if you are using diodes. I think it depends on the particular logic used. I don't have the tools (or motivation) to reverse engineer the controllers myself - they are almost always write-once, thus better replaced with a general purpose micro than hacked.
AFAIK I was the only one physically building a version of the USB controller for a 122-key but there could have been others who never said so. I ran into stupid problems along the way that really killed my interest in it but I'll be revisiting eventually...
For the record, my firmware can support matrices with diodes. You need to define NO_GHOSTKEY_PREVENTION in order to make the code not detect a potential ghosting problem. I couldn't really test this mode, though, for obvious reasons...
I haven't heard of others trying to build one either. You can still be first! :)
Erm... There's no SHIFT, CTRL or S on my model M's keypad :)
And I don't play games.
Except Global Thermonuclear War.
Anyway, I'm just going to throw some blinkenlights onto it, then mebbe a hex image for a 1391401 to see how it is 'supposed to work'
Then I'll try to build the thing and make sense of yer python? code to make the matrix headers.
So, um, where does it build? It doesn't seem to like cygwin under 'dose, but no-one sane tries to support that particular config anyway. :)
I'm guessing normal linux, /w libusb, perl, python, and the avr chain?
Once you accept that these things don't matter, you are giving manufacturers permission to provide inferior products for no good reason.
I don't think you'll need Perl (anyone still using it? ;) ), but apart from that your list seems to be complete (plus autoconf and automake for building from Git repository (OK, then you'll need Perl, too)). Cygwin may also work (dunno), cross-compiling with MinGW should work as well. The only catch is that two versions of libusb are required because the bootloadHID program (not written by me) needs an ancient version of libusb; it should really be ported some day...
To build, run the configure script with correct arguments (see configure --help) in order to generate the Makefiles, then run "make". If you've cloned the Git repository and didn't download the tarball from Sourceforge, run "autoreconf -i" inside the source directory to build the configure script first. The README.matrix file describes how matrix files are supposed to be written.