MSX keyboard

[Robb Bates]

Wayne,

I'm thinking about making an MSX compatible keyboard and I'm reading the mky.asm code.

Am I correct in that the code under CP/M converts the matrix keyboard into PS/2 scan codes which are then converted to ASCII input for the BIOS somewhere else?

And several of the the MSX keys can be interpreted as standard PC type keys?  ALT, WIN, PRINTSCRN, PAUSE, BREAK and such?

Would it be safe to say that I can be both CP/M and MSC compatible as long as I build a matrix that meets the MSX standard, but add some extra rows for extra keys that CP/M could use,  Though I'm not sure what all those might be, but I know End Page Up, Page Down and some Function keys are missing from MSX.

Can you give me any guidance?  Anything to watch out for?

Robb

[Doug Jackson]

Hi Rob,

There is a whole suite of well engineered boards that implement MSX for RC2014 from a fellow that has put the designs on GitHub.

I have his keyboard.  Its very yellow, but uses beautiful keys witches.

Here is a link

https://github.com/dinoboards/yellow-msx-series-for-rc2014

Doug Jackson

VK1ZDJ 

--
You received this message because you are subscribed to the Google Groups "RC2014-Z80" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rc2014-z80+...@googlegroups.com.
To view this discussion, visit https://groups.google.com/d/msgid/rc2014-z80/abf9773b-47f7-499f-9e4c-a93077ef4161n%40googlegroups.com.

[Robb Bates]

Dean has some great stuff!  I'm considering not re-inventing the wheel and just getting his keyboard.  There's also the omega keyboard, but I'm not sure how well that would work with the RC2014.  Would require some hacking.

But I kind of want to make my own for some reason.  If you've seen my 6502 project, I've pretty much created an entire computer (effectively the same thing as an RC2014) from the chips up, with my own PCB designs and drivers and OS.  The only thing I haven't built was the keyboard.  So it's almost a rite of passage for me.

Robb

[Robb Bates]

On that note, I'm looking at my PC keyboard and trying to think of which keys I have never used on my RC2014.

I want to basically build a keyboard for the MSX, but also one that will double duty for CP/M.  So I'll need a mix of both keyboards.  It's already 95%+ the same.

I'm trying to think... have I ever used any F-keys in CP/M?  Or the page up/down?  Alt? End?  Numpad?

The MSX needs F1 through F5...but does CP/M need any F-keys?

Robb

[Richard Deane]

I believe that you should consider, not what cp/m needs, but what the applications under CP/M need. Applications are configured for one or more of several terminal types, eg adm3a, vt52, vt100 and more modern xterm. Your keyboard needs to be generating ASCII characters and escape sequences. Scan codes are irrelevant to the applications. Look at dBase II. Wordstar 3, Supercalc2 and  Turbo Pascal 3.01a. If your keyboard works with those then it would seem sufficient.

To view this discussion, visit https://groups.google.com/d/msgid/rc2014-z80/9a09ef93-9840-4e96-b724-35d81afd3874n%40googlegroups.com.

[Doug Jackson]

I completely agree.

CP/M has no concept of scan codes. It was always designed to take input from ASCII terminals.

Supporting VT100 keys, or ADM3a or even Hazeltine works, keeping in mind that the first step of installing any piece of commercial quality software was telling it what type of terminal you were using.

I vividly remember installing Wordstar and Turbo Pascal. 

Doug

To view this discussion, visit https://groups.google.com/d/msgid/rc2014-z80/CAG2GuRZTmTrvW2C33mneFzxbhNg3XTsNqXu9jc2wLdbK9wPctA%40mail.gmail.com.

[Robb Bates]

Well, true that CP/M itself doesn't care about scan codes.  But Wayne's keyboard driver does.  And I was also thinking last night about modifying the keyboard driver so that we could use some of the keys we're used to using but aren't implemented in the applications.

