• Please review our updated Terms and Rules here

ISA USB board

Excellent.
Is it with reb insw ?

The lotech board also use zws that speed it up.
Can you try to copy a big file and mesure the time ?
I need a lotech like board as well to be able to do code on the BIOS. 😀
Dual USB one to Boot one to use the driver can be Nice. With 2 boards, one dual board or USB Hub.
 
You can try something: load the driver.
It will map the disk again as D: then you will be able to hot swap the disk: the driver will reinit the disk if you do a dir D;
And you can compare the speed for the c: and d: drive with file copy.
I you do a second partition it should be seen ?
 
I've been using REP INSB; I thought INSW read from ports N and N+1 simultaneously to get a 16-bit-wide operation. That seems to make sense given that the references imply they take the same number of clock cycles, which wouldn't be the case if INSW actually reached out across an 8-bit bus twice for data.

Bumped the version to 0.81 with the new feature of "try to reset the module before retry" if we got a timeout, and since we now have a reset procedure that doesn't write to the screen, it uses it when the command for "reset disc system" is done. Not sure I like this in that it adds a couple seconds delay during boot, and it introduces another "fixed duration pause for the sake of letting the CH375/6 sort itself out" at the end of the reset process. I hate those on principle.
 
Re INSW. The low byte is read from port n and the high byte from port n+1. When reading a word from an 8-bit expansion card, there are physically two ISA bus cycles back to back generated from each instruction.

This is how the Lo-tech card is able to achieve a performance gain - by mapping A0 of the CH375 to A1 on the ISA bus. Therefore, whether the read is from port+0 or port+1, the CH375 sees the same condition and treats them as two consecutive reads. This improves performance because there are less instruction cycles, and on a machine with a 16-bit memory bus (ie v30), the store side of the transaction will be twice as quick too.
 
Bumped the version to 0.81
Just been testing 0.80, It works fine but i see little / no difference in the bench marks.

Can you try to copy a big file and mesure the time ?
I redid the flash drive, Primary partition C: 252MB secondary partition D: 252MB, I created a 4MB binary file and put it on C:, I boot up using the 0.80 BIOS and copy the 4 MB Binary from C: to D:, I used the stopwatch on my phone and it took 1 minute and 55 seconds.
 
4*1024 / 115 * 2 = 72Kb/s
With my last driver version, on a 8086 8MHz, a 2014Kb file is copied in 21s > 191Kb/s, this is close to what is seen by Disktest

I did a copy from a folder to a sub folder.
 
Last edited:
Back in post #281 i was getting about 70 KB/s with my XT-IDE card fitted and booting from the flash drive via the XUB boot menu.
 
Back in post #281 i was getting about 70 KB/s with my XT-IDE card fitted and booting from the flash drive via the XUB boot menu.
@Malc - forgive me, it's hard to keep track of testing configurations. Which CPU and board is the latest BIOS test (4MB copy in 1m55s) done with?

@Hak Foo - the 8086 sector transfer code can be improved by unrolling the loop. e.g., replacing this:

Code:
	MOV CX, AX			;SET CX TO NUMBER OF BYTES
 .WRITE_IN_LOOP:			;LOOP LABLE
  	MOV AL, [ES:BX]		;STORE BYTE
	OUT DX, AL			;WRITE TO DATA PORT
	INC BX				;INC BX
	LOOP .WRITE_IN_LOOP	;LOOP UNTIL DONE

with something like this:

Code:
	MOV	AX, ES	; While the BIOS spec has the package at ES:BX,
	MOV	DS, AX	; LODSB/STOSB/OUTSB/INSB transfers to/from...
	MOV	SI, BX	; ...DS:SI
	CLD				; clear direction flag; increment SI after each load
%rep 64 ; BYTEs
	LODSB			; Load BYTE from [DS:SI]
	OUT		DX,AL	; Write BYTE to port
%endrep

...and likewise for the read loop, because jumps are painfully slow.

Fast-mode code for Lo-tech boards (requires COMMAND_PORT per card base address and DATA_PORT as COMMAND_PORT + 02h):

