Sounds good. It should be just a different Keymap for a 122key then?

The boards will have a complete firmware on them, including a US ANSI map. It's easy enough for him to flash then before placement apparently. I am assuming he has an automated doohickey to do it.

When I said Manual finishing, I meant at time of manufacture. The boards should be ready to plug in and go, assuming a US ANSI layout.

100% of my needed parts are here now.

I'll be playing with laying out parts on the board (the stripboard I have has the copper strips going the 'wrong' direction) and perhaps coming up with photos showing a decent layout for a 122.

Keep in mind that, at least with the original 122-key terminal M design, the controller doesn't mount into a spot on the case...it's screwed onto the metal backplate, so there's some flexibility afforded by that.

That's why I had reservations about going the stripboard route - it being too dependent on layout of the board as well as the wiring.

It's just a matter of component placement. The "wires" still go the same way, the schematic hasn't changed. My controller will be significantly smaller than the Prototype (That is why we have prototype's, make it, see it works, improve it. Without the initial prrof-of-soncept, there isn't a 2nd or 3rd revision etc).

Indeed.  I just dont like splitting up an already-fragile stripboard just for the alignment.  

Now if there was something a bit more reliable than compressed paper-board to solder onto, I'd be less likely to just skip to the finished boards.

Indeed.  I just dont like splitting up an already-fragile stripboard just for the alignment.  

Now if there was something a bit more reliable than compressed paper-board to solder onto, I'd be less likely to just skip to the finished boards.

Fibreglass board.

If Kishy would be so kind as to post a picture...

It's much more substantial than the normal Veroboard. It also doesn't smell.

I'm fine with standard stuff. I built an Amp about 10 years ago on it, and it's still going strong. Hell, my Glass-density analyser for my A Level project (A looooong time ago) is still working perfectly on veroboard (The Final on PCB is still used in a factory today surprisingly enough!)

Yes, what he sent me is awesome stuff...it's almost like plastic in the sense that it's got no smell, texture is smooth, thickness uniform, all that stuff.

I'd be happy to post a photo but I've hacked it apart into two pieces for my two controllers. Had been hoping to clean up the rough edge before showing it off...and ideally also finish the board...but oh well, I will anyway, you can all lawl at my bad construction techniques. Decided to go with 'simple' design for the first, LED design for the second.

I gradually realized more and more that I'd have to run a little wire lead for ALL of the FFC connector pins regardless of what I did, so I just threw em on there with no regard for pin alignment with the AVR socket. I highly recommend nobody do it the same way I have, it's going to be very messy with 28 little jump wires in the finished item.

Show Image

Looking good.  Is there a way to position things so that you can use ribbon cables to wire up the 'cardedge connector' to the ATMEGA?  It would seem a bit easier that way to keep things together.

Looking good.  Is there a way to position things so that you can use ribbon cables to wire up the 'cardedge connector' to the ATMEGA?  It would seem a bit easier that way to keep things together.

Thanks...aside from the burn marks here and there, I think it's not TERRIBLE, just a little amateurish.

Yes, ribbon cables would be feasible, however in a couple segments. Carefully look at the schematics and you'll see not all of the pins are together in continuous blocks. On the overall it'd be possible and a cleaner way to do it, but since I've already prepared all the little jump wires I'll do this one that way. I'm learning from the first build so I can do the second one better.

I took the picture of your controller from #37 and the matrix info posted by Specter_57 as a reference. I've seen that, like on the Model M, the connectors are mounted in opposite directions, but the pins are numbered 20...1, 8...1 from left to right (both, on the controller and on the matrix info). So I used the numbering scheme suggested by the numbers on the controller to write down the matrix definition file.

Looked at original controller again...yes, the silkscreening suggests 20-1 and 8-1. Just gotta hope that means the obvious meaning.

You can check whether or not I messed this bit up by making sure that Left Control is attached to the right-most contacts on the two connectors (corresponding to column 1, row 1) when plugging the matrix sheets to the controller. Similarly, the left-most contacts (column 8, row 20) should go to the Enter key on the numpad. If not, there is some problem...

Alright, so what I'll do is follow the schematic (the later version of simple.pdf) the way I have been to connect those four pins, get some firmware on the bugger and see what happens. Won't be connecting any other wires if those keys don't function right...if they do I may just finish the thing up entirely.

