Skip to main content
Home Forums Skunkworks PS-2 <-> ADB Project Skunkworks PS-2 <-> ADB Project
Thread

Skunkworks PS-2 <-> ADB Project

Skunkworks PS-2 <-> ADB Project Peripherals 45 posts Mar 25, 2012 — Jun 21, 2013
Here are the shots I promised of my KeyStone Converter:

file.php


file.php


file.php


file.php


file.php


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... :b&w:

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!

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.

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.

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. :approve:

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.

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! }:)

:lol: Round circuit board & case hack using LEDs in a Tap Light? [;)] ]'>
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. :p
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! [:D] ]'>

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

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

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

In dreams. :-/

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

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/mechanical-keyboard-guide#post_6025204

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.

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.

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.

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:
' *
' * 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
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. :)

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 . . .

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.

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.

Because keyboards back then supported both the HID and legacy PS/2 protocols. the MCU inside the keyboard knew to switch into legacy mode when it detected the PS/2 clock frequency. Optical mice were this way as well, and they too, dont support dual protocols anymore except for more expensive ones.

Some more expensive models still do, but ive noticed the cheapo 10 dollar keyboards that you can pick up at the garden variety store no longer support legacy PS/2 so as soon as you put the little "green" adapter on it, nothing happens.

I'm exhausted, so I'm not sure what I was babbling about earlier, or now for that matter, but here's the link:

USB <- OR -> TTL Seria Adapter Threadl

PL2303HX USB to TTL Converter Module

Since my brain is firing on just three of eleven badly tuned cylinders ATM:

How about just skipping all the wiring mess and converting Bluetooth KBD/Mouse Protocols to an ADB pigtailed receiver box? :o)

Trash, I'm pretty sure you're conflating USB peripheral vs. host devices again. (Granted, I'm having trouble following things again.) To really grossly oversimplify it, it's a lot easier to make a USB peripheral than a USB host, and anything that converted a USB keyboard and/or mouse to ADB would be a *host* while your little TTL->USB toy is a *peripheral* and there's no way to turn it around to be a host.

There are some small microcontrollers that are fast enough to do USB Host in software; example:

https://courses.cit.cornell.edu/ee476/FinalProjects/s2007/blh36_cdl28_dct23/blh36_cdl28_dct23/index.html

It implements enough of a low-speed USB 2.0 hub on an AVR32 to drive a mouse and convert its output to serial. There are also "prefab" USB host chips that can be used to offload the entire USB protocol stack into a "black box":

http://www.ftdichip.com/Products/ICs/VNC1L.htm

Thus if you really wanted to use USB devices instead of PS/2 if you certainly *could* use them without an impossible amount of effort. Really though, if you're talking about actually *developing* something I'd strongly suggest using PS/2 devices for the initial version simply because PS/2 is basically known backwards and forwards, there's tons of driver code you can steal, and it's simple from an electrical and timing standpoint. It's the ADB side you need to figure out, why pile on complexity on the front end when it's the back end you're worried about?

Trash, I'm pretty sure you're conflating USB peripheral vs. host devices again. (Granted, I'm having trouble following things again.)
Indubitably, I can't follow anything involving the concepts of USB, MicroController or programming for I/O involving these when they're involved in a single project.

But thanks for your continued tuteldge.

Reason:

My mind is a visual conflagration of competing conceptual imagery, roiling, boiling, melting and fusing in seemingly endless confusion that makes sense in certain snapshots.

Strategy:

I've given up on trying to fully understand or DO any hacks beyond the NuBus Architecture and 6500 PCI level projects already on my plate. However, I HAVE decided to keep bringing up the crazy notions I come up with like this last, because the next couple of generations of hackers are fluent in the languages that are my weaknesses.

When I make my inevitable, mistaken, uninformed impressions as clearly as I can in .TXT, there are corrections forthcoming from knowledgeable old guard brothers-in-arms such as yourself and younger comrades like Bunsen. Such corrections/explanations will remain lost on myself, but will remain useful to those comrades with the ability and will to go to hacking heights/depths into current/less ancient architectures where I care not tread.

Excuse for continued posting of apparent drivel:

My mistake in buying the <$3.00 USB <- OR -> TTL converter :?: for the Duo's Modem Bay inspired two competent comrades to assault the obstacle by flanking manouvre.

It's all right, I hope I didn't sound too snippy. The world needs "idea men", don't get me wrong.

I don't know if it would help much, but maybe here's an analogy that might help for understanding USB in the future: USB peripherals are like drill bits and accessories. There's all sorts of cool things you can attach to a drill: spade bits, sanding disks, hole saws, screwdrivers, miniature lathes... heck, I've used a hand drill powered emergency sump pump before. The one thing all drill bits have in common is they need to be chucked onto a *drill* before they can work. The drill is the USB host, which is almost always a "computer". Just like there's no way you can chuck two bits together and have them do anything useful there's no way you can take a USB peripheral and connect directly it to another. Without a "drill" there's no "power", and thus you are dead in the water before you start.

This is basically how it works. USB is point-to-point, not really a bus at all. A given USB host device can talk to one peripheral device at once, and the host directs the entire conversation. I know, wait, what about USB hubs? In this analogy imagine that a USB hub is a sort of gearbox that can transfer torque from one input "drill", the host, to any of a number of output shafts. When a computer is using multiple USB devices "at once" on a hub it's actually shifting the "transmission" rapidly from one device to another. USB devices are not like Firewire or SCSI, which are peers of the host interface and have their own busmastering capability; USB devices are complete slaves to the host and cannot talk directly to each other. You *need* a host of some sort, be it a full-fledged computer or a minimal microcontroller-based implementation, to drive the conversation, and no off-the-shelf peripheral like a USB-to-serial converter is going to have the brains to be the host.

(The one exception is "USB On-The-Go", which is a specification for things like mobile phones or media players, which sometimes act as USB peripherals and sometimes act as hosts. A good example of this is the USB cable that Apple sells for iPods to let them download photos from a digital camera on the go. When the iPod is plugged into your computer it's a peripheral emulating a hard disk, but with the digital camera cable the iPod is a host for the camera, which itself is probably emulating a USB storage device. But really what the specification covers is how in the case of two OTG devices cross-connected to each other they negotiate which should be the master and which should be the slave. Once the devices have chosen their role they then act like normal USB hosts or peripherals respectively.)

Anyway. Maybe putting it in those sort of terms might help. But if not, no worries.

mp.ls