The Memotech MTX Series
MTX PC Keyboard Interface
his prototype board layouts using Excel, this helps him
place the components on a matrix representing his
prototype board, but they are not schematic diagrams in
the usual sense.
Note: the layout is drawn as reference to be used for
soldering, so the view is from the underside of the
board, i.e., the components are a mirror image of the
This is the layout for
Martin's prototype board, the major components being the
Propeller, associated serial EPROM and two 74x7
components placed and soldered onto a small prototype
board that Martin happened to have available.
The board sits conveniently on top of the MTX keyboard
connector and would allow the MTX keyboard shell to be
closed if required but does not have the facility to
connect the MTX keyboard at the same time as the PS/2
board fitted to the MTX and attached to a PC PS/2
keyboard I/O slot adapter panel.
You can also see
the flying lead connected to the MTX User Port socket
from where Martin has picked up 5VDC for the board.
Martin's component layout and converted it to a KiCad
schematic as shown.
As noted above, plugging
into the MTX keyboard connector prevents the MTX keyboard from being connected at the same time.
|When the Propeller
keyboard interface is incorporated into MTXPlus+ it will
connect in parallel with the existing MTX matrix
keyboard interface, allowing a PS/2 keyboard and an
original MTX keyboard to be connected at the same time.
I decided that it would be nice to have a similar setup
on an original MTX so that a PS/2 keyboard could be
connected as and when required, without needing to open
up the computer.
The easiest method of
connecting a PS/2 keyboard would be to have a PS/2
connector on a trailing lead exiting the rear of the
case, but I also though that it would be nice to be able
to include a PS/2 connector on the MTX itself.
There are a couple of options to achieve this, either by
drilling an additional hole in the rear plastic I/O port
panel, or by drilling one of the end plates. I was not
keen on the first method, but was happier drilling one
of the endplates as they would be much easier to replace
if the keyboard connector was removed in the future. The
left hand side end plate is not a good choice as it
would be obstructed by any MTX expansion hardware; the
right hand side end plate is a better option.
also considered allowing the PS/2 keyboard PCB to to
mounted to the right of the computer board(s) such that
the PS/2 connector could be mounted on the PCB, rather
than needing a flying lead. If the PCB was mounted at
the right hand side of the case, then IDC cables would
be needed between the existing keyboard, computer
keyboard connector and the new PCB.
for these options, I added additional headers to my
design to allow the MTX keyboard to be connected
simultaneously with the PS/2 keyboard and/or to run an
IDC cable from the right hand side of the case to
the MTX keyboard connector.
options meant that my prototype design was quite a bit
larger than Martin's to allow space for the additional
pin headers to be located in the deepest part of the
case (at the rear). Whilst this design gives the most
flexibility, it does mean that the board becomes quite
large and exceeds the target price point for the PCB
manufacturer that I use (<100mm).
prototype board - with a couple of changes from the 3D
model for ease of construction.
I found that the
Propeller and EPROM needed to be a little further
towards the top of the board than Martin's prototype to
allow adequate clearance when the MTX keyboard was
prototype board fitted to the MTX keyboard connector.
You can see the my PC PS/2 keyboard I/O slot adapter
panel attached and below the PS/2 cable, the 20 pin DIP
header that I have attached to the User Port socket. (Bad
Design ! see below)
Although the MTX keyboard connector pin 20 provides
0v, in addition to the 5v connection on pin 20 of
the User port, I have also picked up 0v from pin 16,
this provides a little more strain relief on the jumper
wire, rather than just having it connected to the 5v
|After a little
debugging and editing of the code, Bill's Propeller code
worked very well, with the same limitations on the
mapping between the PC keyboard and the MTX ROM that
exist in MEMU
on which the Propeller code is based.
issues are described in the
keyboard section on the
emulation page of Andy's site and are associated
with issues related to shifted and unshifted keys.
Quoting from Andy's page, "... to type certain MTX
characters, you must type different things on the host
PC keyboard. This remapping is done to ensure an
unshifted host PC keypress corresponds to an unshifted
MTX keypress and a shifted host PC keypress
corresponds to a shifted MTX keypress." and "the whole
host PC keypad maps to the whole MTX keypad, based on
key position, not what is written on the keys"
"The effect of the shift-state problem :- "
Use host keypress
|To produce MTX
This behavior is not ideal, but is considered to be
the most practical way of using a PC keyboard on the MTX
without making changes to the MTX ROM. The
difference between the effect of a keypress and what is
written on the keys is most noticeable with the PC
numeric keypad - see the diagram at the top of the page
for further detail.
has developed patches for the MTX ROM to map the PC
keyboard characters to the desired MTX keystroke when
the keyboard "Scroll Lock" mode is active. An updated
ROM image is available below.
In standard mode the system works as now with key
mismatches. In "Scroll Lock" mode the main keyboard
keycaps all match except "back quote". (The keypad in
shift mode is still offset because the cursor keys are
For MTX users with CP/M or SDX disk
systems, Bill has written loadable
drivers that enable the "Scroll Lock" mapping mode
to be used without requiring changes to the MTX ROM.
For CP/M this works by patching the CP/M BIOS in
high memory. For SDX BASIC, a small routine is loaded
between the sound buffers and system variables, which
hooks into an SDX call vector to provide the additional
5V Power Connection
Although the User Port was used to provide the 5VDC
to the boards for testing, we did not pay enough
attention to the restriction included in the MTX
Operator's Manual - the User Port is only specified as
being able to supply 20mA - the propeller and more
significantly, the PC keyboard requires considerably
more than that. Inspection of the MTX computer board
shows that the 5V supply to the User Port is on a very
thin PCB trace - I suspect that it was this that set the
maximum current available from the User Port. It would
be a relatively easy task to solder an additional wire
from a 5V connection to the 20 way socket, but that
would prevent the PCB from being "plug & play". Instead,
we will likely use a test clip to pick up 5VDC from a
convenient point on the MTX computer board.
(Taking power from the MTX PCB may be problematic if the
computer is fully loaded with internal and external
expansion boards. If the MTX 5V supply is close to
capacity, then an external 5V supply would be needed.)
Inclusion of USB
The prototypes that Martin and I had built operated as intended, however, I had not appreciated that
PS/2 keyboards were as obsolete as they actually are and
the difficulties that might bring when implementing this
project on a wider basis, should it be of interest to
others. Whilst legacy PS/2 keyboards are still
available, it appears that the PS/2 adapter plates that
Marin and I had used are pretty much impossible to find.
During my testing, I used a legacy PS/2 compatible
keyboard with 6-pin mini-DIN connector. Bill and Martin
had used USB keyboards with "dumb" USB to PS/2 adapters
which worked perfectly. When I tried to use one of my
USB keyboards in the same way, the system failed to
recognise the keyboard and respond to key presses. As it
turns out, older USB keyboards can detect when a PS/2
interface is being used and use the PS/2 protocol so a
passive adapter works fine. Newer USB keyboards do not
all support the PS/2 protocol and an active adapter
would be needed to do protocol conversion.
had predicted that this may be an issue and had already
found USB interface code for the propeller that was
"worth thinking about". It was obvious that my original
intention to have a PS/2 compatible interface was short
sighted and a USB keyboard interface is pretty much
essential. With that in mind, I asked Bill if he could look
at developing the code for a USB interface too.
Bill's initial research - a proposed design for a dual
It seems that the USB interface
needed the USB signal lines connected to low address pins
on the Propeller (A0-A7) and the USB and PS/2 interfaces
use different resistor values and voltage levels. This
design allowed the pull-ups / downs to be selected by
that it may have been
possible to find a pair of resistor values that can work
for PS/2 or USB keyboards (to be determined by testing),
in which case, it would be possible to simplify the
design as shown here, where only a single jumper is
needed to select the keyboard type.
The status of
the single jumper could also be used to identify the
type of keyboard (PS/2 or USB) so that the Propeller
could choose the appropriate code to execute.
the prototypes suggested that the PS/2 resistor values
would also work for USB keyboards, so a single set of
resistors has been configured in the "final" schematic
used to generate a prototype PCB.
As of March
2018, the prototype boards had been proven to work in
PS/2 or USB mode, the dual mode code had not been tested
but as the hardware appeared to work, I committed a trial
run of PCBs to manufacturing.
3D model of the PCB. The components are pushed as far up
the PCB as possible and the board size reduced to 100mm
wide to minimise the PCB production cost.
run of the PCB has identified a couple of minor issues .
1. The DIP-14 sockets are too close together,
which makes installing the buffers in sockets a tight,
but workable, fit. (The tolerances in the sockets allows
the chips to be installed at the opposite ends of the
2. The top DIP-14 socket is too close to
the MTX keyboard pass-through connector, but bending the
pins at about 30 degrees allows the connector to be
plugged in and the keyboards operated in parallel.
PCB, fitted to MTX.
The MTX keyboard has been
disconnected for the photo, but fits without problem
with the pins on the pass-through connector bent
slightly as shown.
(On this board, the activity
LED is orientated so that I could see it more easily for
testing, normally, it will be mounted on the surface of
PC Motherboard USB header header is shown opposite. It
is designed to support two USB connections; there are a
number of varieties of mating cables which support 1
(4/5 pin cables) or 2 (9 pin cable) USB devices. Most of
these cables should be suitable for use with the MTX
keyboard PCB USB header when connected appropriately.
NB : The keyboard PCB USB pin
header is not keyed, Pin 1 is the left hand pin, closest
to the MTX keyboard pass through connector.
adapter cables are available in 4 and 5 pin varieties.
Either may be used with pin 1 (5V) connected to pin 1 of
the header. If a 5 pin cable is used, pin 5 (usually a
slightly thicker core used for the cable screen) will be
unconnected and overhang the keyboard pin header.
MTX Mouse interface ? (Cancelled)
Martin has been working on an additional hardware interface
to support the use of a PC PS/2 mouse with the MTX. To avoid the
need for new driver software or modifications to applications
software and games, Martin's interface is designed to mimic the
cursor keys in the same way as the Memtoech joystick interfaces
worked. Martin's design uses an Atmel ATMega328
microcontroller and supporting GAL and also connects in parallel
with the existing MTX keyboard (and PC keyboard interface if
Whilst Martin's mouse interface is a nice technical solution,
I am not sure whether there is enough demand to justify making
it a "product". However, it **may** be possible to add mouse
functionality to the keyboard interface without having to make
significant hardware modifications. Adding a PS/2 mouse appears
to be relatively straightforward and likely to fit in the
available free space of the Propeller. Adding a USB mouse is
more complex and further work is required to determine whether
it is possible.
In either case, it will not be possible to
upgrade a keyboard only PCB to include a PS/2 and/or USB mouse.
Martin's results when testing his mouse interface with
NewWord, it is apparent that using the ROM keyboard scanning
functions to update the mouse position is too slow to be
practical - certainly with CP/M software. Given that the
limitation appears to be the keyboard scanning speed, using the
Propeller to provide the interface to the mouse would also have
the same issues as the AVR interface.