\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}
