Wie mache ich aus einer Binärdatei in Assembler einen DOS-sys-Treiber?

  • Hatte gestern wegen Kopfschmerzen und Schwindelgefühlen :( keine Lust, stundenlang auf den BIOS-Code des GA-5AX zu starren, um die letzte noch fehlende Funktion Force Snoop INV zu aktivieren. Na ja, vielleicht auch vorletzte Funktion, man findet ja nie ein Ende, sondern immer nur noch mehr Haare in der Suppe, also dem BIOS. :Aufreg Ich überlege noch, ob ich versuchen soll, die Cachefunktion für den Schatten-RAM von C0000-FFFFF zu aktivieren. Aber nur, wenn's nicht zu viel Arbeit macht :S Jedenfalls dachte ich mir, ich versuche mal, mein neu erworbenes Wissen in der Praxis einzusetzen, um dieses Problem zu lösen:

    Nicht aus Frust, sondern einfach nur weil das Treffen im Südwesten morgen nicht stattfindet, habe ich die Arbeit am Aladdin 7 vorerst eingestellt. Schaut im Moment so aus:

    Alle Laufwerke drinnen und verkabelt. DR-DOS 7.03 ist installiert aber noch ohne Sound- und Netzwerkkartentreiber. Im Real-Mode mit HIMEM.SYS hab ich keine UMBs, da UMBPCI.SYS den Chipsatz nicht kennt :( Datenblätter für die Northbridge konnte ich auch keine auftreiben


    Soweit ich die Funktionsweise von UMBPCI.SYS richtig verstanden habe, aktiviert es den Schreib-/Lesezugriff für die Schatten-RAM-Bereiche, indem es die entsprechende Konfiguration in den Chipsatzregistern ändert und unter MS-DOS die Funktion "Request XMS-UMB" bereitstellt. Zum Glück verwende ich DR DOS und benötige daher letztere Funktion nicht. Lt. Dokumentation zu UMBPCI müßte es also reichen die RAM-Bereiche zu aktivieren, den Rest macht dann der Speichermanager von DR DOS selbst. :)

    Leider ist das ohne Datenblatt nicht so ganz trivial, weil man ja die Offsets der dazu benötigten Register nicht kennt. Aber nach ein bißchen Reverse Engineering und mit etwas Intuition bei der Interpretation der Registerwerte habe ich eine Vorstellung davon, welche Offsets beim Aladdin 7 geändert werden müssen, um den Schreib-/Lesezugriff auf die RAM-Bereich C0000-FFFFF zu ermöglichen. Das will ich nun testen.

    Das dazu nötige Programm kann ich in Assembler schreiben. Das funktioniert jedoch nur, wenn ich es im BIOS ausführe, was ich wiederum nicht will, da es nur unter DOS, aber nicht unter Win98SE laufen soll.


    Wie mache ich nun aus einem Assemblerprogramm eine SYS-Datei, die ich als Treiber in der CONFIG.SYS laden kann?

    Ich werde mich von keinem einzzzigen Prozzzessor trennen.
    Jedoch lockt es mich beinahe, ihn Dir zu überlassen, nur um zu sehen, wie er Dich in den Wahnsinn treibt :evil:


    Meine Begehren

  • Wenn ich mich richtig erinnere: Es hat in den meisten Fällen keinen Vorteil eine .SYS zu erstellen, abgesehen davon dass der Treiber in der config.sys vor der der autoexec.bat geladen wird. Es ist einfacher und flexibler einen .COM-TSR zu schreiben. Damit kannst Du dieselben Funktionen realisieren.


    Ich hatte viele Geräte-Treiber geschrieben und dabei immer auf .COM gesetzt...


    Wenn Du einfach nur ein paar Register ändern und das Ergebnis ansehen willst: .COM

  • Nun, der Treiber muß als erster in der config.sys noch vor dem Speichermanager geladen werden, da letzterer ja sonst den Schatten-RAM nicht in UMBs umwandeln kann. Wenn's auch mit einer com geht, soll's mir recht sein. Reicht es, dazu ein org 100h vor den Code zu stellen, also in etwa so:


    Gibt es auch für Linux einen Compiler, der mir eine com erstellen kann? Mein aktuellstes Windows ist zur Zeit 98SE :whistling:

    Ich werde mich von keinem einzzzigen Prozzzessor trennen.
    Jedoch lockt es mich beinahe, ihn Dir zu überlassen, nur um zu sehen, wie er Dich in den Wahnsinn treibt :evil:


    Meine Begehren

    Einmal editiert, zuletzt von Lotosdrache ()

  • Nee, wenn es am Anfang in die config.sys soll musst es wohl ein .SYS sein. Die Struktur ist eher kompliziert. Ich habe keine Ahnung mit welchem Compiler man die erstellen kann.


    Du kannst es so zumindest mal als .COM ausprobieren und schauen ob es tut was es soll. Irgendwas zur Programmbeendigung brauchst Du noch in Zeile 15.


    Wenn es funktioniert würde ich mir die .SYS einfach mit einem HEX-Editor zusammenbauen, damit bist Du bei so einem kleinen Programm schneller fertig als irgendwelche Tools auszuprobieren...nimm Dir einen anderen einfachen SYS-Treiber als Template und bau den um ;)

  • Du kannst es so zumindest mal als .COM ausprobieren und schauen ob es tut was es soll. Irgendwas zur Programmbeendigung brauchst Du noch in Zeile 15.

    Upsi, hab noch ein END eingefügt, kompiliert und es mal beim Start von Win98SE in der autoexec.bat ausführen lassen - allerdings erst einmal auf einem Aladdin V-Board, da über diesen Chipsatz ja alles bekannt ist.

    Was soll ich sagen :?: Es tut, was es tun soll. Mal sehen, wie's bei DR DOS aussieht. Das kann mehr aus der config.sys heraus starten als MS-DOS.

    Ich werde mich von keinem einzzzigen Prozzzessor trennen.
    Jedoch lockt es mich beinahe, ihn Dir zu überlassen, nur um zu sehen, wie er Dich in den Wahnsinn treibt :evil:


    Meine Begehren

  • War dann doch etwas enttäuscht heute vormittag. Konnte die Datei nicht aus der config.sys heraus starten. Es kam irgendwas mit SECURITY.BIN 1.13 und das System hing fest. Auch die Versuche, nur einzelne Bereiche ohne die Cachefunktion zu aktivieren, scheiterten. ;( Vom DOS-Prompt aus ging es, aber das hilft ja nicht, wenn der Speichermanager nicht mehr mitbekommt, daß die Shadowregionen freigeschaltet wurden.

    :-heul:-heul:-heul:-heul:-heul:-heul:-heul


    Wenigstens breitete der Lammbraten beim Mittagessen eine wohlige Wärme in mir aus und ich war tiefenentspannt, fast schon :schlaf:. Da fiel mir ein, ich hatte den falschen Befehl benutzt. EXE- und COM-Dateien in der CONFIG.SYS werden nicht mit DEVICE= sondern mit INSTALL=C:\COMMAND.COM /c geladen :mist:mist:mist


    Also zurück ans Reißbrett, CONFIG.SYS editiert und


    ES GEHT :-party


    Also sofort für jede der 16 Regionen einen eigenen Treiber geschrieben und alle einzeln getestet. Ergebnis:

    Mein Reverse Engineering zum Auffinden der Registeroffsets für das E-Segment und zur Funktionsableitung der einzelnen Bits scheint richtig zu sein. Meine Intuition zur Ableitung der Registeroffsets für das C- und D-Segment aus den WPCRedit Registerwerten und deren Lage relativ zu den Offsets des E-Segments ebenfalls. :D Nur die Offsets für das F-Segment konnte ich nicht verifizieren. DR-DOS weigert sich bei mir beharrlich irgendwas nach F000-F7FF hochzuladen, obwohl das, nach allem was man so liest, gehen soll. Aber das war auch schon beim Aladdin V so X(


    Nun ja. Jetzt ist der DOS-REAL-Mode mit himem.sys jedenfalls schon viel praxistauglicher. Freier Konventioneller Speicher:

    ohne NIC, ohne UMB: 562.912 ( 550K ) REAL.TXT

    ohne NIC, mit UMB: 636.192 ( 621K ) REAL+UMB.TXT

    mit NIC, ohne UMB: 402.384 ( 393K ) REAL+NIC.TXT

    mit NIC, mit UMB: 560.336 ( 547K ) REAL+UMB+NIC.TXT

    Die 3Com-Netzwerktreiber bringen einen halt jedesmal ganz schön in die Bredouille. :rolleyes:


    Dank sei DR-DOS!!! Daß es nicht so dämlich ist wie MS-DOS :P , COM-Dateien in der config.sys starten kann und ohne UMBPCI.SYS auskommt. :thumbup:

    :tanzend:tanzend:tanzend

    Ich werde mich von keinem einzzzigen Prozzzessor trennen.
    Jedoch lockt es mich beinahe, ihn Dir zu überlassen, nur um zu sehen, wie er Dich in den Wahnsinn treibt :evil:


    Meine Begehren

    2 Mal editiert, zuletzt von Lotosdrache ()

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!