• Please review our updated Terms and Rules here

ISA USB board

The Lo-tech board uses 2C0h/2C1h (silkcreen/schematic are inconsistent, sorry). Although the code says, 'await interrupt', it actually seems to be using polled IO anyway so should work fine. Set the Lo-tech board to standard mode.

Also - on closer inspection it should work fine on 8088/8086 as there is CPU detection routine, however it will be really slow as there's no loop unrolling, and it incurs a jump on every byte. It can be easily changed obviously.

Code: 
.READ_IN_LOOP:		    ;LOOP LABLE
	IN AL, DX	;READ BYTE
	MOV [ES:BX], AL		;STORE BYTE
	INC BX				;INC BX
	LOOP .READ_IN_LOOP	;LOOP UNTIL DONE
 
Nobody told me if the driver work on the EMM board with a CH376 so far
 
I wave the w.ch bios code, your code, my driver code, i started to study the xtide code. By taking the Best ideas of all these, we can do something great...
The Best is to add support in the XTIDE, to not reinvent the well for most of the BIOS code.
 
A BIOS can t be faster than the driver on 8088/8086 as the bios is in chs, the driver and the USB chip are in LBA. Then, a double conversion is needed when using the Bios
 
pearce_jj said:
The Lo-tech board uses 2C0h/2C1h (silkcreen/schematic are inconsistent, sorry). Although the code says, 'await interrupt', it actually seems to be using polled IO anyway so should work fine. Set the Lo-tech board to standard mode.

Also - on closer inspection it should work fine on 8088/8086 as there is CPU detection routine, however it will be really slow as there's no loop unrolling, and it incurs a jump on every byte. It can be easily changed obviously.
Click to expand...
I modified mine to use 260h because 2C0h stomps on RTC which also use 2C0h, So what do i put for COMMAND_PORT and DATA_PORT, 0x260 and 0x261 ?, I'm off to work in a bit so can't test until tonight or tomorrow.
 
Malc said:
I modified mine to use 260h because 2C0h stomps on RTC which also use 2C0h, So what do i put for COMMAND_PORT and DATA_PORT, 0x260 and 0x261 ?, I'm off to work in a bit so can't test until tonight or tomorrow.
Click to expand...
Yes
 
I built the bios with COMMAND_PORT set to 0x260 and DATA_PORT set to 0x261 and it just hangs at . Resetting Module so i changed the port settings around and rebuilt the bios. This is where it now gets to and just sits there with a flashing cursor and nothing else. I have the card set to STD mode.

Standalone CH376S Firmware v0.66 - 2022-07-08
. Resetting Module:
. Setting USB Mode:
. IC Revision: B7

And that's it, It goes no further, I have tried CF / SD and Flash drive 128Mb / 256MB and 1Gb all tested and boot's into DOS 6.22 fine, I also enabled DEBUG mode in the bios thinking it might display an error but nope.?
 
Thanks for the hands-on, Malc!

Ugh. Insert a look of abject terror here that I can't really render through ASCII art alone. The CH376 documentation says
"The USB-DEVICE Mode of CH376 is totally compatible with CH372, the USB-HOST Mode of
CH375 is basically compatible with CH375."
Click to expand...
Well, yes, the Tautology Police say that the CH375 is compatible with the CH375, but it seemed a reasonable read that they meant that the CH376's host mode was compatible with the 375.

I have the nasty suspicion "basically compatible" is not so much "1:1 binary compatible" as "potentially compatible at an abstract library level".

I recall a rumour that the whole family of WCH USB-to-whatever chips (i. e. the CH340 used for cheap USB->TTL-serial adaptors) are basically the same microcontrollers running different firmware, so it's possible they're just gating open different commands to make slightly different products.

The next thing that's supposed to happen after printing "IC Revision: nn" is that it fires off the "DISK_CONNECT" and "DISK_MOUNT" commands. (Command 0x30 and 0x31).
The CH375 datasheet does not include those. It has DISK_INIT (command 0x51) that seems broadly similar to the setup parts of DISK_CONNECT and DISK_MOUNT, and DISK_INQUIRY (Command 0x58) that might replace the "leaves behind a device identifier part" of DISK_MOUNT.

We also appear to be missing DISK_CAPACITY (Command 0x3E) and instead have DISK_SIZE (command 0x53). Command RD_USB_DATA0 (0x27) seems to be replaced by RD_USB_DATA (0x28). WR_USB_DATA (Command 0x2C) seems to become WR_USB_DATA7 (Command 0x2B)

