@FreddyV: Would it be possible to allow your modified driver to work on a CH376S also (not expecting any work, just wondering if it might simply work with this chip version, too)?

Background being: I've built such a card and dropped in that chip version, instead of the CH375B. It's able to boot from it via the BIOS, but trying the driver, refuses it:

MJay99 wrote on 2025-10-03, 18:20:

@FreddyV: Would it be possible to allow your modified driver to work on a CH376S also (not expecting any work, just wondering if it might simply work with this chip version, too)?

Background being: I've built such a card and dropped in that chip version, instead of the CH375B. It's able to boot from it via the BIOS, but trying the driver, refuses it:

The attachment ch376S.jpeg is no longer available

Hi,

I don't know 🙁

In theory, CH376 can also be used via a network redirector driver, to access the file system directly.

Unless the source is available somewhere, in which case I would of course try it myself:
And If your setup is still available: Could you maybe compile a version with this chip version check simply commented out? I'd really like to swap the ch376 back in and see if it might simply work.☺️

FreddyV wrote on 2026-07-04, 19:48:

Hi, […]
Show full quote

MJay99 wrote on 2025-10-03, 18:20:

@FreddyV: Would it be possible to allow your modified driver to work on a CH376S also (not expecting any work, just wondering if it might simply work with this chip version, too)?

Background being: I've built such a card and dropped in that chip version, instead of the CH375B. It's able to boot from it via the BIOS, but trying the driver, refuses it:

The attachment ch376S.jpeg is no longer available

Hi,

I don't know 🙁

In theory, CH376 can also be used via a network redirector driver, to access the file system directly.

I would be very interested in a version of the driver that supports the CH376s or the source code for your driver so I can attempt to adapt it if you are willing to share. I also made a card that can use either the CH375B chip or a CH376 module. The CH375 version is working, and I have tried to stumble my way through making a driver for the CH376 version, but it is way beyond my skill set.

Dylan

Hi,
Source is not published as I use the original one decompiled 🙁

Back when I was investigating the Pocket386 I was curious about the CH375 so I started writing a replacement DOS driver in Watcom C.
I wanted to see why it was failing to support USB floppy drives, etc. in case it was driver issue rather than fw.
Turns out, the issue is in fw , so the experiment was a bit useless.
A C driver is also going to be much worse in performance, plus totally untested (not sure if it loads in a 8086 even, binaries are for 386!), so I'm not sure how useful this is to you.
But hey, the source is there at least, to play with =) (openwatcom2 required)

I didn't use anything from the original driver or SDK, only the datasheets, so everything is trial-and-error.
I got it to work up to the point it can init/read/write plus a couple experimental features, such as supporting multiple partitions (by allocating multiple drive letters on boot) and FAT32 when used on FreeDOS.

Heeavily untested, other than 1 Linux-formatted pendrive in a pocket386 running FreeDOS 😀 (a pendrive that the original driver would not read, for some reason. that's something, I guess.).
Now that I got the Book386 I am thinking of continuing, another reason I was doing it in C is to use to create drivers for other OSes.

javispedro1 wrote on 2026-09-08, 22:58:

Back when I was investigating the Pocket386 I was curious about the CH375 so I started writing a replacement DOS driver in Watco […]
Show full quote

Back when I was investigating the Pocket386 I was curious about the CH375 so I started writing a replacement DOS driver in Watcom C.
I wanted to see why it was failing to support USB floppy drives, etc. in case it was driver issue rather than fw.
Turns out, the issue is in fw , so the experiment was a bit useless.
A C driver is also going to be much worse in performance, plus totally untested (not sure if it loads in a 8086 even, binaries are for 386!), so I'm not sure how useful this is to you.
But hey, the source is there at least, to play with =) (openwatcom2 required)

I didn't use anything from the original driver or SDK, only the datasheets, so everything is trial-and-error.
I got it to work up to the point it can init/read/write plus a couple experimental features, such as supporting multiple partitions (by allocating multiple drive letters on boot) and FAT32 when used on FreeDOS.

To load

