Thema: Problem mit E820h

[gäppeldonger]

Nachdem ich schon lange in der tiefsten Softwareebene rumbuddeln wollte, habe ich nach längeren Übungen mit C und einigen Lektüren über Assembler beschlossen, ans Eingemachte zu gehen.

Laut versch. Dokumentationen soll die BIOS-Funktion INT 15h, AX=E820 von jedem neueren Computer unterstützt werden. Ich bekomme aber immer nach dem Aufruf ein gesetztes Carry-Flag.

Bochs scheint es noch nicht zu unterstützen (so schreibt er's zumindest immer in sein Log), ein älteres Board mit P4 und ein ganz neues mit Dual Core spucken das gleiche Ergebnis aus.

Wo ist der Fehler? 

P.S.: Ich lade dieses kleine Programm direkt als Bootsektor von der Diskette...

Code: [Auswählen]

[BITS 16]
[ORG 0]

mov ax, 7C0h
mov ds, ax
mov ax, 500h
mov es, ax
xor di, di

mov eax, 0E820h
xor ebx, ebx
mov ecx, 20
mov edx, 'SMAP'
int 15h

jc failed
mov edx, 'WIN '
jmp short weita

failed:
mov edx, 'FAIL'

weita:
call printEdx

ende:
xor ah, ah
int 0x16
int 0x19

printEdx:
push ebx
push eax

mov ah, 0Eh
mov bx, 07h

mov al, dl
int 10h
mov al, dh
int 10h

shr edx, 16

mov al, dl
int 10h
mov al, dh
int 10h

pop eax
pop ebx

ret

TIMES 510-($-$$) db 0x00
dw 0xAA55


[Jidder]

Hi, und willkommen an Board

Du lädst edx nicht korrekt. Es muss darin 0x534D4150 stehen.

Deine Methode das als String ('SMAP') zu übergeben scheitert, weil bei einem String die Endianess nicht anwendbar ist. (Das ist keine Multibyte-char-Konstante aus C, wo das evtl. anders ist.) Es kommt bei dir dann 0x50414d53 raus, was 0x534D4150 rückwärts ist.

[gäppeldonger]

Oh, auf den Gedanken bin ich garnicht gekommen, obwohl ich mit dem Endian-Problem bereits zuvor mit meiner Prozedur zur Ausgabe des Registerinhalts zutun hatte.

SMAP durch PAMS ersetzt und siehe da, es steht WIN... Vielen Dank!

Aber warum werden in vielen Beschreibungen die ASCII-Strings benutzt, wenn in x86 doch wieder alles verkehrt rum interpretiert wird - und diese BIOS-Funktionen werden obendrein nur in x86 benutzt?

[Jidder]

Eigentlich ist nicht x86 das Problem, sondern der Assembler. Der entscheidet ja, was er aus den Strings macht. Warum der das allerdings so macht, weiß ich auch nicht

[gäppeldonger]

Ich kann mir nicht vorstellen, dass NASM da was falsch macht.

Vorallem, hatte ich dieses Problem erst bei dieser Funktion, während ich z.B. bei VBE ("VESA"), BIOS32 Service Directory ("_32_") und PCI ("$PCI") dieses Problem nicht hatte.
Alle drei Signaturen sind so gespeichert, sodass das erste Char im niederstwertigen Byte und das letzte Char im höchstwertigen Byte sitzt. Sprich, die Signaturen werden als 32-bit Integer behandelt, nicht als 8-bit String (wie bei "SMAP")...