• Please review our updated Terms and Rules here

ISA USB board

Thanks Malc. So unfortunately that rules out having increased USB power with these chips then, unless we are able to somehow get access to the firmware itself.
Never mind, It would have been nice but it sounds like it's going to be too much hassle, Hooking up external power is no big deal.

I plugged my XTIDE R4 back in my XT, The Flash drive is seen by the XUB as a foreign hard drive and i can boot from either the flash drive or CF, I booted from the flash drive and ran DiskTest again and got about 70 Kb/s.
Menu.jpg
 
Thanks Malc. So unfortunately that rules out having increased USB power with these chips then, unless we are able to somehow get access to the firmware itself.
Why do you say that?
I plugged my XTIDE R4 back in my XT, The Flash drive is seen by the XUB as a foreign hard drive and i can boot from either the flash drive or CF, I booted from the flash drive and ran DiskTest again and got about 70 Kb/s.
Only 70 KB/s but you got almost 868 KB/s before? I'm probably missing something. :)
 
Excellent.
If you compare the int13 bios call with this bios and the other, you May find the bug.
Because swap the machine bios to allow USB Boot will not be possible all the time.

If the disk speed test use the timer irq, IRQ May be missed when the code diable the IRQ...
You should copy à big file from one folder to another on the disk, then mesure the time with a clock. Then x2 the result.
 
Why do you say that?
See earlier in the thread. USB device power is negotiated with the host. Since the CH375 only provides the minimum 100mA through a simple 2R pull-up, it would need a powered hub in front of it to drive at 500mA, but as it doesn’t support block storage device connected via a hub, this seems to be impossible without being able to re-program it, to support a hub.
 
See earlier in the thread. USB device power is negotiated with the host. Since the CH375 only provides the minimum 100mA through a simple 2R pull-up, it would need a powered hub in front of it to drive at 500mA, but as it doesn’t support block storage device connected via a hub, this seems to be impossible without being able to re-program it, to support a hub.
I did not test, but some used a USB to CF converter, and boot on a CF.
Is there a difference between Hub and USB to CF ?
 
I did not test, but some used a USB to CF converter, and boot on a CF.
Is there a difference between Hub and USB to CF ?
It probably identifies itself as a storage device and 100mA should be enough for a CompactFlash card. I discovered recently that they will work using parasitic power from the bus itself, at reduced performance.
 
I have USB CF adapters / USB SD adapters and they work fine with my ISA - USB card, My multi card reader also works but with only one card plugged in and must be the first in the chain, USB HUB doesn't work because it is the first in the chain and that is all the ISA - USB card see's.
 
Most/all (CF/SD/whatever) memory card readers present the mounted card as belonging to the same USB mass storage device class as thumb drives. (And hard drives, etc.) Unless you try to use a feature that’s specific to some subset of devices supported under this class (like LUNs or eject commands for optical drives, say) they all behave largely identically. It literally does not matter under most circumstances if you use a “real” USB thumb drive or a flash card in an adapter.
 
Success, i think :) I installed the 'Anonymous' bios and my XT booted from the Flash drive, I dunno why it won't boot with the stock IBM BIOS or the 2 Clone XT bios's i tried.

Yes i changed the define to 0x2B because with 0x2C i had MAJOR corruption issues with this 'Anonymous' bios, I had to Zap the flash drive in another PC and start again.

More testing required but it seem's to be working quite well at the mo.
I've updated the BIOS to detect CH375 versus CH376 and select the correct write command. Obviously, this is a high risk "try it on a scratch device" change, but it seems to work on my CH376.

https://gitlab.com/hakfoo1/v40-bios/-/blob/CH375-Workarounds/disc.asm I also defaulted ALLOW_INTS on, because I suspect it has to do with the benchmarks being all over the show. I figure if we can avoid weird time-distortions, that's important to have an honest idea of what these devices and firmware can actually do.

According to their datasheets, CH376 chips start have version IDs starting with 0x40, but CH375 version numbers start with 0x80, so if we see a version 0x80 or higher, it's presumably a 375.

Right now it probes the device for its version ID before each write or format action. There are probably smarter alternatives:
* Storing the probe result somewhere-- can we steal one byte in the BIOS data area, for example
* Loading a different code base for the 375/376 toggle, like how we do for the 8086/V20+ toggle. Though now we have four copies of things and ROM space isn't free...

With regards to the other BIOSes... are any of them publically available? I could try instrumenting up the disc BIOS a bit more and seeing how those probe it to try to work the issue out. I'm afraid my machine has about as much in common with a "real" XT as grapes do to Grape-Nuts, so I'm not sure if I'll be able to actually get through a POST cycle, but it's worth trying.

Clearly the XT-IDE BIOS does something this one does not, if it can hand-off successfully.

A quick DiskTest since my machine now has both devices in it at the same time.
CH376 on this BIOS (generic 2Gb flash drive, 60M partition out of displayed 504Mb)
Write: 275.08k
Read: 342.19k
8k Random: 5.9 IOPS
Sector Random: 7.0 IOPS
Average time 143ms

XT-IDE: (32Gb Micro-SD card, 60M partition out of displayed 8G)
Write: 273.07k
Read: 637.01k
8K Random: 6.9 IOPS
Sector Random: 7.0 IOPS
Average time 142ms
 
