Nachrichten

41

Lowlevel-Coding / Re:BIOS-Interrupts

« am: 22. April 2011, 10:58 »

Wenn ich es richtig verstanden habe, dann benutzt der SMM einen eigenen Adressierungsmode um auf den gesamten physikalischen Speicher zuzugreifen.

Richtig, der SMM ist wimre so was ähnliches wie ne Kreuzung aus Protected-Mode und UnReal-Mode.

Nun habe ich gelesen das alle modernen Intel-CPUs wie bisher mit dem RM beginnen und dann zu einem "Reset Vector" nach 0xFFFFFFF0 (16 Byte unterhalb der 4 Gib Grenze und damit weit oberhalb des ersten Mib) springen, um dort den ersten Befehl auszuführen.  Dabei wird eine "hidden base address" für EIP verwendet. Auch wenn es nicht offiziell von Intel bekannt gegeben wird, wenn es alle modernen Intel so machen, dann ist es eben eine Methode die auf allen modernen Intel so verfügbar ist und das völlig unabhängig davon ob es nun offiziel zugesichert wird, oder auch nicht.

Es gibt aber noch einige Modi mehr auf modernen x86-CPU, z.B. für das nicht vertrauenswürdige Trusted-Computing. Ich könnte mir vorstellen das nicht jede beliebige Kombination vom Modus-Wechseln unter allen Umständen immer fehlerfrei funktioniert, AMD und Intel machen auch mal Fehler und testen tun die zu erst mal mit den wichtigen Features die häufig benutzt werden und die auch laut Datenblatt vorhanden sein müssen.

Als "undefinierten Betriebszustand" wurde der Unrealmode doch nur definiert,

Da hast Du mich leider missverstanden, es geht nicht um einen "undefinierten Betriebszustand" sondern um eine nicht zugesicherte Eigenschaft.

Indirekt meinte ich ja genau das. Es ist einfach unwichtig ob es eine offizielle Bestätigung z.B. von Intel dafür gibt wenn alle modernen Intel es so machen. Auch ist es egal ob das nun als "Hack" aller modernen Intel-Rechner bezeichnet wird, oder als offiizell zugesichter Feature. Fakt ist, das es ein Standard auf modernen Intel CPUs geworden ist.

Verantwortlich fühlen sich AMD, Intel und alle anderen die x86-CPUs herstellen nur für das was sie auch zugesichert haben, zuerst kommt das Pflichtprogramm und der Rest ist die Kür aber wenn sich dafür keiner interessiert und eben auch niemand Beifall klatscht dann wird die Kür auch schon mal weggelassen oder zumindest stark reduziert. Schau Dir mal an bei was für Fehler AMD und Intel in den letzten 20 Jahren ihre Produkte schon mal zurück gerufen haben und was für Fehler stillschweigend ignoriert werden (das Letzte findet man oft in den Erratas und das Erste in den Medien, ich würde wetten das ein Problem mit dem UnReal-Mode in den Erratas verschwindet).

Das denke ich auch, da der Unrealmode innerhalb von Anwendungen ja kaum mehr benutzt wird.

obwohl MS den Unrealmode im Himem.sys(version 2.03) ja selber jahrelang benutzt hat und der auf nahezu allen damaligen Rechnern ab 1988 verwendet wurde.

Dann hätte HIMEM.SYS mit sehr vielen Spielen und etlichen anderen Programmen die einen DOS-Extender benutzen nicht ordentlich funktioniert.

Was soll daran denn nicht ordentlich funktioniert haben, es gab eben eine Menge Spiele die es benutzen konnten.

Das Problem am UnReal-Mode ist das man ihn nicht erkennen kann und auch nicht prüfen kann ob er beschädigt wurde, man kann nur probieren und schauen ob ne Exception kommt.

Ich denke nicht das Spiele die für den RM/Unrealmode entwickelt wurden damit jemals grosse Probleme hatten. Jede dieser Anwendungen kann ja überprüfen ob Himem.sys gestartet wurde und ggf. wenn nicht ja selber den Unrealmode anschalten und ob er nun schon vorher aktiv war oder nicht ist hierbei doch völlig unwesentlich, da man aus dem RM, und/oder auch aus dem Unrealmode jederzeit wieder erneut den Unrealmode anschalten kann.  Wo ist nun also das Problem, wenn man nicht wirklich festellen kann ob Segmente erweitert wurden, oder noch nicht?

Vorher (im Zeitraum von 1990-1995) benutzten viele Computer-Spiele noch den Unrealmode.

Bitte nenne mal ein paar Beispiele. Alle DOS-Spiele aus der Zeit die ich kenne nutzen einen (zugekauften) anständigen DOS-Extender.

Das kann ich dir leider auch nicht sagen welche Spiele nun genau den Unrealmode benutz haben, aber sicherlich waren es Spiele die den damaligen Himem.sys benutz haben, der ja den Unrealmode dafür benutzt hat. Und nicht jeder Entwickler hatte damals Lust dazu den umständlicher Weg über DOS-Extender zu wählen.

Auch der Umstand das Intel in einigen ihrer CPUs für den Unrealmode selber ein Loadall-Opcode integriert hat, zeigt es doch das wir es hier keinesfalls mit einem Hardware-Bug, oder undefinierten Betriebsmode zu tun haben, sondern das hier ganz gezielt eine Unterstützung für den Unrealmode beabsichtigt war.

Das der UnReal-Mode von den Intel-Ingeniören nicht unbedingt unbeabsichtig war vermute ich auch (ist halt so ein dirty Hack der sich eigentlich ganz von selbst nebenbei ergibt wenn man die Protected-Mode-Spezifikation passend interpretiert), aber das der UnReal-Mode jemals ein echtes zugesichertes Produkt-Feature war ist nicht richtig.

