DOS ain't dead - IDE performance | bugs in IDECHECK, UIDE, XDMA, XDMA32

DOS386

10.09.2008, 02:41
(edited by DOS386, 10.09.2008, 03:11)

IDE performance | bugs in IDECHECK, UIDE, XDMA, XDMA32 (Users)

Some IDE-related observations:

- UIDE drivers don't work at all for me. Either freezer immediately after correct recognizing the drive names, or "working" but no speedup at all. Seems to like (surprisingly ?) more XMGR than HIMEMX. Anyone uses them with success ?

- XDMA works for me :-) any arguments against using it ? Incredible age of 2+1/2 years :crying:

- XDMA32 works also (but "expensive").

- IDECHECK has some bugs.

"idecheck 0 /DMA /U:5" CFG 49=2F00: DMA=1, LBA=1 CFG 51= 200: PIO mode 0-2 timing: 2 CFG 63= 7: Multiword DMA modes supported: 0 1 2 CFG 64= 3: Advanced PIO modes supported: 3 4 CFG 53= 7: UDMA valid=1 setting UDMA mode ... ok CFG 88= 43F: UDMA modes supported: 0 1 2 3 4 5, current 2 CFG 85=3469: Write cache: enabled CFG 47= 10: max. multiple sector value is 16 CFG 59= 10: current multiple sector value: 16 (valid setting) start: 8:35:55,40 Sector --------- 2560 end: 8:36:00,89 time: 0:00:05,49 for 2560 sectors -> 233 kB/sec

Why does it offer modes 0 to 5 and pick only 2 then ? "supported" modes >2 are VERY slow (see above) ... but the antique HD indeed might support UDMA 2 at best ...