You might try changing the defines as follows to see if it gets us further. I'm afraid I can't really test the differences without a CH375 card in hand.
Code: 
CH376S_GET_IC_VER equ        0x01
CH376S_RESET_ALL equ         0x05
CH376S_CHECK_EXIST equ         0x06
CH376S_SET_USB_MODE equ     0x15
CH376S_GET_STATUS equ         0x22
CH376S_RD_USB_DATA0 equ        0x28
CH376S_WR_USB_DATA    equ        0x2B
CH376S_WR_REQ_DATA    equ        0x2D
CH376S_DISK_CONNECT equ        0x51
CH376S_DISK_MOUNT equ        0x58
CH376S_DISK_CAPACITY equ    0x53
CH376S_DISK_READ equ        0x54
CH376S_DISK_RD_GO equ        0x55
CH376S_DISK_WRITE equ        0x56
CH376S_DISK_WR_GO equ        0x57

Also a little curious what you meant by "goes no further." If it doesn't get something that looks like a response after DISK_CONNECT/DISK_MOUNT, it's supposed to give up and say there was no disc there. But maybe it's actually locked in an eternal loop because it fired off a command the 375 doesn't implement, and is waiting for the "task complete" flag.
 
Last edited:
Adding a bit more data, these swaps will not work out-of-the-box with a CH376S, so it's not just a "we only documented the model-specific features."

Specifically, on a 376S, when we finish trying to hit DISK_INIT/DISK_INQUIRY instead of DISK_CONNECT/DISK_MOUNT, we have a bunch of "DDDDDDDDDDDDDDD" for the model name, and when we hit DISK_CAPACITY/DISK_SIZE. and the size is some outlandish value (like 576GB on a 2GB drive) It does seem to proceed through the process though.

When I had the swaps for RD_USB_DATA0 and WR_USB_DATA, it also caught fire badly on the 376S. A "write a file" test seemed to badly corrupt the drive. So I'm going to stick to the 376-compatible ones for now. This seems to work (once I wrote a clean image back to the drive, I was able to boot and write a file) A supplemental 375 datasheet implies RD_USB_DATA0 and RD_USB_DATA may be equivalent though. The WR_USB_DATA/WR_USB_DATA7 difference is troubling.

gitlab.com

disc.asm · CH375-Workarounds · hakfoo / v40-bios · GitLab

GitLab.com
gitlab.com gitlab.com

So we now have a version that tries to use DISK_INIT/DISK_INQUIRY/DISK_SIZE. And if it does stupid things, you can set PROBE_DEVICE to 0, and then it doesn't display the detected garbage, and pretends the drive is 504MB no matter what. This seems necessary for me to not have weird crashes when operating systems try to get device characteristics and find nonsense.

There is definitely some leftover weirdness though on the 376. When it tries to boot, it does the "insert a boot disk and press any key to retry" fail behaviour, like there's garbage left behind in a buffer.

I sort of have an overarching theory that-- if those DISK_INQUIRY/DISK_SIZE commands work on the 376, maybe they're pointing to a different buffer than the one we're reading-- so we get back garbage when we want it, and it's polluting the first actual load attempt. There's some commentary about a second 376 datasheet that shows those commands existing https://pulkomandy.github.io/shinra.github.io/CH376_ext.html -- maybe they exist, but only in a form that doesn't work with the "read results" operation I'm using.
 
pearce_jj said:
Is there a reason to use the ‘376 over the ‘375?
Click to expand...
Hi,

It cad read/Write file from a FAT32.
Then, we can imagine having the disks in a form of disk image (.IMG) and swap them, have a config text file telling the file to use to boot and so on.

More or less like a Gotek, but for disk
 
Practically speaking, there are any number of 32-bit MCUs that support USB OTG, with far more flexible GPIO than those wch chips. Host mode driver code is available.

But don't let that stop you...
 
