TMK ADB to USB keyboard converter

[DamnDan]

Apple Desktop keyboard(Apple IIGS) and Apple Standard keyboard including M0116 and M0118 can not discriminate between left and right modifier. Or those keyboard has same scan code for both left and right modifier key.
So both of those command keys in your pic are same key in reality. If you assign right Alt to the left Command key right Commad key also emits right Alt.

While Extended keyboard(AEK and AEKII) has discriminate between left and right modifier keys except Command keys.

This is ADB protocol limitation, not TMK converter one.

Thank you  I was going crazy with this trying to figure out how to make it work I've decided to just sacrifice OS key and use it as right alt instead

Thank you for all your help

[blargg]

Assuming yours differentiates between left and right shift keys, you could swap right shift and right command traces on the PCB pretty easily. They should both share a common scan line, which you'd leave. You'd cut the trace just before the other line to each switch, and run jumpers to another point on the board where those lines connect to something. Then update the keymap in tmk and it will work flawlessly (though be comical if someone tried to use it in an old Mac). If you're interested I can provide further guidance.

[DamnDan]

Assuming yours differentiates between left and right shift keys, you could swap right shift and right command traces on the PCB pretty easily. They should both share a common scan line, which you'd leave. You'd cut the trace just before the other line to each switch, and run jumpers to another point on the board where those lines connect to something. Then update the keymap in tmk and it will work flawlessly (though be comical if someone tried to use it in an old Mac). If you're interested I can provide further guidance.

Thank you for your response Actually i would love to keep the board original in terms of innards, so that when I decide to sell it or i will die and someone else try to sell it, the board will be a great deal for both keyboard and Apple enthusiasts That is why i sacrificed the OS key in tmk I've learned that I don't use the OS key at all when I work or game so it was the only reasonable choice

Also i use both shifts while I work - Photoshop, coding, writing etc

Second key that i've sacrificed was the "<>" key near the left shift, and now it is used as an FN key to trigger the function row

At the moment, after all the modding of additional layers, I've stopped using any other boards So the sacrifices were for the good M0118 is a really nice small board for my gaming and work needs

Just a question, should there be any springs in space and enter key stabilisers? Mine came with none and these keys were acting all sticky (after pressing they remained in pushed position). After some verification it seems that this was happening due to these keys being held down by stabilisers. I modded my board wih cut pencil springs, but the question remains...am I missing any original stabiliser springs?

Once again thank you all for all your help with this This is as close as I can get to 60-75% boards without going through ALOT of expenses

After I will find some more time to construct a shell for the converter I will post some pictures

Thanks!

[Merc_Ragnar]

?Help?

Hey guys, I'm not a troll, but instead just an idiot who can not apply what I've read here to my keyboard (M0116) project.  I am truly appreciative of your time if you're willing to help. 

Disclaimer:  This is the first time I've attempted a project like this.

My first question:  Regarding the source code at  github/...converter/adb_usb, I have read multiple references to edit keymap.c.  Currently, I can not locate a file called keymap.c.   Given that I need a hex for an M0116 (an iso layout to my knowledge), should I edit the keymap_iso.c file instead? 

ANY help (even just the necessary hex) would be incredibly appreciated. 

You guys do some incredible projects and I consider myself fortunate in being able to be along for the ride.  Thank you for your time.

[tufty]

What you probably want to do is copy keymap_iso.c to keymap_ragnar.c (or, indeed, populate it with the contents of the M0116 map from keymap_common.c), modify to taste, and then do a

make KEYMAP=ragnar

[Merc_Ragnar]

What you probably want to do is copy keymap_iso.c to keymap_ragnar.c (or, indeed, populate it with the contents of the M0116 map from keymap_common.c), modify to taste, and then do a

make KEYMAP=ragnar

Thanks for the heads-up, I'll get back to work and give that a go.

[arfink]

Having a little problem compiling the latest. I'm running Mint with gcc-avr and avr-libc installed, so ought to have all necessary dependencies. Issuing "make" spews lots of proper output before this:

mkdir -p obj_adb_usb_lufa/common
Compiling C: ../../common/debug.c
avr-gcc -c -mmcu=atmega32u4 -gdwarf-2 -DF_CPU=16000000UL -DINTERRUPT_CONTROL_ENDPOINT -DBOOTLOADER_SIZE=4096 -DF_USB=16000000UL -DARCH=ARCH_AVR8 -DUSB_DEVICE_ONLY -DUSE_FLASH_DESCRIPTORS -DUSE_STATIC_OPTIONS="(USB_DEVICE_OPT_FULLSPEED | USB_OPT_REG_ENABLED | USB_OPT_AUTO_PLL)" -DFIXED_CONTROL_ENDPOINT_SIZE=8  -DFIXED_NUM_CONFIGURATIONS=1 -DPROTOCOL_LUFA -DMOUSEKEY_ENABLE -DMOUSE_ENABLE -DEXTRAKEY_ENABLE -DCONSOLE_ENABLE -DCOMMAND_ENABLE -DVERSION=8cec0bc -Os -funsigned-char -funsigned-bitfields -ffunction-sections -fno-inline-small-functions -fpack-struct -fshort-enums -fno-strict-aliasing -Wall -Wstrict-prototypes -Wa,-adhlns=obj_adb_usb_lufa/common/debug.lst -I. -I../.. -I../../protocol/lufa -I../../protocol/lufa/LUFA-120730 -I../../protocol -I../../common -std=gnu99 -include config.h -MMD -MP -MF .dep/obj_adb_usb_lufa_common_debug.o.d  ../../common/debug.c -o obj_adb_usb_lufa/common/debug.o
../../common/debug.c:7:5: error: unknown field ‘enable’ specified in initializer
../../common/debug.c:8:5: error: unknown field ‘matrix’ specified in initializer
../../common/debug.c:8:5: warning: excess elements in union initializer
../../common/debug.c:8:5: warning: (near initialization for ‘debug_config’)
../../common/debug.c:9:5: error: unknown field ‘keyboard’ specified in initializer
../../common/debug.c:9:5: warning: excess elements in union initializer
../../common/debug.c:9:5: warning: (near initialization for ‘debug_config’)
../../common/debug.c:10:5: error: unknown field ‘mouse’ specified in initializer
../../common/debug.c:10:5: warning: excess elements in union initializer
../../common/debug.c:10:5: warning: (near initialization for ‘debug_config’)
make: *** [obj_adb_usb_lufa/common/debug.o] Error 1

Not sure what's going on here, the last version I pulled from Git a couple months ago compiled without hiccups...

[hasu]

On my ubuntu 14.04 with AVR gcc 4.8.2 and avr-libc 1.8.0 I got no error while compile. But I have seen this error some time ago sowewhere. I don't remember how I did with the error.

What are your toolchain versions? And you are using HEAD of master branch, right?

Those 'unknown fields' of debug_config_t is defined in common/debug_config.h, I dont know why those are unknown.
My code may not conform with some C specifications. Am I doing something wrong?

[Merc_Ragnar]

Having a little problem compiling the latest. I'm running Mint with gcc-avr and avr-libc installed, so ought to have all necessary dependencies. Issuing "make" spews lots of proper output before this:

mkdir -p obj_adb_usb_lufa/common
Compiling C: ../../common/debug.c
avr-gcc -c -mmcu=atmega32u4 -gdwarf-2 -DF_CPU=16000000UL -DINTERRUPT_CONTROL_ENDPOINT -DBOOTLOADER_SIZE=4096 -DF_USB=16000000UL -DARCH=ARCH_AVR8 -DUSB_DEVICE_ONLY -DUSE_FLASH_DESCRIPTORS -DUSE_STATIC_OPTIONS="(USB_DEVICE_OPT_FULLSPEED | USB_OPT_REG_ENABLED | USB_OPT_AUTO_PLL)" -DFIXED_CONTROL_ENDPOINT_SIZE=8  -DFIXED_NUM_CONFIGURATIONS=1 -DPROTOCOL_LUFA -DMOUSEKEY_ENABLE -DMOUSE_ENABLE -DEXTRAKEY_ENABLE -DCONSOLE_ENABLE -DCOMMAND_ENABLE -DVERSION=8cec0bc -Os -funsigned-char -funsigned-bitfields -ffunction-sections -fno-inline-small-functions -fpack-struct -fshort-enums -fno-strict-aliasing -Wall -Wstrict-prototypes -Wa,-adhlns=obj_adb_usb_lufa/common/debug.lst -I. -I../.. -I../../protocol/lufa -I../../protocol/lufa/LUFA-120730 -I../../protocol -I../../common -std=gnu99 -include config.h -MMD -MP -MF .dep/obj_adb_usb_lufa_common_debug.o.d  ../../common/debug.c -o obj_adb_usb_lufa/common/debug.o
../../common/debug.c:7:5: error: unknown field ‘enable’ specified in initializer
../../common/debug.c:8:5: error: unknown field ‘matrix’ specified in initializer
../../common/debug.c:8:5: warning: excess elements in union initializer
../../common/debug.c:8:5: warning: (near initialization for ‘debug_config’)
../../common/debug.c:9:5: error: unknown field ‘keyboard’ specified in initializer
../../common/debug.c:9:5: warning: excess elements in union initializer
../../common/debug.c:9:5: warning: (near initialization for ‘debug_config’)
../../common/debug.c:10:5: error: unknown field ‘mouse’ specified in initializer
../../common/debug.c:10:5: warning: excess elements in union initializer
../../common/debug.c:10:5: warning: (near initialization for ‘debug_config’)
make: *** [obj_adb_usb_lufa/common/debug.o] Error 1

