MSX USB

Master (210)

26-01-2020, 10:03

Fellow MSX-ers,

As MSX-ers we understand the power of standards-based hardware and software. This allowed us to use cartridges across 4 generations of MSX (I, II, II+, tR). And, thanks to an elegant BIOS that was extendable, it allowed us to write software on any machine from any vendor. So that we wouldn't feel stuck in the 80's, forever.

Just like the cartridge port was the standard connector for MSX. USB is the standard connector for actually everything these days. So why we don't have USB support yet?

In this spirit I created MSX USB. It is a combination of standard hardware and software that I would like to share with you.

The hardware is based on the CH376s and inspired by the RookieDrive created by Xavirompe. I made sure it works on any MSX and it fully supports the _BUSDIR signal so that it also works on Philips's. The schematics are posted on my GitHub. I guess you can also go out an buy a RookieDrive and use the software but I haven't tested this.

On the software side I want to work together with the community to create drivers for different USB powered devices. To make a jumpstart I already created:

A USB flashdrive driver for NEXTOR. This enables us to connect any FAT32 volume and create multiple FAT16 images on it. Within MSX Basic you can switch between these images with the _INSERTDISK command. Uses the high-level API of the CH376s.
A USB HID compliant keyboard driver. I am now able to connect my wireless Logitech keyboard to the MSX and use it in BASIC and DOS. Uses the sparsely documented low-level API of the CH376s.
Various debugging tools, like CH376s interface and emulator for OpenMSX and CocoaMSX. This allows us to prototype things fast.
C++ based test template to discover CH376s connected USB devices and test different USB protocols.

All of this is also present on my GitHub.

Are we done? Of course not! Next to improving the above mentioned drivers I intend to expand this and develop:

USB Ethernet driver. UNAPI compliant of course.
USB Serial driver.
Any other suggestions?

So what do you think? Want to help me to support as much as possible USB devices on the MSX? Do you want to participate in the software development? Do you want to test and bug fix things? Or just have a cool idea to include?

Let me know!

Cheers,

Sourceror

Entrar ou registrar-se para comentar

Por S0urceror

Master (210)

26-01-2020, 10:05

Update: I intend to join the MSX fair in Nijmegen next week. If anyone is interested we can connect face to face over there!

Por Louthrax

Prophet (2465)

26-01-2020, 10:44

Nice project !

The USB keyboard could be used in games with SofaROM. SofaROM patches calls to SNSMAT to inject joysticks buttons as keys, same could be done for USB keyboards (and USB joysticks / joypads) I guess.

Por zPasi

Champion (499)

26-01-2020, 11:52

Great!

But "the CH376s board will be visible on port 10h and 11h on the MSX" - that may not be very good idea. Those ports are used by the "second AY-3-8910 PSG", as in MFR, Carnivore II and GR8NET.

Por lintweaker

Champion (464)

26-01-2020, 11:54

Nice! Are you bringing some boards to the fair to show ?
I'll be showing my vDisk virtual disk (hw v2) cartridge.

Por Grauw

Ascended (10768)

26-01-2020, 12:28

Cool development! I’m looking forward to seeing it in action. A USB-C port would be nice as well?

zPasi wrote:

But "the CH376s board will be visible on port 10h and 11h on the MSX" - that may not be very good idea. Those ports are used by the "second AY-3-8910 PSG", as in MFR, Carnivore II and GR8NET.

The I/O-ports space is very crowded, it is difficult to find unused addresses and if you do use one it will make it unavailable for other hardware in the future. If your cartridge is not built out of basic components, but has a CPLD, FPGA or similar, I recommend to use Switched I/O ports. There is plenty of I/O space there, avoids conflicts with other hardware, and additional benefit is that the presence is easy to detect.

Do be aware that unfortunately Franky uses I/O ports 48-49H without being switched I/O-aware, so best to avoid those two. But other than that you have 13 I/O ports at your disposal.

Por lintweaker

Champion (464)

26-01-2020, 13:55

Grauw wrote:

Cool development! I’m looking forward to seeing it in action. A USB-C port would be nice as well?

zPasi wrote:

But "the CH376s board will be visible on port 10h and 11h on the MSX" - that may not be very good idea. Those ports are used by the "second AY-3-8910 PSG", as in MFR, Carnivore II and GR8NET.

Do be aware that unfortunately Franky uses I/O ports 48-49H without being switched I/O-aware, so best to avoid those two. But other than that you have 13 I/O ports at your disposal.

Do you know of any reference design/schematic for this?

Por Manel46

Paladin (674)

26-01-2020, 15:41

If you get something similar to Nowind, it will be great.
I got one of the last ones that came out.
Since then I do my tests on real hardware, without needing to record my MFR micro SD.

Por Grauw

Ascended (10768)

26-01-2020, 16:19

lintweaker wrote:

Do you know of any reference design/schematic for this?

I don’t know of anything published like that. Sounds like it could be pretty useful if someone made such a thing. The essence is simple, an “enable” latch which is set by a write of a specific ID to 40H, reset otherwise. Then if enable is latched, returning the complement of the ID when reading 40H, and accessing whatever hardware is connected from 41H through 4FH.

Just slightly too much for discrete components in a small enclosure perhaps, essentially you have two address decoders rather than one, but simple to do in a CPLD.

Por zPasi

Champion (499)

26-01-2020, 17:05

Grauw wrote:

The I/O-ports space is very crowded, it is difficult to find unused addresses and if you do use one it will make it unavailable for other hardware in the future.

A simpler approach would be to just make the port addresses configurable, e.g. with jumpers.

I wonder, is the MSX I/O address space really restricted to 0 - 0FFh? I experimented with my machine(s) and addresses above that (like 100h) did work as expected.

Por Danjovic

Champion (335)

26-01-2020, 18:05

zPasi wrote:

Grauw wrote:

The I/O-ports space is very crowded, it is difficult to find unused addresses and if you do use one it will make it unavailable for other hardware in the future.

A simpler approach would be to just make the port addresses configurable, e.g. with jumpers.

I wonder, is the MSX I/O address space really restricted to 0 - 0FFh? I experimented with my machine(s) and addresses above that (like 100h) did work as expected.

Did you mean to use the upper bits of Z80 I/O addressing like the Sinclair Zeddies?