So wie ich es verstanden habe ist der Loadall-Befehl doch nicht für den PM entwickelt worden, sondern nur für den RM, um nicht in den PM schalten zu müssen. Wenn es nur ein Nebenproduckt bei der Entwicklung des PM gewesen wäre, dann hätte man ihn doch gar nich implementieren müssen.

Ob nun der Unrealmode offizilel zugesichert wurde, das intersesierte doch die damaligen Entwickler ebenso wenig, wie es mich heute interessiert, wichtig ist doch nur ob er im weitem Umfeld verfügbar ist, oder eben nicht.  Das es hier wenige Ausnahmen gibt wo er dann nicht reibungslos funktioniert ist dabei doch eher nebensächlich. Auf den meisten Rechner bis zu heutigen modernen Rechnern ist der Unrealmode verfügbar, alleine das zählt und dafür brauche ich dann bestimmt keine offizielle Zusage von Intel, AMD mehr dafür. Mir genügt es das er bis heute auch auf modernen Rechner im weitem Umfeld benutzbar ist.

PS.: die Art wie Du zitiert finde ich persönlich eher unschön, wenn Du schon meinen ganzen Beitrag am Stück zitierst dann kannst es auch ganz bleiben lassen denn er steht ja eh am Stück unmittelbar vor Deinem Beitrag

Ja das finde ich auch unschön, wo du es nun erwähnst. Ich war wohl noch etwas zu müde als ich den Beitrag schrieb, so das es mir dabei gar nicht aufgefallen ist. Eigentlich versuche ich auch so etwas zu vermeiden.

Dirk

42

Lowlevel-Coding / Re:BIOS-Interrupts

« am: 20. April 2011, 08:40 »

Hallo,

Ich habe den 16 Bit UnReal-Mode schon auf mehreren x86-Rechnerplattforemen erfolgreich verwendet. Begonnen mit 80386er, 80468, mit Rechner für Sockel 5, 6, 7, Pentuim 3, 4 und jetzt Core2Quad und ich habe noch nie derartige Probleme damit feststellen können.

Wir haben damals auf einem 486 und einem Pentium 60MHz (erste Generation, noch kein Sockel 7 aber dafür mit VLB-Slots auf dem Board) getestet und es nicht stabil hin bekommen. Aber vielleicht haben wir uns damals einfach nur zu blöd angestellt, auch das ist nicht ausgeschlossen.

Ich erweiterte aber eigentlich nur DS ....

Ich weis nicht ob das eine Rolle spielt aber ich denke eher nicht.

Ich sehe keinen Grund auf den UnReal-Mode zu verzichten, auf unseren Rechnern lief er bisher genauso stabil und zuverlässig wie RM und PM.

Der UnReal-Mode ist keine zugesicherte Eigenschaft und das macht ihn zu einer Kann-Angelegenheit. Es wäre also durchaus möglich das er irgendwann nicht mehr funktioniert, z.B. auf einer abgespeckten Embedded-Version die trotzdem voll x86-Kompatibel ist. Es gab mal eine 386EX-Variante (Single-Chip-Lösung mit dem üblichen x86-Drum-Herrum komplett integriert), die letzten davon sogar mit Unterstützung für CPUID und den SMM, speziell für kleine Lowest-Power-Applikationen, ich kann mir durchaus vorstellen das da nicht alle üblichen Tricks funktioniert haben, schon weil z.B. keine Windows-Kompatibilität gefragt war dürften auch die Endtests deutlich kleiner ausgefallen sein.


Könnte es eigentlich sein das der SMM den UnReal-Mode kaputt macht?
In den SMM kann ja von jedem beliebigen anderen Modus hinein gewechselt werden und der Ausgangs-Modus wird da speziell gesichert. Ich könnte mir vorstellen dass das Wiederherstellen von "undefinierten Betriebszuständen" (in genau diese Kategorie fällt der UnReal-Mode) nicht immer funktioniert.


Grüße
Erik

Über SMM werden z.B. auch mit "USB legacy" die USB-Signale konvertiert, damit man eine USB-Mouse auch als PS2-Mouse benutzen kann.
Auf meinem Asus Striker-MoBo mit Sockel 775 und Intel Core2quad klappt das auch mit angeschalteten Unrealmode, ohne das der Unrealmode dadurch völlig ausgeschaltet, oder übermäßig gestört wird. Wenn ich es richtig verstanden habe, dann benutzt der SMM einen eigenen Adressierungsmode um auf den gesamten physikalischen Speicher zuzugreifen.

Als "undefinierten Betriebszustand" wurde der Unrealmode doch nur definiert, weil Microsaft ihr damals gerade herauskommendes Windows 95 vermarkten wollte, obwohl MS den Unrealmode im Himem.sys(version 2.03) ja selber jahrelang benutzt hat und der auf nahezu allen damaligen Rechnern ab 1988 verwendet wurde.

Erst mit der Einführung von Windows 95 wurde der Unrealmode nicht mehr interessant, da er nicht mit Windows kooperiert und Anwendungen die den Unrealmode nutzen möchten einen Neustart des Rechners benötigen. Vorher (im Zeitraum von 1990-1995) benutzten viele Computer-Spiele noch den Unrealmode. Hinterher davon zu sprechen das der Unrealmode ein "undefinierten Betriebszustand" wäre ist doch einfach nur eine dreiste Lüge, auch dann wenn manche neuere Hardware diesen selbstauferlegten "undefinierten Betriebszustand" durch nicht mehr kompatible Firmware in wenigen Fällen dazu inkompatibel gemacht haben. Auch der Umstand das Intel in einigen ihrer CPUs für den Unrealmode selber ein Loadall-Opcode integriert hat, zeigt es doch das wir es hier keinesfalls mit einem Hardware-Bug, oder undefinierten Betriebsmode zu tun haben, sondern das hier ganz gezielt eine Unterstützung für den Unrealmode beabsichtigt war.