Not sure what's going on here, the last version I pulled from Git a couple months ago compiled without hiccups...

I can't figure out how to make this stupid thing, but I had to deal with the same obstacle just two days ago. 
Note:  I'm running Mint on my primary laptop.

CODE THAT FOLLOWS FOR LINUX MINT ONLY
Try

Code: [Select]

sudo apt-get install gcc-avr binutils-avr avr-libc

That resolved my errors.

[tufty]

Okay, it's not tested, as I don't have a teensy spare at the moment, but I've just incorporated my M0116 keymap with hasu's latest code.

I've attached a binary.  Merc_ragnar, if you could test it, I'll submit a pull request to hasu.

[arfink]

Having a little problem compiling the latest. I'm running Mint with gcc-avr and avr-libc installed, so ought to have all necessary dependencies. Issuing "make" spews lots of proper output before this:

mkdir -p obj_adb_usb_lufa/common
Compiling C: ../../common/debug.c
avr-gcc -c -mmcu=atmega32u4 -gdwarf-2 -DF_CPU=16000000UL -DINTERRUPT_CONTROL_ENDPOINT -DBOOTLOADER_SIZE=4096 -DF_USB=16000000UL -DARCH=ARCH_AVR8 -DUSB_DEVICE_ONLY -DUSE_FLASH_DESCRIPTORS -DUSE_STATIC_OPTIONS="(USB_DEVICE_OPT_FULLSPEED | USB_OPT_REG_ENABLED | USB_OPT_AUTO_PLL)" -DFIXED_CONTROL_ENDPOINT_SIZE=8  -DFIXED_NUM_CONFIGURATIONS=1 -DPROTOCOL_LUFA -DMOUSEKEY_ENABLE -DMOUSE_ENABLE -DEXTRAKEY_ENABLE -DCONSOLE_ENABLE -DCOMMAND_ENABLE -DVERSION=8cec0bc -Os -funsigned-char -funsigned-bitfields -ffunction-sections -fno-inline-small-functions -fpack-struct -fshort-enums -fno-strict-aliasing -Wall -Wstrict-prototypes -Wa,-adhlns=obj_adb_usb_lufa/common/debug.lst -I. -I../.. -I../../protocol/lufa -I../../protocol/lufa/LUFA-120730 -I../../protocol -I../../common -std=gnu99 -include config.h -MMD -MP -MF .dep/obj_adb_usb_lufa_common_debug.o.d  ../../common/debug.c -o obj_adb_usb_lufa/common/debug.o
../../common/debug.c:7:5: error: unknown field ‘enable’ specified in initializer
../../common/debug.c:8:5: error: unknown field ‘matrix’ specified in initializer
../../common/debug.c:8:5: warning: excess elements in union initializer
../../common/debug.c:8:5: warning: (near initialization for ‘debug_config’)
../../common/debug.c:9:5: error: unknown field ‘keyboard’ specified in initializer
../../common/debug.c:9:5: warning: excess elements in union initializer
../../common/debug.c:9:5: warning: (near initialization for ‘debug_config’)
../../common/debug.c:10:5: error: unknown field ‘mouse’ specified in initializer
../../common/debug.c:10:5: warning: excess elements in union initializer
../../common/debug.c:10:5: warning: (near initialization for ‘debug_config’)
make: *** [obj_adb_usb_lufa/common/debug.o] Error 1

