• Please review our updated Terms and Rules here

ISA USB board

That's definitely progress though. It confirms the same detection code will work on the 375 and 376.

When I've had trouble, it can be useful to add the following shortly after the .START_INT13: label around line 489.
Code:
  .START_INT13:
  PUSH AX
  MOV AL, AH
  CALL WIRTE_AL_INT10_E
  POP AX

Yes, WIRTE is misspelled, and it's been that way since the original code.
Each time it makes its way into the INT13 handlers, it will write two digits for the INT13 function being called, which could be a hint to where things went wrong. It's possible your BIOS or OS is calling something that is not fully implemented here, or the actual read from/write to disc stuff is less compatible than originally imagined. (This assumes that the flow is still "normal" -- we're returning to the main BIOS after printing the CPU detection, and the BIOS starts making INT13 calls to begin the boot process.

In my experience, with PC-DOS 2000 and FreeDOS, even if the geometry is badly scrambled, it seems to usually get to the "load the first few sectors" phases of the boot process- enough to see the "Starting PC-DOS" or ".....123", before it blows up.

Are you running anything else disc-BIOSy at the same time? I was having some issues where it would freeze weirdly when I also had the XT-IDE Universal BIOS trying to boot (with no drives attached)-- I think it failed running INT13 function 0 (reset disc system) which just says "All good"
 
Practically speaking, there are any number of 32-bit MCUs that support USB OTG, with far more flexible GPIO than those wch chips. Host mode driver code is available.

But don't let that stop you...
The thing is, there's an inherent diminishing return here.

If I were working on a 286+, I'd just use an ordinary 16-bit IDE card and an IDE-SD adaptor and save a huge amount of hair pulling.

So you have a narrow niche. Basically XT-class machines. You also have a significant risk of host bottlenecking. It's likely that any well-optimized adapter-- XT-IDE, CH375/6, era-appropriate SCSI card, whatever-- is going to top out within 10 or 20 percent points of each other, unless you're doing DMA or other hardware tricks. So bringing in a super-flexible 32-bit MCU doesn't add much from that perspective.

On the other hand, more flexibility is likely to mean more complexity-- you'd either have to have more host-PC logic to initialize just the features you want, or a special firmware on the MCU to present a lightweight, limited interface. The CH375/6 give us a lot of that already by being narrow in scope. Rather than getting lost in "how do we handle when the drive is actually device 92 on a composite device behind six hubs?" minutae, we can simply say "it doesn't support it."

It's also cheap and packaged in hobbyist-friendly forms (through-hole solderable modules and ready-to-insert ISA cards, and I think some of the PCB-assembly shops include it in their catalog)
 
I have been using this for 8088 machines because I could just use usb sticks and it was cheaper than xtide (and didn't have to dig up cf cards)... redesigning a whole new board for me defeats the benefit (for me).. I did enough of that with the floppy board. :)
 
Are you running anything else disc-BIOSy at the same time? I was having some issues where it would freeze weirdly when I also had the XT-IDE Universal BIOS trying to boot (with no drives attached)-- I think it failed running INT13 function 0 (reset disc system) which just says "All good"
No, I'm using my 'Test' 5160 system, I pulled the XTIDE card, I've got a couple of things i want to try and i will add the code.
 
I have been using this for 8088 machines because I could just use usb sticks and it was cheaper than xtide (and didn't have to dig up cf cards)... redesigning a whole new board for me defeats the benefit (for me).. I did enough of that with the floppy board. :)
Yes i mainly want it for my 8088's, USB sticks are cheaper, Personally i have no interest in mouse / CD ROM support, Being able to boot from a USB stick would be great. I would like to have nicely fabbed boards at a reasonable cost though.
 
Yes i mainly want it for my 8088's, USB sticks are cheaper, Personally i have no interest in mouse / CD ROM support, Being able to boot from a USB stick would be great. I would like to have nicely fabbed boards at a reasonable cost though.
What's your idea of reasonable? I've been getting the ch375 boards for like $21.
 
What's your idea of reasonable? I've been getting the ch375 boards for like $21.
what i mean is a decent bare PCB for around $10 that i can build myself, Parts are cheap enough and they are easy to build. I wouldn't buy one of those Chinese things.
 
Do you need anything different to what the lo-tech board already does @Malc? I was already thinking of adding a second port, one internal, one external, and providing the option to use the eBay modules with it.
 
Do you need anything different to what the lo-tech board already does @Malc? I was already thinking of adding a second port, one internal, one external, and providing the option to use the eBay modules with it.
Like the schematics I shared to you ? :)

2 port will be more expensive, the only advantage I think about it is it may be more simple for the software part than having multiple key on a Hub.

I am working on the design below : Use a 3$ module, for a board we can probably build below $15
 

Attachments

  • 20220702_180248.jpg
    20220702_180248.jpg
    266 KB · Views: 19
Do you need anything different to what the lo-tech board already does @Malc? I was already thinking of adding a second port, one internal, one external, and providing the option to use the eBay modules with it.
An easily obtainable metal bracket is a must have, More power at the USB port would be nice, These laptop hard drives can be power hungry buggers, Some requiring 1 amp or more at spin up :) Better support for the USB port on the PCB, The USB ports can be replaced with headers for attaching panel mount USB ports if required. Can't think of anything else at the mo.
 
