Sphere478 wrote on 2026-10-08, 18:30:

I have one, it’s packed away. One of the generic ones for giving dos a thumb drive I may have posted specifics earlier in the th […]
Show full quote

I have one, it’s packed away. One of the generic ones for giving dos a thumb drive I may have posted specifics earlier in the thread but I sont recall.. Currently I’m using it as a 5v power source on a different 95c rig though 🤣.

I could probably buy whatever card is working the best, what one would that be?

I’d like to use usb sticks in windows 95. That’s probably the biggest need.

Past that, a usb hub and mouse functionality.

Keyboard could easily just stay on the Din/ps/2

There are 3 general categories of USB to ISA devices that I can think of off the top of my head--

1) 8 bit Industrial DOS boards

• CH375 cards like this https://theretroweb.com/expansioncards/s/wch-isa_rom3-1009 that have DOS drivers for USB mass storage but don't support hotswap. Use the FreddyV driver for transfers of about 1MB/s
• CH376 cards have started to show up and people are working on making enhanced drivers available for them

2) Pico boards

• PicoMEM - mouse joystick and USB mass storage support via microusb with some asterisks, caveats and exceptions
• PicoMEM2 - mouse joystick and USB mass storage support via microusb and usb-A with some asterisks, caveats and exceptions
• PicoGUS - mouse support or Panasonic CD-ROM emulation using bin/que files

3) IDE emulators that present USB drives as an ATA drive, although they are a little hard to find these days and have been out of production for a long time. Still not hot swap. I'll post a picture of one if you want to see what they looked like. Listing it here because IDE is pretty much a subset of ISA in some ways.

Did I miss anything?

jdredd wrote on 2026-10-08, 18:46:

