Skunkworks PS-2 <-> ADB Project

[Trash80toHP_Mini]

This ad hoc hack committee got its start in this thread: Anyway to use a PS2 keyboard with my Mac SE Superdrive?

< room to copy relevant posts, etc. >

http://en.wikipedia.org/wiki/Apple_Desktop_Bus

http://en.wikipedia.org/wiki/Apple_Keyboard

[Trash80toHP_Mini]

Here are the shots I promised of my KeyStone Converter:

[zuiko21]

OK, now we're talking

First of all: please cover that EPROM quartz window! We don't want that valuable code erased by ambient UV light...

I shouldn't be writing this (nor even lurking the 68kmla forums) becasue I'm on the last days of a terrible fortnight at work... but I promise to get back to this very interesting project as soon as possible -- not only for the convenient use of popular PS/2 keyboards, but because it may shed some light on the obscure ADB protocol...

Let's go with the ICs: the brain of this device is the Micro Controller, MC68L11D0 -- this is one of the many variants of the popular MC68HC11, with the following differences:

-Works on supply voltages as low as 3 V (although 5 V is fine with it)
-Has no built-in ROM (the -D0 part)

Like many other MCUs, this family may work, among others, in two modes: single-chip (code is executed from internal ROM, and most pins are dedicated to I/O functions) and extended-multiplexed mode; where data and address buses are externally accesible, and code is to be found on an external (EP)ROM chip. This version lacking the internal ROM, obviously is configured to work on this last mode. From my datasheets, it seems that this one can't go over 2 MHz.

Then there's the TC232CPE, close to a bunch of electrolytic capacitors... as the name suggests, this is an equivalent of the popular MAX232, just a converter from TTL/CMOS levels to the +12...-12 V required by th RS-232C serial port -- all from a single +5 V supply!

The EPROM is a 27C64-200DC: a mere 8 KiB EPROM in a rather slow (200 ns) version -- nothing out from the ordinary and shouldn't have that much code to investigate... anyway, this is easily read/copied on the cheapest EPROM programmer (it is socketed, isn't it?)

The remaining ICs are simple logic devices: 74LS05 (open-collector inverters), 74HC00 (quad 2-input NAND gates) and featuring the 74HC573: 8-bit latch for the multiplexed address/data bus.

Save for capacitors and resistor packs, passive components are clear -- although the exact frequency of the crystal might be critical for the interface timing.

The PCB seems to be a simple 2-layer design... shouldn't be that difficult to reverse-engineer -- as soon as I get some time, of course. I don't expect many surprises with the well known pinouts of these ICs, but another picture of the board with the ICs off from their sockets could discard any doubts...

For the general public information: the Keyboard input on your device is the older AT standard on 5-pin full-size DIN connector, but this is electrically compatible (protocol included) with the PS/2 standard, just using a 6-pin Mini-DIN.

So many hacks, so little time...

[Trash80toHP_Mini]

The board is most always in its case and I was careful not to have any sunlight available to the quartz window. But I'll cover it up!

I knew about the AT connector, I just can't find my adapter . . . also forgot to mention the traces & a few jumper wires are all out there in the open, Two layer PCB it is!

Today, I'll look for the OmniView Converter to document, it works with "Windows KBDs". IIRC you needed to choose either the left of right control key to use as the Command Key. It also does a full KVM conversion, which isn't necessary for Sam's case, but would be for a non-AIO Mac or the KVM setups I habitually use.

Pics up of empty socketed KeyStone and OmniView box coming up!

[Trash80toHP_Mini]

I'd MUCH rather see these boxes clean-room cloned rather than copied, we don't allow software piracy . . .
. . . as a mod, I can't condone outright hardware/firmware piracy.

[zuiko21]

Right. As already mentioned, the main use for this is not the mere keyboard adaptation (with ADB peripherals sort-of-readily available) but to learn things about the ADB protocol. That would imply examining the original code in order to get the required specs of the protocol, and then creating from the scratch some new code (not necessarily for this MCU) with similar functionality. Is that OK?

