letzter Beitrag von strik am
16 GB SD-Karte
- AntaBaka
- Erledigt
-
-
-
Gibts nicht inzwischen NTSF-Support für das MMC64? Weil mit FAT bekommt man wegen der wachsenden Clustergröße nicht mehr drauf wie auf eine 4GB-Card.
-
Zitat
Original von logan
Gibts nicht inzwischen NTSF-Support für das MMC64? Weil mit FAT bekommt man wegen der wachsenden Clustergröße nicht mehr drauf wie auf eine 4GB-Card.
Mit FAT32 sollte doch nicht so Problem sein. Dann muß man halt mehrere Partitionen anlegen, damit die Clustergröße im Rahmen bleibt. -
Zitat
Original von logan
Gibts nicht inzwischen NTSF-Support für das MMC64? Weil mit FAT bekommt man wegen der wachsenden Clustergröße nicht mehr drauf wie auf eine 4GB-Card.
Der war gut....Erstens würd ich Oliver dann eher zu ext2 raten als wie zu NTFS, schon alleine weil NTFS nicht vollständig Reversed ist (und seid Vista wieder neues hinzu gekommen sein wird) und Zweitens weis ich das ich selbst eine 200 GByte Platte als eine Partition mit FAT32 formatieren kann.
Überdies würde NTFS Support den ganzen Cevi sprengen, nicht nur die 8 KByte Flash für die MMC64 Firmware.
-
support von mehreren partitionen sollte ja auch nicht so wild sein.
ich frag mich nur grad wie man die als windowsuser wohl anlegen würde
-
SDHC Support kommt mit der nächsten Bios Version. Für ext2 und NTFS ist kein Platz im Bios ROM. 32GB FAT32 Grenze ist übrigens eine künstliche Windows Beschränkung, FAT32 kann theoretisch bis zu 128TB verwalten. Clustergrößen Probleme mit FAT32 wird es erst im TB Bereich geben. Ach ja, und die Tatsache, dass man "nur" 4,2 Milliarden Dateien speichern kann.
-
und sdhc fangen doch erst ab 4gb an oder nicht?
hab hier nen pda der keine sdhc kann, aber hab ne 4gb karte drin. läuft wunderbar
16gb für den cevi.... lol.... soviel soft gibts glaube ich nicht... selbst wenn man alle versionen eines spieles etc nimmt.
es sollte wirklich mal ein "universelles" softwarearchiv geben. wäre was feines
-
16 GB? Pfft, vor zwei Wochen wurden doch schon 32 GB angekündigt.
-
Zitat
Originally posted by jackdaniels
und sdhc fangen doch erst ab 4gb an oder nicht?Es gibt auch ein paar 4GB-Karten die die Spezifikationen ignorieren und als SD statt SDHC angesprochen werden wollen. Ansonsten stimmt die Grenze aber.
-
Zitat
Original von BastetFurry
Der war gut....Erstens würd ich Oliver dann eher zu ext2 raten als wie zu NTFS, schon alleine weil NTFS nicht vollständig Reversed ist (und seid Vista wieder neues hinzu gekommen sein wird) und Zweitens weis ich das ich selbst eine 200 GByte Platte als eine Partition mit FAT32 formatieren kann.
Überdies würde NTFS Support den ganzen Cevi sprengen, nicht nur die 8 KByte Flash für die MMC64 Firmware.
Ich wusste doch das es ein neues Filesystem fürs mmc64 gibt, hab nur NTFS mit FAT32 verwechselt. :rotwerd:
Aber schön das ich dich so belustigen konnte.
-
-
Was sollte NTFS auf einer SD-Karte denn bringen? Das unterstützen doch Kameras und andere Geräte überhaupt nicht. SD schreibt FAT16 vor, SDHC FAT32. Und das ist IMHO ganz gut so.
-
-
machen sd karten nicht eh intern wear-levelling so das man kein spezielles flash dateisystem braucht?
-
Ja, die haben alle wear levelling. Von Sandisk fliegt auch ein ganz interessantes Paper dazu im Netz herum. Da würde ich mir wenig Sorgen machen, das musste man nur ganz am Anfang. Kenne einige Leute, die seit Jahren (!) Systeme mit ganz normalen Dateisystemen wie ext3 auf CF laufen haben, keine Probleme. Und das sind ganz normale NAND-Flashes mit ~10K Zyklen.
-
Ein anderes Datei-System wäre auf jeden Fall eine gute Sache.
Nur nicht wegen wear-leveling oder anderem Spielkram.Nein, interessant wäre ein *einfach* gestricktes Dateisystem welches *leicht* auf der Zielplattform und möglichst mit wenig Speicher implementierbar ist.
FAT ist steinalter, aufgebohrter DOS Müll.
Lange Datei-Namen? Da kommt richtig Freude auf.
Erst recht, weil FAT zwei Namen speichert.Also, einfach ist das Stichwort hier, ausgelegt auf singulären Zugriff, nicht für Multi-Tasking Umgebungen.
32, vielleicht gar 64 Zeichen als eine geschlossene Zeichenkette ohne Murks wie Datei-Erweiterung, das sollte für geschlossene System wie Digital-Kameras keine Einschränkung darstellen.
Platz für Meta-Daten wie Kommentare oder was auch immer.Am Besten pro Datei-Header einen Block auf der Karte damit mit festen Offsets im Block gearbeitet werden kann und nicht in den Blöcken herumgestochert werden muss.
512 Bytes pro Block, 16 Bit Block-Nummern -> 32 GB maximal
Das sollte auch noch ziemlich lange für Geräte wie Digital-Kameras reichen.Wenn dann das noch frei von Lizenz-Gebühren ist kann ich mir schon vorstellen,
dass die Hersteller von Geräten da mitziehen.Und der Zugriff im PC ist auch kein Problem.
Entweder wird das Gerät ohnehin per USB angeschlossen oder es gibt eben ein Programm für den Zugriff auf die Daten. -
Zitat
Original von ShadowolfNein, interessant wäre ein *einfach* gestricktes Dateisystem welches *leicht* auf der Zielplattform und möglichst mit wenig Speicher implementierbar ist.
Ich weiß ja nicht, was du willst, aber FAT ist mit eines der einfachsten Dateisysteme, die es gibt. LFN ist Murks, da gebe ich dir recht, aber sonst ist es extrem simpel. Mein FAT16-Lese-Code auf dem AVR braucht < 1 KB, IIRC.
Und das letzte, was man braucht, ist ein neues, zu allem inkompatibles Dateisystem, finde ich. Es ist ja gerade das schöne, dass man die Karte einfach in den Rechner stecken kann und Dateien ohne Zusatzsoftware hinaufkopieren kann.
-
Ömmm, ich weiss nicht, wo das Problem ist. Der jetzige FAT Code ist etwa 3KB gross und braucht auch nicht besonders viel Speicher. Und langsam ist es auf einem 6510 mit 985khz auch nicht. Das einzige Problem sind halt die Dateinamenskonventionen, die nicht besonders kompatibel zu CBM dos sind, aber dafür kann man ja D64 images mounten. FAT ist alt, aber relativ einfach zu implementieren. LFN sind murks, aber da kneift man dann halt mal die Arschbacken zusammen, und dann bekommt man das auch implementiert.
-
@Oliver_A
Kannst du bitte nochmal in deine PMs gucken? Wo wir gerade beim Thema sind... Da ist was bei mir nicht angekommen, was du mir schicken wolltest.