MSX USB

With USB MIDI support i meant not only playing MIDI's on MSX, but also receiving MIDI data (like Philips Music Module and SFG can do) to support some retro-DAW-like setups

It is quite cool that you are creating an UNAPI specification for USB controllers :) I would recommend that you send your specs (if you didn't already send it) to Nestor/Konamiman so he can review and publish it, that might help other developers wanting to create softwares for your USB interface as well as perhaps some other devices having the same interface (i.e.: Victor Trucco PIsquared, if someone takes over the idea, could implement the specification ;)) congrats for this project, it is shaping up really good :)

This is a good approach. It’s one of the enhancements of the UNAPI specification I proposed to Nestor, to reduce the overhead.

Wireless USB keyboard now working on my MSX USB Unapi driver.

The intent is to release all subsequent drivers on top of my MSX USB Unapi driver as well. This way we have a common foundation. Other hardware developers that intent to create USB cartridges can make them MSX USB Unapi compatible as well and then all client software and drivers will work straight away.

The same MSX USB Unapi driver now powers both the lsusb client program and the new USB HID keyboard driver. I tend to release all my subsequent drivers on top of this MSX USB drivers as well to create an eco system.

Also experimented with a new way of calling Unapi functions. Unapi functions are normally called through the endpoint that was extracted via the appropriate Extended Bios call. Before you call the Unapi function, with function number in register A, you have to find out where the driver is located. In ROM, RAM or Memory Mapper. Based on that you need to call it in the right way. Internally the driver then has to check if the function number exists and call the right function.

I didn't like this setup. First, the burden of calling the driver depending location is placed on the client. Second, it is slower to first do a lookup based on index and then call vs direct call. Third, register A is not available anymore.

To circumvent this I created a hybrid. Function 0 is still the information function per the UNAPI specification. But Function 1 is a function that returns a jumptable. In my case the driver was programmed to be in ROM so the driver generates the correct RST30h calls. RAM or Memory Mapper drivers would choose another appropriate method. The client does now not need to know how to call. It just invokes the appropriate entry in the jumptable, et voila. All registers are now available as well. See the readme for more information.

For compatibility reasons most functions are available both through the jumptable as through standard UNAPI. But the ones that need to be fast go only through the jumptable.

Let me know what you think of this setup.

amazing, keep it up!