i.e. have the keyboard driver be able to emit control codes.  Page Up could emit a ^R and Page Down a ^C, which are effectively the same in most CP/M apps.

In fact, the keyboard driver could have different mappings for different apps.  A hot key could switch between the arrows emitting the usual escape codes, which some apps use and emitting the control codes for those that don't.

[Peter Onion]

On Wed, 2025-04-23 at 05:09 -0700, Robb Bates wrote:
> Well, true that CP/M itself doesn't care about scan codes.  But Wayne's keyboard driver
> does.  And I was also thinking last night about modifying the keyboard driver so that we
> could use some of the keys we're used to using but aren't implemented in the
> applications.
>
> i.e. have the keyboard driver be able to emit control codes.  Page Up could emit a ^R
> and Page Down a ^C, which are effectively the same in most CP/M apps.
>

Robb,

If you look in the "RomWBW Systems Guide", Section 10.7 Video Display Adapter (VDA) you
will see that codes 0xE0 to 0xFF are already assigned to the Function keys,
Insert/Delete/Home/End/PageUp/PageDown/Cursor keys etc..

PeterO

[Wayne Warthen]

Hi Folks,

Just a few comments on this thread FWIW.

The Yellow MSX keyboard is very nice and is based on the Omega keyboard.  I think the Yellow MSX keyboard design is very close to the Omega.  The main difference is really in the RCBus interface board that allows it to be on the RCBus.

The MSX keyboard driver in RomWBW does indeed emulate scan codes under the covers.  I'm actually not entirely sure why Dean did it that way.  RomWBW itself does not know about or care about scan codes.  The PS2 keyboard driver does handle scan codes because it must.  I suspect that Dean was emulating the PS2 driver.

RomWBW deals with keyboards basically as a byte stream.  The bytes are normally just the ASCII equivalents.  There are supplemental bits that indicate the state of the shift/ctrl/etc. keys.  As already pointed out, values 0xE0-0xFF are assigned to a generic set of keys like functions keys, arrow keys, etc.

If you implement a new keyboard and driver, I strongly recommend having the driver conform to the established keyboard byte stream.  Then, as you wish to create key mappings, considering implementing a new terminal emulation module.  You could take the existing ANSI/VT100 module and enhance it or create your own.  Doing it this way will allow any keyboard to be used with the key mappings you want.

One more thing to keep in mind about keyboards.  The MSX and similar keyboards use matrix scanning.  There is substantial overhead to this.  The PS2 keyboard interface is "intelligent" and has very low overhead, buffers incoming keys on its own, and needs no interrupts.

Thanks, Wayne

[Dean Netherton]

Hi Robb and all,

