Author Topic: Making a cheap Model M USB controller  (Read 101111 times)

0 Members and 1 Guest are viewing this topic.

Offline MarkWilliamson

  • Posts: 26
UK supplier for edge connectors
« Reply #200 on: Sat, 03 April 2010, 13:03:42 »
Leotronics looks promising but I don't know what quantities they sell in, I'll send an e-mail: http://www.leotronics.co.uk/template2.asp?id=19

These in particular look about right:
http://www.leotronics.co.uk/196_2604_SERIES..asp?id=19

Offline InSanCen

  • Posts: 560
Making a cheap Model M USB controller
« Reply #201 on: Sat, 03 April 2010, 14:53:44 »
Quote from: MarkWilliamson;169257
Leotronics looks promising but I don't know what quantities they sell in, I'll send an e-mail: http://www.leotronics.co.uk/template2.asp?id=19

These in particular look about right:
http://www.leotronics.co.uk/196_2604_SERIES..asp?id=19


I will be finding out on Tuesday.
Currently Using :- IBM M13 1996, Black :
Currently Own :- 1391406 1989 & 1990 : AT Model F 1985 : Boscom 122 (Black) : G80-3000 : G80-1800 (x2) : Wang 724 : G81-8000LPBGB (Card Reader, MY) : Unitek : AT102W : TVS Gold :
Project\'s :- Wang 724 Pink-->White Clicky : USB Model M : IBM LPFK :
Pointing stuff :- Logitech MX-518 : I-One Lynx R-15 Trackball : M13 Nipple : Microsoft Basic Optical\'s
:

Offline MarkWilliamson

  • Posts: 26
Making a cheap Model M USB controller
« Reply #202 on: Tue, 06 April 2010, 09:56:24 »
Quote from: InSanCen;169287
I will be finding out on Tuesday.


I got a nice response - but not what I wanted - from them:

"Many thanks for your enquiry.

I am sorry to say that our minimum order quantities on FFC connectors would
be in the region of 500 pcs.

Have you tried Farnell or CP electronics.."

So not particularly helpful - I think 500 is probably more than I need at this stage ;-)  Don't really want to destroy my old controller but maybe I'd have to; at least this implies that reasonably small production runs would be feasible in the future although it's possibly still more than your friend in manufacturing would want.

I think I'd looked up Farnell and not managed to find the part but I had not tried CP electronics so maybe I'll have more luck there ...

Offline Specter_57

  • Posts: 143
Of possible interest...ATMega Product Guide
« Reply #203 on: Tue, 06 April 2010, 19:24:58 »
..

As we all know, this project uses an ATmega32 microcontroller, although it is possible to use others....

And so, in case you are considering using another related controller for reasons of cost, number of I/O pins, physical package, etc...this guide may be of interest to the readers here....

From the Atmel page, the "AVR and AVR32 - Quick Reference Guide"
  Introduction of the product range of AVR and AVR32 microcontrollers and application processors

A PDF file, 10MB downloaded

here:
           http://www.atmel.com/dyn/resources/prod_documents/doc4064.pdf

.

...and various adapters for non-parallel devices...

http://www.futurlec.com/SMD_Adapters.shtml


...and  I recently found a few pics of an Avant Steller over on ArsTechnica...and there is a pic of the contoller...it uses an Atmel AT89c52...interesting....


................
Spec_57
« Last Edit: Wed, 07 April 2010, 20:44:41 by Specter_57 »

Offline kishy

  • Posts: 1576
  • Location: Windsor, ON Canada
  • Eye Bee M
    • http://kishy.ca/
Making a cheap Model M USB controller
« Reply #204 on: Wed, 07 April 2010, 21:17:46 »
I've now dumped considerable time and money into this and nothing is working.

Changes since last time:

-Linux (Ubuntu 8.10, running everything with sudo of course. version is a necessity, it would literally take all day to download a current version, had to work with what i have available)
-Whatever version of avrdude was downloaded by apt-get install avrdude
-New programmer
-New AVRs
-Just the basics - connection from programmer, to adapter (pinout verified again), to pins soldered to an IC socket with the AVR in it. correct pins verified.
-Programmed fuses like instructed. Appeared to work, but went extremely fast. No errors given.

Everything beyond that is crap and won't work. Knowing that the fuse setting creates the requirement for an external XTAL, I attached one as needed to the IC socket. No change.

If my new AVR (have two new ones, only touched one) is bricked somehow, I'm going to be extremely annoyed...

Sorry for the tone, I'm just frustrated (hopefully understandably so).
Enthusiast of springs which buckle noisily: my keyboards
Want to learn about the Kishsaver?
kishy.ca

Offline Mnemonix

  • Thread Starter
  • Posts: 163
Making a cheap Model M USB controller
« Reply #205 on: Thu, 08 April 2010, 05:55:39 »
Quote from: kishy;170508
I've now dumped considerable time and money into this and nothing is working.

Changes since last time:

...
-Programmed fuses like instructed. Appeared to work, but went extremely fast. No errors given.


OK, could you try flashing the firmware or boot loader image to a fresh AVR, i.e., without programming the fuses? In factory settings you should not need a crystal for programming, just the six wires on the AVR. Also try option -B 4 or -B 8 if it doesn't work without.

If this is working, but stops working after programming the fuses, I'd suspect a bad/wrong crystal and/or capacitors. You could try hooking up an oscilloscope to see if there's a clean clock signal; that is, if you have access to an oscilloscope.

Quote from: kishy;170508
If my new AVR (have two new ones, only touched one) is bricked somehow, I'm going to be extremely annoyed...

Sorry for the tone, I'm just frustrated (hopefully understandably so).


I understand your frustration, but stopping at this point won't help you, I'm afraid. :/
It's usually possible to de-brick AVRs with a programmer, so don't worry too much.

Offline Specter_57

  • Posts: 143
Making a cheap Model M USB controller
« Reply #206 on: Thu, 08 April 2010, 06:18:52 »
..

Your tone is certainly understandable.  The frustration must be maddening...

I know if that was happening to me...I'd be jumping around and spinning up like this guy over it....and probably would look a lot like him too by now...



.
.
.
...............
Spec_57
.
.
« Last Edit: Thu, 08 April 2010, 14:47:21 by Specter_57 »