By the way, I took a closer look a Ripster's Boscom matrix images, and it seems like the Boscom matrix is a bit different from the 1390702 one... (or I got confused by all those labyrinthine lines on the pictures)

That could be a problem...though it doesn't make sense why it would change, I did say numerous times we should be ready for possible differences...was really hoping that by saying it I'd eliminate the possibility of it happening though. We'll see what happens I guess.

I've chosen the chip-pin-to-connector assignment so that eight contacts of the 20-pin connector can be attached directly to the pins on the MCU (either rows 20...13 to MCU pins 40...33, or rows 12...5 to MCU pins 29...22). This may or may not be of any help, but at least there are no crossing wires this way.

I had noticed that and thought "AWESOME" but then looked at the size of the stripboard I have and said "DAMNIT". Doing that would have resulted in the 8 pin connector floating in the air beside the stripboard.

BTW the reason the AVR socket is in the middle instead of off to the right is because there will be DIP switches to the right of the socket...DIP switches are 1337, jumpers are for...people who aren't DIPswitchy. Let's just say you can't trust me with the engineering sample order form.

In case the connections are wrong and need to be rearranged, it is easy to juggle rows and columns around in the firmware. The boot loader may need to be fixed separately then, though; but you have a programmer, so that's not a problem.

If fixes are necessary, well, that's the nature of the project I suppose. I'll report back my findings and we can go from there.

Alright, so it's in a state I can program it in, but then I hit a roadblock. AVRDude isn't GUI?!?!

GUI? Fortunately not. How could you ever automate anything with a program that looks like a point-and-click adventure? :wink:

Anyway, here are the generated command lines for programming an ATMEGA32. The first command is used for programming the fuses (chip configuration), the second and third are used for writing the boot loader and main firmware, respectively, and the last command makes the boot loader section read-only.

$ avrdude -p atmega32 -c usbasp -U lfuse:w:0x1f:m -U hfuse:w:0xd2:m
$ avrdude -p atmega32 -c usbasp -U flash:w:boot.hex
$ avrdude -p atmega32 -c usbasp -U flash:w:main.hex
$ avrdude -p atmega32 -c usbasp -U lock:w:0x2f:m
Programming is a quite slow process, so I am usually omitting the third command and use bootloadHID (another command line tool) to flash the main.hex file over the keyboard controller's USB port. You'll need to attach the controller to the rest of the keyboard, however, in order to be able to hold down Escape to activate the boot loader... This is also the way to update the firmware later.

To read out the fuse settings (not required, just for checking if fuses are set up correctly), I use this one:

$ avrdude -p atmega32 -c usbasp -U lfuse:r:-:h -U hfuse:r:-:h -U lock:r:-:h
You may need to pass a different string with the -c option if your programmer is not USBasp compatible. The red stick-like programmer should work with exactly these commands.


I hope it works on Windows, too. I've only ever tested this on Linux. It is probably substantially easier to get everything working from scratch on Linux because the required software is either installed there by default or is just an apt-get away.

Note that it is definitely possible to make a working controller by programming the pre-compiled boot loader and firmware images to the MCU, but that there is no binary version of the kbuptool utility program for Windows at the moment. This means that there is no easy way to upload a key map to the controller on Windows, so only the standard QWERTY map will be usable. Someone will need to build the program for Windows to make the controller fully usable.

Reference to GUI was because I thought I had seen, somewhere in the vast expanses of the internet, a screenshot of a GUI program and a reference to AVRdude together, suggesting the screenshot was of AVRdude. Apparently not.

It is very well possible that someone has written a graphical frontend for AVRdude, but I don't know of any.

OK, now I know of one: Google pointed me at avrdude-gui, but obviously I've never tried it.

When does mass production start? I'd like to pre-order a couple

BTW this thread is blatant discrimination against those of us who are neither hardware nor software savvy.

Let's see what InSanCen can arrange. Seems like there is indeed a market for these controllers.

Is this a request for better documentation?

Board layouts for the Terminal 122 would be fine enough, if only regular keyboard controllers are being pre-made.

When does mass production start? I'd like to pre-order a couple

BTW this thread is blatant discrimination against those of us who are neither hardware nor software savvy.

I am working on a PCB layout. Production will start when he get's a break in his orders. As this is a favour, I cannot ask him to break into profit-making production for this. As soon as they are available, you *will* know about it. I will guinea-pig my '89 board for testing. As an aside, he's loving the loaner M i let him have to evaluate the physical space we are working with. All we need is for him to make an account here... ;-P

