\documentclass[11pt,a4paper]{article} % save as utf-8-emacs-unix % language support \usepackage[german]{babel} %\usepackage{german} \usepackage[utf8]{inputenc} % can use Umlauts now ü instead of "u \usepackage{url} % \url{} \path{} with correct "hyphenation" \parindent=0pt \begin{document} \title{Bootmanager und FAT--Reparatur: Neunter Fort(h)schritt (Diskimage in RAMD--Datei)} \shorttitle{Bootmanager und FAT--Reparatur} \author{Fred Behringer} \maketitle \begin{abstract}\itshape 3.5--HD--Disketten sollen `am Stück' hexadezimal ins RAM geschrieben werden, und zwar (zur zwischenzeitlich möglichen Weiterverarbeitung) gleich in eine Datei innerhalb einer RAM--Disk. Die Adressen werden linear (32--Bit--breit) beansprucht, alle Vorgänge laufen aber im puren Real--Modus ab. Ein Abstecher in den Protected--Mode (wie noch seinerzeit in [FB98] als Allheilmittel gegen die 64--K--Segmentierung vorgesehen) ist nicht nötig. \end{abstract} \begin{multicols}{2} % -------------------------------------------------------------------- \section{Ziel} \label{sec:Ziel} Der vorliegende Teil 9 meiner Artikelserie stützt sich stark auf Teil 8 (siehe [FB09]). Es ging und geht um das sektorweise Zwischenspeichern des Inhalts einer 3.5--HD--Diskette in Hexform ins `Extended--RAM' --- mit der Absicht, im RAM Änderungen vorzunehmen, um dann das modifizierte Disketten--Image auf dieselbe oder auf eine andere Diskette zurückzuschreiben. Natürlich könnte man das auch mit einem Hex--Edit--Programm von der Sorte machen, wie es sie auch für DOS schon immer gegeben hat ([CP88], [CW99], [MK92]). Leicht irritiert ist man eben nur, wenn man überraschend z.B. die Meldung `Keine DOS--Diskette' bekommt und wenn der `professionelle' Hex--Editor dann aussteigt. (In Teil 4 der Artikelserie (siehe [FB09]) wurde ein praktischer Anlass diskutiert.) Was tun? Man besinnt sich auf Forth und weiß: Forth kann alles. Ganz schnell und wunderbar interaktiv. Und der Lerneffekt ist groß! Wo man sich in einer puren Assembler--Umgebung nicht ans Werk wagen würde, traut man sich das in Forth ohne Weiteres zu. Natürlich in Mischung aus High--Level-- und Low--Level--Forth. \section{Disketten `beamen'} \label{sec:disketten-beamen} Das Wiederzurückschreiben auf Diskette soll im Vorliegenden abermals auf einen späteren Artikel verschoben werden. Für diesmal liegt mir die Möglichkeit am Herzen, das (nach dem Vorgehen in Teil 8 hergestellte) Disketten--Image als Datei (z.B. nach Amerika ;-) zu versenden. \section{Voraussetzungen} Ich gehe von einem PC--Kompatiblen mit einer CPU von mindestens dem Typ 80486 und mit DOS als Betriebssystem aus. Für meine Experimente verwende ich ein System mit einem AMD--K6--2/500 als CPU und mit 392192 KB an RAM. Meine Arbeiten habe ich mit DOS 6.2 --- aber auch unter dem DOS--Prompt von Windows 95 (DOS 7.0) --- durchgeführt. Von den zu verarbeitenden Disketten verlange ich, dass sie mit 80d Spuren zu je 2 Seiten mit 18d Sektoren/Spur und 512d Bytes/Sektor formatiert sind. Ansonsten wird kein Einhalten bestimmter Disketten--Parameter verlangt. Insbesondere braucht es sich durchaus nicht um DOS--Disketten zu handeln --- ja, der Bootsektor (mit den Disk--Parametern) darf sogar weitestgehend leer sein. Das Forth--Programm (Turbo--Forth und meine Entwicklungen bis Teil 8) laufen von der Festplatte, die also eine DOS--Partition enthalten muss, von welcher zu booten ist. (Turbo--Forth braucht keine großen Ressourcen. Man könnte sich also auch überlegen, den Computer von Diskette zu booten.) Das BIOS muss den erweiterten Interrupt 13h bedienen können. In der \texttt{config.sys} müssen sich \texttt{himem.sys} und \texttt{ramdrive.sys} befinden. (Der RAM--Disk--Treiber kann auch anders heißen, muss aber natürlich mit dem verwendeten DOS verträglich sein. Ich habe auch Experimente mit FreeDOS und anderen DOS--Systemen gemacht. Geht prima!) Sämtlichen Programmteilen aus Teil 8 und aus dem hier Gesagten liegt die Zahlenbasis \texttt{hex} zugrunde. \section{RAM--Disk?} Ich arbeite vorwiegend mit einer RAM--Disk von 30 MB. Für das Vorliegende wäre 1,44 MB ausreichend. Es muss halt eine Datei mit dem Hex--Dump einer vollen 3.5--HD--Diskette hineinpassen. \section{Welches Forth?} Ich gehe von Turbo--Forth in der 16--Bit--Version aus ([MP87]). Diejenigen Forth--Worte aus Teil 8, die (neben Turbo--Forth) im Vorliegenden gebraucht werden, habe ich in einem `Glossar' (siehe gleich) zusammengestellt. Es sind wenige Dinge, die nicht auch unter ZF formuliert werden könnten. Schwierigkeiten würde bei ZF eigentlich nur das komfortable Anzeige--Wort \texttt{dump-32} aus [FB98] und (mit leichter Verbesserung) aus Teil 8 machen. (Ich schreibe alle Forth--Worte klein, was in Turbo--Forth ohne Weiteres erlaubt ist.) Der Einfachheit halber lasse ich ZF im Vorliegenden aus dem Spiel. \section{Grundsätzliches Vorgehen} \begin{enumerate} \item Man lege in der RAM--Disk eine Datei von mindestens der Größe 1,44 MB an. \item Am besten geeignet ist eine Text--Datei. Andere Formen tun es auch. \item Wo finde ich unter DOS eine so große Datei? Im Repository der VD. Von dort hole ich mir regelmäßig die aktuellste Version der PDF--Datei mit dem gerade in Bearbeitung befindlichen VD--Heft für die Vorschläge meiner Artikel--Korrekturen ab. Die PDF--Datei vom 27.5.2011 hat eine Länge von 2232137 Byte. Da passt das Disketten--Image einer 3.5--HD--Diskette prima hinein. \item Mit Hilfe der Angaben in [MA89] könnte ich mir die benötigten Parameter der RAM--Disk aus deren Bootblock heraussuchen. Ich könnte das auch mit PCTOOLS [CP88] machen, aber eben auch mit meinem \texttt{dump-32} aus Teil 8. \item Könnte! Ich kann es aber auch rein überschlagsmäßig angehen. Und das habe ich getan: Die RAM--Disk beginnt hexadezimal bei \texttt{100000.} (1048576. dezimal). \texttt{100000.} ('Punktzahl'!) ist genau die Hex--Adresse des ersten Bytes des Extended--Memorys. Expanded--Memory sei im Vorliegenden ignoriert. Das in die RAM--Disk zu legende Disketten--Image hat eine Länge von 168000h (= 1474560) Bytes. Ich muss dafür sorgen, dass der Bootblock der RAM--Disk einerseits und der Vorspann der (für das Disketten--Image als Container missbrauchten) PDF--Datei andererseits für den beabsichtigten Kopiervorgang erhalten bleiben. Wenn ich also statt mit 100000h mit 150000h anfange, liege ich ganz bestimmt auf der sicheren Seite. Das habe ich nachgeprüft. Geht bestens! \item Ich bin also mit \texttt{150000. getdiskimage} in die zweckmissbrauchte PDF--Datei auf der RAM--Disk hineingegangen und war und bin sicher, dass ich damit das (eventuell modifizierte) Disketten--Image beliebig auf Festplatte, Zip--Diskette oder USB--Stick (der Panasonic--USB--Treiber --- siehe gleich --- läuft bei mir unter DOS und Windows 95 bestens) abspeichern und später wieder hereinholen kann --- ganz einfach dadurch, dass ich die (als Container missbrauchte) PDF--Datei hin und her kopiere. \item In [MA89] wird darauf hingewiesen, dass man in den Bytes 1eh und 1fh des Bootblocks der RAM--Disk (dort nur 128 KB) das Ende der RAM--Disk (in KB) findet und sich durch Hochsetzen des dort gefundenen Wertes einen von der generellen Speicherverwaltung respektierten RAM--Bereich `sichern' kann. Ich habe das hier nicht nötig: Durch Abspeichern in eine Datei, die als `Container' für das Disketten--Image betrachtet werden kann, ist der von mir dafür beanspruchte RAM--Bereich genügend `gesichert'. Und mit den Überlegungen aus Teil 8 brauche ich mir über solche `Absicherungen' sowieso keine Gedanken zu machen. Ja, ich kann noch etwas weiter gehen: Dadurch, dass das Disketten--Image in einer Datei (auf der RAM--Disk) 'eingekapselt' ist, kann selbst dann nichts passieren, wenn ich außer den Turbo--Forth--Teilen noch andere Dinge, wie z.B. PCTOOLS, mit in die RAM--Disk packe. Das habe ich zum Ausprobieren denn auch getan. \end{enumerate} \section{USB--Stick unter DOS} Ich habe es eben unter Punkt 6 angedeutet: Ein als lokales Laufwerk (als `Festplatte' mit FAT16) formatierter USB--Stick von 1 GB läuft bei mir unter DOS 6.2 bestens. "`Geht prinzipiell nicht,"' hatte ich vor meinen Recherchen sagen hören. Von wegen! Ich brauchte dazu in die config.sys lediglich die beiden Zeilen \begin{verbatim} device=USBASPI.SYS /v device=Di1000dd.SYS \end{verbatim} einzubinden. Inzwischen habe ich schon fast wieder vergessen, von welchem FTP--Mirror es mir nach einigem Bemühen gelang, das eben angegebene Panasonic--Treiber--Paar herunterzuladen. \section{Mit DUSE} von Cypress hat das nichts zu tun. DUSE ist ein Kapitel für sich. Mit DUSE bin ich nicht zurechtgekommen. Da nützte auch der als PDF--Datei pompös angelegte DOS--Driver--User’s--Guide von 94,1 KB nichts. Vielleicht war da meine AMD--K6--2--CPU zu primitiv? --- Und warum gibt es niemanden, der versucht, den Quelltext von DUSE zu rekonstruieren? Vielleicht sogar in Forth? Das wäre doch eine interessante Aufgabe (für einen begeisterten Amateur)! \section{microcore.iso in der RAM--Disk} Auf dem eben erwähnten 1--GB--Stick fand ich zufällig noch (aus einem früheren Experiment) die ISO--Datei des Mikro--Linux--Live--Systems `microcore' (hat mit dem in der Forth--Gesellschaft bekannten MicroCore nichts zu tun). Diese ISO--Datei hat eine Länge von 6,81 MB. Das ist mehr als genug für \texttt{getdiskimage} aus Teil 8. Auch das habe ich ausprobiert. 6,81 MB sind 7145472 Bytes, was 6d0800h Bytes entspricht. Mit \texttt{400000. getdiskimage} konnte ich absolut sicher sein, dass die RAM--Disk funktionsfähig bleibt und dass das in der auf der RAM--Disk deponierten ISO--Datei enthaltene Disk--Image bei beliebigem Umkopieren (der ISO--Datei) nicht angetastet wird. Meine RAM--Disk ist, wie schon erwähnt, 30 MB groß. Die ISO--Datei liegt am Anfang der RAM--Disk. Das in die ISO--Datei, ich will sie \texttt{x.iso} nennen, gelegte Disketten--Image ist mit meinem \texttt{dump-32} aus Teil 8 gut zu erkennen: Gleich am Anfang des Disketten--Images kommt die Bezeichnung FREEDOS vor (ich hatte das Image einer FreeDOS--Diskette erzeugt). Ich konnte mir also zur vertrauensbildenden Überprüfung folgendes Vorgehen erlauben (die Türme von Hanoi lassen grüßen): \begin{enumerate} \item \texttt{x.iso} in die RAM--Disk kopieren zu \texttt{y.iso}, \item in \texttt{x.iso} mit \texttt{400000. getdiskimage} das Image der Diskette legen, \item das derart modifizierte \texttt{x.iso} auch in die RAM--Disk kopieren zu \texttt{z.iso}, \item \texttt{y.iso} kopieren nach \texttt{x.iso} --- per \texttt{dump-32} auf image--frei überprüfen, \item \texttt{z.iso} kopieren nach \texttt{x.iso} --- per \texttt{dump-32} auf `Image drin' überprüfen. \end{enumerate} Nachgeprüft werden sollte, dass bei dem Hin- und Herkopieren am Disk--Image (innerhalb der ISO--Datei) nichts verlorengegangen war. Man könnte es mit einem Vergleichs--Programm genauer machen. Fürs Erste dürfte das aber genügen. \section{Freischalten der Adressleitung a20} Mit \texttt{himem.sys} in der \texttt{config.sys} wird die Adressleitung 20 normalerweise freigeschaltet. Hat man aus irgendeinem Grunde keine \texttt{himem.sys} in der \texttt{config.sys}, dann kann man zur Freigabe des Zugriffs auf Adressen oberhalb \texttt{ffff:ffff} das Wort \texttt{free-a20} aus Teil 8 verwenden. \section{Nur Real--Modus benötigt} In [MA89] steht: "`Für den Zugriff auf den Extended Memory müssen Sie den Prozessor in den `Protected Mode' schalten."' Wirklich? Was mich betrifft, ich komme ohne eine solche Maßnahme aus! Die Adressen lassen sich (jedenfalls beim 486 und höher) auch im Real--Modus gleich 32--bit--breit ansprechen. Das Adress--Präfix 67h vor den Maschinenbefehlen macht es möglich. Alles Weitere siehe Teil 8. Hier zur schnellen Überprüfung (123456. = Punktzahl!): \begin{verbatim} 00 123456. c!-32 77 123456. c!-32 123456. c@-32 , [ret] 77 OK \end{verbatim} \section{Glossar einiger Worte aus Teil 8} (Definitionen im Vokabular forth) ad. und len. = Punktzahlen (doppeltgenau). \begin{small} \begin{verbatim} free-a20 ( -- ) Adressleitung a20 lösen c@-32 ( ad. -- c ) Byte c von Adresse ad. zum Stack holen c!-32 ( c ad. -- ) Byte c vom Stack nach Adresse ad. speichern dump-32 ( ad. len. -- ) Stop: [SPACE]. Weiter: [SPACE]. Exit: Eingabetaste Mehr: + . Nochmal zurück: - Vor- oder Zurückschaltung jedesmal 100h Bytes getdiskimage ( ad. -- ) Hex-Image der 3.5-HD-Diskette nach ad. ins RAM legen \end{verbatim} \end{small} \section{DD--Disketten im Arbeitsspeicher} Hätte ich mich auf DD--Disketten beschränkt, so hätte ich mir nicht so viel zu überlegen brauchen: 360 KB passen `normalerweise' gut in das RAM des (vom ursprünglichen PC so bezeichneten) `Arbeitsspeichers'. Bei 1,44 MB (Gegenstand des vorliegenden Artikels) sieht die Sache natürlich anders aus. \section{Zip--Disketten} Warum aber bei HD--Disketten aufhören? Als nächstes Experiment könnten Zip--Disketten vom IOMEGA--kompatiblen Typ anstehen. Ich habe an der von mir verwendeten Experimentier--Anlage 392192 KB RAM--Speicher zur Verfügung. Da passen bis zu drei 100--MB--Zip--Disketten locker hinein. Als RAM--Disk könnte man dann beispielsweise XMSDSK von Franck Uberto [FU98] einsetzen. \end{multicols} \section{Literatur} \begin{tabular}{lp{15cm}} [CP88] & PCTOOLS: PC--Tools--Deluxe R4.21. pctlsdlx.exe. Central Point Software, Inc.(1988). \\ [CW99] & Walter, Christoph: cwdskedt.exe 2.22. Für DOS. Freeware. \\ [FB98] & Behringer, Fred: Real--Mode--32--Bit--Erweiterung für Turbo-Forth. Vierte Dimension 2/1998.\\ [FB09] & Behringer, Fred: Vierter Teil meiner VD--Artikel-Serie. Vierte Dimension 2/2009. \\ [FU98] & Uberto, Franck: XMSDSK, eine RAM--Disk, deren beliebige Länge auch während des Betriebs noch verändert werden kann. \\ [MA89] & Althaus, Martin: Gesprengte Ketten. DOS International 12 (1989). \\ [MK92] & Kalisch, Martin: Disk--Editor 1.2. diskedit.exe, (1992). \\ [MP87] & Petremann, Marc: Turbo--Forth. Liegt in verschiedenen Versionen z.B. auf dem amerikanischen FTP--Server taygeta.com. \\ \end{tabular} \end{document}