1. Sector Read for 8088/8086 CPU:
Code:
.READ_IN_LOOP:
	MOV	AX, ES	; While the BIOS spec has the package at ES:BX,
	MOV	DS, AX	; LODSB/STOSB/OUTSB/INSB transfers to/from...
	MOV	SI, BX	; ...DS:SI
	CLD				; clear direction flag; increment SI after each store
%rep 32 ; WORDs
	IN		DX,AX	; Read WORD from port
	STOSW			; Store WORD to [DS:SI]
%endrep
;	LOOP	.READ_IN_LOOP	; this line should be removed

2. Sector Read for V20/186 or above:
replace REP INSB with
Code:
	SHR		CL,1		; transfer 2 bytes per cycle
	REP INSW		; read from device and store to memory, in words

3. Sector Write for 8088/8086 CPU:
Code:
.WRITE_IN_LOOP:
	MOV	AX, ES	; While the BIOS spec has the package at ES:BX,
	MOV	DS, AX	; LODSB/STOSB/OUTSB/INSB transfers to/from...
	MOV	SI, BX	; ...DS:SI
	CLD				; clear direction flag; increment SI after each load
%rep 32 ; WORDs
	LODSW			; Load WORD from [DS:SI]
	OUT		DX,AX	; Write WORD to port
%endrep
;	LOOP	.WRITE_IN_LOOP	; this line should be removed

4. Sector Write for V20/186 or above:
replace REP OUTSW with
Code:
	SHR		CL,1		; transfer 2 bytes per cycle
	REP OUTSW		; read from memory and write to device, in words

Hopefully I didn't make any mistake in the code!
 
Bumped the version to 0.81 with the new feature of "try to reset the module before retry" if we got a timeout, and since we now have a reset procedure that doesn't write to the screen, it uses it when the command for "reset disc system" is done. Not sure I like this in that it adds a couple seconds delay during boot, and it introduces another "fixed duration pause for the sake of letting the CH375/6 sort itself out" at the end of the reset process. I hate those on principle.
Just tried 0.81, As you say there's a delay during boot, it's actually quite a delay on my XT before it gets to booting DOS, I prefer the previous version, Quicker boot up.
 
I suspect the XUB is doing some additional housekeeping that keeps the timing more honest (as well as likely adding some overhead). I thought enabling interrupts was enough, but perhaps not. I definitely get lower benches with the XUB active.

I don't think I can do the INSB/INSW gimmick because the module I'm using isn't wired in that way too.

I've now completely gutted the "initialization" process. The old way was "Hit the reset command once, try a load of times to do detect-signs-of-life". The new one is like the example code-- spam the reset command 100 times, wait, and then try the detect-signs-of-life command once." It seems to be pretty fast and consistent now.

I think I've improved the "fixed length wait" code so it's more consistent, and added a config option to lengthen the pauses after the reset and DISK_INIT operations, in case it's too fast and ends up unreliable. These should get us a good compromise between "spends 20 minutes waiting to load" and "fails to detect". See new version 0.82.
 
In the driver, the RESET Command is used only if the CH375 IRQ Status fail.

DISK_INIT Is used instead.

CH375_InitDisk proc near ; Used by CH375_Check_DiskReady
push di
push cx
call CH375_GetIRQStatus_And_CMD_0A_20
jz short loc_A46
mov al, CMD_DISK_INIT
call CH375_SendCMD_Delay
call Wait_IRQ_Status14h
 
I've now completely gutted the "initialization" process. The old way was "Hit the reset command once, try a load of times to do detect-signs-of-life". The new one is like the example code-- spam the reset command 100 times, wait, and then try the detect-signs-of-life command once." It seems to be pretty fast and consistent now.

I think I've improved the "fixed length wait" code so it's more consistent, and added a config option to lengthen the pauses after the reset and DISK_INIT operations, in case it's too fast and ends up unreliable. These should get us a good compromise between "spends 20 minutes waiting to load" and "fails to detect". See new version 0.82.
Tried 0.82, I had to change the Config from 2 to 3 because it failed to find the drive when set to 2, Still Got a delay between the 'minimal boot loader' and 'starting DOS' but not as bad as it was with 0.81, Got a new issue though, During initial detection and between the 'minimal boot loader' and ' starting DOS' i am getting ' Clicks ' from the speaker ? but once fully booted no more Clicks. No difference in the bench marks.
 
