*** M E M O R U M ***

Extracts from an email conversation between Dave and myself that might be of more general interest.

Dave:

On a slightly related subject, if I could only get a MTX case & keyboard, I would like to build a MEMU-Pi inside a real MTX, replacing a duff mother board and using the old MTX keyboard. Yes, I know that the keyboard might not be great, but it would look fantastic.

My questions is, how much work would I it be to directly connect the MTX keyboard connector to the GPIB pins in the Pi and write some code to translate the key presses to MEMU speak?

Bill:

With regard to interfacing a real MTX keyboard to MEMU-Pi, it is certainly possible, but there are a few issues. The MTX keyboard requires 8 drive lines and 10 sense lines, so at least 18 GPIO ports, 19 if you also want to monitor the reset keys. The RPi has at most 17 GPIO on P1. On the Rev. 2 boards there are a few more GPIO on P5, so it would be just about possible. However, a better solution would be to use an I2C based I/O expansion board to provide the necessary number of connections. There are a number of commercial expansion boards that would be sufficient to connect the keyboard. However, I have been fantasising about a custom board that would supply keyboard connector, joystick connections (in parallel with keyboard, as per MTX), printer port, two serial ports, and perhaps even the internal MTX PIO port. Attempting to emulate the expansion bus would probably be a stretch too far.

With regard to user interface, the reset keys could act as the SysReq key, bringing up the configuration screen. If this then included an option to select which of the screens to display, then you would not need to change any of the functionality of the main keyboard at all. Even better would be if it was possible to monitor the two reset keys separately. Then one key could be SysReq, while the other toggles between screens. However, that would require a modification to the keyboard PCB. There are a number of ways this could be done, either adding wires or diodes, without having to cut any of the tracks.

Dave:

Separate reset key functions would be neat, if the MTX keyboard was interfaced with your expansion board, could any required modification be done on the board, rather than on the keyboard PCB? As no tracks need cutting, this might be possible?

Bill:

In order to get separate reset keys, you have to modify the keyboard PCB in some way in order to get at the connection between the two reset keys.

The simplest solution is to solder a wire from the track joining the two reset keys keys (not connected to the plug), and solder the other end to one of the main keyboard drive lines. Then the two reset key connections become additional sense lines.

Another approach is to solder diodes across the reset keys, with cathodes on the sides that connect to the plug, and anodes on the sides that just connect to each other. Then on the interface board, put pull ups on both reset key lines. Drive one side low and the other side becomes sense for one of the keys. Remove the drive from the first side, and apply it to the second. The first side is then sense for the other reset key.

Unfortunately, both of these approaches would interfere with the operation with a standard MTX motherboard. The only fully compatible solution I can think of so far is to add a separate 21st connection to the track joining the two reset keys.

Actually, the second approach would almost work, except that one of the two reset keys (but not the other) would be sufficient to reset the MTX.

Bill again:

A possible solution using available hardware:

* RPi (a model A will do)
* One (or possibly two) IO expansion boards (http://www.pi-supply.com/product/quick2 ... board-kit/)
* 4 port powered USB hub.
* Two USB to serial convertors
* One USB to parallel converter.

There should be room for all of that inside the MTX case.

Then it is only a question of software.

Dave:

That looks like a neat little kit, and with the motherboard removed (and maybe even without) everything would fit inside the case.

As you say, it's just that small matter of the software.

What we need is some one with lots of experience coding for the Z80 and the RPi, where are we going to find someone like that I wonder

Bill:

Post the idea on the forum?

Postscript:

I have for some time been considering adding serial and parallel port hardware to MEMU-Pi, although I had not previously thought of supporting the MTX keyboard. However, knowing how long it takes me to get around to anything, I thought it worth posting the idea here to see whether anyone else wants to run with it.

Ahh, the black art of keyboard decoding
Actually you don't need anything like 18 lines to decode the MTX keyboard.
You do however need one inexpensive logic chip.
A 74LS145N (at 88p+VAT) can take 4 inputs and decode them to 10 outputs which can drive 10 keyboard lines. As a different binary number (actually a BCD number) is supplied to the inputs, so each output line goes low in turn. Just what you need to drive a keyboard matrix . So have 4 GPIO lines drive the 74LS145N, while 8 (or more) GPIO lines monitor inputs from the keyboard matrix. The outputs are open-collector, so you do need pull-up resistors, I suggest a in-line resistor network.

Of course, you can take this further and use a micro-controller to do all the hard work of scanning the keyboard, it can then just supply a serial data stream (two bytes for each key) to tell the MEMU-Pi when a key is pressed, or released

Links:
http://www.ti.com/product/SN74LS145/description
http://www.ti.com/lit/ds/symlink/sn74ls145.pdf
http://uk.farnell.com/texas-instruments ... dp/1470804

Mark

Since the joysticks just mimic key presses, would wiring them in parallel with the keyboard matrix, as on the original MTX still work for the Pi ?

How about a 74HC154, it's a 4 to 16 decoder, but its CMOS so should work at 3.3v ? It's a similar sort of cost too.

The extra lines might even enable the country code to be faked/detected.

Martin A wrote:Since the joysticks just mimic key presses, would wiring them in parallel with the keyboard matrix, as on the original MTX still work for the Pi ?

Yes, there would be no operational problem with that. The only concerns are RFI and cable capacitance. But I don't really see these being a problem

Martin A wrote:How about a 74HC154, it's a 4 to 16 decoder, but its CMOS so should work at 3.3v ? It's a similar sort of cost too.

You could use one of these, but ideally we are looking for open collector/open drain outputs to save fitting lots of 1N4148 diodes (which also reduce the output voltage range).

You can drive 74LS inputs from 3.3V CMOS logic, just include some pull-up resistors (say 10k to the +3.3V rail) on the inputs to help the CMOS get up to the TTL logic high (VIH=2V Min.).

The outputs from the 74LS145N are not a problem, as they are open-collector

And I'm sure a +5V supply can be found from somewhere

Mark

However, for fast scanning of a limited number of keys, some games may drive more than one line low at the same time.

Bill

If there are games (or indeed) other software that needs this, there are only two choices: exactly replicate the keyboard interfacing functionally, or use your own hardware arrangements and then simulate the effect to the MTX system so that the game software still thinks it is seeing a MTX keyboard. It just means the emulation software has to be a bit more complex.

Mark

@Dave, you are good at opening these cans of worms

Mark

Another thought...
If a two way serial link (I2C or SPI) is provided between the MEMU-Pi and a micro-controller, the MEMU-Pi can send the output scan data to the micro-controller, which can output it to the keyboard. The micro-controller then reads the keyboard "sense" lines and sends this data back to the MEMU-Pi.

If done correctly, this should be completely transparent to any software

Mark

Mark,

As you say, there are at least two ways of interfacing an MTX keyboard to MEMU:

The direct method: Whatever the emulated Z80 writes to port 5 is applied to the keyboard drive lines, and When the emulated Z80 reads ports 5 or 6 it receives whatever is on the keyboard sense lines.

The indirect method: Have a software simulation of the MTX keyboard. The emulated Z80 sets virtual drive lines and reads virtual sense lines. The state of the individual simulated keyboard keys are updated in response to physical keyboard events. This is, of course, how MEMU works with a normal PC keyboard. And as you say, it would be possible to implement custom scanning of the MTX keyboard and then generate keyboard events, irrespective of what the emulated Z80 is doing.

However, ultimately there are 20 pins on the MTX keyboard connector, at least 19 of which have to be connected to the smaller number of RPi GPIO pins. Whether you do this using a combination of a 3-8 decoder (3 bits) for the drive lines plus a 10-1 multiplexer (4 address + 1 data bit) for the sense lines, or an I2C I/O chip or a microcontroller; these are all port expanders of one form or another, which is what I said in the first place.

Would you care to come up with a hardware design for Dave?

Bill.

1024MAK wrote:@Dave, you are good at opening these cans of worms

Mark

I'm always happy to issue a challenge

- I just need someone to solve it now