Not sure what's going on here, the last version I pulled from Git a couple months ago compiled without hiccups...

I can't figure out how to make this stupid thing, but I had to deal with the same obstacle just two days ago. 
Note:  I'm running Mint on my primary laptop.

CODE THAT FOLLOWS FOR LINUX MINT ONLY
Try

Code: [Select]

sudo apt-get install gcc-avr binutils-avr avr-libc

That resolved my errors.

I had already thought to install those too, and found that despite having them installed, it still borked on me. Is this just a Linux Mint problem? I am running v13 LTS, so it's a little behind.

[arfink]

For GCC-AVR I have 1:4.5.3-3
For avr-libc I have 1:1.7.1-2

I suppose for my next thing to try, I'll be seeing about updating those. I believe those are the newest in the Mint 13 repo though, so this might be a little beyond where I can/will go with this today. I might resort to compiling in my Windows VM to save having to upgrade a bunch of dependencies beyond the repos.

[Merc_Ragnar]

For GCC-AVR I have 1:4.5.3-3
For avr-libc I have 1:1.7.1-2

I suppose for my next thing to try, I'll be seeing about updating those. I believe those are the newest in the Mint 13 repo though, so this might be a little beyond where I can/will go with this today. I might resort to compiling in my Windows VM to save having to upgrade a bunch of dependencies beyond the repos.

I should probably simply shut my mouth as I have NO experience in hardware.  I did resolve the same error you had for Mint 17 by running an update and then the code I posted above.  I have no idea why I had the initial error as I already had GCC-AVR installed, but after the update and running the code above the error did resolve.

Okay, it's not tested, as I don't have a teensy spare at the moment, but I've just incorporated my M0116 keymap with hasu's latest code.

I've attached a binary.  Merc_ragnar, if you could test it, I'll submit a pull request to hasu.

Thank you so much I had all but given up and just resolved to grab an adapter.  I'll give her a go tonight.



EDIT:  Tuffy, I have no idea what to do with the .elf or how to test that on the Teensy.  I don't know how to convert/make a hex out of the elf and I am unable to load it onto my Teensy.  Anyway I can score the .hex from you?

[tufty]

Oh god I'm an idiot.  Attached.

Should work like this:

Code: [Select]

  /* Default layer : plain keymap
   *                     +-------+
   *                     | power |
   *                     +-------+
   * +---+---+---+---+---+---+---+---+---+---+---+---+---+-----+ +---+---+---+---+
   * |esc| 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 0 | - | = | bks | |clr| = | / | * |
   * +---------------------------------------------------------+ +---+---+---+---+
   * | tab | q | w | e | r | t | y | u | i | o | p | [ | ] |   | | 7 | 8 | 9 | + |
   * +-----------------------------------------------------+   | +---+---+---+---+
   * | ctrl | a | s | d | f | g | h | j | k | l | ; | ' |return| | 4 | 5 | 6 | - |
   * +---------------------------------------------------------+ +---+---+---+---+
   * | shift  | z | x | c | v | b | n | m | , | . | / |  shift | | 1 | 2 | 3 |   |
   * +---------------------------------------------------------+ +-------+---|ent|
   * |Fn1|opt|comnd| ` |                   | \ |lef|rig|dwn|up | |   0   | . |   |
   * +---------------------------------------------------------+ +-------+---+---+
   */
  /* Layer 1 :
   *                     +-------+
   *                     | Eject |
   *                     +-------+
   * +---+---+---+---+---+---+---+---+---+---+---+---+---+-----+ +---+---+---+---+
   * |Esc|F1 |F2 |F3 |F4 |F5 |F6 |F7 |F8 |F9 |F10|F11|F12|     | |   |   |   |Mut|
   * +---------------------------------------------------------+ +---+---+---+---+
   * |     |   |   |   |   |   |   |   |   |   |   |   |   |   | |   |   |   |VoU|
   * +-----------------------------------------------------+   | +---+---+---+---+
   * |      |   |   |   |   |   |   |   |   |   |   |   |      | |   |   |   |VoD|
   * +---------------------------------------------------------+ +---+---+---+---+
   * |Capslock|   |   |   |   |   |   |   |   |   |   |Capslock| |   |   |   |   |
   * +---------------------------------------------------------+ +-------+---|   |
   * |Fn1|   |     |   |                   |   |Hom|End|PgD|PgU| |       |   |   |
   * +---------------------------------------------------------+ +-------+---+---+
   */
