Thema: Diskette: int 13h im PM

[joachim_neu]

Vorteile:

- der Übertragungsvorgang verläuft automatisch
- du musst den Übertragungsvorgang nicht überwachen
- du kannst während der Übertragung andere Tasks an den Prozessor lassen

Nachteile:

- du kannst nur die unteren 16 MB im Speicher adressieren, sodass du in den meisten Fällen den Sektor in einen gesicherten Bereich kopieren und von dort aus dann in den Programmbereich kopieren musst

[SSJ7Gohan]

Man sollte auf jeden Fall DMA verwenden, das hat den Vorteil, das man wärend der Datenübertragung noch andere Sachen mit der CPU machen kann, und es viel schneller ist als PIO.
Man kann ja die ersten 16 MB für DMA reservieren, dann hat man kein Problem mit den 16 MB. Wenn diese 16 MB bereits voll sind, kann man ja immernoch PIO als Alternative benutzen. Selbst das kopieren in den oberen Speicherbereich ist eventuell schneller, da man beim kopieren in DWORDs verarbeiten kann, beim PIO kann man aber meist nur einzelne Bytes lesen.

[bitmaster]

Vielen dank, ich werde also DMA verwenden (ich arbeite sowieso im 16 Bit PM, also max. 16 MByte )

Aber was muss der Code des IRQ6 machen?

Danke!!!

[joachim_neu]

Man sollte auf jeden Fall DMA verwenden, das hat den Vorteil, das man wärend der Datenübertragung noch andere Sachen mit der CPU machen kann, und es viel schneller ist als PIO.
Man kann ja die ersten 16 MB für DMA reservieren, dann hat man kein Problem mit den 16 MB. Wenn diese 16 MB bereits voll sind, kann man ja immernoch PIO als Alternative benutzen. Selbst das kopieren in den oberen Speicherbereich ist eventuell schneller, da man beim kopieren in DWORDs verarbeiten kann, beim PIO kann man aber meist nur einzelne Bytes lesen.

Ich würds auch verwenden (tu ich auch ), auch, weil bei der Übertragung per DMA keine Daten verlohren gehen. Bei dem anderen kann es sein, dass, wenn der Task durch einen Taskwechsel unterbrochen wird (was fast immer so sein sollte), Daten verlohren gehen, weil der FDC sich nicht kümmert, ob seine Daten ankommen. (Soweit ich weiß...)

[Osbios]

Nicht wenn man es ordentlich programmiert.
Aber dann wird für jedes Byte ein Int aufgerufen was die ganze sache ja so langsam macht. Z. B. Win95 (glaube auch 98  ) benutzt kein DMA für die Floppy, das kann man auch gut erkennen wenn das System ausgelastet ist  nur weil man was mit der Floppy macht.

Damals bei "Betriebssystemen" wie Dos war das kein Problem denn man musste sowieso warten bis alle Daten gelesen oder geschrieben waren.
Aber bei Multitaskingsystemen kam erschwerend die komplexere Int  verarbeitung des PM hinzu.

Ich hab mal ausprobiert wie schnell eine fd daten lesen kann.
Für eine ganze fd benötigt ich 42 Sec.
1440 KB = 1474560 Byte
1474560 / 42 = ~35108 Ints. pro Sec.

[bitmaster]

OK, wie gesagt werde ich es auch mit DMA machen. Ich habe herausgefunden, dass der IRQ6 Code ledinglich zeigen soll das er aufgerufen wurde. Dies kann er z.B. in dem er den Wert 1 in einer Variable abspeichert. Dann kann man später mit cmp variable,1 prüfen ob der IRQ6 aufgerufen wurde. Dann habe ich auch herausgefunden das ich neun Bytes an dem 3F5h senden muss, um Sektoren schreiben/lesen zu können. Aber wie genau mach ich das jetzt mit DMA? Ich meine wo muss ich die Adresse angeben, wo er mir den Sektor hinkopieren soll?

Danke!!!

PS: Und warum gibt es zwei Controller?

[Osbios]

Um DMA zu benutzen musst du den DMA Chip ansprechen. Ich habe hier mal ein bisel Code meines "Treibers" herausgesucht, aber das meiste habe ich nur irgendwoher Copy&Past.  

Code: [Auswählen]

;DMA channel 0-3 command register
 mov al,00010100b
       ;|||||1=controller; 0=memory-to-memory
       ;||||1=compressed timing; 0=normal timing
       ;|||1=rotating priority; 0=fixed priority
       ;||1=extended write selection; 0=late write selection
       ;|1=DREQ sense active high; 0=low
       ;1=DACK sense active high; 0=low
 out 0x8,al