The 68HC11 being a derivative of the 6800 family, like the 6502 I'm used to, makes the task of interpreting the original code, by no means a trivial task, but at least feasible.

[Trash80toHP_Mini]

NoPro, DeclROM spelunking & ROM tweaking are time honored traditions here at the 68kMLA. Outright copying for re-use as is, with the exception of missing or damaged ROMs, or requesting images for emulation purposes, would be the only intolerable aspects under current policy, AFAIK.

[dougg3]

I'm (mostly) fluent in 68HC11 assembly language if needed...

Also, here's an interesting MIcrochip application note about making an ADB device using a PIC microcontroller. Looks like it provides a lot of the necessary info no matter what the microcontroller is!

http://www.microchip.com/stellent/idcpl ... e=en011062

[Trash80toHP_Mini]

If we actually clone this device, let's spec a large enough ROM and the lines for it to implement a programmable key re-mapping device.

[MidnightCommando]

As per OtherThread...

Has anyone looked at the Keyboard Babel project for ADB -> PS/2 conversion to implement in a microcontroller of some description? They've done a great job documenting the low-level protocols for various means of turning button-mashing into characters.

Dealing with the mouse could be done in discrete logic with apparent ease, if the stream of bits coming down the serial or PS/2 could be reduced (again, on a micro) to its base "events" - motion forwards/backwards on axis x/y, and button_down and button_up - examining how the teardrop ADB mouse does this would be a good strategy to reproduce the desired behaviour. Better yet, a two or three button ADB mouse (such as the one on some NeXTstations?) so that it's apparent how to handle multiple buttons. Not sure how scroll wheels would work, but examining existing implementations would once again prove beneficial there.

An elegant solution taking minimal space would involve a CPLD with a softcore microcontroller onboard (6811, 6502, whatever), and using the remaining space for the (negligible) logic necessary to turn mouse input into Magical Wonderful ADB Goodness.

Even were one not to use a CPLD, such a converter could be made sufficiently compact by the use of SMT devices and (of course) a double-layer PCB.

Of course, to be truly impressive, the Power button needs to be a big red palm-sized thing on the top of the converter, not that tiny little thing on the Keystone box ... we need some sense of theatrics after all!

[Trash80toHP_Mini]

Round circuit board & case hack using LEDs in a Tap Light?

[olePigeon]

An elegant solution taking minimal space would involve a CPLD with a softcore microcontroller onboard (6811, 6502, whatever), and using the remaining space for the (negligible) logic necessary to turn mouse input into Magical Wonderful ADB Goodness.

My only contribution to this thread is to put in an official vote for the 6502.

[Trash80toHP_Mini]

While I appreciate the significance of the 6502, I'd much rather see an overkill Proc with enough I/O lines to do ASCII conversion of old VT100 KBDs and all the crazy layout WorkStation Clicky-Boards. I, for one, am getting really tired of MembraneMushPush .TXT input devices. Let's do some ReallyRetro forward I/O compatibility with this puppy as well as the obvious backwards conversion of the current crop-o-KBDcrap!

. . . gotta dig out some pics from old threads . . .

This is another vote for programability of multitudinous command key sets with Alps KeySwitches Inside!

. . . and a Newton KBD would go great sitting in front of my CD SC NetTop hack!

[Mk.558]

Does this mean we can work on a USB > ADB adaptor?

We already have ADB > USB. But optical mice rule on old games.

[Trash80toHP_Mini]

In dreams.

That's for another thread and not likely to happen, this one is for real.

[MacJunky]

I'd much rather see an overkill Proc with enough I/O lines to do ASCII conversion of old VT100 KBDs and all the crazy layout WorkStation Clicky-Boards. I, for one, am getting really tired of MembraneMushPush .TXT input devices. Let's do some ReallyRetro forward I/O compatibility with this puppy as well as the obvious backwards conversion of the current crop-o-KBDcrap!

