Thema: Diskette: int 13h im PM

[joachim_neu]

Ich würde generell vermeiden, den VM86 Mode zu nutzen, und ihn nur dann nutzen, wenn es unbedingt nötig ist (VESA Framebuffer z.B.). Er ist unportabel (x86_64 unterstützt ihn nicht mehr), switches zurück in den Realmode sind leichter, und das BIOS ist meistens auch nicht gerade bugfrei.

1. Wenn du nach Portabilität gehst, kannst du den PM vergessen, den gibt es auch nicht in 64Bit-Ausführung. Da musst du deinen Kernel eh umschreiben (GDT, IDT, ...)
2. Kann man doch nicht für einen Treiber in den RM wechseln. Wo kommen wir da hin, dann könnte jeder Treiber die volle Macht übers System übernehmen.
3. Ich denke das BIOS ist bugfreier als der Code, den wir produzieren...

[bitmaster]

Ich würde generell vermeiden, den VM86 Mode zu nutzen, und ihn nur dann nutzen, wenn es unbedingt nötig ist (VESA Framebuffer z.B.). Er ist unportabel (x86_64 unterstützt ihn nicht mehr), switches zurück in den Realmode sind leichter, und das BIOS ist meistens auch nicht gerade bugfrei.

1. Wenn du nach Portabilität gehst, kannst du den PM vergessen, den gibt es auch nicht in 64Bit-Ausführung. Da musst du deinen Kernel eh umschreiben (GDT, IDT, ...)
2. Kann man doch nicht für einen Treiber in den RM wechseln. Wo kommen wir da hin, dann könnte jeder Treiber die volle Macht übers System übernehmen.
3. Ich denke das BIOS ist bugfreier als der Code, den wir produzieren...

Das sehe ich ganz genau so.

[SSJ7Gohan]

1. Naja, stimmt, wie der Kernel intern aufgebaut ist, ist egal. Und ob ich jetzt in den RM wechsele oder den VM86 Mode nutze ist dafür auch egal.
2. Ja, stimmt, das ist ein Vorteil des VM86 Modes. Allerdings ist der VM86 Mode auch nicht sehr sicher, ausser wenn du sehr viel emulierst. Du weißt z.B. nicht, auf welche Ports das Video-BIOS zugreifen muss, um VBE einzuschalten, daher musst du den Zugriff auf alle Ports erlauben, wodurch auch jeder Treiber die volle Macht übers System übernehmen könnte. (Über APM das System ausschalten usw.)
3. Naja, wenn in unserem Code Bugs sind, können wir sie beheben, beim BIOS müssen wir uns darauf verlassen, das alles klappt. Ausserdem will ich nicht alles vom BIOS machen lassen, sondern meine eigenen Treiber benutzen, ausser wenn es halt nicht möglich ist.

[joachim_neu]

2. Ja, stimmt, das ist ein Vorteil des VM86 Modes. Allerdings ist der VM86 Mode auch nicht sehr sicher, ausser wenn du sehr viel emulierst. Du weißt z.B. nicht, auf welche Ports das Video-BIOS zugreifen muss, um VBE einzuschalten, daher musst du den Zugriff auf alle Ports erlauben, wodurch auch jeder Treiber die volle Macht übers System übernehmen könnte. (Über APM das System ausschalten usw.)

Das kannst du einfach herausfinden. Du sperrst alle Ports und lässt dir von den auftretenden Protected Faults zeigen, auf welche Ports zugegriffen wird. Die kannst du dann beim nächsten Durchlauf aufmachen, bis keine Faults mehr auftreten.

[SSJ7Gohan]

Die Ports, auf die zugegriffen wird können aber je nach System unterschiedlich sein.

[Osbios]

2. Ja, stimmt, das ist ein Vorteil des VM86 Modes. Allerdings ist der VM86 Mode auch nicht sehr sicher, ausser wenn du sehr viel emulierst. Du weißt z.B. nicht, auf welche Ports das Video-BIOS zugreifen muss, um VBE einzuschalten, daher musst du den Zugriff auf alle Ports erlauben, wodurch auch jeder Treiber die volle Macht übers System übernehmen könnte. (Über APM das System ausschalten usw.)

Also meines Wissens nach haben Treiber in den meisten Betriebssystemen sowieso die volle Kontrolle über das System.

Das kannst du einfach herausfinden. Du sperrst alle Ports und lässt dir von den auftretenden Protected Faults zeigen, auf welche Ports zugegriffen wird. Die kannst du dann beim nächsten Durchlauf aufmachen, bis keine Faults mehr auftreten.

Wofür sollte man dann noch Ports sperre, wenn man sowieso alle Ports sofort wieder freigibt wenn sie benutzt werden?

[Legend]

2. Ja, stimmt, das ist ein Vorteil des VM86 Modes. Allerdings ist der VM86 Mode auch nicht sehr sicher, ausser wenn du sehr viel emulierst. Du weißt z.B. nicht, auf welche Ports das Video-BIOS zugreifen muss, um VBE einzuschalten, daher musst du den Zugriff auf alle Ports erlauben, wodurch auch jeder Treiber die volle Macht übers System übernehmen könnte. (Über APM das System ausschalten usw.)

