• Please review our updated Terms and Rules here

ISA USB board

Okay, I built a copy right now with these options:

MAX_SPT equ 63 MAX_HPC equ 16 MAX_CYL equ 1024 %assign DISPLAY_CH376S_ERRORS 1 %assign INJECT_INT19_HANDLER 1 %assign ALLOW_INTS 1 %assign DOUBLE_WIDE 1 %assign SHADOW 1 COMMAND_PORT equ 0xE4 DATA_PORT equ 0xE0 COMMAND_PORT_2 equ 0 DATA_PORT_2 equ 0 WAIT_LEVEL equ 10

and it powers up on a 4.77MHz 8088 fine. DOS loads, and FDISK does too. I'll admit to using a drive that works already, but I'm not sure I have anything working but unpartitioned.

The wording "non-system disc" doesn't come from this BIOS. It seems like it might be baked into the boot sector of on discs with a typical floppy-style boot sector... I wonder if the disc is configured in a way that's confusing the system-- like FDISK is looking for a hard-disc style partition table in a floppy-style formatted drive?

I wonder if a FDISK /MBR would help recover normalcy on the drives. What do they look like on another machine, i. e. in Windows Disc Manager?
 
Last edited:
I also planned Write to the F000 Segment as it is supposed to contain ROM, to not disturb the system to configure it…

Extended BIOS functions, with Hot swappable ROM Bank (Virtually unlimitted BIOS library) and whatever else.....
At least on 5160, it will need to use slot 8 or have a physical connection to the ROM socket(s). I’ve documented why here:

I don’t know about other systems.
 
Okay, I built a copy right now with these options:

MAX_SPT equ 63 MAX_HPC equ 16 MAX_CYL equ 1024 %assign DISPLAY_CH376S_ERRORS 1 %assign INJECT_INT19_HANDLER 1 %assign ALLOW_INTS 1 %assign DOUBLE_WIDE 1 %assign SHADOW 1 COMMAND_PORT equ 0xE4 DATA_PORT equ 0xE0 COMMAND_PORT_2 equ 0 DATA_PORT_2 equ 0 WAIT_LEVEL equ 10

and it powers up on a 4.77MHz 8088 fine. DOS loads, and FDISK does too. I'll admit to using a drive that works already, but I'm not sure I have anything working but unpartitioned.

The wording "non-system disc" doesn't come from this BIOS. It seems like it might be baked into the boot sector of on discs with a typical floppy-style boot sector... I wonder if the disc is configured in a way that's confusing the system-- like FDISK is looking for a hard-disc style partition table in a floppy-style formatted drive?

I wonder if a FDISK /MBR would help recover normalcy on the drives. What do they look like on another machine, i. e. in Windows Disc Manager?
Already tried that but just tried again and still the same, Using a perfectly bootable flash drive i get the ' Non system disk or disk error ', Go back to the previous bios and all works perfectly.

Re: FDISK /MBR should Not be needed as it can often make things worse, Format C: /s OR SYS C: should be all that's needed, Though i just booted my XT via floppy and ran FDISK /MBR on my perfectly bootable flash drive and now my flash drive still won't boot on my XT and now won't boot at all on my other PC's. So i will have to wipe and re-install.

Here's a screen shot of FDISK when i try to partition a fresh flash drive, The XT is frozen and all i can do is switch off, Note the garbage at the bottom.
Fdisk.jpg
Try running FDISK on a fresh flash drive.
 
Uggh. I see the issue now. The way you described it originally, I thought FDISK was failing to launch at all.

I was able to replicate your FDISK error, when I swapped in a CH375 module. I did my original testing with a CH376, so I didn't exercise the "select correct write command for the chip" code path for the 375. It was popping an unwanted extra value off the stack (which caused that display corruption, it was likely trying to return to the top of the BIOS and running detection code again) and clobbering the operation code choice. Patching that seemed to fix FDISK, I was able to partition some random 16Gb stick with a 2Gb non-DOS partition back to a 504Mb DOS disc. I did have to FDISK /MBR it afterwards to make it bootable, likely because it was full of leftovers (it was probably a Linux or Haiku live disc with who-knows-what x86-64 code in the boot record)

This has ended up with a surprising amount of combinatoric complexity-- at least four major code paths (8088/v20 x CH375/6) and arguably more when you consider shadowing, double-wide, or second drive selections. I clearly need to build a continuous integration system: a room full of XT clones and a breaker that I can throw every time I need to reboot them all with a new ROM image.

