Probleme bei IDE-Platten >504MB
Grund warum MS-DOS nicht ohne Hilfe (=LBA) mit (E)IDE-Platten >504MB klarkommt:
-------------------------------------------------------------------------------
Das Problem ist schnell erklärt. Man kauft sich eine Festplatte, z.B. eine
1GB Festplatte, schließt sie an, trägt sie ins BIOS-SETUP ein (oder verwendet
AUTODETECT, ganz egal), startet FDISK zum partitionieren und bemerkt:
FDISK erkennt nur 504MB (=528482304 Bytes), mehr eben nicht !
Woran liegt das nur ?
MSDOS geht bei der Ansteuerung der (E)IDE-Festplatte über den BIOS-Interrupt
INT13h. Dieser INT13h schafft aus historischen Gründen maximal folgende
Parameter: 1024 Zylinder / 255 Köpfe / 63 Sektoren
(10bit) (8bit) (6bit)
Wie man erahnen kann wurden bei der Konzeption des BIOS seitens von IBM zwei
Bits bei den Sektoren geliehen und bei den Zylindern verwendet. Mit diesen
maximalen Parameterwerten muß MSDOS nun auskommen. Kein Problem, wie folgende
Rechnung belegt:
1024 * 255 * 63 * 512 Bytes = 8422686720 Bytes = ca. 8 GigaBytes
MSDOS kann also 8GB verwalten, warum macht es dann bei (E)IDE-Platten bereits
bei 504MB schlapp und bei anderen Platten (beispielsweise SCSI) gehen 8GB ?
Der Grund liegt bei den IDE und EIDE Platten selbst:
Eine (E)IDE-Platte verhält sich dem System gegenüber wie eine MFM-Festplatte.
Das bedeutet, daß der sich auf der Platte befindliche Controller register-
kompatibel ist zu einem alten MFM-Controller namens "WD-1003" von Western
Digital. Diese Registerkompatibilität hat nun aber folgende Begrenzungen:
65535 Zylinder, 16 Köpfe, 255 Sektoren
(16bit) (4bit) (8bit)
Vergleicht man nun die MSDOS-Begrenzung mit der WD1003-Begrenzung ergibt sich:
MS-DOS: 1024 / 256 / 63
WD1003: 65535 / 16 / 255
-------------------------
KGN : 1024 / 16 / 63
Rechnen wir nun mit diesem "Kleinsten Gemeinsamen Nenner" (KGN) dann folgt:
1024 * 16 * 63* 512 Bytes = 528482304 Bytes = 504 MegaBytes
So errechnet sich diese MSDOS-(E)IDE Grenze.
Die Lösung des Problems kann besteht nun in einem kleinem Trick namens LBA.
Beim Logical Block Adressing bekommt jeder Sektor eine Nummer. Somit entfällt
die physikalische Aufteilung in Cylinder/Heads/Sectors (CHS) und weicht einer
logischen Aufteilung. Dem DOS gegenüber kann somit über INT13h somit wieder
eine Platte mit 1024/256/63 (C/H/S) vorgegaukelt werden und 8GB sind somit
die endgültige Obergrenze.
Den LBA-Modus kann man auf drei Arten in seinem System integrieren:
1.) Das BIOS-SETUP selbst besitzt diesen Modus bereits, dann muß man ihn
lediglich einschalten (enable).
2.) Man kauft einen EIDE-Controller MIT (!!!) eigenem BIOS auf dem dann LBA
mitgeliefert wird.
3.) Man installiert einen LBA-fähigen Treiber, welcher im Bootsektor der
Festplatte verankert wird und der sich beim Booten des Rechners immer ins
RAM lädt (ähnlich wie ein Bootsektor-Virus das auch macht), dann
sich in den INT13h einklinkt um diesen entsprechend zu modifizieren.
LBA-Erweiterungen sind beispielsweise "EZ-DRIVE" oder "ONTRACK"
Beim LBA-Modus muß allerdings beachtet werden, daß die verwendete
Festplatte ebenfalls den LBA-Modus unterstützt. Wenn dem nicht so ist, dann
kommt das BIOS auch nicht im LBA-Modus an die Platte ran. Hierfür gibt es bei
manchen BIOSsen einen Spezialmodus namens LARGE oder EXTENDEND (XCHS). Der
Unterschied zu Standard-CHS besteht darin, daß die Platte zwar über ihre
CHS-Einteilung angesprochen wird, das BIOS aber extra für DOS eine Umrechnung
auf eine andere CHS-Einteilung vornimmt (Translation). In diesem Falle würde
aus einer 2038/16/63 Platte (physikalisch) eine 1019/32/63 Platte (für DOS)
werden.
MSDOS hat das Problem also nur mit IDE- und EIDE-Platten. Bei der Verwendung
von SCSI übernimmt der SCSI-Controller den INT13h und hat damit das Ruder
selbst in der Hand !
Andere Betriebssysteme wie OS/2, LINUX, WINDOWS NT, etc. haben diese Probleme
nicht, da sie den INT13h erst gar nicht benutzen. Diese Systeme laufen
vollkommen im 386-Protected Mode (ab 80386SX) und können damit sowieso
auf keine einzige BIOS-Funktion zurückgreifen (wg. einer vollkommen anderen
Adressierungsart des Prozessors)
Fragen oder Kritik richten Sie bitte privat an: tramp@pipeline.rhein-neckar.de
TRAMP findet man in folgenden NewsGroups: de.comp.sys.ibm-pc und z-netz.rechner.ibm.hardware
zurück zur TRAMPs Info Homepage