• Updated 2023-07-12: Hello, Guest! Welcome back, and be sure to check out this follow-up post about our outage a week or so ago.

TashTrio: ADB Keyboard, Mouse, and Modem too!

tashtari

PIC Whisperer
This project is sort of an offshoot from TashKM but it's got at least one feature that is and will be unique to it, so...

Introducing... TashTrio!


Elevator Pitch

It's an ADB peripheral which appears to the computer as a trio of ADB devices: an extended keyboard, a mouse, and a Global Village TelePort ADB modem, contained entirely within a single Microchip PIC12F1840 (8 pins, ~$1.50) microcontroller.

The behaviors of the emulated ADB keyboard and mouse are directed by a PS/2 keyboard and mouse which are connected to it; the emulated modem's data is transmitted and received to/from a host connected on the PIC's UART. In effect, this allows a broader range of input devices, including ones still widely available as new, to connect to an ADB Mac as well as giving it a third (albeit slow) serial port.


Project Status

Firmware is stable and working on a breadboard, no PCB yet.


Caveats

Emulation of the modem is incomplete; the firmware ignores a lot of commands sent to the modem which are not important for the modem's ability to function as a serial port. The TelePort ADB modem driver does not appear to acknowledge baud rate being set on the serial port that it emulates, so the baud rate of the PIC's UART is set via special key combinations on the keyboard.

The PS/2 keyboard requires power in order to report any keystrokes, therefore a Mac that can be powered on via the power key cannot be powered on using this device.

Because of the way the PIC12F1840's limited pins are used, the PS/2 keyboard and mouse share a clock pin. As far as I know, this is not something that is often (ever?) done, but the protocol seems to allow it and I haven't had any problems with it. The keyboard's data pin is input-only to the PIC, and as such, its LEDs cannot be controlled.


What's Next

Making a PCB, primarily. There are a few minor features that I could implement surrounding the PS/2 mouse, too, such as adjusting its resolution and using the scroll wheel for something, and I may take these on as well.


Code

 

rabbitholecomputing

Vendor The First
And now, there's a hardware reference design for TashTrio, appropriately named PS2ADB. We're working on a 3D-printed enclosure, since there's exposed +5 volts DC on the bottom of the PCB. We'll be releasing the schematic for it in the near future. Anybody who would like to know more about PS2ADB, and ask questions, is welcome to do so at in this PS2ADB-specific thread

PS2ADB.JPG
 

tashtari

PIC Whisperer
Could you technically use an old serial mouse on the serial port?
The PIC could talk to a serial mouse over its UART if there was some provision made to power it (I think they siphon power from one of the flow control lines). That said, the firmware currently does not support this and probably won't in future.
 

Angelov68k

Member
Finally, I took a crack at it!
Programmed the PIC12 and dropped up a minimal circuit board for it.
Mouse is cruising along perfectly, but the keyboard does not work.

I noticed every time I'm jiggling the PS2 mouse and hitting a key on the keyboard simultaneously, the mouse pointer freezes for just a blink. Checked my connections over and over, everything seems solid.

The 5K pullup resistors for the PS/2 inputs that I use... Could it be that the resistance value's not right? I read something like 1k to 10k should be fine.

Ideas?
 

tashtari

PIC Whisperer
Hm. The behavior with the mouse cursor freezing for a split second doesn't surprise me, one of the compromises I made with TashTrio (in order to fit it into an 8-pin PIC) was that the PS/2 mouse and keyboard share a data line, so they can't talk at the same time. The fact that the keyboard isn't registering at all makes me wonder if there's something about the keyboard's signalling that's outside of spec - or outside of what I expected, at least. Do you have another PS/2 keyboard you can try it with? Is the nonworking keyboard PS/2 only or is it a dual protocol one that speaks PS/2 or USB? And last, but not least... do you own a scope or logic analyzer? =)
 

Angelov68k

Member
The keyboard is a good old Cherry "MY 3000 R/M" (G81-3000LRNDE) that is native PS/2. I use it on another computer and it is working. It looks it gets powered up (three lights blink for a second) and the cursor freeze on keypress might mean it is trying to talk back. No other PS/2 keyboard around to check with it... but I have scope and logic analyzer :D
 

tashtari

PIC Whisperer
Can you get a trace of the PS/2 clock and data lines when pressing a key on the keyboard? I'm hoping there will be something that stands out...
 

Angelov68k

Member
On a very brief test, I could not see anything.
First, I tested the board without chip, connected to ADB for power and only the keyboard.
Connected the logic analzer to PS2 CLK and PS2-Keyboard DAT pins (RA2, RA3).
Inside the logic analyzer software, I set a decoder for PS/2 protocol and I can see the keycodes coming and being decoded correctly.
During the entire time the voltage is stable 5.

index.php

photo_5438642788741796837_x.jpg



Then I repeated with the PIC in the socket - still the same behaviour, looking rather OK to me...
photo_5438642788741796845_w.jpg

photo_5438642788741796858_y.jpg

Do you maybe see something already or we need more specific tests? Is there a diode or something required for the RA3 pin?
 