Dirk

43

Lowlevel-Coding / Re:BIOS-Interrupts

« am: 19. April 2011, 08:02 »

Erwischt. Den nachfolgenden Beitrag hatte ich allerdings noch gar nicht gelesen um darauf gleichzeitig antworten zu können, denn beim Schreiben schaue ich eigentlich nicht ständig nach, ob schon neue Beiträge eingetroffen sind.

Wenn du auf Absenden drückst, weist dich das Forum eigentlich darauf hin. Das steht dann in roter Schrift über dem Eingabeformular, das in diesem Fall dann wieder erscheint.

Das muss ich wohl dann übersehen haben. Danke für den Hinweis.

Dirk

44

Lowlevel-Coding / Re:BIOS-Interrupts

« am: 18. April 2011, 01:06 »

Hallo,

Genau das sind Doppelposts, Dirk.

Erwischt. Den nachfolgenden Beitrag hatte ich allerdings noch gar nicht gelesen um darauf gleichzeitig antworten zu können, denn beim Schreiben schaue ich eigentlich nicht ständig nach, ob schon neue Beiträge eingetroffen sind.

Prinzipiell darf jeder BIOS-Interrupt auch in den Protected Mode gehen.

Das würde aber bedeuten das man mit solchen BIOS-Interrupt kein Memmorymanager wie emm386.exe mehr verwenden kann.  Mir ist kein Rechner bekannt der nicht mehr auf diese Weise DOS-kompatibel ist.

Bei geladenem EMM386 bist du im VM86, das lässt sich feststellen.

Damit dann die Bios-Routine anstatt selber in den PM zu schalten einen Speicherzugriff über den Memorymanager macht?

Der Unrealmode lässt sich nicht feststellen, denn er ist mit dem RM identisch.

Ja leider. Man kann nur festellen ob der obere Adressbereich erreichbar ist.

BIOS und Treiber können also darauf Rücksicht nehmen.

Bisher habe ich noch keine solche Hardware verwendet.

Ich habe mal gelesen, dass einige Option-ROMs (SCSI-Controller, Grafikkarten) in ihren Handlern auch genau das tun.

Ich habe es nur gerüchteweise gehört, das es so etwas geben soll. Welche Karten davon nun genau betroffen sind konnnte ich jedoch noch nicht ermitteln.

Kurze Suche ergibt dieses:

Code: [Auswählen]

    #12881: Intel RAID cards not working on Westville 533 (BIOS B05 +).
    This was due to the Intel RAID card going into protected mode and
    not returning to big real mode. The fix is to go back into big real
    mode immediatly after option ROMs have executed.


Ah prima. Aber wie darf man das denn nun verstehen, werden beim Zurückschalten in den "big real mode/UnRealmode" etwa nur FS und GS auf 4 Gib erweitert, wie es oft für den UnRealmode empfohlen wird, oder werden auch DS und ES erweitert?

Auch PXE-Boot-ROMs müssen im Protected Mode arbeiten, um die Boot-Images im Speicher verwalten zu können und sie stellen meist auch einen Zugriff auf das Netzwerk "für später" bereit. Der TCP/IP-Stack dafür dürfte auch im erweiterten Speicher liegen...

Die Frage ist immer, ob die Funktionen korrekt zurückkehren (also auch in den Unrealmode) oder nicht.

PXE-Boot-ROMs habe ich noch nie verwendet, auch kenne ich keinen einzigen PC-Anwender persöhnlich der je so etwas benutzt hat.

Guter BIOS-Code würde im Übrigen auch dann, wenn er in den PM schaltet, alles brav wieder zurücksetzen.

Wenn emm386.exe bereits gestartet wurde, dann wird kein Bios-Interrupt selber mehr in den PM schalten können.

Aber er kann dies feststellen. Stellt der Interrupt fest, dass er im VM86 aufgerufen wurde, dann wird eine RM-kompatible Routine aufgerufen, andernfalls eine effizientere Routine, die über den PM geht.

Ok, also wahlweise läuft der Speicherzugriff dann über den Memmorymanager, wenn vom VM86 aufgerufen wurde.

Ich denke aus diesem Grund werden solche Bios-Funktionen die selber in den PM schalten nicht oft anzutreffen sein und damit eine Ausnahme bleiben.

Naja, RM ist nur 16-bittig. Die große Masse der BIOS-Funktionen wird damit auskommen - nach dem Boot sind BIOS-Interrupts ohnehin fast nutzlos

Für DOS sind BIOS-Interrupts ganz gewiss nicht nutzlos und ein wesentlicher Bestandteil des Systems.

- aber wenn es um hohe Geschwindigkeit geht... wie gesagt, ich würde mich nicht drauf verlassen. There be dragons.

Ich selber möchte eigentlich nur Hardware verwenden mit den der RM und auch der UnRealmode zuverlässig läuft.

Die mitgelieferten PCMCIA-Treiber für mein eines Notebook (486er) funktionieren übrigens mit geladenem EMM386 nicht, neuere Versionen schon.

Es gibt auch einige ältere DOS-Spiele die selber in den PM schalten und kein EMM386 mögen.

Und mein VIA VX800 mag es garnicht, wenn man die Vesa-Treiber benutzt (danach funktionieren die nativen Treiber nicht mehr ohne Neustart); das mag aber schlechte Hardware sein.

Gruß,
Svenska

Ich würde immer ein System mit auswechelbarer GraKa vorziehen und Notebooks/Schlappis haben mir zu viele Mängel als das ich dazu Lust verspühren würde mich damit zu befassen.

Dirk

45