note that capslock is now the "layer" key (and works best with the locking mechanism removed), and actual capslock is on layer 1.

[hasu]

Having a little problem compiling the latest. I'm running Mint with gcc-avr and avr-libc installed, so ought to have all necessary dependencies. Issuing "make" spews lots of proper output before this:

mkdir -p obj_adb_usb_lufa/common
Compiling C: ../../common/debug.c
avr-gcc -c -mmcu=atmega32u4 -gdwarf-2 -DF_CPU=16000000UL -DINTERRUPT_CONTROL_ENDPOINT -DBOOTLOADER_SIZE=4096 -DF_USB=16000000UL -DARCH=ARCH_AVR8 -DUSB_DEVICE_ONLY -DUSE_FLASH_DESCRIPTORS -DUSE_STATIC_OPTIONS="(USB_DEVICE_OPT_FULLSPEED | USB_OPT_REG_ENABLED | USB_OPT_AUTO_PLL)" -DFIXED_CONTROL_ENDPOINT_SIZE=8  -DFIXED_NUM_CONFIGURATIONS=1 -DPROTOCOL_LUFA -DMOUSEKEY_ENABLE -DMOUSE_ENABLE -DEXTRAKEY_ENABLE -DCONSOLE_ENABLE -DCOMMAND_ENABLE -DVERSION=8cec0bc -Os -funsigned-char -funsigned-bitfields -ffunction-sections -fno-inline-small-functions -fpack-struct -fshort-enums -fno-strict-aliasing -Wall -Wstrict-prototypes -Wa,-adhlns=obj_adb_usb_lufa/common/debug.lst -I. -I../.. -I../../protocol/lufa -I../../protocol/lufa/LUFA-120730 -I../../protocol -I../../common -std=gnu99 -include config.h -MMD -MP -MF .dep/obj_adb_usb_lufa_common_debug.o.d  ../../common/debug.c -o obj_adb_usb_lufa/common/debug.o
../../common/debug.c:7:5: error: unknown field ‘enable’ specified in initializer
../../common/debug.c:8:5: error: unknown field ‘matrix’ specified in initializer
../../common/debug.c:8:5: warning: excess elements in union initializer
../../common/debug.c:8:5: warning: (near initialization for ‘debug_config’)
../../common/debug.c:9:5: error: unknown field ‘keyboard’ specified in initializer
../../common/debug.c:9:5: warning: excess elements in union initializer
../../common/debug.c:9:5: warning: (near initialization for ‘debug_config’)
../../common/debug.c:10:5: error: unknown field ‘mouse’ specified in initializer
../../common/debug.c:10:5: warning: excess elements in union initializer
../../common/debug.c:10:5: warning: (near initialization for ‘debug_config’)
make: *** [obj_adb_usb_lufa/common/debug.o] Error 1

Not sure what's going on here, the last version I pulled from Git a couple months ago compiled without hiccups...

I can't figure out how to make this stupid thing, but I had to deal with the same obstacle just two days ago. 
Note:  I'm running Mint on my primary laptop.

CODE THAT FOLLOWS FOR LINUX MINT ONLY
Try

Code: [Select]

sudo apt-get install gcc-avr binutils-avr avr-libc

That resolved my errors.

I had already thought to install those too, and found that despite having them installed, it still borked on me. Is this just a Linux Mint problem? I am running v13 LTS, so it's a little behind.

For GCC-AVR I have 1:4.5.3-3
For avr-libc I have 1:1.7.1-2

I suppose for my next thing to try, I'll be seeing about updating those. I believe those are the newest in the Mint 13 repo though, so this might be a little beyond where I can/will go with this today. I might resort to compiling in my Windows VM to save having to upgrade a bunch of dependencies beyond the repos.

I confirmed this error occurs on WinAVR(avr-gcc 4.3.3) too. Seems like this GCC bug is involved with the error and **GCC 4.6 or later** will be able to compile without the error if I'm correct.
GCC Bug 10676 - Using unnamed fields in initializers: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=10676

Now we have two possible workarounds. Let me know whether these work for you.
WORKAROUND1: Update GCC to 4.6 or later
or
WORKAROUND2: Replace code

Code: [Select]

debug_config_t debug_config = {
    .enable = false,
    .matrix = false,
    .keyboard = false,
    .mouse = false,
};
with

Code: [Select]

