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
Impressum nach § 5 TMG