Last edited:
I've updated the BIOS to detect CH375 versus CH376 and select the correct write command. Obviously, this is a high risk "try it on a scratch device" change, but it seems to work on my CH376.
Seem's to work for me too on my CH375, My DiskTest results are way off, I got over 1000 Kb/s, up and down like a YO YO, I found if i fit the stock IBM BIOS ROMS back in and with my XTIDE card fitted i can boot from the flash drive perfectly fine via the XUB Boot Menu, Without the XTIDE it won't boot from the flash drive but if i let it boot from floppy i can access the flash drive read / write perfectly fine as before.
 
Today's changes at https://gitlab.com/hakfoo1/v40-bios/-/blob/CH375-Workarounds/disc.asm:
* I've retooled the detection code. Originally, after DISK_INIT, we could read the drive name out of the buffer, but this always struck me weird. I didn't feel confident that this was intentional behaviour, as it's 1) not in the docs, and 2) if you actually tried to wait for an interrupt (command complete flag) like the docs suggest should happen, it disappeared. And the fact DISK_INQUIRY never returned sense concerned me too.

What I found out is that seemingly, you can't immediately sit and wait for the interrupt flag to be set after DISK_INIT. I guess the "interrupt" flag was still set from the last operation, and it was falling through immediately, so the entire "wait for ready, then do DISK_INQUIRY" process was just crashing down in flames and returning garbage. I added a slight delay after DISK_INIT, and now DISK_INQUIRY seems to reliably return the device name as expected (on a 376, at least, of course).

There's also some twiddling with the timing-- I'm trying to get it to where it initializes reliably, but also fast. I feel like there's a lot of hidden state inside the CH375/6... sometimes it will spring to life instantly, before the screen finishes warming up, and sometimes it spends 10-15 seconds where we reset and reset and reset and finally it starts responding to commands in a timely manner. Strangely, "wait longer after triggering the reset" doesn't seem to be a panacea.

The big exciting change is that there's a new option INJECT_INT19_HANDLER. If you set it to 1, it will try to hijack the existing INT19 vector with a minimal bootloader that tries to load from drive A, then drive C. This may solve the issue Malc had with other BIOSes-- if the original BIOSes were floppy-only and never even checked a hard disc, then they are probably expecting the hard disc controller to stuff its own bootloader in place.

I originally wanted to experiment with detection-- only overwriting the bootloader vector if another ROM hadn't done it yet, but it's hard because of segmented addressing; the BIOS I'm using loads the vectors as F000:blah, rather than F800:blah, and that's difficult to tell apart from an option ROM loaded at F000. I suspect I won't really need this option personally, but it does seem to work since I can see it displaying the signature if I pull out the XT-IDE and HD floppy BIOSes.
 
Most/all (CF/SD/whatever) memory card readers present the mounted card as belonging to the same USB mass storage device class as thumb drives. (And hard drives, etc.) Unless you try to use a feature that’s specific to some subset of devices supported under this class (like LUNs or eject commands for optical drives, say) they all behave largely identically. It literally does not matter under most circumstances if you use a “real” USB thumb drive or a flash card in an adapter.
In the original driver, there is a command to select the LUN 1
 
@ Hak Foo
Can I suggest you something ?
Your Wait for interrupt is an infinite loop, in the original driver and BIOS, it is not the case, and if it is too long, they do some initialization.
I think I should share my driver code with you, you can find ideas inside.
 
There might be some options there. Really, "wait for interrupt" was mostly to replace (brittle) fixed delay loops in earlier revisions. I suppose we could declare a disc error and abandon the operation for most of those calls, but I think at that point, we don't have a great recovery strategy.

We could try to reset the CH376 and re-init the drive, maybe in function 0x0, but I'm not sure if that would get to a salvagable place.
 
In the Driver/BIOS Code, they retry (3 retry max before error) or reset depending of the code returned by the IRQ Status command.
This does not change anything in the transfer speed if this code is here or not, so I did keep everything.
 
The big exciting change is that there's a new option INJECT_INT19_HANDLER. If you set it to 1, it will try to hijack the existing INT19 vector with a minimal bootloader that tries to load from drive A, then drive C. This may solve the issue Malc had with other BIOSes-- if the original BIOSes were floppy-only and never even checked a hard disc, then they are probably expecting the hard disc controller to stuff its own bootloader in place.
And it works perfectly :) Tested with stock IBM XT BIOS and Clone XT BIOS, I took the pics with the clone XT BIOS fitted.
A.jpg
B.jpg
I Ran DiskTest with a 1024KB test file.
C.jpg
I install Checkit 3 and ran the hard drive benchmark
D.jpg
This is the best version of the BIOS yet IMO, Tested on my XT 5160 anyway, I have not noticed any problems yet, It seem's stable and nippy, Not sure about the benchmark results though but it's definitely nippy. I will keep playing.
 
Glad you're enjoying it.

I've tried one more big respin on it. As FreddyV suggested, I've changed the "wait forever for interrupt" logic to be "wait 0xFFFE probes for interrupt" (in practice, most operations finish in well under 0x100). If we see we've timed out, it's structured to *attempt to* retry read/write/format operations 3 times before reporting an error, and the "init/probe drive info" operations during boot are restarted the normal "up to 10 times before admitting defeat". It's also a bit more aggressive about assuming defeat if the init/probe stuff behaves strangely.

This can't be easily tested since I don't have the means to make the CH376 fail on demand, outside of "beyond the scope" things like ripping the flash-drive out of the socket while writing. One possibility would be to drop the threshold to near zero probes, but that might not test the retry logic well (as the retries would similarly fail), and then we're back to the problem of "we know something went wrong, but can we reliably get enough understanding of the scenario to recover, or at least not make things worse?"

I think I'm probably going to merge this branch back to the "main" branch soon, as the experiment has been quite fruitful.
 
Last edited:
Back
Top