Aber beim EF haben sich mehrere Leute die Arbeit geteilt. Außerdem hat skoe das Dateisystem mitgeliefert und nicht gesagt: Hier ist 1 MB Speicher – wie ihr den verwaltet, ist euer Ding.
Ich habe zwar gesehen, dass eine Art Dateisystem-Spec in der EF-Doku steht, aber war die nicht von alx und dir? Und hat die ausser euch jemals jemand verwendet?
Aber gut, wenn ihr ein Dateisystem haben wollt, kann ich mir ja eben was in Stichpunkten aus den Fingern saugen:
- Die ersten 64KB des Flash werden für das Initial-Lader-Programm (für LOAD) reserviert, zB ein Filebrowser
- Der komplette weitere Speicher wird in 4KB-Blöcken verwaltet (passend zur Erase Size), für die ich mal eine Nummerierung nach dem Schema "adresse / 4096" annehme. Blöcke 0 bis 15 sind die reservierten 64KB am Anfang aus der vorherigen Klausel, da es 2 MB Flashspeicher gibt hat der höchstnummerierte Block die Nummer 511. Sollte es mal Tapecarts mit abweichender Erase Size geben müsste man mal schauen, wie man das umstellt.
- Das Dateisystem besteht aus verketteten Listen von 4KB-Blöcken. Es gibt keine Bitmap freier Blöcke, diese lässt sich aber durch Auslesen der ersten 2 Byte aller Blöcke selbst erstellen. (Theorie dahinter: Schreibzugriffe sind selten)
- Die ersten zwei Byte eines Blocks enthalten seinen Status und ggfs. die Verkettung auf den nächsten Block. Sie sind als LSB-First-16-Bit-Wert zu interpretieren. Wenn Bit 15 dieses Statusworts (Bit 7 des zweiten Byte) gesetzt ist, ist der Block frei und er sollte komplett gelöscht sein (alle Bytes auf 0xff).
- Bit 14 des Statusworts ist gesetzt, falls dies der letzte Block in einer Kette ist. In diesem Fall enthalten Bits 11 bis 0 die Anzahl der Byte in diesem Block, die noch zur Datei gehören und Bit 12 und 13 sind reserviert (empfohlener Wert: 0)
- Bit 14 des Statusworts ist gelöscht, falls dies nicht der letzte Block in einer Kette ist. In diesem Fall sind alle auf das Statuswort folgende Bytes Teil der Datei und Bit 12 bis 4 enthalten die Nummer des nächsten Blocks. Bits 13 und 3 bis 0 sollten den Wert 0 enthalten. (Theorie dahinter: Keine Bitshifts nötig, um aus der Blocknummer die Startadresse des nächsten Blocks zu bestimmen)
- Der erste nicht reservierte Block (Nummer 16) enthält den Anfang des Inhaltsverzeichnisses
- Ein Eintrag im Inhaltsverzeichnis besteht aus 18 Byte. Die ersten 16 Byte sind ein PETSCII-codierter Dateiname (aufgefüllt mit 0xa0), die darauffolgenden 2 Byte bilden ein 16-Bit-Wort (LSB first), welches die mit 16 multiplizierte Blocknummer des ersten Blocks der Datei angibt (genauso wie im Statuswort eines nicht-letzten Blocks)
- Da 4094 nicht glatt durch 18 teilbar ist, bleibt nach 227 Inhaltsverzeichnis-Einträgen ein Rest von 8 Byte am Ende eines Inhaltsverzeichnis-Blocks. Diese 8 Byte sind reserviert und sollten 0xff enthalten.
- Falls 227 Inhaltsverzeichnis-Einträge nicht ausreichen, kann das Inhaltsverzeichnis durch Blockverkettung beliebig verlängert werden.
- Ungenutzte Einträge im Inhaltsverzeichnis werden mit 18x 0xff gefüllt.
- Es dürfen keine zwei Einträge mit identischem Namen im Inhaltsverzeichnis existieren, wobei ungenutzte Einträge nicht unter diese Regel fallen.
grübel grübel und studier...warum tut sich denn nichts hier