Offline kishy

  • Posts: 1576
  • Location: Windsor, ON Canada
  • Eye Bee M
    • http://kishy.ca/
Making a cheap Model M USB controller
« Reply #207 on: Thu, 08 April 2010, 21:23:05 »
Thank you mnemonix for putting my head back on straight.

[strike]Successful flashes using the new untouched AVR, without touching fuses. Are we suspecting bad XTALs then?[/strike] Maybe not, will update this when I'm sure.

k, got what appears to be a successful flash of boot.hex.

sudo avrdude -B 8 -p m32 -P usb -c usbasp -U flash:w:boot.hex

initialized, ready to accept

progress bar for reading, 100% in 0.01s
signature 0x1e9502
erases, reads file, detects as intel hex
writes flash (32632 bytes), 100% in 29.75s

verifies entirely properly.

now, when i switch the filename out for main.hex, I get something much less fun.

it detects the file as intel hex, but of 4198 bytes...I thought this file was supposed to contain substantially more stuff?

it writes it "100% in 3.00s", attempts to verify, finds an error. first mismatch at 0x0000. "0x0c != 0x00"

then i get warnings about the fuse values changing, apparently.

lfuse supposedly went from e1 to 0
hfuse supposedly went from 99 to 0

I answer no to these because nothing but grief came from answering yes to equivalent questions with the earlier AVRs...it just hangs if you say yes, and I'm playing it safe with this one.
« Last Edit: Thu, 08 April 2010, 21:33:12 by kishy »
Enthusiast of springs which buckle noisily: my keyboards
Want to learn about the Kishsaver?
kishy.ca

Offline Mnemonix

  • Thread Starter
  • Posts: 163
Making a cheap Model M USB controller
« Reply #208 on: Fri, 09 April 2010, 06:03:29 »
Quote from: kishy;170774
progress bar for reading, 100% in 0.01s
signature 0x1e9502
erases, reads file, detects as intel hex
writes flash (32632 bytes), 100% in 29.75s

verifies entirely properly.


Good news so far. :) ~30 seconds is really fast, though, compared with how long it takes with my programmer.

Quote from: kishy;170774
now, when i switch the filename out for main.hex, I get something much less fun.

it detects the file as intel hex, but of 4198 bytes...I thought this file was supposed to contain substantially more stuff?


No, that's OK. The boot loader is rather small, but it's located at the end of the flash memory. Programming is performed serially, starting at the beginning of the memory. So, when writing the boot loader, the whole flash memory must be "skipped" until the boot loader section is reached, and AVRdude reports nearly 32 kB for the size.

The main firmware, however, is located at the beginning of the flash memory, so it will be written more quickly, and AVRdude displays its real size.

Quote from: kishy;170774

it writes it "100% in 3.00s", attempts to verify, finds an error. first mismatch at 0x0000. "0x0c != 0x00"

then i get warnings about the fuse values changing, apparently.

lfuse supposedly went from e1 to 0
hfuse supposedly went from 99 to 0

I answer no to these because nothing but grief came from answering yes to equivalent questions with the earlier AVRs...it just hangs if you say yes, and I'm playing it safe with this one.


Alright, that's odd. Here is a list of other values you could try with option -B. For instance, you could try -B 1600 for some really slow timings. Try increasing the speed successively if writing main.hex with -B 1600 works.

And the fuses should never change just by writing to the flash memory... Strange.

Offline kishy

  • Posts: 1576
  • Location: Windsor, ON Canada
  • Eye Bee M
    • http://kishy.ca/
Making a cheap Model M USB controller
« Reply #209 on: Sat, 10 April 2010, 14:41:21 »
Same results using value of 1600 for -B, but it did take longer (though it still claims 3.00s).

Same stuff about changing back the fuses. Still saying no to these.

Retrying with boot.hex, same results, but it took longer. Claimed 29.79s...

Why is it telling me it's taking the same time when it clearly isn't?

Without meaning to suggest any incompetence on your part mnemonix can you please 100% verify that the fuse values you provided are correct? I get that initialization failed, rc=-1 thing with the chips that I attempted to set the fuses on. I'm thinking either bad fuse settings or bad crystals or good crystals that don't correspond to the needs the fuse settings create.
Enthusiast of springs which buckle noisily: my keyboards
Want to learn about the Kishsaver?
kishy.ca

Offline Mnemonix

  • Thread Starter
  • Posts: 163
Making a cheap Model M USB controller
« Reply #210 on: Sun, 11 April 2010, 13:53:40 »
Quote from: kishy;171233
Same results using value of 1600 for -B, but it did take longer (though it still claims 3.00s).

Same stuff about changing back the fuses. Still saying no to these.

Retrying with boot.hex, same results, but it took longer. Claimed 29.79s...

Why is it telling me it's taking the same time when it clearly isn't?

Without meaning to suggest any incompetence on your part mnemonix can you please 100% verify that the fuse values you provided are correct? I get that initialization failed, rc=-1 thing with the chips that I attempted to set the fuses on. I'm thinking either bad fuse settings or bad crystals or good crystals that don't correspond to the needs the fuse settings create.


Checked it again...

This is the command that I am using to program the fuses on my test ATmega32 (followed by the output):
Code: [Select]
$ avrdude -p atmega32 -c usbasp -U lfuse:w:0x1f:m -U hfuse:w:0xd2:m
avrdude: warning: cannot set sck period. please check for usbasp firmware update.
avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.02s

avrdude: Device signature = 0x1e9502
avrdude: reading input file "0x1f"
avrdude: writing lfuse (1 bytes):

Writing | ################################################## | 100% 0.01s

avrdude: 1 bytes of lfuse written
avrdude: verifying lfuse memory against 0x1f:
avrdude: load data lfuse data from input file 0x1f:
avrdude: input file 0x1f contains 1 bytes
avrdude: reading on-chip lfuse data:

Reading | ################################################## | 100% 0.01s

avrdude: verifying ...
avrdude: 1 bytes of lfuse verified
avrdude: reading input file "0xd2"
avrdude: writing hfuse (1 bytes):

Writing | ################################################## | 100% 0.01s

