Sourcecode Fortschritt

[Erhard Henkes]

Rev. 72:
http://prettyos.svn.sourceforge.net/viewvc/prettyos?view=rev&revision=72

Erkennung von Filename/extension stabilisiert (bei einigen Versuchen hatte es Probleme gegeben. strncpy ok?)

FAT parsen beschleunigt.

Später soll man z.B. 'kernel.bin' in der shell eingeben. Dann wird zunächst in der shell selbst nach dem Befehl gesucht und falls nicht vorhanden, das File auf der Floppy Disk gesucht und entweder geladen/ausgeführt (z.B. xxx.elf) oder nach dem Finden als nicht ausführbar dargestellt (z.B. bin oder sys oder ...).

[Erhard Henkes]

Rev. 73:
http://prettyos.svn.sourceforge.net/viewvc/prettyos?view=rev&revision=73

Zwischenschritt: File wird probeweise mittels FirstCluster und zugehöriger FAT-Chain in einem Array file[...] aufgebaut.

Der Algorithmus ist allerdings nicht brauchbar, da der zweite Cluster via FAT-entry[i] gefunden wird (siehe Rev.74).

[Erhard Henkes]

Rev. 74:
http://prettyos.svn.sourceforge.net/viewvc/prettyos?view=rev&revision=74

Zwischenschritt:
Algorithmus zum Auffinden der Cluster-Kette mittels 2nd_Cluster = FAT[1st_Cluster] als Start.

1. File 'program.elf' auf die Diskette kopieren, da dieses File gesucht wird
2. Testet den Algo mittels 'fformat'

[Erhard Henkes]

Rev. 75:
http://prettyos.svn.sourceforge.net/viewvc/prettyos?view=rev&revision=75

Zwischenschritt:
Suche nach 'kernel.bin' und "Laden" in ein Array file[...].
Noch immer in den fformat-Befehl eingebunden.

Nächster Schritt: Auslagern in eigene Load-Funktion und Start via Eingabe des Filenamens in der Shell.

[Erhard Henkes]

Rev. 76:
http://prettyos.svn.sourceforge.net/viewvc/prettyos?view=rev&revision=76

fdir: file ohne Extension nun auch ohne Punkt
makefile: rm -f .o
fat12.c: algorithmus korrigiert, FAT-Clusterkette wird zu langsam gelesen

Problem: Unterschiedliche Inhalte in File-Array bei real PC (1./2. Cluster identisch eingelesen) und qemu (klappt gut). Lesevorgang? DMA?

Anmerkung:
noch bei 'fformat' testweise untergebracht, bis es richtig läuft, dann separate Load-Funktion mit Start durch die shell.

[Erhard Henkes]

Rev. 77:
http://prettyos.svn.sourceforge.net/viewvc/prettyos?view=rev&revision=77

Meilenstein: (noch eingebettet in 'fformat')
Separate Load-Funktion: flpydsk_load(char* name, char* ext):
In dieser Version gelingt erstmalig das Laden und Ausführen einer Datei (hello.elf, 3 Cluster) von Floppy Disk!

Screenshot:
http://www.henkessoft.de/OS_Dev/Bilder/Load_Process_from_Floppy.PNG
(Anmerkung: Der dritte Cluster besteht nicht nur aus lauter Nullen, sondern enthält genau ab Byte 21 Daten unterschieldich zu 0x00. Es werden allerdings jeweils die ersten 20 Byte eines Clusters zur Kontrolle angezeigt. Der beste Beweis, dass der Vorgang klappt, ist selbstverständlich, wenn ein Programm ordnungsgemäß startet.)

[Erhard Henkes]

Rev. 78:
http://prettyos.svn.sourceforge.net/viewvc/prettyos?view=rev&revision=78

Nun kann man den Dateinamen, z.B. "hello.elf" oder einfach "hello", auch "hello." direkt in der Shell eingeben.

Läuft allerdings noch nicht völlig rund - Zeichendarstellung verschoben, ab und zu #PF(beim Ausführen des Programms?) - aber es ist unser Einstieg in die bunte Landschaft der User-Programme, mal abgesehen von der im Kernel mittels "incbin" mitgelieferten Shell.

Zur Zeit kann nur das elf-Format "seziert" werden. Ideen für kleine Programme sind bereits genügend vorhanden.

Die hoffentlich ausgeführte Datei befindet sich übrigens hier:
...\PrettyOS\trunk\Source\user\user_test_c\
Sourcecode:

#include "userlib.h"

