Hallo Besucher, der Thread wurde 4,5k mal aufgerufen und enthält 34 Antworten

letzter Beitrag von C=Mac am

SD2IEC

  • Diese 29 (eigentlich sind es 30, denn ein Block wird automatisch beim Formatieren angelegt) sind für das Directory des Hauptverzeichnisses reserviert aber in der BAM noch nicht belegt. Das ist im Prinzip wie bei einer 1541, wo ab Track 18 Sektor 1 das Directory steht.

    Schon klar, aber das beantwortet die Frage nicht. Was im "Normalfall" passiert, ist lange nicht so interessant wie die Grenzfälle:
    Nehmen wir mal eine 128K-Partition, die müsste dann ja "448 blocks free" anzeigen (192 auf Spur 1 und 256 auf Spur 2).


    Test1: Wenn man nun 448 Blöcke durch Dateien belegt (=> 0 blocks free), kann man dann
    a) immer noch ein Unterverzeichnis anlegen? Theoretisch passt das ja noch locker in die reservierten Dir-Blöcke, aber machen die CMD-Laufwerke das oder weigern sie sich?
    b) immer noch eine Datei mit bis zu 29 Blöcken anlegen? Theoretisch passt die ja noch locker in die reservierten Dir-Blöcke, aber machen die CMD-Laufwerke das oder weigern sie sich?


    Test 2: Ein Hauptverzeichnis, das alle reservierten Blöcke benutzt, kann 30*8=240 Einträge aufnehmen. Was passiert beim 241. Eintrag? Wächst das Hauptverzeichnis dann in die "normalen" Blöcke hinein, oder ist dann einfach Schluss (wie bei der 1541)?


    Solange diese Sonderfälle nicht klar sind, wäre eine Änderung am SD2IEC-Code nur Herumdoktern ohne Sinn und Verstand.

  • Test1: Wenn man nun 448 Blöcke durch Dateien belegt (=> 0 blocks free), kann man dann
    a) immer noch ein Unterverzeichnis anlegen? Theoretisch passt das ja noch locker in die reservierten Dir-Blöcke, aber machen die CMD-Laufwerke das oder weigern sie sich?

    Ich habe es nur mit einer 256 Blocks großen CMD-Native-Partition probiert. Ich kann bei "1 Block free" kein UV mehr erstellen, da ein UV eben 2 Blocks braucht.


    b) immer noch eine Datei mit bis zu 29 Blöcken anlegen? Theoretisch passt die ja noch locker in die reservierten Dir-Blöcke, aber machen die CMD-Laufwerke das oder weigern sie sich?

    Habe ich nicht probiert..... Nehme aber an, das es nicht geht. "Blocks free" zeigt mir an, dass keine Blocks mehr frei sind und gut ist.


    Test 2: Ein Hauptverzeichnis, das alle reservierten Blöcke benutzt, kann 30*8=240 Einträge aufnehmen. Was passiert beim 241. Eintrag? Wächst das Hauptverzeichnis dann in die "normalen" Blöcke hinein,

    Ich habe einfach mal 250 Files auf eine Native-Disk (1,6 MB, HD-Diskette im CMD-Native-Mode) kopiert. Kein Problem feststellbar. Das CMD-DOS nutzt dann eben freie Blöcke oberhalb des reservierten Bereiches und gut ist.


    Und ganz ehrlich (meine persönliche Meinung): Native-Mode macht doch erst wirklich Sinn, oberhalb 1 MB. Da funktioniert das auch bis auf das beschriebene auf dem SD2IEC! Wer kleinere DNPs verwenden will, kann ja auf D64, D71 oder D81 umsteigen ...........


    Gruß
    Werner

  • Ich mache also das Gleiche auf echter CMD-Hardware und auf dem SD2IEC (DNP) und erhalte unterschiedliche Diskbelegungen....

    Die Blockallokationsstrategie der CMD-Geräte ist meines Wissens nirgendwo dokumentiert, sd2iec implementiert daher eine recht einfache Variante. Kannst du irgendwelche Kompatibilitätsprobleme dadurch feststellen oder ist das nur ein Schönheitsproblem?

  • Ich kann bei "1 Block free" kein UV mehr erstellen, da ein UV eben 2 Blocks braucht.

    Danke. Ich nehme an, die Fehlermeldung war dann "Disk full"?

    Ich habe einfach mal 250 Files auf eine Native-Disk (1,6 MB, HD-Diskette im CMD-Native-Mode) kopiert. Kein Problem feststellbar. Das CMD-DOS nutzt dann eben freie Blöcke oberhalb des reservierten Bereiches und gut ist.

    Danke.
    Daraus schließe ich jetzt mal, dass beim Hauptverzeichnis die Blocksuche bei T1S34 anfängt und bei Dateien und Unterverzeichnissen erst bei T1S64, und dass es keine weiteren Sonderabfragen/Wraparounds gibt.

    Und ganz ehrlich (meine persönliche Meinung): Native-Mode macht doch erst wirklich Sinn, oberhalb 1 MB. Da funktioniert das auch bis auf das beschriebene auf dem SD2IEC! Wer kleinere DNPs verwenden will, kann ja auf D64, D71 oder D81 umsteigen

    Die genaue Größe ist ja auch nicht von Belang, die von mir genannten Zahlen dienten nur der Erläuterung des Beispiels.
    Worum es eigentlich ging ist: Nach welchen Algorithmen belegt CMD die Blöcke? Und da sind eben mehrere Möglichkeiten denkbar: Es hätte ja zum Beispiel auch sein können, dass bei Dateien und Unterverzeichnissen erst bei T1S64 angefangen wird und bei einem Fehlschlag dann nochmal bei T1S34. Oder dass beim Hauptverzeichnis eben nur der reservierte Bereich durchsucht wird. Aber jetzt ist die Sache geklärt.

  • Die Blockallokationsstrategie der CMD-Geräte ist meines Wissens nirgendwo dokumentiert, sd2iec implementiert daher eine recht einfache Variante.

    Die offensichtlich den Platz besser ausnutzt. :D
    CMD hat wohl - genau wie CBM - die Seek-Zeiten etwas optimieren wollen, was bei SD-Karten ja wurscht ist.

    Kannst du irgendwelche Kompatibilitätsprobleme dadurch feststellen oder ist das nur ein Schönheitsproblem?

    Mit den bisherigen Infos könnte man Kompatibilitätsprobleme zumindest konstruieren... :weg:
    Ich stelle mir vor, dass ein "Fix" eher unschön wäre, weil man dann beim Erweitern eines Verzeichnisses tatsächlich untersuchen müsste, ob es sich um das Haupt- oder ein Unterverzeichnis handelt.

  • Kannst du irgendwelche Kompatibilitätsprobleme dadurch feststellen oder ist das nur ein Schönheitsproblem?

    Bisher nicht, was aber nicht unbedingt was aussagt ;-) . Kann ja nur auf CMD-FD testen.


    Da aber ein DNP ein 1:1 Abbild einer CMD-Native-Partition ist, sollten sich DNPs auch genauso verhalten.....


    die Fehlermeldung war dann "Disk full"?

    Habe ich nicht weiter geprüft, das Fehler-Blinken der FD-LED hat mir gereicht ;-) .


    dass beim Hauptverzeichnis die Blocksuche bei T1S34 anfängt und bei Dateien und Unterverzeichnissen erst bei T1S64

    Das sehe ich anders:
    Die Suche nach freien Blocks sollte grundsätzlich ab Track 1 Sektor 64 beginnen. Nur für das Anlegen einer neuen Directory-Seite sollte sie bei Track 1 Sektor 34 anfangen.


    Gruß
    Werner

  • Das sehe ich anders:Die Suche nach freien Blocks sollte grundsätzlich ab Track 1 Sektor 64 beginnen. Nur für das Anlegen einer neuen Directory-Seite sollte sie bei Track 1 Sektor 34 anfangen.

    Wo ist denn da jetzt der Unterschied zu meiner Formulierung?!
    "Die Katze miaut und der Hund bellt."
    "Nein, das ist ganz anders: Der Hund bellt und die Katze miaut!"

  • Wo ist denn da jetzt der Unterschied zu meiner Formulierung?!

    Ihr meint beide das gleiche. Aber genauer ist: Die Sektor-Suche für das Root-Directory beginnt bei 1:34, ansonsten bei 1:64. Ein Unterverzeichnis ist ja auch ein Directory...


    Die Blockallokationsstrategie der CMD-Geräte ist meines Wissens nirgendwo dokumentiert, sd2iec implementiert daher eine recht einfache Variante. Kannst du irgendwelche Kompatibilitätsprobleme dadurch feststellen oder ist das nur ein Schönheitsproblem?

    Es ist nur indirekt dokumentiert. Im CMD-Handbuch Anhang I steht:
    Max. Seq.Dateigröße: 16.564.864 Bytes
    Das sind genau 65.216 Blocks (a 254Bytes).
    Native kann max. 255*256 Blocks haben, das sind 65.280.
    Abzüglich der 65.216 für die max. Dateigröße bleiben genau 64 Blocks übrig.
    Und damit belegt die CMD Datensektoren erst ab 1:64.


    Man müsste das HD-ROM untersuchen um das zu bestätigen.


    P.S. im HDDOS gibt es die Byte-Folge a9 40 2c a9 01 ... was nach

    Code
    1. lda #$40
    2. b $2c ;BIT, 2 Byte überspringen.
    3. lda #$01

    aussieht. Hab das ROM aber nicht disassembliert. Könnte aber auch heißen das die Suche für das Root-Directory bei 1:1 beginnt. Was nicht unlogisch wäre denn für das reservieren der BAM+RootDir beim Format könnte der Einsprung bei Zeile#3 liegen. Ansonsten bei Zeile #1.

  • "hader Fehler " oder so ähnlich

    Wird wohl Header Fehler gewesen sein. Und als TopDesk benutzt Du den, der am 10.11. im Bereich GEOS veröffentlicht wurde?


    Ansonsten sollten wir diese Diskussion dann im Thema "GEOS" fortsetzen. Da sitzen die Spezialisten ;-) und hier wird das langsam offtopic....


    Gruß
    Werner

  • Gibt es überhaupt eine Möglichkeit die .dnp wider auf eine CMD-HD zu Kopieren ? ( 1:1 )

    Hab's ausprobiert.


    16 MB-Partition von der HD auf's SD2IEC, kein Problem.


    DNP-Image zurück auf eine 16 MB-Partition, ohne Probleme.


    Keine Fehlermeldung und UV's konnten gewechselt werden, Dateien gestartet.
    Auch aufräumen zeigte keine Probleme an.


    Verwendet wurde diese TD-Version.


    Gruss C=Mac.