Sourcecode Fortschritt
-
Revision 515:
- Fehlerbehandlung von execute jetzt in shell.c
- execute und loadFile geben nun FS_ERROR zurück
- Disk zählt noch zu lesende Sektoren -> Möglichst seltenes an/aus des Motors bei "beweglichen" Medien wie Floppys, HDDs und CDs
- Syscall-Definition von execute repariert
- Kleinigkeiten
-
Revision 516:
- (jetzt hoffentlich funktionierende) Floppy-Motor-Steuerung
- Zahlreiche Funktionen aus fat12.c entfernt
-
Rev. 517:
Es gibt nach Umbauarbeiten (dank an MrX) überraschende Probleme auf real PC mit der Floppy:
Bei mir hört es in der ports-liste nach FDD auf, nur noch read error
daher cross-check, bitte testen.
Mit den nachgereichten Versionen für die Motorsteuerung geht es ebenfalls nicht!
http://codepad.org/oZCtQChr
http://codepad.org/kaH3aG1q
http://codepad.org/MJDdABeh ("mal eine ältere Version")sag mir, ob es a) geht und wenn nicht b) zuletzt "off" angezeigt wird
a) es geht nicht (zwei PC mit echter Floppy, zwei Disketten)
b) "on" steht vorne nach Finden der FDD; "off" kommt nicht, nur der read error mit Lampe aus (bei beiden PCs and der exakt gleichen Stelle).MrX: bitte checke mal die Rev. 517, ob die wirklich so auf real PC bei dir läuft. Vielleicht hast du lokal eine andere Version.
VMWare läuft mit rev. 517 korrekt, aber lädt viel zu lahm.
Gibt man nur "ttt.elf" ein, so wird "Trying now on 1:/." angezeigt, aber korrekt geladen.VBox klappt gut mit zwei Floppys, lädt schnell.
Qemu läuft analog VBox.Nachdem ich auch noch auf meinem Entwicklungs-PC das gleiche negative Ergebnis erhielt:
Bei manchen PCs muss man zwei mal laden, bis es klappt (DMA-Init-Problematik, muss noch im geänderten Code untersucht werden), also erstes mal read error, dann beim zweiten mal Erfolg. Wenn wir aber Sektoren zählen und entsprechend bei null abschalten, könnte dies genau vor dem erfolgreichen Lesen erfolgen.
Nur so eine Idee. Spricht nur dagegen, dass das "off" bei dem einen Test nicht kam. Also könnte es auch sein, dass dieser Lesevorgang zur Detektion des Partitionsnamens in einer Fehlerschleife hängen bleibt.
Ein Test auf einem vierten PC: ebenfalls nicht ok. Nach ENTER drücken gings weiter, aber ständig read error und Festhängen an diesem Punkt. ttt.elf wurde nicht geladen, als es endlich gelang dies einzutippen.
Irgendetwas ist in Rev. 517 gegenüber früheren Versionen massiv gestört im Lesevorgang.
Bitte gegen den Ablauf im alten Code checken.Cuervo: bitte ebenfalls prüfen.
-
Danke für die Umfangreichen Tests, Erhard.
(dank an MrX)
Danke, das ichs zerschossen hab?
Naja, ab und zu muss man mal was kaputt kriegen, ums wieder zusammensetzen zu "dürfen"
-
Rev. 518: Vorbereitungen FAT-Modul: Schreiben (Ablösung file.c und weitgehend fat12.c)
-
Revision 519:
- Floppyproblem behoben. Ich hatte nicht bedacht, das flpydsk_enable_controller den Motor abschaltet. Daher wichen CurrentDisk->motor und Realität vonnander ab
- Shell gibt nun Dateinamen statt "1:/" bei retry an.
- Kleinigkeiten
-
Rev. 520:
Vorbereitung fat-modul für Schreiben
-
Revision 521:
- flpydsk_writeSector gebaut und in devicemanager.c genutzt
- Fat-Treiber verbessert (Kürzungen, Scope von Variablen, seltsame return-Konstruktionen; 100 Zeilen gespart bei mehr Funktionen (singleSectorWrite))
-
Revision 522:
boot2.asm: wurde erneut gehotfixt, indem der stack von 1FFFFh nach 3FFFFh geschoben wurde
Nun hat Kernel.bin im RM Platz zwischen 3000h und ca. 40000h (Stack), also knapp 250000 bytes.
makefile: der kernel wird bewusst mit -O3 gebildet, um erstens einen größeren Kernel mit ca. 130K zu erhalten und zweitens Fehlermöglichkeiten mit O3 zu testen.
-
Rev. 523:
Vorbereitung für verbessertes file read/write in fat.h/c (fopen ausgetauscht, fopenFileName und Helper-Fkt. ergänzt)
-
Rev. 524:
strchr war bereits vorhanden in der userlib, nun auch in util.h/.c (kernel)
-
Revision 525:
- Screenshot wird (fehlerhaft) mit fat.c erzeugt
- fopenFileName erkennt nun Partition
- boot2.map wieder entfernt
- Zahlreiche Formatierungen und kleinere Änderungen/Optimierungen
-
rev. 526 (noch fehlerhaft in fat.c):
Am Ende von fopenFileName ist ein Fehler versteckt, der zu einem #PF führt.
Bitte um Hilfe bei der Fehlersuche. Die eingebauten printf helfen mir nicht weiter, weil es bei realPC und verschiedenen Sims ganz anders reagiert. Bei qemu kommt reboot. VMWare und VBox zeigen den Fileptr im Heap.Nach dem #PF kann man mittels Strg+s bei manchen Simulationen weiter machen. Einmal existiert screen.txt offenbar bereits und einmal nicht.
Man kann auf real PC auch ENTER eingeben und z.B. ttt.elf laden. Die shell ist nicht sofort kaputt. Erst wenn man zurück kommt von ttt.elf geht nichts mehr.
Man startet einen Thread aus dem Keyboard-Treiber, also Interrupt, dann Fehler, schon wieder "Interrupt", dann erneut Strg+s ...
:schland:
-
Rev. 527:
kleine verbesserung durch globales fileTemp in fat.c für fopenFileName
Wenn man bei realPC vorher die Floppy quick-formatiert, damit das screen.txt wirklich neu ins Verzeichnis geschrieben wird, dann läuft es fehlerfrei durch. Die Datei hat aber trotz Anzeige des Sektor-Schreibens noch keinen Inhalt.
-
Rev. 528:
- FILEPTR durch FILE* ersetzt
- fileTemp auf heap
- FAT-Debugging verbessertProblem: bei Strg+s wird der root dir Eintrag und die Daten geschrieben, leider noch nicht die FAT-Cluster-Kette
-
Rev. 529:
- NULL Pointer abgefangen bei fopenFileName Rückgabewert (fwrite und fclose unterbinden)
- DEBUG verbessertProblem: FAT1 u. FAT2 werden noch nicht geschrieben
-
Rev. 530: Zwischenschritt
fclose angepasst, so dass FAT1 u. FAT2 geschrieben werden, wenn notwendig.
Allerdings ist jetzt noch ein merkwürdiger Fehler enthalten.
FAT wird noch nach root dir geschrieben.Vielleicht findet jemand den Fehler durch Vergleich 529/530 (AFK)
-
Rev. 531: Zwsichenstand (Arbeitsversion)
Zweites write nach root dir "zerschießt"
-
Revision 532:
- Floppy-Motor-Bug behoben.
- Optimierungen und Kürzungen
-
Rev. 533:
Freeze nach dem Laden eliminiert! Liegt an free(fileptr) in fclose (fat.c)
Kleinigkeiten im Code von fat.c angepasst
FAT-debugging auf Lesen/Schreiben reduziert