Lowlevel-Coding / Re:BIOS-Interrupts

« am: 17. April 2011, 09:43 »

Mir ist kein Bios-Interrupt bekannt der selber in den PM schaltet und wieder zurückin den RM. (Mainboad mit EFI-Bios?)

Da in keiner Spezifikation steht, dass das ausgeschlossen ist, würde ich mich nicht darauf verlassen. Prinzipiell darf jeder BIOS-Interrupt auch in den Protected Mode gehen.

Das würde aber bedeuten das man mit solchen BIOS-Interrupt kein Memmorymanager wie emm386.exe mehr verwenden kann.  Mir ist kein Rechner bekannt der nicht mehr auf diese Weise DOS-kompatibel ist.
 

Ich habe mal gelesen, dass einige Option-ROMs (SCSI-Controller, Grafikkarten) in ihren Handlern auch genau das tun.

Ich habe es nur gerüchteweise gehört, das es so etwas geben soll. Welche Karten davon nun genau betroffen sind konnnte ich jedoch noch nicht ermitteln.

Guter BIOS-Code würde im Übrigen auch dann, wenn er in den PM schaltet, alles brav wieder zurücksetzen.

Wenn emm386.exe bereits gestartet wurde, dann wird kein Bios-Interrupt selber mehr in den PM schalten können.
Ich denke aus diesem Grund werden solche Bios-Funktionen die selber in den PM schalten nicht oft anzutreffen sein und damit eine Ausnahme bleiben.

Dirk

46

Lowlevel-Coding / Re:BIOS-Interrupts

« am: 17. April 2011, 09:18 »

Hallo,


während meiner Schulzeit, also vor sehr vielen Jahren, hab ich und ein Kumpel mal versucht ein RM-Programm zu bauen das mit Hilfe von FS und GS mehr als 64 kB ansprechen sollte. Wir haben FS und GS auch anständig im PM initialisiert und sind korrekt in den RM zurückgesprungen. Das System lief auch ganz normal weiter aber irgendwann gab es dann eine GP-Exception wenn über FS oder GS mit einem Offset größer 64 kB zugegriffen wurde. Unsere Lösung war das wir einen passenden Excpetion-Handler in die RM-IDT eingetragen haben (für INT 0x0D) der einfach nur in den PM ging, FS und GS wieder passend initialisierte und dann zurück im RM ein IRET gemacht hat. Mit diesem Trick konnten wir die durchschnittliche Laufzeit unseres Programm deutlich steigern aber irgendwann krachte es trotzdem wegen irgendeiner unbehandelten Exception. Soweit ich mich noch erinnern kann hatten wir einfach Probleme im RM genau zu analysieren ob der INT nun wirklich eine Exception ist oder eben ein IRQ 5 (ein INT 0x0D wäre zwar auch möglich gewesen aber das hatten wir einfach mal ignoriert). Eigentlich sollte das kein Problem sein aber mit dem PIC kannten wir uns damals nicht so richtig aus. Einen Dissasembler der den Befehl auf den der IP auf dem Stack zeigt genau analysiert um zu erkennen ob das ein Speicherzugriff ist oder nicht erschien uns damals als zu aufwendig und einfach immer in den PM zu gehen kostete enorm viel Performance und löste das Problem trotzdem nicht vollständig. Zumindest nicht bei Programmen die die Soundkarte (welche ja IRQ 5 wollte) benutzt haben. Aber auch wenn es keinen IRQ 5 gab hielt unser Schmalspur-UnReal-Mode nicht ewig.

Es ist zwar durchaus möglich das wir das damals nicht ordentlich implementiert haben und es deswegen nicht stabil lief aber von einer ernsthaften/längeren Benutzung des UnReal-Mode kann ich persönlich trotzdem einfach nur abraten.


Grüße
Erik

Ich habe den 16 Bit UnReal-Mode schon auf mehreren x86-Rechnerplattforemen erfolgreich verwendet. Begonnen mit 80386er, 80468, mit Rechner für Sockel 5, 6, 7, Pentuim 3, 4 und jetzt Core2Quad und ich habe noch nie derartige Probleme damit feststellen können.

Ich erweiterte aber eigentlich nur DS, da man bei der Verwendung von FS, oder GS ja immer ein Segment-Prefix benutzen muss. Und so kann man auch weiterhin über DS auf das Datensegment unserer Anwendung wie gewohnt mit einem 16 Bit-Offset darauf zugreifen und nun zusätzlich mit einem 32 Bit-Offset auf den gesamten 4 GiB-Adressraum zugreifen.

Ich sehe keinen Grund auf den UnReal-Mode zu verzichten, auf unseren Rechnern lief er bisher genauso stabil und zuverlässig wie RM und PM.

Dirk

47

Lowlevel-Coding / Re:BIOS-Interrupts

« am: 15. April 2011, 07:29 »

Du willst die BIOS-Interrupts im Unrealmode ausführen? Geht das überhaupt zuverlässig, denn so ein BIOS-Code kann ja sonstwas tun?

Bios-Interrupts lassen sich entweder im RM, oder im V86-Mode, oder im 16 Bit-Unrealmode ausführen, aber nicht im PM.
Erst wenn erneut in den PM geschaltet wird und Segmente geladen werden mit anderen Einträgen bei der Segmentgrößße im dortigen GDT,
dann wird diese Segmentgröße in die Schattenregister geschrieben.

Mir ist kein Bios-Interrupt bekannt der selber in den PM schaltet und wieder zurückin den RM. (Mainboad mit EFI-Bios?)

Dirk

48

Lyrisches Eck / Ein kleines Bit

« am: 11. April 2011, 23:47 »