Also meines Wissens nach haben Treiber in den meisten Betriebssystemen sowieso die volle Kontrolle über das System.

Ja, in Linux sowieso und in Windows haben es auch die meisten. Das ist aber kein Zeichen von einem gutem (möglichts stabilem) Kerneldesign (auch wenn es ein paar wenige % Performance bringt).

[elfish_rider]

Ich habe oft gelesen, dass man DMA nicht benutzen sollte. Ich verstehe aber nicht warum. Hat das einen Nachteil? Geht das überhaupt ohne?

Das interessiert mich auch! Welches Register müsste man dann auslesen, um über P I/O an Daten zu kommen? 0x03F5?

[SSJ7Gohan]

Naja, DMA ist recht langsam (maximal 4MB/s) und kann nur die ersten 16 MB addressieren, er ist aber besser für Multitasking Umgebungen geeignet (wärend die Daten übertragen werden, kann die CPU was anderes machen.) und AFAIK kommt man beim FDC nicht um den DMA rum.

[joachim_neu]

2. Ja, stimmt, das ist ein Vorteil des VM86 Modes. Allerdings ist der VM86 Mode auch nicht sehr sicher, ausser wenn du sehr viel emulierst. Du weißt z.B. nicht, auf welche Ports das Video-BIOS zugreifen muss, um VBE einzuschalten, daher musst du den Zugriff auf alle Ports erlauben, wodurch auch jeder Treiber die volle Macht übers System übernehmen könnte. (Über APM das System ausschalten usw.)

Also meines Wissens nach haben Treiber in den meisten Betriebssystemen sowieso die volle Kontrolle über das System.

Heißt nicht, dass wir so dumm sein müssen, und es auch machen.

Das kannst du einfach herausfinden. Du sperrst alle Ports und lässt dir von den auftretenden Protected Faults zeigen, auf welche Ports zugegriffen wird. Die kannst du dann beim nächsten Durchlauf aufmachen, bis keine Faults mehr auftreten.

Wofür sollte man dann noch Ports sperre, wenn man sowieso alle Ports sofort wieder freigibt wenn sie benutzt werden?

Warum alle freigeben? Man gibt nur die frei, die gebraucht werden.

Die Ports, auf die zugegriffen wird können aber je nach System unterschiedlich sein.

Nein, FDC und DMA gehen immer über die gleichen Ports (zumindest bei x86), oder hast du schonmal was anderes gesehen? Und wenn: Wie soll man dann herausfinden, wo die sich verstecken?

[SSJ7Gohan]

Das bezog sich nicht auf DMA und FDC, sondern auf VBE.

[joachim_neu]

Achso, ja, das kann sein. Aber wenn man VESA im RM mit LFB aktiviert, dann braucht man dafür eg. nichtmehr zurück in den RM.

[bitmaster]

Also ich komm da einfach nicht weiter. Ich habe alles mögliche versucht, aber nicht funktioniert. Das einzige was funktioniert ist: Motot an und Motor aus. Aber ich möchte jetzt aus testzwecken nur einen Sektor (Sektor 4, sprich den dritten Sektor) mit Daten beschreiben. Aber VMware zeigt mir eine Fehlermeldung an und Bochs macht gar nichts mehr. Der Sektor wurde auch nicht beschrieben. Was mache ich da falsch? Hier mein Code:

Code: [Auswählen]

xor al,al
call fdc_activate_motor
mov bl,0Fh
call fdc_sendbyte
xor bl,bl
call fdc_sendbyte
xor bl,bl
call fdc_sendbyte
mov bl,01h
call fdc_wait
xor cl,cl
mov dx,07C0h
xor bx,bx
call dma_xfer ;bis hier mache ich glaube ich alles richtig
mov bl,0C5h ;jetzt komt der Fehler
call fdc_sendbyte
xor bl,bl
call fdc_sendbyte
xor bl,bl
call fdc_sendbyte
xor bl,bl
call fdc_sendbyte
mov bl,03h
call fdc_sendbyte
mov bl,02h
call fdc_sendbyte
mov bl,18
call fdc_sendbyte
mov bl,1Bh
call fdc_sendbyte
mov bl,0FFh
call fdc_sendbyte
xor bl,bl
call fdc_wait
jmp $

Hier mal die Funktionen von denen ich ausgehe das dort ein Fehler sein kann:

Code: [Auswählen]

;input:  bl, 0=ohne sensei, 1=mit sensei
;output: -
fdc_wait proc near
cmp irq6_done,1
jne fdc_wait
pusha
push bx
cli
mov cx,0007h
fdc_wait_loop:
mov dx,03F4h
in al,dx
and al,10h
or al,al
jz fdc_wait_weiter
dec cx
jz fdc_wait_weiter
call fdc_getbyte
jmp fdc_wait_loop

