File nicht von Beginn an einlesen

Eine PRG-Datei ist eine sequentielle Datei, nur mit anderer Kennzeichnung. Mit Direktzugriff ist da also leider nichts.

Mit viel Aufwand und Beschränkungen gäbe es eine Chance, wenn Du Dich an den internen Aufbau der Diskette ranmachst.

Aber dann würde es nicht mehr mit beliebigen Geräten funktionieren, sondern nur noch mit von Dir unterstützen Standard-Formaten und Geräten wie 1541 laufen. Und die 1541 direkt zu programmieren wäre dann auch hilfreich.

Wieso nicht etwas wie "Track & Sector"? Da gab es eine Version auf einer CBM-Demodisk (?T&S), und eine weitere mir bekannte von einer Gruppe.

Quote from Joystick

Wieso nicht etwas wie "Track & Sector"? Da gab es eine Version auf einer CBM-Demodisk (?T&S), und eine weitere mir bekannte von einer Gruppe.

Das ist ein Programm zum Anzeigen der Disketten-Belegung. Was genau soll das jetzt bringen?

EDIT: Oh halt - da reden wir aneinder vorbei. Nicht Diskettenbelegung.

Damit konnte man (zumindest in meiner Version) mit nem Tastatenkürzel ein komplettes Programm Sektor für Sektor nachverfolgen, unabhängig wie es gespeichert wurde, also mit der Sprungadresse am Blockanfang.

Ich hab die Programme auch hier nicht zur Hand, um auf die Schnelle nachzusehen - war nur so ein Gedanke. Zumindest hab ich so damals in die Programme reingeschaut - war vor allem bei Zak McKracken, Detective Game und RMS Titanic für mich recht nützlich.

Edit2:
Auf der CBM-Demodisk heisst die Datei "Display T&S", SO ÄHNLICH (aber wesentlich besser und schneller) war das von mir gemeinte. Man gab Track + Sektornr ein und glaub mit Plus / Minus ging es vor/zurück und bei "J" wurde das Programm mit der Sprungadresse verfolgt. Ich finds nur leider nicht auf Anhieb auf CSDB.

Wie andere schon gesagt haben, du kannst den internen Aufbau der Diskette nachverfolgen: In Track 18 suchst du nach dem Programmnamen, dort wird auch auf den Sektor verwiesen, wo das Programm beginnt. Von da an gilt: jeder Sektor (Block) des Programms enthält 256 Bytes: die ersten zwei zeigen auf den nächsten Sektor, die anderen 254 enthalten "Inhalt". Das kannst du solange lesen, bis das erste (oder die ersten beiden? Weiß nicht mehr) Bytes eines Sektors 0 sind - das ist dann die Ansage, dass es sich hier um den letzten Sektor handelt.

Dieser Ansatz sollte auch mit nicht Commodore-Laufwerken funktionieren. Und natürlich kannst du dich dann auch "rückwärts" in der Datei bewegen, vorausgesetzt du hast irgendwo eine Liste der Sektoren gespeichert, die du bereits entlang gewandert bist.

Mir stellt sich allerdings die Frage "wozu der Aufwand"? Der Anwender will den Text ja lesen, also wieso künstlich einschränken? Ladezeit sparen? Das sollte bei kurzen Textdateien eher nicht ins Gewicht fallen - und wenn doch: Sektorweise auf der Disk herumzusuchen beschleunigen dann halt wieder nicht alle Speeder...

Quote from WebFritzi

...
Dabei ist mir nicht klar, ob es überhaupt möglich ist, eine Datei ab einer bestimmten Position einzulesen ohne sie von Beginn an zu durchlaufen.
...

Mit dem standard CBM DOS Format ist dieses nicht möglich. In den ersten beiden Bytes eines Diskettensektors (data block) befinden sich nur die Informationen für den folgenden Track & Sektor (bzw. letzen Sektor & Restbytes).
Ergo mit diesen Informationen weißt du leider nicht zu welcher Datei die Daten in dem jeweiligen Sektor gehören.
Daher müßtest du eine Datei vom ersten bis zum letzten Sektor scannen und die Track&Sektor Informationen ablegen so wie es z.B. ein IFFL-Scanner tun.

Jetzt habe ich zu langsam getippt...

Auf den Standard-Laufwerken kannst du der Blockkette folgen, damit kannst du jeden Block anspringen.

