• Please review our updated Terms and Rules here

ISA USB board

The ' Ticks' are gone and keyboard working, But 16-bit mode is not working on my CH375 ISA - USB card, It is continually trying to ' Reset Module ', I have swapped the ports and set card to ' Fast Mode ' and no joy.
I didn't leave my XT running long enough, I just tried again and it eventually gets to ' Drive not found skipping install ' and then boots from floppy, Adjusting the 'Wait_Level' either way gets to Drive not found quickly or takes a long time.

If i set the ISA - USB card to STD mode and Ports in the BIOS as normal 0x261h and 0x260h and BIOS to 16-bit mode 'DOUBLE_WIDE equ 1' my XT boots fine into DOS, Which i found a bit odd because i didn't think it would work, But it's obviously not working in fast mode.
 
Last edited:
The REP INSW mod @Malc pertains only to 186/v20 CPUs. Hence if it’s actually an XT, with 8088 CPU, it won’t work as it stands. It can be modified along the lines of my post a few days back, but a little bit more work to do.
 
I'm pleased that the clicks are gone, at least. Small victories.

The double-wide code is only turned on in the V20/186 code paths. So if it launches in 8086 mode, it shouldn't make be engaged.

What I find very odd is that you're getting stuck at the initial bring-up. There are no meaningful changes to that section of code, aside from a bout of deduplication. It's not doing anything new. That only uses 8088 instructions.

Is it possible that the ports for "fast" mode were transcribed wrong, so it was probing the void when it tried to boot?

I seem to sometimes get "stuck" after loading enough DOS to see "Starting PC-DOS" but I'm not sure if this is normal random glitches (something left uninitialized, cold solder, bad luck, etc). or due to the fast mode. Have yet to reproduce it on demand.
 
I forgot to mention i did swap the stock 8088 for a Sony V20 when testing in 'Fast mode'.

Is it possible that the ports for "fast" mode were transcribed wrong, so it was probing the void when it tried to boot?
In STD mode i set the ports as normal in the bios ' Command_Port equ 0x261' and 'Data _Port equ 0x260' and it works fine.

In FAST mode i set the ports in the bios to ' Command_Port equ 0x260' and 'Data _Port equ 0x261' and it does not work.

When using 'FreddyV's' Fast mode ( 16-bit) driver i use port 0x261 and it works great.

Should i be using different port for 'Fast mode' with this bios ?
 
From my perspective, that's just weird. I'm not making any physical hardware changes; as I said, I'm just taking advantage of incomplete decode on the system I'm working with.

Using the Lo-Tech schematic for reference, it looked like if J4 were closed on pins 1-2, A1 would be used to toggle command/data rather than A0. This would presumably allow for pairs of "next to each other" ports-- i. e. 262/263 for command and 260/261 for data.

If it's jumpered that way, does command_port equ 0x262 and data_port equ 0x260 work?
 
I forgot to mention i did swap the stock 8088 for a Sony V20 when testing in 'Fast mode'.


In STD mode i set the ports as normal in the bios ' Command_Port equ 0x261' and 'Data _Port equ 0x260' and it works fine.

In FAST mode i set the ports in the bios to ' Command_Port equ 0x260' and 'Data _Port equ 0x261' and it does not work.

When using 'FreddyV's' Fast mode ( 16-bit) driver i use port 0x261 and it works great.

Should i be using different port for 'Fast mode' with this bios ?
Data port always 260h. Command port 261h for standard and 262h for fast.
 
If it's jumpered that way, does command_port equ 0x262 and data_port equ 0x260 work?
Data port always 260h. Command port 261h for standard and 262h for fast.
That works :)
E.jpg
I copy a 4 Mb Binary file from C: to D: and it took 37 Seconds.

I turn off INJECT_INT19_HANDLER 0 in the bios and fit my XT-IDE card and boot from the flash drive via the XUB Boot Menu and run DiskTest.
F.jpg
I also ran MediaTest with no problems.
 
have tried 0.86, Works fine and certainly usable on my XT, Even at 70 KB/s with stock 8088 :)
G.jpg
 
Yeah, most of what I've been working on lately is self-indulgent cleanup and making the boot sequence look more official. There's not much exciting there in terms of compatibility and performance. The absolute latest change moves a few lines around so that hopefully if someone puts in the wrong port numbers, it will be shown BEFORE the "can't find disc" message, so a screenshot will be more useful to debug.

I'm sort of wanting to keep the ROM size below 4095 bytes (4k - one byte checksum), allowing to fit it, a full-bells-and-whistles XT-IDE BIOS (10-12k), HD floppy BIOS (8k) and a regular XT BIOS (8k) in a 32k ROM. We're at like 4007 bytes now, and some of the code-golfing options really come at the cost of legibility and/or performance (adding extra CALL/RET or JMP to combine multiple copies of similar code, or removing the shift-optimizations in CHS-LBA calculation). Expect future versions to get more verbose in their messages, as that's a cheap place to buy another 10 bytes at a time.

A fair bit of the size comes from repeating several functions in 8088 and V20 flavours-- if it were actually built as two seperate ROMs there would be significantly more headroom, but this would be sort of inconvenient for my use case, where I swap between the processors fairly regularly.

