4. Sourcecode Fortschritt

Sourcecode Fortschritt

  • M

    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))

    0
  • E
    Mod

    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. 👍

    0
  • E
    Mod

    Rev. 523:

    Vorbereitung für verbessertes file read/write in fat.h/c (fopen ausgetauscht, fopenFileName und Helper-Fkt. ergänzt)

    0
  • E
    Mod

    Rev. 524:

    strchr war bereits vorhanden in der userlib, nun auch in util.h/.c (kernel)

    0
  • M

    Revision 525:

    - Screenshot wird (fehlerhaft) mit fat.c erzeugt
    - fopenFileName erkennt nun Partition
    - boot2.map wieder entfernt
    - Zahlreiche Formatierungen und kleinere Änderungen/Optimierungen

    0
  • E
    Mod

    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:

    0
  • E
    Mod

    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.

    0
  • E
    Mod

    Rev. 528:

    - FILEPTR durch FILE* ersetzt
    - fileTemp auf heap
    - FAT-Debugging verbessert

    Problem: bei Strg+s wird der root dir Eintrag und die Daten geschrieben, leider noch nicht die FAT-Cluster-Kette

    0
  • E
    Mod

    Rev. 529:

    - NULL Pointer abgefangen bei fopenFileName Rückgabewert (fwrite und fclose unterbinden)
    - DEBUG verbessert

    Problem: FAT1 u. FAT2 werden noch nicht geschrieben

    0
  • E
    Mod

    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)

    0
  • E
    Mod

    Rev. 531: Zwsichenstand (Arbeitsversion)
    Zweites write nach root dir "zerschießt"

    0
  • M

    Revision 532:

    - Floppy-Motor-Bug behoben.
    - Optimierungen und Kürzungen

    0
  • E
    Mod

    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

    0
  • E
    Mod

    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. 🙄

    0
  • M

    Revision 535:

    - Projektfile von VC++ 2008 auf 2010 umgestellt
    - file.c/.h gelöscht, fat12.c weiter aufgeräumt
    - Kleinere Änderungen/Optimierungen

    0
  • E
    Mod

    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öscht

    Strg+s (Screenshot) gelangt nun endgültig via device manager und fat.h/c auf die Floppy Disk. 🙂

    0
  • M

    Dass das mit dem DMA nichts zu tun hat, habe ich ja bereits gesagt...

    0
  • E
    Mod

    Rev. 537:

    fat.c: flushdata ersetzt

    So wie es aussieht, läuft noch alles 🙂

    MrX: bitte Motorsteuerung checken (flushdata hatte vorher singleSectorWrite auch in fwrite!)

    0
  • M

    Revision 538:

    - Floppy-Motor-Bug behoben: Global-Access wurde nicht initialisiert. (Danke für die Hilfe bei der Bugsuche, ehenkes)
    - devicemanager/fat/floppy/usb: Schnittstelle geändert, Gerät wird mit übergeben als void* (nicht disk_t*, sondern disk_t::data)
    - Returnwerte von SectorRead/Write auf FS_ERROR umgestellt
    - Optimierungen

    0
  • E
    Mod

    Rev. 539:
    fat.c:
    - Screenshot (Strg+s) funktioniert nun auch wiederholt (Rückgabewerte korrigiert in fat.c)
    - Optimierungen

    0
Anmelden zum Antworten