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

How often these days do we hear of MTXs with keyboard problems, repeating keys, "sticky" keys, plain dead keys ?

From the inventive mind of Bill Brending, here's the solution.

Use a PS2 keyboard instead!

Bill's idea is to use a Propeller to provide an interface between the serial PS2 protocol and the matrix based MTX keyboard header.

I've build a prototype to test the idea on a real MTX The 40 pin socket is for the propeller, with the usual 8 pin serial eeprom holding the boot code and a 3v LDO regulator to power both. The 2, 14 pin, sockets are for a pair of 7407 or 7417 open collector drivers to convert the 3v propeller output to 5v and cope with the resistors connected to the keyboard header in the MTX.

The reset button is now redundant, as a later revision of Bill's code allows reset from the keyboard just like the MTX.

In place, on a real MTX, with a keyboard attached. The flying lead to the central I/O socket is the 5v power source, as that's the only thing needed that's not available on the 20 way keyboard header. Having proved it works, Dave's been working on a layout that will fit under the keyboard to allow the case to be closed. The position of the propeller on the prototype prevents that.

On Dave's wish list, and there are hints that Bill may be able to get it to work, is adding USB keyboard support.

Wow! Thats amazing. Well done all.

Why not mount a MTX in a ATX case with all the hardware mods you guys have come up with. It would have to be a black case That would cure the problem of space and mount points for drives and memory sticks etc.

It would still be good to use a PS/2 keyboard on an original MTX.

I had been preparing a web page that n the subject.......

It’s still in “draft”, but here it is . . . . .

http://www.primrosebank.net/computers/m ... ps2kbd.htm

Regards
Dave

Just to get the attributions right (as per Dave's web page):

Original idea - Dave
Suggestion of using Propeller - Martin
Propeller firmware - Me
First hardware test - Martin
PCB concept design - Dave

It's actually possible to get ATX size prototyping boards. Which means its possible to build something a bit like

This.... That's an old picture, the IDE and full MTX style keyboard are now working, instead of relying on the plug in card.

However the long term plan is to add a PS2 (or USB) keyboard interface and USB to serial to the SIO.

Even incomplete, the wiring might be a bit much for some to attempt ....

Dave wanted a description of the Propeller code ...

The Propeller chip is a fast 32 bit micro-controller, designed for hardware interfacing, with eight largely independent cores, called "Cogs" in Propeller speak. It can be programmed in assembler, a high level language designed specifically for the chip called "Spin", or in a number of other languages such as C. In designing software for the Propeller it is typical for each cog to be dedicated to a specific task, such as controlling a piece of hardware, and for the cogs to cooperate to implement the entire functionality.

For the PS/2 keyboard interface, the Propeller is under-utilised, employing only four cogs, and not those fully:

Cog 0
The propeller always starts by executing code written in Spin on the first cog. This may be a major part of the software, or it may just le initialisation code. In this case it just initialises some addresses in memory, starts the next three cogs, running assembler code, and then halts.

Cog 1
This is the interface to the PS/2 keyboard. Much of the code was borrowed from the Propeller Object Exchange. When a key is pressed or released on the keyboard, the keyboard sends 1-3 bytes of serial data over clock and data lines to the Propeller. This first cog receives this data and turns it into a one byte event code, with 7 bits identifying the key, and one bit to indicate key press or release. These event codes are then added to a first-in, first-out (FIFO) buffer. Keys on the PS/2 keyboard which have no MTX equivalent are ignored at this point and not added to the FIFO.

This cog performs two other functions:

• On startup of the cog, it first sends a reset command to the keyboard, so that it is in a known state, and then sets the auto-repeat rate on the PS/2 keyboard to the slowest possible. I would have turned auto-repeat off if that was an option. Note, on the MTX the keys will still auto-repeat, but that is functionality built into the MTX ROM, not the PS/2 keyboard repeat.
• Presses of the "Scroll Lock" key are not added to the FIFO. Instead they cause a command to be sent back to the keyboard to turn on or off the Scroll Lock LED. Also the state of Scroll Lock is recorded by a flag in Propeller RAM.

Cog 2
This cog retrieves events from the FIFO buffer, and updates an in-memory model of the MTX keyboard accordingly. For most keys this is simple, as the PS/2 key corresponds to a single MTX key. For a few keys, the MTX key affected also depends upon the shift state at the time the key was pressed. The affected MTX key has to be remembered so that the correct MTX key can be released on receiving a key release event. For MTX+ use, if Scroll Lock is enabled, the key mapping is changed again, making use of the three key matrix positions that don't have a key on the MTX keyboard, to work around the issue of different shift state between some symbols on the PS/2 and MTX keyboards.

Cog 3
This cog reads the state of the MTX keyboard drive lines, and outputs the the selected row of the in-memory keyboard model to the sense lines. The MTX Z80 writes the drive lines with one instruction, and reads the sense lines with the very next instruction. With a real keyboard the sense lines update instantly (or at least at the speed of light). The Propeller is significantly faster than the Z80 but updating the sense lines in time is still a challenge. In order to achieve this, it has to be assumed that only one drive line is active at any one time. This is always true for the MTX ROM, but may not be true for all games that implement their own keyboard decoding. The Propeller code uses a binary search to identify the active drive line. This enables the required keyboard row to be selected using only three tests.


This structure means that USB support can, in principle, be implemented by replacing the cog 1 code by USB code which similarly queues key press and release events in the FIFO buffer.

Hi Bill,

thanks a lot for the description!

regards
Dave

Yes, a very nice write up

Mark

Bill B wrote:This structure means that USB support can, in principle, be implemented by replacing the cog 1 code by USB code which similarly queues key press and release events in the FIFO buffer.

Could the theoretical USB code go in say cog 4, so that either type keyboard could be used depending which is plugged in at the time ??

The USB protocol is far more demanding than PS/2. Using the USB driver that I have found requires three cogs to read the keyboard. There are also some differences in the electrical connection required.

Dave's current plan is to have a link (or links) which adapt the electrical interface appropriately, and applies a high or low signal to one of the Propeller pins. On startup, the Propeller would read the state of this pin, and start either the PS/2 or the USB keyboard read code as required. There should be room in the EEPROM for both lots of code.

The other option might be to have completely separate electrical interfaces for USB and PS/2 keyboards, connected to different pins on the Propeller. Then run both the PS/2 and USB keyboard reade code. That would require modification to the FIFO buffer. A FIFO with one writer and one reader is fairly simple. Two writers requires locking to prevent conflicts.