4. Sourcecode Fortschritt

Sourcecode Fortschritt

  • E
    Mod

    rev. 566:

    userlib.h/c hat nun srand und rand:
    hello.elf:

    PrettyOS [Version 0.0.1.6]                                Console 0: HELLO   ELF
--------------------------------------------------------------------------------

================================================================================

                                C - Testprogramm!                               

--------------------------------------------------------------------------------

                                 ! Hello World !                                

94      26602   30017   18297   20363   13015   28509   15290   29003   24399   
3339    28849   17055   19424   4588    15756   6098    11834   1351    21383   
18431   155     14763   14082   4564    25482   30678   20183   15765   18376   
20694   32234   8292    29828   23406   31490   25791   15822   24763   23255   
15434   32590   15383   108     24271   12086   29246   26526   31363   7541    
17328   32253   31115   13102   15958   32220   16574   18024   4711    32676   
19373   22023   11917   13678   18912   16891   26436   1232    8547    21431   
11651   29430   31362   10980   6303    5877    14544   25175   18284   1629    
1390    321     23717   28685   20105   3238    6798    22860   24613   19729   
25047   12565   31257   7301    6084    11697   1883    20662   14219   10380   

____      <>_<>                                       _______                ___
[] | .---|'"`|---.                                  (_______) |_|_|_|_|_|_|| [] 
-o-'`o"O-OO-OO-O"o'                                `-oo---oo-'`-oo-----oo-'`-o--
--------------------------------------------------------------------------------
Wednesday, June 30, 2010, 23:32:12   34 s runtime. CPU: 3816 MHz               /
    0
  • M

    Version 0.0.1.8:

    - Farbwechsel-Fehler vielleicht behoben (Beim Interrupt geschah es vermutlich)
    - fopen in Betrieb genommen (leichter Fehler noch: Append geht noch nicht, wird morgen korrigiert)
    - Synchronisation userlib-Header
    - malloc-Alignment in einigen Fällen von PAGESIZE auf 0 geändert
    - ...

    0
  • M

    Version 0.0.1.9:

    - fseek und fclose in Betrieb genommen
    - 'a'-Bug behoben
    - FAT_file_t fast komplett aufgeräumt
    - Kleinigkeiten

    0
  • E
    Mod

    Rev. 569 (0.0.1.9)

    Neu: arrow.c und ARROW.ELF (User-Programm erstellt von ehenkes, um die Möglichkeiten von keyPressed unf srand/rand zu demonstrieren und anderen Lust zu machen ebenfalls tolle Spielideen umzusetzen) 🙂

    0
  • M

    Version 0.0.1.10:

    - makefile fügt ARROW.ELF automatisch dem Image hinzu
    - HELLO.ELF wiederhergestellt
    - ehenkes Arrow-Spiel verbessert
    -- ESC beendet Programm
    -- getch statt sleep am Ende
    -- Bugfixes&Optimierungen

    0
  • E
    Mod

    Rev. 571 (0.0.1.10):

    arrow.c/elf verbessert zum Abschluss (Abfrage von Taste Q für quit)

    0
  • E
    Mod

    Rev. 572 (0.0.1.11):

    neu in fat.h/c:
    FS_ERROR FAT_remove (const char* fileName, FAT_partition_t* part)

    @MrX: bitte einbinden, falls nicht schon erfolgt

    0
  • E
    Mod

    Rev. 573 (0.0.1.12):

    - FAT_remove korrigiert
    - FS_ERROR FAT_rewind(FAT_file_t* fileptr)

    Anmerkungen:

    1. FAT_remove: strcpy(fileptr->name, fileName); // must be 8+3 formatted first (muss das im FS manager passieren?) // strcpy muss evtl. noch angepasst werden auf strncpy mit 11 zeichen

    2. FAT_rewind: // fileptr->seek = 0; // has to happen in FS manager

    3. FAT_rename: noch nicht implementiert, muss erst noch diskutiert werden, ob dabei ein copy und delete erfolgen darf

    @MrX: das endgültige Einbinden / Testen sollten wir zusammen durchführen

    0
  • M

    Version 0.0.1.13:

    - FAT_rewind gelöscht und durch rewind im fsmanager ersetzt, da rewind(file) äquivalent zu fseek(file, 0, SEEK_SET) ist und das im fsmanager erledigt werden kann und soll.
    - FAT-remove nimmt nun einen partition_t* statt FAT_partition_t*
    - FAT_remove in fsmanager "integriert"
    - Kleinigkeiten

    0
  • E
    Mod

    Bei FAT_rewind bin ich mir nicht ganz sicher, es existiert immerhin ein
    FS_ERROR FAT_fseek(file_t* file, int32_t offset, SEEK_ORIGIN whence).

    remove geht nicht, weil kein 8+3 Filename "screen__txt" übergeben wurde, sondern "screen.txt". Das wird jetzt im Filemanager erledigt, da die Funktion FormatFileName(...) seit neuestem dort ist.

    Jetzt gehts (ausprobiert mit screen.txt auf Floppy). Habe den "remove" Test in video.c belassen für eigene Versuche (auskommentiert ab Zeile 273):

    Rev. 575 (0.0.1.14)

    0
  • M

    Erhard Henkes schrieb:

    Bei FAT_rewind bin ich mir nicht ganz sicher, es existiert immerhin ein
    FS_ERROR FAT_fseek(file_t* file, int32_t offset, SEEK_ORIGIN whence).

    Ich bin mir völlig sicher.

    Denn, wie ich schon sagte, rewind(file) ist äquivalent zu fseek(file, 0, SEEK_SET), also kann man rewind so implementieren, das es den o.g. fseek-Aufruf durchführt, welcher dann u.a. FAT_fseek aufruft. Genau so hab ich es gemacht.

    0
  • E
    Mod

    @MrX: Ja, du hast völlig Recht. Siehe: http://openbook.galileocomputing.de/c_von_a_bis_z/016_c_ein_ausgabe_funktionen_014.htm#mjff798e62f1469fc3901b349f005d6547
    Gut gemacht. 👍

    0
  • E
    Mod

    Rev. 576 (0.0.1.15):
    FS_ERROR FAT_rename(const char* fileNameOld, const char* fileNameNew, partition_t* part)
    FS_ERROR FAT_fileRename (FAT_file_t* fileptr, const char* fileName)

    Getestet mit Floppy, funktioniert. 🙂

    Testcode siehe video.c, Zeile 273 ff.

    //rename test 
    waitForKeyStroke();
    uint32_t error = rename(Pfad,"1:/scrnew.txt"); 
    printf("\nrename test: error: %u", error);

    // remove test 
    waitForKeyStroke();
    error = remove(Pfad); 
    printf("\nremove test: error: %u", error);
    waitForKeyStroke();
    0
  • E
    Mod

    Rev. 577 (0.0.1.16):

    rename funktioniert nun auch mit rename(Pfad,"scrnew.txt") und mit Floppy und USB MSD.

    Test in video.c ab Zeile 273 (auskommentiert)

    getFilename angepasst, damit keine Pfadangabe vor dem Filenamen notwendig ist.

    const char* getFilename(const char* path)
{
    if (strchr((char*)path,'/')==NULL && strchr((char*)path,'|')==NULL && strchr((char*)path,'\\')==NULL)
    {
        return path;
    }
    else
    {
        // ...
    }
}
    0
  • M

    Version 0.0.1.17:

    - FormatFileName wieder in fat.c (War doch besser dort aufgehoben)
    - initrd etwas umgebaut

    0
  • M

    Version 0.0.1.18

    - fsmanager auf fgetc/fputc umgestellt
    -- Bedingt durch fehlendes caching im FAT-Treiber ists sehr langsam
    - FAT_fread/FAT_fwrite nur noch intern im FAT-Treiber genutzt
    - getch im Kernel eingebaut -> CPU-Sparen mit hlt

    0
  • E
    Mod

    Erste Tests:

    strg+s (screenshot auf floppy) und strg+u (screenshot auf usb-stick) gehen noch gleich schnell, Schreibvorgänge sind im FAT-Modul bereits gecacht. 👍

    ttt.elf laden:

    a1) Floppy real: wird jedes byte einzeln per sector lesen geladen (lese-cache notwendig), real abgebrochen zum Schutz des FDD

    a2) Floppy Qemu: geht (etwas langsamer ^^)

    b1) USB-Stick real: #PF (schreiben in read-only area ??), entweder bug eingebaut oder technik geht so nicht (MrX: bitte prüfen und kommentieren)

    b2) USB-Stick VMWare-Player: wird jedes byte einzeln per sector lesen geladen (lese-cache notwendig), interessanter Dauertest für OS und Stick (auch nett: Stick ziehen, dauer-rot auf screen ^^)

    Ein interessanter Trümmerhaufen, aus dem Phoenix aus der Asche wieder erstehen soll. 😉

    Die Grundfrage ist die, ob nach erfolgreichem Read-Cache-Einbau die Performance nicht doch leidet durch die vielen zusätzlichen Abläufe zwischen dem Lesen der Bytes mit fgetc. 😕

    0
  • E
    Mod

    0.0.1.19 (SVN Rev. 580)

    Read Cache für readSector funktioniert wie gewünscht. 🙂

    Leider existiert ein Problem beim Laden von usb-stick (Ursache noch nicht untersucht)

    0
  • E
    Mod

    0.0.1.20 (Rev. 581)

    ➡ Problem: malloc spinnt! (seit 0.0.1.18) keiner weiß warum ^^

    Es passiert, wenn ein programm einmal geladen wird (muss nicht ausgeführt werden)

    file->name von pointer auf array umgestellt, wegen Analogie zu FAT_file->name (dort exakt 8+3), hilft aber nicht beim aktuellen Problem, sollte aber ansonsten fehlersicherer sein, da man dabei nicht vergessen kann malloc(...) auszuführen.

    0
  • E
    Mod

    malloc/free beginnend vom Start verfolgt:

    void* malloc(uint32_t size, uint32_t alignment)
{
    //...

    // debug
    textColor(0x0E);    
    printf("\nmalloc: %X",address);
    textColor(0x0F);
    waitForKeyStroke();

    return address;
}

void free(void* address)
{
    // debug
    textColor(0x0E);
    printf("\nfree: %X",address);
    textColor(0x0F);
    waitForKeyStroke();

    //...
}

    Fazit: Da passt nix zusammen! 🙄

    Beweis-Foto: http://www.henkessoft.de/OS_Dev/Bilder/0_0_1_20_malloc_free_problem.PNG

    malloc    free
--------------------------------------
C0000000   
          C0000048
          00000000
C0004CC0  
          C0204CC0          
          C0000568
          C0000690
          C0000038

    usw.

    Absoluter Nonsens zur Zeit.

    0
Anmelden zum Antworten