Have you looked at what Unicomp offers? Is this not enough keyboard for you?
http://pckeyboards.stores.yahoo.net//122keyterkey.html
And look at the options you have for connectivity!

More here: http://pckeyboards.stores.yahoo.net//keyboards.html
And here is a list that has some details about a few of our modern options: http://www.overclock.net/t/491752/mecha ... st_6025204

[techknight]

I wrote AVR code to read a PS/2 mouse and output its direction, button status and amount the mouse has moved in a project to connect an optical PS/2 mouse to a mac plus, a project that never materialized. Written in BASCOM-AVR. I could publish it if it would do anyone any good, and could finish what I started.

I never messed with the ADB protocol.

[techknight]

I found a GNU based full ADB library for the AVR series in C. One problem, i dont program in C so some of the operators throw me off.

my PS/2 code is written in BASIC, which that compiler is not free. So you would have to find PS/2 source code in C which i dont i have, or i could convert the ADB library to BASCOM BASIC. either way.

[Trash80toHP_Mini]

Have you looked at what Unicomp offers? Is this not enough keyboard for you?

$99.00! Och! Are ye daft mon?!?

Check some of these babies out! Nimitz Class KBD & more . . .

[techknight]

Well, i use BASCOM for alot of things including commercial based stuff for work. So I have it. lol. The Demo version is fully functional and will compile up to 2K of code for the 2313. which is what my PS/2 routine is written for.

I just dont do C, or i would have written everything in C and did it the freeway that way. I could do ASM, but.. well... heck with that. lol.

[techknight]

eh, have a looksee anyway.

Might be useful, then again, it might not be. but its published now for your eyes to see.

Alot of this could be optimized and cleaned up, such as the 2 dedicated I/O pins for active pulldowns really arnt necessary, but it was my first attempt at working a protocol, and it works. lol.

Remember now, the original intent which was never finished, was using a PS/2 based mouse on a Mac 128/512/Plus so it was provisioned to emulate the square wave encoder signals but i never got that far, so debugging routines are in there, for example LEDs are used to indicate the mouse movement, and positioning information.

Code: Select all

' *
' * Title         : PS2.bas
' * Version       : 1.0
' * Target        : ATTiny2313
' * Author        : techknight
' * Program code  : BASCOM AVR
' * Hardware req. :
' * Description   : IBM PS/2 Mouse to Macintosh Bus Mouse translator
' * TODO          : Timeouts need added into PS/2 routines to prevent hangs
' *
' ***************************************************************************
'$regfile = "attiny2313.dat"                                 ' use the Tiny2313
$regfile = "2313def.dat"
$crystal = 18432000                                         ' at 18.432mhz


'Configure the data direction registers for port D
'PD0 PS2 Data
'PD1 PS2 Clock
'PD2 PS2 Data PullDown NPN Transistor
'PD3 PS2 Clock Pulldown NPN Transistor

'PB0 Y interrupt
'PB1 Y direction
'PB2 X interrupt
'PB3 X direction
'PB4 Mouse Button 1

Disable Interrupts

Config Portd = Output
Config Portd.0 = Input
Config Portd.1 = Input
Config Portb = Output

Portd = 0                                                   'turn all internal pullups OFF and outputs to 0
Portb = 0
Portd.3 = 1                                                 'inhibit communication between any PS/2 device

Dim Temp As Byte
Dim Temp2 As Byte
Dim Count As Byte
Dim Index As Byte
Dim I As Byte
Dim Ps2 As Byte
Dim Parity As Byte
Dim Status As Byte
Dim Movex As Byte
Dim Movey As Byte
Dim Button As Byte

'PS2 data send/receive routines

Declare Sub Sendps2(byval A As Byte)
Declare Sub Recps2
Declare Sub Initmouse



'Main Loop
Call Initmouse

Do
Call Recps2
Status = Ps2
Call Recps2
Movex = Ps2
Call Recps2
Movey = Ps2