Benchmark-wise, this thing does seem to love low wait states. With the V40 CPU, you can configure it on the fly by pushing a byte to port 0xFFF5, and switching from "maximum wait states" (3 on memory, 3 on I/O) to zero-wait seems to potentially double benchmarks. Of course, not everyone can exploit that.
 
If we sacrifice 1kb in RAM, we can have variable CHS (up to 4gb), auto création of disk read/write code > speed x2 or more with same ROM size.
I need to build my board to be able to do something,
Also, why not simulate 2 disk or more, by splitting the USB in multiple parts.
With this chip, the only limit is the time to code....
 
I sort of experimented with "simulate two discs" before, but it didn't get off the ground; I think I had failed to convince the outside world that two discs existed. The drawback there is that the flash drive would no longer look conventional, if you put it in another machine, it would see the first "disc" and then a bunch of garbage that it didn't recognize. I figure a very real use case is to use a larger machine to "preload" the flash drive at a much faster rate than the target could do.

You can push it to about 8Gb by changing the maximum head count (MAX_HPC) to 255, but I found the performance of an 8086-class CPU tossing around a 504Mb partition is bad enough, and a lot of 8086-friendly operating systems don't support over 2Gb per partition anyway. The one thing I was was dynamic was the INT41 disc parameter table; we hard code "maximum allowed size" there, so if you enabled up-to-8Gb support, and used a 4Gb drive, they'd clash, but I'm not sure a lot of software outside of disc utilities uses them. It tries to warn you to update this if you decide to use, say, a 256Mb drive.

I'm also not completely up on the most official ways to model geometry above 504Mb, the hack to 8G seems to work, but it might not be the most compatible way to model an off-size disc.

I'm not sure I understand why moving the code to RAM would be faster? The decision "use 8086 vs v20" is done at initialization time, so there's no real rework done at runtime. Does a typical XT use more wait states when talking to ROM than RAM?
 
I still don't follow. The RAM is also 8 bit wide. For example, the Zenith Z-150 has zero RAM on the processor board, so it could only concievably access it via the 8-bit bus. If you had an 8086, it might be viable then, although I wonder if you could just "shadow RAM" things-- write a little utility that copied the BIOS segment out of ROM and into (ideally, upper) RAM and adjusted the INT13 vector.
 
Yes I mean for 8086 and more.
Also, if you want to limit the rom size, we can build the unrolled loop read/write code in the ram.

I use my driver with dos 6, a1gb partition on a 8086 8mhz and the performance is excellent.

Limit the code size to 4kb to have all the BIOS in one ROM is interesting only for people doing advanced customization. Most of the ppls take the boards and want them to work directly. This will be extremely rare.
 
Maybe an answer is to have the BIOS not take memory, but implement a function call allowing it to do so? So the feature can be enabled at run time if required.
 
Well, here's an embarrassing fix.

I had tried to re-enable interrupts at the top of the INT13 handler, so we wouldn't lose timers and stuff. Been there for a while now. But the code immediately overwrote the newly-re-enabled interrupt flag. This is why for all this time, it's been quoting outlandishly high benchmarks. Now I'm seeing DISKTEST figures in the 300kBps range for an 8MHz V40, zero wait states and all speed-ups enabled. This feels more plausible to me-- the XT-IDE should be about twice as fast because it's fundamentally got a 16-bit wide source to be feeding in. A full run takes about 55 seconds, and gosh, the clock has advanced about 55 seconds instead of ~30!

This also means that any knowledge we have of how delicate being interrupted is-- timer, serial, etc, was incorrect. I would hope the CH376 is forgiving of occasionally disappearing for an interrupt-handler worth of time mid-operation-- the fact it can be largely operated with single DEBUG outputs makes me think it is-- but dig out your early-2000s colour-coded Terror Alert Level dial and crank it a notch or two higher. Worst case, if you're more comfortable with the distorted timer than any risk of interruption, turn off ALOW_INTS
 
The XTIDE UB runs with interrupts enabled (see Int13h.asm):

Code:
95 Int13h_DiskFunctionsHandler:
96    %ifndef RELOCATE_INT13H_STACK
97        sti                                 ; Enable interrupts
 
On the main branch, I did some tweaks for the retry behaviour on read/write; I think we were losing our "start of the buffer" pointer and potentially the number of sectors (186 writes), so a replay would not behave correctly to the point of potentially corrupting memory or data. This is theoretical, as I'm still not really testing the error flows that well without the ability to make the CH375/6 blow up on command.


I've been doing some experimentation on shadowing to RAM, and the results are not promising-- a lot of "it suddenly branches off to nowhere." In the best case scenario (seems to work better with an 8088 than a V20/40) it makes its way to a prompt, but loading anything non-trivial seems to fail with the disc flashing like it forgot to end the reads correctly. Not really sure why it would behave differently in RAM instead of ROM, but the behaviour is the same whether I put it at the top of (lowered) conventional memory, or high memory (C8000) where presumably nothing should be surprisingly loading stuff OVER the migrated memory.
 
I will write a BIOS loader to be able to do test, as I don t have a lotech board and I don t want to flash my xt cf board rom
 
Back
Top