avrdude: 1 bytes of hfuse written
avrdude: verifying hfuse memory against 0xd2:
avrdude: load data hfuse data from input file 0xd2:
avrdude: input file 0xd2 contains 1 bytes
avrdude: reading on-chip hfuse data:

Reading | ################################################## | 100% 0.01s

avrdude: verifying ...
avrdude: 1 bytes of hfuse verified

avrdude: safemode: Fuses OK

avrdude done.  Thank you.


I can read back their values using this command:
Code: [Select]
$ avrdude -p atmega32 -c usbasp -U lfuse:r:-:h -U hfuse:r:-:h -U lock:r:-:h 2>/dev/null

Fuses after flashing boot.hex and main.hex:
Code: [Select]
lfuse 0x1f
hfuse 0xd2
lock  0x3f


Fuses after locking:
Code: [Select]
lfuse 0x1f
hfuse 0xd2
lock  0x2f


This is what I see when writing boot.hex:
Code: [Select]

$ avrdude -p atmega32 -c usbasp -U flash:w:boot.hex
avrdude: warning: cannot set sck period. please check for usbasp firmware update.
avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.02s

avrdude: Device signature = 0x1e9502
avrdude: NOTE: FLASH memory has been specified, an erase cycle will be performed
         To disable this feature, specify the -D option.
avrdude: erasing chip
avrdude: warning: cannot set sck period. please check for usbasp firmware update.
avrdude: reading input file "boot.hex"
avrdude: input file boot.hex auto detected as Intel Hex
avrdude: writing flash (32632 bytes):

Writing | ################################################## | 100% 249.62s

avrdude: 32632 bytes of flash written
avrdude: verifying flash memory against boot.hex:
avrdude: load data flash data from input file boot.hex:
avrdude: input file boot.hex auto detected as Intel Hex
avrdude: input file boot.hex contains 32632 bytes
avrdude: reading on-chip flash data:

Reading | ################################################## | 100% 194.91s

avrdude: verifying ...
avrdude: 32632 bytes of flash verified

avrdude: safemode: Fuses OK

avrdude done.  Thank you.


And for main.hex:
Code: [Select]
$ avrdude -p atmega32 -c usbasp -U flash:w:main.hex
avrdude: warning: cannot set sck period. please check for usbasp firmware update.
avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.02s

avrdude: Device signature = 0x1e9502
avrdude: NOTE: FLASH memory has been specified, an erase cycle will be performed
         To disable this feature, specify the -D option.
avrdude: erasing chip
avrdude: warning: cannot set sck period. please check for usbasp firmware update.
avrdude: reading input file "main.hex"
avrdude: input file main.hex auto detected as Intel Hex
avrdude: writing flash (5196 bytes):

Writing | ################################################## | 100% 39.72s

avrdude: 5196 bytes of flash written
avrdude: verifying flash memory against main.hex:
avrdude: load data flash data from input file main.hex:
avrdude: input file main.hex auto detected as Intel Hex
avrdude: input file main.hex contains 5196 bytes
avrdude: reading on-chip flash data:

Reading | ################################################## | 100% 31.07s

avrdude: verifying ...
avrdude: 5196 bytes of flash verified

avrdude: safemode: Fuses OK

avrdude done.  Thank you.