Hak Foo said:
Also a little curious what you meant by "goes no further." If it doesn't get something that looks like a response after DISK_CONNECT/DISK_MOUNT, it's supposed to give up and say there was no disc there. But maybe it's actually locked in an eternal loop because it fired off a command the 375 doesn't implement, and is waiting for the "task complete" flag.
Click to expand...
It just hung, All i could do was switch off the computer.
Hak Foo said:
You might try changing the defines as follows to see if it gets us further. I'm afraid I can't really test the differences without a CH375 card in hand.
CH376S_GET_IC_VER equ 0x01
CH376S_RESET_ALL equ 0x05
CH376S_CHECK_EXIST equ 0x06
CH376S_SET_USB_MODE equ 0x15
CH376S_GET_STATUS equ 0x22
CH376S_RD_USB_DATA0 equ 0x28
CH376S_WR_USB_DATA equ 0x2B
CH376S_WR_REQ_DATA equ 0x2D
CH376S_DISK_CONNECT equ 0x51
CH376S_DISK_MOUNT equ 0x58
CH376S_DISK_CAPACITY equ 0x53
CH376S_DISK_READ equ 0x54
CH376S_DISK_RD_GO equ 0x55
CH376S_DISK_WRITE equ 0x56
CH376S_DISK_WR_GO equ 0x57
Click to expand...
Done and it get's further, But it will not boot from any drive i have tried, I have used a 1Gb flash drive with a 504Mb image written to it, Changed the CHS parameters in the bios for smaller drives SD / CF and always get the same.
one.jpg All drives tested and boot perfectly fine into DOS 6.22.
 
Hak Foo said:
So we now have a version that tries to use DISK_INIT/DISK_INQUIRY/DISK_SIZE. And if it does stupid things, you can set PROBE_DEVICE to 0, and then it doesn't display the detected garbage, and pretends the drive is 504MB no matter what.
Click to expand...
I will have a play
 
I've poked at it more. It seems like the bring-up code is different when using DISK_INIT-- again/still, based on CH376S behaviour. At least on the 376, We don't actually need to do DISK_INQUIRY to get the device name, and removing it and changing the bring-up cycle a little avoids the "pollution" of the boot attempt I mentioned earlier. I suspect that in the past, when you tried to load the first sector, it reads garbage off from the DISK_INIT/DISK_INQUIRY and doesn't boot. For me, the main BIOS was detecting it as nonbootable and asking a retry, but your mileage may vary. It also looks like CH375 DISK_SIZE is different behaviour from DISK_CAPACITY; it provides 4 more bytes to indicate block size and returns the block count big-endian instead of little-endian.

The updated code at https://gitlab.com/hakfoo1/v40-bios/-/blob/CH375-Workarounds/disc.asm now as much CH375-compatible code as I can get away with, but still boots on CH376S.

The thing I might expect to be spicy would be trying to write to the disc. I'm still using CMD_WR_USB_DATA, since CMD_WR_USB_DATA7 seemed closely correlated to my drive getting corrupted. The sample CH375 code always uses CMD_WR_USB_DATA7.

This forum post (http://poligon2.kp4.ru/topic/32602) when ran through Google Translate, says of the CH376S:
In terms of working with USB packets, this module is almost identical to the CH375. The only difference found is that the developers replaced the WR_USB_DATA7 command (code 0x2B) with an absolutely identical command, the WR_USB_DATA command (code 0x2C), for no apparent reason. In this case, the 0x2B command on CH376 does not actually work!
Click to expand...

So you might need to adjust the line in the top of the file to
Code: 
CH376S_WR_USB_DATA    equ        0x2B
before assembling. As usual, no guarantees, likely full of bugs even on 376S, but definitely something different to try.

pearce_jj said:
Is there a reason to use the ‘376 over the ‘375?
Click to expand...
For me, the system I'm working with has the 376 designed in-- it has a socket for one of those $6 CH376S-on-a-breakout-board modules, Therefore, all the prior work from here is based on that.

I figured if we can get to a shared code base that makes both 375 and 376 work, then development efforts can be combined.
 
Chuck(G) said:
Practically speaking, there are any number of 32-bit MCUs that support USB OTG, with far more flexible GPIO than those wch chips. Host mode driver code is available.

But don't let that stop you...
Click to expand...
Of course, anyway, these chip are simple to solder, easy to do simple boards, easy to program.

I want to work on an ISA Pi, even with a Pi Nano, we can do much more, but need to program the Pi nano as well.
 
@Hak Foo - based on what I can see on eBay, the pin out of the CH375 boards looks to be the same which might at least make testing both a snap!
 
There are at least two, and possibly three pinouts of the CH376 modules. I'm looking at a CH375 module that might be the right pinout and will order it, but it could still be wrong when it shows up.
 
You must log in or register to reply here.
Back
Top