@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 2026-09-10, 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 2026-09-10, 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.

Just reading through this thread .. sorry if this is a bit "behind".

Back in the day (prob 15+ years ago) when I was setting up the ImageDisk bootable floppy (for people who need IMD but don't have a system running DOS),
as part of the methods to get files on/off the "transient" system, I found and included some basic USB mass-storage support files/drivers for DOS.

You can get the ImageDisk bootable floppy image from "Daves Old Computers" - I have no idea how applicable ths might be to more modern systems!

dylanfm wrote on 2026-09-10, 11:01:

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.

I have checked and yes there are some warnings in the main driver due to some code I used to print 32-bit integers like the sector number, but nothing major, you can even comment that part out and nothing should break.
But the test program (test.c, test.exe) builds as is with -0, no changes required. You should be able to try it (after changing ch375_port to whatever you have). I just tried with openwatcom 2.x latest.

dylanfm wrote on 2026-09-10, 11:01:

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.

If you want a bit more unsolicited advice, I think you are starting in the wrong direction, i.e. your goal should be to figure out the ch376, rather than the driver part. If you figure out what's diferent about the ch376 (and maybe it's just nothing!), then patching the orig driver should be trivial.
I.e. focus on the ch375/6 parts, not on the MS-DOS parts (unless, of course, your goal is to learn to write MS-DOS drivers in the first place, in which case: enjoy).

javispedro1 wrote on 2026-09-11, 19:01:

If you want a bit more unsolicited advice, I think you are starting in the wrong direction, i.e. your goal should be to figure out the ch376, rather than the driver part. If you figure out what's diferent about the ch376 (and maybe it's just nothing!), then patching the orig driver should be trivial.
I.e. focus on the ch375/6 parts, not on the MS-DOS parts (unless, of course, your goal is to learn to write MS-DOS drivers in the first place, in which case: enjoy).

I'm not saying you are wrong, but ultimately I feel that I will need to be able to write a driver in order to use the CH376. While I don't remember the differences now, from when I was looking at it before I believe that there are differences. Even if there were no differences, the CH375 driver at least checks the chip version, so the driver would need to be modified to take that out. Without the source, I don't think I can figure out how to get around that.

When I was looking at this before, I had asked AI to help me write a driver for the CH376 and it explained the differences between the CH375 and CH376 and spit out a new driver. That driver didn't work, it would just lock up my computer when it tried to load, so then it led me down a path of trying to make a dummy driver that didn't do anything. But the dummy code the AI suggested didn't work either, and all the fixes it came up with either wouldn't compile or still locked up my computer. I will have to go back a look at what I have exactly, but I have a bunch of info on the CH375 and CH376 from the manufacturer and kind of feel that some where I have snippets of assembly code for them. There is also that open source bios that has code for the CH376. I just don't know how to turn that into a driver.

Actually, looking back at what I have downloaded, I have folder called "CH376_ISA_CARD-ch376-driver-development" that seems to have source code and instructions for building a CH376Dos driver with Turbo C 2.0 that I don't remember ever trying out or even really looking at. I think I will see if that builds. Maybe this is a solved problem already.

EDIT: Nevermind, this "CH376_ISA_CARD-ch376-driver-development" folder was just the non-working AI generated code. I had forgot all the files it had generated (code for a test program in C, a build.bat file, a readme file etc) and it didn't have comments on the files that I was expecting so I didn't recognize it.

dylanfm wrote on 2026-09-16, 08:10:

I'm not saying you are wrong, but ultimately I feel that I will need to be able to write a driver in order to use the CH376. While I don't remember the differences now, from when I was looking at it before I believe that there are differences. Even if there were no differences, the CH375 driver at least checks the chip version, so the driver would need to be modified to take that out. Without the source, I don't think I can figure out how to get around that.

Well if it's just removing a version check it should be trivial, source or not 😀
I took a quick look over the datasheets. For sure the CH376 has more features than the CH375. Interestingly it has a mode that actually parses the filesystem by itself, so that would map nicely to a redirector interface (like what Freddy commented). However the manual also seems to hint that it is a superset of the CH375, so I suppose it is likely that all the CH375 commands are still there, even if not explicitly mentioned by the datasheet?
In the same way that all CH372 commands are available in the CH375...
Note also redirector drivers ("file based") are completely different from "block" disk drivers as in the CH375. You'd want to read "Undocumented DOS" for a redirector driver.

Re my CH375 driver -- I made optional the parts requiring a 386, and rebuilt for the 8086 (replace all -3 in makefile with -0). See attached for binary. It does not check for chip version at all, just prints it.
Albeit unless you can use the serial port debugging it will simply crash if the command set is really different on the CH376. The first command it will throw that's not on the CH376 datasheet is DISK_INIT...

I have also given it a homepage -- https://git.javispedro.com/cgit/chu.git/about/ . I spent some time with it until I got 6.22 format.com to "work" 😀
Someone may find the multiple partition support interesting, as a way to workaround the FAT16 size limits. (Albeit arguably the CH376 and a redirector driver would be a better approach).