Eigenes OS?


  • Mod

    Bell

    Was noch fehlt ist "bell". :p

    '\a': Was soll denn da passieren?
    Ich habe es gerade mal ausprobiert:

    #include <iostream>
    
    int main()
    {
     for(int i=0;i<100;++i)
         std::cout << '\a' << "bell ";
    }
    

    Da kam nichts aus meinem PC! 😃
    Ich habe einen speaker code (timer, channel 2) probiert, aber da ist alles abgestürzt, hier ist der Code, ging aber nicht, alles abgestürzt. 🙄
    ..


  • Mod

    Als Belohnung für die, die bisher dabei geblieben sind:
    http://www.youtube.com/watch?v=_RyodnisVvU 😉
    http://www.youtube.com/watch?v=o8VqCqpfWrk



  • Erhard Henkes schrieb:

    http://www.youtube.com/watch?v=o8VqCqpfWrk

    *gähn*
    das sind coole roboter: http://www.bostondynamics.com/content/sec.php?section=robotics
    (mit verbrennungsmotor und so)
    🙂


  • Mod

    OK, will niemanden langweilen, also "back to the grindstone":
    http://www.henkessoft.de/OS_Dev/Downloads/PrettyOS_last_version.zip

    Ich habe die GDT/IDT-Infos und Timer-Späßchen auf dem Screen lahm gelegt und begonnen, den Keyboard Treiber zu überarbeiten, damit man endlich Texte mit automatischem Zeilenumbruch und Scroll eintippen kann, so eine Art Primitiv-Editor eben. Nobuo T dürfte sich freuen, die while(TRUE) Story ist vorbei, nun läuft es nur einmal den "Scanner" durch, wie es logischer ist. BACKSPACE, TAB und ENTER funktionieren, aber man hat noch keine Steuerung mit den Pfeiltasten (da bin ich noch vorsichtig, ein move_cursor_right() ist allerdings schon eingebaut; Orientierung an schwarzer DOS-Box (cmd)?), diesbezüglich muss man also noch "übertippen" bzw. sich mit der Kombination aus TAB und BACKSPACE korrekt positionieren. Pos1, Ende, Entf ... sind auch noch nicht aktiviert. Das läuft ja alles via putc(...) als default im printformat(...), siehe keyboard_handler(...).
    ..

    Was fehlt eurer Meinung nach noch bei dem EDIT-Modus des OS?
    "Befehle" würde man dann wohl per ENTER entgegen nehmen?
    In einem strcmp (analog zur Methode im Real Mode, jetzt nur in C) vergleichen und entsprechend über eine switch/case-Kontrollstruktur reagieren?
    Welche Befehle würdet ihr denn als ersten Schritt implementieren?
    - Info/info
    - Help/help/?
    - Reboot/reboot
    - ...


  • Mod

    Damit wir nicht den Gesamtüberblick verlieren, hier eine rohe Tasklist / Sammlung aus den bisherigen Posts:

    - PIC (die beiden PICs wurden bereits beim remapping von IRQ 0-15 verarbeitet)
    - PIT (programmable interval timer)
    - Speaker (ja, BEEP (frequence)! Seit Win NT kaputt wegen Behinderung.)
    - (video.c vernünftig ausbauen, bisher nur rudimentär)
    - OS-Thematik (generell)
    - Dynamische RAM Verwaltung:
    - Unterteilung des Speichers in Blöcke statischer Groesse (4KB)
    - Verwaltung (stat. Arrays, Bitmaps, dynam. Free-Lists)
    - Reservierungsstrategie next fit
    - Wiedereingliederungsproblematik
    - Paging
    - Programme & Prozesse
    - Multitasking vs Singletasking
    - Prozesserzeugung, Kontextwechsel, Scheduling, Verdrängung
    - Privilegien / Schutzmechanismen / Adressraumtrennung
    - Micro- vs Macro-Kernel
    - inter-process communication

    - Kernel-API (und einem HW-Abstraktions/Treiber-Prinzip).
    Alle Kernel-Funktionen, Treiber etc. einfach nur ueber C-Funktionen und header zur Verfuegung zu stellen,
    ist sicher nicht das Wahre. Ich wuerde die Einrichtung eines kleinen Sets der wichtigsten Funktionen zum
    I/O und spaeter dann Speicher- und Prozessverwaltung ueber Interrupts aehnlich DOS oder Linux vorschlagen.
    Je nachdem, was fuer einen Kern du basteln willst (Micro oder Monolith), waere es evtl. sinnvoll,
    das schon ganz am Anfang beim Aufbauen der ersten abstrakteren OS-Funktionen wie RAM-Verwaltung zu diskutieren,
    statt erst bei Adressraumtrennung, Privilegien und IPC. Evtl. mit Verweis auf diese spaeteren Themen zur Begruendung.

    - Was du da weiter anfuehrst, sind doch eher Spezialfaelle und Teilgebiete, des Themenbereichs Scheduling
    (Echtzeit-Prozesse). Solche Ansaetze wie Prioritaetensteuerung oder verschiedene Ansaetze fairer Ressourcenverteilung
    mit verschiedensten abgefahrenen queue-Konstrukten (da gibt es wirklich eine Menge weit komplizierteres
    als einfache Prioritaetensteuerung) kann man da vielleicht in einem Ueberblick kurz anschneiden,
    aber um den Rahmen nicht zu sprengen, waere mein Vorschlag, sich schliesslich einfach auf Round Robin zu beschraenken.

    - DMA-Gefrickel ist ja nun voellig abgehoben. Immer im Hinterkopf behalten, dass das ein Internet-Tutorial
    und kein Kompendium zur OS-Entwicklung werden soll - das wird wie ich das sehe schon so eine ordentliche Portion Stoff.

    Timer:
    - für frei laufende countdown-timer machste dir z.b. ein paar funktionen:
    // erzeugt einen neuen timer und meldet ihn beim OS an. gibt 0 zurück, wenn kein timer alloziert werden konnte
    timer_t *timer_create(void);

    // startet den timer, der ab jetzt vom OS von 'timeout' bis 0 runtergezählt wird
    void timer_start (timer_t *timer, unsigned long timeout);

    // prüft ob der timer abgelaufen ist, gibt 0 zurück, wenn der timer noch läuft, sonst 1
    int timer_expired (timer *t);

    // beseitigt den timer (trägt ihn z.b. aus der liste des OS aus und gibt seinen speicher frei)
    void timer_free (timer_t *timer);

    die hardware-isr schaut bei jedem tick in eine verkettete liste, ob timer drin sind, die sie runterzählen muss.

    Keyboard:
    - zu den I/O-daten: am besten du benutzt FIFO-buffer für sowas.
    die ISR (z.b. von der tastatur) trägt empfangene daten in den FIFO ein und die anwendung holt sie sich raus.
    ein tastatur-FIFO kann recht klein sein und darf ältere daten überschreiben, weil uralte tastendrücke ja nicht mehr interessieren.
    ein benutzer-prozess kann dann einfach zeichen aus dem FIFO holen, z.b. so:
    // hole ein zeichen aus dem tastatur-buffer. wenn c -1 (oder EOF) ist, war der FIFO leer
    int c = getchar();



  • Erhard Henkes schrieb:

    Was fehlt eurer Meinung nach noch bei dem EDIT-Modus des OS?

    vi-Kompatibilitätsmodus? 😉


  • Mod

    vi-Kompatibilitätsmodus?

    Interessanter Punkt. Ich kenne bisher nur dieses gvim und kann mich nur noch dunkel an den DOS editor (EDIT) erinnern. Arbeitet vi wie gvim?



  • Erhard Henkes schrieb:

    vi-Kompatibilitätsmodus?

    Interessanter Punkt. Ich kenne bisher nur dieses gvim und kann mich nur noch dunkel an den DOS editor (EDIT) erinnern. Arbeitet vi wie gvim?

    vim ist ein aufgemotzter vi, also voll kompatibel, aber genau so besch... in der bedienung. btw, ein editor ist doch kein bestandteil eines OS, sondern nur eine gewöhnliche anwendnung. mach besser mit'm OS weiter und nicht noch 'ne baustelle auf.
    🙂


  • Mod

    ein editor ist doch kein bestandteil eines OS, sondern nur eine gewöhnliche anwendnung. mach besser mit'm OS weiter und nicht noch 'ne baustelle auf.

    "Festina lente" sagt der Lateiner (Lieblingsspruch des Kaisers Augustus). Mir geht es aktuell darum, keyboard.c und video.c vernünftig zu stabilisieren. Diese beiden Module mit ihren Funktionen sind wichtig. Das wird dann auch das Ende von Teil 1 (Booten, RM, A20 Gate, RM -> PM, asm <-> C, GDT, IDT u. IRQ, video, timer und keyboard). Bei Teil 2 geht es mit dem wirklichen OS (Speicher, Multitasking, Prozesse, API, ...) weiter. Aber zuerst muss Teil 1 so abgerundet sein, dass man dort niemand verliert.

    Ein echter Editor ist in der Tat ein User-Programm, gehört also nicht zwingend zum OS. Daher werde ich mich bezüglich der Bedienung an den DOS- und Linux-Konsolen orientieren.

    Noch eine Detail-Frage: Über den PIT bin ich ja etwas weg gegangen, akzeptiere bisher die Standardeinstellung. Sollte man so etwas in der Art noch einbauen:

    void systemTimer_setFrequency( ULONG freq ) 
    {
       ULONG divisor = 1193180 / freq; //divisor must fit into 16 bits
    
       //TODO: save frequency globally
    
       // Send the command byte.
       outportb(0x43, 0x36);
    
       // Send divisor.
       outportb(0x40, (UCHAR)(  divisor     & 0xFF )); // low  byte
       outportb(0x40, (UCHAR)( (divisor>>8) & 0xFF )); // high byte
    }
    

    Ich habe es mal mit 100 Hz (Standard: ca. 18 Hz), also alle 10 ms ein Tick, probiert:

    void timer_install()
    {
        /* Installs 'timer_handler' to IRQ0 */
        irq_install_handler(0, timer_handler);
        systemTimer_setFrequency( 100 );
    }
    
    void sleepSeconds (ULONG seconds)
    {
        // timer_wait((ULONG)18.2065*seconds); // standard
        timer_wait((ULONG)100*seconds);
    }
    

    Macht das mit 100 Hz Sinn? Sollte man hier eine Auswahl bieten oder eine Festeinstellung vornehmen? (wird für IRQ-gesteuertes Multitasking interessant)

    Beim Keyboard verwende ich nun auch gespeicherte Cursors, falls man z.B. Infos in eine Statuszeile schreibt:

    void keyboard_handler(struct regs* r)
    {
       UCHAR KEY;
       KEY = k_getch();
       restore_cursor();
       printformat("%c",KEY); // the ASCII character
       save_cursor();
    }
    

    ckernel.c:

    #include "os.h"
    
    int main()
    {
        k_clear_screen();
    
        // GDT, IDT, ISRS, IRQ, timer, keyboard
        gdt_install();
        idt_install();
        isrs_install();
        irq_install();
        timer_install(); //jetzt incl. Frequenz
        keyboard_install();
        sti();
    
        set_cursor(0,0);
        printformat("   ************************************************\n");
        printformat("   *                                              *\n");
        printformat("   *          Welcome to PrettyOS 0.05            *\n");
        printformat("   *                                              *\n");
        printformat("   *        The C kernel has been loaded.         *\n");
        printformat("   *                                              *\n");
        printformat("   ************************************************\n");
    
        settextcolor(4,1);
    
        int y=10;
        while(TRUE)
        {
    	sleepSeconds(20);
    	if(y>24) y=24;
    	set_cursor(0,++y);
    	printformat("10 sec have passed");
        };
        return 0;
    };
    

    In Bochs klappt dies ganz gut mit den 100 Hz.

    Allgemein:
    Bezüglich des OS überdenke ich momentan die Reihenfolge. Wäre nun das "Paging" als nächster Schritt angesagt? Man kann diesem Mechanismus ja doch nicht wirklich entfliehen, und ich möchte wegen des interessanten inneren Aufbaus ein Multitasking-OS aufbauen.



  • Erhard Henkes schrieb:

    Wäre nun das "Paging" als nächster Schritt angesagt? Man kann diesem Mechanismus ja doch nicht wirklich entfliehen, und ich möchte wegen des interessanten inneren Aufbaus ein Multitasking-OS aufbauen.

    naja, virtual memory und paging/swapping/was-auch-immer kannste auch später noch einbauen. multitasking geht auch, ohne mmu und isolation des speichers der prozesse voneinander. nachträglich lässt sich virtual memory transparent ins system integrieren, ohne dass grossartige umbauten nötig sind. wenn dich das thema interessiert, kannste natürlich sofort damit loslegen. aber irgendwie werd' ich das gefühl nicht los, dass du dir sowas wie 'nen projektplan machen solltest.
    🙂


  • Mod

    projektplan

    @+fricky: Du siehst das IMHO sehr schematisch. "Projekte" sind zumeist langweilig, ökonomisch getrieben und haben einen engen Zielkorridor. So etwas interessiert mich nur beruflich.

    Experimente schaffen dagegen wirklich Neues. Ich habe weitgehend klare Vorstellungen von der prinzipiellen Vorgehensweise. Obwohl es keine klare Theorie über den optimalen Weg gibt, werden vielfach bestehende OS als Ziel nachgeahmt. Als Ziel schwebt mir ein lernfähiges und bezüglich der Anforderungen adaptives OS vor, bin aber nicht sicher, ob dies im ersten Ansatz erreichbar ist.

    Zur Zeit geht es erst einmal darum, die Basics stabil und dennoch flexibel zu arrangieren, um zum Experimentieren einzuladen. Das Ganze kann sich auch gabeln, wenn es darum geht interessante Pfade zu verfolgen. Bisher denke ich, habe ich hoffentlich noch keinen neuen wirklich verfolgenswerten Ansatz übersehen.

    Einen Fehler muss ich allerdings gestehen, nämlich das Tutorial in deutsch aufgesetzt zu haben. Damit halte ich einige interessierte Mitstreiter aus aller Welt auf Distanz. Vielleicht kann ich noch kapitelweise englische Summaries einflechten, die das Nachvollziehen/Mitdenken erlauben.



  • Erhard Henkes schrieb:

    Einen Fehler muss ich allerdings gestehen, nämlich das Tutorial in deutsch aufgesetzt zu haben. Damit halte ich einige interessierte Mitstreiter aus aller Welt auf Distanz. Vielleicht kann ich noch kapitelweise englische Summaries einflechten, die das Nachvollziehen/Mitdenken erlauben.

    wenn du anklingen läßt, daß du dich freuen würdest, wenn das jemand übersetzen würde, dann findet sich vermutlich auch jemand, der sich freut, das offiziell zu übersetzen, natürlich mit namensnennung und link auf die hp des edlen helfers.


  • Mod

    wenn du anklingen läßt, daß du dich freuen würdest, wenn das jemand übersetzen würde, dann findet sich vermutlich auch jemand, der sich freut, das offiziell zu übersetzen, natürlich mit namensnennung und link auf die hp des edlen helfers.

    Nein, daran habe ich wirklich nicht gedacht, da das Tutorial noch zu sehr im Fluss ist. Vorne den Abschnitt im Real Mode könnte man z.B. noch mit interessanten Befehlen/Funktionen aufbohren. Ich finde z.B. dein C++-Tutorial als didaktisches Vorbild super. Solche Fragestellungen mit Lösungen sind wirklich schön, weil man dadurch die Leser zum Experimentieren und selbst denken anregen kann. Es geht mir darum, auf praktische Weise zu zeigen, welche "Bausteine" beim OS-Bau zur Verfügung stehen, wie diese funktionieren und was man damit praktisch machen kann.


  • Mod

    Zunächst muss ich die Funktionen innerhalb video.c an allgemein übliche Vorgehensweisen anpassen. Mir ist z.B. aufgefallen, dass das "Backspace" noch nicht "löscht", das scheint aber üblich zu sein. http://de.wikipedia.org/wiki/Backspace
    "Rücklöschtaste". Das und einiges andere muss ich zunächst anpassen, bevor es weiter geht. So, das sieht schon besser aus, sogar rekursiv 😃 :
    Bei P(0,0) macht es gar nichts mehr, ansonsten geht es eins zurück, löscht (druckt ' ') und geht wieder eins zurück. Am Zeilenanfang muss ein Rücksprung ans Zeilenende eins höher erfolgen.

    void putch(UCHAR c)
    {
        USHORT* pos;
        UINT att = attrib << 8;
    
        if(c == 0x08) // backspace: move the cursor back one space and delete
        {
            if(csr_x)
            {
                --csr_x;
                putch(' ');
                --csr_x;
            }
            if(!csr_x && csr_y>0)
            {
                csr_x=79;
                --csr_y;
                putch(' ');
                csr_x=79;
                --csr_y;
            }
    
        }
        // ...
    }
    

    Der Keyboard Handler fängt jetzt auch an, sich um die Sondertasten zu kümmern:

    void keyboard_handler(struct regs* r)
    {
       UCHAR KEY;
       KEY = k_getch();
       restore_cursor();
       switch(KEY)
       {
           case KINS:
               break;
           case KDEL:
               move_cursor_right();
               putch('\b');//BACKSPACE
               break;
           case KHOME:
               move_cursor_home();
               break;
           case KEND:
               move_cursor_end();
               break;
           case KPGUP:
               break;
           case KPGDN:
               break;
           case KLEFT:
               move_cursor_left();
               break;
           case KUP:
               break;
           case KDOWN:
               break;
           case KRIGHT:
               move_cursor_right();
               break;
           default:
               printformat("%c",KEY); // the ASCII character
               break;
       }
       save_cursor();
    }
    

    In video.c musste auch noch einiges hinzu gefügt werden.

    void move_cursor_right()
    {
        ++csr_x;
        if(csr_x>=80)
        {
          ++csr_y;
          csr_x=0;
        }
    }
    
    void move_cursor_left()
    {
        if(csr_x)
            --csr_x;
        if(!csr_x && csr_y>0)
        {
            csr_x=79;
            --csr_y;
        }
    }
    
    void move_cursor_home()
    {
        csr_x = 0; update_cursor();
    }
    
    void move_cursor_end()
    {
        csr_x = 79; update_cursor();
    }
    

    wie üblich:
    http://www.henkessoft.de/OS_Dev/Downloads/PrettyOS_last_version.zip

    Wenn jemand hier bessere Ideen hat, bitte posten.
    Ich bin mir z.B. noch nicht sicher, ob man bei der Instruktionseingabe überhaupt einen Wechsel der Zeile - und damit mehrzeilige Eingaben - zulassen sollte.
    Bei END springe ich an das Ende der Zeile und nicht an das Ende des Eingetippten. Bei DEL lösche ich auch nur ein Zeichen und schiebe nicht den Rest der Zeile eins nach links.
    Vielleicht müsste man zwischen zwei ENTER einen virtuellen Befehlsstring aufbauen, der von HOME bis END geht. Zumindest sieht es bei der DOS-Box (Konsole) so aus. Da bin ich noch flexibel.



  • Ist auch einfach die Frage, wie komfortabel Du das überhaupt gestalten möchtest.
    Ein grundlegender Kommandointerpreter könnte ja einen eigenen Editor mitbringen, sodaß etwas Rudimentäres vollkommen ausreicht. Auf der anderen Seite kannst Du's im Kernel aber bis zum kompletten Memoryhexeditor treiben 😉



  • IMHO haben konkrete Reaktionen auf Tasteneingaben im IRQ-Handler (HW-Treiber) nichts zu suchen. Das sind Teile einer Anwendung. Ist vielleicht so zu Demo-Zwecken ganz nett, aber mit brauchbarem OS-Design hat das nichts zu tun.
    Irgendwie macht das so immer noch den Eindruck, als wuerdest du die Sache ein wenig wie dieses erste Polling-Relikt behandeln.
    Also entweder ueberlegst du dir ein vernuenftiges Treiber-Design und machst bei keyboard und video dann mal langsam die Kiste zu (das bedeutet auch, dass du kapselnde Funktionen brauchst, falls du mal mit dem Entwurf einer echten API anfaengst), dann kannst du auf diesen abgeschlossenen Treibern auch etwas rumbasteln, das ueber den Rest des Tutorials im Prinzip so funktionieren sollte, oder du beschraenkst dich hier nur auf das absolut notwendigste. Solche aufwendigen, dennoch halbgaren und bestenfalls bis zum Ende dieses Kapitels brauchbaren Basteleien sind IMHO kontraproduktiv.


  • Mod

    IMHO haben konkrete Reaktionen auf Tasteneingaben im IRQ-Handler (HW-Treiber) nichts zu suchen. Das sind Teile einer Anwendung. Ist vielleicht so zu Demo-Zwecken ganz nett, aber mit brauchbarem OS-Design hat das nichts zu tun.

    Ja, das ist völlig richtig. Ich werde jetzt bei video.c und keyboard.c aufhören, als kleine Demo reichen diese Funktionen bereits. "Externe Anwendungen" sind noch nicht lauffähig. Was ich auf der Stufe noch einfügen möchte, ist ein Kommandozeileninterpreter mit nachgeschaltetem strcmp(...) und entsprechenden Reaktionen so wie beim Real Mode, am besten in main(), diesmal nur in C programmiert und ohne BIOS. Diese Parallele erwartet man irgendwie. 🙂
    Dann geht's im zweiten Teil thematisch mit Paging, Heap, Designfragen weiter. Das wird dann aber alles elend komplex. Da knabbere ich noch dran. Zur Zeit beschimpft mich sogar schon mein Linker, weil ich Paging und Heap modular nicht sauber auseinander halte. Übel, übel, .... 😃
    EDIT: zumindest das endlich geschafft. 😃

    @Nobuo T: Wenn ich Dich richtig verstanden habe, würdest Du im Keyboard Handler die Information in eine Queue stecken. Der Kommandozeilen-Interpreter (wo gehört der als "Anwendung" hin? Für mich ist dies noch Teil des Kernels.) müsste sich diese dann dort abholen und verarbeiten, so wie jetzt - zur Demo - bereits im Keyboard Handler erfolgt, richtig? Der Kommandozeilen-Interpreter muss ein Prompt drucken, nach ENTER die Zeile (ohne Prompt) schlucken und verarbeiten mittels strcmp und switch/case-Struktur (wie bei einer Windows-Nachrichten-Pumpe).



  • Der Keyboardhandler sollte die Eingaben nicht in eine eigene Queue fließen lassen, sondern gleich an die Queue der aktiven Anwendung.
    Deshalb würde ich als nächstes damit beginnen Grundstrukturen für Anwendungen zu definieren. Da gehören dann auch die Schnittstellen zu Treibern dazu.

    Wenn man die Grundstrukturen hat, dann am besten gleich Multitasking/threading und nen einfach Scheduler einbauen, dann macht es einfach mehr Spaß.

    Man kann auch erst mal die Schnittstellen zu den Treibern weglassen und einfach ein paar Anwendungen laufen lassen. Die könnten dann ja alle gleichzeitig in den Bildschirm malen.

    Wenn man erst mal zwischen Anwendungen und Kern/System getrennt hat, dann ist es einfacher die Schnittstellen zu entdecken und zu bauen. Das diese dann gleich so angenehm wie möglich sind ist natürlich noch eine ganz andere Frage.

    jenz


  • Mod

    zwischen Anwendungen und Kern/System getrennt

    Ja, das ist wohl der entscheidende Punkt.

    Der Keyboardhandler sollte die Eingaben nicht in eine eigene Queue fließen lassen, sondern gleich an die Queue der aktiven Anwendung.

    Ja, das klingt sinnvoll, damit es keine Verwechslungsprobleme beim Leeren eines gemeinsamen Briefkastens gibt. Das Problem ist, dass wir noch keine Anwendungen laufen lassen können, weil die Strukturen hierzu noch fehlen. Würdest Du den Kommandozeileninterpreter bereits als Anwendung in Privilegstufe 3 laufen lassen?

    Am besten gleich Multitasking/Threading und 'nen einfachen Scheduler einbauen, dann macht es einfach mehr Spaß.

    Spaß klingt gut. 🙂

    Man kann auch erst mal die Schnittstellen zu den Treibern weglassen und einfach ein paar Anwendungen laufen lassen. Die könnten dann ja alle gleichzeitig in den Bildschirm malen.

    Das mache ich momentan mit dem Timer und dem "Editor" Keyboard Handler ja auch, deshalb musste ich schon den Cursor speichern.

    Ich experimentiere gerade mit einem Paging-/Heap-Modul, ist kompliziert (schlecht für Didaktik), miteinander vernetzt und klappt leider noch nicht, wie ich es will. Das wollte ich als nächsten Schritt einfügen, noch bevor die Anwendungen im Multitasking laufen. Das gehört aber alles nach Teil 2, der leider viel Zeit braucht (liegt an meinen beschränkten Fähigkeiten und Erfahrungen in diesem Bereich). Macht aber nichts, fahre ja kein Wettrennen.

    Teil 1 wollte ich mit einem kleinen Befehlsinterpreter im Kernel (Analogie zur Vorgehensweise im RM) beenden, damit die eingetippten Zeichen Sinn machen. Kann man aber in Teil 2 wohl alles wegwerfen, da hat Nobuo T leider Recht. 🙄
    Sehe ich aber nicht als großes Problem.
    EDIT: Vielleicht kann man die Idee mit dem BIOS-Briefkasten und dem Abholen der Post dort durch einen Befehlsinterpreter kombinieren. 🙂



  • Klar waere es ein praktisches Konzept, eine KB-queue pro Anwendung einzurichten. Da das OS in diesem Stadium aber noch nicht mal ein Konzept fuer Anwendungen hat, ist das alles noch Zukunftsmusik und erst im naechsten Kapitel ausfuehrlich zu diskutieren.
    Eine globale queue zum Ablegen der KB-Codes (so macht es das BIOS auch) waere im Moment sicher am praktischsten. Diese liesse sich spaeter auch relativ einfach entsprechend den Beduerfnissen des Multitaskings anpassen.
    Die ISR liest also die Scancodes vom KB, setzt die Flags, wandelt in ASCII-Codes um, o.Ae. und eine getch-Funktion (vgl. int 16h, ah=0) liest die queue dann im Rahmen der Anwendung (hier einfach des "Kerns") wieder aus.


Anmelden zum Antworten