Schnell wird es nicht, außer du liest die Kette zu Beginn in ein Array ein und kannst dann jeden Block gezielt laden.

Die ersten zwei Bytes eines Blocks zu lesen sollte auch schnell gehen.

Quote from WebFritzi

Momentan tendiere ich dazu, einfach die ersten 1024 Byte einzulesen und gut is. Der Viewer soll eigentlich nur ein kleines Tool zum schnellen Einsehen von Dateien sein - bspw. von Readme-Dateien o.ä. Dafür sollte 1 KB locker reichen.

Die Idee würde ich da auch unterstützen. Eventuell könnte man ja die Länge (oder gar die gesamte Datei) als Option gestalten.

Aber man wirklich schrittweise immer nur einen Teil, einlesen möchte (weil etwa der Platz nicht vorhanden ist, die gesamte Datei am Stück einzulesen), dann würde ich dazu tendieren, ein Programm auf die Floppy laden, das nur die Link-Kette nachgeht (zwar die Blöcke von Disk lesen müsste, aber nicht über den Bus übertragen muss) und die Track und Sektoren aller Blöcke zurück liefert. Man muss da zwar die Datei komplette vom Medium lesen, aber das wird vermutlich doch deutlich flotter gehen, als das komplette Übertragen zum C64.
Am C64 kann man dann die gewünschte Position direkt ansteuern und entlang der Datei wandern (und die Blöcke dann vielleicht in einem LRU-Cache oder so aufheben bzw. im Speicher lassen).

Wie auch schon xionum erwähnt hat, muss das eigentlich kein eigenes Floppy Programm sein. Es gibt ja die Befehle, Blöcke zu lesen (ohne dass sie gleich übertragen werden müssen). Also kann man den Vorgang auch vom C64 aus steuern. Aber es kann aus Interleave-Gründen bzw. Blockanordnung vielleicht zu längerem Lesen vom Medium kommen, wenn zusätzliche Umdrehungen des Meidum notwendig sind, um den entsprechenden Folgeblock zu erwischen.

Quote from JeeK

Aber man wirklich schrittweise immer nur einen Teil, einlesen möchte (weil etwa der Platz nicht vorhanden ist, die gesamte Datei am Stück einzulesen), dann würde ich dazu tendieren, ein Programm auf die Floppy laden,

Wäre damit nicht automatisch ein SD2IEC raus?

Da würde ich dann eher das Verzeichnis Blockweise in den C64 holen bis ich den Verzeichnis-Eintrag gefunden habe, und dann damit die Sektorkette einlesen. Klar, da muss man dann zwischen 1541/71/81/Native unterscheiden, aber das geht auch mit SD2IEC.

P.S. Man könnte die Verzeichnis-Blöcke auch nur in einen Floppy-Buffer einlesen und einzelne Bytes auslesen, dann muss man nicht alle 256 Bytes zum C64 übertragen. Aber auch das sollte mit einem SD2IEC funktionieren.

Aber bei einem SD2IEC speichert man doch gerne außerhalb von Images, mal GEOS ausgenommen.

Quote from darkvision

Wäre damit nicht automatisch ein SD2IEC raus?

Da würde ich dann eher das Verzeichnis Blockweise in den C64 holen bis ich den Verzeichnis-Eintrag gefunden habe, und dann damit die Sektorkette einlesen. Klar, da muss man dann zwischen 1541/71/81/Native unterscheiden, aber das geht auch mit SD2IEC.

Wieso SD2IEC?
Ich meine ja nur von der einen gewünschten Datei. Genau wie du geschrieben hast, aus dem Verzeichnis den Start-Punkt holen und dann die Kette entlang hanteln, aber dabei den Inhalt der Datei nicht zum C64 übertragen. Deswegen hab ich erst gemeint mit einem auf der Floppy laufenden Programm. Aber es müsste auch mit den Blockbefehlen und dem Auslesen der ersten 2 Bytes gehen.

Quote from markusC64

Aber bei einem SD2IEC speichert man doch gerne außerhalb von Images, mal GEOS ausgenommen.

Ja, außerhalb eines DiskImages geht das dann nicht, aber ein README auf einer Diskette hat man in der Regel innerhalb eines D64

Ein Floppy-Programm schließt das SD2IEC ganz aus, die TR/SE-Lösung nur ein SD2IEC-Verzeichnis. Ich weiß gar nicht ob man aktuell ein DiskImage in GUI64 überhaupt verlassen kann... wenn kein SD2IEC-Support da ist wäre die TR/SE-Lösung für mich der kleinste gemeinsame und kompatibelste Weg...