So everything is going rather slow. Playing around with option -B has no effect whatsoever, except for a message that the SCK frequency is being set (followed by a warning that this didn't succeed). It always takes the same time to write the images, no matter what values for -B I am setting. Time is displayed correctly, too.

Now, here is what I get when I'm trying to write to that ATmega32 with the crystal removed from the circuit:
Code: [Select]

avrdude: warning: cannot set sck period. please check for usbasp firmware update.
avrdude: error: programm enable: target doesn't answer. 1
avrdude: initialization failed, rc=-1
         Double check connections and try again, or use -F to override
         this check.


avrdude done.  Thank you.


Fails because the AVR has been configured to use an external crystal. You know this message already, so a bad crystal or wrong/bad capacitors are possible.
Are you sure that you've received 22 pF capacitors (not 22 nF)?

Now trying with a fresh ATmega16, never touched before, and without a crystal. The circuit consists of the AVR, the programmer, and the six wires going from the AVR into my programmer, nothing else. Reading the fuses works:
Code: [Select]
$ avrdude -p atmega16 -c usbasp -U lfuse:r:-:h -U hfuse:r:-:h -U lock:r:-:h
avrdude: warning: cannot set sck period. please check for usbasp firmware update.
avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.02s

avrdude: Device signature = 0x1e9403
avrdude: reading lfuse memory:

Reading | ################################################## | 100% 0.01s

avrdude: writing output file ""
0xe1
avrdude: reading hfuse memory:

Reading | ################################################## | 100% 0.01s

avrdude: writing output file ""
0x99
avrdude: reading lock memory:

Reading | ################################################## | 100% 0.01s

avrdude: writing output file ""
0x3f

avrdude: safemode: Fuses OK

avrdude done.  Thank you.


So, factory settings of an ATmega16 are
Code: [Select]
lfuse 0xe1
hfuse 0x99
lock  0x3f


Writing the boot loader and firmware images succeeds, too:
Code: [Select]
$ avrdude -p atmega16 -c usbasp -U flash:w:boot.hex
avrdude: warning: cannot set sck period. please check for usbasp firmware update.
avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.02s

avrdude: Device signature = 0x1e9403
avrdude: NOTE: FLASH memory has been specified, an erase cycle will be performed
         To disable this feature, specify the -D option.
avrdude: erasing chip
avrdude: warning: cannot set sck period. please check for usbasp firmware update.
avrdude: reading input file "boot.hex"
avrdude: input file boot.hex auto detected as Intel Hex
avrdude: writing flash (16248 bytes):

Writing | ################################################## | 100% 122.15s

avrdude: 16248 bytes of flash written
avrdude: verifying flash memory against boot.hex:
avrdude: load data flash data from input file boot.hex:
avrdude: input file boot.hex auto detected as Intel Hex
avrdude: input file boot.hex contains 16248 bytes
avrdude: reading on-chip flash data:

Reading | ################################################## | 100% 97.05s

avrdude: verifying ...
avrdude: 16248 bytes of flash verified

avrdude: safemode: Fuses OK

avrdude done.  Thank you.


Code: [Select]
$ avrdude -p atmega16 -c usbasp -U flash:w:main.hex
avrdude: warning: cannot set sck period. please check for usbasp firmware update.
avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.02s

avrdude: Device signature = 0x1e9403
avrdude: NOTE: FLASH memory has been specified, an erase cycle will be performed
         To disable this feature, specify the -D option.
avrdude: erasing chip
avrdude: warning: cannot set sck period. please check for usbasp firmware update.
avrdude: reading input file "main.hex"
avrdude: input file main.hex auto detected as Intel Hex
avrdude: writing flash (5196 bytes):

Writing | ################################################## | 100% 39.18s

avrdude: 5196 bytes of flash written
avrdude: verifying flash memory against main.hex:
avrdude: load data flash data from input file main.hex:
avrdude: input file main.hex auto detected as Intel Hex
avrdude: input file main.hex contains 5196 bytes
avrdude: reading on-chip flash data:

Reading | ################################################## | 100% 31.09s

avrdude: verifying ...
avrdude: 5196 bytes of flash verified

avrdude: safemode: Fuses OK

avrdude done.  Thank you.



I really can't see why your programmer fails to write the main.hex image to the AVR that still has its fuses in default settings. :(

I'd now try writing main.hex using different values for -B so to set the SCK frequency to the various values mentioned here. Let's hope there is one that works for you.

Offline Hydron

  • Posts: 15
Making a cheap Model M USB controller
« Reply #211 on: Fri, 21 May 2010, 08:53:36 »
Thought I'd add to this discussion as my introductory post.

I found geekhack while searching for ideas for modding a Model M to bluetooth, and decided to have a go at making a USB version after seeing that someone had done all the hard work already (software isn't my specialty, though I get by).

Without further ado, here is my completed effort:


And if a crystal and some headers is a bit boring, here is a shot of the brains:


As you can see I've avoided through hole parts as much as possible - I hate perfboard, drilling holes and mucking about bending/cutting component leads, so SMD was the way to go.  The micro is actually a atmega162 as it was easier to get, and the A and C ports are swapped from the defaults to avoid crossing wires - this required some software changes which I'll get to later.

The PCB is my first ever effort at home etching - I'm pretty happy at how it turned out, even given the slight layer missalignment, fingerprints and soldering job done at 2am.  I used the toner transfer from photo paper method and ammonium persulphate etchant.  Probably the hardest thing was drilling holes well with a crappy drill - another reason for SMD where possible.

As for software, the first change was to the configure script to add the definition and correct fuses for the atmega162. The next thing was a changed bit name in the watchdog timer register - the name changes between the 16 and the 162 yet the function is essentially identical. The final and most irritating change was to the bootloadHID code in order to make it fit in the 162. For some reason the boot code compiles slightly larger on the 162 than the 16, just enough to tip it over the 2kB barrier and stop it from working. Thankfully there is an option in the bootloadHID code to shave a few bytes from the code by disabling use of the -r (auto reset) option on the HID programmer, and this took it under 2kB, albeit after a bit of cursing before i found the option.
When i get a chance I'll put these changes together and submit them back to the author so he/she can impliment them as they want.

As for the initial programmer, I'm using a very cheap and nasty cable which connects the programming pins to the parallel port via some protection resistors (these would have been on the board if i'd remembered). I've used this method a bit in the past and it seems to work fine, albeit slowly. Info here: http://www.bsdhome.com/avrdude/. Programmer type for avrdude is "bsd".

I'm happy to share the design/code changes if anyone is interested in building this - the board is done in altium (protel) as this is what i use at work, but the artwork as a PDF is usable by anyone if they want to do the toner transfer thing.

A bit of background, I'm an electrical engineer in New Zealand and do a bit of PCB design in my day job, though normally of much more complicated boards and with the benefit of professional manufacture.
I've managed to acquire a few IBM boards cheaply via auction, namely:
3 good 1391401s
1 1391401 with missing keys
1 UK model M with missing keys (the same keys as the other one :( )
1 new-in-box fixed cord lexmark model m (this was my first and the only one i've payed more than $2-10 for)
1 model M2 (working, this is apparently rare)
and finally a model F i rescued from getting thrown out.

The 1391401s (one with keys from the lexmark) are the only ones that get used, UK layout is weird and the F drops too many keys. Alas, it seems impossible to find any m13 black boards down in this part of the world, which is what i really want.

And finally to whet some appetites, I'm working on a proper bluetooth model M, and am fairly confident I can make it work. This isnt a hack with usb -> bluetooth converters or anything (though hackish in other ways), and should be very low power, but it may take me a while as I'm quite busy at the moment.

Edit: just noticed in the photo that I missed a (non-vital) connection, can anyone see it?
« Last Edit: Fri, 21 May 2010, 09:01:46 by Hydron »

Offline itlnstln

  • Posts: 7048
Making a cheap Model M USB controller
« Reply #212 on: Fri, 21 May 2010, 08:59:57 »
Strong work.  Very well done.

BTW, welcome to Geekhack!


Offline Mnemonix

  • Thread Starter
  • Posts: 163
Making a cheap Model M USB controller
« Reply #213 on: Fri, 21 May 2010, 13:46:47 »
Quote from: Hydron;185290
Thought I'd add to this discussion as my introductory post.


Wow, that's cool! Beautiful board.

Quote from: Hydron;185290
The final and most irritating change was to the bootloadHID code in order to make it fit in the 162. For some reason the boot code compiles slightly larger on the 162 than the 16, just enough to tip it over the 2kB barrier and stop it from working.


Ah, those are the sort of problems that can ruin your whole day. I could add an option to the configure script that enables your workaround.

Quote from: Hydron;185290
When i get a chance I'll put these changes together and submit them back to the author so he/she can impliment them as they want.


I'll happily integrate your changes. :)

If you like, I can also put the PCB design and changed schematic into the source tree so that they are in some "standard place" where people can find them. PDFs would be great. Or just post them here.

Quote from: Hydron;185290
And finally to whet some appetites, I'm working on a proper bluetooth model M, and am fairly confident I can make it work. This isnt a hack with usb -> bluetooth converters or anything (though hackish in other ways), and should be very low power, but it may take me a while as I'm quite busy at the moment.


A Bluetooth Model M would be very cool indeed. I'm looking forward to see that one! Are you going to write the firmware from scratch or will you try to extend the Keyboard Upgrade sources?

And could you tell us which Bluetooth chip will you use? Just curious since I've been working on a Bluetooth project last month...

Offline Hydron

  • Posts: 15
Making a cheap Model M USB controller
« Reply #214 on: Fri, 21 May 2010, 19:15:31 »
Quote from: ripster;185310
I'm too much of a wimp to attempt SMT anything!


I actually find coarse pitch SMD (which this is, it gets MUCH finer) is easier and quicker to solder than through hole. The resistors/capacitors are really easy and you dont need to muck about with bending and cutting legs or anything. The micro is less so, but still took no longer than the DIP would have. One side of it I managed to do first time with no solder bridges between pins, the other sides i got bridges so I flooded them with solder and then sucked it off with solder wick (this is sort of the cheating way to do it - its REALLY easy for a chip like this). With a stereo microscope and a finer iron (which i have at work), i wouldn't have even had to use the wick.

Quote
Wow, that's cool! Beautiful board.


Not very beautiful compared to a professional board, but very beautiful compared to verroboard! (no offence to thread starter)

Quote
If you like, I can also put the PCB design and changed schematic into the source tree so that they are in some "standard place" where people can find them. PDFs would be great. Or just post them here.


I'll tidy them up a bit and do this. May not happen immediately. Might be able to find the digikey part numbers too, for those in the USA.

Quote
A Bluetooth Model M would be very cool indeed. I'm looking forward to see that one! Are you going to write the firmware from scratch or will you try to extend the Keyboard Upgrade sources?

And could you tell us which Bluetooth chip will you use? Just curious since I've been working on a Bluetooth project last month...


I managed to get hold of a keyboard with a BP20422 module locally, also available here: http://russnelson.com/bluetooth-keyboard-controller.html
Some info here: http://bluepacket.net/BluePacket/admin/file/BP20422-PB-003.pdf and here: http://www.bluepacket.net/doc/BP20422.PDF
Problem with this module is the scan matrix is fixed - unless you made your own membrane to put into a model M you're out of luck. Mine has a different matrix than the original blue packet module, so it CAN be changed, but probably only by the manufacturer or with NDAs for the source or something.

My plan is to use a micro to scan the model M matrix and emulate the expected matrix to the bluetooth module when it scans itself. Pretty sure I'll be able to get it going, though it may be tricky with timing and stuff. I've picked a micro with 54 I/O pins and some very low power sleep modes, so hopefully that will work and will give reasonable battery life. Worst case I could grab a FPGA from work and brute force it with programmable logic, but that involves a bunch of work getting a board (the FPGA is 208 pins, you can hand solder one but a decent board is essential). So it is a hackish way of doing it, but short of trying to reverse engineer the EEPROM code on the BP20422 its the only way I can see working. Probably wont use much or any of the existing Keyboard Upgrade code, except maybe the anti ghosting stuff.

If I get one going it probably wont be that cheap, or buildable without an etched PCB. I would however consider building a couple and sending them out, maybe in exchange for black keycaps or something :P. Shipping to/from New Zealand can be damn expensive though :(.

Offline dfj

  • Posts: 171
  • Location: Canada
  • Visit our irc: #geekhack on libera.chat!
Making a cheap Model M USB controller
« Reply #215 on: Sat, 05 June 2010, 19:16:49 »
So, I'm new here, so here is a 'practice' post about something simple you folks have mentioned in this thread a few times. I've had good success with ISA slots, so I'm going to try to describe how I do so in the same way I'm going to describe other, hopefully more useful, topics. :)

An ISA connector works well, though a spacer is needed. For home-brew solutions to this problem they are readily available, and cutting a spacer out of a piece of scrap board is no big deal. Now, fer bulk production, that spacer is a pain - it wants to be a hair thinner than 1/16", (the mylar membrane is doubled at the connector with carbon over the trace as well.)
  I just hacked (hacksaw) an edge connector off an old ISA board, then cleaned it up with a file, testing it repeatedly while thinning it (also with a file) until it went, but still giving a decent firm hold.
  While still at the debugging prototyping stage, the ISA card can be stuffed into some wire-wrap pin strip, then stuck into a breadboard, or an old IDE cable etc...
  Ugh, this is me first post - but pics are warranted. I din' get shots of the original filing down, but it should be clear what I did. I love filing, and will idly do it the way other folks might whittle or watch tv. I think this is straightforward, though... the tolerances are loose, and the bits flexible enough to handle moderate clumsiness:



So - that little whitish toothed spacer is also quite helpful - I found it stuffed into an old AGP slot, but you can make one out of anything. The key thing is that it spaces the two membrane connectors apart the correct amount so that they both will line up with the contacts of the ISA slot. Yes, I used a file to make it. The hook is just so you can get it out again, should you want to.
Now, you can see that I scraped the thickness of the scrap board down a bit. It only required about 0.1 mm, i.e. 1/10th of a mm. But - it really needs it: you don't want yer membrane folding and buckling as you try to force it in.

and here we have two easy ways to connect the back end of an ISA slot to yer prototyping environment, we have it easy here since we are only worried about one side of the pins so this will plug into a solderless breadboard at the other end without thought.
  One side, half of an old chip-holder, for those who prefer their magic smoke kept inside chips. I soldered some normal straight pin-headers (e.g. fer jumpers, etc...) onto it, so I could use whatever ribbon cable I had handy.
  In the other, the wire-wrap headers. both work well, though, with lots of headers you can stuff the ISA slot right into a breadboard and it will hold well. normally, that would suck, but again, we are only using one side at a time so we don't mind shorting across the ISA pins what are directly opposite.

Cool - images din' take too much damage from the 'resizing' process.

Oh, and I made it as stiff as I could get away with, while still being able to get it in. I put both pieces of membrane in using the white spacer to position them, then work the piece of card in which locks them in place. locks is about right - my cat knocked my setup off my desk, and my actual breadboard and a nasty 1394100 keyboard assembly (metal, membranes, keysockets, keys) all ended up dangling on either side of the back support of my chair - hanging by the bloody IDE connectors I was using.
 Breadboard: I screw solderless breadboards, etc... onto it. I can't help it, it's the way I worked when I was a kid. Breadboards are made of wood, keyboards are made of IBM. :)

  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. :)
dfj
Fave Switch manus: IBM, Topre, Matias, ...

Offline timofonic

  • Posts: 59
Making a cheap Model M USB controller
« Reply #216 on: Sat, 05 June 2010, 20:49:01 »
Hello dfj...

Imentioned you on another forum thread, you can look it here. That way more people can look at your amazing effort and then more possibilities to help you too ;)