Cool, thanks for spending your time on this project! Can't wait to see the result.



Would you care taking the dimensions of the smaller Model M Mini into account, too? There's less space in vertical direction in a Mini, so you'd need to be careful placing big parts not too far from the back of the case. I could take pictures and measure the available space for you.

If you can get me some Dimensions, I will make sure it fits. I will attempt to make sure that regular M and Mini have ready-to-go mounting holes. I will need the Width and height of the available space, and where the mounting holes/posts are located.

OOOOooooo.  Model M Mini PCB - sign me up!

Here's the dimensions.

...Good Pictures and Metric Numbers...

USB Mini Layout would be great for me!  Let me know if you need any other measurements or bigger pics.

Perfect! I can see the only measurement I needed that you didn't include (3rd pic down, centers on mounting posts).

I think we can accomodate that. As long as component placement and traces do not interfere, I should be able to make a drop-in board that will fit in both the M and the Mini. I just need to open an M and see if a board that size can be securely mounted. If it can, the finished product will be the size of the Mini's board. This is assuming that the controller is identical, and will just not use the rows and columns for the Numpad. If these can be left floating, then no additional work is needed. If they need to be tied low, than I think a switch could toggle between M and Mini modes.

I also had a quick chat with the guy who will be making these. Having looked into it, he think's it would be more feasable to do a PCB only run for .1 components. Just sounding out for interest, as he will have spare capacity on that line before he does on lines handling components. We also chatted about timescale. Bad news. Assuming no order cancellations, he's flat-out busy for at least 3 months (PCB only) and 5 months (Full board, assuming he finds a suitable connector for the Membrane to PCB). As I have said previously, the first run will be done at cost to GH members (and only "real" GH members, not someone registering just to get hold of it). Because of this, I will *not* let him break production, he is after all, a friend of mine.

.1 components means 0.1 mm pitch? As long as the 2.54 mm pitch membrane connectors fit in there somehow, why not?

.1", or 2.54mm

Hm, better late than never. How many units would he want to produce?

He is producing, regardless. this is me calling in favours. If viable, he will produce more afterwards. The initial run will be ~100 units.

I hate FPC/FFC connectors.

Can I find a UK source? Can I hell as like. Digikey's UK site carries them, but judging from the shipping total (VAT to be added afterwards too), they are in the US.

Farnell and RS do not carry them either (and I know Maplin do not, as I work there).

On the upside (and someone queried this a while ago but I forgot to check), Maplin do a lucky bag of switches. In them are cherry whites. All the bag's I have checked have 3, but YMMV, it is a lucky bag after all.

I hate FPC/FFC connectors.

I feel your pain.

I've got my engineering samples from German W+P Products. They are asking for a minimum ordering quantity of ~100 per type, so if they are not charging too much for shipping, this could be an option. I don't know the price of the connectors, however, because they didn't tell me... Just sent me some free connectors that I needed.

Once you guys get this working, would it be a big step to wireless bluetooth? I would guess that an internal AA battery or two could supply the current, and some kind of USB to Bluetooth keyboard adapter could also be built in? Those might not exist though, I really have no clue.

I could imagine hacking a Bluetooth USB hub like this one, in the spirit of Ripster's Model M USB hack. Instead of using the Blue Cube to convert from PS/2 to USB, you would use the hub to convert from USB to Bluetooth (either by using the hub as intended, or by hacking it to fit into the keyboard case). Don't know about the power supply, though...

InSanCen, could you include four empty soldering pads to the USB lines on your design? This way one could connect the controller directly to some Bluetooth hub/converter without using USB plugs.

This is VERY frustrating.

I checked my wiring, everything seems correct following the 'simple' schematic. I've retraced it 3 different times and find nothing different from the schematic. However I still get these weird errors.

Now I'm getting this on any command:


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.

Considering that voltage supply may have been the issues, I tried without using the programmer jumper that supplies power. For voltage I tried using a powered USB hub, with no USB connection to computer, plugged into wall. Nothing changed at all regarding errors.

Tried with my second AVR, same crap.

Do we suspect faulty programmer, or what? I told eBay seller I suspected one or both chips may be faulty (to make sure they are aware of it before any deadlines come up) so they're waiting to hear from me if I think it's the chip(s) or not. I would like to know myself...