debug_config_t debug_config = {};


[tufty]

I've just thrown you a pull request, which should fix the gcc < 4.6 issues and keep your code readable.

The commit before adds files with a trailing ~ in their names to .gitignore, which is useful, and the one before that adds my m0116 keymap (currently untested, as I noted before)

[hasu]

Thank you for suggestion, tuffy.

I fixed the issue of debug.c compile at this commit.
https://github.com/tmk/tmk_keyboard/commit/818070913275349c3906e2c4cdc3d69da5b7e132

Code: [Select]

diff --git a/common/debug.c b/common/debug.c
index c4fa3a0..2ed1006 100644
--- a/common/debug.c
+++ b/common/debug.c
@@ -1,12 +1,15 @@
 #include <stdbool.h>
 #include "debug.h"
 
+#define GCC_VERSION (__GNUC__ * 10000 + __GNUC_MINOR__ * 100 + __GNUC_PATCHLEVEL__)
 
-//debug_config_t debug_config = { .enable = false, .matrix = false };
 debug_config_t debug_config = {
+#if GCC_VERSION >= 40600
+    /* GCC Bug 10676 - Using unnamed fields in initializers
+     * https://gcc.gnu.org/bugzilla/show_bug.cgi?id=10676 */
     .enable = false,
     .matrix = false,
     .keyboard = false,
     .mouse = false,
+#endif
 };
-


[tufty]

OK, I done a stupid.

As my ADB testing teensy (now hardwired into a wacom tablet) had ADB wired to C7, I had hacked my local branch to listen for ADB on that pin, rather than hasu's default D0.  And I didn't rectify that before building the binary I posted before.  Woops.

Here's one built with the aforementioned M0116 keymap and, crucially, listening on what should be the correct pin.

<hangs head in shame>

[tufty]

<and more shame>

It's been a long day.

[Merc_Ragnar]

<and more shame>

It's been a long day.

Thanks for all the help on this. 

Good news:  I got the Teeny reading as a keyboard on my windows laptop.
Bad news:  I could never use the keyboard and ended up smelling a burning plastic smell and discovered the large black chip on the keyboard was incredibly hot.

I'm now checking out my solders again, specifically the contact my resistor is making.

 

[blargg]

With the Teensy off, use a meter to be sure that GND actually connects to GND on the keyboard PCB when they're plugged together. Sounds like the polarity was backwards, and you've got Vcc from the Teensy going to GND on the keyboard.

[tufty]

Good news:  I got the Teeny reading as a keyboard on my windows laptop.
Bad news:  I could never use the keyboard and ended up smelling a burning plastic smell and discovered the large black chip on the keyboard was incredibly hot.

Aaargh!

That's not good, but you probably guessed that anyway.  I concur with blargg, sounds an awful lot like you've got something messed up soldering-wise.  Any chance of a photo?  Also double-check you've got the ADB connection wired up correctly.  The plug is symmetrical, so it's easy to mix up which wire goes where based on a pinout, and there's seemingly no standard as to what colour the wires are.

[zacbir]

Is there a preferred place to tie into the ADB circuitry when doing an internal Teensy mod? I've attached photos of three possibilities that occur to me.

1) tack solder to the back of the ADB connector PCB. This seems to be what Scotty did here: http://ifixit.org/blog/4468/hack-it-better-apple-extended-keyboard-ii/

2) shim into the connector between the ADB connector PCB and the keyboard PCB

3) desolder the ADB connector PCB and tie in directly to the keyboard PCB.

I don't plan on using the keyboard with a standard ADB-capable Mac, so I don't mind losing the ADB connectivity.

Incidentally, anyone know what the 5 pin(s) are there for?

[tufty]

There's only 4 pins - +5v, GND, data, PSW (power switch).  The 5th "pin" you're seeing on the AEK is "shield", which is usually synonymous with GND.

[zacbir]

Right. That's why I was asking. But thanks, that clears it up anyway.

[zacbir]

Back to the original question, though: Anyone want to chime in on how they wired up their AEKII? At this point, I'm planning on route #3 (desoldering the ADB connector entirely, and running the wires from the keyboard directly to the Teensy 2.0.

[tufty]

That's what I'd do, replacing the ADB connector with a B or mini-B USB connector on a flying lead.

[blargg]