"IDECHECK 0" or "IDECHECK 0 /I13" (some PC's do work, some not) : PCI v2.0c BIOS found PCI 0039 ( 0): vendor ID=8086, device ID=7111 PCI 0039 ( 4): command register=5, status register=280 PCI 0039 ( 8): revision ID=1, class code=10180 PCI 0039 (32): Busmaster DMA controller port base=F000 flushing cache ... ok reading partition table ... ok start: 8:35:15,58 Sector --------- 0 00 00[DAM not found track 0 not found command aborted uncorrectable EC C error ] 00 error end: 8:35:15,58 time: 0:00:00,00 for 0 sectors -> 0 kB/sec

I13 doesn't work on some PC's, while PIO and DMA always do. Report is not very well formatted (minor bug), but what's worse, I13 doesn't work at all, no idea why :crying:

- XDMA32 is faster than IDECHECK. Is it possible ? PIO of IDECHECK cca 9 MiB/s, DMA of IDECHECK cca 15 MiB/s, I13 of IDECHECK via XDMA32 18 MiB/s !!! Bug or "feature" ?

---
This is a LOGITECH mouse driver, but some software expect here
the following string:*** This is Copyright 1983 Microsoft ***

Japheth

Germany (South),
10.09.2008, 07:50

@ DOS386

IDE performance | bugs in IDECHECK, UIDE, XDMA, XDMA32

Post reply

> I13 doesn't work on some PC's, while PIO and DMA always do. Report
> is not very well formatted (minor bug), but what's worse, I13 doesn't work
> at all, no idea why :crying:

Did you read the readme.txt and tried /S:127? Some BIOSes are unable to read a full 64 kB block with int 13h ( /S:128, which is the default and max ).

> - XDMA32 is faster than IDECHECK. Is it possible ? PIO of IDECHECK cca 9
> MiB/s, DMA of IDECHECK cca 15 MiB/s, I13 of IDECHECK via XDMA32 18 MiB/s
> !!! Bug or "feature" ?

I don't know.

---
MS-DOS forever!

DOS386

23.09.2008, 15:58

@ Japheth

IDE performance | bugs in IDECHECK, UIDE, XDMA, XDMA32

Post reply

> Did you read the readme.txt

YES.

> and tried /S:127? Some BIOSes are unable to
> read a full 64 kB block with int 13h
> /S:128, which is the default and max

Failed to pick this info before for unknown reasons :-(

Anyway, /S:128 works sometimes (no secure failure again :-( ) ... but /S:64 indeed seems to help if /S:128 fails :-)

Thus what remains is a cosmetic problem of IDECHECK's report making it look "very broken" what it in fact isn't :-|

Rayer wrote:

> speed gain about 3x

I have 11 x "raw" speedup on one PC ... less with file access using XDMA (FAT sucks :-( )

---
This is a LOGITECH mouse driver, but some software expect here
the following string:*** This is Copyright 1983 Microsoft ***

DOS386

25.09.2008, 16:00
(edited by DOS386, 25.09.2008, 16:11)

@ DOS386

IDE performance | bugs in IDECHECK, UIDE, XDMA, XDMA32

Post reply

> remains is a cosmetic problem of IDECHECK's report making it
> look "very broken" what it in fact isn't

Fixed :-)

BTW, I have one more similar problem - but needs more tests.

---
This is a LOGITECH mouse driver, but some software expect here
the following string:*** This is Copyright 1983 Microsoft ***

DOS386

04.10.2008, 04:57

@ DOS386

IDE performance | new bugs discovered in IDECHECK

Post reply

FYI, I am with XDMA 3.1 now, because 3.3 causes XMS corruption :-(

And, I discovered some "new" bugs in IDECHECK:

- /NOI hack doesn't work. Symptoms range from suspiciously good results (up to 2 seconds to "read" the complete HD, no time for the activity light to even go on :lol3: ), through HDPMI exceptions up to low memory corruption (freezer, DOS kernel puking). What is it supposed to do at all ? Anyone can reproduce it ?

-
movzx eax,ax shl eax, 4 mov [dwDMAList],eax add eax,10h mov [bufadr],eax mov edi, eax add eax,10000h-1 ;begin on a 64 kb boundary for DMA xor ax,ax mov [bufadr2],eax mov ecx,20000h/4 test [flags],FL_PIO jnz @F mov ecx,10000h/4 mov edi, eax @@: mov eax,ecx shr eax,8 invoke printf, CStr(<lf,"%u kB read buffer at linear address %X",lf>), eax, edi xor eax,eax rep stosd

Maybe this could be optimized a bit ... is it needed to clear different areas of memory depending from PIO or DMA ? Clear all or nothing :-)

@@: clc ret waitdata_1:: @@: test byte ptr @flat:[fIRQ],80h jnz waitdata_ex in al,61h loop @B stc ret waitdata_ex:

quad-dot - bug or feature ?

---
This is a LOGITECH mouse driver, but some software expect here
the following string:*** This is Copyright 1983 Microsoft ***

Japheth

Germany (South),
04.10.2008, 09:01

@ DOS386

IDE performance | new bugs discovered in IDECHECK

Post reply

> - /NOI hack doesn't work. Symptoms range from suspiciously good
> results (up to 2 seconds to "read" the complete HD, no time for the
> activity light to even go on :lol3: ), through HDPMI exceptions up to low
> memory corruption (freezer, DOS kernel puking). What is it supposed to do
> at all ? Anyone can reproduce it ?

/NOI shouldn't be used. It cannot work currently, because it needs the assembly time switch ?SETHDIRQ to be 1 - and IIRC the switch is 0 ... and it must be 0 :-D .

---
MS-DOS forever!

DOS386

05.10.2008, 13:58

@ Japheth

IDE performance | new bugs discovered in IDECHECK

Post reply

> /NOI shouldn't be used.

So it should be disabled maybe if it's know to be broken ? ;-)

> It cannot work currently, because it needs the assembly time switch
> ?SETHDIRQ to be 1 - and IIRC the switch is 0 ... and it must be 0

Need "grab HD IRQ (problem with native controllers!)" for being able to "use polling, not IRQ" ? :confused:

invoke printf, CStr(10) @putchr lf

What does ^^^ this do ?

;--- externals wvsprintfA proto stdcall :dword, :dword, :dword wsprintfA proto c :dword, :dword, :VARARG include vioout.inc

What is the benefit of VIOOUT over INT $21 or INT $10 ? Maybe there is some space for optimization here ;-) BTW, I got it compiled and "working" with both VIOOUT and VWSPRINTF barred out :clap: ... was < 4 KiB plain code ... but not very verbose anymore :clap:

---
This is a LOGITECH mouse driver, but some software expect here
the following string:*** This is Copyright 1983 Microsoft ***

Berlin, Germany,
10.09.2008, 11:57

@ DOS386

IDE performance | bugs in IDECHECK, UIDE, XDMA, XDMA32

Post reply

> - XDMA32 works also (but "expensive").

"expensive" means what here?

> Why does it offer modes 0 to 5 and pick only 2 then ? "supported" modes >2
> are VERY slow (see above) ... but the antique HD indeed might
> support UDMA 2 at best ...

What HDD and mainboard chipset did you use?

---
Forum admin

RayeR

CZ,
10.09.2008, 15:34

@ DOS386

IDE performance | bugs in IDECHECK, UIDE, XDMA, XDMA32

Post reply

> - UIDE drivers don't work at all for me. Either freezer immediately after
> correct recognizing the drive names, or "working" but no speedup at all.
> Seems to like (surprisingly ?) more XMGR than HIMEMX. Anyone uses them
> with success ?

In my case UIDE works pretty well on intel ICH7 controller, speed gain about 3x. No probmems with QEMM, himem.sys, jemmex.exe...

---
DOS gives me freedom to unlimited HW access.

Rugxulo Usono, 10.09.2008, 16:03 @ RayeR	IDE performance \| bugs in IDECHECK, UIDE, XDMA, XDMA32 Post reply
	> In my case UIDE works pretty well on intel ICH7 controller, speed gain > about 3x. No probmems with QEMM, himem.sys, jemmex.exe... UIDE works well for me on my pretty old 430VX Triton II. However, XDMA / XDMA32 don't.

Khusraw

Bucharest, Romania,
10.09.2008, 16:12
(edited by Khusraw, 10.09.2008, 19:31)

@ DOS386

IDE performance | bugs in IDECHECK, UIDE, XDMA, XDMA32

Post reply

> - UIDE drivers don't work at all for me. Either freezer immediately after
> correct recognizing the drive names, or "working" but no speedup at all.

I assure you that UIDE is tested almost exhaustively by different people and there is no such problem reported. Please give some details about your system.

---
Glory to God for all things