fdc_wait_weiter:
pop bx
or bl,bl
jz fdc_wait_no_sensei
mov bl,08h
call fdc_sendbyte
call fdc_getbyte
call fdc_getbyte
fdc_wait_no_sensei:

mov irq6_done,0
sti
popa
ret
fdc_wait endp

Code: [Auswählen]

;input:  bl = Byte das gesendet werden soll
;output: -
fdc_sendbyte proc near
pusha
mov cx,0080h
mov dx,03F4h
fdc_sendbyte_loop:
in al,dx
and al,0C0h
cmp al,80h
jne fdc_sendbyte_weiter
mov dx,03F5h
mov al,bl
out dx,al
popa
ret
fdc_sendbyte_weiter:
in al,80h
loop fdc_sendbyte_loop
popa
ret
fdc_sendbyte endp

Code: [Auswählen]

;input:  -
;output: bl = Byte aus dem Datenregister
fdc_getbyte proc near
push ax
push cx
push dx
mov cx,0080h
mov dx,03F4h
fdc_getbyte_loop:
in al,dx
and al,0D0h
cmp al,0D0h
jne fdc_getbyte_weiter
mov dx,03F5h
in al,dx
mov bl,al
pop dx
pop cx
pop ax
ret
fdc_getbyte_weiter:
in al,80h
loop fdc_getbyte_loop
pop dx
pop cx
pop ax
ret
fdc_getbyte endp
Es wäre wirklich nett wenn ihr euch das mal anschaut. Ich finde den Fehler einfach nicht.

Danke!!!

[bitmaster]

So, ich habe es nun entlich geschafft. Es funktioniert. Ich hatte das lesen/schreiben beim DMA Code vertauscht und den Kopf nicht zur richtigen Spur positioniert. Also wunderbar alles funktioniert. Aber jetzt habe ich immer noch ein kleines Problem. Was ist wenn jemand eine nicht 1,44 MByte Diskette mit meinem OS benutzen will? Würde es dann abstürtzen? Also im RM macht der int 13h das ja alles automatisch (außer natürlich die Anzahl der Heads, Sectors a Track usw.). Aber ich muss dem FDC genau die Formate angeben die er zu lesen hat. Also bitte ich um Informationen der verschiedenen Diskettenformate. Z.B. Wird bei 1,44 MByte als Länge der GAP3, 1Bh angegeben. Wie heißt es bei den anderen Formaten. Welche Datenrate brauchen die Formate? Wann kommt FM und wann MFM zu tragen? Also im Prinzip würde ich gerne alle Informationen über den Verschiedensten Diskettenformaten (natürlich nur die für den PC) haben. Danke!!!

bitmaster

[bitmaster]

Code: [Auswählen]

@fdd_login(){
        push    cx
        str     cx
        ; Schon eingeloggt:
        cmp     [fdd_data_user],cx
        jz      .is_logged_in
        cli     ; Keine Interrupts, damit jetzt kein Taskwechesl kommt.
        ; Nein, ist das FDD frei:
        cmp     word ptr [fdd_data_user],0
        jnz     .error
        mov     [fdd_data_user],cx
        sti
        mov     dword ptr [fdd_login_count],0
        pop     cx
        mov     cl,1
        ret
.is_logged_in:
        inc     dword ptr [fdd_login_count]
        pop     cx
        mov     cl,1
        ret
.error:
        sti
        pop     cx
        xor     cl,cl
        ret
}

Und was ist wenn genau nach dem jz      .is_logged_in (bedingung nicht erfüllt) ein Taskwechsel stattfindet? Also das cli erst gar nicht ausgeführt wird?

bitmaster

[bitmaster]

MFM ist gültig bei High Density Disks, oder? Was macht das Bit7 beim schreib/lese Befehl? In einem Doku steht das dann die gewünschte Operation auf beiden Seiten ausgeführt wird. Aber es wird nicht von beiden Seiten gelesen/geschrieben obwohl ich das Bit7 gesetzt habe. Wäre auch irgendwie unlogisch. Aber wofür ist Bit7 denn dann wirklich?

bitmaster

[bitmaster]

Hallo,

wie gesagt funktioniert eigentlich alles. Nur habe ich festgestellt, dass es beim echten PC ziemlich langsam ist (das lesen und schreiben vom/auf Diskette). Also unter den Emulatoren läuft es ziemlich schnell bzw. normal. Aber wenn ich es auf einem wirklichen PC ohne Emulator laufen lasse, dauern 64 KByte lesen oder schreiben ca. 1,5 Minuten. Das ist viel zu lange. Auch hört man das Laufwerk kaum gegenüber das lesen im RM mit dem int 13h. Muss ich eigentlich bei jedem lesen/schreiben eines Sektors das Laufwerk rest(en)? Muss ich auch jedes mal die Drive-Timings setzten? Ich warte auch nirgendwo die 1/2 sekunden. Muss man das unbedingt? Warum und wo genau?

Danke!!!

bitmaster