I keep my keyboards unmodified (other than making caps lock a momentary key), so that I can easily plug the adapter into another ADB keyboard, debug problems by testing on another keyboard, sell the keyboard later, etc. I like flexibility. A common S-video cable can be used to connect to the keyboard.

[zacbir]

For the AEKII, is it sufficient to remove the physical locking mechanism on the Caps Lock switch, and use the tmk code to grant it momentary behavior (versus combined keydown/keyup) in order to be able to treat Caps Lock as Control? Anyone with a step-by-step on this procedure?

[ocodo]

Is there a preferred place to tie into the ADB circuitry when doing an internal Teensy mod? I've attached photos of three possibilities that occur to me.

1) tack solder to the back of the ADB connector PCB. This seems to be what Scotty did here: http://ifixit.org/blog/4468/hack-it-better-apple-extended-keyboard-ii/ (Attachment Link)

2) shim into the connector between the ADB connector PCB and the keyboard PCB (Attachment Link)

3) desolder the ADB connector PCB and tie in directly to the keyboard PCB. (Attachment Link)

I don't plan on using the keyboard with a standard ADB-capable Mac, so I don't mind losing the ADB connectivity.

Incidentally, anyone know what the 5 pin(s) are there for?

Does anyone have the pinouts of that ribbon cable? Looks like the perfect place to patch from.  3D print a mount for the teensy and we have a nice mini USB connector to replace one ADB and a remaining ADB on the other side, for backwards compatibility. 


Edit:  This looks more than adequate. https://geekhack.org/index.php?topic=14290.msg1409902#msg1409902



ADB Pin outs left - to - right

Code: [Select]

5 : 4 (Gnd) : 5 : 3 (VCC) : 5 : 2 (Pwr) : 5 : 1 (Data) : 5

[zacbir]

SUCCESS

Turned out to be a 1 hour project, once I had all the components in place. Ultimately, I went with an external connector for three reasons:

  1) Fear of working in cramped conditions

  2) Can more easily fall back on one of the other spare keyboards if something goes wrong

  3) DAT original ADB cable!

Process writeup:

So, I bought the keyboards together on eBay from a single seller (he discounted the lot of 4 for $112 - $28 a pop!). He sent me serial numbers, confirming that all had the Alps switches. They had no cables, though, so I was originally planning on an internal mod with a pretty stock USB cable. I looked at the Zeal PC custom cables, and considered getting a grey coiled cable, but man, it'd be more than the keyboard! I planned for a bit of redundancy, so I ordered two of the Teensy 2.0 boards, and started collecting some other bits and bobs. Got some various soldering bits off Amazon and Adafruit, and got a batch of 10 S-Video connectors off eBay for $5. Also came across two coiled ADB cables on eBay, one NOS, each for ~$5. So, I was set. Easy peasy lemon squeezy.

Now to come up with some sort of housing for it.

Thanks for the inspiration, GeekHack, and thanks for the code, Hasu!

Happy clackety clack

[MontyElephant]

Ok so I'm really new to all of this. I decided to go with an Arduino micro since I could get it locally. I am stuck at how to load the hex file on to the chip. When I select Connection > USB > Open in FLIP it says "Could not open USB device." The arduino shows up in the device manager under Ports > Arduino Micro (COM 3). What am I doing wrong?

Thanks

[hasu]

zacbir, nice write up!

MontyElephant, FLIP cannot work with Arduino bootloader, you will need to use avrdude instead.

EDIT: command like this will work for you, device name varies depending on your system.

Code: [Select]

avrdude -patmega32u4 -cavr109 -b57600 -Uflash:w:adb_usb.hex -P/dev/ttyACM0


[MontyElephant]

MontyElephant, FLIP cannot work with Arduino bootloader, you will need to use avrdude instead.

EDIT: command like this will work for you, device name varies depending on your system.

Code: [Select]

avrdude -patmega32u4 -cavr109 -b57600 -Uflash:w:adb_usb.hex -P/dev/ttyACM0


Ok so I was able to upload the hex (i think) using Arduino Builder. I then plugged it into the breadboard with all the wires and then plugged it all into the computer aannnd nothing... I took it back out of the breadboard and now when I plug it in the blue LED turns on but neither of the LEDs on top blink as before. If I press reset, the top LEDs will blink briefly and the device will show up temporarily in the same spot under COM4 and then disappear. Did I do something wrong?

[hasu]

you will see keyboard device of vid:feed and pid:0adb if your board is programmed with tmk firmware. My converter doesn't control any LED on Arduino.

