Hi. I'm new here, but I have a little experience with ADB tablets. Bernard emailed me today, so I thought I'd register and post what I know.
As you are all no doubt aware, ADB tablets are dirt cheap on fleabay and the like. This is because nobody can use them, so nobody wants them. Nobody can use them, because they have a completely proprietary interface, the ports for which haven't been included on an actual shipping computer since 1998 or so (and even then, they were only ever on Macs).
Now, I'm one of those people who hoard old tech, and who feel bitter and twisted when that old tech no longer works. Especially when that old tech cost an arm and a leg a mere couple of months before Wacom decided they weren't gonna ship drivers for that "old" tech under Apple's new OS. Yeah, I've got an ADB tablet.
So I went out of my way to start developing a driver for OSX (based on some work I did years back on developing a driver for Linux, but that's a whole 'nother story), the result of which was the imate-osx project (which can be found at the google code site). This allows some machines with very specific versions of OSX and specific pieces of the Griffin iMate hardware to talk to specific ADB tablets. Yeah, it's a bit flakey, but nobody seems interested in helping out and I've been - erm - busy. Yep, that's right. "busy". Certainly not "slacking off", or "lazy", just "busy".
Anyroadup, here's some ADB tablet "general" info.
- The ADB tablets do not use the same logic boards as the serial ones. You can't just hook up a serial cable and expect it to work, at least not without some considerable software work
- Some of the larger (high end) ADB tablets had swappable driver boards, and could run ADB or serial, depending on which board was installed. Wacom offered a "low price" board swap for these tablets as a sop to the community when they announced they weren't going to support ADB any more. If you could find a supply of those boards, you'd be a hero, although It probably wouldn't help with the tablets smaller than 12x12
- The messages sent across ADB are not the same as those sent across the serial connection, although they do appear to be similar, so you can't just do a level conversion, either
So where does that leave those with ADB tablets?
Frankly, the phrase "in the shit" springs to mind, but there are options.
Firstly, one could get hold of an ADB-USB adaptor (the only one that works properly is Griffin's "iMate", now discontinued), and write a driver for one's favoured OS. It's a fair amount of work, but the imate-osx project is there. As the iMate appears as an ADB controller, you have to write a whole ADB stack, not just a driver for the tablet.
Secondly, you could get hold of a microcontroller and hook it up to ADB, with some firmware to make it handle the ADB side of things, and look either like a serial tablet or a generic HID tablet. That's what Bernard wants to do; I think he's probably right. If nothing else, it makes the resulting device platform independent.
Or you could say "cobblers to it", chuck the tablet in the bin and buy a USB model. Yeah, right.
In any case, you need to know a few things. Let's look at ADB itself.
ADB is a single-wire protocol handling one master and up to 15 slaves, and it's not very fast. There's full documentation of the underlying protocol (how devices talk to the controller, timings and so on) in "About Macintosh", and also in the technical documentation for the Apple IIgs. Both of these are available online.
An ADB device has a bus address (defaulted by the device, but possibly changed to avoid collisions on ADB startup) and what's knwon as a "handler number". The handler number is very important for ADB tablets, as they start up, by default, behaving as though they are a standard one-button ADB mouse. The driver for the tablet needs to tell it to move to the proper handler before the firmware will start sending absolute location, pressure, tilt, and all that other good tablet stuff.
The proper handler number is model specific. Which is to say, a UD-0608A 6x8 ADB tablet will have a different handler number to a GD-1212A, and so on. That's a bugger, and the only way to find out what the correct handler number is for a specific model of tablet, is to hook up the tablet to an old mac running OS9 or below, with the proper Wacom drivers installed, and then look to see what handler is assigned using an app named "ADB Parser".
ADB treats each device as having a number of registers, which store up to 8 bytes of data each. Wacom tablets use all the registers.
ADB is a polled bus. The controller will ask each device in turn if it has new data. Combined with the speed of the bus, this effectively limits the ADB tablets to a maximum sample rate. It's not very high. You are *not* going to get a polling speed of over 100Hz.
The data that is sent over the bus is similar to, but not the same as, the serial protocol. Here's what I found:
Extracted from an ArtPad II, model UD-0608-A using ADB Analyzer, a 9500, a Powerbook G3, one dead ADB mouse, a Newton
keyboard, 4x2.2K resistors, 1 1K in line resistor pack, a bit of solderless breadboard, and some wire. Not pretty.
By default, this tablet appears at handler 0x3a, and gets moved to handler 0x68 by the Wacom driver. That's where we
want to put it, I think. Is it by chance that 0x68 is a truncation of 0608? Would a 1212 be moved to 0xcc? I think
it likely. Need to get someone to try, I guess.
Static device information is coded in register 1 and Register 3. Reg 3 is, as usual, the handler id.
ADB Register 1 holds 8 bytes, and appears to encode the following:
?? ?? xx xx yy yy ?? ??
Resolution of my tablet is 2450 dpi (0x5000 / 2450 = 8, 0x3e00 / 2450 = 6) or 0.01mm
xxxx : maximum x co-ordinate
yyyy : maximum y co-ordinate
items referred to as ?? I haven't figured out yet.
All but the second byte appear to be static data. Second byte is random, but seems to be fixed per setting of R3, although its value
doesn't seem to be related to r3 value in any way.
Packets sent after address resolution is finished
Talk R1 38 20 50 00 3c 00 06 17 // Talk register 1, presumably to determine if this is actually a wacom tablet
Talk R0 a6 bc 0b 4b 00 80 1f 19 // Talk register 0, doesn't always do this. Possibly irrelevant, may be triggered
// by normal ADB polling?
Talk R3 6e 3a // Talk register 3, find out what handler it's set to.
Talk R1 38 20 50 00 3c 00 06 17 // Talk register 1, Always an identical result to the previous talk
Listen R3 6f 68 // Listen register 3, set handler to 68
Talk R3 6x 68 // Talk register 3, did it take?
Listen R1 67 68 // Listen register 1, do what? First byte changes, seems irrelevant.
Talk R1 38 03 50 00 3c 00 06 17 // After the listen, byte 2 has changed, but there seems to be no reason to it.
Talk R0 // No data in this case, will repeat if there is any, this is probably a normal poll
Talk R3 61 68 // Appears to be normal MacOS ADB init handling, probably not required
Despite Dave Fleck's assurances to the contrary, there appears to be nothing over-onerous in the protocol. Each
poll interval can result in 8 bytes being sent, with the command byte that makes 9 bytes per packet, at 100Hz, or 8100bit/s.
Even USB 1.1 devices should be able to handle 12Mbit/s, so we're not even close to throttling USB. It has to be said, it is
pretty close to thrashing ADB, which could be an issue for OSX, but to be frank, I think Wacom have been talking crap
since day 1. Anyway, back to matters in hand.
The tablet polls just like any other device, with a talk R0 command, which returns an 8 byte packet if there's anything to
In short, it looks like this:
Talk R0 ss xx xx yy yy pp tx ty
ss : status
xxxx : x coordinate
yyyy : y coordinate
pp : pressure,
tx : X tilt, +-127, -ve to the left
ty : Y tilt, +-127, -ve away from user
The status byte is similar to, but not the same as, that used by the Wacom IV binary protocol:
7 Always 1
6 Pointer in proximity indicator
5 Stylus : 1, Cursor : 0
4 Button Depressed (click)
Button encoding, as given by the nybble defined by B0..B3 depends on the tool in use. Nothing like a standard
approach, after all, and this is nothing like one.
If it's a puck:
Button = 1 - Front centre
Button = 2 - Left
Button = 3 - back centre
button = 4 - right
For the stylus (ultrapen eraser), it's all a bit arse arse as the number is a bitmap of the "tip pressed" and button
Button = 1 - nib pressed
Button = 2 - side button 1 pressed
Button = 3 - nib pressed and side button 1 pressed
button = 4 - side button 2 pressed in proximity *or* eraser in proximity
Button = 5 - Eraser pressed *or* side button 2 pressed and tip pressed
Button = 6 - Eraser in proximity with side button 1 pressed
Button = 7 - can't do this, I don't think.
A little explanation from the wacom docs...
# When the eraser is in proximity of the tablet, or the second side switch is pressed while the pen is
# in proximity, then the tablet will transmit a switch number of 4. When the eraser tip is pressed
# against the tablet, or the second side switch is pressed while the pen tip is pressed against the
# tablet, then the tablet will transmit a switch state of 5.
# Note that the tablet cannot detect the difference between an eraser in proximity and a pen tip with
# the 2nd side switch pressed in proximity (switch state 4), and it cannot detect the difference
# between an eraser pressed against the tablet and a tip pressed against the tablet while the 2nd side
# switch is pressed (switch state 5).
# Note: The WACOM drivers differentiate between the eraser function and the second side switch
# function by analyzing the first switch state transmitted after the pen enters proximity: if the initial
# switch state is 4, the driver assumes that an eraser is now in proximity, and if the initial switch
# state is 0 and changes later to 4 or 5, then the driver assumes that the pen tip is in proximity and
# that the 2nd side switch was pressed at the later moment.
Back to the rest of the packet:
Following the status byte, there are 2 bytes of X coordinate, and 2 bytes of Y coordinate, both of which
are clipped to the maximum dimension as specified in the register 1 packet, then one byte of signed pressure, with -128 being the minimum / off tablet reading, and 127 being the highest, and a signed byte each for x tilt and y tilt. X tilt is negative to the left, y is negative *away* from the user.
For a puck, pp, tx and ty will be zero
OUT OF PROXIMITY
When the tool moves out of proximity, you will get a packet with a status of '80' or 'A0' (depending on tool),
with last received data in the rest of the packet. The status byte will look like this, even if a button was
pressed as the tool went out of prox.
ss = %10x00000
Macro buttons are indicated by a single "out of proximity" message, but with the button depressed flag set, as follows:
Talk R0 %10x1xxxx 00 bb 00 00 00 00 00
bb is the button number, and the x's in the status byte change depending on tool and button used. All other data is zero.
The Stylus seems to need occasional R2 packets as well, not sure what this is for, there seems no rhyme or reason
to when they are requested, and what they contain seems random. 8 bytes of random. They are requested *directly*
after an Talk R0 event (i.e. not polled), and followed, again immediately, immediately by an talk R0.
They appear to be applied to device address ^ 0x08, which is unused (by chance?) but that could be my stupid
analyzer setup playing up. I have no idea what these are, anyway, but the R0 data seems to be enough to be going
on with for the moment.
R2 Data (without driver installed)
Further analysis needed on this
R2 appears to always return data, it could be polled without requiring a kernel extension at all, but we'd have to deal with
(i.e. block) the R0 data being picked up by the mouse handler. Not sure what the format of the status byte in R2 is, the rest
seems consistent with R0 and the handler having been changed.
Device Original New Register 1 Who
UD-0608-A 0x3a 0x68 38 20 50 00 3c 00 06 17 Me
UD-0608-A 0x3a 0x68 38 79 50 00 3C 00 06 17 Adam Ladds (firstname.lastname@example.org)
GD-0912-A 0x6a 0x6a 04 12 77 10 5d fc 00 07 Bernhardt (tabletmagic forum) (confirms scaling at 2450dpi)
ADB Parser from Griffin links 3a to "ArtZ" models, 6a to "Intuos", which might well make sense. Were there any other families with ADB interfaces?