• Please review our updated Terms and Rules here

ISA USB board

Maybe it would be better to use an expansion slot USB port and have internal header motherboard type pin headers on the card itself.
 
Maybe it would be better to use an expansion slot USB port and have internal header motherboard type pin headers on the card itself.
And use up an expansion slot, Not realy a good idea, A panel mount USB cable with internal header can be used ( I fitted one to my 5160 test system ) but this requires drilling a panel which everyone is not willing to do, I'm sure something can be done to secure the card in place, I've been using my ISA-USB card for years now and had to replace the USB port on the card once, The problems i had with the USB port resulted from multiple insertion / removal of flash drives and the weight of the flash drive hanging off the USB port, Using the USB extension cable has alleviated these problems and it means i can get at the Flash drive from the front and not the rear of the computer which is also a bonus.
 
Primarily a cosmetic update today.

I had grand visions of "hey, I can finally fix where at some point around v0.8 a couple of specific cheapo flash drives stopped detecting" but they seem to work again. So I restructured the power-on messaging to be more compact and, fairly blatantly, follow the style of GlaBIOS. Now it looks like it was built in.
 
Okay, a more interesting experiment in user-friendliness:


Built as a separate branch because it's a bit of a high-risk offering.

At initialization, instead of having one or two drive ports hard-coded, it scans a list of them in the ROM and detects until it finds (at most) two drives. It currently looks on E0/E4 (where the Homebrew8088 boards load one), 260/262 (mostly so I had a known failure in between good detections to test that use case), 270/272 (where my AliExpress board that's been wired to support double-wide addressing lives), and 360/362 (so we could confirm that once we get to two good drives, we stop searching). This is sort of filler data until I can review the discussion and different cards boards and prepare a better list

This is nice, if (for example), you have one drive mounted internally, always there, and another with a drive that you remove sometimes and it shouldn't pretend there are always two drives, or so you don't have to burn a new ROM for every possible card. More practically, it means one or two ROMs (8-bit wide/16-bit wide) would support almost everyone out of the box, rather than having to reassemble for different port numbers only.

You still need to decide if you want 8- or 16-bit mode, and the real sin, however, is that we have to buy some RAM space to store the list of ports that actually contained CH37x units.

I chose to use some space in the BIOS data area 40:C0 through 40:C7 which is described as part of a 16-byte "NMI Scan Code Buffer (Convertible)" in https://stanislavs.org/helppc/bios_data_area.html . Hopefully this means that as long as we're not on a PC Convertible, we're safe. Most of the real Convertibles seem to have been attacked by the Keyboard People already. :mad:

It could be done as a "steal 1kb of conventional RAM" but that seems an awful big cost to store 8 bytes of data.

The usual "this may catch fire and break everything, I take no liabilities and explicitly disclaim any warranty" disclaimer applies.

Note that this may also initialize a bit differently; so I didn't have to spend forever waiting for initialization to spin on the ports that don't have CH37x units, it a check-for-life that was normally done 200x only 2x. Still seems to work for real hardware, but maybe it should be a tunable later.

Note this also adds a bit to the ROM size, to where it's about 4115 bytes before packing. It should be possible to golf it down below 4095 again, but the default build has been allocating 6kb for quite a while.

Potential extensions would involve storing info for more than two CH37x units, which might involve changes to the logic that decides "is this a drive we service, or do we pass it back to the floppy controller INT13 handler" and "calculating the number of drives for INT13 function 8" stealing more RAM somewhere (4 bytes per device).
 
Works for me :) I used the canned image "ch37x-bios.bin", No problems in detecting my flash drive and booting DOS, Excellent!
 
Updated the auto-detect version: Trimmed some messages to drop down below 4096 bytes again (double-wide mode-- the unrolled loops in 8086 mode mean single-wide exceeds 4k), and changed the ports we scan for a CH375/6. It should look for E4/E0, 262/260, and 2C2/2C0 in 16-bit mode, and E4/E0, 261/260 and 2C1/2C0 for 8-bit wide mode. These are all the known locations for a CH375/6 I could find. Obviously it's trivial to change if we find more, and you may want to build it to put the ports you use first.

The big risk is just the 8 bytes we're using in the BDA. If something else decides "Hey, I'm not a PC Convertible and can clobber this buffer too", or just "I'm gonna buffer overflow and puke on the BDA", we'll be shouting at devices that don't exist and disc access will blow up. I wish we all had upper RAM available so we could just cleave off EFFF:0 to EFFF:7 or something.

Lowering conventional RAM by 1k to store the details is a chicken-egg problem actually. With the shadowing option, we're at least storing the segment we chose as part of the interrupt vector, but with just "drop RAM 1k before boot and store info here", we don't know after boot if we're the only device that did this. I know some BIOSes themselves would only offer 639k RAM because they stole 1k, but after boot we don't know if we came first and 639k contains our parameters, or the BIOS came first and it contains BIOS scratch data.
 
