Model F hacks

[bladamson]

I think that's totally doable with a 15KHz sample rate! \o/

Edit: And if that's too slow, we can two teensies, each scanning half the keyboard at the same time, talking together via UART maybe. :3

[msiegel]

i just did an experiment:

cut the controller card off of the switch matrix pcb, and get a 2V battery pack.
set multimeter to DC V mode and hold leads together to calibrate: 0V.
on the switch matrix pcb, attach battery pack (-) lead to ground pin.
attach (+) lead to target row pin.
place a hammer on the target switch.
touch (-) lead to target column pin.
(theoretically, target switch pads are now charged to 0Vpress multimeter probes against target column and row pins.
take reading, repeat 3x to verify.

result: no detectable change.

conclusion: either 2V is too low a voltage to couple through the pcb (maybe), or maybe a cheap multimeter can't detect the potential on a capacitor that's in the low pF range (likely).

or... doin it rong XD

:-/ ?

[bladamson]

I think you need to jigger something up with a resistor and maybe an additional capacitor so that it acts like an rc voltage divider, then send a pulse and see what happens on the other end.  If there's enough coupling (switch closed), the pulse at the other end should be able to pass a certain voltage threshold, and then you know to register a keystroke.

I doubt the capacitance of the switches is great enough to discharge enough to deflect your your meter before the charge is gone.  Likely what little charge there is is bleeding off before you can even get the meter probes on it. :<

But.....  I don't remember much of this stuff at all.  It's very likely that I am totally wrong about something here. <_<

Edit:  I think your best bet is to program the AVR to do this for you, and have it print the results of the ADC to the usb monitor or something.

Edit: And I remember reading something somewhere about the AVR pins being protected from overvoltage by schottky diodes, so that "maybe an additional capacitor" comment above was along the lines of decreasing the reactance of the circuit so that the voltage going to the ADC will be great enough to push through the overvoltage diode.

Edit: I have no freaking clue what value resistor and capacitor would be needed to make it work right though. X_x

[msiegel]

i'll make a couple more passes in the simulator, try to line up a few simple tests for the avr (and hopefully "safer" ones

from the manual:

[dec.net]

As stated elsewhere, I have no idea what I'm talking about, but wouldn't it make sense for the purpose of testing to connect the switch output to some amplifying/stabilizing device, such as either a plain transistor or even an op-amp? That way you could perhaps have a look at what's going on at reasonable current levels (as in detectable by multimeters). I'd very much suppose there is something similar going on somewhere in the controller circuits to make those weak tiny signals from the switches actually usable. If you then added in another small capacitance to even out the voltage between pulses, you pretty much have a stable switch voltage, I suppose.

Chris

PS: Also of course, I'd try finding some source of AC for more actual pulses to measure for each key trigger. I'd suppose a signal generated by your soundcard run through an audio amplifier would very much suffice; if you got a high quality card, you can easily generate a 20 or even 48kHz pulse signal with any old free signal generation software; then level it in with your multimeter and the amplifier volume, and there you have your replacement pulse signal, perfect for testing. Just don't forget to disconnect the other speaker while you're at it.

[bladamson]

PS: Also of course, I'd try finding some source of AC for more actual pulses to measure for each key trigger. I'd suppose a signal generated by your soundcard run through an audio amplifier would very much suffice; if you got a high quality card, you can easily generate a 20 or even 48kHz pulse signal with any old free signal generation software; then level it in with your multimeter and the amplifier volume, and there you have your replacement pulse signal, perfect for testing. Just don't forget to disconnect the other speaker while you're at it.

The original electronics are definitely doing it with a 5v digital signal some way.  I think it can be done with a 5v square pulse rather than a sinusoidal signal.

[dec.net]

Yes, I agree, that's what I meant - I suppose you could generate something quite "square-pulsey" with a good quality (read: high sampling frequency) soundcard. A decent pro-sumer sound card can go up to 192KHz Sampling frequency, which leaves 96Khz as the highest useable frequency; there are at least three octaves of frequency headroom for a 20KHz (or what was the frequency that the original controller is using?) squarewave.

Chris

[bladamson]

Go do your SEO somewhere else, Steve-o. -_-'

Edit: Nevermind!  Spammy post was deleted I guess.

[bladamson]

Hey Matt!  Sorry for kinda disappearing.  Work got kinda busy for a while. :3

How are things going with your capacative hackery?

[msiegel]

Hey Matt!  Sorry for kinda disappearing.  Work got kinda busy for a while. :3

How are things going with your capacative hackery?

howdy!

i breadboarded a circuit that's able to read the state of a pair of 10pF capacitors, as a mockup of the pcb pads... but then i tried it with the real pcb and it doesn't work!

testing with the real pcb, even when the hammer is not present the circuit always reads back as if the switch is "closed": 5v goes in, and > 0.85v is seen on the sense line. i suspect the problem is EMI.

so next i'll try adding some shielding. the model F has tons of shielding so i'm guessing it's probably required for this system to work

[dfj]

Bah, sorry, I've been messing around with this problem on and off for the last 6 months... come say hi to us on #geekhack some time, I'm way behind in my posts here....
  I've managed to get it to full nkro on the 122, via clocking the teensy's comparator clock aggressively... but my code is an horror story, and I'm still not rock-solid stable, with occasional phantom makes and breaks - so, not ready for release open source release yet. My goal has been to read the matrix significantly more quickly than the IBM hardware does, and to that end I'm using a somewhat different approach. That said, I'll be more than happy to share what little I've discovered about how IBM is doing things. My approach is intended to reduce the scan-time of the board from IBM's roughly 16ms down to the 3-6ms range, so as to make crossing shots within a frame a little easier when gaming.

thanks,
dfj

[msiegel]

that's outstanding! congratulations

do you double scan each switch to reduce the effects of noise? ibm mentions this technique in the patent; i wasn't sure the teensy's onboard comparator was fast enough to handle the workload...

[hasu]

Though I don't know how fast Realforce does,
I believe that HHKB scans 8x8 matrix every about 15ms(66Hz) from logic analyzer chart.

This is HHKB scanning chart, the time scale is not clear... sorry.



This chart is from:.
http://geekhack.org/showwiki.php?title=Island:12047

[dfj]

Ah, just checked out yer HHKB matrix mods - sweet stuff. Looks like the HHKB pro is doing pretty much the same thing as the F, except using the pair of a TP1684 and a trusty 74HC4051 instead of the proprietary 8273565 that the 8 sense line F's used (there is also a four sense line version used by some IBM keyboards - not all strictly Model F).

      So - a Teensy(++) has a tolerable mux on the ADC lines, but, internally, just one adc - a binary sequential comparator.  If you set the hi-power to the adc bit on the teensy, then you can get the comparator running closer to the main-clock on the thing - though I lose some accuracy when I bring it above a MHz. I'm not at all clear from the datasheets what the max rate actually is, it can be set up to half the main clock-rate, though this is suggested for running at lower rates than 16MHz. Since it loses accuracy on the comp at such rates, (and thus precision on the adc), it's kinda academic how fast one can push it without breaking it.

       I'm still working out the right combination of sample-rates, strobes, offset voltages, actuation thresholds, etc... that will be happy on such hardware. I have a few op-amps lying around - if I can restrict it to readily available ones, then I will be cool with using one, but I kinda want a method that is viable to open-source without requiring folks to buy a stack of weird components. right now I'm getting by with just a mess of resistors and just the teensy for an IC - it would be nice to get this to work, but it is fiddly.
     
Roughly how long is the strobe and how long is the relaxation before the next strobe on the hhkb pro? Also how long after the start of the strobe does the capsense take its test? On my F, the strobe is about 30us, with the relaxation about 60us. IBM does this 8 times per column, though, the '122' key boards have 16 columns. (127 actual key locations and 1 internal test location there is a bit of a gap between strobe groups, so the end result is closer to 15ms rather than the 12 that might be possible if they were packed.
     
So yeah, I'm around - feel free to say if yer on irc, and for the love of $%&*& someone send me a pm next time Hasu posts a cute hax! I don't always remember to come poke around here on the forum enough.

 until,
dfj

[dfj]

Yeah, I'm currently doing a double sense, since I'm not so  stable yet... the IBM F does not seem to actually do this, though... I  think it would add 16 bytes to the RAM image of the controller, on top  of the 8 required to retain the actual current key state, plus 10-16 for the  event buffer. The 8048 only had 64 bytes of ram - space is _tight_. From our probing it is clear that the keys are all scanned in sequence, so the whole matrix would need to be stored as a tentative version... hmm, I suppose the second pass can check as it goes, so that doesn't require a full copy...

  So : the real reason we know the F does not do this, even without looking at the firmware, is that we can bounce a key by flicking it with our finger, and see the make, and then break about 16ms later... hence there was only time for two scans, not four scans.
  See - my other post above/below to hasu - the teensy comp is accurate and fast enough... getting the right threshold set, this is a trick. For folks willing to solder this together, mind, tuning a pot isn't the end of the world. A teensy etc... could run the code to help the geekhacker adjust the pot, presumably.

[JohnElliott]

Yeah, I'm currently doing a double sense, since I'm not so  stable yet... the IBM F does not seem to actually do this, though... I  think it would add 16 bytes to the RAM image of the controller, on top  of the 8 required to retain the actual current key state, plus 10-16 for the  event buffer. The 8048 only had 64 bytes of ram - space is _tight_. From our probing it is clear that the keys are all scanned in sequence, so the whole matrix would need to be stored as a tentative version... hmm, I suppose the second pass can check as it goes, so that doesn't require a full copy...

 
It reads the keys in groups of 8 (so they can fit into a byte). Then, if that byte differs from the corresponding byte in the matrix, it does two further reads of that row. I think. The code starts at 0205h in the microcontroller ROM for the 84-key F, or 024Dh for the 122-key F, if you want to examine it.

(RAM in the 122-key F controller is laid out like this:

Code: [Select]


00-07 registers
08-09 stack, one level only
0A-29 Flags for keys, 2 bits per key. 0 = Make only, 1 = Make/Break, 3=Repeat
2A,2B Used when reading the keyboard
2C-3B Bitmap of pressed keys
3C-3E Buffer of scancodes to send to the host
3F Last scancode transmitted to host

The 84-key Model F drops the key flags, which gives it more space; the second register bank at 18-1F can be used as such, for example, and the output buffer is larger.)

[dfj]

Ah - yer right, confirmed this on yer AT dump: the count to two is on the carry bit tested at 028c. bloody xrl's keep hurting me brain - xrl to test, then xrl again to recover yer value...
  So - this is great: on a possible change, read the column twice to confirm... this is what I will do: see, the question one might ask is, if one has a change, why not just read again to see if it is there? Well - I discovered that every time you hit a key, the hammer coming down often (i.e. unreliably) _generates_ a pulse on that sense line - this pulse is garbage, and just serves to wreck whatever else was reading at the time - since it hits the sense line regardless of strobe. Thus - the first sense is often pure trash, so - two more column probes of only that column are sweet stuff. depending on what yer offset current is like, the mini-pulse from a hammer coming down might disrupt sensing for up to a millisecond. on the F the offset is generated by the sense chip, so I don't rightly know exactly how it is powered... I see the same event when scoping the IBM controller, though the pulse is shorter than on my stuff - presumably they are driving the offset harder.
 
 fun stuff - thanks for pulling them bins! btw - did you do it with a home uC/breadboard, or do you have a fancy programmer for it? Once I remembered thta almost all these chips need to be _verified_ after burning, it became clear that a lot of them will be easily recovered since security and IP idiocy was not a factor at that point.

(I have a 1390131, I want to pull the stuff in case it is dual-mode, and detects XT machines... )

thanks,
dfj

[JohnElliott]

fun stuff - thanks for pulling them bins! btw - did you do it with a home uC/breadboard, or do you have a fancy programmer for it? Once I remembered thta almost all these chips need to be _verified_ after burning, it became clear that a lot of them will be easily recovered since security and IP idiocy was not a factor at that point.

(I have a 1390131, I want to pull the stuff in case it is dual-mode, and detects XT machines... )

I used a Willem programmer with the 8048 adaptor board. I tried it on the XT model F keyboard controller as well, but that just returned zeroes, so I think it may well be protected. The Willem can burn 8048s (though sometimes it takes a couple of tries) but not 8049s, which is a pity, because I still haven't been able to test my 2k terminal-emulation firmware for the 122-key F.

Model Ms use 6805 derivatives rather than 8048s IIRC, which the Willem doesn't appear to include support for. Whether there is a way of reading these controllers electronically, or whether you have to break out the fuming nitric acid, I don't know.

[looserboy]

its possible to do something with  at-8pin-modular plug connector model m keyboard?
change cable possible? - or adapters? for ps2?

[dfj]

The 5-pin AT connector on a Model M? Yeah - a normal AT-PS2 dumb connector should work if you can find one. Will also work if you find a PS/2 cable from another M, but - then you'd have another M.
  Search around on this site, there's likely info to be had if you can't find one, and instead need to make one.
g'luck