Attachments

  • photo_5438642788741796834_y.jpg
    photo_5438642788741796834_y.jpg
    95.5 KB · Views: 82

tashtari

PIC Whisperer
Nope, that looks pretty textbook to me... hrm. You shouldn't need a diode for the RA3 pin. I suppose you could vary the value of the pullup resistors, but I'm skeptical that that's the problem. Have you tried plugging the keyboard in by itself, without the mouse? Maybe the mouse is somehow interfering with the keyboard, but I'm kind of grasping at straws. I'll think on this and see if I can come up with anything cleverer...
 

Angelov68k

Member
Yes, I have tried plugging only the keyboard and start. Its lights blink once (gets powered up), and then nothing.

I read in the Microchip AN591 that ADB is open collector and needs a pullup resistor on the other side on its I/O line. I somehow missed that and did not have a pullup there, so I added a 10K one. No change.

In some places I read that the cable types have some relation to the pullup resistors values, so I will try this next. My ADB cable is 2 meters long.

One thing I noticed is when I have ADB I/O line connected to the analyzer, I see bursts in cyclic fashion and when I move the mouse, I see some data being represented but when I press keys, it appears the same way as when I do not press them. It is not conclusive, I have to record it properly to see, but my feeling is that no keyboard commands are output to ADB, while the mouse ones are coming out.
 

tashtari

PIC Whisperer
when I press keys, it appears the same way as when I do not press them. It is not conclusive, I have to record it properly to see, but my feeling is that no keyboard commands are output to ADB, while the mouse ones are coming out.
Yeah, this tracks, the ADB communication with the Mac is working fine (since it can communicate mouse data) but something is keeping the PIC from seeing and thus reporting any data coming from the keyboard.

One thought... how did you program the PIC? Did you use a PICkit3 or something similar?
 

Angelov68k

Member
Oh, no... I programmed it in a DIY way, using FT232R adapter and PICPgm software with properly mapped pins.
At least the PICPgm verified it after recording and I also checked it at least once again after recording.
It seemded fine, but maybe I have to check this once again. Would it make any difference if I flash it with PICkit? Maybe the programming options/configuration bits that I used are not correct?

photo_5447279263599415743_y.jpgpicprg_write.PNG
 
Last edited:

tashtari

PIC Whisperer
I programmed it in a DIY way, using FT232R adapter and PICPgm software
Aha! Now things are beginning to make sense...

Maybe the programming options/configuration bits that I used are not correct?
This is my theory. The keyboard data pin is RA3, which also does double duty as the PIC's reset pin (!MCLR), depending on a bit in the configuration word (specifically, bit 6 of the first configuration word needs to be set to zero). If that pin is configured as !MCLR, not only will the firmware not be able to read its value, but any time you press a key on the keyboard, the PIC will reset, which would account for the brief freezing of the mouse pointer.

By way of background, PICs can be put into programming mode in one of two ways. First, a high voltage (8 to 9 volts on the PIC12F1840) can be connected to the Vpp/!MCLR pin - this is the classic method and always works. Second, !MCLR is brought low and a special sequence is clocked into the ICSP pins (RA0 and RA1 on the PIC12F1840) - this is the low-voltage method and has some limitations: (1) it can be disabled using the high-voltage mode, and crucially (2) it requires RA3 to be !MCLR.

The problem is that if, as I suspect, your FT232R/PICPgm solution is using the low-voltage programming method, RA3 cannot be set as a digital input, because the PIC needs it to be available to tell when to go into programming mode and thus it cannot be used to read the keyboard's input. I'm not familiar with using a FT232R/PICPgm to program PICs, but it may be possible to build a circuit capable of switching a high voltage to Vpp/!MCLR that it can use - I'd be interested to find out, it might put PIC programming within reach of more people. If not, though, you can either get a programmer such as a PICkit3 or ICD3 from somewhere like ebay (PICkit3s usually go for around $30, I suspect these are Chinese clones, but they seem to work well enough), or I can mail you a programmed PIC12F1840, which I'll do for just the cost of the chip itself and shipping, just let me know.
 

VMSZealot

Well-known member
That rocks. Now what about support for joysticks / joypads? That seems to be a function missing from all other ADB adaptors!
 

tashtari

PIC Whisperer
That rocks. Now what about support for joysticks / joypads? That seems to be a function missing from all other ADB adaptors!
My head's mostly in networking land at the moment, but I have some ideas for how this might be accomplished, I did RE the protocol for the Gravis Mac Gamepad, which does correspond nicely to a SNES controller. Out of curiosity, what would you like to see as the device being adapted to ADB?
 

VMSZealot

Well-known member
Honestly, for myself, I have no compelling need - I found myself a Gravis Gamepad and CH FlightStick. But it was a long hunt, and I would definitely have bought a device like this if one had been available. I'd have thought the way to go would be to make commonly available devices (something like the Logitech input devices) compatible either with the most widely adopted Mac controllers (Gravis Gamepad and CH FlightStick) or, in the case of a game pad), map them to keyboard keys so that no driver is required.
 
Top