Probably pointless and useless to you.. as I did this for ME an my old DOS systems I am messing with ( IBM PS2 with an NEC V30 C […]
Show full quote

Probably pointless and useless to you.. as I did this for ME an my old DOS systems I am messing with ( IBM PS2 with an NEC V30 CPU )...

Can use the CH375 for other things if put the effort in. USB>Serial, USB>Webcam, USB>Ethernet, blah....

https://github.com/jdredd87/CH375USBTools

So if limited on space/resources/ect, could use the CH375 to work with other things besides storage.

But may give others ideas....

That looks like a lot of cool stuff! I'm going to look into it more.

For reference, this is my ISA CH37x card that I have designed and have been using, in case it is useful for anybody else:
https://github.com/dfmcwhir/ISA_CH37X_XTIDE_DoC_combo_card

dylanfm wrote on 2026-10-08, 22:36:

That looks like a lot of cool stuff! I'm going to look into it more. […]
Show full quote

jdredd wrote on 2026-10-08, 18:46:

Probably pointless and useless to you.. as I did this for ME an my old DOS systems I am messing with ( IBM PS2 with an NEC V30 C […]
Show full quote

Probably pointless and useless to you.. as I did this for ME an my old DOS systems I am messing with ( IBM PS2 with an NEC V30 CPU )...

Can use the CH375 for other things if put the effort in. USB>Serial, USB>Webcam, USB>Ethernet, blah....

https://github.com/jdredd87/CH375USBTools

So if limited on space/resources/ect, could use the CH375 to work with other things besides storage.

But may give others ideas....

That looks like a lot of cool stuff! I'm going to look into it more.

For reference, this is my ISA CH37x card that I have designed and have been using, in case it is useful for anybody else:
https://github.com/dfmcwhir/ISA_CH37X_XTIDE_DoC_combo_card

Yah it is pretty neat I think. I picked up a P3 450mhz box yesterday. So I can run 3.11 / 95 / 98 / XP on.... And an attempt here soon to get Windows examples of everything maybe working.
My fav really was the ethernet adapter.. i bought a few to try out to get a few chipsets working... Then what was neat, was the USB>DisplayLink , having a working ( but slow ) 2nd display of sorts.

Mostly just demos and proof of concepts for some things, like the webcam, but its nice to know can use the CH375 for other things than just keyboard/mouse/storage.

I do want to pick up a CH376 to try out...

I do have a new driver too for DOS storage too @ https://github.com/jdredd87/CH375
Idea on this was over FreddyV's was all in one driver and any improved abilities I could get squeaked out.
As far as I know 8086 and 486 have been tested. Nothing in the middle yet?
Slower the machine ( 8086 NEC v30 in my case ) the better the results. As it has V20/V30 optimizations.

Now that I have a 486 and P3 system to work with i'd like to see what more can be done.

And with the sources I posted maybe give others a starting point to work with and create their own wacky things.

Here it is from earlier in thread

dylanfm wrote on 2026-10-01, 05:32:

Attached are the datasheets for the CH376 and CH375 chips. There are definitely some differences in the commands (the commands for RD_USB_DATA and WR_USB_DATA are different, the SET_DISK_LUN input data is different, etc). Which differences matter I don't know.

But the data0 and data commands are the same except for something about locking which I think is irrelevant for disk mode, and the SET_DISK_LUN command is not actually called by anyone (seems to be missing from the datasheet, but I think it's still there anyway).

In fact, since I still have the suspicion that the CH376 is a strict superset of the CH375...
I was able to get your AI's ch376usb.sys to work on my ch375 just by commenting the parts that are definitely new to the ch376:
- The "busy" bit in the status word (not sure why it should be used in ISA/parallel mode? this seems to be for SPI access which ch375 doesn't have. and we also wait for the interrupt anyway).
- The "disk_connect" and "disk_mount" which are the new commands for file based access, which do not exist in the ch375. But this driver does not actually use file-based access, so it could also use the old command "disk_init" (in fact the AI has generated calls to disk_init too, no idea why, but it just fallbacks to it ).

This kind of confirms my suspicion ... ch375 commands work in ch376, ch376 is a superset of ch375.
The new features in ch376 are related to file-based access (file read, file write, etc.) instead of sector-based, but these are not used at all by a DOS block driver, only a network redirector or something else could benefit from those (and thus be able to e.g. read FAT32 partitions on non-FAT32 DOS).

Attached minimal patch for ch376dos.asm which made it work on my ch375. I am rather curious if the driver still works on your CH376 after you apply this patch.

I see that Aliexpress is selling variants of this card with 2 USB ports and an included EEPROM chip (presumably containing some BIOS). Does anyone have experience with these?

feipoa wrote on 2026-10-12, 21:51:

I see that Aliexpress is selling variants of this card with 2 USB ports and an included EEPROM chip (presumably containing some BIOS). Does anyone have experience with these?

Oh cool!

Wonder how long till we have a fully functional 4 port isa card

Muhahahah

“Laughs maniacally”

Whatcha think is on the eeprom? Xt-ide?

Edit:

Okay, so here’s what I found,

The rom is for stuff like “ HakFoo's standalone USB BIOS code”

And the extra port is not a data port, it’s a power input port for giving the primary port (and maybe the system also? Not that it amounts to much) more stable 5v power (it’s a power input port into the card)

javispedro1 wrote on 2026-10-11, 17:42:

But the data0 and data commands are the same except for something about locking which I think is irrelevant for disk mode, and t […]
Show full quote

But the data0 and data commands are the same except for something about locking which I think is irrelevant for disk mode, and the SET_DISK_LUN command is not actually called by anyone (seems to be missing from the datasheet, but I think it's still there anyway).

In fact, since I still have the suspicion that the CH376 is a strict superset of the CH375...
I was able to get your AI's ch376usb.sys to work on my ch375 just by commenting the parts that are definitely new to the ch376:
- The "busy" bit in the status word (not sure why it should be used in ISA/parallel mode? this seems to be for SPI access which ch375 doesn't have. and we also wait for the interrupt anyway).
- The "disk_connect" and "disk_mount" which are the new commands for file based access, which do not exist in the ch375. But this driver does not actually use file-based access, so it could also use the old command "disk_init" (in fact the AI has generated calls to disk_init too, no idea why, but it just fallbacks to it ).

This kind of confirms my suspicion ... ch375 commands work in ch376, ch376 is a superset of ch375.
The new features in ch376 are related to file-based access (file read, file write, etc.) instead of sector-based, but these are not used at all by a DOS block driver, only a network redirector or something else could benefit from those (and thus be able to e.g. read FAT32 partitions on non-FAT32 DOS).

Attached minimal patch for ch376dos.asm which made it work on my ch375. I am rather curious if the driver still works on your CH376 after you apply this patch.

I tested your patched driver and the computer just hung while booting. No text about loading the driver was put on the screen prior to hanging. I tested it with and without the CH376 card installed. I also re-tested the previous driver you had patched to make sure I didn't mess up testing of that one and it behaved the same as last time, no errors while loading, but would give me errors when I tried to access the drive "Not ready reading drive D, abort, retry, fail?". Before and after testing, I used my CH376DOS driver and confirmed that it was working

However, I also tested both of these patched drivers with my CH375 card installed and they behaved (failed) the same way as they did when I had the ch376 card installed. But then I also tried my CH375 card with the stock ch375 driver and it didn't work either although in a different way. With the stock CH375 driver and CH375 card, it just hangs up while trying to read the usb drive, either during boot after loading the driver or if I try to switch to that drive after boot, without any errors. This is the same CH375 card I have used in the past, so either something has gone wrong with the card's HW or it doesn't like the thumbdrives I am trying to use. I know I have used this same thumb drive with both the CH375 and CH376 cards in the past, but I have reformatted them in different ways multiple times trying different settings so maybe the current way the thumbdrive is formatted is incompatible the ch375 card? I don't know. I will have to troubleshoot that.

feipoa wrote on 2026-10-12, 21:51:

I see that Aliexpress is selling variants of this card with 2 USB ports and an included EEPROM chip (presumably containing some BIOS). Does anyone have experience with these?

I like the third variant much better, the one with a Disk-On-Chip on a adapter PCB connected to the ROM socket. The Disk-On-Chip comes preloaded with a DOS install complete with the ISA USB driver. It allows you to plug in the card, boot of the Disk-On-Chip and access the files on the USB stick in the top USB port. It is great for testing motherboards.

Note:
-The bottom USB port is power only.
-The Disk-On-Chip has only 7MB disk space available.
-The Disk-On-Chip will be your C:, the USB stick if present will be D:
-The read speed is about 450kBs.
-You need to create a AUTOEXEC.BAT on the Disk-On-Chip to stop it from asking for the date/time on every boot.

Dorunkāku wrote on 2026-10-13, 05:36:

I like the third variant much better, the one with a Disk-On-Chip on a adapter PCB connected to the ROM socket. The Disk-On-Chip […]
Show full quote

feipoa wrote on 2026-10-12, 21:51:

I see that Aliexpress is selling variants of this card with 2 USB ports and an included EEPROM chip (presumably containing some BIOS). Does anyone have experience with these?

I like the third variant much better, the one with a Disk-On-Chip on a adapter PCB connected to the ROM socket. The Disk-On-Chip comes preloaded with a DOS install complete with the ISA USB driver. It allows you to plug in the card, boot of the Disk-On-Chip and access the files on the USB stick in the top USB port. It is great for testing motherboards.

Note:
-The bottom USB port is power only.
-The Disk-On-Chip has only 7MB disk space available.
-The Disk-On-Chip will be your C:, the USB stick if present will be D:
-The read speed is about 450kBs.
-You need to create a AUTOEXEC.BAT on the Disk-On-Chip to stop it from asking for the date/time on every boot.

The included DiskOnChip may be socketed and replaced with a bigger size chip (there are variants up to 1 GB, I think) and this could replace the need of CompactFlash to IDE adapter and the CF card.

Do you know what is the purpose of the three jumpers (including the unpopulated one near the CH375B chip)?

The Disk-On-Chip is indeed socketed. It is a M-Systems MD-2800-D08.
The jumper on the left of the card selects between 0x280 and 0x2c0. I don't know what the other ones do.

Dorunkāku wrote on 2026-10-13, 09:10:

The Disk-On-Chip is indeed socketed. It is a M-Systems MD-2800-D08.

You're right. I overlooked this and it spares the socket modification.

Dorunkāku wrote on 2026-10-13, 09:10:

The jumper on the left of the card selects between 0x280 and 0x2c0. I don't know what the other ones do.

If there is a chinese manual in DOC drive included, we could use a random online translator.

You don't need rare Disk on chip for this. I made a slight modification of common CH375 card to be able to jumper also 64kB EPROM. It's enough to boot my ROMOS with bare Freedos, tiny command.com and the driver so it can bootstrap a computer without driver installled.

dylanfm wrote on 2026-10-13, 01:23:

I tested your patched driver and the computer just hung while booting.

So if if happens there most likely the change that affects that is the "busy" bit change.
Hum. I find it unlikely that we need to poll for the busy bit after each ISA write (I guess they would have documented it if it was the case).
But maybe what goes on is that the mere fact of polling for the bit is a adding a couple more reads in the bus, thereby acting as extra wait states after a write ?
This may also explain why my driver may not work -- I have no extra wait states whatsoever; never had a problem with those here, but then again I don't have any pre-386 hw to play with.

dylanfm wrote on 2026-10-13, 01:23:

ith the stock CH375 driver and CH375 card, it just hangs up while trying to read the usb drive, either during boot after loading the driver or if I try to switch to that drive after boot, without any errors. This is the same CH375 card I have used in the past, so either something has gone wrong with the card's HW or it doesn't like the thumbdrives I am trying to use. I know I have used this same thumb drive with both the CH375 and CH376 cards in the past, but I have reformatted them in different ways multiple times trying different settings so maybe the current way the thumbdrive is formatted is incompatible the ch375 card? I don't know. I will have to troubleshoot that.

Heh. The reason I started my C driver years ago is because the original one is very picky about the partitioning layout (in fact I can do nice things such as multiple partitions, extended ones, LBA, etc). I have the impression all the AI 'derivatives' have the same code as the original driver, at least for partition table parsing.

RayeR wrote on 2026-10-13, 12:12:

You don't need rare Disk on chip for this. I made a slight modification of common CH375 card to be able to jumper also 64kB EPROM. It's enough to boot my ROMOS with bare Freedos, tiny command.com and the driver so it can bootstrap a computer without driver installled.

I agree, but my point here is to not use (E)EPROMs and things like XT-IDE BIOS or other chip-based boot things plus HDD or CFtoIDE adapter with CF card. These DOC chips are not so rare. Sometimes I see different sizes for sale on ali-baba-and-his-40-thieves 😀 And they're not so expensive.

Here's one interesting possible option for laptops: there is a RATOC CompactFlash to USB Host card which was intended to be used in Windows CE palmtops but it can be used in PCMCIA slots with a passive adapter. There is now a Win9x driver for it (AI made) see here: https://github.com/zikolas/cfu1-win9x

javispedro1 wrote on 2026-10-13, 14:30:

So if if happens there most likely the change that affects that is the "busy" bit change. Hum. I find it unlikely that we need […]
Show full quote

So if if happens there most likely the change that affects that is the "busy" bit change.
Hum. I find it unlikely that we need to poll for the busy bit after each ISA write (I guess they would have documented it if it was the case).
But maybe what goes on is that the mere fact of polling for the bit is a adding a couple more reads in the bus, thereby acting as extra wait states after a write ?
This may also explain why my driver may not work -- I have no extra wait states whatsoever; never had a problem with those here, but then again I don't have any pre-386 hw to play with.

So, if I remember right, when I had AI create the CH376 driver, initially it was polling bit 7 which should indicate the interrupt state. But that didn't work for some reason and then it switched to monitoring the busy bit instead. Even after that switch there were other problems getting it to work. I could be mis-remembering.

With your driver, do you only use the base address and the base address + 1? My card, which is copied from the reference design can read the interrupt pin of the CH375 on the base address + 2, but I don't know if the stock CH375 driver actually does that or if it uses something similar as what my CH376 driver does.

javispedro1 wrote on 2026-10-13, 14:30:

Heh. The reason I started my C driver years ago is because the original one is very picky about the partitioning layout (in fact I can do nice things such as multiple partitions, extended ones, LBA, etc). I have the impression all the AI 'derivatives' have the same code as the original driver, at least for partition table parsing.

The thing is, I have used the stock driver with the CH375 card a lot without issue so it is kind of frustrating that I can't get it to work now. I have tried formatting the usb drive a number of different ways with no luck. I don't actually remember how the thumb drive was formatted when it was working before, I think I just had a random thumbdrive that I plugged in and it worked, so I kept using it. I kind of wonder if I accidentally switched which CH375 driver I was using. I have another computer with a ch375 card installed that I haven't touched so I should boot that one up and see if I can get that one working to narrow down if it is a USB drive or CH375 card/driver issue.

Btw if CH37x is used in raw mode when it just R/W LBA sectors it should be totally irrlevant how it's partitioned or what filesystem is formatted as it should be handled by DOS above the driver...

dylanfm wrote on 2026-10-14, 06:03:

So, if I remember right, when I had AI create the CH376 driver, initially it was polling bit 7 which should indicate the interrupt state. But that didn't work for some reason and then it switched to monitoring the busy bit instead. Even after that switch there were other problems getting it to work. I could be mis-remembering.

But see the ch_int_pending function: it is still polling bit 7 anyway, so it's actually monitoring both things, waiting until bit 4 falls after each ISA write, then waiting until bit 7 rises after each command.
I'd like to avoid adding wait states if possible; the driver is already slow enough as it is. I have to admit though I have no idea why this would require more wait states on a 8086 than a 386, but it's the most likely scenario I guess.

dylanfm wrote on 2026-10-14, 06:03:

With your driver, do you only use the base address and the base address + 1? My card, which is copied from the reference design can read the interrupt pin of the CH375 on the base address + 2, but I don't know if the stock CH375 driver actually does that or if it uses something similar as what my CH376 driver does.

Yes, only 0 and 1, no alias. I can read the interrupt bit on base+1. base+2 is not wired on pocket386, so the drivers are not assuming this otherwise they'd not work.

RayeR wrote on 2026-10-14, 08:22:

Btw if CH37x is used in raw mode when it just R/W LBA sectors it should be totally irrlevant how it's partitioned or what filesystem is formatted as it should be handled by DOS above the driver...

No, DOS doesn't handle partitions except for fixed disks visible at the int13h level.
For a .sys "block" disk driver, DOS expects to see "logical units" only (a.k.a. drive letters), so the driver is supposed to handle partitions.
If instead of using a block device you'd use a ROM BIOS extension (providing int13 services) then DOS would enumerate the partitions on boot, assigning drive letters depending on how many partitions were found during boot only.
So it's a tradeoff: you can use a int13 ROM BIOS, then DOS does partition parsing for you, FDISK works, etc. , but then treats it as a fixed disk rather than removable, and you are subject to the annoying BIOS int13 CHS interface and limits (1024 cylinders / ~8GB).
Or, you can use a .sys block driver like the ones here, then DOS gives you an arbitrary number of drive letters at boot time, allows hot swapping, and uses "clean" LBA-based access (2TB limit) ... but then driver is supposed to handle partition tables and map them to the (fixed number of) drive letters. FDISK also won't work (but partition-specific things like FORMAT may work).
(You are still subject to the DOS FS limits -- i.e. each FAT16 part no larger than 2GB -- since DOS is still parsing FAT. But the partition itself can be way past the 8GB limit).

What I was doing in my driver is a trade-off. I request one drive letter from DOS, but then the user can decide which partition from the USB drive is to be mapped to that drive letter, and change it from the command line.
Note also that if you play with DOS internals you could do whatever you want, such as removing/adding drive letters at hotplug.

Ok, but within a partition is it still sector-based access? Then dos should parse dos boot record of selected partition and handle FS if it understand it - msdos 7.x and freedos can handle fat32...
so driver would not need to know FS it can just look up for active flag partition or just use the first partition it finds in partition table and read the start lba of that prtition... yes it could also validate if partition table contains known FS to dos but not technically not needed. Only in case that flashdisk would contain multiple partitions and some would be unknown to dos it could skip them...