Es war einmal ein kleines Bit, das lebte im Land des Großvesirs Megabyte.
Er war ein grausamer Herscher. Er verlangte von jedem seiner Untertanen
daß sie immer in Gruppen von 8 sich formieren sollten. Sie durften jetzt nur
noch zusammen zur Arbeit, zusammmen Essen und Schlafen gehen.
Jeder Tag war so lang wie ein Taktzyklus. Abends, wurde der Refresh-Wagen
zur Abfütterung durch die Leiter-Bahnen-Straße gefahren.

Unser kleines Bit hatte seinen Arbeits-Platz im 3. Speicher-Block.
Es las jeden Tag die ankommenden Daten aufmerksam und schrieb
auch die Daten-Post wieder zurück. Doch eines Tages wurde es krank.
Beinahe glaubte es, es müsse nun als Dirty-Bit sein leben fristen.
Doch dann fiel ihm sein Vetter ein. Der arbeitete in einer großen Scannerfabrik.
Dort wurde es von high nach low gründlich untersucht und man stellte ihm
viele Fragen: Ob es vieleicht einem Saboteur der Virus-Bande begegnet sei,
oder ob es zu tief in den Cache geschaut habe?

Doch alles Suchen und Testen blieb erfolglos.
Vieleicht war es einfach nur schon zu alt für den anstrengen Job.
Traurig und völlig erschöpft klopfte es beim großen Megabyte an,
um seine Versetzung zu beantragen. Der Boß musterte Ihn und sagte:
Du mußt 32 Tage in die Cmos-Zelle. Dort gibt es rund um die Uhr Essen und
Trinken. Selbst wenn die große Dunkelheit kommt, wo alle Bits schlafen gehen,
mußt du wachhbleiben. Erst wenn die Götter dich wieder rausholen kannst du
deine Geschichte erzählen. Und wenn es nicht gestorben ist, kann man es heute
noch erzählen hören .....

Bibabuze.man

49

Lowlevel-Coding / Re:BIOS-Interrupts

« am: 05. April 2011, 00:05 »

Okay, jetzt wird der Code ausgefuehrt, macht aber ein paar Zicken, sobald ich in den RM springe.
Hier ist mal der Code:
....

Wird diesen 16 Bit-RM-Bios-Interrupt vom Virtual 8086 Mode aus aufgerufen, denn sonst zickt dieser Bios-Interrupt schon selber sogar noch bevor in den RM geschaltet wird herum?

Dirk

50

OS-Design / Re:booten / laden von diskette

« am: 03. April 2011, 04:15 »

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

51

Lowlevel-Coding / Re:BIOS-Interrupts

« am: 03. April 2011, 02:57 »

EIP kann man weder lesen noch schreiben. Darum geht keine IP-relative Adressierung. Es lässt sich nur über CALL und JMP verändern.

Wir können auch eine Adresse auf den Stack schieben und dann ein Rücksprung machen.

Dirk

52

OS-Design / Re:booten / laden von diskette

« am: 02. April 2011, 09:57 »

Hallo Simon.

Nach eigenen Angaben programmiert er schon 1,5 Jahre Assembler. Ich würde ihn damit nicht gerade als wirklichen Anfänger bezeichnen. Und ich denke nach 1,5 Jahren wird es möglicherweise Zeit die verschiedenen Adressierrungsarten einmal näher kennenzulernen. Und ob er nun durch eine schlichte Tabelle wo die verschiedenen Adressierungsarten ersichtlich werden nun verschreckt wurde, das kann ich so noch gar nicht erkennen, zumal er nun ein Interesse bekundete sich die Adressierungsarten einmal genauer anzuschauen. Auch meine ich das es nur wenig nütztlich ist nur um den heissen Brei herumzudebatieren, ohne mal konkrete Fakten auf den Tisch zu packen mit denen man sich auch etwas spezieller und eingehender befassen kann.

Da muss ich ganz bescheiden sagen:
Ich hab mich erstmal gefreut, das ich überhaupt etwas funktionierendes hingekriegt habe, und habe dann auf dem Niveau weiterprogrammiert.
Ich habe überhaupt keine Ahnung über Real Mode, usw...
Speicheradressierung hat mich auch noch nicht besonders beschäftigt, weil ich es nie gebraucht habe.
Ich bin sogesehen ein Anfänger
Simon

Schönen Dank das du dazu noch etwas zu sagen hast und ich freue mich das du beim Programmieren schon ein klein wenig Erfolg hattest.
Was genau hast du denn programmiert?
Du sagst das dein Programm schon größer als 512 Bytes ist. Ich denke mir das du dort wohl auch mal eine Speicheradresse beschrieben und ausgelesen hast.

Nun habe ich mal nach asmarc gesucht und diese Adresse gefunden:
http://assembler86.de/download/asmarc.exe

Im dort enthaltenen "Liesmich.txt" findet man auch nähere Details dazu z.B. unter Systemvoraussetzungen, das man ein PC mit DOS ab Version 3.x benötigt.
Dieser Assembler arbeitet also im 16 Bit-Realmode und man kann damit 16 Bit-Realmode-Programme erstellen.

Beim weiterern Stöbern fand ich dann auch ein "10.asm" im Verzeichniss "Lernprog".
Dort wird gezeigt wie man eine Zeichenkette über DOS-Funktion 0Ah eingibt und dazu wird eine Speicheradresse mit den folgenden Befehlen beschrieben:

Code: [Auswählen]

OBJECT Line:
  MaxLen DB ?                 ; 1. Feld "MaxLen"  (ein Byte groß)
  Length DB ?   
    ....
    ....
    lea  di,  Line.MaxLen
    mov  Word [di], 254
    ....
    .....
Der LEA-Befehl läd in das DI-Register die Adresse(Offset) von "Line.MaxLen".
Und der folgende MOV-Word-Befehl schreibt über DI den Wert zu dieser Adresse und der darauf folgenden Adresse("Line.Length").