;DMA channel 0-3 mode register
 mov al,01010110b
       ;||||||XX:channel select 0..3
       ;||||XX:00=Verify transfer; 01=Write transfer; 10=Read transfer
       ;|||1=NonAutoinitialized
       ;||X:Address increment(0=+;1=-)
       ;XX:00=Demand mode; 01=Single mode; 10=Block mode; 11=Cascade mode
 out 0xB,al

 out 0xC,al ;DMA clear byte pointer flip-flop(only write something)

 mov eax,floppy_buffer+0x500 ;0x10000?
 out 0x4,al  ;linear @ 0-7
 shr eax,8
 out 0x4,al  ;linear @ 8-15
 shr eax,8
 out 0x81,al ;linear @ 16-23

 out 0xC,al ;DMA clear byte pointer flip-flop
 
 mov al,0xff
 out 0x5,al
 mov al,0x1
 out 0x5,al ;load 511 into count register (to read one sector)
 ; it should be noted that for multiple transfers, the
 ; second value output to port 05h is equivalent to
 ; (2*number of sectors)-1

 mov al,0x2
 out 0xa,al ;release channel 2

 ;enable DMA 1
 mov al,0x10
 out 0x8,al ;this is the value for enabling the DMA for the mode required

Zusätzlich muss man dem FDC noch sagen das er DMA benutzen soll:

Code: [Auswählen]

mov al,3;= Fix Drive Data
 call floppy_write
 mov al,0x0F
       ;  |x=head unload time
       ;  x = step rate
 call floppy_write
       
       ;head unload time
       ;|   1M  500k  300k  250k (Data Transfer Rate)
       ;0  128   256   426   512
       ;1    8    16  26.7    32
       ;2   16    32  53.3    64
       ;. ....  ....  ....  ....
       ;E  112   224   373   448
       ;F  120   240   400   480
       
       ;step rate
       ;|   1M  500k  300k  250k (Data Transfer Rate)
       ;0  8.0    16  26.7    32
       ;1  7.5    15  25.0    30
       ;2  7.0    14  23.3    28
       ;. ....  ....  ....  ....
       ;E  1.0     2   3.3     4
       ;F  0.5     1   1.7     2

       
 mov al,00000010b
       ;|||||||x 0=DMA 1=noDMA
       ;xxxxxxx = head load time
 call floppy_write
       
       ;head load time
       ; |   1M  500k  300k  250k (Data Transfer Rate)
       ; 0  128   256   426   512
       ; 1    1     2   3.3     4
       ; 2    2     4   6.6     8
       ;.. ....  ....  ....  ....
       ;7E  126   252   420   504
       ;7F  127   254   423   508
       


Das was da steht muss nicht umbeding Fehlerfrei sein, aber wir sollten alle Informationen zusammentragen um das Geheimniss FDC zu lüften.   : D

*denktübereingroßestuorialnach*

[bitmaster]

danke

Also der Obere Code zur DMA steht auch so in meinem PC Hardwarebuch. Das werde ich mir jetzt genaustens durchlesen. Das mit dem DMA an FDC: Und was ist mit der Funktion "floppy_write"?

*denktübereingroßestuorialnach*

Das wäre echt super.

Danke!!!

[joachim_neu]

*denktübereingroßestuorialnach*

Das wäre echt super.

So eins habe ich vor längerer Zeit einmal angefangen, mal sehen, ob ich das weitermache. Wenn jemand ein Tut schreiben will, kann ich ihm gerne meine Anfänge als Stütze geben.

[Osbios]

Also der Obere Code zur DMA steht auch so in meinem PC Hardwarebuch. Das werde ich mir jetzt genaustens durchlesen. Das mit dem DMA an FDC: Und was ist mit der Funktion "floppy_write"?

*denktübereingroßestuorialnach*

Das wäre echt super.

Danke!!!

Ich unterschlagen halt auch mal was.  

Code: [Auswählen]

floppy_write: ;data port=al
 push ax
 mov dx,0x3F4
 .loop1:
  in  al,dx
 and al,11000000b
 cmp al,10000000b
       ;|X:1=FDC to CPU; 0=CPU to FDC
       ;X :data reg ready
 jne .loop1

 inc dx
 pop ax
 out dx,al
ret

@joachim_neu:
Ja, alles was man an Infos sammel kann ist gut. Wenn es zu groß zum posten ist bitte als Email: osbios at web . de

Ich habe mir schon mal Gedanken über den Inhalt gemacht:

-BIOS Diskettenfunktionen
-Programmierbeispiele (Mit Ablaufdiagram?)
-Sonstiges (Tipps, Bugs, Besonderheiten, ...)
-Befehlsliste der BIOS-Funktionen

-direkte Programmierung des Diskettenlaufwerkkontrollers
-Kontroller Modele
-Register/Ports
-Interrupt
-DMA
-Programmierbeispiele (Mit Ablaufdiagram?)
-Sonstiges (Tipps, Bugs, Besonderheiten, ...)
-Befehlsliste für den FDC

Also eine ausführliche Dok. für Programmierer. Oder soll man gleich in die Vollen gehen und alles was man zu Floppys finden kann als THE ULTIMATIVFLOPPYDOKU titulieren? ^^

Auf jeden fall will ich auch solche sachen wie DMA soweit erklähren, dass man deren Benutzung im Zusammenhang mit der Floppy ohne extra Tuts verstehen kann.

Eventuell noch Ideen was fehlt?

[joachim_neu]

