DOS ain't dead

R. Loew's AHCI cdrom driver AHCICD.SYS doesn't find my SATA DVD drive (the driver expects to find a SATA capability register set, which is optional and isn't exposed by the SATA controller of my board ).

Are there any alternative drivers to try or is this the only one that exists?

---
MS-DOS forever!

> R. Loew's AHCI cdrom driver AHCICD.SYS doesn't find my SATA DVD drive (the
> driver expects to find a SATA capability register set, which is optional
> and isn't exposed by the SATA controller of my board ).
>
> Are there any alternative drivers to try or is this the only one that
> exists?

Maybe UDVD2 by Jack? Copies: http://mercurycoding.com/downloads.html#DOS It probably also requires SATA, but I am not sure whether AHCICD only has a detection issue or whether it really NEEDS (additional?) SATA compatible registers? Can you "expose" that extra register by changing your BIOS settings or by manipulating PCI/PCIe device settings with a small DOS tool? Or is it completely absent in your controller hardware?

---
FreeDOS / DOSEMU2 / ...

> > R. Loew's AHCI cdrom driver AHCICD.SYS doesn't find my SATA DVD drive
> (the
> > driver expects to find a SATA capability register set, which is optional
> > and isn't exposed by the SATA controller of my board ).
> >
> > Are there any alternative drivers to try or is this the only one that
> > exists?
>
> Maybe UDVD2 by Jack? Copies: http://mercurycoding.com/downloads.html#DOS It
> probably also requires SATA, but I am not sure whether AHCICD only has a
> detection issue or whether it really NEEDS (additional?) SATA compatible
> registers? Can you "expose" that extra register by changing your BIOS
> settings or by manipulating PCI/PCIe device settings with a small DOS tool?
> Or is it completely absent in your controller hardware?

Jack absolutely refused to implement AHCI because "AHCI is too complicated".

> I am not sure whether AHCICD only has a
> detection issue or whether it really NEEDS (additional?) SATA compatible
> registers?

Most likely it needs them - because the reason to exist for SATA compatibility registers is to allow a so-called Index Data Pair (IDP) mechanism, that simplifies AHCI register access for real-mode software.

> Or is it completely absent in your controller hardware?

No, this controller is AHCI-only.

It's not a real problem, may use another machine - it's just a bit inconvenient.

---
MS-DOS forever!

> R. Loew's AHCI cdrom driver AHCICD.SYS doesn't find my SATA DVD drive (the
> driver expects to find a SATA capability register set, which is optional

And why not to fix/improve R. Loew's AHCI driver? You're brave ASM coder, it's only 15kB...

Other option, isn't possibe to set that bit in chipset before loading the driver? Sigh, I'm worried they removed IDE compatible mode from nrwer chipsets and even chipsets that still supports it may lack support in BIOS.

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

> And why not to fix/improve R. Loew's AHCI driver? You're brave ASM coder,
> it's only 15kB...

Good idea. I wasn't aware that the source is available.

I adjusted the source, it works, using unreal mode to access the memory-mapped HBA register set.

Regretably it's copyright R. Loew, so I cannot distribute it freely.

> Other option, isn't possibe to set that bit in chipset before loading the
> driver?

What bit? It's a relatively new board, I guess they omitted all "legacy" stuff.

---
MS-DOS forever!

> Good idea. I wasn't aware that the source is available.

I think I posted here some link to R.L. legacy in the past, he made also set of very interesting DOS utilities e.g. the TRIM tool (that I reformated source to compile and trying to understand how it works) not only Win9x stuff...

> I adjusted the source, it works, using unreal mode to access the
> memory-mapped HBA register set.

I woud expect that trick. It could be modified to use JEMM services to access MMIO.

> Regretably it's copyright R. Loew, so I cannot distribute it freely.

AFAIK the whole package including the sources was put online by his family to make them freely available, at least for non-commercial use (they no longer sell the SW). I don't know what kind of licence, if explicitly specified, there's a thread about it on MSFN...

> What bit? It's a relatively new board, I guess they omitted all "legacy"
> stuff.

OK, then no other way than use AHCI. BTW does it still have AHCI BIOS INT13h services for DOS? (doesn't help for CD/DVD, just HDDs).

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

Jack asked me to convey the following message:

> In his post above, my "good friend" Tom Ehlert says:

> > Jack absolutely refused to implement AHCI because
> > "AHCI is too complicated".

> Tom is misinformed as usual. The major reasons why
> I refused to put AHCI in my drivers are (A) AHCI was
> supposed to offer "legacy" mode, to make writing new
> drivers optional, and (B) AHCI is actually worthless
> for DOS, as DOS handles I-O requests "one at a time"
> and cannot "queue" them, which AHCI needs to improve
> speed. I decided NOT to complicate my drivers; DOS
> runs exactly the same with "legacy" AHCI or standard
> SATA controllers, since both are actually identical!
> If cheap mainboard vendors are now dropping "legacy"
> AHCI support, fault all of THEM, and not me!!

> Jack R. Ellis

---
Glory to God for all things

> I adjusted the source, it works, using unreal mode to access the
> memory-mapped HBA register set.
>
> Regretably it's copyright R. Loew, so I cannot distribute it freely.

I think, a diff file produced with -U2 (default) would be okay. Maybe -U1 is already enough.

---
Forum admin

> > If cheap mainboard vendors are now dropping "legacy"
> > AHCI support, fault all of THEM, and not me!!

The problem is that now it's not lazyness of MB BIOS writers but the final decision of chipset manufacturers intel and AMD to drop the (almost all) legacy things. So now there's need for AHCI support. It seems it shouldn't be so complicated according R.L's driver.

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

> I think, a diff file produced with -U2 (default) would be
> okay. Maybe -U1 is already enough.

I'm afraid this is no useful approach - because the first thing I did with the original was to "reformat" the source: indent reduced to 4, code labels and opcodes separated to 2 lines.

But the changes are indeed minimal - one can see from this that Mr. Loew was a master.

Here's the changes, in case anyone desperately needs such a driver:

    OUT     DX,EAX
    POP     EBX
    POP     EDX
    RET

    include hbap.inc

GETHBA:
    @setint0d
    PUSH    EDX                     ;AX = ADDR
    MOV     EDX,CS:[HBA]
if 0
    AND     EDX,EDX
    JS      GHP
    OUT     DX,AX
    ADD     DX,4
    IN      EAX,DX
    JMP     GHE
GHP:
    CALL    PUTPCI
    ADD     EDX,4
    CALL    GETPCI
GHE:
else
    movzx eax,ax
    mov eax,[edx+eax]
endif
    POP     EDX
    @restint0d
    RET

PUTHBA:
    @setint0d
    PUSH    EDX                     ;AX = ADDR  ECX = VALUE
    MOV     EDX,CS:[HBA]
if 0
    AND     EDX,EDX
    JS      PHP
    OUT     DX,AX
    ADD     DX,4
    MOV     EAX,ECX
    OUT     DX,EAX
    JMP     PHE
PHP:
    CALL    PUTPCI
    ADD     EDX,4
    MOV     EAX,ECX
    CALL    PUTPCI
PHE:
else
    movzx eax,ax
    mov [edx+eax], ecx
endif
    POP     EDX
    @restint0d
    RET


and, in the init section:


GOTHBA:
    DEC     BP
    JNZ     NXTHBA
if 0 ;don't search for SATA compatibility header
    MOV     DL,34H
    CALL    GETPCI
GETCAP:
    AND     AL,AL
    JZ      NG
    MOV     DL,AL
    CALL    GETPCI
    CMP     AL,12H
    JZ      GOTCAP
    MOV     AL,AH
    JMP     GETCAP
GOTCAP:
    ADD     DL,4
    CALL    GETPCI
    CMP     AL,0FH
    JNZ     IOPORT
    ADD     DL,4
    MOV     DS:[HBA],EDX
    JMP     ENDHBA
IOPORT:
    MOV     CX,AX
    SHR     CL,2
    AND     CL,0FCH
    AND     AL,0FH
    SHL     AL,2
    MOV     DL,AL
    CALL    GETPCI
    TEST    AL,1
    JZ      NG
    AND     AL,0FEH
    ADD     AX,CX
    MOV     DS:[HBA],EAX
ENDHBA:
else
    smsw ax
    test ax,1
    jz @F
    mov dx,offset msg6
    jmp NG1
msg6 db "ahcicdp driver can't work in V86 mode!",13,10,13,10,'$'
@@:
    mov dl,24h  ;get ABAR5
    call getpci
    mov ds:[HBA],eax
    mov eax,cs
    shl eax,4
    add eax,offset gdt-8
    mov dword ptr ds:[gdtr+2],eax       ;set linear address of GDT
endif
    MOV     AX,4
    CALL    GETHBA



my changes are easy to identify, they are in lower case.

Finally, there's a new file, named hbap.inc, where I put the "unreal" stuff into:



;--- define macros @setint0d and @restint0d
;--- these macros activate unreal mode

    align 8
gdt label qword
        dw -1,0,9200h,0CFh      ; 32-bit flat data descriptor
;       dw -1,0,9200h,0         ; 16-bit data descriptor

SEL_FLAT equ 8
;SEL_DATA16 equ 16

gdtr dw 3*8-1,0,0

;--- exception 0D: no need to check if it's a real exception,
;--- since interrupts were disabled.

int0d:
        push ds
        push eax
        lgdt fword ptr cs:[gdtr]
        mov eax,cr0
        inc ax
        mov cr0,eax
        jmp @F
@@:
        dec ax
        push SEL_FLAT
        pop ds
        mov cr0,eax
        pop eax
        pop ds
        iret

@setint0d macro
        pushf
        cli
        push ds
        push 0
        pop ds
        push ebx
        push cs
        push offset int0d
        mov  ebx,ds:[13*4]
        pop  dword ptr ds:[13*4]
endm
@restint0d macro
        mov ds:[13*4],ebx
        pop ebx
        pop ds
        popf
endm


to assemble, enter:


jwasm -bin -Foahcicd.sys ahcicd.asm


Hint: better do NOT move the XBDA if you load this driver. In my machine, several HBA data regions are located in this area.

Also, be aware that this driver runs in real-mode only. There's a check, but it's in the init phase only, so if you load the driver before loading jemm386, you won't get a warning.

---
MS-DOS forever!

https://www.rloewelectronics.com/
https://msfn.org/board/topic/180215-rloew-1952-2019-has-passed-away/

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

> Also, be aware that this driver runs in real-mode only. There's a check,
> but it's in the init phase only, so if you load the driver before loading
> jemm386, you won't get a warning.

Any chance for adapt it for V86 mode?

---
DOS-u-akbar!

> Jack asked me to convey the following message:
>
> > In his post above, my "good friend" Tom Ehlert says:
>
> > > Jack absolutely refused to implement AHCI because
> > > "AHCI is too complicated".
>
> > Tom is misinformed as usual. The major reasons why
> > I refused to put AHCI in my drivers are (A) AHCI was
> > supposed to offer "legacy" mode, to make writing new
> > drivers optional, and (B) AHCI is actually worthless
> > for DOS, as DOS handles I-O requests "one at a time"
> > and cannot "queue" them, which AHCI needs to improve
> > speed. I decided NOT to complicate my drivers; DOS
> > runs exactly the same with "legacy" AHCI or standard
> > SATA controllers, since both are actually identical!
> > If cheap mainboard vendors are now dropping "legacy"
> > AHCI support, fault all of THEM, and not me!!

I abbreviated (and maybe oversimplified).

Jack Ellis, 15 Mrz 2012:


"As I have noted, (A) AHCI is USELESS for DOS, as DOS does "One at a
time" I-O and cannot make use of AHCI's much-touted "Native command
queuing", and (B) AHCI is RIDICULOUSLY complex, the obvious results
of it being designed by a [MISERABLE!] "ANSI committee" which tried
to satisfy EVERYBODY and in the end satisfied NOBODY, as-usual! I
have REFUSED to implement actual AHCI in UIDE/UIDE2, and I shall do
so for as long as "IDE compatibility" mode exists -- I have NO wish
to double my drivers' I-O logic and so reduce their cache capacity,
"Por NADA!" [for NOTHING], since DOS can never use AHCI queuing!"

the conclusion remains the same: no, Jack Ellis drivers won't support AHCI.

I found that I already have on my site/download collection another AHCI driver ahcicd.sys version 1.1 by intel dated 2008, can you try if it works?

http://rayer.g6.cz/download/ahcicd.sys

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

> I found that I already have on my site/download collection another AHCI
> driver ahcicd.sys version 1.1 by intel dated 2008, can you try if it
> works?
>
> http://rayer.g6.cz/download/ahcicd.sys

Can't download it, it looks like FF tries to "run" .SYS-files and tells me "No video with supported format and MIME type found". What an idiotic pile of sh!t!

Please change the file to .zip!

---
MS-DOS forever!

> Any chance for adapt it for V86 mode?

Yes, of course - but not by me.

And please be aware that my changes were a "quick and dirty" hack - tested on ONE machine, with ONE configuration. For example, I didn't care about A20, because my device is of the "always ON" type.

---
MS-DOS forever!

Right click|Save link target as... doesn't work?

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

> Right click|Save link target as... doesn't work?

No, they messed it completely. There's a menu item "save video as...", but clicking it has no effect at all.

---
MS-DOS forever!

> > Right click|Save link target as... doesn't work?
>
> No, they messed it completely. There's a menu item "save video as...", but
> clicking it has no effect at all.

but I finally remembered that I can download with another tool - 'wget' did it.

The linked driver is from Intel, 2008 ( at least that's what it tells ). It behaves like Loew's driver, claiming "SATA controller not found". So I suppose it also expects to find the PCI SATA capability registers for IDP access.

---
MS-DOS forever!

> Can't download it, it looks like FF tries to "run" .SYS-files and tells me
> "No video with supported format and MIME type found". What an idiotic pile
> of sh!t!

Same problem with Habit Browser on Android. So maybe a MIME configuration issue on RayeR's web server.

---
Forum admin

By the way - similar discussion we hahe hed here in the past:
http://www.bttr-software.de/forum/mix_entry.php?id=7412

---
DOS-u-akbar!

> > Can't download it, it looks like FF tries to "run" .SYS-files and tells
> me
> > "No video with supported format and MIME type found". What an idiotic
> pile
> > of sh!t!
>
> Same problem with Habit Browser on Android. So maybe a MIME configuration
> issue on RayeR's web server.

Confirmed that the mimetype is wrong.

Not sure why Japheth's Firefox suggests to
just run com/exe/bat/sys immediately then?

Headers for http://rayer.g6.cz/download/ahcicd.sys are:

HTTP/1.1 200 OK
Server: nginx
Date: Thu, 14 Jan 2021 xx:xx:xx GMT
Content-Type: audio/mpeg
Content-Length: 12149
Connection: close
Last-Modified: Mon, 06 Mar 2017 00:34:28 GMT
ETag: "xxxx-xxxxxxxxxxxxx"
Accept-Ranges: bytes
Cache-Control: max-age=0, must-revalidate
Expires: Thu, 14 Jan 2021 xx:xx:xx GMT

---
FreeDOS / DOSEMU2 / ...

> > Same problem with Habit Browser on Android. So maybe a MIME
> configuration
> > issue on RayeR's web server.
>
> Confirmed that the mimetype is wrong.

Thanks.

> Not sure why Japheth's Firefox suggests to
> just run com/exe/bat/sys immediately then?

Because it only looks at the MIME type?
My Habit Browser does the same.

---
Forum admin

In Mozilla Seamonkey the left mouse click opens video player but right click/save as works. I don't have control of server settings bu I can set my own .htaccess if it would be usefull in this case. Also I think that MIME types can be some way overrided in browser config.
BTW what about COM and EXE files, do you have the same issue?
http://rayer.g6.cz/download/mm.com
http://rayer.g6.cz/download/salamand.exe
(for me the COM file displays chinese tea and EXE opens save dialog)

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

> By the way - similar discussion we hahe hed here in the past:
> http://www.bttr-software.de/forum/mix_entry.php?id=7412

Thanks for the hint! Although I don't really understood what software DOSferatu actually had developped ( or was talking about ): was it a AHCI HDD or DVD driver or some speed demonstration code only?

---
MS-DOS forever!

> > I refused to put AHCI in my drivers are (A) AHCI was
> > supposed to offer "legacy" mode

> > If cheap mainboard vendors are now dropping "legacy"
> > AHCI support, fault all of THEM, and not me!!

They actually cannot be blamed, because there always - since AHCI v1 - existed the HBA CAP.SAM bit (bit 18). If set, the controller supports AHCI access mechanisms ONLY. So the IDE - or "legacy" - emulation was "optional" from the very beginning.

---
MS-DOS forever!

> behaves like Loew's driver, claiming "SATA controller not found". So I
> suppose it also expects to find the PCI SATA capability registers for IDP
> access.

OK, thx for testing, good to know. I don't have such new HW yet and my laptop at work lacks optical drive. Does your machine have at least AHCI BIOS for HDD access?

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

> OK, thx for testing, good to know. I don't have such new HW yet and my
> laptop at work lacks optical drive. Does your machine have at least AHCI
> BIOS for HDD access?

Yes, booting DOS is no problem.

I wrote a little ahci utility that displays the status of the controller, so you can see by running it if the loew-driver will work:

https://github.com/Baron-von-Riedesel/AHCI1

---
MS-DOS forever!

Thanks, here I post the log from my Dell work laptop - so it should have IDP and no modded driver needed:


no IDE Busmaster device (class=0x01018x) found
no SATA IDE device (class=0x010600) found
SATA AHCI device (class=0x010601) found at bus/device/function=0/23/0:
  vendor=0x8086, device=0xa102
  CMD=0x7 ([0]=IOSE,[1]=MSE (Memory Space Enable),[2]=BME (Bus Master Enable)
  EROM=0x0
  capabilities ID=0x5, next pointer=0x70
  capabilities ID=0x1, next pointer=0xa8
  capabilities ID=0x12, next pointer=0x0
  SATA capability register set found, Index-Data Pair (IDP) available
  interrupt line=11
  AHCI Base Address=0xed353000
  CAP - HBA Capabilities (RO): 0xef34ff41
  CAP.NP[0-4]=1 (# of Ports-1)
  CAP.NCS[8-12]=31 (# of Command Slots-1)
  CAP.PMD[15]=1 (1=supports multiple DRQ block data transfers for PIO)
  CAP.SAM[18]=1 (1=supports AHCI mode only)
  CAP.ISS[20-23]=3 (Interface Speed Support, 1=1.5Gb,2=3Gb,...)
  CAP.SCLO[24]=1 (1=supports Command List Override)
  CAP.SNCQ[30]=1 (1=supports Native Command Queuing)
  CAP.S64A[31]=1 (1=supports 64-bit Addressing)
  GHC - Global HBA Control: 0x80000000
  GHC.AE[31]=1 (1=AHCI Enable)
  IS - Interrupt Status Register: 0x0
  PI - Ports Implemented: 0x5 (is a DWORD bit-string, max. ports=32)
  VS - AHCI Version: 1.31
  Port 0, Base=0xed353100
    CLB - Command List Base Address=0x9d800
    FB - FIS Base Address=0x9dc00
    IS - Interrupt Status=0x0 ([0]=D2H Reg FIS, [1]=PIO Setup FIS, [2]=DMA Setup FIS, ...)
    IE - Interrupt Enable=0x0
    CMD - Command and Status=0x4004016
    CMD.FRE[4]=1 (1=FISes may be written to FIS receive area)
    CMD.CCS[8-12]=0 (Current Command Slot)
    CMD.FR[14]=1 (1=FIS receive running)
    CMD.CR[15]=0 (1=Command List running)
    CMD.HPCP[18]=0 (1=Hot Plug Capable Port)
    CMD.ATAPI[24]=0 (1=device is ATAPI)
    TFD - Task File Data=0x50
    SIG - Signature=0x101 (received from device on first D2H register FIS)
    SSTS - SATA Status=0x133 (Device Detection[3:0]=3, Interface Speed[7:4]=3, Power Management[11:8]=1)
    SCTL - SATA Control=0x300 (DET[3:0]=0, SPD[7:4]=0, IPM[11:8]=3)
    SERR - SATA Error=0x0
    SACT - SATA Active=0x0 (bit string for max. 32 command slots)
    CI - Command Issued=0x0 (bit string for max. 32 command slots)
      CL Base=0x9d800, size=0x400 (32*32)
      CL[0] PRDTL=1 CFL=5 flgs+PMP=0x0 PRDBC=0x200 (PRDTL=items in PRDT)
      CL[0] Command Table Base Address=0x9dd00 (CFIS=+0 ACMD=+0x40 PRDT=+0x80)
        CFIS: type=0x27
        PRDT: 0x9be00 0x1ff
      (received) FIS at 0x9dc00, size=0x100 (DSFIS=+0 PSFIS=+0x20 RFIS=+0x40 UFIS=+0x60)
  Port 2, Base=0xed353200
    CLB - Command List Base Address=0x9d800
    FB - FIS Base Address=0x9dc00
    IS - Interrupt Status=0x0 ([0]=D2H Reg FIS, [1]=PIO Setup FIS, [2]=DMA Setup FIS, ...)
    IE - Interrupt Enable=0x0
    CMD - Command and Status=0x4004016
    CMD.FRE[4]=1 (1=FISes may be written to FIS receive area)
    CMD.CCS[8-12]=0 (Current Command Slot)
    CMD.FR[14]=1 (1=FIS receive running)
    CMD.CR[15]=0 (1=Command List running)
    CMD.HPCP[18]=0 (1=Hot Plug Capable Port)
    CMD.ATAPI[24]=0 (1=device is ATAPI)
    TFD - Task File Data=0x7f
    SIG - Signature=0xffffffff (received from device on first D2H register FIS)
    SSTS - SATA Status=0x4 (Device Detection[3:0]=4, Interface Speed[7:4]=0, Power Management[11:8]=0)
    SCTL - SATA Control=0x330 (DET[3:0]=0, SPD[7:4]=3, IPM[11:8]=3)
    SERR - SATA Error=0x0
    SACT - SATA Active=0x0 (bit string for max. 32 command slots)
    CI - Command Issued=0x0 (bit string for max. 32 command slots)


BTW how hard would sending ATA commands via AHCI compared to old PIO? When my program is already in pmode and I can map the MMIO, this is not problem in DJGPP. I didn't studied AHCI yet. Is the standard generic enough it would work then also for AMD AHCI and other manuf.?

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

>
> BTW how hard would sending ATA commands via AHCI compared to old PIO? When
> my program is already in pmode and I can map the MMIO, this is not problem
> in DJGPP.

Ok, but don't forget that you have to provide physical addresses for the DMA engines.

> I didn't studied AHCI yet. Is the standard generic enough it
> would work then also for AMD AHCI and other manuf.?

I think so. I tried my modified loew-driver on three AHCI machines ( 1 AMD, 2 Intel ),
and it worked on all three.

I'm still wondering how the BIOS of my "AHCI only without IDP"-machine manages HD access in v86-mode. How does it access the HBA registers without using unreal mode? I cannot imagine that it uses Int 15h, ah=87h or VCPI.

---
MS-DOS forever!

> Ok, but don't forget that you have to provide physical addresses for the
> DMA engines.

Do all ATA commands over AHCI requires use DMA? E.g. ATA identify or read/write a single sector? On old (S)ATA there was choice to use DMA commands except e.g. TRIM that requres strictly DMA.

> I'm still wondering how the BIOS of my "AHCI only without IDP"-machine
> manages HD access in v86-mode. How does it access the HBA registers without
> using unreal mode? I cannot imagine that it uses Int 15h, ah=87h or VCPI.

Maybe some SMM magic? What transfer rate you got cca under DOS?

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

> Do all ATA commands over AHCI requires use DMA? E.g. ATA identify or
> read/write a single sector? On old (S)ATA there was choice to use DMA
> commands except e.g. TRIM that requres strictly DMA.

There's no port address available in AHCI, so you can talk to the HBA in "DMA terms" only. The real communication between HBA and the device may be a different matter.

> Maybe some SMM magic? What transfer rate you got cca under DOS?

about 125 MB/sec int 13h read speed (using a seagate HD, dated 2013).

To access the memory mapped registers in real-mode I tried to temporarily "remap" the HBA ( by changing PCI config registers ), but that obviously "doesn't work". But the chipset perhaps may offer such an option.

---
MS-DOS forever!

> To access the memory mapped registers in real-mode I tried to temporarily
> "remap" the HBA ( by changing PCI config registers ), but that obviously
> "doesn't work". But the chipset perhaps may offer such an option.

Jack asked me to convey the following message:

> I am LAUGHING and APPALLED re: this AHCI "Thousand CLOWNS Show" on BTTR!

> Instead of "fumbling around" with re-mapping, or other schemes to handle
> AHCI memory-mapped registers, why don't you all REALIZE the following --

> * Memory-mapped I-O registers are at ADDRESSES in the 4-GB memory space!

> * So, they should be accessable using "regular" memory READS and WRITES!

> * A general-purpose READ/WRITE MEMORY handler can do so, IF it has logic
> capable of working either in real-mode OR in protected-mode.

> * ANY current driver dealing with XMS memory ALREADY HAS such a handler!

> Re: the noted "problem" of using "Int 15h, AH=87h" protected-mode calls,
> my usual 635-MB disk-to-disk file copy test with XHDD in real-mode gives
> an average 26.5 seconds on my PC. Exactly that same test in protected-
> mode (JEMM386 loaded) gives an average 27.4 seconds. Losing only 3% of
> time is a CHEAP PRICE to pay, for a real-mode AND protected-mode driver!

> Why don't you simply LIFT the 32-bit MOVE handler from your much-beloved
> HimemX driver (WITHOUT all of its "front-end" XMS error tests!), and put
> that handler into whatever AHCI driver you desire?? Should do the job.
> Similar logic has worked fine in ALL my caching drivers, for 13+ YEARS!!

> Jack R. Ellis

---
Glory to God for all things

> > I am LAUGHING and APPALLED re: this AHCI "Thousand CLOWNS Show" on BTTR!
>
> > Instead of "fumbling around" with re-mapping, or other schemes to handle
> > AHCI memory-mapped registers, why don't you all REALIZE the following --
>
> > * Memory-mapped I-O registers are at ADDRESSES in the 4-GB memory space!
>
> > * So, they should be accessable using "regular" memory READS and WRITES!
>
> > * A general-purpose READ/WRITE MEMORY handler can do so, IF it has logic
> > capable of working either in real-mode OR in protected-mode.
>
> > * ANY current driver dealing with XMS memory ALREADY HAS such a handler!

Thanks, Jack, for your kind remarks and suggestions! Very much appreciated!

---
MS-DOS forever!

> There's no port address available in AHCI, so you can talk to the HBA in
> "DMA terms" only.

What you means by "DMA terms" only? Is there involved some programming of legacy DMA controller? This part of PC HW I don't understand much.
My bare imagine was it works similar to e.g. NVidia GPU control that I played with NVclock - you simply have a bunch of MMIO registers, some memory buffer for data, so you fill the data, write some registers in memory and last you write some control reigister that triggers whole action...

> about 125 MB/sec int 13h read speed (using a seagate HD, dated 2013).

Nice, this is pretty decent speed in DOS. My MB reach ~90MB/s on SSD in IDE mode.

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

> > There's no port address available in AHCI, so you can talk to the HBA in
> > "DMA terms" only.
>
> What you means by "DMA terms" only? Is there involved some programming of
> legacy DMA controller?

No, no. With "DMA terms" I just meant: you have to setup one or two registers with physical addresses and then wait until everything is done - more or less that what you wrote about the NVidia GPU handling.

---
MS-DOS forever!