'Set mouse button
Portb.4 = Status.0
                                                             'Mouse has moved down
If Status.5 = 1 Then
   Portb.1 = 1
End If
If Status.4 = 1 Then                                        'mouse has moved left
   Portb.3 = 1
End If
If Movex > 0 And Movex < &H7F Then                          'mouse has moved right
   Portb.2 = 1
End If
If Movey > 0 And Movey < &H7F Then                          'mouse has moved up
   Portb.0 = 1
End If
If Status.7 = 1 Then
   Portb.0 = 1
End If
If Status.6 = 1 Then
   Portb.2 = 1
End If
Waitms 5
Portb = 0

'DEBUGGING ROUTINE... Flash out byte PS2 and HALT
'I = 0
'For I = 7 To 0 Step - 1
'Portb.1 = 1
'Portb.0 = Status.i
'Wait 1
'Portb.1 = 0
'Wait 1
'Next




Loop









'This subroutine prepares the PS/2 Slave device for a data transmission from the AVR Host...
'data byte in A is written to the slave device
Sub Sendps2(byval A As Byte)
Parity = 0
I = 0
Ps2 = 0
Count = 0
Temp2 = A

Portd.3 = 1                                                 'pull clock low, inhibit communication
Waitus 100                                                  'wait 100 microseconds
Portd.2 = 1                                                 'pull the data line low
                                                            'Request to Send

Portd.3 = 0                                                 'Release the clock line

Do
Loop Until Pind.1 = 1                                       'wait high/low transistion. data valid only on low transition
Do
Loop Until Pind.1 = 0


Do
   Shift Temp2 , Right
   Temp = Sreg And 1
   If Temp = 1 Then
      Portd.2 = 0                                           'Release data line, pulls high
      Parity = Parity + 1
   Else
      Portd.2 = 1                                           'pull data low
   End If

   Do
   Loop Until Pind.1 = 1                                    'wait high/low transistion. data valid only on low transition
   Do
   Loop Until Pind.1 = 0

   I = I + 1
Loop Until I = 8


   If Parity.0 = 0 Then
      Portd.2 = 0                                           'if even parity, set data line high by turning off pulldown
   Else
      Portd.2 = 1                                           'otherwise its odd parity so set data line low turning on pulldown
   End If

   Do
   Loop Until Pind.1 = 1                                    'wait high/low transistion. data valid only on low transition
   Do
   Loop Until Pind.1 = 0

   Portd.2 = 0                                              'release the data line

   Do
   Loop Until Pind.1 = 1                                    'wait high/low transistion. data valid only on low transition
   Do
   Loop Until Pind.1 = 0


   If Pind.0 = 1 Then                                       'If no ACK received, then we try it again 3 times
      Portd.3 = 1                                           'inhibit communication and try resending again.
      Goto Sendps2
      Count = Count + 1
      If Count = 3 Then
         Ps2 = &HFF
         Exit Sub
      End If
   End If

   Do
   Loop Until Pind.1 = 1                                    'wait for clock to go idle high

   Waitus 50
   Portd.3 = 1                                              'Inhibit communications after transmission

End Sub




'This subroutine recieves back any data that the PS/2 slave device may have in its buffer.
'Data and Clock lines get set to idle state and listen for any responses from the device
'Received data byte stored into variable PS2
Sub Recps2
Parity = 0
I = 0
Ps2 = 0

Portd.3 = 0                                                 'release the clock and data line to idle = high
Portd.2 = 0                                                 'Ready to Receive

Do
Loop Until Pind.1 = 0                                       'wait until clock transistion low

If Pind.2 = 1 Then Goto Recps2                              'if data high, false start bit received, re-call routine


'Read in 8 data bits
Do

   Rotate Ps2 , Right , 1                                   'Rotate the data bits by 1

   Do
   Loop Until Pind.1 = 1                                    'wait high/low transistion. data valid only on low transition
   Do
   Loop Until Pind.1 = 0

   If Pind.0 = 1 Then
      Set Ps2.7
      Parity = Parity + 1
   Else
      Reset Ps2.7
   End If

   I = I + 1