Did you check for bad solder joints? Sometimes they look good, but make only a bad connection.

Checked with multimeter, everything's got good continuity. Looking at the joints, many look 'cold jointed', but any that had continuity issues were reflowed immediately.

On any command, even when trying to program or read out the fuses? If you've successfully programmed the fuses to the values I've posted here before, then you'll have to make sure that the crystal is hooked up correctly, even for programming. This is because the fuse settings instruct the AVR to use an external oscillator for its clock. The "target doesn't answer" error seems reasonable if there's no clock.

Yeah, any command...but only sometimes!

If I unplug the programmer from the computer I can get it to pretend to behave for one operation, then it starts acting dumb again. Whatever operation I can get it to do fails in some manner or another.

Crystal is hooked up in correct position. Dumb question: there is NO type of "polarity" on a crystal, correct?

At the advice of the seller of the programmer, I've started using -B # switch on the commands to slow it down. The device signature problems went away when I tried 0.1, and it appeared to successfully write the bootloader, but then the content didn't match when it was done. It took around 7-8 seconds to do it so it wasn't an "insta-fail".

So probably not a power problem, but if you have other USB ports, you could give them a try, too.

Have tried the programmer on all 4 of my laptop's USB ports.

When getting alternate power for the ATmega32 being programmed, it's just connected to a powered hub with no USB connection out of the hub...just using it for power. Power at the hub ports is good.

Is the second AVR pristine, i.e., with the fuses still in factory settings? If so, it should respond even with no external oscillator attached. We could rule out a bad crystal then.

Second one does not have fuses programmed.
Apparently, neither does the first. They keep changing themselves back to 0, as avrdude likes to inform me.

Hard to say what's the real problem. Could still be a pure software problem. Did you upgrade to a new version of avrdude already? Also try running avrdude more verbosely (like -vvvvv) to see what's going on. The example in the manual for the programmer sets option "-P usb"; I've never needed that one, but it could be a Windows thing (OTOH, it seemed to work for you w/o -P before).

I can't upgrade to a newer version of avrdude because a newer version doesn't exist compiled and working and including USB support...for Windows.

Regarding -P, apparently "atmega32" is incorrect, BTW. It's "m32". I started making some progress after making that change, but it's back to how it was before. Will try -P usb (you're the second to mention it) on next attempt.

Verbose...if next attempt gives problems, I'll re-do it verbosely and throw the output here.

Did you try Linux instead of Windows? A live CD like the Ubuntu installer should be enough for testing. Avrdude can be installed while running the live Ubuntu system, without touching your harddisks.
No, I don't trust Windows.

Linux...do not want, but will try as a last resort. I don't believe the type of issues showing up here CAN result from an OS incompatibility...the inconsistent nature of the failures and the fact that they change somewhat from attempt to attempt tells me this. A pure OS incompatibility would hang up in the exact same way every time because the OS isn't allowing something to happen...

If you have a breadboard, try setting up a minimal circuit just consisting of the AVR, the crystal oscillator, the three capacitors, and the 10k resistor. Leave out all the USB-related stuff. Then hook up your programmer and try again. If the minimal circuit works, then your bigger circuit must be wrong. Without a breadboard, you could still try this with wires, even if it's crude.

No breadboard, but setting up with wires should be doable. My patience is going out the window however.

There's a reason I dislike open source software such as avrdude. This is the reason.

Not that it doesn't work...that there's no phone number to call and give them a piece of my mind.

I decided to try an erase, since I've read that it's generally needed if you're going to be re-writing the contents of the flash (which didn't seem right, since the entire flash contents seem to be erased before a transfer if avrdude is to be believed, but whatever)

First, we see the non-verbose output:

C:\WinAVR-20100110\bin>avrdude -B 0.1 -p m32 -P usb -c usbasp -e

avrdude: set SCK frequency to 1500000 Hz
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.

Now, we see the verbose output:

C:\WinAVR-20100110\bin>avrdude -B 0.1 -p m32 -P usb -c usbasp -e -vvvv

avrdude: Version 5.10, compiled on Jan 19 2010 at 10:45:23
         Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/
         Copyright (c) 2007-2009 Joerg Wunsch

         System wide configuration file is "C:\WinAVR-20100110\bin\avrdude.conf"


         Using Port                    : usb
         Using Programmer              : usbasp
         Setting bit clk period        : 0.1
