DOS ain't dead

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

- 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

- 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 ***

> 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

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!

> - 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

> - 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.

> 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.

> - 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

> 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 ***

> 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 ***

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 ), 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 ***

> - /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 ), 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 .

---
MS-DOS forever!

> /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" ?

    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 ... was < 4 KiB plain code ... but not very verbose anymore

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