Wenn du schon DMA machst, dann auch richtig ausführlich. Du kannst es ja 2teilig machen, wenn du Lust hast. Erst DMA und dann FDC mit Benutzung von DMA.

[Osbios]

Ich habe schon darüber nachgedacht nicht alles in eine Dokumentation reinzustopfen, aber aus Sicht eines Programmierers der die Floppy programmieren will ist ein einzelne Dok. mit allen nötigen Infos natürlich nicht schlecht. Der Programmierer hat daduch auch mehr Übersicht, da z.B. für Floppy mit DMA nicht alles über DMA-Programmiererung enthalten sein muss.

Naja, dann werde ich micht mal selber ransetzn und ersteinmal Informationen zusammensuchen. Wenn ich einen besseren Überblick habe kann ich die einzelnen Bereiche besser abgrenzen.

[bitmaster]

Also ich wäre wirklich sehr dankbar für ein ausführliches Tutorial zu diesem Thema. Im Moment verstehe ich nämlich nur Bahnhof.

[bitmaster]

@[MM]: Also ich glaube das bei deinem Code irgendwie was fehlt. Z.b. bei motoroff. Wo wird denn da der Motor ausgeschalten? Und ca. 3 Sekunden wird dort auch nicht gewartet. motoroff_now verstehe ich ja aber motoroff nicht. Da felt doch was, richtig?

[joachim_neu]

Nur, um es mal gesagt zu haben:
Es ist theoretisch auch möglich, das RM Int 13 im PM weiterzuverwenden. Wie? Nun, man macht sich einen Task, schaltet den in den VM86, mappt ihm alles, wie ers im RM hätte und öffnet die notwendigen FDC-Ports im IO-Bitmap des TSS. So kann ein RM-Treiber in einem emulierten RM weiterhin die RM-Ints benutzen und man erspart sich das Programmieren.

[bitmaster]

Nur, um es mal gesagt zu haben:
Es ist theoretisch auch möglich, das RM Int 13 im PM weiterzuverwenden. Wie? Nun, man macht sich einen Task, schaltet den in den VM86, mappt ihm alles, wie ers im RM hätte und öffnet die notwendigen FDC-Ports im IO-Bitmap des TSS. So kann ein RM-Treiber in einem emulierten RM weiterhin die RM-Ints benutzen und man erspart sich das Programmieren.

Das will ich aber nicht.

[Jidder]

Nur, um es mal gesagt zu haben:
Es ist theoretisch auch möglich, das RM Int 13 im PM weiterzuverwenden. Wie? Nun, man macht sich einen Task, schaltet den in den VM86, mappt ihm alles, wie ers im RM hätte und öffnet die notwendigen FDC-Ports im IO-Bitmap des TSS. So kann ein RM-Treiber in einem emulierten RM weiterhin die RM-Ints benutzen und man erspart sich das Programmieren.

ich kenn eine einfachere methode: man schreibt einen RM-Code->PM-Code konverter, der auf binärcode-ebene arbeitet. den jagt man dann vor dem ersten benutzen des int 13h über eben diesen rüber. dann muss man den interrupt nur noch in die IDT eintragen. so einfach ist das

[bitmaster]

Hi,

ich habe noch eine Frage. Ich kann mit dem 3F4h und 3F7h die Datenrate einstellen. Aber was ist da der unterschied bzw. wann sollte ich welches Register benutzen.

Danke!!!

[joachim_neu]

Nur, um es mal gesagt zu haben:
Es ist theoretisch auch möglich, das RM Int 13 im PM weiterzuverwenden. Wie? Nun, man macht sich einen Task, schaltet den in den VM86, mappt ihm alles, wie ers im RM hätte und öffnet die notwendigen FDC-Ports im IO-Bitmap des TSS. So kann ein RM-Treiber in einem emulierten RM weiterhin die RM-Ints benutzen und man erspart sich das Programmieren.

Das will ich aber nicht.

Ich habs nur der Vollständigkeit wegen gesagt. Es soll ja auch andere Leute geben, die vor dem Problem stehen (werden) und die Such-Funktion benutzen.

Nur, um es mal gesagt zu haben:
Es ist theoretisch auch möglich, das RM Int 13 im PM weiterzuverwenden. Wie? Nun, man macht sich einen Task, schaltet den in den VM86, mappt ihm alles, wie ers im RM hätte und öffnet die notwendigen FDC-Ports im IO-Bitmap des TSS. So kann ein RM-Treiber in einem emulierten RM weiterhin die RM-Ints benutzen und man erspart sich das Programmieren.

ich kenn eine einfachere methode: man schreibt einen RM-Code->PM-Code konverter, der auf binärcode-ebene arbeitet. den jagt man dann vor dem ersten benutzen des int 13h über eben diesen rüber. dann muss man den interrupt nur noch in die IDT eintragen. so einfach ist das

Das wird nicht so einfach sein. Du musst die ganzen Adressen neu berechnen und den Code manipulieren. Außerdem musste (wie schon gesagt) alles von 16 bit zu 32 bit bringen. Da finde ich das andere einfacher, auch, weils sicherer ist.

[SSJ7Gohan]

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.