[LOWLEVEL] Memmap

[oDOSseus]

Hallo leute.

ich habe in meiner Freizeit einen kleinen bootloader programmiert und einen kleinen Kernel. Sozusagen ein miniOS. Es ist eher Spielerei. Ich habe nur ein paar Fragen:
Wie genau sieht die "Mem-map" (ich weiß kein besseres Wort) von einem PC im 1MB RAM bereich aus? Wo darf ich hinschreiben, wo nicht?
Zweite Frage:
Kann ich den Cursor verschieben ohne Interrupt 10h zu benutzen?

[freecrac]

Hallo leute.

ich habe in meiner Freizeit einen kleinen bootloader programmiert und einen kleinen Kernel. Sozusagen ein miniOS. Es ist eher Spielerei. Ich habe nur ein paar Fragen:
Wie genau sieht die "Mem-map" (ich weiß kein besseres Wort) von einem PC im 1MB RAM bereich aus? Wo darf ich hinschreiben, wo nicht?

Ohne den DOS-Interrupt 21h(AH=48h,49h,4Ah) wüßte ich jetzt auch nicht genau welche Bereiche nicht benutzt werden dürfen.

Zweite Frage:
Kann ich den Cursor verschieben ohne Interrupt 10h zu benutzen?

Wie du dir schon denken kannst: Den Bios-Interrupt(int 10, ah=2) von der GraKa kann man auch ohne DOS benutzen. Der Linux-Bootloader benutzt diesen Bios-Interrupt, um den Cursor zu setzen.

Alternativ dazu kann man die CRTC-Register für 6845-based color Videocontroller Port 3D4h(Address) und 3D5h(Data) Cursor Location High Register (Index 0Eh) und Cursor Location Low Register (Index 0Fh) beschreiben. Allerdings sind die CRTC-Register manchmal für direkte Portzugriffezugriffe versperrt und die Entriegelung dafür bei verschiedenen GraKas unterschiedlich realisiert worden. Gewöhnlich wird dazu eine Portadresse zum Verriegeln/Entriegeln verwendet und mit den dafür nötigen Werten beschrieben. Die Portadressen und die Werte dafür varieren von GraKa zu GraKa.

Hier ein kleiner Überblick über die CRTC-Register:
http://www.osdever.net/FreeVGA/vga/crtcreg.htm

Programmierbeispiel:
(Hinweis für "Source in assembly": Für 16 Bit und 32 Bit-CPUs muss die Registergröße anpasst werden, da in diesem Beispiel davor und danch 64Bit-Register gepush/gepopt werden;
wenn die Registerinhalte gar nicht gerettet werden brauchen, dann kann man die push- und pop-Befehle dort auch weglassen):
http://wiki.osdev.org/Text_Mode_Cursor

Noch ein Beispiel:
http://joelgompert.com/OS/lesson7.htm

Dann gibt es auch entsprechende Systemvariable im Speicher (ich glaube die werden vom int 10h gesetzt):

Code: Alles auswählen

0040:0050	 Video cursor position page 0, bits8-15=row,bits0-7=column
0040:0052	 Video cursor position page 1, bits8-15=row,bits0-7=column
0040:0054	 Video cursor position page 2, bits8-15=row,bits0-7=column
0040:0056	 Video cursor position page 3, bits8-15=row,bits0-7=column
0040:0058	 Video cursor position page 4, bits8-15=row,bits0-7=column
0040:005A	 Video cursor position page 5, bits8-15=row,bits0-7=column
0040:005C	 Video cursor position page 6, bits8-15=row,bits0-7=column
0040:005E	 Video cursor position page 7, bits8-15=row,bits0-7=column

Dirk

[wobo]

Hallo leute.

ich habe in meiner Freizeit einen kleinen bootloader programmiert und einen kleinen Kernel. Sozusagen ein miniOS. Es ist eher Spielerei. Ich habe nur ein paar Fragen:
Wie genau sieht die "Mem-map" (ich weiß kein besseres Wort) von einem PC im 1MB RAM bereich aus? Wo darf ich hinschreiben, wo nicht?

Weiß ich auch nicht so genau. Aber der am PC erste "verbotene" Speicherbereich dürfte die Interruptektorentabelle für die CPU sein, die immer an Speicherstelle 0000:0000 beginnt und für 256 Ints 1024 Byte benötigt. Direkt daran schließt sich das BIOS Datensegment an, was angeblich immer 256 Byte groß ist ($0040:0000 bis $ 0040:00FF). Allerdings bin ich mir bei der Größe nicht sicher. Die Größe von 256 Byte habe ich nie als Dogma mitbekommen. Meist heißt es immer nur "das 256 Byte große BIOS Datensegment", was vielleicht nur unsauber formuliert ist und nur bedeuten soll, dass die ersten 256 Byte standardisiert sind. Je nach BIOS sind vielleicht auch mehr belegt.

Jedenfalls belegt nach PC-Intern 3.0 das Bios auch noch die Speicherstelle $0040:$0100 für das int5-Flag. Damit hätten wir schon 257 Byte.... Ich wette, das wird noch mehr... (Vielleicht weiss Brueggi, wo der vom BIOS benötigte RAM-Speicher endet)

Die zweite Speichergrenze dürfte die 640k-Grenze sein. IBM hatte damals halt gesagt, ab $A000:0000 beginnt der Speicher für Erweiterungskarten und ist für RAM per definitionem Tabu. (Auch wenn der "640k ought to be enough"-Spruch Bill Gates angelastet (und von ihm bestritten wird), für die 640k-Grenze war allein IBM verantwortlich und nicht Microsoft).

Zwischen Ende des BIOS-Datenbereichs bis zur 640k-Grenze müßte Platz für den OS sein.

