14 Jan
2012
14 Jan
'12
12:11 p.m.
Does anyone on the list know if there is an adapter for TRS-80s (Model I/III/IV) to use
PS/2 Keyboards?
Cloud-9 makes one for the Color Computer, but the keyboard matrix between the two families
are slightly different.
My friend has a Model IV with a bad keyboard (the thin film ribbon is damaged) and
replacement keyboards don't come up on eBay all that often.
Thanks!
Al Hartman
14 Jan
14 Jan
1:56 p.m.
I don't have a Mod IV. But if I build something here in Brazil, will you
be able to duplicate it there?
---
Enviado do meu Motorola PT550
Meu site: http://www.tabalabs.com.br
----- Original Message -----
From: "Al Hartman" <alhartman at yahoo.com>
To: <cctalk at classiccmp.org>
Sent: Saturday, January 14, 2012 6:11 PM
Subject: PS/2 Keyboard adapter for TRS-80?
Does anyone on the list know if there is an adapter
for TRS-80s (Model
I/III/IV) to use PS/2 Keyboards?
Cloud-9 makes one for the Color Computer, but the keyboard matrix between
the two families are slightly different.
My friend has a Model IV with a bad keyboard (the thin film ribbon is
damaged) and replacement keyboards don't come up on eBay all that often.
Thanks!
Al Hartman
15 Jan
15 Jan
11:42 a.m.
I don't have a Mod IV. But if I build something here in Brazil, will you
be able to duplicate it there?
Are crosspoint swithc ICs still easily available? (It seems that so many
useful ICs are no longer made ;-(). If so,e it would seem to be posisble
to use one of those to simulate the keyswithc matrix for just avout any
swithc-type keyboard. Add a microcotnroller to decode the PS/2 keyboard
signal then if you detect akey-down code close the appropriate swtich in
the crosspoint array, if you detect a key-up contd open it. OK, there may
be a little more work for keys that were originally mechancially locking,
but that's essentially it, I think.
-tony
11:51 a.m.
=> Are crosspoint swithc ICs still easily available? (It seems that so many
useful ICs are no longer made ;-(). If so,e it would
seem to be posisble
to use one of those to simulate the keyswithc matrix for just avout any
swithc-type keyboard. Add a microcotnroller to decode the PS/2 keyboard
signal then if you detect akey-down code close the appropriate swtich in
the crosspoint array, if you detect a key-up contd open it. OK, there may
be a little more work for keys that were originally mechancially locking,
but that's essentially it, I think.
But Tony, I can do everything with a $2 microcontroller...Why the
crosspoint IC? :oO
16 Jan
16 Jan
1:22 p.m.
=> Are crosspoint swithc ICs still easily available? (It seems that so many
Can you? I am very supprised...
Although having seen the price of crosspoint ICs (which have a much
better spec that uou'd need for this) I can see wanting to avoid one.
However...
The question related to the TRS-80 M1/3/4 keyboard. These keyboards are
memory mapped. I don't man that they are controled by memory mapped
ports. I maena that the keyboard appears to the CPU as being 256 bytes of
memory.
The keyboard column lines (say) are the 8 low-oeder CPU address lines,
fed through open collector buffers. The keyboard row lines go to a
3-state buffer and then to the CPU data bus. This 3-state buffer is
enabled by the system address decoder whenver an address in the 256 bytes
assigned othe keyboard is accessed.
The normal keyboard scan refrences addeesses xx01, xx02, xx04, xx08,
xx10, xx20, xx40 and xx80 in order, thus selecting one column at a time.
But you don't _have_ to do that. In particular you could look at one
column only (if say all you wanted to detect was the BREAK key). Or you
can look at other addresses to get the logical OR of the keys in those
columns. In partocular looking at address xxFF will indicate if any key
is pressed. These tricks might not be used by the ROM or standard OS
drivers, but they work on all m,achiens, and I know some applciation
software (games, etc) used them.
The keyboard column lines, being simply the low 8 address lines are
chaning all the time whether the machine is reading the keyboard or not.
You get the low half of every memory, I/O and refresh address there.
So what your device has to do is to detect every change of the address
lines and present the apporpriate logical OR of the key states to the
inputs of the buffers. And you have to do that iwthin the read cycle time
of the Z80 processor (which could be clocking at 4MHz in an Model 4).
Yo do not have the keyboard read-enable signal available on the keyboard
connector (at least not in an M3 or M4) since the buffers are on the CPU
board. You might be able ot get it by solderign a wire ot the appropriate
pin on the CPU board, I am not sure if it's an avaialve signal on the
later 'gate array' machines, though.
So what you have to do is detect every change of the column lines 9which,
rememebr are CPU address lines) and output the appropraite pattern to the
inputs of hte 3 state buffers within, say, 500ns. While also decoding
PS/2 data from the keyboard, of course
But even if you have the enable signal, and if you've stored the effective
contents of all 256 possible keyboard laocations, you still have to get
the address, pick the right one of those 256 values and get it on the
3-state buffer inputs in 500ns. Again while decoding PS/2 data.
The first seems ot be a very tall order, the later just a tall order for
any $2 microcontroller...
Unfortunately, the TRS-80 depends on being able to close multiple
switchhes at the smae time (and not just obvious extras like the shfit
key), so the obvious hardware solution of a multiplxer + demutiplexer
(whichonly allows one effective keypress at a time) doesn't work.
The necessary logic to do it properly is quite simple, but not easy to
build in a few chips (nnless you use an FGPA or similar :-().
-tony
useful ICs are no longer made ;-(). If so,e it
would seem to be posisble
to use one of those to simulate the keyswithc matrix for just avout any
swithc-type keyboard. Add a microcotnroller to decode the PS/2 keyboard
signal then if you detect akey-down code close the appropriate swtich in
the crosspoint array, if you detect a key-up contd open it. OK, there may
be a little more work for keys that were originally mechancially locking,
but that's essentially it, I think.
But Tony, I can do everything with a $2 microcontroller...Why the
crosspoint IC? :oO 
1:57 p.m.
On 16 Jan 2012 at 21:22, Tony Duell wrote:
The necessary logic to do it properly is quite simple,
but not easy to
build in a few chips (nnless you use an FGPA or similar :-().
It would seem to me that a 256-byte SRAM (preferably dual-ported, but
not strictly necessary if one watches the timing) and a
microcontroller to set and clear the bits in said SRAM would be
sufficient.
Or am I missing something?
--Chuck
17 Jan
17 Jan
11:34 a.m.
On 16 Jan 2012 at 21:22, Tony Duell wrote:
Since the read is totally asynchronous (and you don't, in general, get a
read strobe on such keyboard interfaces), the RAM pretty much does have
to be dual-ported (or at least separate read and write ports, with
separate address lines).
If notm there wil lbe times when the host machine is readign the
'keyboard' when your interface is trying to update the RAM. Since the
interface can't know when the host machine is redig nthe keyboard, you
can't prevent writes at that time. if the RAM is single-ported, then
(given a sensible) desing, the host will mopst likely think all keys are
up. And with some keyboard drivers, if they detect a key is up after
seeing it down after the debounce delay, and then see the key apparently
down again (in this case because the interface is no longer writing to
the RAM), the host will see 2 keypresses. Thus you'll get what appears to
be key boaunce.
The necessary logic to do it properly is quite
simple, but not easy to
build in a few chips (nnless you use an FGPA or similar :-().
It would seem to me that a 256-byte SRAM (preferably dual-ported, but
not strictly necessary if one watches the timing) and a microcontroller to set and clear the bits in said SRAM
would be
sufficient.
Or am I missing something?
No, given a dual-ported RAM, this works. It's fine for a 8*8 matrix (as
in the case of the TRS-80). it's less fine for a 16*8 matrix, when you
needa 64K dual-ported RAM and have to update 32768 locations (i.e.
half of them) for every key change-of-state.
Are small dual-porrted RAMs easy to obtain now?
-tony
1:57 p.m.
On 17 Jan 2012 at 19:34, Tony Duell wrote:
Since the read is totally asynchronous (and you
don't, in general, get
a read strobe on such keyboard interfaces), the RAM pretty much does
have to be dual-ported (or at least separate read and write ports,
with separate address lines).
Well, yes and no. Given the speed of a 4MHz Z80 and its timing, I
think it would be possible to slip in with even a low-end MCU to do
some updating after every line change. I also suspect that the TRS80
probably has some debouncing logic so that momentary glitches in the
state of a key isn't a big deal.
Or you could split a 512 byte SRAM and divide it into two pages,
always writing to one half and swapping pages after every keystroke.
Are small dual-porrted RAMs easy to obtain now?
IDT still offers small (1Kx8) async dual-ported 5V SRAMs. I suspect
that there are other suppliers as well.
In either case, the logic isn't complex.
--Chuck
2:49 p.m.
On 1/17/2012 1:34 PM, Tony Duell wrote:
No, given a dual-ported RAM, this works. It's fine
for a 8*8 matrix (as
in the case of the TRS-80). it's less fine for a 16*8 matrix, when you
needa 64K dual-ported RAM and have to update 32768 locations (i.e.
half of them) for every key change-of-state.
Given the original topic, a dual port
RAM is indeed feasible. However,
for keyboards that can be scanned either way (CBM VIC-20, C64, C128,
C128D, +4), dual port will not work, as one cannot guarantee that the
rows are the "addresses" and the columns are the "data" or vice versa.
For reference, the CBM PET has a 3-8 decoder used to select rows in the
KB matrix, so a dual port ram option can work (because the design can
guarantee the address and data usage)
There is a MT8816, which is an 8x16 matrix.
As Tony notes, KB matrix diodes would make things more complicated, if
not impossible.
Jim
4:24 p.m.
On 17 Jan 2012 at 16:49, Jim Brain wrote:
As Tony notes, KB matrix diodes would make things more
complicated, if
not impossible.
I concocted my soluation after looking at the TRS-80 model 4
schematics.
Clearly, other keyboard schemes will require other solutions. But
I'd still want a MCU to decode the PS/2 keyboard proposed. Maybe
Tony wants to do the decoding with discrete logic, but that would not
be my first choice for simplicity, expense or power. It's not the
PS/2's choice either to the best of my knowledge.
--Chuck
5:12 p.m.
On Jan 17, 2012, at 19:24, "Chuck Guzis" <cclist at sydex.com> wrote:
On 17 Jan 2012 at 16:49, Jim Brain wrote:
Even the AT keyboard (whose protocol the PS/2 keyboard uses) used an 8042 and possibly a
scanning IC.
- Dave
As Tony notes, KB matrix diodes would make things
more complicated, if
not impossible.
I concocted my soluation after looking at the TRS-80 model 4
schematics.
Clearly, other keyboard schemes will require other solutions. But
I'd still want a MCU to decode the PS/2 keyboard proposed. Maybe
Tony wants to do the decoding with discrete logic, but that would not
be my first choice for simplicity, expense or power. It's not the
PS/2's choice either to the best of my knowledge.
18 Jan
18 Jan
11:28 a.m.
Even the AT keyboard (whose protocol the PS/2 keyboard
uses) used an
8042 and possibly a scanning IC.
All IBM PC family keyboards contain a microcontroller. I beleive this was
origianlly an 8048, but I have seen at least one IBM keyboard with a 6805
in it. The clone keyboards that I've seen that have recognisable ICs (as
opposed to epoxy-cvapped direct-on-board ones) contain 8048s or similar.
The PC/AT (and I assume PS/2s) have an 8042 microcntrolelr on the
moterhboard to handle communcation with the keyboard. The PC and PC/XT
don't, they use a TTL shift register an a little glue logic.
-tony
17 Jan
17 Jan
8:06 p.m.
On 1/17/2012 6:24 PM, Chuck Guzis wrote:
On 17 Jan 2012 at 16:49, Jim Brain wrote:
I agree. C=Key does exactly that, using a crosspoint for the matrix and
an AVR for the PS/2 protocol.
Jim
--
Jim Brain
brain at jbrain.com
www.jbrain.com
As Tony notes, KB matrix diodes would make things
more complicated, if
not impossible.
I concocted my soluation after looking at the TRS-80 model 4
schematics.
Clearly, other keyboard schemes will require other solutions. But
I'd still want a MCU to decode the PS/2 keyboard proposed. Maybe
Tony wants to do the decoding with discrete logic, but that would not
be my first choice for simplicity, expense or power. It's not the
PS/2's choice either to the best of my knowledge.
--Chuck
18 Jan
18 Jan
10:57 a.m.
There are a lot of adapters (Atmel and PIC) that will take a PS/2
keybaord and make it into a USB device.... those would be a very good
start as you'd have 1/2 of the work down, next you'd want to guy the
VUSB core out of the code, then take the input from the PS/2 and set of
the ports of the microcontroller for output, setup a row and column and
create your matrix and then build the hardware with some diodes for the
outputs to avoid debounce and and other issues.
Jim Brain wrote:
On 1/17/2012 6:24 PM, Chuck Guzis wrote:
On 17 Jan 2012 at 16:49, Jim Brain wrote:
I agree. C=Key does exactly that, using a crosspoint for the matrix
and an AVR for the PS/2 protocol.
Jim
As Tony notes, KB matrix diodes would make things
more complicated, if
not impossible.
I concocted my soluation after looking at the TRS-80 model 4
schematics.
Clearly, other keyboard schemes will require other solutions. But
I'd still want a MCU to decode the PS/2 keyboard proposed. Maybe
Tony wants to do the decoding with discrete logic, but that would not
be my first choice for simplicity, expense or power. It's not the
PS/2's choice either to the best of my knowledge.
--Chuck
11:20 a.m.
On 18 Jan 2012 at 13:57, Curt @ Atari Museum wrote:
There are a lot of adapters (Atmel and PIC) that will
take a PS/2
keybaord and make it into a USB device.... those would be a very good
start as you'd have 1/2 of the work down, next you'd want to guy the
VUSB core out of the code, then take the input from the PS/2 and set
of the ports of the microcontroller for output, setup a row and column
and create your matrix and then build the hardware with some diodes
for the outputs to avoid debounce and and other issues.
I'm not following--the code to interface to a PS/2 keyboard is no big
deal--see the PS/2-to-XT converter I did for the VC forum using an 8-
pin PIC MCU. In this situation, a 20-pin ATTiny2313 would be more
than adquate.
The Model 4 uses 8 bits from the address lines and 8 bits of the data
lines in a system-defined space. Essentially, the keyboard interface
represents 256 bytes of memory where the contents change depending
upon what key is pressed.
Since the PS/2 keyboard does its own debouncing, I'm having a problem
figuring out what the diodes are for.
Jim and Tony proposed using an 8x8 crosspoint switch IC; I proposed
using a dual-ported 256 byte RAM. as an alternative. I'll admit that
I haven't checked prices on either; it could be that the crosspoint
switch IC is cheaper than the DP RAM.
In either case, I don't see the need for debouncing (although the TRS-
80 probably has code to do it). Maybe you were thinking about using
an array of 256 relays?
Just color me dense today.
--Chuck
11:42 a.m.
On 1/18/2012 12:57 PM, Curt @ Atari Museum wrote:
There are a lot of adapters (Atmel and PIC) that will
take a PS/2
keybaord and make it into a USB device.... those would be a very good
start as you'd have 1/2 of the work down, next you'd want to guy the
VUSB core out of the code, then take the input from the PS/2 and set
of the ports of the microcontroller for output, setup a row and column
and create your matrix and then build the hardware with some diodes
for the outputs to avoid debounce and and other issues.
I don't have an issue
with the electronics per se. My main stumbling
block is the lack cheap uCs that are USB "host" mode capable. For
example, the atmega32u2 is USB device mode capable, but not host mode.
Host mode capable devices are larger and more expensive.
Jim
2:01 p.m.
On 18 Jan 2012 at 13:42, Jim Brain wrote:
example, the atmega32u2 is USB device mode capable,
but not host mode.
Host mode capable devices are larger and more expensive.
It seems that it depends on your exact needs. For example, the
ATMega32 can be made to talk to a USB mouse:
http://courses.cit.cornell.edu/ee476/FinalProjects/s2007/blh36_cdl28_d
ct23/blh36_cdl28_dct23/index.html
I suspect that the same is true of a USB keyboard and other simple
HID devices. But those are exceptions and not a general solution.
There are interface chips, such as the FTDI Vinculum and the Maxim
MAX3421, which probably wouldn't break the bank. With that you can
implement a lightweight host on an Arduino:
https://github.com/felis/USB_Host_Shield_2.0
LUFA provides specialized (e.g. HID host, MIDI host) host
capabilities for a limited set of peripherals using the AT90SUB
chips.
http://www.fourwalledcubicle.com/LUFA.php
On the other hand, silicon's getting cheaper, so implementing a host
design using ARM or PIC32 isn't a big deal and both have USB host
capabilities (and vendor-supplied software to go along with it).
But if you're looking for a general host controller with 5V Vcc and a
DIP package, I suspect that you'll be looking a long, long time.
--Chuck
2:14 p.m.
I can use a $1.00 Atmega8A and easily implement a USB keyboard and connect an Atari 800
keyboard in a row/column matrix very easily. Now going the other way around requires the
port pins to be outputs and you would use the same amount of pins for talking to a ps/2
keyboard as talking out as a USB device, you'll still need 2 pins for clock lines and
run at 12mhz for best results... You don't need to throw a lot at this situation.
Sent from my iPhone
On Jan 18, 2012, at 5:01 PM, "Chuck Guzis" <cclist at sydex.com> wrote:
On 18 Jan 2012 at 13:42, Jim Brain wrote:
example, the atmega32u2 is USB device mode
capable, but not host mode.
Host mode capable devices are larger and more expensive.
It seems that it depends on your exact needs. For example, the
ATMega32 can be made to talk to a USB mouse:
http://courses.cit.cornell.edu/ee476/FinalProjects/s2007/blh36_cdl28_d
ct23/blh36_cdl28_dct23/index.html
I suspect that the same is true of a USB keyboard and other simple
HID devices. But those are exceptions and not a general solution.
There are interface chips, such as the FTDI Vinculum and the Maxim
MAX3421, which probably wouldn't break the bank. With that you can
implement a lightweight host on an Arduino:
https://github.com/felis/USB_Host_Shield_2.0
LUFA provides specialized (e.g. HID host, MIDI host) host
capabilities for a limited set of peripherals using the AT90SUB
chips.
http://www.fourwalledcubicle.com/LUFA.php
On the other hand, silicon's getting cheaper, so implementing a host
design using ARM or PIC32 isn't a big deal and both have USB host
capabilities (and vendor-supplied software to go along with it).
But if you're looking for a general host controller with 5V Vcc and a
DIP package, I suspect that you'll be looking a long, long time.
--Chuck
2:41 p.m.
On 1/18/2012 4:14 PM, Curt Vendel wrote:
I can use a $1.00 Atmega8A and easily implement a USB
keyboard and connect an Atari 800 keyboard in a row/column matrix very easily. Now going
the other way around requires the port pins to be outputs and you would use the same
amount of pins for talking to a ps/2 keyboard as talking out as a USB device, you'll
still need 2 pins for clock lines and run at 12mhz for best results... You don't need
to throw a lot at this situation.
matrix KB to USB is indeed very easy. As you
note, M8 is easily doable
(LUFA + the KB connector of choice and some glue code).
The other way requires host mode functionality. Chuck, I'll admit I did
not see the limited Host mode support in LUFA, but I did see the EE
project. I dloaded the code, and it's definitely a college project
:-). I decided against trying to refactor the code into something usable.
In my case, as I redesign C=Key, I have some other goals in mind:
* field upgradable via USB port
* Support for hose and device mode (current C=Key operates in both
directions as well)
* Minimal parts count (I'm aware of the VNC1L and such, but they are
pricey for what they offer)
Since DIP/TH packaging is not a requirement for me, and minimal parts
count and small size is, I am leaning towards a small OTG-capable ARM
variant for the new design. They are reasonably inexpensive, and offer
all of capabilities I feel are needed.
I would enjoy a cheaper Xpoint switch option, but perhaps that is asking
too much. Dual Port RAM is cheaper, but some apps depend on the
interesting effects of "n" key rollover, which is harder to replicate in
a dual port RAM setup. Of course, I think the C64, which can scan
either way, dual purposes the row and column lines for joysticks, and
uses two of the lines to select paddles, is an extreme case, but it's a
challenging case nonetheless. TRS-80 M4 does indeed seem easier to support.
Jim
2:59 p.m.
If you want to work together on something Jim, I'd be happy to.
Sent from my iPhone
On Jan 18, 2012, at 5:41 PM, Jim Brain <brain at jbrain.com> wrote:
On 1/18/2012 4:14 PM, Curt Vendel wrote:
I can use a $1.00 Atmega8A and easily implement a
USB keyboard and connect an Atari 800 keyboard in a row/column matrix very easily. Now
going the other way around requires the port pins to be outputs and you would use the same
amount of pins for talking to a ps/2 keyboard as talking out as a USB device, you'll
still need 2 pins for clock lines and run at 12mhz for best results... You don't need
to throw a lot at this situation.
matrix KB to USB is indeed very easy. As you
note, M8 is easily doable (LUFA + the KB connector of choice and some glue code).
The other way requires host mode functionality. Chuck, I'll admit I did not see the
limited Host mode support in LUFA, but I did see the EE project. I dloaded the code, and
it's definitely a college project :-). I decided against trying to refactor the code
into something usable.
In my case, as I redesign C=Key, I have some other goals in mind:
* field upgradable via USB port
* Support for hose and device mode (current C=Key operates in both
directions as well)
* Minimal parts count (I'm aware of the VNC1L and such, but they are
pricey for what they offer)
Since DIP/TH packaging is not a requirement for me, and minimal parts count and small
size is, I am leaning towards a small OTG-capable ARM variant for the new design. They
are reasonably inexpensive, and offer all of capabilities I feel are needed.
I would enjoy a cheaper Xpoint switch option, but perhaps that is asking too much. Dual
Port RAM is cheaper, but some apps depend on the interesting effects of "n" key
rollover, which is harder to replicate in a dual port RAM setup. Of course, I think the
C64, which can scan either way, dual purposes the row and column lines for joysticks, and
uses two of the lines to select paddles, is an extreme case, but it's a challenging
case nonetheless. TRS-80 M4 does indeed seem easier to support.
Jim
7:23 p.m.
On 1/18/2012 4:59 PM, Curt Vendel wrote:
If you want to work together on something Jim, I'd
be happy to.
I'd love to. Options for a small-ish OTG-capable uC with 24 pins
of IO
(8+12 for a 8x12 matrix, 1 for RESET, 1 for LED, 2 for AUX duty) + USB
at a low cost would be ideal.
Jim
3:34 p.m.
On 18 Jan 2012 at 17:14, Curt Vendel wrote:
I can use a $1.00 Atmega8A and easily implement a USB
keyboard and
connect an Atari 800 keyboard in a row/column matrix very easily.
Now going the other way around requires the port pins to be outputs
and you would use the same amount of pins for talking to a ps/2
keyboard as talking out as a USB device, you'll still need 2 pins for
clock lines and run at 12mhz for best results... You don't need to
throw a lot at this situation.
The USB keyboard and mice are special HID devices and not at all like
most other USB devices as I noted. As a counter-example, I suspect
you'll have a lot of trouble talking to a USB flash drive with an
ATMega8. In that sense, the ATMega8 isn't a true USB host. See my
cite on using a Mega32 to talk to a mouse--mothing to it.
Serving as host to a USB WiFi modem, on the other hand, is a real
project.
One of the more frequent questions on the MCU forums is "how do I
talk to a USB flash drive using a low-end AVR or PIC?". The answer
is that you don't--at least not without some external help.
--Chuck
3:57 p.m.
On Jan 18, 2012 3:38 PM, "Chuck Guzis" <cclist at sydex.com> wrote:
The USB keyboard and mice are special HID devices and not at all like
most other USB devices as I noted.
I must have missed what you were getting at there. In what way specifically
are USB keyboards and mice "special"? For the purposes here just that they
are typically implemented as Low-Speed devices instead of Full-Speed
devices?
-Glen
6:09 p.m.
On 18 Jan 2012 at 15:57, Glen Slick wrote:
On Jan 18, 2012 3:38 PM, "Chuck Guzis"
<cclist at sydex.com> wrote:
Well, they're low-speed devices, but they're unique among HID devices
in that they also implement a "boot protocol". The HID spec devotes
quite a few pages to this.
--Chuck
The USB keyboard and mice are special HID devices and not at all
like most other USB devices as I noted.
I must have missed what you were getting at there. In what way
specifically are USB keyboards and mice "special"? For the purposes
here just that they are typically implemented as Low-Speed devices
instead of Full-Speed devices?
8:56 p.m.
On Jan 18, 2012 6:13 PM, "Chuck Guzis" <cclist at sydex.com> wrote:
Well, they're low-speed devices, but they're unique among HID devices
in that they also implement a "boot protocol".
Ok, I can see that point. Writing a general purpose HID report parser
doesn't seem like a whole lot of fun if you need to fit it into a small
microcontroller.
-Glen
7:28 p.m.
On 1/18/2012 5:34 PM, Chuck Guzis wrote:
The USB keyboard and mice are special HID devices and
not at all like
most other USB devices as I noted. As a counter-example, I suspect
you'll have a lot of trouble talking to a USB flash drive with an ATMega8.
I
think, in the midst of trimming the post, we've messed with the OP's
goal, USB KB to KB matrix. For that purpose, a "pseudo" USB Host
implementation that can handle HID would suffice, though it might be
more trouble than simply obtaining a true OTG-capable uC.
One of my most important design goals is the ability to support a USB
flash drive. It sounds silly to do so on a KB interface, but I have
found "field-upgrades" to be an essential hobbyist project criteria, as
it allows incomplete firmware to be enhanced and bugs fixed without
requiring all customers own a programmer and remove the device from the
circuit. It makes hobbyist projects infinitely more pleasurable to
produce, as you can feel significantly less guilty if a bug is found
after production. For this feature, alas, a pseudo-USB host
functionality would probably not be enough.
For the DIYer, though, it might be enough to use LUFA and it's at90USB
HID host support.
Jim
--
Jim Brain
brain at jbrain.com
www.jbrain.com
8:18 p.m.
On 18 Jan 2012 at 21:28, Jim Brain wrote:
One of my most important design goals is the ability
to support a USB
flash drive. It sounds silly to do so on a KB interface, but I have
found "field-upgrades" to be an essential hobbyist project criteria,
as it allows incomplete firmware to be enhanced and bugs fixed without
requiring all customers own a programmer and remove the device from
the circuit. It makes hobbyist projects infinitely more pleasurable
to produce, as you can feel significantly less guilty if a bug is
found after production. For this feature, alas, a pseudo-USB host
functionality would probably not be enough.
Well, you may want to think about the AVR USB MCUs (8 bit, 16MHz).
Atmel has a couple of appnotes doing this with an AT90USB647 or
AT90USB1287 (AVR247). That's probably close to the minimum (64QFN
package) that you can do this in.
--Chuck
8:53 p.m.
On 1/18/2012 10:18 PM, Chuck Guzis wrote:
Well, you may want to think about the AVR USB MCUs (8
bit, 16MHz).
Atmel has a couple of appnotes doing this with an AT90USB647 or
AT90USB1287 (AVR247). That's probably close to the minimum (64QFN
package) that you can do this in.
Understood, though it's $10+ in singles,
while the LPC1756 is $8.40 in
singles and the price drops faster in 100s than for the AVR.
64tqfp versus 80tqfp.
the onboard EEPROM on the 647 (for custom keyboard mappings) makes life
interesting, though.
Jim
19 Jan
19 Jan
1:20 a.m.
On 18 Jan 2012 at 22:53, Jim Brain wrote:
Understood, though it's $10+ in singles, while the
LPC1756 is $8.40 in
singles and the price drops faster in 100s than for the AVR.
64tqfp versus 80tqfp.
the onboard EEPROM on the 647 (for custom keyboard mappings) makes
life interesting, though.
Oh, I like ARMs too. :) But I thought we were looking for an 8-
bit solution. My mistake. If you don't mind single-sourcing, a
PIC32MX2 might also be worth a glance.
So how many of these things do you plan to put out? I can't imagine
that there's a huge market in keyboard-to-vintage PC converters.
--Chuck
22 Jan
22 Jan
10:54 p.m.
On 1/19/2012 3:20 AM, Chuck Guzis wrote:
On 18 Jan 2012 at 22:53, Jim Brain wrote:
I'd prefer a small OTG-capableuC that
didn;t cost $8.00, but either ARM
or AVR will work. I don't know much aboiut PIC32, but I'm shying away
Understood, though it's $10+ in singles,
while the LPC1756 is $8.40 in
singles and the price drops faster in 100s than for the AVR.
64tqfp versus 80tqfp.
the onboard EEPROM on the 647 (for custom keyboard mappings) makes
life interesting, though.
Oh, I like ARMs too. :) But I thought we were
looking for an 8-
bit solution. My mistake. If you don't mind single-sourcing, a
PIC32MX2 might also be worth a glance. from AVR32 and PIC32 and such in favor of ARM. In the
spirit of Tony's
philosophy on having all the material on hand to fix things, I
think the
AVR32/PIC32/etc. uCs are too niche. ARM is all over the place, and the
likelihood that one could get a compiler and a programmer 10 years from
now on ARM is probably better than for some of the other families.
So how many of these things do you plan to put out? I can't imagine
that there's a huge market in keyboard-to-vintage PC converters.
Mainly I am
interested in the CBM tangent, and you'd be surprised how
many people want a PC KB on their C64/C128. But, it looks like a small
design could be re-purposed to handle lots of options.
Jim
11:08 p.m.
Zitat von Jim Brain <brain at jbrain.com>:
In the spirit of Tony's
philosophy on having all the material on hand to fix things, I think
the AVR32/PIC32/etc. uCs are too niche. ARM is all over the place, and
the likelihood that one could get a compiler and a programmer 10 years
from now on ARM is probably better than for some of the other families.
Not being an ARM fan at all, I was still impressed how fast the first
design went here with an luminary (now TI). Got the gcc for it, which
was a simple compile. OpenOCD for JTAG. Enough examples and makefile
on TI's webpage.
Just writing down the application after that.
11:58 p.m.
On 23 Jan 2012 at 0:54, Jim Brain wrote:
I'd prefer a small OTG-capableuC that didn;t cost
$8.00, but either
ARM or AVR will work. I don't know much aboiut PIC32, but I'm shying
away from AVR32 and PIC32 and such in favor of ARM. In the spirit of
Tony's philosophy on having all the material on hand to fix things, I
think the AVR32/PIC32/etc. uCs are too niche. ARM is all over the
place, and the likelihood that one could get a compiler and a
programmer 10 years from now on ARM is probably better than for some
of the other families.
The MX2 is OTG-capable and comes in packages as small as 28 pins.
I've got a soft spot for PIC32 in that it's basically a MIPS R4000
core with peripherals tacked on. Microchip does their own silly
thing, programming it with their proprietary ISP programmer (PICkit),
even though they employ an on-chip ISP-to-JTAG converter (which is
what really does the programming). I believe their toolchain has its
roots in the GCC R4000 compiler as well, so it isn't as if that's
going bye-bye anytime soon. Think of it as an SGI workstation on a
chip.
Some of the PIC32 family has 5v-tolerant inputs, which is a plus in a
lot of cases. No EEPROM, however, which is too bad. But you're
right--without some second sources, it's probably doomed in the long
run competing against the ARM.
ARMs are everywhere and comparatively cheap. I like the low-end 8-
bit AVRs, but with the 32-bitters, you might as well use an ARM.
--Chuck
18 Jan
18 Jan
11:24 a.m.
On 17 Jan 2012 at 16:49, Jim Brain wrote:
If you re-read my original post, you'll see I porposed using a
microcontroller (to decode the PS/2 signals) and a crosspoint switch IC.
As Tony notes, KB matrix diodes would make things
more complicated, if
not impossible.
I concocted my soluation after looking at the TRS-80 model 4
schematics.
Clearly, other keyboard schemes will require other solutions. But
I'd still want a MCU to decode the PS/2 keyboard proposed. Maybe
Tony wants to do the decoding with discrete logic, but that would not be my first choice for simplicity, expense or power.
It's not the
PS/2's choice either to the best of my knowledge.
I beleive the PS/2s used a microcontrolelr on the motherboard. The PC/AT
certainly did (an 8042). The PC and PC/XT did not, but then keyboard
protorcol there is a little simpler.
I do feel, though , that in some cases, a microcontroller (or other
programmed devices) adds complexity and makes it more dificult to
understnd or repair the device in the future, I can understnad why
commercial organisations like this, but it does seem rather against the
spirit of classic computing (which to some extent depends on
understnading old machines and being able to repair them).
-tony
11:19 a.m.
On 1/17/2012 1:34 PM, Tony Duell wrote:
I assume in this case the row and column lines are connected to a PIA or
similar chip so that they can either be inputs or outputs. The CoCo is
similar.
Most other machines enforce in the hardware whether the rows or columns
are the 'driven' lines, which means you can use a dual-ported RAM, or
digital logic to simulate the keyboard
No, given a dual-ported RAM, this works. It's
fine for a 8*8 matrix (as
in the case of the TRS-80). it's less fine for a 16*8 matrix, when you
needa 64K dual-ported RAM and have to update 32768 locations (i.e.
half of them) for every key change-of-state.
Given the original topic, a dual
port RAM is indeed feasible. However,
for keyboards that can be scanned either way (CBM VIC-20, C64, C128,
C128D, +4), dual port will not work, as one cannot guarantee that the
rows are the "addresses" and the columns are the "data" or vice
versa. For reference, the CBM PET has a 3-8 decoder used to
select rows in the
KB matrix, so a dual port ram option can work (because the design can
guarantee the address and data usage)
There is a MT8816, which is an 8x16 matrix.
Right.
As Tony notes, KB matrix diodes would make things more complicated, if
not impossible.
I don't think you can simulate such a keybaord usign an analogue
crosspoint IC. On the otehr hamd, the existance of such diodes pretty
much enforces which lines are inputs and which are outputs, so yuu could
then use the dual-ported RAM solution.
-tony
16 Jan
16 Jan
9:10 p.m.
On 1/15/2012 1:51 PM, Alexandre Souza - Listas wrote:
=> Are crosspoint swithc ICs still easily
available? (It seems that so
many
I would be interested in hearing how one does that. I tried to
implement
such a thing with a 16MHz AVR, but there were issues:
* Some SW scans the KB in interesting ways, so just emulating the std
KB scanning routine triggers was not enough to work.
* On the C64, the joysticks share the KB address lines, so if a user
presses joystick buttons while using the KB, very non standard pins
are connected.
* Some apps scan the KB backwards (ie, drive the columns and read the
rows as opposed to driving the rows and scanning the columns). That
required more code.
I *suppose* you could hook each of the 16 KB lines (assuming and 8x8
matrix) to an interrupt, and then create a table of values for any
combination. But, it seemed easier and more flexible to use a cross
point, especially since I also wanted to allow use of the original KB in
addition to the PS/2 KB.
Jim
--
Jim Brain
brain at jbrain.com
www.jbrain.com
useful ICs are no longer made ;-(). If so,e it
would seem to be posisble
to use one of those to simulate the keyswithc matrix for just avout any
swithc-type keyboard. Add a microcotnroller to decode the PS/2 keyboard
signal then if you detect akey-down code close the appropriate swtich in
the crosspoint array, if you detect a key-up contd open it. OK, there
may
be a little more work for keys that were originally mechancially
locking,
but that's essentially it, I think.
But Tony, I can do everything with a $2 microcontroller...Why the
crosspoint IC? :oO
9:25 p.m.
I *suppose* you could hook each of the 16 KB lines
(assuming and 8x8
matrix) to an interrupt, and then create a table of values for any
combination. But, it seemed easier and more flexible to use a cross
point, especially since I also wanted to allow use of the original KB in
addition to the PS/2 KB.
Hmmm, I didn't know all of that :(
17 Jan
17 Jan
11:58 a.m.
I *suppose* you could hook each of the 16 KB
lines (assuming and 8x8
matrix) to an interrupt, and then create a table of values for any
combination. But, it seemed easier and more flexible to use a cross
point, especially since I also wanted to allow use of the original KB in
addition to the PS/2 KB.
Hmmm, I didn't know all of that :(
16 Jan
16 Jan
9:04 p.m.
On 1/15/2012 1:42 PM, Tony Duell wrote:
You can still obtain the Mitel (then Zarlink, then Microsemi) MT8812
units from the factory and other places. That's what C=Key uses.
Jim
--
Jim Brain
brain at jbrain.com
www.jbrain.com
I don't have a Mod IV. But if I build something here in Brazil, will you
be able to duplicate it there?
Are crosspoint swithc ICs still easily available?
(It seems that so many
useful ICs are no longer made ;-(). If so,e it would seem to be posisble
to use one of those to simulate the keyswithc matrix for just avout any
swithc-type keyboard. Add a microcotnroller to decode the PS/2 keyboard
signal then if you detect akey-down code close the appropriate swtich in
the crosspoint array, if you detect a key-up contd open it. OK, there may
be a little more work for keys that were originally mechancially locking,
but that's essentially it, I think.
-tony
17 Jan
17 Jan
11:57 a.m.
You can still obtain the Mitel (then Zarlink, then
Microsemi) MT8812
units from the factory and other places. That's what C=Key uses.
RIght, thanks, I;ll look into those.
Of couese the problem with crospoint switch ICs is that they will act
like an array of mechanical switches, and could have 'sneak paths'. If
the origianl keyboard has a diode in series iwth each key (or with some
of the keys, like SHIFT), then the crosspoint switch IC may not correctly
simulate the keyboard's behaviour.
A good solution would seem to be a set of latches (one for each column),
feeding open-collector buffers (enabled by the column scan lines), the
outputs of corresponding buffers of each latcvh being linked togeter and
to the row lines. Problem is, there is no 8-bit latch with open-colelctor
outputs that I can quickly spot, so it's 2 or 3 ICs (3 ICs, say a '374
and a couple of '03s ) for each column. I suppose you could program an
FPGA to do it, but that's horrible...
-tony
4763
days inactive
4772
days old
39 comments
9 participants
participants (9)
-
alhartman＠yahoo.com -
ard＠p850ug1.demon.co.uk -
brain＠jbrain.com -
cclist＠sydex.com -
curt＠atarimuseum.com -
emu＠e-bbes.com -
fraveydank＠gmail.com -
glen.slick＠gmail.com -
pu1bzz.listas＠gmail.com