ch376 native usb support

[dinoboards]

Hi Wayne,

This is not eZ80 related.

Something else for your consideration.

I have been progressing over the last few weeks, the porting into RomWBW, the code I wrote for my MSX kits to drive the CH376 usb module. This code enables full usb protocol access - enumerating hubs, and many devices.

My msx build has support built-in to drive USB hubs, floppy disks, mass storage devices, keyboards and printers - with plans for other usb device types in the future.

I had always wondered how i could port this code to RomWBW. The first challenge is, I am using the z88dk c compiler to write the code.

I do have a working version on my local fork of RomWBW. See image of the boot up messages:

This is booting up using my ez80 -- but the code should work just fine on a standard Z80 CPU - as it does for my MSX system

To make this work, I had to create a 2 stage build process. First, use z88dk c compiler to convert the c code to assembler. Then load that assembly code into the HBIOS's standard build process.

I suspect you don't want to add z88dk to your toolchain requirements - and I would image it would be a challenge for window builds.

This is what i have done so far, for the build process.

• I have added the relevant c code to the directory Source/HBIOS/ch376-native/source-doc
• I have a makefile that when run, will compile/transpile the c code into assembly files in directories:
  • Source/HBIOS/ch376-native/base-drv (common code to enumerate and communicate usb devices)
  • Source/HBIOS/ch376-native/scsi-drv (usb mass storage hbios driver)
  • Source/HBIOS/ch376-native/ufi-drv (usb floppy hbios driver)
  • Source/HBIOS/ch376-native/keyboard (usb keyboard hbios driver
• Added to hbios, new config switches to enable optional including of the drivers. The HBIOS build process just see conventional assembly files to process. (so should work on windows etc)

At this stage, this means that if anyone pulled my fork, and does the normal HBIOS build process, they will be able to build in the usb drivers - no need to have z88dk installed etc.

But if someone wanted to 'patch' or change the code, they can of course change the 'generated' assembly. But they really should change the C source files and regenerate the assembled code.

I am hesitating to create a PR - as I am not sure if this is something you would want - and understand you might want to review and think about this a bit.

At the moment, the code is sitting on my fork: master...dinoboards:RomWBW:dean-ch376-usb-native-4

Interested in your thoughts - but no rush.

Dean

[wwarthen]

Hi @dinoboards,

This looks amazing. I definitely want to try and include this work. Yes, it is not ideal that the true source (C code) is not part of the build process.

It would not be an issue to add z88dk to the Linux/Macos build process. However, as you say, not easily accomplished under Windows. -- way too big and/or too complicated for general user to deal with. Your approach may be fine. I need to review it and think about it a bit.

I am out of town for the next 10 days. I probably can't do a reasonable review of this until I return. Do you mind if it waits until then?

Anyway, a couple of questions in the meantime:

• HBIOS space is becoming severely limited and has started breaking some configurations (out of space). If CH376 native is not enabled, does it impact HBIOS space at all? In other words, is the entire code purely independent?

• How much space is taken up by CH376 native? If the sub-drivers are independently enabled, can you break it down by each one?

Thanks, Wayne

[dinoboards]

I am out of town for the next 10 days. I probably can't do a reasonable review of this until I return. Do you mind if it waits until then?

Of course - no worries

HBIOS space is becoming severely limited and has started breaking some configurations (out of space). If CH376 native is not enabled, does it impact HBIOS space at all? In other words, is the entire code purely independent?

The entire code is base is independent. When disabled, no code or increase of HBIOS is applied. I used your approach of only #including the specific module when enabled.

How much space is taken up by CH376 native? If the sub-drivers are independently enabled, can you break it down by each one?

I was concerned that the code, since written in c, might just not fit at all. It does take a far bit of space.

CH376 Native occupies 5291 bytes.
CH376 USB Keyboard occupies 1333 bytes.
CH376 SCSI Mass Storage occupies 1603 bytes.
CH376 UFI Floppy Storage occupies 1838 bytes.

You can see from above the memory consumption. Keyboard, SCSI and UFI can be independently enabled. Only the core must be active for support. The core include all the hub enumeration and protocol helpers. An alternative version could possibly be developed, that does not support hubs - so only one USB device could be used at a time.

One thing that i guess needs to be figured out, is how to control the port numbers that are used. My CH376 module uses different ports, and at the moment the C code has these port numbers defined in code. Ideally we would want a way to configure ports in the same way that other hbios drivers are done. Will have a think about how this could be done...

Dean

[wwarthen]

Hi @dinoboards,

Just wanted to let you know I have not forgotten about this. I was basically out of commission for about 3 weeks and I now have a bunch of stuff I am trying to catch up on. I will be taking a deeper look at this soon.

Thanks, Wayne

[dinoboards]

Hi @wwarthen

Thanks for the update - no worries and no rush - its that time of year.

I intend to do some more testing myself of this --- just also not had a chance yet. Might be a couple of weeks myself - or given the holiday season - next year....

I may have observed a potential regression. (Not sure if its something I introduced, of its something else on the master branch.) I was having a couple of issues under CP/M- both with my USB driver and the CF driver.

• When attempting to access drives from D: and up - i was getting access errors
• I also tried to do SYSCOPY for cp/m 3 - and it would always return a DOS Error and not copy.

But i need to confirm exactly the scenarios. Confirm if its something i introduced, what branch, or something i am doing wrong, etc..

Dean