Last edited:
Updated the auto-detect version: Trimmed some messages to drop down below 4096 bytes again (double-wide mode-- the unrolled loops in 8086 mode mean single-wide exceeds 4k), and changed the ports we scan for a CH375/6. It should look for E4/E0, 262/260, and 2C2/2C0 in 16-bit mode, and E4/E0, 261/260 and 2C1/2C0 for 8-bit wide mode. These are all the known locations for a CH375/6 I could find. Obviously it's trivial to change if we find more, and you may want to build it to put the ports you use first.
Perfect, Not sure ports 2C2/2C0 - 2C1/2C0 are required though, 2C0 stomps on some RTC's, and it was a booboo with the lo-tech experimental boards, I modified mine to use 260h and don't know of anyone else who has a working lo-tech board!. Easy enough to modify / build the BIOS as you say.
 
WRT to 2C0, I removed it from the latest version. As much as anything, its value was to let me easily generate a failure-to-detect for debugging purposes.

WRT to 260, I don't have one to say. I feel like in that situation, the EMS board has to give because its ports can be reassigned without soldering, while the CH375 card can't.

I think the CH375 board only responds on 2 (or if modified) 4 ports, but I can't be 100% sure there aren't other "incomplete decode" matches that would conflict with the Lo-tech card.

Worst case, it's trivial to reassemble it with a preferred ports list. The goal was just more "batteries included" operation for more use cases, and to give myself a project for the long weekend. :)

The auto-detect mode is now merged into the main version, but there's a tag labelled 0.96 for the code before that, in case someone has a situation where the use of BDA memory does cause problems and need to use a hard-code model.
 
The auto-detect mode is now merged into the main version, but there's a tag labelled 0.96 for the code before that, in case someone has a situation where the use of BDA memory does cause problems and need to use a hard-code model.
The auto-detect mode is an excellent addition, It works!, Please keep up the excellent work :)

I just wish there was more of a choice in acquiring these ISA - USB boards other than the Chinese offerings.
 
Yeah, the commercial card sort of sucks. The fitment is bad-- the port sticks wildly out of the back of the case-- and it's inflexible in configuration.

I know there were a few designs for other cards being mocked up earlier in the thread, but I don't know if any of them ever made it to actual PCB.

The chip comes on a little breakout module for like 5 bucks. That's where I got into it-- the homebrew8088.com motherboard designs just socket one of these modules to the board, and use a few gates to interface it. The designer behind those boards showed a picture of a CH376 ISA card on his Discord recently, but no further details.

I was actually a little disappointed with the Book8088 fiasco that they sold a product with an 8088 and a CH375 in it, yet forgot to appropriate this BIOS too. :D
 
Lo-Tech had a revision 2 in the works at one time but never went to completion for some reason, FreddyV had a design that went to PCB that never got built / tested afaik, I have a couple of those modules CH375 and CH376 i bought years ago, Back then it was cheaper to buy the module than to buy the chips on their own.

I did wonder about the Book8088 laptop thing when i read about it, Though i noticed in one of the photo's it had a USB driver dated 2020.
 
The chip comes on a little breakout module for like 5 bucks. That's where I got into it-- the homebrew8088.com motherboard designs just socket one of these modules to the board, and use a few gates to interface it.

On a whim I recently bought a couple of those little breakouts, intending to maybe try interfacing one to a TRS-80 for laughs, but now you've got me wondering if I can tack one of these onto my homebrew Tandy 1000 EX/HX expansion board. (I think I might be able to scrape up an output on the I/O decode GAL to enable it with.) It already has an XT-CF on it but the flash ROM size is more than enough to hold the BIOS for both that and this...

Edit: Is an IRQ necessary, or can this driver work with polling? The breakouts I bought have CH375s, not CH376s on them if that makes any difference.
 
Last edited:
The Board I designed is this one, I made it to connect to the small board available from internet.
But unfortunately, it support only one pinout and there are 2 around.
I ordered 5 PCB and did not test them as I moved to the PicoMEM project that is 1000% better :)

ISA_USB.png
 
There's a change to the package today, but most people won't need it.

Since I retooled my memory card to expose a full 128k of ROM, I've been looking for something to do with the extra space. So I made a skeletonized version of this BIOS that will access a disc image from memory, and supplants the floppy drive, providing a rudimentary "boot from ROM" functionality.

With all the "real" features cut out, it's <1k (edit: but if it's not padded to 2K, it seems to trigger weird behaviour with loading the ROM), and I was able to boot the 63k image from http://boginjr.com/it/sw/dev/bootlpt-86/

It's now set up as an INT 18 replacement-- that should allow most BIOSes to give up and boot it when they run out of bootable drives, and the XUB lets you skip straight there with the ROM Boot menu option.

This just hijacks INT13 functionality for drive A, stashing the old handler and passing it off for other drives. I could imagine having a recovery toolkit (FDISK/FORMAT/SYS/DEBUG) if you have a big enough image to work with. Of course, that turns into a "how much UMB space am I willing to give up for this gimmick." question.
 
Last edited:
I was trying to debug a problem report on Gitlab, and discovered at least some BIOSes don't leave DS=CS when launching an option ROM. The Xi8088 BIOS, for example, does this; this was causing display corruption-- we went to print a message and found nonsense. Now we explicitly set this precondition at launch.

Other BIOSes seem to contaminate register AH after running INT 10h function 0x0E to print a character, so you couldn't just do "print another character and assume AH was still 0x0E". I've attempted to ameliorate this-- hopefully there should be less display corruption.
 
Back
Top