search

wwarthen / RomWBW

System Software for Z80/Z180/Z280 Computers
GNU Affero General Public License v3.0
341 stars 101 forks source link

ch376 native usb support #456

Open dinoboards opened 1 week ago

dinoboards commented 1 week ago

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:

image

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.

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: https://github.com/wwarthen/RomWBW/compare/master...dinoboards:RomWBW:dean-ch376-usb-native-4

Interested in your thoughts - but no rush.

Dean

wwarthen commented 1 week ago

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:

Thanks, Wayne

dinoboards commented 1 week ago

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