Offline Mnemonix

  • Thread Starter
  • Posts: 163
Making a cheap Model M USB controller
« Reply #217 on: Mon, 07 June 2010, 15:55:49 »
Quote from: dfj;190019
So, I'm new here, so here is a 'practice' post about something simple you folks have mentioned in this thread a few times. I've had good success with ISA slots, so I'm going to try to describe how I do so in the same way I'm going to describe other, hopefully more useful, topics. :)


Ah, very nice to see this being done. :) Should be of help for those out of luck getting the correct connectors.

Quote from: dfj;190019
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


True, no one forces you to use the HID specs, only the regular PC BIOSes do.

You'd need to design a new protocol to support more keys being sent at once and write OS drivers for this protocol, but you'd still need to implement the HID specs to get the keyboard to work when the driver is not available (in BIOS, during OS installation, rescue CDs). Since the 6-key limit is not a true limitation for most people, the simple protocol is sufficient in most cases, plus it's implemented already everywhere, so that's most probably the reason why none of the keyboard manufacturers are trying to make anything better.

Maybe one day when PS/2 is really, really finally dead, and if there's demand for NKRO ("demand" as in "worth serious amounts of money"), someone might devise a new protocol and declare it the new "standard" HID protocol for keyboards. Today it's cheaper to just build and sell PS/2 keyboards with NKRO and not putting effort into developing something new for USB.

