17 Jan
2012
17 Jan
'12
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