PrettyOS Fehler-/Testthread
-
Ist es so gedacht, dass sich die externen Dateien nur ohne die Eingabe der Endung aufrufen lassen? Bsp: hello - funktioniert; hello.elf funktioniert nicht?!
-
Ist es so gedacht, dass sich die externen Dateien nur ohne die Eingabe der Endung aufrufen lassen? Bsp: hello - funktioniert; hello.elf funktioniert nicht?!
Beides sollte funktionieren. Da ist was durch die Veränderungen durcheinander geraten. Gib bitte solange
HELLO .ELF
ein, bis es wieder geht.
-
OK...
Nächste Meldung: Habe unter Bochs Probleme PrettyOS zum laufen zu bringen. Bochs kann scheinbar nicht vom Image booten - Pfadanpassung in der entsprechenden Config brachte leider keine Erfolge.
Meldung:
00020932447p[BIOS ] >>PANIC<< No bootable device.
-
Ich verwende momentan bochs überhaupt nicht mehr, sondern nur noch qemu, weil es deutlich schneller ist.
Ich habe es gerade mal wieder mit Bochs getestet, geht bestens vom Image:
romimage: file=$BXSHARE/BIOS-bochs-latest cpu: count=1, ips=10000000, reset_on_triple_fault=1 megs: 1024 vgaromimage: file=$BXSHARE/VGABIOS-lgpl-latest vga: extension=vbe floppya: 1_44=G:\OSDev\PrettyOS\trunk\Source\FloppyImage.bin, status=inserted ata0: enabled=1, ioaddr1=0x1f0, ioaddr2=0x3f0, irq=14 ata1: enabled=1, ioaddr1=0x170, ioaddr2=0x370, irq=15 ata2: enabled=0, ioaddr1=0x1e8, ioaddr2=0x3e0, irq=11 ata3: enabled=0, ioaddr1=0x168, ioaddr2=0x360, irq=9 boot: floppy floppy_bootsig_check: disabled=0 log: bochsout.txt panic: action=ask error: action=report info: action=report debug: action=ignore debugger_log: - parport1: enabled=1, file="parport.out" vga_update_interval: 300000 keyboard_serial_delay: 250 keyboard_paste_delay: 100000 mouse: enabled=0 private_colormap: enabled=0 keyboard_mapping: enabled=0, map= i440fxsupport: enabled=0
-
So, ich meld mich hier auch mal...
Mein Problem:
Texteingabe funktioniert in user-programmen nicht. ich bekomme nicht die möglichkeit (weder selbstgeschriebene noch hello.elf) einen Text einzugeben; das Programm beendet sich in dem Moment, wo man etwas eingeben müsste. (Wenn man den Text ausgeben lässt, nachdem man getch() genutzt hat, wird der Text nicht angezeigt, andernfalls jedoch schon).EDIT: ich hätt wohl noch auf die Revision und die Umgebung eingehen sollen: Das Problem besteht mindestens seit Revision 86. 87 enthält es auch. Verwendetes System: Sun Virtual Box 3.1.2
-
Hast du irgendwo eine Test-File im Repository liegen?
-
Bitte mal http://prettyos.svn.sourceforge.net/viewvc/prettyos?view=rev&revision=88 testen (den Absturz des user-program habe ich hoffentlich verhindert, denn ab und zu läuft das einfach über exit hinaus!
-
http://www.c-plusplus.net/forum/viewtopic-var-p-is-1853944.html#1853944
Rev. 89 hat das Problem nun endlich im Griff. Während gets wurde der Task gewechselt. Die shell hat dem User-Programm die Eingaben gestohlen.
Was ist hier die beste Lösung?
-
Beste Lösung: Der Kernel verwaltet die Tastatureingaben und gibt sie an das aktuelle Programm weiter (das, das sichtbar (oder so) ist), oder an das, das gemeldet hat, dass es eine Eingabe will. Dann müsste die Shell solange "anhalten".
Ausserdem kommen die Farben beim Multitasking durcheinander, also sollte jedes Programm seine Farbe merken und wieder aktivieren, wenn es dran ist...
-
Rev. 89 läuft bei mir Fehlerfrei. Auch das mehrfache ausführen von hello.elf funktioniert tatellos!
-
eigentlich funktioniert alles soweit, aber ich hab noch etwas (nicht so wichtig, eigentlich) gefunden: Die Sekunden seit dem Start laufen viel! zu schnell.
-
Noch ein (erheblich größeres) Problem.
Es kommt mglw. durch das Multithreading.Die Konsolenausgabe läuft nicht geordnet. Das äußert sich wie folgt:
Textfarbe ändert sich ohne zutun meinerseits mitten im user-programm und es werden Zeilen vertauscht. Dies tritt insbesondere nach Benutzereingabe auf.EDIT: hälfte vergessen
getch funktioniert garnicht; selbe problem wie gehabt (falls das eigentlich hätte behoben sein sollen)
-
getch funktioniert garnicht; selbe problem wie gehabt
Hast Du den Stack-Pointer auch gegenüber program.c verändert für das weitere Programm hello.c (oder test.c oder was auch immer)? Ist offenbar notwendig. Darüber müssen wir noch diskutieren.
start.asm:; start.asm [BITS 32] extern __bss_start extern __end extern _main extern _exit extern _test global _start _start: mov esp, 0x500000 ; stackpointer call _main call _exit call _test jmp $
-
ich hab die neue start.asm verwendet...
-
OK, dann wundert mich das schon etwas. Kannst Du genau ausführen oder testen, was nicht geht? Mit was testest Du (real, simulation)?
-
ich teste mit Virtual Box 3.1.2
Hab übrigens da gleich mal virtualPC gestartet: Kann keine User-progs laden. Lesefehler von der Disk
-
Ja, das ist mir auch schon aufgefallen, dass Virtual PC nicht von Floppy liest. Real geht es aber, zumindest bei meinen Test-PC.
-
Ich weiß nicht ob das schon irgendwo aufgenommen wurde: Nach dem Programmstart (hello.elf, clear.elf) wird der Prompt nicht wieder neu gezeichnet. Habs jetzt auch nochmal in VirtualBox getestet, wo's auch perfekt läuft.
-
Ja, bei mir läuft es auch in Sun VB. In der Rev. 90 wurden noch zwei Fehler im Kernel beseitigt.
-
Anmerkungen zu Rev. 91:
mit echter Floppy: (klappt offenbar nicht überall lt. Cuervo)
- FAT lesen zu langsam (umbauen auf einmaliges Lesen der gesamten FAT in ein Array, dann evtl. nur die Blöcke von 12 Bit entziffern, die wirklich für ein File beim Laden gebraucht werden)
- #define FATMAXINDEX 150 ///TEST <--- nur als Test brauchbar, denn der Wert kann überschritten werden (momentaner work-around: floppy disk vor dem Aufspielen der Files formatieren), dann #PF als ErgebnisAllgemein:
- Zeichenausgaben (incl. Farbe) geraten beim Taskwechsel noch allgemein durcheinander (Kritische Ressourcen während Benutzung allokieren für eine Task --> "critical section")- shell: Eingabe "hello.elf" --> sucht nach ".elf" (Eingabe-Algo überarbeiten)
Simulationen:
- MS Virtual PC liest nicht von Floppy