Skunkworks PS-2 <-> ADB Project

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

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

 

[techknight]

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.

 

[Trash80toHP_Mini]

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? )

 

[Gorgonops]

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?

 

[Trash80toHP_Mini]

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.

 

[Gorgonops]

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.

 

[Trash80toHP_Mini]

You didn't come off snippy at all, I wasn't being defensive or apologetic, and thanks for the generous compliment.

The drill/bit analogy/imagery works well for me. I've always thought of USB as the fleet of foot, higher powered, hot-swappable offspring of ADB, which I've yet to make a study of as well. Maybe it's because my thought processes are so in tune with the parallel worlds of the fast and slow I/O buses of the Mac's ancient architectures and the SCSI Peripheral Model that I'm not drawn to the world of serial comms. My brain is more a massively parallel imagery co-processor gone wild, with a stunted verbal center that gifts me with a wonderfully whacky turn of phrase based on wild word combinations when it's working well. But I can't tell a story, a joke or explain a project worth a da . . . whatever . . .

. . . it's fun trying and I can sketch out a concept in isometric detail in seconds when words fail me! :approve:

< overly personal drivel mode alert >

I rather enjoy the respect I get around these parts, and over on 'fritter, as the, crazy, wild eyed creative type/dreamer. It's a role I've always played at in real life, only to finally discover that I was gifted with ADD and, much more recently, the manic-depressive/artistic temperament so well described by Kay Redfield Jameson. Both were tremendous advantages in the graphic arts and sign industries, as well as in the creation of the "font emulator" electronics start-up. My gifts have garnered a lot of respect IRL, I've lived a very blessed life. The most precious blessing of all has been the passing of my penniless/priceless, family inheritance on to my son. Hopefully not the Bi-Polar portion, but he's got the master craftsman's hands of both my grandfathers, the visual abilities and sculptor's touch of his tight cooper great-great granddaddy, my father's and his maternal grandfather's razor sharp intellects, my artistic/creative abilities, coupled with his mother's heart, verbal/social skills and gifted mind as well.

It's almost three years ago today, since my release from the hospital into this most wonderful of my several lifetimes. I mark April Fool's Day, the anniversary of the day HP-Mini brought me back to my longtime virtual homes and sources of comradeship online, and out into the WiFi Coffee Shop Society IRL, as my third birthday. Having found the "where is jt? posts" here while I was in the hospital was a call back to this wonderful new life.

Thanks gang!

< /overly personal drivel mode alert >

 

[Bunsen]

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

And there are a number that have USB Host in hardware, too, with standard HID drivers.

Subject: SCSI for the 512K (or 128?)

seems like you can get ARM Cortexes for under $2 in single quantities these days. Add a handful of bucks for one with lots of built in I/O.
Lots of potentially useful clues in this thread:

http://forums.parallaxinc.com/forums/default.aspx?f=25&m=426250

the latest 32-bit line-up from NXP / ARM Cortex range. / basic 8K/8K 50MHz version / only $1.31 in 100 quantities ($1.76 one off), and only slightly more for 32K Flash versions. What am I doing even thinking about 8-bit'rs? /
Then there was the LPC1343 with built in USB MSC and HID capabilities! Ok, these weren't under $2, but around $5, which is what I pay just for an FT232R anyway. /

A free development environment exists based on the Eclipse IDE.

It's the ADB side you need to figure out

I quite agree. Everything else - PS/2, USB HID etc, is both fully documented and available ready-rolled as open source code, or indeed in hardware. Get one or more micros talking to the Mac first, and then worry about the downstream side.

 

[techknight]

And, that has already been done, discussed in a Microchip PIC application note.

 

[MidnightCommando]

If it's already been done, why are we still sitting around measuring our ... *ahem* hard drive sustained transfer speeds? >_>

 

[techknight]

Wasnt done by me, it was done by Microchip Inc. and the application note is published. I dont use their products so I cant do much with the information, but its out there nonetheless.

 

[Trash80toHP_Mini]

No EPROM erasure indicated, further testing required . . .

Also in this shot of the RadLab:

SuperIIsi™ goodies:

IIsi NuBus Adapter

Radius Rocket33

SCSI II DaughterCard

Radius Studio Array SCSI II RAIDbox

Miscellania and Tanning Salon Equipment:

PowerBook 160 in off config of its on again/off again boot attempt basis trickery

PowerBook 160 Battery Bay BootSafe Security Device

21" Radius PrecisionView 2150 showing off again Video Mode

21" MAG Innovision MX21F video display from pet IIfx

21" ViewSonic G810 Portrait Display

22" ViewSonic Professional Series P225fNinja

(sorry about the brightness and contrast levels: set for clickey input message-n-KBD clarity)

 

[Bunsen]

[ADB] was done by Microchip Inc. and the application note is published

Well then - find a PIC with USB HID support, add the ADB code from their appnote, write a few lines of glue code, bang, done.

(he says, as he slinks off to work on something else...)

 

[techknight]

There is only one problem. I use AVR microprocessors, never used a PIC, so am unfamiliar with how a PIC operates. Thats the whole issue. lol. if the appnote was in AVR, it wouldnt be an issue at all.

Only thing i can really do is study the appnote well enough to convert over to AVR.

Oh, and for the record Bunsen Sir, I may be reading this the wrong way, but the way I read it is your comment was uncalled for. Yes I may have multiple projects, but the information that I had posted is in for a forum for not just I, but others to read. I had even posted code for the AVR that is a fully FUNCTIONAL PS/2 stack for others to read, if i didnt think anyone else could use it, i would have never posted it. You treat me as if I was the only one running this show. There are others that could take the information I posted and do something with it. I am not the only one here.

I realize the comment made, and various others by other members all lead to the basic same thing: Your getting sick of my shit, many projects and master of none. I've completed a few as time allowed, but not all. Anyway, thats no problem, I completely understand, ill stop, so no further comments against me can be made.

 

[Trash80toHP_Mini]

I'm sorry you''re taking it that way, I don't think Bunsen is trying to give you a hard time. In a place like this, with varying level of expertise, interest and curiosity in so many different areas, I feel like it's impossible for people NOT to come off as being flip. I, for one, really enjoy your input here.

There's just too much assumption and not enough real communication going on in the fora. IRC doesn't count, it's what is laid down in .txt in these threads that makes this place a great place to be a member.

It's also what convinces lurkers to become new recruits.

whatever . . . I'm tired and cranky and . . .