I'm already practicing Agile Programming on this project (the XT is in one room, the machine with the ROM programmer is in another, and I sprint between the two for each build) :)
 
This has ended up with a surprising amount of combinatoric complexity-- at least four major code paths (8088/v20 x CH375/6) and arguably more when you consider shadowing, double-wide, or second drive selections. I clearly need to build a continuous integration system: a room full of XT clones and a breaker that I can throw every time I need to reboot them all with a new ROM image.

I'm already practicing Agile Programming on this project (the XT is in one room, the machine with the ROM programmer is in another, and I sprint between the two for each build) :)
You're doing an excellent job, I don't know how far you intend to go with this bios but would it be easier in the long run if you made it 'modular' ??. A bit like the XUB.

Everybody's use case is going to be different, For me it's already surpassed my initial requirements :)
 
Yeah, I'm sort of surprised it got this far. My original use case was that I bought into a "build an XT clone" project that used the CH376 as an alternative to an era-appropriate disc controller, but the firmware was sort of a work-in-progress. All I really needed was to support that one design. But I figured if we got to the point where the CH375/6 platform was actually a viable choice alongside XT-IDE and XT-CF style products, it means more resources (developers, people finding bugs, knowledge) orbiting around it and hopefully better code.

I feel like the kit userbase is still an important target and you can see it in my choices:
* Since that kit was originally designed with a total of 32k ROM, we're better off being frugal in case people want to stuff it with things like boot-to-ROM utilities, XT-IDE or HD floppy controller BIOSes too.
* Since the kit can be built with an 8088, a V20, or a V40 based on preference, it's nice to keep the 8086 and V20+ modes in a single binary, so it's turnkey for people who want to build the kit, but lack the software knowledge to rebuild the ROM with custom options. I know the XT-IDE builds tend to split the two.
 
