USB-HID keyboard via CH376s

Page 1/2
| 2

By S0urceror

Supporter (4)

S0urceror's picture

21-11-2019, 15:53

Hi,

I have a pet project based on the CH376S where I try to connect a USB-HID keyboard. Although I am confident I can get it working in assembly I am already thinking about the next step.

Which is to integrate this new keyboard driver into the BIOS. Since MSX does not know the concept of drivers a hook on the BIOS or replacing the current function could do the trick. What do you think?

But... How much software is out there that directly reads the PPI? What did the standard say about this? Always use BIOS?

Any comments? Stupid endeavour? Let me know.

Login or register to post comments

By sdsnatcher73

Hero (654)

sdsnatcher73's picture

22-11-2019, 13:12

I’ve been talking to Sharksym about MMCSD v4 and one of his new projects (SLT-X to be specific). For that last project he says he is cloning PPI port A8. I have no idea if something similar is possible for your project (or if keyboard is even accessed over port I/O)...

By Giangiacomo Zaffini 2

Master (167)

Giangiacomo Zaffini 2's picture

22-11-2019, 14:32

I thought It was easier to take PPI in and just satisfy it's low count pins interface for keyboard with fast GPIO of a modern and cheap micro and some level translator, I was thinking of an arm Cortex-M, or a weaker one.
On a side note, is CH376S chip commonly used for file management?

By NYYRIKKI

Enlighted (5398)

NYYRIKKI's picture

22-11-2019, 14:46

I have some experience about the subject... I plugged PS/2 keyboard directly to joystick-port and wrote a driver to use it by using hooks. This kind of solution works fine on DOS, word processing and BASIC applications, but games are usually out of question. If they don't use I/O directly then they at least use SNSMAT-routine that is a bit more hard to emulate without performance hit. Sometimes key presses are interpreted from RAM NEWKEY-table. In general standard keyboard scan is a bit poison for game developers since it takes quite a bit of time and the amount depends of the MSX model. (Usually the scan is done every 2 or 3 VDP interrupts, but not always.) If the game is time critical it is better to implement the keyboard read by other means.

By Palver

Rookie (21)

Palver's picture

23-11-2019, 23:53

You can use a raspberry pi to read the usb keyboard data and feed ppi pins. I tried and works flawlessly. The only problem is the msx starts way faster than the raspberry, so you have to wait about ten seconds to get the keyboard working.

By ducasp

Master (163)

ducasp's picture

24-11-2019, 02:16

Palver wrote:

You can use a raspberry pi to read the usb keyboard data and feed ppi pins. I tried and works flawlessly. The only problem is the msx starts way faster than the raspberry, so you have to wait about ten seconds to get the keyboard working.

Or do it baremetal, pretty fast boot time. Wink

By sd_snatcher

Prophet (3092)

sd_snatcher's picture

24-11-2019, 15:33

S0urceror wrote:

Since MSX does not know the concept of drivers

The MSX knows the concept of drivers, but back then the concept was different. Drivers were compiled (IOW, embedded) in the BIOS of the hardware that it was meant to support. User-loadable drivers would be (1) too expensive, since it would require more RAM a floppy disk and (2) Too complicated for normal users to setup, and the MSX was intended to be as easy to use as an appliance.

Since all MSX existing models came with exactly the same 8255 PPI keyboard interface, all of them came with exactly the same embedded keyboard driver, changing only the keyboard layout decoder. But the MSX Technical handbook explicitly stated that the keyboard interface (as well as any other hardware) could be different:

This is a quote from the page 336 of the book:
"For example, the current MSX scans the keyboard by using 8255 PPI. In the near future, however, there may be computers having separate keyboards using an infrared communication link. This new computer may not use the 8255 PPI ; it might use some other chip to do serial communications to handle the keyboard. If the software scanning the keyboard uses the 8255 directly, the new computer would not support the software."

By Grauw

Ascended (8515)

Grauw's picture

24-11-2019, 16:05

S0urceror wrote:

How much software is out there that directly reads the PPI?

Plenty. I can’t give a number but it is done, to be more precise probably you just need to give it a go. I think the majority of 80s commercial software (esp. Japanese) probably doesn’t though.

So it sounds like a cool project, just be aware that it won’t be universally compatible with all software. Implement the programming interface on a hardware level if that’s what you want.

By S0urceror

Supporter (4)

S0urceror's picture

25-11-2019, 14:30

Thanks guys for all the feedback. To summarise:

  • The driver is in the BIOS and could be changed there, or via hooks extended.
  • DOS and BASIC use this default driver. Everything that is well behaving.
  • A lot of other software exists that goes around this. Games directly scan the PPI, etc.

For my use-case being able to use it in BIOS and DOS is already great. I plan on using my trusted USB-HID compliant wireless keyboard to control my MSX!

First I will finish the USB-HID driver. When I'm done I will share it with you guys. BTW. the CH376 is the successor of the CH372 and CH375 and it can connect to any USB device. This opens up a lot of opportunities!

@NYYRIKKI, can you shed some light which hooks you used?

PS. I will also soon share my open-source USB Nextor Driver and BASIC extensions. Inspired by the RookieDrive but then different.

By NYYRIKKI

Enlighted (5398)

NYYRIKKI's picture

25-11-2019, 16:41

S0urceror wrote:

@NYYRIKKI, can you shed some light which hooks you used?

I had to look from the source and it seems that I hooked in from H.TIMI and then just replaced the whole keyboard scan routine with my own version while writing high value to SCNCNT. I remember one of the reasons to take such drastic approach was that the keyboard scan has nasty habit of messing up with joystick port pins 6-8 and I didn't want that since these were the pins that were actually wired to the PS/2 keyboard data and clock pins... but it seems that this was also pretty much my only option as the advanced official keyboard hooks are limited to H.KEYC and H.KEYA that expect scancode to arrive from PPI -> they are not good in this kind of scenario. I guess that if you don't want to start modifying ROMs, you have to do something similar. Edit: Although I used H.TIMI, actually H.KEYI sounds like the one that is actually meant for this purpose according to standard. Smile The calls are pretty much next to each other in the ROM.

Quote:

PS. I will also soon share my open-source USB Nextor Driver and BASIC extensions. Inspired by the RookieDrive but then different.

This sounds interesting!

By ducasp

Master (163)

ducasp's picture

25-11-2019, 22:16

I'm working with Victor Trucco and other 10 developers on a Raspberry -> MSX Interface, Victor already implemented a first version of a USB Keyboard working in any MSX, basically he intercepts A9/AA/AB, and answer according to the USB keyboard status. It works like a charm since the keyboard lines are pulled-up and if you put it down while being read, it won't cause any issues, as long as you are not pressing the msx keyboard at the same time (then you could pottentially short the keyboard multiplexer outputs with the signal being fed by the interface, not sure if the current sank or drawn in case of opposing polarities could damage the multiplexer or not, so, you can use one or the other).

This doesn't require bios changes, driver, etc and work with anything, and since usually this is used because of the difficulty of finding keyboard replacement for bad keyboards, seems like a good compromise in my oppinion.

Page 1/2
| 2