avrdude: seen device from vendor ->www.fischl.de<-
avrdude: seen product ->USBasp<-
         AVR Part                      : ATMEGA32
         Chip Erase delay              : 9000 us
         PAGEL                         : PD7
         BS2                           : PA0
         RESET disposition             : dedicated
         RETRY pulse                   : SCK
         serial program mode           : yes
         parallel program mode         : yes
         Timeout                       : 200
         StabDelay                     : 100
         CmdexeDelay                   : 25
         SyncLoops                     : 32
         ByteDelay                     : 0
         PollIndex                     : 3
         PollValue                     : 0x53
         Memory Detail                 :

                                  Block Poll               Page
      Polled
           Memory Type Mode Delay Size  Indx Paged  Size   Size #Pages MinW  Max
W   ReadBack
           ----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ---
-- ---------
           eeprom         4    10    64    0 no       1024    4      0  9000  90
00 0xff 0xff
                                  Block Poll               Page
      Polled
           Memory Type Mode Delay Size  Indx Paged  Size   Size #Pages MinW  Max
W   ReadBack
           ----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ---
-- ---------
           flash         33     6    64    0 yes     32768  128    256  4500  45
00 0xff 0xff
                                  Block Poll               Page
      Polled
           Memory Type Mode Delay Size  Indx Paged  Size   Size #Pages MinW  Max
W   ReadBack
           ----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ---
-- ---------
           lfuse          0     0     0    0 no          1    0      0  2000  20
00 0x00 0x00
                                  Block Poll               Page
      Polled
           Memory Type Mode Delay Size  Indx Paged  Size   Size #Pages MinW  Max
W   ReadBack
           ----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ---
-- ---------
           hfuse          0     0     0    0 no          1    0      0  2000  20
00 0x00 0x00
                                  Block Poll               Page
      Polled
           Memory Type Mode Delay Size  Indx Paged  Size   Size #Pages MinW  Max
W   ReadBack
           ----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ---
-- ---------
           lock           0     0     0    0 no          1    0      0  2000  20
00 0x00 0x00
                                  Block Poll               Page
      Polled
           Memory Type Mode Delay Size  Indx Paged  Size   Size #Pages MinW  Max
W   ReadBack
           ----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ---
-- ---------
           signature      0     0     0    0 no          3    0      0     0
 0 0x00 0x00
                                  Block Poll               Page
      Polled
           Memory Type Mode Delay Size  Indx Paged  Size   Size #Pages MinW  Max
W   ReadBack
           ----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ---
-- ---------
           calibration    0     0     0    0 no          4    0      0     0
 0 0x00 0x00

         Programmer Type : usbasp
         Description     : USBasp, http://www.fischl.de/usbasp/

avrdude: try to set SCK period to 1e-007 s (= 10000000 Hz)
avrdude: set SCK frequency to 1500000 Hz
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.

...and why is the SCK period going to 1500000 Hz if I'm REDUCING the number?!?! Shouldn't it be...you know...going down?

I should add that I have released new firmware images and source tarballs on SourceForge yesterday, now at version 0.3.0.

It's possible to use two function keys now, allowing to quick-switch between the default key map and three alternative key maps.

I also had a quick chat with the guy who will be making these. Having looked into it, he think's it would be more feasable to do a PCB only run for .1 components. Just sounding out for interest, as he will have spare capacity on that line before he does on lines handling components. We also chatted about timescale. Bad news. Assuming no order cancellations, he's flat-out busy for at least 3 months (PCB only) and 5 months (Full board, assuming he finds a suitable connector for the Membrane to PCB). As I have said previously, the first run will be done at cost to GH members (and only "real" GH members, not someone registering just to get hold of it). Because of this, I will *not* let him break production, he is after all, a friend of mine.

I don't think I necessarily qualify as a "real" GH member as I only just registered to take part in this thread (though not specifically to try to buy a PCB!).  But if there were one or two boards available too me at a reasonable price I'd be interested.  Just the PCB would be cool, an assembled board would also be of interest since I could concentrate on programming it.  If it had the bootloader so it could be flashed without a programmer that would be just fine by me!

I don't think I necessarily qualify as a "real" GH member as I only just registered to take part in this thread (though not specifically to try to buy a PCB!).  But if there were one or two boards available too me at a reasonable price I'd be interested.  Just the PCB would be cool, an assembled board would also be of interest since I could concentrate on programming it.  If it had the bootloader so it could be flashed without a programmer that would be just fine by me!

