Für den oscar64 Compiler überlege ich gerade ob man ein fseek implementieren kann für die stdio.h. Das ist bislang noch nicht existent, und ich frage mich ob das bei CBM Drives überhaupt geht? Gibt es da ein Kommando entweder im Kernal von C64, PET und Co. oder im DOS des Laufwerks um zu Byte (oder Block) X der Datei zu springen? Ich kenne mich nur mit Unix, DOS und so aus, und da ist ein fseek halt absoluter Standard.
Wie in SEQ Datei suchen...?
-
root42 -
23. November 2025 um 10:19 -
Unerledigt
Es gibt 13 Antworten in diesem Thema, welches 301 mal aufgerufen wurde. Der letzte Beitrag (
-
-
- Interessanter Beitrag
Gibt es da ein Kommando entweder im Kernal von C64, PET und Co. oder im DOS des Laufwerks um zu Byte (oder Block) X der Datei zu springen?
Nein. Das Commodore DOS unterstützt das nicht direkt. Du musst also bis zur gewollten Stelle lesen.
Beim einem fseek vom Beginn geht das noch ganz gut (wenn auch langsam), bei einem fseek() von hinten musst du erst die Länge ermitteln (indem du ganz ans Ende springst), dann rechnen und dann an die richtige Position springen (wieder von vorne).
Optimieren kann man das natürlich, indem man die T/S-Linker in jedem Block per Hand bearbeitet, aber dann hat man relativ viel Aufwand, muss sich auch noch einen Speicher für die Linker anlegen und ist auch noch teilweise Laufwerk-spezifisch. Das ist nicht schön.
Dieses Fehlen eines Seek ist der Grund, warum Commodore das REL-Fileformat eingeführt hat, welches es in DOS1 wohl noch nicht gab: Bei REL-Dateien werden die T/S-Linker in extra Blöcken abgespeichert, so dass man halt doch schnell springen kann.
-
Krill Könnte dein Loader da helfen? Kann der an beliebige Stellen in einer Datei springen?
-
Krill Könnte dein Loader da helfen? Kann der an beliebige Stellen in einer Datei springen?
Nee, kann er nicht.
Habe öfter mal über das Seek-Problem nachgedacht, aber bisher noch nichts eingetippt, um es zu lösen.
Das größere Problem wäre da aber die Integration ins DOS - es sei denn, man beschränkt sich auf ein "Fire&Forget"-Seek-Modul, das bei Bedarf ins Laufwerks-RAM gedaddelt und ausgeführt wird und dann, so fix es eben unter den Speicherbeschränkungen (Anzahl freier Puffer) gehen kann, von Anfang der Datei seekt und mit der Datei an der gewünschten Stelle wieder dem DOS die Kontrolle überlässt.
Das wäre dann potenziell viel Tak-tak-tak, aber der Spuk dürfte nach wenigen Sekunden vorbei sein. -
Ja, dass das nicht ohne Einschränkung geht wäre ja okay. Ich überlege gerade was man bräuchte um fseek und ftell umsetzen zu können.
-
Ja, dass das nicht ohne Einschränkung geht wäre ja okay. Ich überlege gerade was man bräuchte um fseek und ftell umsetzen zu können.
Für ftell muss ja nur ein Zähler über die Datei-Operationen (vorrangig read, also CHRIN) mitgeführt werden.
So ein richtiges Seek bräuchte aber entweder einen halbwegs DOS-transparenten Loader... oder ein besseres DOS.
-
Ja, dass das nicht ohne Einschränkung geht wäre ja okay. Ich überlege gerade was man bräuchte um fseek und ftell umsetzen zu können.
Für ftell muss ja nur ein Zähler über die Datei-Operationen (vorrangig read, also CHRIN) mitgeführt werden.
So ein richtiges Seek bräuchte aber entweder einen halbwegs DOS-transparenten Loader... oder ein besseres DOS.
Ja, ftell sollte machbar sein. fseek ginge auch, wenn man die Datei schließt und dann mit fread einfach zur passenden Stelle vorspult. Ist halt nur sehr langsam -- ohne Speedloader.

Ans Dateiende springen ist mir auch noch nicht klar. Kann man die Größe einer Datei erfragen?
-
Ans Dateiende springen ist mir auch noch nicht klar. Kann man die Größe einer Datei erfragen?
Wenn die Directory nicht manipuliert ist, ja.
Mit Blockgranularität.
Sprung ans Ende wäre ja nur Seek von der aktuellen Position aus, bis das Dateiende erreicht ist.Für ein Seek vom Ende rückwärts müsste man es aber so machen, wie strik es beschrieben hat (wegen der Ungenauigkeit der Größenangabe).
Das ist aber kein großes Problem, wenn das Seek vom Anfang halbwegs schnell ist. -
Blockgranularität verstehe ich. Aber woher weiß ich denn wann IM letzten Block die Datei zu Ende ist...?
-
Im letzten Sektor stehen dann anstelle des Track/Sektor-Links als erste zwei Bytes die Werte $00 $xx mit $xx = Index des letzten in diesem Sektor genutzten Bytes.
Krill: könnte man ggfs. die Routine im DOS 'zweckentfremden' die für ",A" (Append) genutzt wird? Die muß ja im Grunde schon das gleiche machen, und wird nur an der gegebenen Position beendet.
-
Krill: könnte man ggfs. die Routine im DOS 'zweckentfremden' die für ",A" (Append) genutzt wird? Die muß ja im Grunde schon das gleiche machen, und wird nur an der gegebenen Position beendet.
Das scheint mir beim Raufgucken auch nur ein Seek vom Anfang via "Vorspulen" zu sein, nur dass das Senden zum Rechner gespart wird. Schnell sieht das auch nicht aus.

-
Schnell sieht das auch nicht aus.

Nett wäre es natürlich, die GCR-Dekodierung auf nur die ersten zwei Bytes im Sektor abzukürzen. Noch netter wäre wahrscheinlich, das Einlesen der Disk-"Rohdaten" auch schon nach den ersten drei Bytes zu beenden. Der absolute Luxus wäre dann vermutlich, diese Daten für alle Sektoren eines Tracks innerhalb einer Umdrehung einzulesen.

Aber wir sind uns schon einig, daß ohne Nutzung einer weiteren Datenstruktur (wie eben die Side-Sektoren bei REL-Files) für eine einigermaßen schnelle Nachbildung von fseek() in CBM DOS eine derartige Routine (im Floppy-RAM) nötig ist, die sich im wesentlichen nur schnell die Sektorverkettung entlang hangelt.
-
Schnell sieht das auch nicht aus.

Nett wäre es natürlich, die GCR-Dekodierung auf nur die ersten zwei Bytes im Sektor abzukürzen. Noch netter wäre wahrscheinlich, das Einlesen der Disk-"Rohdaten" auch schon nach den ersten drei Bytes zu beenden.

Aber wir sind uns schon einig, daß ohne Nutzung einer weiteren Datenstruktur (wie eben die Side-Sektoren bei REL-Files) für eine einigermaßen schnelle Nachbildung von fseek() in CBM DOS eine derartige Routine (im Floppy-RAM) nötig ist, die sich im wesentlichen nur schnell die Sektorverkettung entlang hangelt.
Natürlich. Das war der Gedanke bei "so fix es eben unter den Speicherbeschränkungen (Anzahl freier Puffer) gehen kann".
Je mehr Platz für Code ist, desto mehr dieser Optimierungen kann man einbauen.
Nach den ersten Bytes das Einlesen/Dekodieren zu beenden ist allerdings unschön, weil dann die Prüfsumme nicht überprüft werden kann. Und bis zum nächsten Block warten muss man eh, also kann man auch den Block "in-place" komplett einlesen, dekodieren und prüfsummieren... wenn es der Platz für Code erlaubt.
Ohne Rücksicht auf das DOS kann man aber in einem Loader beim Rückwarts-Seek Bitte melde dich an, um diesen Link zu sehen. machen, um den REL-Quatsch zu vermeiden.
-
Dieses Fehlen eines Seek ist der Grund, warum Commodore das REL-Fileformat eingeführt hat, welches es in DOS1 wohl noch nicht gab: Bei REL-Dateien werden die T/S-Linker in extra Blöcken abgespeichert, so dass man halt doch schnell springen kann.
Das REL-Format erlaubt zwar das Positionieren, aber das Dateiende ist dem DOS nicht (unmittelbar) bekannt. Das müsste/könnte man (etwa binär) suchen (also den letzten Record, der bereits angelegt ist). Also das seek() aus unixoiden Betriebssystem ist selbst damit leider auch nur zu einem Teil abgedeckt. Das war schließlich auch nicht ein Ziel des CBM DOS.