You know all of this already, I guess. :) Just my two cents here.

Quote from: dfj;190019
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...


While I doubt that NKRO with N > 1 plus modifiers is useful for anything (hey, I'm not a gamer! :nerd:), I'm still interested in your project and the techniques you are going to use. Keep us posted, please! :)

Offline JBert

  • Posts: 764
Making a cheap Model M USB controller
« Reply #218 on: Mon, 07 June 2010, 17:07:56 »
Quote from: Mnemonix;190632
A
Quote from: dfj;190019
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

True, no one forces you to use the HID specs, only the regular PC BIOSes do.

You'd need to design a new protocol to support more keys being sent at once and write OS drivers for this protocol, but you'd still need to implement the HID specs to get the keyboard to work when the driver is not available (in BIOS, during OS installation, rescue CDs). Since the 6-key limit is not a true limitation for most people, the simple protocol is sufficient in most cases, plus it's implemented already everywhere, so that's most probably the reason why none of the keyboard manufacturers are trying to make anything better.

Maybe one day when PS/2 is really, really finally dead, and if there's demand for NKRO ("demand" as in "worth serious amounts of money"), someone might devise a new protocol and declare it the new "standard" HID protocol for keyboards. Today it's cheaper to just build and sell PS/2 keyboards with NKRO and not putting effort into developing something new for USB.

You know all of this already, I guess. :) Just my two cents here.
Ehr, as far as I understood the HID specs correctly the device has a "descriptor" of its data format available so the host knows what it can send and receive. The low-level protocol stays the same, it is then up to the host to make sense of the bytes which are sent over the wire. Hence programming a driver is mostly rewriting scan code to virtual key mapping, the only catch is that you have to do it for most OSs.

If you want to support the BIOS, you can still allow the keyboard to be put in legacy mode, it just makes the firmware more complex.
IBM Model F XT + Soarer's USB Converter || Cherry G80-3000/Clears

The storage list:
IBM Model F AT || Cherry G80-3000/Blues || Compaq MX11800 (Cherry brown, bizarre layout) || IBM KB-8923 (model M-style RD) || G81-3010 Hxx || BTC 5100C || G81-3000 Sxx || Atari keyboard (?)


Currently ignored by: nobody?

Disclaimer: we don\'t help you save money on [strike]keyboards[/strike] hardware, rather we make you feel less bad about your expense.
[/SIZE]

Offline Mnemonix

  • Thread Starter
  • Posts: 163
Making a cheap Model M USB controller
« Reply #219 on: Tue, 08 June 2010, 14:29:14 »
Quote from: JBert;190669
Ehr, as far as I understood the HID specs correctly the device has a "descriptor" of its data format available so the host knows what it can send and receive. The low-level protocol stays the same, it is then up to the host to make sense of the bytes which are sent over the wire. Hence programming a driver is mostly rewriting scan code to virtual key mapping, the only catch is that you have to do it for most OSs.

If you want to support the BIOS, you can still allow the keyboard to be put in legacy mode, it just makes the firmware more complex.


Yes, that's what my many words tried to say. :)
Support for more than six keys at a time is possible, but comes at a cost.

Offline dfj

  • Posts: 171
  • Location: Canada
  • Visit our irc: #geekhack on libera.chat!
Making a cheap Model M USB controller
« Reply #220 on: Wed, 09 June 2010, 01:03:00 »
Quote from: Mnemonix;190983
Yes, that's what my many words tried to say. :)
Support for more than six keys at a time is possible, but comes at a cost.


