Trennlinie im Directory

Es gibt 31 Antworten in diesem Thema, welches 5.708 mal aufgerufen wurde. Der letzte Beitrag (19. September 2019 um 23:26) ist von phat-phu.

  • Spur 18, Sektor 0

    Vorsicht! Sektor 0 enthält die BAM. Das Directory geht in 18/1 los. Zweiter Block ist 18/4 usw...

    Aber nur wenn ein Speeder (z.B. Jiffy) Eingebaut ist. Sonst ist es bei der 1541 18/1 - 18/11 - 18/21 - 18/10 usw. also Interlave 10, die 1571 hat ein Interlave von 6.

    Die Werte 10 und 6 gelten für Dateien, nicht für das Inhaltsverzeichnis. Dort ist der Wert nun mal 3.

    Yes, I'm the guy responsible for the Bitte melde dich an, um diesen Link zu sehen. cross assembler. And some Bitte melde dich an, um diesen Link zu sehen..

  • Mit dem DirMaster kann man das auch sehr schön erledigen.

    .Bitte melde dich an, um diesen Anhang zu sehen.

    Wenn Du ein paar schöne Trenner entworfen hast lassen die sich schön zwischen den Images hin und her kopieren.

    Im Disk Editor kann man verfolgen, wie die ersten beiden Bytes jeweils auf den nächsten Directory Sektor zeigen bis 00 FF.

  • Soweit ich mich erinner ist der Zugang zur DIR-Spur ganz einfach,

    man muß nur die Datei mit

    :OPEN1,8,1,"$": öffnen und schon liest man die Diskettenspur mit dem Inhaltsverzeichnis.

    Erst kommt die BAM, dann die Datei-Einträge.

    Schönen Gruß.

  • Und wie läuft das in Basic?

    Mein einst von entwickelte entwickelte Anwendung "DISK-SORTER" (ist eigentlich ein DIRectory SORTER, aber sei's drum), mag vielleicht als Anschauungsbeispiel dienen, siehe Bitte melde dich an, um diesen Link zu sehen..

    Ein bisschen in meiner eigenen Implementierung geschmöckert und da verwendet ich auch fix den Interleave von 3.

    Es war mir - wenn es stimmt bzw. eine Relevanz haben sollte - nicht bewusst, dass die verwendeten Blöcke in Spur 18 auch korrespondierend in der BAM als belegt bzw. unbelegt gekennzeichnet sind. Ich ging immer davon aus, dass bei einem Neueintrag das Verzeichnis der Link-Kette entlang gesucht wird und die nächste freie Lücke sucht. Da hilft die BAM auch nicht. Das wäre mir schon zu unsicher, weil man eventuell nicht sicher sein kann, ob die Link-Kette wirklich mit Interleave 3 geschrieben ist, d.h. man weiß trotz BAM auch nicht unbedingt den nächsten freien Block, wenn man nicht wirklich die Link-Kette durchgegangen ist. Wenn man aber sowieso die Link-Kette durchgeht (um einen freien Eintrag zu suchen), braucht man die BAM auch nicht mehr. Wenn da nebenbei die BAM aktualisiert wird, ist das dann ja nett, aber sehr sinnvoll erscheint mir das auch nicht mehr. Zumal ändert der Füllgrad ja auch die Free-Block-Count überhaupt nicht. Die 664 freien Blöcke haben ja die 19 Sektoren vom Spur 18 schon abgezogen (vom der Gesamtanzahl 683). So gesehen hätte ich das Directory eigentlich als statische Struktur bestehend aus 18*8 Einträgen gesehen (losgelöst von der BAM).

    Werd ich mal in eine Mußestunde nachforschen oder nachlesen (in einem der Floppy-Buchklassiker) bzw. lasse mich hier gerne durch entsprechende belegte Informationen eines Besseren belehren.

  • Sowas hab ich auch in Basic gebastelt. Für C64 und C128 (80Z-Modus).

    Wenn gewünscht stelle ich das gerne mal hier rein.

    Gruß, Gerd

    Bitte melde dich an, um diesen Link zu sehen.

    Bitte melde dich an, um diesen Link zu sehen.

  • Ich ging immer davon aus, dass bei einem Neueintrag das Verzeichnis der Link-Kette entlang gesucht wird und die nächste freie Lücke sucht. Da hilft die BAM auch nicht.

    So wird zunächst gesucht, ob es freie Einträge in den vorhandenen Directoryblocks gibt, richtig. Ist dies nicht der Fall, wird dann mit Interleave 3 weitergezählt, und von da aus der nächste Block belegt, der in der BAM eben als frei markiert ist. Ist kein solcher vorhanden, gibt es ein DISK FULL zurück. Ob da auch leichtsinnigerweise Spur 18, Sektor 0 mit einbezogen wird, sollte dieser Block als frei markiert sein, habe ich nicht geprüft.

    d.h. man weiß trotz BAM auch nicht unbedingt den nächsten freien Block, wenn man nicht wirklich die Link-Kette durchgegangen ist.

    Für das Folgen der Link-Kette (um daraus die BAM zu generieren) ist VALIDATE zuständig. Das sollte man auch unbedingt ausführen, wenn der Verdacht besteht, daß mit der BAM was nicht stimmen könnte. Sonst könnte nämlich jeder weitere SAVE Dateien abschießen. Das ist eine Tücke, die bei Verwendung von Diskwizzard durchaus passieren kann, wenn man unvorsichtig ist, weil dieses Programm eben auch die BAM ignoriert.

    Die 664 freien Blöcke haben ja die 19 Sektoren vom Spur 18 schon abgezogen (vom der Gesamtanzahl 683).

    Die werden nicht mitgezählt, weil sie nicht für Dateien vorgesehen sind. Dennoch funktionieren dort auch Dateien, was dann aber die Anzahl der möglichen Verzeichniseinträge reduziert.

  • Für das Folgen der Link-Kette (um daraus die BAM zu generieren) ist VALIDATE zuständig. Das sollte man auch unbedingt ausführen, wenn der Verdacht besteht, daß mit der BAM was nicht stimmen könnte. Sonst könnte nämlich jeder weitere SAVE Dateien abschießen. Das ist eine Tücke, die bei Verwendung von Diskwizzard durchaus passieren kann, wenn man unvorsichtig ist, weil dieses Programm eben auch die BAM ignoriert.

    In der Tat, da muss ein Directory-Sorter tatsächlich, wenn es mehr Blöcke schreibt als er gelesen hat, die BAM mitziehen. Das

    Ich muss gestehen, meine erwähnte Applikation tut dies derzeit nicht (in V1.21). X/

    Wenn da nämlich im Directory keine Lücken sind und am Ende ein nicht in der BAM als belegt gekennzeichneter Block in Verwendung ist, wird ein SAVE für einen neuen Eintrag genau diesen Block als "frei" überschreiben.

    So wird zunächst gesucht, ob es freie Einträge in den vorhandenen Directoryblocks gibt, richtig. Ist dies nicht der Fall, wird dann mit Interleave 3 weitergezählt, und von da aus der nächste Block belegt, der in der BAM eben als frei markiert ist. Ist kein solcher vorhanden, gibt es ein DISK FULL zurück. Ob da auch leichtsinnigerweise Spur 18, Sektor 0 mit einbezogen wird, sollte dieser Block als frei markiert sein, habe ich nicht geprüft.

    Kann nicht einbezogen werden, da der Block initial in der BAM als belegt gekennzeichnet ist (wie auch 18/1).

  • In der Tat, da muss ein Directory-Sorter tatsächlich, wenn es mehr Blöcke schreibt als er gelesen hat, die BAM mitziehen. Das

    Ich muss gestehen, meine erwähnte Applikation tut dies derzeit nicht (in V1.21). X/

    Wenn da nämlich im Directory keine Lücken sind und am Ende ein nicht in der BAM als belegt gekennzeichneter Block in Verwendung ist, wird ein SAVE für einen neuen Eintrag genau diesen Block als "frei" überschreiben.

    Schnell mal eine Bitte melde dich an, um diesen Link zu sehen. nachgelegt, die das Problem behebt. Die BAM wird immer genau entsprechend der verbrauchten Dir-Blocks gesetzt (egal, ob weniger oder mehr verbraucht werden).

  • Schnell mal eine Version 1.22 nachgelegt, die das Problem behebt.

    Jau, schnell mal.

    • V1.21 1987-01-29 alte Version, siehe auch Abschnitt Bitte melde dich an, um diesen Link zu sehen.!
    • V1.22 2019-09-04 aktuelle Version

    Was sind schon ~32 Jahre unter Freunden. :)

  • Jau, schnell mal.

    V1.21 1987-01-29 alte Version, siehe auch Abschnitt Fehler!
    V1.22 2019-09-04 aktuelle Version

    Was sind schon ~32 Jahre unter Freunden. :)

    Da könnte sich Mirkosoft mal eine Scheibe abschneiden, bei DEN Supportzeiträumen und vor allem zu den Supportkosten! :thumbup:

  • Jau, schnell mal.

    Ja ganau, seit der Kenntnis des Fehlers bis zu Behebung ... eine Frage der Ehre. Ich kann ja kein potenziell fehlerhaftes Programm online lassen (selbst wenn die "Userbase" mit mir alleine überschaubar bleibt). ;) Da muss man jedenfalls nicht auf den "Patch-Day" warten ... :D

  • Sowas hab ich auch in Basic gebastelt. Für C64 und C128 (80Z-Modus).

    Wenn gewünscht stelle ich das gerne mal hier rein.

    Gruß, Gerd

    Gerne! Magst Du's hier mal anhängen?