[DOSferatu]

Ein Tip meinerseits:

Für die genaue "Memory-Map" kann man auch Ralph Brown's Interrupt List (RBIL) konsultieren. (u.a. auch auf meiner Seite zu finden: http://www.imperial-games.de/html/dosd2.htm )
In der RBIL sind nicht nur Interrupts gelistet, sondern auch wichtige Portadressen und Speicherbelegung.

[oDOSseus]

direkt in 0040:0050 schreiben funktionierte nicht
werde wohl beim interrupt bleiben.
Der bootloader wird ab 07C0:0000 gespeichert (vom bios). Dahinter lade ich direkt noch stack und kernel. D.h. für ein Optionales Programm ist gar kein platz. wie schafft DOS das, dass man 640k COM-Dateien ausführen kann, wenn der anfang der RAM gar nicht frei ist?

[Nilquader]

Man kann ja auch keine 640K COM-Dateien ausführen - höchstens 64K. Und die sollten doch bei dir nach dem Laden von Stack und Kernel auch noch frei sein - oder? DOS lädt übrigens (zumindest in den neueren Versionen) große Teile seines Systems in den nicht durch Erweiterungskarten genutzten Speicher oberhalb der 640K, damit mehr Platz für Programme bleibt. 640K werden es dennoch nicht...eher etwa 610-620K.

[oDOSseus]

Ach so ist das! Ja dann macht das Sinn. Danke

[freecrac]

direkt in 0040:0050 schreiben funktionierte nicht
werde wohl beim interrupt bleiben.

Diese Adressen dienen wohl eher der Information, um die Positionen auszulesen.
Das eigentliche Setzen des Cursors muss über die CRTC-Register erfolgen, zusätzlich kann man dann auch noch die Position in den Biosvariablen speichern.

Der bootloader wird ab 07C0:0000 gespeichert (vom bios). Dahinter lade ich direkt noch stack und kernel. D.h. für ein Optionales Programm ist gar kein platz. wie schafft DOS das, dass man 640k COM-Dateien ausführen kann, wenn der anfang der RAM gar nicht frei ist?

Den optionalen Programmcode(binäre Daten) läd man eben an eine höhere Adresse.

Dirk

[Brueggi]

Ich geb da jetzt auch mal meinen Senf dazu Theor. kann sich der Bootlader oder eine Zwischeninstanz ja per BIOS die installierte RAM-Config übergeben lassen - das heißt, so weisst du schonmal, wo das obere Ende des konventionellen RAMs bis 640K liegt.

Schwierig wirds bei einigen Rechnern (z. B. hatte ich mit Think Pads die Erfahrung gemacht), die sagen z. B. es sind 640K frei, belegen aber trotzdem offenbar am oberen Ende des RAMs einen kleinen Teil, so das es hier zu abstürzen kommt, wenn man nicht ein paar Bytes abzieht (so hab ich es gemacht, und seit dem keine Probleme mehr gehabt).

Von unten her würde ich (hab den genauen Wert jetzt nicht im Kopf, müsste in den Quellcode von meinem DOS kucken) nicht unter $04FFF beginnen - oder es zumindest ausgiebig auf diversen PCs testen.

Ich habe die Lösung gewählt, dass das Kernel automatisch in den letzten 64K-Block geladen wird (dort liegt auch der Stack). Auf Wunsch hin (per Befehl) lässt sich Kernel auch in die HMA verschieben. So arbeitet das DOS auch mit Treibern wie dem Ontrack Diskmanager zusammen - der zwackt ein paar KB am oberen Ende ab, und sorgt dafür dass das BIOS entsprechend weniger konventionellen Speicher "erkennt".

Anwendungen bzw. Programme einladen - das kannst Du später machen wie du lustig bist. Bei mir gibts zwei grundarten von Programmen - normale Anwendungen und residente Programme. letztere werden immer am oberen Speicherende angesiedelt, wobei normale Files von "unten nach oben" geladen werden. Überschneiden sich beim Laden beide Bereiche, gibts nen "Out of Memory"-Fehler. Außerdem bekommt jedes Programm beim Start nicht nur die Kommandozeilen-Parameter übergeben, sondern auch Informationen über den freien Speicher (es kann ja sein, das ein Programm vielleicht nur 30K groß ist, aber ggf. nochmal 128K braucht, um Bilder zu laden oder sowas halt).

Und wenn ja mal der Speicher knapp wird (ist bei mir eigentlich noch nie der Fall gewesen), dann kannst Du dir auch noch einen Speichermanager basteln, der RAM oberhalb der 1 MB-Grenze verwaltet. Wobei ich meinen Speichermanager bisher nur in 2 Fällen wirklich gebraucht hab

Viele Grüße,

Brueggi

[Brueggi]

Am besten geht dein Bootlader so vor:
1. Testen der Speicherkonfig
2. Laden des Kernels in den entsprechenden Speicherbereich (denk daran, das du Probleme kriegst, wenn Du versuchst, Daten/Programme an Speicher oberhalb von 640K bzw. 1 MB zu laden, das macht der DMA-Controller nicht mit - du musst dann per hand die Daten verschieben).
3. Sprung ins Kernel

Du sparst dir eine Menge Aufwand, wenn du nicht kompatibel auf Teufel komm raus bist (wozu sollte man z. B. Ur-PCs mit 128K unterstützen? Wie groß ist die Zielgruppe dort?) - wobei man darüber jetzt streiten kann.

Bei Fragen stehe ich gerne zur Verfügung.

[oDOSseus]

Danke für eure tatkräftige Hilfe. Wenn es soweit ist, werde ich ncoh einmal darauf zurückkommen