*embarrassed look* I had the speaker pulled when testing most of yesterday.

I find that when I use a drive with the blinking LED, the delay between the boot loader handoff and "starting DOS" usually involves one or two "drive goes off, then on" cycles; This is the OS calling "reset disc system" BIOS call, and this BIOS honouring the request and resetting the CH375/6. (I figure at some point, there will be code that actually uses that to recover from a surprise condition).

You could patch around the SILENT_RESET section of the code, to instead perform the "Send 57, expect A8" check first... then a "wake and sane" CH375/6 can skip the entire reset-and-wait process and go straight to detection, to shave a few seconds.

WRT the clicking: I've tried to adjust it to leave the timer in square-wave mode, which means it (should) count down by twos (so the delay count probably needs to be higher; I've defaulted to 10 for now). I figured maybe it was producing weird results because the timer mode was being changed. I also reduced the amount of poking at port 61, so hopefully less chance of accidentally enabling the speaker. On my setup, it doesn't click right now, but I don't make promises. Part of the reason I have the speaker removed much of the time is that my machine has a not-quite-compatible port 61 implementation that results in the speaker doing weird stuff, mostly staying on unwanted.

Was it a single click, or a "brrrr"? I was able to get "brrrr" by accidentally turning the speaker on in the middle of the delay logic, but I don't think the code was intentionally built that way.

There's also some rework intended to improve the quality of the "get capacity" behaviour, replacing some "spin forever waiting for the right answers" code with some more formal "wait for interrupt and check status" behaviour.

This was triggered when I found at least one model of flash drive doesn't like the DISK_SIZE call and just returns status 82 forever. Apparently some drives will fail the DISK_SIZE call have to have the R_SENSE call performed to get their error status and then they respond correctly. We also have a fallback after enough failures, where it says "if you won't tell us, assume 504Mb". The drive may be borked there, though, since it's probably going to blow up at the next command given.

I note the drive worked fine a while ago, when I was using the CH376 commands, maybe there's enough behaviour or semantic difference that the forced R_SENSE was not needed.


... so anyway, here's Wonderwall ... v0.83 https://gitlab.com/hakfoo1/v40-bios/-/blob/main/disc.asm

Note the seperate "CH375 adaptations" branch is now merged mainline.
 
Last edited:
Just tried v0.83, had a couple of warnings when building, Missing colons on line 2111 and 2143 easy fix, I'm still getting the 'Clicks' though and another issue: My keyboard no worky, I get no response from the keyboard at all, I revert back to v0.82 and keyboard works.
 
You really should check my code. R_sense is call after the disk size as well.
This is "not" my code, but the driver one.
Regarding the reset, you can check if the disk is Ok before doing the reset.
Disk size is not read / used in the driver but this function is called after disk init.
 
Just tried v0.83, had a couple of warnings when building, Missing colons on line 2111 and 2143 easy fix, I'm still getting the 'Clicks' though and another issue: My keyboard no worky, I get no response from the keyboard at all, I revert back to v0.82 and keyboard works.
Mask error in the port 61 write.
 
Ugh. I don't think it was a mask error so much as a MOV statement backwards. I stored the original value of port 61, then chose to restore some random nonsense that probably turned off your keyboard and/or made annoying noises.

I've tried to fix that, but also had two other bees in my bonnet:

1. I finally combined "reset code" used by the INT13 function 0 and "reset if something went wrong" with that used during initial detection. We're getting close to 4K ROM usage, so it's hopefully both a savings and a way to avoid things falling out of synch.
2. I looked over the schematic of my board, and it turns out REP INSW or OUTSW is a viable option. It technically appears to map the data socket to ports 0xE0, E1, E2, E3 (and possibly E8-EC). There's a new option called DOUBLE_WIDE to turn this on (for V20/186 mode only). I'm hoping real-world timings are still loose enough that this doesn't cause reliability risk.
NOTE THIS IS TURNED ON IN THE DEFAULT CONFIG AND MAY WELL NOT WORK ON ALL CH375 CARDS; PLEASE CHECK BEFORE TESTING.
 
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.
 
Back
Top