[MontyElephant]

you will see keyboard device of vid:feed and pid:0adb if your board is programmed with tmk firmware. My converter doesn't control any LED on Arduino.

Ok so when I plug the device in (without being plugged into the breadboard), it shows up as you specified. However, as soon as I put it in the breadboard, when I connect it, it connects momentarily (I can hear the windows "device connected" sound) but then immediately disconnects (again indicated by the sound). Would this imply an issue with my wiring?

EDIT: Ok so it stays on until I plug in the keyboard (M0116). And if I unplug the keyboard it turns on again...

EDIT 2: I'm retarded. I was reading the wiring diagram as if I was looking down at the male end of the cable and not the female end... IT WORKS NOW.. TYPING WITH AN M0116 from my dad's old SE/30

[Blaise170]

Nevermind.

[zacbir]

Hey, fellow hackers.

I wrote up my experience this morning converting the Caps Lock to a momentary key. The highlight was that I accidentally pried the actual switch off the base! Luckily, it just broke the solder. I cleaned it up with my solder wick and re-situated it and soldered it back, good as new, but I got the lock pin out successfully.

http://zacbir.net/blog/2014/12/19/getting-control-over-caps-lock/

Maybe it'll help anyone else stumped on this little procedure.

[loudaslife]

You can use PJRC Teensy or other dev board with ATMega32U4.

Does that mean it will work with the Leonardo Pro Micro? I'm worried the Arduino bootloader might mess something up. For the ultra-thrifty, a Pro Micro can be found for about half the cost of a teensy.

Edit: I am an idiot and somehow missed that part of the thread while I was skimming through. Disregard that.

[hwood34]

Does anyone have a picture of a finished mod on an M0116? I'm seeing lots of pictures, but the cables on all them seem to have 3 wires, while mine has 4, differently colored wires

[tufty]

Expect 4 wires internally.  +5v, GND, ADB and PWR.  There will be 5 connections to the connector (it's shielded).  You want +5, GND and ADB.  PWR is the hard-wired power switch connection, ignore it.

[hwood34]

Expect 4 wires internally.  +5v, GND, ADB and PWR.  There will be 5 connections to the connector (it's shielded).  You want +5, GND and ADB.  PWR is the hard-wired power switch connection, ignore it.

Ah, now looking back over this I get it. Ugh, still such a noob with this kind of stuff )

[zacbir]

I suspect this is doable, but am a bit lost amid the fragments of documentation in hasu's github code.

If you were to remap the Print Screen key to be a Fn key, would OS X interpret <Print Screen>-<F8> as Play/Pause automatically? If so, which key code would you use to represent the Fn key on an Apple USB/Bluetooth keyboard? There are KC_FN0 - KC_FN31, but nothing that seems to be a sole Fn key.

EDIT: To clarify, I know that I could simply wire up Scroll Lock to VOLD and Pause to VOLU, but I'm wondering about setting up a key as a modifier key to basically get media keys (and other OS X specific keys) using the AEKII.

[hasu]

Not sure exactly what you want, but I guess you want to make Print Screen a momemtary'Layer switching' and have Play/Pause keycode on F8 key in another layer.
https://github.com/tmk/tmk_keyboard/blob/master/doc/keymap.md#31-momentary-switching

[zacbir]

Not sure exactly what you want, but I guess you want to make Print Screen a momemtary'Layer switching' and have Play/Pause keycode on F8 key in another layer.
https://github.com/tmk/tmk_keyboard/blob/master/doc/keymap.md#31-momentary-switching

That's exactly what I was looking for! Thanks, hasu!

[zacbir]

Thanks, hasu!

Successfully reintroduced the media keys to my AEKII, and wrote it up: http://zacbir.net/blog/2015/01/08/in-media-res/

[mougrim]

You wrote that any controller, based on ATMega32U4, can be used.

Do you happen to know if Arduino Leonardo http://arduino.cc/en/Main/arduinoBoardLeonardo suitable for this purpose?

It's just I can get it a lot cheaper than teensy in my country.

[hasu]

You can use Leonardo without problem.

[mougrim]

You can use Leonardo without problem.

Thank you, hasu. It's just it's pins are marked somewhat different... you don't happen to know what pin I need to use for data? Analog a0? I won't have any problem with +5v and GND, but data...

[hasu]

I don't remember. Just check its schematic yourself.