That's definitely progress though. It confirms the same detection code will work on the 375 and 376.
This is interesting, I booted up using a Free Dos floppy and Free Dos complained that the partition on the CF card was 'Suspicious' and recommended CHS parameters of 979-7-32, I've been using the manufactures CHS parameters in the data sheet for my CF card, So i obeyed, I set the CHS in the Bios to 979-7-32 I booted up again using the floppy and ran FDISK, Deleting the old partition and created a new one rebooted Format C: and installed the FREE DOS system files, and now Free Dos is happy :) Still can't boot from the CF but i can now access the CF using FREE DOS or MS DOS 6.22 boot floppy's.

I booted up again via floppy and installed 'DiskTest' on the CF, I Ran DiskTest and MediaTest on the CF:

3.jpg
4.jpg
I'm going to try a different system bios from an XT clone just to rule out the stock IBM bios.
 
Last edited:
What is the hardware ? XT 286 ?
Look at these perf.....

There is a function called at the begining of all the Read/write in the driver, I think it is to reinit the USB if it fail, I never tried to remove it.
This function is not in the BIOS.

979-7-32 is strange, it is not possible to have 7 heads (Even value) and 33 sectors.........
 
it is not possible to have 7 heads

FWIW, there were early voice coil actuator drives that had odd numbers of heads. (… actually available. They dedicated a full surface of one platter for the servo positioning info. Newer drives universally used “embedded servo” formatting.)
 
According to this datasheet, the CH375 supports FAT12/16/32. I was musing on whether it would be faster to have the chip deal with the file system, than the host. I'm not sure how, or if, it could be integrated with DOS in such a way mind.
 
According to this datasheet, the CH375 supports FAT12/16/32. I was musing on whether it would be faster to have the chip deal with the file system, than the host. I'm not sure how, or if, it could be integrated with DOS in such a way mind.
It is what I answered you as a difference between the chip yesterday.

What can be done :
Have the Disk images as .IMG files and mount the image we want (At boot time for example)
Create a text file that can be read by the BVIOS to list the image files.

Regarding the BIOS, this is not normal at all that the sector Read/Write work and it does not Boot.
I suppose that when you Boot on a Floppy, the BIOS init code is executed, otherwise the USB Sector Read/Write will not work.....
 
It is what I answered you as a difference between the chip yesterday.

What can be done :
Have the Disk images as .IMG files and mount the image we want (At boot time for example)
Create a text file that can be read by the BVIOS to list the image files.

Regarding the BIOS, this is not normal at all that the sector Read/Write work and it does not Boot.
I suppose that when you Boot on a Floppy, the BIOS init code is executed, otherwise the USB Sector Read/Write will not work.....

I was looking at it from a different angle - move all the file system weight to the MCU. The real-world IOPS (i.e., through the file system) on XT class machines are poor (just 4 in the tests above). If we could offload that effort to the MCU, maybe the machine could run better overall and even with FAT32. The idea is basically to have INT21h send everything to the MCU instead of trundling through the FAT via INT13h itself.
 
I was looking at it from a different angle - move all the file system weight to the MCU. The real-world IOPS (i.e., through the file system) on XT class machines are poor (just 4 in the tests above). If we could offload that effort to the MCU, maybe the machine could run better overall and even with FAT32. The idea is basically to have INT21h send everything to the MCU instead of trundling through the FAT via INT13h itself.
Yes, I did read it after, this require indeed to rewrite most of the Int21h, we really need to know the DOS perfectly for this.

The way I see it will change the solution as a HDD "Gotek" : We can use lot of different disk image, even if we loose the possibility to directly put the USB key on another PC, to transfer file. (With a Dual USB Board, and the driver it will still be possible...)
 
The way I see it will change the solution as a HDD "Gotek" : We can use lot of different disk image, even if we loose the possibility to directly put the USB key on another PC, to transfer file. (With a Dual USB Board, and the driver it will still be possible...)

Before going too deep here it would probably be worthwhile to actually benchmark how well random access within a file actually works with this thing. I assume what you’re envisioning here is the BIOS/Int13 oriented driver on the PC will treat a file opened by the MCU as a linear block of sectors (IE, like it was an LBA addressed disk device), and you’re going to leave it up to the microcontroller to handle the housekeeping of actually updating this one file. Maybe my concern is completely misplaced, but this at least “feels” to me at a gut level like this might be significantly more expensive than raw block access for this thing to keep track of, especially if there is any file system fragmentation.

I mean, I guess it might be fine, the Gotek’s pretty anemic STM ARM chip pulls it off, but the performance expectation there is only, what, around 50K/s?

… to expand on that gut feeling, the reason I’m suspicious is I assume the raw block access calls are pretty much passed straight through the USB layer for the controller on the USB device to handle, LBA block access is a native essential part of generic USB disk access. This file system feature, however, is going to be living inside whatever compute resources are embedded in this chip, right?
 
Last edited:
Back
Top