Thema: booten / laden von diskette

[erik.vikinger]

Hallo,

und ggf. auch kleine Programmschnipsel die zeigen welcher Opcode hierbei verwendet wird.

Das ist IMHO aber schon deutlich mehr als man am Anfang wirklich verkraftet.

Man braucht nicht unbedingr dafür ein 32Bit-OS um Programme(oder Teile davon) im 32 Bit-Mode auszuführen. Vom purem 16 Bit-DOS aus gestartet (ohne Memorymangaer wie emm386.exe) kann jede Anwendung selber in den 32 Bit-PM schalten und einen Opcode der für den 32 Bit-Mode entwickelt wurde dann auch ausführen.

Also wenn die Programme quasi ihr eigenes OS mitbringen (ein DOS-Extender ist ja fast ein richtiges OS) dann heißt das nicht das man keinen passenden System-Mode-Code benötigt der die gewünschten Features auch anbietet.
Außerdem will hier ja wohl niemand ein OS wie DOS entwickeln, oder doch?

Der Unrealmode ist weder ein Trick noch ein Bug, sondern ein zu Anfang verleugneter Betriebsmode der mit der Einführung der 80386 hinzukam.

Der Unreal-Mode ist aber wimre nicht absichtlich eingeführt worden sondern ist eigentlich schon eine Art Bug weil beim Zurückschalten vom PM auf RM die Segment-Shadow-Register nicht passend zurück gesetzt werden. Einen echten Nutzwert hat der Unreal-Mode aber nicht weil er nur schwer praktisch nutzbar ist, jedes Laden eines Segment-Registers im RM setzt immer die Segment-Shadow-Register auf für den RM passende Werte (also Limit auf 64kB usw.).

Ich habe überhaupt keine Ahnung über Real Mode, usw...

Eigentlich reicht es ja auch wenn der Compiler davon Ahnung hat, wobei es natürlich trotzdem nützlich ist wenn man als Programmierer auch mal ein paar Ebenen tiefer blicken kann. Vor allem im Low-Level-Bereich wird man aber über wenigstens grundlegende Assembler-Kenntnisse nicht herum kommen, eigentlich sollte man IMHO für ein OS schon eher fortgeschrittene Assembler-Kenntnisse haben.

Speicheradressierung hat mich auch noch nicht besonders beschäftigt, weil ich es nie gebraucht habe.

Was, Deine Programme haben noch nie auf den Speicher zugegriffen? Respekt!

Code: [Auswählen]

Puffer1  DB  0,1,2,3,4,5,6,7,8,9
         DB  "ABCDEFGHIJ"
         ....
         ....

         lea  di, Puffer1
         mov  bx, 10
         mov  al, [bx+di]
         .....


Falls das eine Art INT2HEX_ASCII sein soll ist da ein Bug drin, mal sehen wer den noch findet.


Grüße
Erik

[freecrac]

Man braucht nicht unbedingr dafür ein 32Bit-OS um Programme(oder Teile davon) im 32 Bit-Mode auszuführen. Vom purem 16 Bit-DOS aus gestartet (ohne Memorymangaer wie emm386.exe) kann jede Anwendung selber in den 32 Bit-PM schalten und einen Opcode der für den 32 Bit-Mode entwickelt wurde dann auch ausführen.

Also wenn die Programme quasi ihr eigenes OS mitbringen (ein DOS-Extender ist ja fast ein richtiges OS) dann heißt das nicht das man keinen passenden System-Mode-Code benötigt der die gewünschten Features auch anbietet.

Nur weil man in den PM schaltet kann man das doch nicht als ein eigenständiges OS bezeichnen. Das haben auch schon manche DOS-Spiele gemacht.

Außerdem will hier ja wohl niemand ein OS wie DOS entwickeln, oder doch?

Ich selber habe nicht vor ein OS zu entwickeln.

Der Unrealmode ist weder ein Trick noch ein Bug, sondern ein zu Anfang verleugneter Betriebsmode der mit der Einführung der 80386 hinzukam.