Bei dieser Adressierung wird das DS-Segmentregister verwendet und die vollständige Adresse bildet sich aus "DS:DI" bzw. "DS:Line.MaxLen"
Das Daten-Segment-Register "DS" braucht man hierbei nicht extra mit in den MOV-Befehl mit angeben, da es hierbei standardmäßig zugeordnet wird, wenn man das DI-Register als Adress-Register verwendet.

...

In der von mir geposteten Intel-Postbyte-Tabelle findet man auch noch andere Adressierungarten mit den man auf eine Speicherstelle zugreifen kann.
Hiermit kannst du etwas experimentieren.

Beispiel:

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]
         .....
Ich vermute du kannst hierbei erkennen was hier in das AL-Register geladen wird.

Dirk

53

OS-Design / Re:booten / laden von diskette

« am: 01. April 2011, 10:22 »

Ich halte es dennoch für überzogen, einen Anfänger, der ein paar Grundsatzfragen gestellt hat, gleich mit einer Seite Assemblercode und zusätzlichen Details zuzubomben.

Nachfragen geht immer, verschrecken ist einfacher.

Nach eigenen Angaben programmiert er schon 1,5 Jahre Assembler. Ich würde ihn damit nicht gerade als wirklichen Anfänger bezeichnen. Und ich denke nach 1,5 Jahren wird es möglicherweise Zeit die verschiedenen Adressierrungsarten einmal näher kennenzulernen. Und ob er nun durch eine schlichte Tabelle wo die verschiedenen Adressierungsarten ersichtlich werden nun verschreckt wurde, das kann ich so noch gar nicht erkennen, zumal er nun ein Interesse bekundete sich die Adressierungsarten einmal genauer anzuschauen. Auch meine ich das es nur wenig nütztlich ist nur um den heissen Brei herumzudebatieren, ohne mal konkrete Fakten auf den Tisch zu packen mit denen man sich auch etwas spezieller und eingehender befassen kann.

Ich selber bin ja auch kein Mensch der besonders schnell lernt, doch etwas Inhalt sollte schon in einer Antwort enthalten sein, damit man eben einen konkreten Ansatzpunkt hat mit dem man sich weiterführend beschäftigen kann. In diesem Sinne weiss ich auch nicht so recht was man mit einer Antwort wie etwa "Um Betriebsmode XY zu programmieren braucht man quasi eine neue Assembler-Sprache mit vielen Änlichkeiten" überhaupt anfangen soll, dann das sagt ja eigentlich überhauptz nichts aus und der Lerneffekt wäre zumindest damit bei mir mit so einer Antwort gleich Null.

Bitte versteht das jetzt nicht als persöhnlichen Angriff, das soll jetzt keine Schelte sein und auch ich habe bestimmt noch Defizite dabei wie man ein Wissen am besten rüberbringt. Ich selber bin auch dankbar wenn an meinem Stil Kritik geübt wird, es ist ja auch nicht so einfach einen fremden Hilfesuchenden mit uns unbekannten Vorwissen richtig einzuschätzen um eine Antwort geben zu können die genau dort ansetzt wo es benötigt wird. Hier braucht man aber auch das Feedback des Fragestellers, falls man nicht gerade rein zufällig mal ins Schwarze mit seiner Antwort trifft.

Dirk

54

OS-Design / Re:booten / laden von diskette

« am: 31. March 2011, 23:37 »

Vielen Dank für das erfolgreiche Umbringen des Threads.

Wie meinst du denn das?

Ich habe doch den Thread mit konkreten Fakten am Leben gehalten an den man sich orientieren kann.

Dirk

Du hast das sicher nur gut gemeint, allerdings muss man sagen, dass es fuer einen Anfaenger zu viel sein koennte (Habe ich jetzt auch so aus seiner Reaktion gedeutet). Das geht ja schon sehr weit in die Theorie, was fuer einen ersten Ueberblick zu viel sein kann.

Ist zumindest meine Meinung

Einen Bootloader und einen eigenen Kernel zu benutzen ist nun mal mit vielen Details verbunden.
Ich würde ja auch eher zu Anfang erstmal nur kleine Anwendungen programmieren wollen, bevor ich mit einem Kernel herumspiele. Aber du hast schon recht, es ist schwer abzuschätzen womit man beginnen sollte, wenn man schon beim Threadstart mit dem Wunsch konfrontiert wird ein System mit Assembler hinzubekommen, aber die verschiedenen Adressierungarten noch nicht bekannt sind.

Dirk

55

OS-Design / Re:booten / laden von diskette

« am: 31. March 2011, 23:26 »

Hallo,

aber ab einen 80386 (mit 21 Adressleitungen) gibt es diese Beschränkung doch gar nicht mehr und man kann vergleichsweise wie im 16 Bit-Unrealmode auch im 16 Bit-PM den gesamten 4 GiB-Adressraum vollständig adressieren, vergleichsweise wie im 32 Bit-PM.

Das ist irgendwie blöd formuliert, also das mit dem 16Bit-PM.
Wenn man auf einem 386 oder höher in den PM schaltet gibt es da erstmal keinen direkten Unterschied zwischen 16Bit-PM und 32Bit-PM, erst durch die Attribute der benutzten Segmente ergibt sich dann ob die CPU nun 16Bit-Code oder 32Bit-Code ausführt.

Ja genau dieser Hinweis fehlte noch und ggf. auch kleine Programmschnipsel die zeigen welcher Opcode hierbei verwendet wird.
Doch ich dachte mir es am Anfang so einfach wie möglich zu halten.

Man kann den Segmenten eines 16Bit-PM-Programm nicht einfach so ein größeres Limit geben (um dann >64kB ansprechen zu können), dann wären es ja 32Bit-Segmente.

