Sourcecode Fortschritt
-
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
-
Rev. 534: Noch Versuchsversion zur Klärung
Durch einen völlig unverständlichen Hotfix geht es nun!
// fatWrite (fileptr->volume, 0, 0, true); // TEST: das klappt nicht überschreibt auch die root dir uint32_t i, sectorFAT; for (i=0, sectorFAT=globalLastFATSectorRead; i<1/*fileptr->volume->fatcopy*/; i++, sectorFAT+=fileptr->volume->fatsize) { printf("\ni: %u sectorFAT: %u", i,sectorFAT); if (singleSectorWrite(sectorFAT, globalBufferFATSector, fileptr->volume) != CE_GOOD) { return CLUSTER_FAIL_FAT16; } } globalFATWriteNecessary = false; waitForKeyStroke();
Vielleicht sind das Spiegelungen beim Schreiben auf die Floppy. Am ANfang hatten wir da auch Probleme. Müsste so etwas sein.
-
Revision 535:
- Projektfile von VC++ 2008 auf 2010 umgestellt
- file.c/.h gelöscht, fat12.c weiter aufgeräumt
- Kleinere Änderungen/Optimierungen
-
Rev. 536:
- HOTFIX von fclose nach fatWrite (nur für FAT12) übertragen, damit dies allgemein funktioniert
- initializeDMA wieder von außen zugänglich gemacht und für flpydsk_read_directory ("fdir") reaktiviert (kein Erfolg)
- DEBUG-Ausgaben in fat.c zurück gesetzt, feste printf gelöschtStrg+s (Screenshot) gelangt nun endgültig via device manager und fat.h/c auf die Floppy Disk.
-
Dass das mit dem DMA nichts zu tun hat, habe ich ja bereits gesagt...