@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