Weil ein SD2IEC eine Floppy oft ersetzen kann. Aber eben keinen Code per M-E oder U2, U3, .. oder ähnlichen ausführen kann.

Und außerhalb von Images hat ein SD2IEC i. d. R. FAT32 (stellt sich die Frage, ob es auch FAT16 sein kann?). Da ist auch nichts mit Blockverkettung über die ersten beiden Bytes. Und sowieso, der Aufbau ist ganz anders, und wegen der anderen Blockgröße der direkte Zugriff auch.

Nee, das SD2IEC wäre recht schnell draußen, wenn man da low-level ran will.

Edit: Was macht denn die Software, dass es unbedingt im Image sein muss? Fast alles außer "U0", "U1", "B-R", "B-W" geht auch außerhalb von Images.

Edit 2: Auch das IDE64 wäre damit raus, das hat nochmals ein anderes Dateisystem.

Quote from JeeK

Ich meine ja nur von der einen gewünschten Datei. Genau wie du geschrieben hast, aus dem Verzeichnis den Start-Punkt holen und dann die Kette entlang hanteln, aber dabei den Inhalt der Datei nicht zum C64 übertragen.

OK, mein Fehler... ich hab "ein Programm auf die Floppy laden" so verstanden, das auf dem Laufwerk selbst ein Programm ausgeführt wird. Das kann ein SD2IEC nicht.

Quote from markusC64

Und außerhalb von Images hat ein SD2IEC i. d. R. FAT32 (stellt sich die Frage, ob es auch FAT16 sein kann?

Klar, FAT12 und FAT16 gehen auch.

Quote from markusC64

Auch das IDE64 wäre damit raus, das hat nochmals ein anderes Dateisystem.

IDE64 und sd2iec akzeptieren den P-Befehl (Position) auch für normale Dateien, sd2iec allerdings nur ausserhalb von Disk-Images - irgendwann rüste ich das vielleicht auch mal für Dateien in Images nach, auf einer SD-Karte ist es ja nicht so schlimm die Datei nochmal von Anfang an durchgehen zu müssen. Die Syntax bei Nicht-REL-Dateien ist "P" plus ein Byte für die Sekundäradresse des zu positionierenden Buffers plus vier Byte für den Offset innerhalb der Datei (little endian, 0-basiert, fehlende Bytes werden als 0 angenommen).

Wozu braucht man denn hier ein Floppy-Programm? Für den vorgesehenen Anwendungsfall reicht es völlig, am Start der Datei (=Anfang des Texts) anzufangen und sich dann Sektor-Weise vor- und zurück zu bewegen. Dass man rückwärts zu einem Teil "geht", den man nicht schon mal geladen hatte, ist ausgeschlossen. Und wenn man nicht gerade eine Anzeige haben will, welchen Anteil des Gesamttexts man bereits gelesen hat, muss die Software auch nicht wissen wie viele Sektoren noch folgen.

Es reicht also völlig, sich beim schrittweisen Laden die Position von bereits gelesenen Sektoren in der richtigen Reihenfolge irgendwo zu merken - dann kann man sich auch problemlos im Text wieder rückwärts bewegen.

Quote from Korodny

Wozu braucht man denn hier ein Floppy-Programm? Für den vorgesehenen Anwendungsfall reicht es völlig, am Start der Datei (=Anfang des Texts) anzufangen und sich dann Sektor-Weise vor- und zurück zu bewegen....

Es reicht also völlig, sich beim schrittweisen Laden die Position von bereits gelesenen Sektoren in der richtigen Reihenfolge irgendwo zu merken - dann kann man sich auch problemlos im Text wieder rückwärts bewegen.

Stimmt irgendwie, so völlig frei muss der Zugriff für den Zweck gar nicht unbedingt sein.

Quote from Korodny

Wozu braucht man denn hier ein Floppy-Programm?

Ich glaub das war hier nur ein Missverständnis...

Wenn es darum geht weiter/zurück zu blättern hätte ich aber auch kein Problem damit wenn man beim einlesen der Daten zu Beginn eine Schleife ergänzt, die Daten vor dem gewünschten Text einfach "überliest" bzw. verwirft... Klar, das dauert dann jedes mal etwas länger, aber man hat die Möglichkeit auch Dateien >1Kb zu lesen ohne TR/SE-Lösung.