Thought i should add my 2 cents -- that be 2 aussie cents.  (Side Note: It's been many years since Aussie currency removed the 1 and 2 cents coins.  So all amounts need to be divisible by 5 - so rounding 2 cents to nearest - would mean - here are my 0 cents??)

Dean has some great stuff!  I'm considering not re-inventing the wheel and just getting his keyboard.  There's also the omega keyboard, but I'm not sure how well that would work with the RC2014.  Would require some hacking.
But I kind of want to make my own for some reason.  If you've seen my 6502 project, I've pretty much created an entire computer (effectively the same thing as an RC2014) from the chips up, with my own PCB designs and drivers and OS.  The only thing I haven't built was the keyboard.  So it's almost a rite of passage for me.

At the risk of losing a sale -- a lot of what we do here, I would submit, is 're-inventing the wheel'.  Adding our own flare - or just doing it to learn in the process of design and build. By all means 'steal' my schematics and anything else I have published as you wish.

The MSX keyboard driver in RomWBW does indeed emulate scan codes under the covers.  I'm actually not entirely sure why Dean did it that way.  RomWBW itself does not know about or care about scan codes...... I suspect that Dean was emulating the PS2 driver.

Hmm.  I did it a while ago, and yep - probably copy&paste coding to get it to work - at least i didn't Vibe code it!  Perhaps there is some optimisation that can be done to the driver.  

Dean

--
You received this message because you are subscribed to the Google Groups "RC2014-Z80" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rc2014-z80+...@googlegroups.com.

To view this discussion, visit https://groups.google.com/d/msgid/rc2014-z80/c0b76d6f-5ce3-4865-a03d-2698a9776881n%40googlegroups.com.

[Dean Netherton]

Hi Wayne,

Just to follow up, regarding scan codes - i suspect the reason I implemented 'ps2 scancodes', was that I was trying to be consistent with the hbios system call responses.

### Function 0x4E -- Video Keyboard Read (VDAKRD)

| **Entry Parameters**                   | **Returned Values**                    |

|----------------------------------------|----------------------------------------|

| B: 0x4E                                | A: Status                              |

| C: Video Unit                          | C: Scancode                            |

|                                        | D: Keystate                            |

|                                        | E: Keycode                             |

Does this mean that only the E: Keycode response is required.  D:Scancode and E:Keystate are optional - and only supplied for the PS2 driver?

Dean

[Sergey Kiselev]

The Dean's keyboard is a very slightly modified version of Omega keyboard. As far as I know, the modifications are:

- Diodes for every key to prevent ghosting. Not sure if they are really needed as the original MSX systems only have these on Shift, Graph, and Code

- Use two 74HC138 3-to-8 decoders instead one 74LS145 4-to-10 decoder

You would still need to use the 8255 PPI based interface board to connect the keyboard to a RC2014 system

[Wayne Warthen]

On Wednesday, April 23, 2025 at 7:16:10 PM UTC-7 Dean Netherton wrote:

Just to follow up, regarding scan codes - i suspect the reason I implemented 'ps2 scancodes', was that I was trying to be consistent with the hbios system call responses.

### Function 0x4E -- Video Keyboard Read (VDAKRD)

| **Entry Parameters**                   | **Returned Values**                    |

|----------------------------------------|----------------------------------------|

| B: 0x4E                                | A: Status                              |

| C: Video Unit                          | C: Scancode                            |

|                                        | D: Keystate                            |

|                                        | E: Keycode                             |

Does this mean that only the E: Keycode response is required.  D:Scancode and E:Keystate are optional - and only supplied for the PS2 driver?

Hi Dean,

This is entirely my fault.  The documentation leads you to believe that the driver must provide scancode, keystate, and keycode.  That is not correct.  The only mandatory field is keycode.  Keystate is desirable for future enhancements, but is not currently used by the ANSI emulation.  The value should be zero if not available.  Scancode probably should not have ever made it into the API.  I probably figured it might be useful in some scenario.  It is entirely optional.  The documentation should have indicated that the Scancode value is optional for the driver to implement and that it is driver dependent.  This means that the scancode would be entirely different depending on the hardware.  So, in the case of the MSX keyboard, it could be a code that represents the "scancode" from the keyboard matrix scan.

I will clarify the documentation and apologize for the extra work this caused you.

Thanks, Wayne 

[Dean Netherton]

Hi Wayne,

Thanks for the clarification - make total sense.

And No need to apologize at all mate.  Seriously - none.  This is free opensource code... I am old enough -- I should have clicked myself that the scan codes may not have been necessary.  I think I mostly copied code - so I don't think there was much 'effort'.  Nonetheless, this may mean that the code can be optimised. 

I have been working on the USB Keyboard driver - which has very different scan codes -- So this helps me clean-up that driver a bit.  If I can reduce what the interrupt handler's needs to do - then it can reduce the performance impact to the system..

 

Cheers

Dean

--

You received this message because you are subscribed to the Google Groups "RC2014-Z80" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rc2014-z80+...@googlegroups.com.

To view this discussion, visit https://groups.google.com/d/msgid/rc2014-z80/bf4e6403-65d9-4fc2-ba50-e47422464c91n%40googlegroups.com.