Bah, says the bloke what wrote them krazed makefiles. :)
 
  But, the parent is nearly correct - the HID configuration is parsed by the OS, and then a FA-alike is built to eat the responses/generate requests... but the sweet part is that the USB HID spec describes this in detail, and current linux, OS X, and 'dose versions are all happily parsing the things correctly after boot.
  That is to say - no drivers need to be installed unless you want to support writing to the device in fancier ways.
  So, in the morning handshake for keyboards, the boot protocol is requested, which is fixed, (rumour has it) since in the early days mainboard manufacturers raised a stink about having to write parsers. Once an OS is up, the kb is rebooted, and is not forced to the boot proto, so can freely define its own whacky descriptor. Nice thing, these are not alternate responses, rather entire protocols set at startup, so the response descriptor need not contain that 1 byte 'which' field. This is a big deal when you are trying to keep yer responses inside the 8 byte limit per interrupt.
  Not that it matters until folks start using the kbupgrade for nkro hardware, but the 8 byte limit applies to each interrupt - you can spec a response bigger than 8 bytes, but it will need to span two ints, with a delay of at least 1m per int, if I remember. The HID spec is pretty readable, particularly if you skip past the discriptor protocol higher levels to the keyboard samples. They even have a cute mouse+keyboard combined protocol example.
  Oh wait, folks _have_ requested that for kbupgrade, no? They want to poke the mouse cursor about using some cursor-ish thang?

  mumble, grr... stayed up too late again. kraxy forum.
until,
dfj
Fave Switch manus: IBM, Topre, Matias, ...

Offline Mnemonix

  • Thread Starter
  • Posts: 163
Making a cheap Model M USB controller
« Reply #221 on: Wed, 09 June 2010, 14:13:37 »
Quote from: dfj;191195
Bah, says the bloke what wrote them krazed makefiles. :)


Makefile.am files, if you please. ;)
The Makefiles are generated. No way I would write those by hand.

Quote from: dfj;191195
Not that it matters until folks start using the kbupgrade for nkro hardware, but the 8 byte limit applies to each interrupt - you can spec a response bigger than 8 bytes, but it will need to span two ints, with a delay of at least 1m per int, if I remember.


Yes, low speed USB hubs are required to support at least (only) 8 bytes per interrupt packet, and Keyboard Upgrade keyboards are only low speed USB devices. You could try sending larger packets, I guess, but it may not work. Sending the keyboard status in multiple packets can be slow and is more complicated for the firmware and the OS driver, but it could be done; not by me, however. ;)

Quote from: dfj;191195
The HID spec is pretty readable, particularly if you skip past the discriptor protocol higher levels to the keyboard samples. They even have a cute mouse+keyboard combined protocol example.
  Oh wait, folks _have_ requested that for kbupgrade, no? They want to poke the mouse cursor about using some cursor-ish thang?


I've also requested that feature. :)
The currently dead trackpoint on my M4-1 needs to get a new life.

Offline dfj

  • Posts: 171
  • Location: Canada
  • Visit our irc: #geekhack on libera.chat!
Making a cheap Model M USB controller
« Reply #222 on: Wed, 09 June 2010, 15:53:57 »
Dang, I've got no nipples on any of my boards to test with - I'm not a nipple person.

  I've got the multi-packet deal working on a PS2->USB nkro adapter, but I've been driven mad by the two streams of interrupts - need to grok the locking abilities of the AVR and get my queues to stop borking before I release... unless you grok that crap, in which case this might be sweet, as I've got interrupt-spanning responses working for nkro, sturdy ps2 parsing, and a SPI debug stream... You've got a stack of matrices already, an optional host-side client, and on-the fly remapping working... As it happens we focussed on different stuff, so there isn't anywhere near as much duplication as I feared. That is to say, my own mad research was not wasted. :)

 So - to be clear, you have a live repo, actual users, and you don't vanish into the void for months at a time as much as I do. I am totally offering express my stuff in terms of your design and contribute it as patches for you to make the call on.