int main()
{
    settextcolor(12,0);
    puts("Hello, Pretty Operating System World!\n");
    puts("This piece of software was loaded by PrettyOS from your floppy disk.\n");
    settextcolor(15,0);
    return 0;
}

Nun können wir entsprechende User-Programmideen umsetzen (makefile und Umgebung muss noch entsprechend erweitert werden. Ich habe das Programm hello.elf einfach durch Substitution von program.c und anschließendem Rücktausch erzeugt, denn wir müssen ja start.asm und das passende Linkerskript beim Compilieren/Linken verwenden.). Damit lenkt sich der Blick auch auf die vorhandene und noch zu erweiternde API (syscalls) und die magere/fehlende C-Bibliothek im User-Bereich.

Vielleicht findet jemand die Gründe, warum es manchmal zu #PF kommt und warum echte Hardware in einigen Fällen (auf meinem Entwicklungsrechner von ca. 2004 funktioniert es) noch Lese-Probleme macht, während es dagegen mit qemu problemlos funktioniert.

Am besten mit qemu probieren (FloppyImage.bin wird ja mitgeliefert bzw. beim Compilieren erzeugt), da es auf echter Hardware noch eindeutig zu wenig performant abläuft (im 5-10 Minuten-Bereich).

[Erhard Henkes]

Rev. 79:
http://prettyos.svn.sourceforge.net/viewvc/prettyos?view=rev&revision=79

Verbesserungen bei der Eingabe in der Shell

[Erhard Henkes]

Rev. 80:
http://prettyos.svn.sourceforge.net/viewvc/prettyos?view=rev&revision=80

Verbesserungen in fat12.c

[Erhard Henkes]

Rev. 81:
http://prettyos.svn.sourceforge.net/viewvc/prettyos?view=rev&revision=81

shell (program.c): Leereingabe abgefangen (!)
flpydsk.c: delay von 50 ms bei Lese-/Schreibvorgängen auf null reduziert

Simulation mit FloppyImage und qemu läuft nun rapide.
Echte Floppy mit qemu etwas beschleunigt.

[Erhard Henkes]

Rev. 82:
http://prettyos.svn.sourceforge.net/viewvc/prettyos?view=rev&revision=82

timer.c: Systemfrequenz reduziert von 1000 Hz (wie bei Linux) auf 100 Hz (wie früher; führt wieder zu geordneter Bildschirm-Darstellung)
fat.c: log_task_list() vor und nach dem auszuführenden Programm dargestellt, damit die Tasks demonstriert werden

Screenshot:
http://www.henkessoft.de/OS_Dev/Bilder/Rev82.PNG

Rev. 83:
http://prettyos.svn.sourceforge.net/viewvc/prettyos?view=rev&revision=83

Zwischenversion nur für Fehlersuche (Probleme in neuestem Sun Virtual Box und einigen qemu-Versionen)

Rev. 84:
http://prettyos.svn.sourceforge.net/viewvc/prettyos?view=rev&revision=84
Zusätzlich Erstellungswerkzeuge für HELLO.ELF im Unterordner für eigene Experimente. TODO: alles abändern auf übergeordnet Ordner (nasm, make, userlib, ...).

[Erhard Henkes]

Rev. 85:
http://prettyos.svn.sourceforge.net/viewvc/prettyos?view=rev&revision=85

Veränderungen in program.c

Läuft bei mir absturzfrei mit qemu, Sun Virtual Box, MS Virtual PC (dort allerdings Leseprobleme von Floppy)

Bitte prüfen!

Die roten Punkte stellen die Durchläufe durch die innere Schleife der shell dar.
Hier kann man das abstellen:

