Eigenes OS?



  • abc.w schrieb:

    Nun wollte ich mal mit ndisasm ein wenig disassemblieren, hie und da mal schauen und schon gibt es ein kleines "Problem" mit kernel.bin. In der kernel.asm gibt es ja mal 16-Bit, mal 32-Bit Code, was mit [Bits 32] und [BITS 16] "umgeschaltet" wird. Nun, ndisasm kommt damit nicht klar oder ich kenne noch nicht die Möglichkeit, wie man es hinkriegt, dass alles zusammen sauber disassembliert wird...

    Ja, ist ein Problem. Die Situation hat man auch nicht all zu haeufig, dass man 16- und 32-Bit code in einem binary hat.
    Ehrlich gesagt bin ich in die Verlegenheit auch noch nicht wirklich gekommen, bzw. hoechstens in einem Debugger - den kann man oft bei Bedarf umschalten.

    abc.w schrieb:

    Wäre vielleicht ein Splittern der kernel.asm in zwei Dateien sinnvoll? Eine mit [BITS 16], die andere mit [BITS 32]?

    Problem beim Aufteilen waere, dass man entweder beim 2. Teil mit dem Start-Offet (org) aufpassen muesste, oder Verschnitt haette, wenn man es an eine groessere, festgelegte Adresse packt.
    Da ist die uebersichtliche Disassemblierbarkeit mit einem einfachen disasm IMHO irgendwie nachrangig.

    abc.w schrieb:

    Eine Sache bezüglich Disassemblieren noch: Am Ende des Bootloaders und des Kernels wird mit Nullen aufgefüllt (X ist 510 oder 1024):

    times X-($-$$) db 0
    

    Was würde gegen z.B. so was sprechen:

    times X-($-$$) hlt
    

    Also Auffüllen mit HLT-Befehlen... Ist nur ein Vorschlag, aber ich persönlich sehe ein Paar Vorteile:
    - beim Disassemblieren sieht man sofort, wo das Ende ist (ok, mit Nullen sieht man es auch, aber man hat lauter add [bx+si],al stehen, was irgendwie unschön ist)
    - zumindest psychologische Wirkung, man fühlt sich ruhiger, weil, wenn die CPU dort warum auch immer ankommt, bleibt sie dort stehen und es passiert nichts 🙂

    Naja, grundsaetzlich vielleicht nicht schlecht, was die Uebersicht beim Disassemblieren betrifft, hat aber ansonsten nicht viel Zweck. Ob der Rechner nun stehen bleibt bis zum naechsten IRQ oder gleich ein wenig dummes Zeug rechnet ist bei so einem gravierenden Problem dann wohl auch ein wenig egal. :p


  • Mod

    Jungs, ihr seid richtig kreativ! Macht richtig Spaß mit euch. Der eine baut einen Wrap in den Stack, dass den Profis vom osdev.org der Verstand stehen bleibt und ein anderer schlägt "times X-(-$) hlt" vor. 😃

    Das mit dem Stack auf 0 habe ich bisher noch nicht gesehen, finde es aber richtig gut. Ich habe es mir einfach als wrap vorgestellt, wie damals beim A20-Gate.

    Ich habe mal "times X-(-$) hlt" in Google eingegeben. Null Fundstellen!
    Das ist doch echt ein Grund, dies zu verwenden. 😉 Die massenweise F4 im Hex-Editor sehen richtig lustig aus: http://www.henkessoft.de/OS_Dev/Bilder/boot_bin_hex.JPG

    @abc.w: die "hlt" sind schon im Tut eingebaut und hochgeladen. 👍

    Die msg00 ist schon entfernt (ich hatte sie mal aufgehoben, weil ich dachte vielleicht bauen wir sie didaktisch noch ein, so mit keystroke und weiter ...). 😃



  • Erhard Henkes schrieb:

    Jungs, ihr seid richtig kreativ! Macht richtig Spaß mit euch. Der eine baut einen Wrap in den Stack, dass den Profis vom osdev.org der Verstand stehen bleibt und ein anderer schlägt "times X-(-$) hlt" vor. 😃

    Tja, in der Tat. 😃 So viel war hier schon laenger nicht mehr los. Ist AFAIR uebrigens inzwischen auch der laengste Thread in diesem Forum. 👍


  • Mod

    Ich habe mal "times X-(-$) hlt" in Google eingegeben. Null Fundstellen!

    Das X muss man natürlich ersetzen:
    "times 510-(-)db0"380Fundstellen(auchnichtgeradeviel,wirsindschondabei)"times510() db 0" 380 Fundstellen (auch nicht gerade viel, wir sind schon dabei) "times 510-(-$$) hlt" 1 Fundstelle: http://kldp.org/node/89199 (leider sind wir nicht Erster! 🙄 )

    "times 1024-(-)db0"20Fundstellen"times1024() db 0" 20 Fundstellen "times 1024-(-$$) hlt" 0 Fundstellen


  • Mod

    Und zum Teil ueber die A20 zunaechst noch: Ueber die Ports 60h und 64h sprichst du erstmal nur mit dem Controller auf dem Mainboard. Darueber kannst du dann (seriell) etwas an die Tastatur schicken. Und D1 an 64h ist einfach ein Kommando, das bewirkt, dass das naechste Byte auf Port 60h beim outputport landet, statt bei der Tastatur.

    Ich habe das nun hoffentlich klar genug dargestellt:
    http://www.henkessoft.de/OS_Dev/OS_Dev1.htm#mozTocId13510

    Hier würde ein Bild helfen. Muss mal nachdenken.



  • Hier ein kleiner Hinweis zur Übersicht:

    loop:
    
    (...)
    
     jmp loop :confused:
    

    Es verwirrt beim Lesen wenn ein Labelname wie ein Opcode klingt. Es wäre vielleicht besser, Opcodenamen wie "Reservierte Worte" nicht als Bezeichner zu verwenden.

    Noch was zum "Voodoo-Mode": 🙂
    Drauf verlassen kann man sich ja, solange eben nichts und niemand die Segmentregister verändert. Das wäre z.B. der Fall, wenn man vorhat, ein RM-OS zu schreiben *wegduck* und dann das Format für ausführbare Programme selbst festlegt. Oder (viel einfacher) bei bootfähigen Programmen, die die Hardware testen, oder wirklich schnell mal eine Zahl ausrechnen sollen.


  • Mod

    Es verwirrt beim Lesen wenn ein Labelname wie ein Opcode klingt. Es wäre vielleicht besser, Opcodenamen wie "Reservierte Worte" nicht als Bezeichner zu verwenden.

    Sehr guter Hinweis. Wird geändert.



  • @Erhard Henkes:
    Die Screenshots auf deiner Webseite würde ich eher im PNG-Format abspeichern und nicht als JPEG. Das hätte folgende Vorteile gegenüber JPEG:

    1. Keine unscharfen Kanten, Text bleibt daher gut lesbar.
    2. Oft kleinere Dateigröße.

  • Mod

    Die Screenshots auf deiner Webseite würde ich eher im PNG-Format abspeichern und nicht als JPEG

    Danke für den Tipp 👍
    EDIT: Ist deutlich performanter als JPG. Werde mich wohl umgewöhnen müssen. 😉



  • Noch etwas zur Integer-Arithmetik (signed/unsigned Addition vs. Subtraktion).
    Weitergeführt bis zum "Ende" würde die "RealMode" dann in etwa aussehen wie folgt:

    RealMode:
     add sp, -0x40     ; space for input buffer (64 chars)
    (...)
     add sp,  0x40     ; clean it, please
     ret
    

    Besser wäre da die "klassische" (und verständliche) Logik:

    RealMode:
     sub sp,  0x40     ; space for input buffer (64 chars)
    (...)
     add sp,  0x40     ; clean it, please
     ret
    


  • Ob nun sub oder add ist in diesem Fall wohl reine Geschmackssache. Ich versuche sub wenn moeglich aus dem Weg zu gehen, da ich das uebersichtlicher finde (es gehen auch Mythen ueber einen Geschwindigkeitsvorteil um...).
    Und wer nicht erkennt, dass
    +(-40) == -(+40)
    ist, hat noch andere Probleme als sich mit OS-Entwicklung zu befassen. 😃
    Was hat das mit "klassischer Logik" zu tun?

    Was das "clean please" betrifft: Hast natuerlich prinzipiell recht. So wuerde/koennte man das sauber in einer Prozedur mit lokalen Variablen loesen. Evtl. koennte man einen entsprechenden Kommentar platzieren.
    Der Code fuer den Prompt (was du wohl "RealMode" nennst?) ist allerdings keine klassische Prozedur und hat deshalb auch keinen Ausgang, bei dem das irgendwie sinnvoll unterzubringen waere. Anders ausgedrueckt: Wenn der Prompt verlassen und der angelegte Puffer damit nicht mehr gebraucht wird, also freigegeben werden koennte, wird jedes Mal der RM-Stack unmittelbar danach eh eingestampft.
    Assembler ist in der Hinsicht nun mal einfach keine Sprache fuer Sauberkeitsfanatiker. 😃



  • wann geht's denn nun endlich mit dem OS los?
    🙂


  • Mod

    wann geht's denn nun endlich mit dem OS los?

    Zunächst habe ich die Code-Abschnitte erklärt, z.B. die "Zeigermechanik" bezüglich des Selektors auf die Deskriptoren-Tabelle. In vielen anderen Artikeln findet man

    jmp [b]0x8[/b]:ProtectedMode
    

    und

    mov    ax, [b]0x10[/b]
        mov    ds, ax      ; data descriptor --> data, stack and extra segment
        mov    ss, ax            
        mov    es, ax
    

    , und niemand erklärt, woher die 0x8 oder 0x10 eigentlich kommen, fallen einfach vom Himmel. Die Berechnung habe ich mittels Abbildung zum Selektoraufbau und Linksshift mit dem wissenschaftlichen "Calculator" nun hoffentlich klar genug dargestellt.
    http://www.henkessoft.de/OS_Dev/OS_Dev1.htm#mozTocId533818 please check 😉

    Didaktisch bin ich noch nicht völlig zufrieden, da muss noch einiges klarer gezeichnet und umgestellt werden.
    Von dieser Seite ( http://forum.osdev.org/viewtopic.php?f=1&t=19451 ) kommen auch noch einge Randbemerkungen.

    Nun ist aber immerhin eine ansprechende Basis mit eingeschaltetem A20 Gate und Protected Mode entstanden, die sich allerdings noch völlig autistisch verhält. 😃
    Die nächsten Schritte werden dem Kernel die Innen- und Außenwelt systematisch öffnen. Ich denke hier gerade über das Was, Wie, Wann und ASM vs C und die Aufgliederung der Module nach. Auf jeden Fall möchte ich den didaktischen Aspekt ganz vorne sehen. Daher würde mich interessieren, wie Einsteiger ohne Erfahrungen in OS Development das Tutorial bisher einschätzen.



  • Erhard Henkes schrieb:

    Die nächsten Schritte werden dem Kernel die Innen- und Außenwelt systematisch öffnen. Ich denke hier gerade über das Was, Wie, Wann und ASM vs C und die Aufgliederung der Module nach.

    ok, als faustformel: alles was in C nicht so toll geht, machste in asm (z.b. umschaltung der tasks), alles andere in C. weil du ja x86 benutzt, sollteste dann auch auf die 'task state segmente' eingehen.
    🙂


  • Mod

    @+fricky: Danke für Deine Ratschläge. 🙂



  • Erhard Henkes schrieb:

    @+fricky: Danke für Deine Ratschläge.

    keine ursache. es gibt übrigens auch kernels, die ganz ohne asm auskommen. such mal nach protothreads/contiki und das hier:
    http://www.nilsenelektronikk.no/nenesos.html
    🙂


  • Mod

    Contiki is designed for microcontrollers with small amounts of memory. A typical Contiki configuration is 2 kilobytes of RAM and 40 kilobytes of ROM.

    Ist mir schon klar, wo ich mich bei dem x86-Gerödel befinde. Das Programm oder OS wird dann eben ins EEPROM geflasht (mache ich beim Asuro oder Nibo auch: http://www.henkessoft.de/Roboter/Bilder/Nibo_mit_STK500_flashen_Ausschnitt_small.jpg ) anstelle von Floppy oder Hard Disk gebootet. Übrigens sehe ich ASM nicht als Nachteil für den bisherigen OS Start.

    Mal eine andere Frage: Kennt sich jemand mit Qemu aus? Ich habe es bisher nicht geschafft, das OS damit zu booten. Lohnt es sich, sich damit herum zu quälen?

    Zum Debuggen erscheint mir der Bochs Debugger momentan ideal.
    @Nobuo T: Wie debuggst Du bei solchen Entwicklungen genau?



  • Im Abschnitt über die A20-Leitung ist mir folgendes aufgefallen:

    Es fehlt der definitive Grund, warum sie unbedingt im PM aktiviert sein muß. Ich will es mal so formulieren: Im PM kann ich auf die paar Byte, die die A20-Leitung adressiert, auch gerne verzichten. Aber warum sollte ich das lieber nicht? 🙂



  • Erhard Henkes schrieb:

    Contiki is designed for microcontrollers with small amounts of memory. A typical Contiki configuration is 2 kilobytes of RAM and 40 kilobytes of ROM.

    Ist mir schon klar, wo ich mich bei dem x86-Gerödel befinde. Das Programm oder OS wird dann eben ins EEPROM geflasht (mache ich beim Asuro oder Nibo auch: http://www.henkessoft.de/Roboter/Bilder/Nibo_mit_STK500_flashen_Ausschnitt_small.jpg ) anstelle von Floppy oder Hard Disk gebootet.

    naja, das waren ja nur beispiele, für nicht-preemptive kernels, die entweder continuations oder state machines für's task-switching benutzen. sowas muss nicht unbedingt ins flash, man kann's auch vom laufwerk booten.

    Übrigens sehe ich ASM nicht als Nachteil für den bisherigen OS Start.

    nachteil ist, je mehr asm du einsetzt, desto mehr nagelst du dein OS auf einen spezifischen prozessor fest. und wenn du so, wie bis jetzt, weiter machst, kannste dein tutorial bald in 'die geheimen tricks der x86-assembler gurus' umtaufen.
    🙂


  • Mod

    Es fehlt der definitive Grund, warum sie unbedingt im PM aktiviert sein muß. Ich will es mal so formulieren: Im PM kann ich auf die paar Byte, die die A20-Leitung adressiert, auch gerne verzichten. Aber warum sollte ich das lieber nicht?

    Im Protected Mode kann man problemlos mit 32 Bit arbeiten. Daher muss man das A20-Gate wieder aktivieren, da ansonsten bei bestimmten Speicherzugriffen Fehler auftreten, da die 21. Adressleitung deaktiviert ist. Das bedeutet, das man auf eine andere Speicherstelle zugreifen kann als beabsichtigt. Daher schaltet man A20 ein, bevor man den Kernel und weitere Programmteile startet. Ist das so o.k.?


Anmelden zum Antworten