Aber gewiss doch, beginnend vom 16 Bit-RM können wir in den 16 Bit-PM schalten und in der GDT die Segmente-Größe z.B. des Datensegments auf 4 Gib erweitern (auf einem 80386+).
Beispiel für ein Datensegment-Eintrag in der GDT, um darüber bis zu 4 Gib zu adressieren:

Code: [Auswählen]

       DW 0FFFFh
       DW 0
       DB 0
       DB 92h
       DB 0FFh
       DB 0FFh


Man kann also im PM problemlos 16Bit-Programme und 32Bit-Programme mischen, es müssen nur die jeweils passenden Segment-Descriptoren benutzt werden und der OS-Kernel muss natürlich mit beidem umgehen können (es ist also auf jeden Fall ein 32Bit-OS nötig wenn man auch 32Bit-Programme ausführen möchte).

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.

Logisch das man 32 Bit-Anwendungen die z.B. für Linux/Windows/OS2... entwickelt wurden nicht ohne diese OS ausführen lassen kann.
Aber ein eigens entwickelter 32 Bit-Opcode kann man auch ohne ein 32 Bit-OS ausführen lassen.
Hier muss man also unterscheiden, ob die Anwendung für ein bestimmtes OS entwickelt wurde, oder eben nicht.

Das mit dem UnReal-Mode ist etwas anders, da lädt man mit einem Trick größere Limits in die Segment-Shadow-Register um eben mehr als 64kB ansprechen zu können.

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

Aber ob all diese kniffligen Dinge für einen Anfänger schon das richtige sind möchte ich dann doch bezweifeln. Ich denke für den Einstieg ist eine Hochsprache (die vor einem all diese Dinge gut versteckt) doch wesentlich besser geeignet. x86 ist eine extrem komplexe und unübersichtliche Plattform, wenn man sich da nicht gleich völlig verzetteln will sollte man sich erst einmal auf das Wesentliche konzentrieren.


Grüße
Erik

Diese Entscheidung überlasse ich jedem selber.

Mir persöhnlich macht das Programmieren mit Hochsprachen überhaupt kein Spaß und das erste was ich auf einem PC(es war ein 80286er) gelernt habe war es Debug.exe zu bedienen, noch bevor ich irgendwelche Befehle des von mir damals verwendeten MSDOS 5 überhaupt kennen gelernt habe. Damit habe ich dann die Funktionsweise der CPU erkundet und mich somit auf das Wesentliche konzentriert, denn wenn man hardwarenah programmieren möchte, dann ist es sehr zweckmäßig die genaue Funktionsweise der CPU kennen zu lernen.

Dirk

56

OS-Design / Re:booten / laden von diskette

« am: 31. March 2011, 22:26 »

Vielen Dank für das erfolgreiche Umbringen des Threads.

Wie meinst du denn das?

Ich habe doch den Thread mit konkreten Fakten am Leben gehalten an den man sich orientieren kann.

Dirk

57

OS-Design / Re:booten / laden von diskette

« am: 31. March 2011, 16:19 »

rizer: "Relative Adressierung" heißt nicht zwingend relativ zu IP oder PC. Du kannst auch relativ zu Segmenten oder relativ zu BX programmieren. Es ist aber in jedem Fall möglich.

Adressierungsarten:
Bei der indirekten Adressierung verwendet man anstelle einer fixen Adressangabe ein Offset-Register, wo die Adresse enthalten ist. Hiebei kann man verschiede Offset-Register kombinieren deren Werte zusammengerechnet die Adresse bilden auf die zugegriffen werden soll. Die Kombinationsmöglichkeiten für 80386+ bei der Verwendung von 32Bit-Offsetregister sind wie folgt deklariert und werden im sogenannten "ModR/M"-Byte, oder auch Postbyte des verwendeten Opcodes eingetragen:

http://www.timmermann.org/ralph/index.htm?http://www.ralph.timmermann.org/controller/pentium.htm


Bei der Verwendung von 16-Bit-Offset-Register können nur BX oder BP als Basis- und nur SI oder DI als Indexregister verwendet werden, der Skalenfaktor ist nicht verfügbar und das „Displacement“ auf 16 Bit beschränkt.

Siehe auch: http://tams-www.informatik.uni-hamburg.de/lehre/2001ss/proseminar/mikroprozessoren/vortraege/03-x86-befehlssatz/ausarbeitung.pdf

Code: [Auswählen]

Format of Postbyte(Mod R/M aus Intel-Doku)
------------------------------------------
MM RRR MMM

MM  - Memeory addressing mode
RRR - Register operand address
MMM - Memoy operand address

RRR Register Names
Filds  8bit  16bit  32bit
000    AL     AX     EAX
001    CL     CX     ECX
010    DL     DX     EDX
011    Bl     BX     EBX
100    AH     SP     ESP
101    CH     BP     EBP
110    DH     SI     ESI
111    BH     DI     EDI

---

16bit memory (No 32 bit memory address prefix)
MMM   Default MM Field
Field Sreg     00        01          10             11=MMM is reg
000   DS       [BX+SI]   [BX+SI+o8]  [BX+SI+o16]
001   DS       [BX+DI]   [BX+DI+o8]  [BX+DI+o16]
010   SS       [BP+SI]   [BP+SI+o8]  [BP+SI+o16]
011   SS       [BP+DI]   [BP+DI+o8]  [BP+DI+o16]
100   DS       [SI]      [SI+o8]     [SI+o16]
101   DS       [DI]      [DI+o8]     [SI+o16]
110   SS       [o16]     [BP+o8]     [BP+o16]
111   DS       [BX]      [BX+o8]     [BX+o16]
Note: MMM=110,MM=0 Default Sreg is DS !!!!