It will be a while before this materialises. In the meantime, Read, Participate and yeah, sure no problem. You will then be a "Real" GH member... lol.

That comment was meant to deter someone looking to post, get a board, then dissapear for ever more. If you make a contribution to this forum (and if you can program AVR's, to this thread), then you are just as valid as any other GH member.

From what I've read in this thread it should be possible to convert most membrane keyboards right?  As long as the membrane can be hooked up in some way ...  This has potential for me as I have piles of rubber dome membrane keyboards I never use.  I'm in the process of getting to grips with understanding how a keyboard works on the electronic level at the moment.  As I understand it, for a simple membrane keyboard, the microcontroller is basically multiplexing all the keys onto fewer inputs by scanning rapidly across them?  And all I need to worry about is hooking up the keyboard controller to the membrane, programming it with the row / column count and telling it where the keys are positioned within that grid?  Sounds "easy" in principle but I know how "simple" things tend to go, especially in the realm of real electronics :-S

Hm, could be useful in some occasions.

I'd like to get my M4-1 trackpoint supported at some time, but didn't try a lot yet (no time). If mouse emulation over keyboard would be implemented, then some parts of the code could surely be reused for the trackpoint.

Yep, I reckon there'd be plenty of common code there.

I also got to thinking that a cool concept, if mouse support were available, would be to flip thing on their head - an open source mouse controller with optional keyboard emulation ;-)  I imagine that'd be easy for anything mechanical and tricky for anything optical, though.

Yes.

Many keyboards are IMHO not worth the trouble, though, unless you are modding them for educational purposes.

In my case it might just be "not destroying a good keyboard" purposes, I think ;-)

Yes. Instead of connecting each key switch directly to its own I/O pin on the MCU (so you'd need more than 100 I/O pins for a full-size keyboard), you're arranging them in an nxm matrix (requiring only n+m I/O pins, or fewer) and scan along one dimension. This saves I/O pins, but can introduce ghosting unless avoided in hardware (by adding diodes to the switches).

Aha!  Thanks, that link has answered many of my remaining hazy points.  I wasn't sure how the diodes / resistors came into it before.  Now I feel much more equipped to understand this stuff...

Yes, where extension of the firmware is the easy part. Tracing the matrix is not very hard, but can be time-consuming. Big matrices (like the 122-key IBM keyboards) require additional hardware.
Connecting your circuit to the membrane can be troublesome if the connection requires some nasty, hard to obtain connector or if there's no real connector at all (glued to the board).
It may also be hard to fit your circuit board into the keyboard case if it's a slim case.

All in all, it depends on the keyboard whether or not it's hard to mod. IBM keyboards are very mod-friendly as it seems.

Does the current code support all of a full-size kb - numpad etc?  I'm not looking to look up crazy / cool IBM terminal keyboards just yet ;-)

I also got to thinking that a cool concept, if mouse support were available, would be to flip thing on their head - an open source mouse controller with optional keyboard emulation ;-)  I imagine that'd be easy for anything mechanical and tricky for anything optical, though.

Um, yes, that's a different point of view then.

Does the current code support all of a full-size kb - numpad etc?  I'm not looking to look up crazy / cool IBM terminal keyboards just yet ;-)

Sure, it works with a full-size Model M already. In theory you could even build your own 200-key (or so) keyboard that has one key for each of the USB key codes, but I'm quite sure that no one would ever want such a beast.

and as to getting your trackpoint working...if my understanding of the trackpoint is correct...it uses a controller separate from the keyboard...and so it may not be feasible to incorporate it into the ATmega device...and likely unnecessary...but I may be wrong here.

The M4-1 trackpoint is just a stick with four strain gauges attached. There are four lines going to the strain gauges, and two coming back from them. The challenge now is to measure the resistances of the strain gauges accurately, which are changing slightly depending on the direction the stick is bent to. It should be possible to extend the firmware so to measure the strain gauges' resistances from time to time and derive a mouse movement from them.

Quite some time ago, I tried using the ATmega's analog inputs with their internal amplifiers for measuring the resistances, but found out, after lots of trying, that the internal  amps are broken on the DIP versions of the chip... ;( The data sheet indirectly mentions this, too. After disabling the amps, I could take some reasonable measurements, but signal amplification is absolutely necessary for a useful resolution. I'll look into this again when I have more spare time and will play around with some external opamps.