Der Unreal-Mode ist aber wimre nicht absichtlich eingeführt worden sondern ist eigentlich schon eine Art Bug weil beim Zurückschalten vom PM auf RM die Segment-Shadow-Register nicht passend zurück gesetzt werden.

Doch das glaube ich schon, das der Unrealmode mit voller Absicht eingeführt wurde, denn es gab ja auch (auf einigen CPUs) den Loadall-Befehl der genau dafür entwickelt wurde und auch Microsoft hat den Unrealmode schon ganz bewusst im Himem.sys benutzt. Es wurde aber ein Mantel des Schweigens darüber gehüllt und dann noch behauptet das es ein Bug sei. Alles nur dreiste Lügen um das damals kommende Windows besser vermarkten zu können.

Einen echten Nutzwert hat der Unreal-Mode aber nicht weil er nur schwer praktisch nutzbar ist, jedes Laden eines Segment-Registers im RM setzt immer die Segment-Shadow-Register auf für den RM passende Werte (also Limit auf 64kB usw.).

Das ist ebenfalls eine nicht wahre Behauptung.

Die Shadow-Register kann man nicht vom RM aus zurücksetzen, dafür muss man wieder in den PM schalten und von dort ein Segmenteintrag mit 64ikB-Grösse laden um den Unrealmode damit quasi wieder auszuschalten, denn sonst bleiben die Shadow-Register unverändert bestehen, egal wie oft man die Segmentregister im RM mit einer Adresse läd. DOS und BIOS läßt sich damit auch weiterhin nutzen. Probiere es einfach selber aus, wenn du es nicht glauben kannst.

Gerüchteweise soll es aber einige PCI-Karten gegeben haben, die über ihr Bios selber in den PM schalten und damit den Unrealmode quasi wieder abschalten. Welche Karten das machen, das konnte mir aber bisher keinen veraten.

Der Unrealmode läßt sich sehr leicht auch praktisch nutzen. Siehe dazu auch mein Beispiel zur Vesa-Programmierung.

Ich erweitere dabei nur das Datensegment, weil damit braucht man kein Segment-Prefix zur Adressierung. Um auch weiterhin auf mein Datenbereich der Anwendung zugreifen zu können, lade ich "DS" mit dieser Adresse wie gewohnt. Um einen Zugriff auf Adressen im 4 Gib-Adressraum mit "DS:Reg32" zu bekommen ziehe ich von der gewünschten oberen, linearen Adresse die Adresse des Datensegments davon ab.

Code: [Auswählen]

Puffer1  DB  0,1,2,3,4,5,6,7,8,9
         DB  "ABCDEFGHIJ"
         ....
         ....

         lea  di, Puffer1
         mov  bx, 10
         mov  al, [bx+di]
         .....


Falls das eine Art INT2HEX_ASCII sein soll

Nö eigentlich nicht, ich habe nur willkürlich zwei Tabellen angelegt ohne darüber nachzudenken wofür man die konkret verwenden könnte.
Damit wollte ich nur zeigen das man zwei verschiedene Adressregister kombinieren kann, um auf eine Speichstelle zuzugreifen.

Dirk

[Simon]

Hallo
ich hab nen (einigermaßen) funktionierendes Softwaremultitasking programmiert und eine Funktion zum herunterfahren eingebunden (Die aber leider nie getestet werden konte).
Mein Programm habe ich immer mit der NTVDM Cpu getestet. Hat auch so funktioniert wie es soll.
Weil ich direkt von der Tatstatur (Polling) die Werte  einlese, musste ich einen Tatstaturtreiber schreiben.
Dadurch ist mein Programm schonmal um ca 700 bytes größer geworden.
Sonst kann mein Programm schon Zeichen einlesen, anzeigen, und jeweils ein Zeichen nach vorne springen, wenn das Zeichen geschrieben worden ist.
Zur Speicheradressierung:
ich habe immer mov xx,[<variable>] geschrieben, der rest hat der Compiler gemacht.
Und bitt diskutiert nicht so viel rum, ich komme selbst langsam nicht mehr mit......
Simon