while(true)
      {
          ///TEST
          settextcolor(4,0);
          puts(".");
          settextcolor(15,0);
          ///TEST
          ...

TODO: Gibt man "kernel.bin" ein, so wird nur ".bin" gesucht (geht nur mit "kernel .bin")

Die Systemfrequenz wurde wieder auf 1000 Hz eingestellt, da dies anfänglich Vorteile mit Sun VB brachte.

[Cuervo]

Revision 85 geht bei mir nur auf einem einzigen Computer fehlerfrei, und zwar PC 2.
PC 1 gibt einen GPF in der PCI-Liste aus und PC 3 startet neu (das ist der, der früher IMMER ging aber kaputt war und ich gestern wieder zusammengebaut habe).
In qemu läuft es, in VirtualBox auch, MS VPC hab ich nicht. In VitualBox läuft es allerdings SEHR langsam... da kann man die roten Punkte mitzählen^^

[Erhard Henkes]

Rev. 86:
http://prettyos.svn.sourceforge.net/viewvc/prettyos?view=rev&revision=86

- getch() in user.c umgebaut, so dass auf eine Eingabe gewartet wird.

unsigned char getch()
{
    unsigned char ret;
    do
    {
        __asm__ volatile( "int $0x7F" : "=a"(ret): "a"(6) );
    }
    while(ret==0);
    return ret;
}

- DEBUG-Ausgaben entfernt (motor on/off; rote Punkte)

@Cuervo: bei meinen PCs läuft es

[anubis2k5]

Revision 86: bei Eingabe von HELLO.ELF wird -->.ELF<-- nicht gefunden.
Bei Eingabe von "hello" hingegen funktioniert es - gewollt?!

Nachtrag: Besteht die Möglichkeit einen extra Threat zum Testen der Revisionen zu öffnen? Ich glaube hier wird's langsam voll...

Nachtrag 2: Nachdem ich alle .bin;.map;*.elf - Dateien gelöscht habe, um ein "sauberes" System zu bekommen, musste ich feststellen, dass die Datei "HELLO.ELF" nicht gefunden wird. Wirklich aussagekräftige Fehlermeldung erhalte ich nicht. Habt ihr eine Idee?

tools/CreateFloppyImage2 PrettyOS FloppyImage.bin stage1_bootloader/boot.bin sta
ge2_bootloader/BOOT2.BIN kernel/KERNEL.BIN user/user_test_c/HELLO.ELF
Cannot open the file 'user/user_test_c/HELLO.ELF'
mingw32-make: *** [ckernel] Error -1

[Erhard Henkes]

Im Unterverzeichnis ...\PrettyOS\trunk\Source\user\user_test_c build.bat ausführen.

mingw32-make main

==> HELLO.ELF

[Erhard Henkes]

Rev. 87:
http://prettyos.svn.sourceforge.net/viewvc/prettyos?view=rev&revision=87

Zwischenschritt (leider noch Fehler enthalten) mit Bitte um Fehlersuche.

task.c: exit als syscall eingebaut (beendet Prozess)
user.c: gets eingefügt

User-Programm mit gets (altes Programm in "zzz_alternative_User-Programme", falls die Fehler nerven, das sollte wiederholbarer laufen)

Systemfrequenz: 100 Hz

Diese Version sollten wir nun erstmal stabilisieren, da ich an mehreren Stellen kleine Ungenauigkeiten vermute, die nun zuschlagen.

Bei MT kann es auch zu races kommen, sodass wir noch einiges gegeneinander abschotten müssen.

[Erhard Henkes]

Rev 88:
http://prettyos.svn.sourceforge.net/viewvc/prettyos?view=rev&revision=88

Zwischenschritt mit Bitte um Fehlersuche / Ideen.

Diagnose aktiviert (PID der tasks werden angezeigt)

Absturz bei Überschreiten von exit (wird durch test-Funktion angezeigt) in start.asm verhindert durch jmp $

User-Programm mit gets <--- richtig schlimm, lange namen eingeben

Systemfrequenz: 10 Hz

Was muss durch cli/sti abgeschottet werden?
Wo sind kritische Abschnitte notwendig?

[Erhard Henkes]

Rev. 89:
http://prettyos.svn.sourceforge.net/viewvc/prettyos?view=rev&revision=89

Fehler gefunden! Wie erwartet im Multitasking.

Während der Ausführung von gets wurde der task gewechselt. Damit fing die shell Zeicheneingaben und vor allem das ENTER (Line Feed: 10) des User-Programms ab, das dann auf das Ende des Strings wartete.

Abhilfe: Das Taskswitching wurde während gets(...) deaktiviert (wohl keine dauerhafte Lösung). Hierzu wurde ein syscall settaskflag geschaffen.

siehe: task.c, syscall.c, userlib.c

Wenn man das nachvollziehen will:
Diagnose in os.h aktivieren, dann sieht man die PID der Tasks. Einfach in gets das taskswitching zulassen.

[Erhard Henkes]

Rev. 90:
http://prettyos.svn.sourceforge.net/viewvc/prettyos?view=rev&revision=90

Fehlerbeseitigungen:
task.c: in exit() sofort task-switch nach sti(), damit der Prozess nicht hinter exit gelangen kann.
interrupts.asm: 0x7E war dort nicht eingetragen in die IDT (--> #GP)! Danke an XanClic für diesen Hinweis!