(in my PS2 handler I deal with lots of the errors, and request resends relatively well. This was needed because I gave the USB interrupt priority, thus it would periodically nuke the PS2 packets).

  For the rest of us without an over-hot board, and don't care about preserving the 2-10 (min 2, max 10) rollover of an M, the conversion to USB with hardware remapping is pretty sweet all by itself. Also, if the board still works, a converter doesn't require much work - in particular, no need to hack a connector to them bloody membranes. :}
  The cost of that conversion (if V-USB's claims to be able to stabilize the internal oscillator of an ATINY is well-founded) might fall down to under $5, or even lower... visions of someone throwing yer stuff onto an 8-pin with a few resistors and diodes, dead-bug style.... Hey, we can all have our fantasies. ;)
 
off to blink some LEDs,
dfj
Fave Switch manus: IBM, Topre, Matias, ...

Offline dfj

  • Posts: 171
  • Location: Canada
  • Visit our irc: #geekhack on libera.chat!
rough example: tired of alluding to things.
« Reply #223 on: Wed, 09 June 2010, 17:19:32 »
Feel like I'm talking too much, and not 'showing' enough.
 This is the idea of what I did for the large packets - I've gotten these through a few cheaper and more expensive hubs, to a couple of OS Xs, XP and w7... I don't think I've tested much of my recent stuff under linux.  
[ insert excuse here: 'I din' wanna crash me file-server, it still has decent uptime', etc... ]

Not to worry, the C++ in my stuff is 90s-style, I'll convert it to C without effort.

So, courtesy of the v-usb licensed examples what I based these snippits (Thanks Christian!) on:

Code: [Select]

char UsbKeyboardDevice::fct_read_remaining = 0;

uchar usbFunctionRead(uchar *data, uchar len) {
    if(len > UsbKeyboardDevice::fct_read_remaining) {
        len = UsbKeyboardDevice::fct_read_remaining;
    }

    uchar * buffer = UsbKeyboardDevice::reportBuffer;
    buffer += (BUFFER_SIZE - UsbKeyboardDevice::fct_read_remaining);
    for(uchar i=0; i<len; i++) {
        data[i] = buffer[i];
    }
    //currentAddress += len;
    UsbKeyboardDevice::fct_read_remaining -= len;
    return len;
}


Gets yer state across at startup, and then in yer big loop you want to periodically call something like:
Code: [Select]

if (UsbKeyboard.ready()) {
    if (dirty) {
left = UsbKeyboard.sendPartialBuffer();
if (left == 0) {
   dirty = false;
}
    }
    if (usb_queue_count && !dirty) {
        unsigned char key = usb_queue[usb_queue_first];
if(usb_queue_breaks & (1 << usb_queue_first) ) {
   UsbKeyboard.releaseKey(key);
} else {
            UsbKeyboard.pressKey(key);
}
        // race laden queue :(
usb_queue_first++;
usb_queue_first &= USB_QUEUE_MASK;
usb_queue_count--;
dirty = true;
    }
}


where sendPartialBuffer might look like:
Code: [Select]

int sendPartialBuffer() {
    if(spb_remainder == 0) {
spb_remainder = BUFFER_SIZE;
spb_data = reportBuffer;
    }

    if (usbInterruptIsReady()) {
if(spb_remainder > 8) {
   usbSetInterrupt(spb_data, 8);
   spb_data += 8;
   spb_remainder -= 8;
} else {
   usbSetInterrupt(spb_data, spb_remainder);
   spb_data = reportBuffer;
   spb_remainder = 0;
        }
    }
    return spb_remainder;
}



V-USB does the usbSetInterrupt properly, so it doesn't race - at least. ;)


So - I'll need to grok what you are doing with the HID client stuff, so as to figure out which bits will mix and which will fight. My stuff is pure HID, no drivers needed - just stuff it in, wait fer the beeps/blinkenlights and type away.
Fave Switch manus: IBM, Topre, Matias, ...

Offline dfj

  • Posts: 171
  • Location: Canada
  • Visit our irc: #geekhack on libera.chat!
Mebbe breadboarding it first wasn't all that reasonable...
« Reply #224 on: Fri, 11 June 2010, 22:19:07 »
... but, I tested the 1391401 code, then feeling all cocky I threw on the 1390702 code (sans led)... which I am typing on currently. :)
  So - kudos to ze Mnemonix, the 1390702 stuff works, yup.

Yeah, so - I can't say I'm a fan of automake, but once I figured out that my deltas to the config went into config.status, it wasn't so bad...

Ok - I'm not actually using a 1390702, I'm actually using a 1394100, so it has some funky labels on the keycaps - I'm going to have to take a closer look at how you mapped this stuff out by default...

Anyway, Mnem: Thanks fer all the hard work!

oh - and here's the mess that is serving these poor USB packets:



The glowing green LED was the caps while the chip thought it was in a 1391401...

and this is the horror story that I test on.
  I have a strange aversion to zeners, so I use a couple of diodes to step the signal voltage down and a schottky to bring it back. I'm a coder, not an EE, nuff with the mockings. :)

kk, someone wake up kish, I've got a beautiful 1386887 which is crying out fer a perfboard hackjobby...

until,
dfj
Fave Switch manus: IBM, Topre, Matias, ...

Offline kishy

  • Posts: 1576
  • Location: Windsor, ON Canada
  • Eye Bee M
    • http://kishy.ca/
Making a cheap Model M USB controller
« Reply #225 on: Fri, 11 June 2010, 22:29:52 »
Kishy's awake. Click the link at the top right of the screen and come find me.
Enthusiast of springs which buckle noisily: my keyboards
Want to learn about the Kishsaver?
kishy.ca

Offline Specter_57

  • Posts: 143
Making a cheap Model M USB controller
« Reply #226 on: Tue, 29 June 2010, 06:41:38 »
.

Here is an interesting read I stumbled across, a design reference manual from Freescale Semiconductor,...."USB and PS/2 Multimedia Keyboard Interface" with a reference design schematic included, and firmware discussion.

The controller design in this thread is electrically and physically simpler than the one presented in the reference document due to the use of the ATmega device, and is to be preferred.....but the document is worth a read nonetheless, in my opinion.


Take a look here at this PDF:  

http://www.freescale.com/files/microcontrollers/doc/ref_manual/DRM014.pdf

Enjoy

............
Spec_57

Offline sethstorm

  • Posts: 257
Making a cheap Model M USB controller
« Reply #227 on: Wed, 30 June 2010, 11:47:22 »
Quote from: Specter_57;197499
.

Here is an interesting read I stumbled across, a design reference manual from Freescale Semiconductor,...."USB and PS/2 Multimedia Keyboard Interface" with a reference design schematic included, and firmware discussion.

The controller design in this thread is electrically and physically simpler than the one presented in the reference document due to the use of the ATmega device, and is to be preferred.....but the document is worth a read nonetheless, in my opinion.


Take a look here at this PDF:  

http://www.freescale.com/files/microcontrollers/doc/ref_manual/DRM014.pdf

Enjoy

............
Spec_57

Since I have a 8x13 matrix on my Wheelwriter, that only makes things more interesting.  That, and it appears to have room for terminal boards.
« Last Edit: Wed, 30 June 2010, 11:51:41 by sethstorm »
Current:
IBM: Model M: 1391401, 1386887 Terminal 122 Key 
IBM: Model F: 6110668 Terminal 122 key with Trackpoint and M13 blacks
IBM: Specialty: Wheelwriter 5, Boltmodded.  AT F layout, M technology. 
Lexmark/IBM: M13 Black Trackpoint
NCR:HO150-STD1-01-17 Decision Mate V - The other Gray NCR linear.


Offline MarkWilliamson

  • Posts: 26
Making a cheap Model M USB controller
« Reply #228 on: Fri, 05 November 2010, 18:28:02 »
So, whilst noodling around reading about Model Fs, I think I found a thread where Mnemonix acquired one - I wondered if you'd had any success in replacing the controller in that?

I've got a Model M waiting for me to build a new controller but it'd be awesome to be able to USB-ify the F and add some programmability to make up for the lack of keys (e.g. layer switching like the HHKB, say).

Offline kishy

  • Posts: 1576
  • Location: Windsor, ON Canada
  • Eye Bee M
    • http://kishy.ca/
Making a cheap Model M USB controller
« Reply #229 on: Mon, 09 May 2011, 17:11:48 »
Well...it only took...forever...

[ Guests cannot view attachments ] 18031[/ATTACH]

I'm having severe matrix incompatibility problems, but these I'm sure can be fixed easily (appears the old 122s do have a different matrix from the new ones)

The problem seems to have been supply power...hooked the suckers up to my PSU 5V output and it's good to go...thanks to the lovely folks in IRC who put up with frustrated me over the last couple days as I revisited this project.

Also, I dumped that irritating avrdude in favour of this...highly recommended (if you have the usbasp programmer, as I do)
« Last Edit: Mon, 09 May 2011, 17:15:14 by kishy »
Enthusiast of springs which buckle noisily: my keyboards
Want to learn about the Kishsaver?
kishy.ca