Been doing some light cleanup today. The startup messages are a bit terser (I didn't like that we were getting to the point where were going to scroll the VGA BIOS signature away with two drives) and I think it fails more gracefully (no hang at the end of initialization) if you say a second CH37x exists and it doesn't. With debugging removed-- I have a rather inefficient unrolled "dump the registers" function-- we seem to build below 4k again, but I'm leaving the 6k tagging for the moment. Probably nothing here of interest unless you want to experiment with two CH37x cards, but it's merged back to the main branch.
 
Got the CH375 card in today, so I can now properly test dual-drive operation. Found some mistakes where we were always looking at the ports for drive #1 (a SHR instead of a SHL so instead of converting 1->2 for an offset, we got 1->0), which should be sorted now. It always checks the device type before writing, so it seems to handle one device being a 376 and one being a 375 just fine-- I suspect this is an uncommon scenario.

The compatibility behaviour with the drives that the little CH375 module didn't like was a touch different-- at least one would detect, but at boot report error 17 (Buffer overflow) when reading and eventually the OS gave up.

It looks like the Aliexpress card does not support double-wide mode as-is. :/ I notice the schematic on the mini-CD provided does not match the board (no port jumpers, and using a GAL that wasn't on the actual card). Does anyone know what J1 does? I didn't see an obvious behaviour change when closing it, and I couldn't see an obvious visual of where it goes.
 
Last edited:
Got the CH375 card in today, so I can now properly test dual-drive operation. Found some mistakes where we were always looking at the ports for drive #1 (a SHR instead of a SHL so instead of converting 1->2 for an offset, we got 1->0), which should be sorted now. It always checks the device type before writing, so it seems to handle one device being a 376 and one being a 375 just fine-- I suspect this is an uncommon scenario.

The compatibility behaviour with the drives that the little CH375 module didn't like was a touch different-- at least one would detect, but at boot report error 17 (Buffer overflow) when reading and eventually the OS gave up.

It looks like the Aliexpress card does not support double-wide mode as-is. :/ I notice the schematic on the mini-CD provided does not match the board (no port jumpers, and using a GAL that wasn't on the actual card). Does anyone know what J1 does? I didn't see an obvious behaviour change when closing it, and I couldn't see an obvious visual of where it goes.
Nice !
 
Not a meaningful one. The CH375 seemed to initialize and detect a bit faster than the 376, but I tended to connect different drives, so it's not apples-to-apples. I ended up chasing down a weird lockup situation (the machine would beep furiously and freeze mid-RAM-test, which seemed to be remedied by taking out every single card and reinstalling :sigh: )
 
Ran DISKTEST on two of the same type of drives (some fairly recent PNY 16Gb USB 2.0 units that came as a set of 5)-- the kbps values were *identical* but the IOPS on the CH375's drive was higher, I suspect because it was a completely empty drive versus one with some files on it.
 
If you bought the "normal" CH375 card off AliExpress, here's some thoughts on experimental bodges to try to support double-wide mode. Note this is *difficult to reverse and potentially easy to wreck stuff hardware changes* and as such comes with no warranty and no promise it will work. In particular, I don't use the ROM socket, so you might need to think about where to cut traces so as to preserve routing to there, and I can't say if that makes weird things happen to it.

1. The CH375's "A0" pin, pin 8, is directly wired to XT Bus pin A31 (Address bit 0). It's routed through a big through-hole opening obviously intended for some DIP footprint version of the chip, so you can just cut "after" that on the back side of the PCB and run the bodge wire from that that opening to bus pin A30 (Address Bit 1).

That gets the CH375 looking for commands on port **2 and **3 and data on port **0 and 1, but that's not enough. The CH375 chip select logic is only set up to enable ports two at a time.

2. The CH375 Chip Select signal (pin 27 on the CH375) is generated by the 74HC139. The output is on pin 12. Pin 13 seems to be wired to bus signal "Address Bit 1" (pin A30). Slice the trace, and bodge a wire from Pin 13 to "Address bit 2". (Bus pin A29). This will cause chip select to be set low on a group of four neighbouring ports instead of two.

bodges.jpg

With this, it would detect when addressed at ports 260/262, and with double-wide mode enabled, I was able to load stuff. I have not extensively tested it. I hate the way the bus pins just sucked up the solder and got bulgy and ugly. I suspect over time, this will bend the corresponding contacts in the slot. You may be able to find better spots to tie to-- for example, the ROM socket pins are an obvious target, especially if you don't use the socket.

I suspect double-wide mode may be more timing sensitive. When I ran at 14MHz, the initial detection (which is always single-wide) went fine, but DOS couldn't properly read the disc and just declared "invalid drive specification". At 8MHz, it was fine. The CH376 seemed okay at both speeds, but it could be any number of issues-- board design, individual sample performance, bad luck.
 
Last edited:
Hi, 12MHz on a 286 ?
There is normally no difference between "8bit" and "16Bit"
 
No, a V40. You can get them rated up to 20MHz, and they have configurable wait-states, so you can get a machine that will marginally hobble along all the way up to 20MHz when populated with modern 55ns SRAM :)
I suspect there's a sweet spot of clock speed + wait states that will maximize performance and stability; I can tell the CH37x parts get really feisty as you ramp the clocks up past normal-XT territory.
 
No, a V40. You can get them rated up to 20MHz, and they have configurable wait-states, so you can get a machine that will marginally hobble along all the way up to 20MHz when populated with modern 55ns SRAM :)
I suspect there's a sweet spot of clock speed + wait states that will maximize performance and stability; I can tell the CH37x parts get really feisty as you ramp the clocks up past normal-XT territory.
On the V40, you should use my 286 driver.
 
I'm having trouble getting any boot roms working with my CH375 card (from AliExpress) on my IBM 5160 (stock bios).

It works fine when using the V1.9A driver or FreddyV's C375V88.SYS from here.

With the "original" boot rom CH375_8K_v15_NoCtrl_final_working_512MB.BIN, I get the following.

orig.png

I can't seem to get the right CHS values it wants.

With Hak Foo's rom, I took v0.87 of disc.asm, as Malc seemed to have good luck with versions around that time (pre the dual card changes).
I left all the options as they were except changing the ports to 0x260 and 0x262, and burned it to an 8K eprom.

build.JPG


However when booting I just get this.

v87.png


Pressing F1 just drops me into IBM Basic. I've attached the rom to this post. Anything obvious I'm doing wrong? Thanks!
 

Attachments

  • v87.zip
    18.4 KB · Views: 9
I suspect the build options got garbled.

The older BIOS has a comment about using 8 512-byte blocks-- 4K in size-- but you're calling PADBIN with the 6144 value to get to 6K. It only moved up to a 6K size after that version.

Likely, when the BIOS tries to read the ROM, it sees the "I'm 8 blocks long" signature, and looks for the checksum 4K in. It won't find it there. Try using PADBIN with "4096" instead, or a newer .ASM file.

Also, I think the AliExpress cards are single-spaced ports without surgery, so you probably want 260 and 261 for the port numbers, not 260/262.
 
Also The 'Double_Wide' option should be off for the Chinese variant
 
Back
Top