DOS ain't dead

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

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

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

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

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

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