wie ist das mit einem Block auf einer Diskette?

Es gibt 15 Antworten in diesem Thema, welches 2.850 mal aufgerufen wurde. Der letzte Beitrag (10. Juni 2010 um 22:44) ist von Heiko.

  • wie ist das mit einem Block auf einer Diskette?

    Ein Block sind 256 Byte.

    Sind das alles Bytes welche für mein Programm da sind oder auch Bytes welche etwa auf den nächsten Block zeigen?

    Stehen also alle 256 Byte für mein Programm zur Verfügung?

    wieso belegt ein exakt 4 kB großes ROM Image welches ich mit prlink von meinem PC auf mein CBM 8250 Diskettenlaufwerk geschoben habe 17 Block und nicht 16 Block? (4kB=16 x 256 Byte)

  • Die ersten beiden Bytes Zeigen auf den nächsten Block (Track + Sektor). In einem Block sind also 254 Datenbytes.

  • Hallo,

    ich mag mich irren, aber wenn ich mich recht erinnere zeigen die ersten beiden Bytes des Datenbereichs eines Blocks auf den nächsten Block, oder enthalten eine Endmarkierung.
    So steht es zumindest im Handbuch meiner 1541er. Der Aufbau eines Blocks ist, soviel ich weis, bei allen GCR-Floppys gleich, sodaß es auch auf Deine zutrifft.

    Ich mutmaße einfach mal, daß es ein Überbleibsel aus den Anfängen der Datenspeicherung bei Commodore mit Tonbandkassetten ist.

  • Wenn der TRACK gleich 0 ist, dann ist es der letzte Block der Kette. Und dann ist das zweite byte (SECTOR) die Anzahl der Bytes im letzten Block.

    Bitte melde dich an, um diesen Link zu sehen. --- Bitte melde dich an, um diesen Link zu sehen. --- Bitte melde dich an, um diesen Link zu sehen.

  • Danke das erklärt wieso mein 4kB image 17 Block und nicht 16 Block lang ist.

  • Danke das erklärt wieso mein 4kB image 17 Block und nicht 16 Block lang ist.


    Nicht ganz :)

    Zudem hat Dein Image vermutlich 2 bytes vorweg als Startadresse.

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

  • Zusammengefasst: ein Blick besteht aus 256 Byte, die sind Nummeriert (auser Direktory, da ist es anders) von 0 - 255. Es ergeben sich folgende Belegungen, bei PRG-Files.

    1. Block: Byte 0 Spur, Byte 1 Track, Byte 2 Lo-Byte Rechner und Byte 3 Hi-Byte.

    Alle Folgeblöcke: Byte 0 Spur, Byte 1 Track.

    Letzter Block: Byte 0 ist immer 0 als Endekennung, Byte 1 Anzahl der restlichen Bytes.

    Wem es beim Bit zählen schwindelig wird, der hat zuviel davon.

    Alt werden ist schön, das Altern nicht.

  • Byte 1 Anzahl der restlichen Bytes.

    Byte 1 ist die Anzahl belegter Bytes im Sector, das ist inkl. der beiden Bytes 0 und 1. Wenn also noch 26 Bytes "Restprogramm" in diesem Sektor gespeichert sind, steht in Byte 1 eine 28.

    Basic V2 Programme unter Windows editieren: Bitte melde dich an, um diesen Link zu sehen.

  • Ich mutmaße einfach mal, daß es ein Überbleibsel aus den Anfängen der Datenspeicherung bei Commodore mit Tonbandkassetten ist.

    Nein. Es ist eine Grundvoraussetzung um Dateien unterschiedlicher Länge auf einer Diskette unterzubringen. Commodore hält im Directory nur ein Bit pro Datenblock vor, das angibt ob der Block frei ist (BAM). Der IBM-PC sammelt sämtliche Verkettungs-Zeiger im Directory und verzichtet auf eine separate Liste der freien Sektoren (FAT). CP/M notiert die belegten Blöcke bei jedem Dateieintrag und muß sich jedesmal durch die Liste hangeln, wenn es einen neuen block beshcreiben möchte (deswegen muß man unter CP/M 2.2 nach dem Diskettenwechsel einen Soft-reset auslösen)

    Immer aber gibt es irgendwo eine Angabe, wo der nächste Block steht oder ob dieses der letzte der Datei ist.

    KI-Verwendung in diesem Posting: Rechtschreibkontrolle des Browsers.
    Abweichungen aufgrund des technischen Fortschritts oder individueller Vorlieben vorbehalten.

  • An mc71,

    sorry, hatte mich falsch ausgedrück.
    Ich meinte damit den Umstand, daß ein Block ausgerechnet 256 Byte lang ist.
    Die Commodore Rechner speicherten, soweit ich mich erinnere, die Daten auf Datasette schon in Blöcken zu 256 Byte.
    Man hat das dann wohl für die Disketten übernommen, allerding dann leider zwei Byte als Zeiger abgezweigt.
    Zumindest mutmaße ich es mal so.

  • Naja, genaugenommen drängen sich 256 Bytes bei einem 8-Bitter ja direkt auf, eine Page, die man schön indiziert mit ,X oder ,Y in Assembler beackern kann. das dürfte der eigentliche Grund für diese Größe sein.

    Auf der Disk sieht es ja noch viel schlimmer aus, weil die Daten GCR-kodiert werden und dann ist so ein Block ein ziemlich langer Bitstream, der echt unhandlich ist...

    Basic V2 Programme unter Windows editieren: Bitte melde dich an, um diesen Link zu sehen.

  • Die Länge von Blöcken auf Datenträgern ist eigentlich immer eine 2-er Potenz. Also 256, 512, 1024 usw. Mit Tapes hat das nichts zu tun, denn das Commodore Tape Format kennt keine Blöcke.

  • Hallo fröhn,

    äh doch.
    Bei Programmen wird bei allen Commodore-Computern (von PET2001 bis C128 ) jeder Block ja zwei mal hintereinander auf das Band geschrieben bevor er zum nächsten kommt, um eine Hohe Datensicherheit zu erreichen. Dadurch sinkt ja dabei auch die effektive Datenrate von 300bps auf 150bps (beides etwa). Es wird aber nicht das Programm als ganzes abgespeichert und das dann nochmal wiederholt.
    Und diese Blöcke beinhalten, neben einem langen Vorspann und jeder Menge syncronisations und Summenzeichen, bis zu 256 Byte Daten.
    Nur der erste Block, der Programmname und noch ein paar andere Angaben beinhaltet, und vielleicht der letzte, je nach Dateigröße, hat weniger.

  • Es wird aber nicht das Programm als ganzes abgespeichert und das dann nochmal wiederholt.


    Doch. Deswegen konnte man zB bei Turbotape schon nach der Hälfte den Ladevorgang abbrechen und das Programm starten. Sparte nochmal Zeit :)

  • Ja, ich habe es jetzt gefunden.
    Nicht Programme, sondern Daten-Files. Also Haeder Typ 2-Dateien waren es. Und diese Blöcke waren dann nicht 256 sondern 192 Byte groß.
    'tschuldigung, habe mich vertran.
    (Gefunden in "64 Intern" Seite 110)
    Also muß ich das zuerst gesagte wieder Zurücknehmen. Die Blockgröße der Floppy hat nichts mit der der Datasette zu tun.