Loop Until I = 9                                            '0 is a state in this sense.

Do
Loop Until Pind.1 = 1                                       'wait high/low transistion. data valid only on low transition
Do
Loop Until Pind.1 = 0

'parity bit is 0 on an odd number of 1's
'parity bit is 1 on an even number of 1's
'So, we test on the condition of bad parity.
'so if we had 3 1's, and parity bit is 1, packet is BAD.
'or vice-versa, even number of 1's and 0 parity bit.
'otherwise, packet recieved properly
If Parity.0 = 1 And Pind.0 = 1 Then
   Portd.3 = 1                                              'inhibit communication forcing clock low
   Call Sendps2(&Hfe)                                       'Call for Resend on bad parity and try again
   Goto Recps2
Elseif Parity.0 = 0 And Pind.0 = 0 Then
   Portd.3 = 1
   Call Sendps2(&Hfe)
   Goto Recps2
End If

Do
Loop Until Pind.1 = 1                                       'wait high/low transistion. data valid only on low transition
Do
Loop Until Pind.1 = 0

If Pind.0 = 0 Then                                          'stop bit is logical 1, if 0 then bad transmission try again..
   Portd.3 = 1
   Call Sendps2(&Hfe)
   Goto Recps2
End If

'otherwise, if we pass all this crap above, then yay the PS/2 packet was received properly.

Portd.3 = 1                                                 'Transmission recieved, inhibit communication to allow time for processing

End Sub





'This subroutine initializes a PS/2 mouse and puts it into data reporting mode.
'When in data reporting mode, any movment or action from the mouse, it will transmitt bytes
'back to host when lines are idle (logic high), otherwise it buffers until overflow, or lines release
Sub Initmouse
Index = 0
Ps2 = 0

Do
   Call Sendps2(&Hff)                                       'Reset the mouse
   Call Recps2                                              'Receive the ACK
   If Ps2 = &HFA Then                                       'is ACK ok?
      Call Recps2
      If Ps2 = &HAA Then                                    'Self test passed?
         Call Recps2
         If Ps2 = &H00 Then                                 'is PS/2 device a valid mouse?
            Call Sendps2(&Hf4)                              'Enable data reporting streaming (sends data on mouse movement or action)
            Call Recps2
            If Ps2 = &HFA Then                              'did mouse ACK the sent command?
               Ps2 = 0
               Exit Sub                                     'mouse initiliazation passed
            End If
         End If
      End If
   End If

   Index = Index + 1
Loop Until Index = 3

Ps2 = &HFF                                                  'mouse initialization failed

End Sub








[MidnightCommando]

Does this mean we can work on a USB > ADB adaptor?

That's actually be relatively simpler - all you need is something to decode USB HID (very very very very very standard) and turn it into ADB (which this project will make more feasible, hopefully.)

It is, however, way outside the scope of this.

[Trash80toHP_Mini]

Start a new thread, this is the forum of impossible dreams.

I've been wondering if we can do something with my >$3.00 Serial -> USB toy. It's single direction, but maybe we can do a wireless connection with a USB Nubbin inside an ADB or ASCII KBD?

I'm on break, I'll post a link to the thread later . . .

[techknight]

code and schematics for the ADB to USB exist already. thats how i found the ADB library for AVR in C.

Oh wait, your trying to go the other way with it. lol. nevermind.

[Mk.558]

It is, however, way outside the scope of this.

Why not? The market is flooded (or was...) with USB to PS/2 adaptors that came with mice & men keyboards.

'Sides, there goes the question...why not? What is not known about the USB standard? We (might) have the working elements of a ADB controller, so a simple microcontroller (ahem Arduino? nah that's probably way over, but if it wasn't done with an Arduino than it wasn't proper) with the code and a small etched or prefabbed circuit board and *KABAM!* we now have not just PS/2 but many other things that could be useful: like USB optical trackballs.