32bit memory (Has 67h 32 bit memory address prefix)
MMM   Default MM Field
Field Sreg     00        01          10             11=MMM is reg
000   DS       [EAX]     [EAX+o8]    [EAX+o32]
001   DS       [ECX]     [ECX+o8]    [ECX+o32]
010   DS       [EDX]     [EDX+o8]    [EDX+o32]
011   DS       [EBX]     [EBX+o8]    [EBX+o32]
100   SIB      [SIB]     [SIB+o8]    [SIB+o32]
101   SS       [o32]     [EBP+o8]    [EBP+o32]
110   DS       [ESI]     [ESI+o8]    [ESI+o32]
111   DS       [EDI]     [EDI+o8]    [EDI+o32]
Note: MMM=110,MM=0 Default Sreg is DS !!!!

---

SIB is (Scale/Base/Index)
SS BBB III
Note: SIB address calculated as:
<sib address>=<Base>+<Index>*(2^(Scale))

Fild   Default Base
BBB    Sreg    Register   Note
000    DS      EAX
001    DS      ECX
010    DS      EDX
011    DS      EBX
100    SS      ESP
101    DS      o32        if MM=00 (Postbyte)
SS      EBP        if MM<>00 (Postbyte)
110    SS      ESI
111    DS      EDI

Fild  Index
III   register   Note
000   EAX
001   ECX
010   EDX
011   EBX
100              never Index SS can be 00
101   EBP
110   ESI
111   EDI

Fild Scale coefficient
SS   =2^(SS)
00   1
01   2
10   4
11   8

ASM86FAQ.TXT(asm86faq.zip) auf: http://www.sac.sk/files.php?d=12&p=5
bzw. hier: ftp://ftp.sac.sk/pub/sac/text/asm86faq.zip

Dirk

58

OS-Design / Re:booten / laden von diskette

« am: 31. March 2011, 01:15 »

(max. 1 MB RAM im Real Mode, 16 MB RAM im 16-Bit Protected Mode).

Mit einem 80286 kann man im Protectmode(PM) zwar nur max. 16 MiB physikalischen Speicher adressieren, aber ab einen 80386 (mit 21 Adressleitungen) gibt es diese Beschränkung doch gar nicht mehr und man kann vergleichsweise wie im 16 Bit-Unrealmode auch im 16 Bit-PM den gesamten 4 GiB-Adressraum vollständig adressieren, vergleichsweise wie im 32 Bit-PM.

Die 32-Bit-Programmierung unterscheidet sich davon aber, es ist im Endeffekt eine neue Assemblersprache mit sehr viel Ähnlichkeit, ...

Der einzige Unterschied auf einem 80386+ zwischen dem 16 Bit-Mode und dem 32 Bit-Mode ist die Verwendung der Register-Size-, Operand-Size- und Adress-Size-Prefixe und wie die CPU folgende Operation mit und ohne diese Prefixe interpretiert und ausführt.

Für den 16 Bit-Mode muss man diese Prefixe verwenden, wenn man 32 Bit-Register, 32 Bit Operanden und/ oder 32 Bit Adressen verwenden möchte.
Bei der Verwendung von 16 Bit-Register, 16 Bit-Operanden und/oder 16 Bit-Adressen muss man im 16 Bit-Mode diese Prefixe weglassen.
Und umgekehrt im 32 Bit-Mode muss man diese Prefixe verwenden, wenn man 16 Bit-Register, 16 Bit-Operanden, oder 16 Bit-Adressen verwenden möchte
und man muss diese Prefixe weglassen, wenn man 32 Bit-Register, 32 Bit Operanden und/ oder 32 Bit Adressen verwenden möchte.

Es kehrt sich also nur die Bedeutung mit oder ohne dieser Size-Prefixe um. (Mit der adressierbaren Größe des Speichers haben beide Modi(16 Bit, 32 Bit) rein gar nichts zu tun, wenn man eine 32 Bit-CPU verwendet.)

...

Der Unterschied zwischen dem PM und dem RM, ob nun im 16 Bit-Mode, oder im 32Bit-Mode ist da schon weitaus umfassender und daher nicht mehr in nur wenigen Sätzen so schnell abgehandelt.

Dirk

59

Lowlevel-Coding / Re:getc , Tastaturtreiber

« am: 15. February 2011, 10:29 »

Hm, wen interessiert heutzutage noch DOS?

Na alle Programmierer die vom Retro-Feeling der alter DOS-Kisten begeistert sind!

Dirk

60

Lowlevel-Coding / Re:getc , Tastaturtreiber

« am: 13. February 2011, 09:58 »

Soll es für DOS sein?:

Ralf Browns Interrupt List(RBIL):
http://www.pobox.com/~ralf
http://www.pobox.com/~ralf/files.html
ftp://ftp.cs.cmu.edu/afs/cs.cmu.edu/user/ralf/pub/

RBIL->inter61b.zip->INTERRUP.F
--------D-210A-------------------------------
INT 21 - DOS 1+ - BUFFERED INPUT
   AH = 0Ah
   DS:DX -> buffer (see #01344)
Return: buffer filled with user input
Notes:   ^C/^Break are checked, and INT 23 is called if either detected
   reads from standard input, which may be redirected under DOS 2+
   if the maximum buffer size (see #01344) is set to 00h, this call returns
     immediately without reading any input
SeeAlso: AH=0Ch,INT 2F/AX=4810h

Format of DOS input buffer:
Offset   Size   Description   (Table 01344)
 00h   BYTE   maximum characters buffer can hold
 01h   BYTE   (call) number of chars from last input which may be recalled
      (ret) number of characters actually read, excluding CR
 02h  N BYTEs   actual characters read, including the final carriage return

Dirk