Thread
Skunkworks PS-2 <-> ADB Project
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
< room to copy relevant posts, etc. >
http://en.wikipedia.org/wiki/Apple_Desktop_Bus
http://en.wikipedia.org/wiki/Apple_Keyboard
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:
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 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!
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.
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:
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/idcplg?IdcService=SS_GET_PAGE&nodeId=1824&appnote=en011062
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/idcplg?IdcService=SS_GET_PAGE&nodeId=1824&appnote=en011062
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! }
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! }
My only contribution to this thread is to put in an official vote for the 6502.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.
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! :approve:
] ]'>. . . 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! :approve:
Have you looked at what Unicomp offers? Is this not enough keyboard for you?http://pckeyboards.stores.yahoo.net//122keyterkey.htmlI'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! [}] ]'>
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 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.
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.
$99.00! Och! Are ye daft mon?!? 8-oHave you looked at what Unicomp offers? Is this not enough keyboard for you?
Check some of these babies out! Nimitz Class KBD & more . . . [
] ]'>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.
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.
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
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.)Does this mean we can work on a USB > ADB adaptor?
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 . . .
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 . . .
Why not? The market is flooded (or was...) with USB to PS/2 adaptors that came with mice & men keyboards.It is, however, way outside the scope of this.![]()
'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.
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?
)
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?
) 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?
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?
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.Trash, I'm pretty sure you're conflating USB peripheral vs. host devices again. (Granted, I'm having trouble following things again.)
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.
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.
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 >
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 >
And there are a number that have USB Host in hardware, too, with standard HID drivers.There are some small microcontrollers that are fast enough to do USB Host in software
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.
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.It's the ADB side you need to figure out
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)
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.
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.
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 . . .
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 . . .
Indeed, sir, you are.I may be reading this the wrong way
I was referring to myself, slinking off to work on something else, not you; "he says..." being what I thought was a reasonably well known self-referential meme - my mistake. An attempt to acknowledge my slight twinge of guilt that, though I make what seems an obvious suggestion, I do not at this time plan to participate in bringing it about, as I am trying to focus on one project at the moment. The comment was aimed at no-one apart from me - and the suggestion itself - aimed at no-one but whoever might stumble upon it and decide to make use of it.
I'm certainly not "sick of" your anything right now. As far as I can tell, your contributions hereabouts are quite valuable. I too tend to have a thousand and one plots and schemes bubbling away in the back of my mind, and give myself an excruciatingly hard time about lack of focus and follow-through. Hence, trying hard not to get distracted by the new shiny.
I know - and thus you're already a few ahead of meI've completed a few as time allowed
Nah, I'm good thanks.
I'm going to wrap up my Plus keyboard project first before getting distracted by another project. ADB is on my list, I just need to complete a couple other things first. I've got the documentation I need for ADB, and I think the same board as the Plus keyboard project will work fine for ADB too. But I've got rev0 PCBs for the Plus project on the way from seeed as I type this. The intent is to have them plug in to the mass produced stm32f0discovery board. But being my first PCB evar, I'm sure it will take some refinement. Electronics projects take forever waiting on parts.
I'm going to wrap up my Plus keyboard project first before getting distracted by another project. ADB is on my list, I just need to complete a couple other things first. I've got the documentation I need for ADB, and I think the same board as the Plus keyboard project will work fine for ADB too. But I've got rev0 PCBs for the Plus project on the way from seeed as I type this. The intent is to have them plug in to the mass produced stm32f0discovery board. But being my first PCB evar, I'm sure it will take some refinement. Electronics projects take forever waiting on parts.