DEVICE=...\CHUDISK.SYS /N4 /P260 /R /3
(settings are just an example)
/N is the number of drive letters to allocate -- each letter will be mapped to one PRIMARY partition, so no point with N>4 right now.
/P is the IO base (260 is the pocket386's)
/R means read-only (to avoid surprises as driver was just an experiment)
/3 is to include FAT32 partitions when enumerating partitions

Heeavily untested, other than 1 Linux-formatted pendrive in a pocket386 running FreeDOS 😀 (a pendrive that the original driver would not read, for some reason. that's something, I guess.).
Now that I got the Book386 I am thinking of continuing, another reason I was doing it in C is to use to create drivers for other OSes.

Cool, I will take a look at it. I was trying to make a CH376 driver in assembly (using a lot of help from AI because I'm not a good coder), but I couldn't even get a dummy driver that didn't do anything to load without locking up the computer and AI just kept leading me in circles for fixes. Never did figure out if it was a tool chain problem or a bad code problem and finding info about making a dos driver is a little difficult and the info I did find often wouldn't work with whatever assembler I was trying to use. I recently saw a dos driver template for openwatacom C and thought maybe I would have better luck with that. Maybe I will have better luck with that.

dylanfm wrote on Today, 01:15:

javispedro1 wrote on 2026-09-08, 22:58:

Back when I was investigating the Pocket386 I was curious about the CH375 so I started writing a replacement DOS driver in Watco […]
Show full quote

Back when I was investigating the Pocket386 I was curious about the CH375 so I started writing a replacement DOS driver in Watcom C.
I wanted to see why it was failing to support USB floppy drives, etc. in case it was driver issue rather than fw.
Turns out, the issue is in fw , so the experiment was a bit useless.
A C driver is also going to be much worse in performance, plus totally untested (not sure if it loads in a 8086 even, binaries are for 386!), so I'm not sure how useful this is to you.
But hey, the source is there at least, to play with =) (openwatcom2 required)

I didn't use anything from the original driver or SDK, only the datasheets, so everything is trial-and-error.
I got it to work up to the point it can init/read/write plus a couple experimental features, such as supporting multiple partitions (by allocating multiple drive letters on boot) and FAT32 when used on FreeDOS.

To load

DEVICE=...\CHUDISK.SYS /N4 /P260 /R /3
(settings are just an example)
/N is the number of drive letters to allocate -- each letter will be mapped to one PRIMARY partition, so no point with N>4 right now.
/P is the IO base (260 is the pocket386's)
/R means read-only (to avoid surprises as driver was just an experiment)
/3 is to include FAT32 partitions when enumerating partitions

Heeavily untested, other than 1 Linux-formatted pendrive in a pocket386 running FreeDOS 😀 (a pendrive that the original driver would not read, for some reason. that's something, I guess.).
Now that I got the Book386 I am thinking of continuing, another reason I was doing it in C is to use to create drivers for other OSes.

Cool, I will take a look at it. I was trying to make a CH376 driver in assembly (using a lot of help from AI because I'm not a good coder), but I couldn't even get a dummy driver that didn't do anything to load without locking up the computer and AI just kept leading me in circles for fixes. Never did figure out if it was a tool chain problem or a bad code problem and finding info about making a dos driver is a little difficult and the info I did find often wouldn't work with whatever assembler I was trying to use. I recently saw a dos driver template for openwatacom C and thought maybe I would have better luck with that. Maybe I will have better luck with that.

Hobby(beginner) C++ programmer.
I found and combined two github projects. Cregfix ASM and dos driver template, maybe it will help: https://github.com/Raduq91/vcache-error-dos-driver-fix

Interestingly, the datasheet claims the CH376 should be a superset of the CH375. Have you found out why the CH376 is not able to work with the CH375 drivers, or are you trying to use some CH376 functionality?

You may have noticed In the above tarball there is also a test program (test.exe), I was using it during the trial-and-error phase. as it is not a driver and does not require reboots it was easier to work with. It also prints lots of debug messages.
invoke "test h" - call set_usb_mode, enables host mode
then "test d" - calls disk_init , tries to get disk size
then "test e" - call disk_read , tries to read sector 0 (so you can declare success if you see the 0x55AA signature of the MBR in the output 😀 ).
Hopefully that one is usable even in 8086 , but otherwise you may have to rebuild it without the -3 in the makefile (this enables 386 instructions).

Argh, I was hardcoding the ch375_port base in test.c to 0x260 , so you most likely need to rebuild indeed.

javispedro1 wrote on Today, 09:38:

Interestingly, the datasheet claims the CH376 should be a superset of the CH375. Have you found out why the CH376 is not able to […]
Show full quote

Interestingly, the datasheet claims the CH376 should be a superset of the CH375. Have you found out why the CH376 is not able to work with the CH375 drivers, or are you trying to use some CH376 functionality?

You may have noticed In the above tarball there is also a test program (test.exe), I was using it during the trial-and-error phase. as it is not a driver and does not require reboots it was easier to work with. It also prints lots of debug messages.
invoke "test h" - call set_usb_mode, enables host mode
then "test d" - calls disk_init , tries to get disk size
then "test e" - call disk_read , tries to read sector 0 (so you can declare success if you see the 0x55AA signature of the MBR in the output 😀 ).
Hopefully that one is usable even in 8086 , but otherwise you may have to rebuild it without the -3 in the makefile (this enables 386 instructions).

Argh, I was hardcoding the ch375_port base in test.c to 0x260 , so you most likely need to rebuild indeed.

I'm just getting back to looking at this again, but when I was looking at it before, I was under the impression that the CH376 has the same capabilities as the CH375 (plus more) but the commands to implement them are different. I'm not trying to do anything extra on the CH376. I will have to track that information down again.

I tried assembling your code, but got errors for i386 registers and instructions that weren't available on the x86 processor I had specified for the project. I fixed those errors (maybe incorrectly), but then got a bunch of different errors. I don't recall exactly what they were, I think they were for undefined labels or functions, but I assume it is something that isn't configured in my toolchain correctly.

So, I have started reading "Writing MS-DOS Device Drivers" (https://archive.org/details/writingmsdosdevi00lair_0) and I'm going to take another stab at learning how to do this in assembler.