Hello, Guest the thread was viewed1.4k times and contains 14 replies

last post from darkvision at the

CVT file format

    german translation below - Deutsch Übersetzung unten.


    I think I'll do this topic in english so I can forward answers directly to Gideon. Gideon has a question:




    The main question is, do all CVT files have a GEOS info block?


    From the geos.txt on the internet, it reads:


    Quote

    GEOS files usually have an entity attached called an INFO block. It

    contains ICON info, author, file description, load address etc. However,

    just because an INFO block does not exist for a given file, does not mean

    that the file is not a GEOS file.

    This suggests that not all GEOS files have an info block. But if they don't, what does the CVT file look like?



    I - that's markusC64 - think that's not strictly true. Geos boot files (geomakeboot and likewise) might not have an info block, CVT files also don't. But both are not geos files in a strict sense.


    What do you know?





    Ich denke, ich mache dieses Thema auf Englisch, damit ich Antworten direkt an Gideon weiterleiten kann. Gideon hat eine Frage:




    Die Hauptfrage ist, ob alle CVT-Dateien einen GEOS-Infoblock haben?


    In der geos.txt im Internet steht es so:

    Quote

    GEOS-Dateien haben normalerweise eine Entität angehängt, die INFO-Block genannt wird. Er

    enthält ICON-Informationen, Autor, Dateibeschreibung, Ladeadresse usw. Wie auch immer,

    nur weil ein INFO-Block für eine bestimmte Datei nicht existiert, heißt das nicht

    dass die Datei keine GEOS-Datei ist.


    Dies legt nahe, daß nicht alle GEOS-Dateien einen Infoblock haben. Aber wenn sie keinen haben, wie sieht dann die CVT-Datei aus?




    Ich - also markusC64 - denke, dass das nicht ganz richtig ist. Geos-Bootdateien (geomakeboot und ähnliches) haben vielleicht keinen Infoblock, CVT-Dateien auch nicht. Aber beides sind keine Geos-Dateien im engeren Sinne.



    Was wisst Ihr?

    Ich verstehe das Problem noch nicht so ganz: Muss man wissen ob die Datei eine unter GEOS ausführbare Datei oder ein Dokument ist?


    geoConvert nimmt an, wenn ein InfoBlock vorhanden ist, das es eine GEOS-Datei ist und wandelt diese dann von GEOS nach CVT. Ohne Infoblock wird versucht die CVT-Datei nach GEOS zu wandeln.

    Code
    1. ;*** Ausgewählte Datei konvertieren.
    2. :DoConvert1File jsr FindSlctFile
    3. lda dirEntryBuf+19 ; Track InfoBlock.
    4. beq :101
    5. jmp GEOS_CBM ; => GEOS nach CBM wandeln.
    6. ::101 jmp CBM_GEOS ; => CBM nach GEOS wandeln.

    Bei GEOS->CVT wird erst danach entschieden ob SEQ oder VLIR.


    Es gibt ja sowieso nur zwei Gründe für ein CVT: Der InfoBlock und das VLIR-Format. Ist das nicht gegeben, dann muss man auch nichts konvertieren. Und VLIR in der Regel immer = Infoblock. Also sollte der Infoblock-Test schon ausreichen.


    Kein Infoblock, keine GEOS-Datei und die Konvertierung GEOS->CVT oder CVT->GEOS wird beendet.


    Eine BASIC-Datei nach CVT zu wandeln macht keinen Sinn, wird daher zumindest von geoConvert auch nicht unterstützt.


    Wenn es noch um den Umweg über das FAT-Dateisystem geht, dann kann man ja das Format abwandeln: Grundsätzlich nach CVT wandeln. Dann wird der Verzeichnis-Eintrag mit allen Infos (z.B. GEOS-Dateityp, CBM-Dateityp) in der FAT-Datei mit abgespeichert und könnte auf dem Ziel wieder hergestellt werden.

    Wenn kein Infoblock vorhanden, dann müsste man diesen auch nicht mit abspeichern. Wobei so ein CVT dann kein CVT mehr wäre und von geoConvert auch nicht mehr umgewandelt werden kann.

    Das fütchte ich auch, ein "CVT" ohne Info Block ist einfach useless - hat man das gerade mal auf dem FAT erhalten (vermutlich eher versehentlich aus Benutzersicht), so kann man damit quasi nichts machen - kein Emulator mag das, die Tools auf den PC können damit nicht umgehen und das SD2IEC auch nicht.


    "Echte" Geos Dateien ohne Info Block halte ich ja eher für ein Gerücht, wie bereits eingangs beschrieben.


    Auf der anderen Seite: Eine CVT Routine, die für den Extremfall geeignet ist und dann doch nur mit Info Block aufgerufen wird, ist aus Softwareentwicklungssicht der Idealfall. Wenn man später mal auf die Idee kommt, die zu benutzen, um die Directoryeinträge inkl. möglicher Modifikationen zu übertragen, dann passt das wenigstens.

    Quote from markusC64

    Die Hauptfrage ist, ob alle CVT-Dateien einen GEOS-Infoblock haben?

    Ich versuche es mal ;-) :


    Das obige Zitat stammt aus der Beschreibung "GEOS.TXT". Diese stellt die Information zu dem Format einer Geos-Datei auf Diskette dar. Das hat also erst mal gar nichts mit .CVT zu tun ;-) . Für .CVT gibt es eine eigene Beschreibung (CVT.TXT). Aber in der zitierten Passage ist ein Fehler (oder eine Ungenauigkeit) drin:


    Quote

    However, just because an INFO block does not exist for a given file, does not mean

    that the file is not a GEOS file.

    Das stimmt so nicht. Wird dem Leser (wenn er die gesamte GEOS.TXT liest ;-) ) hoffentlich klar:


    Quote

    5. Check the FILE TYPE byte (position $24). If it is non-zero, then there

    is likely an INFO block attached.

    Eine Geos-Datei muss immer einen Info-Block haben, da sonst wichtige Informationen nicht zur Verfügung stehen (Lade-, Startadresse, zu welcher App gehört die Datei, ...). Diese Infos befinden sich im Info-Block. Der Info-Block ist aber nicht in der normalen Track-/Sektor-Verkettung einer normalen (C64-)Datei mit der Datei verbunden. Deshalb dürfen Geos-Disketten niemals mittels CBM-DOS "Validate" behandelt werden. Das würde die Geos-Dateien zerstören. Gleiches gilt übrigens auch für den VLIR-Index-Block.



    Zur eigentlichen Frage:

    Ein .CVT ist eine konvertierte Geos-Datei (siehe .CVT.TXT). Bei der Konvertierung bleibt der Info-Block erhalten (sonst könnte man die Geos-Datei ja nicht wieder herstellen), wird aber als normaler Block (mit Track-/Sektor-Verkettung über die ersten 2 Bytes eines Blockes innerhalb des .CVT gespeichert. Nur in diesem Format können Geos-Dateien außerhalb Geos kopiert bzw. per DFÜ übertragen werden


    Das .CVT enthält die gesamte Geos-Datei (inclusive Info-Block der Datei). Aber das .CVT selbst ist eine normale C64-Datei und kann/darf somit keinen Info-Block haben.


    Gruß

    Werner

    Quote from markusC64

    Auf der anderen Seite: Eine CVT Routine, die für den Extremfall geeignet ist und dann doch nur mit Info Block aufgerufen wird, ist aus Softwareentwicklungssicht der Idealfall. Wenn man später mal auf die Idee kommt, die zu benutzen, um die Directoryeinträge inkl. möglicher Modifikationen zu übertragen, dann passt das wenigstens.

    Convert oder auch später geoConvert hatten einen ganz anderen Hintergrund: GEOS-Dateien in einer Mailbox oder damals per EMail zu versenden, nachdem man die Dateien mit diversen Tools vom C64 auf den PC konvertiert hat.

    Daraus ist auch geoConvert98 entstanden weil ich damals große Setup-Dateien für MegaPatch austauschen musste. Und die ersten SETUP-Pakete konnte CONVERT nicht verarbeiten (max. 255-Sektoren-Problem). Wurde dann zum Schluss ja aber in mehrere kleinere Dateien aufgeteilt. Für das aktuelle GD3 ist das aber wieder ein Thema, wobei da eh D81 als Container fungieren wird. Von daher Danke für den Reminder ;)


    Also geht es wirklich nur um einzelne GEOS-Dateien. Für was anderes waren die Tools nie gedacht.


    Heute nimmt man da ein D64... das wäre damals wohl Verschwendung gewesen.


    Klar könnte man CONVERT/geoConvert aufbohren um als generisches Container-Format zu fungieren. Aber das nur anzupassen weil das U64 jetzt Dateien über das FAT-Dateisystem austauschen will?

    Wenn man das will kann man ja ein V3-Format erstellen, wo dann die ersten beiden Bytes entweder auf einen Infoblock zeigen oder auf den VLIR-Header oder die Programmdaten. Alles wichtige steht ja im Verzeichnis-Eintrag selbst.


    Ich will den Code eh mal überarbeiten, da sind so viele schreckliche Fehler in den Kommentaren enthalten. Aber ob ich das noch ergänze weiß ich nicht. Das Programm funktioniert so wie es soll.


    Wenn es mal so ein V3-Format in die freie Wildbahn schafft, dann überlege ich mir das ggf. Aber ich sehe da aktuell aus Nutzersicht keinen Bedarf.


    Wenn es nur um lange Dateinamen geht könnte man auch mind. das VFAT-Format unterstützen. Das erlaubt auch längere Dateinamen. SD2IEC zumindest zeigt auch 16Zeichen lange Dateinamen im Root-Verzeichnis an. Für mich war das damals kein Thema weil auf Disketten nur FAT12 unterstützt wird, da gibt es nur 8+3. Daher erstellt geoConvert auch FAT-kompatible Dateinamen. Auf VFAT könnte man sich das schenken und dann würde ein CONVERT V2.x-Format für GEOS-Dateien reichen.

    Um Gottes willen, nicht die existierenden Tools anpassen. Gideon will "nur" wissen, was vorkommt, damit er die Implementierung passend machen kann.


    Wie ich Gideons letzter E-Mail entnehme, hat er erleichtert aufgenommen, dass Geos-Dateien ohne Infoblock nicht vorkommen.


    Edit: Die Dateien auf einen FAT Laufwerk zu speichern, hat natürlich nur zwei Zwekce:


    (1) Um jene später wieder iin ein Dxx Image hineinzukopieren

    (2) Am PC dann jene Dateien vergleichen zu können.

    Quote from markusC64

    (1) Um jene später wieder iin ein Dxx Image hineinzukopieren

    (2) Am PC dann jene Dateien vergleichen zu können.

    Naja... für die beiden Zwecke reicht es aus den Infoblock zu testen und entweder als Datei auf VFAT zu speichern oder als CVT.

    Quote from markusC64

    Um Gottes willen, nicht die existierenden Tools anpassen.

    Naja... zumindest bin ich aktuell schon dabei die Beschreibung des Formats anzupassen und ggf. geoConvert abzusichern: Wenn der Verzeichnis-Eintrag keinen Infoblock beinhaltet muss das Programm abbrechen. Sonst würde der erste Teil der Programm-Daten oder der VLIR-Header selbst als Infoblock gespeichert. Also nur verbesserte Fehlerbehandlung.

    Quote from darkvision

    Also nur verbesserte Fehlerbehandlung.

    Dagegen ist natürlich nichts einzuwenden, wenn man die Robustheit gegenüber ungewöhnlichen Konstellationen auf der Diskette verbessert.


    Quote from darkvision

    Naja... für die beiden Zwecke reicht es aus den Infoblock zu testen und entweder als Datei auf VFAT zu speichern oder als CVT.

    Am besten eine ganze CVT. Recht frisch fertig geworden ist, dass die Ultimate 64 eine CVT von FAT wieder in ein Dxx speichern kann. Erste Tests damit hat Gideon schon durchgeführt - und ich hoffe, dass diesmal da weniger Bugs zu finden sind.


    Da wir alle einhellig meinen, Geos Dateien ohne Infoblock kämen nicht vor, hat Gideon das nun auch nicht vorgesehen.

    Zur Info: Ich hab die Beschreibung des CVT/G98-Formats aktualisiert.

    Ich hab versucht das ins (schlechte) Englische zu übersetzen, da es evtl. auch für nicht-deutsch-sprechende Anwender von Interesse sein könnte. Falls noch jemand Verbesserungsvorschläge hat, dann gerne per Konversation.


    P.S. Oh je... 3x Korrektur gelesen und trotzdem noch Typos... :wand

    Quote from max2022

    ich bin auch auf der Suche nach der Beschreibung des CVT/G98-Formats.

    Ok, G98 ist wieder mal eine deutsche Erfindung (M. Kanet). Damit kann man größere Geos-Dateien konvertieren. Es gibt nur sehr wenige davon ;-) . Es gab z.B. damals (1999 oder so) MP3 in einer einzigen Setup-Datei. Die war zu groß, um sie mit den bis dahin üblichen Convert-Programmen (.cvt-Format) zu bearbeiten. Deshalb wurde das G98-Format entwickelt, was im Prinzip eine Erweiterung des .CVT-Formats ist.


    .CVT existiert schon seit Ende der 1980er Jahre. Man kann Geos-Dateien nicht über Internet oder Mailboxen übertragen. Auch das Kopieren außerhalb Geos geht nicht. Deshalb wurde das .CVT Format erfunden.

    Vorgehen: Geos-Datei in .cvt wandeln, per Internet übertragen, am Zielsystem .cvt in Geos-Wandeln.


    Die originale Beschreibung für .CVT gibt es übrigens hier: https://ist.uwaterloo.ca/~schepers/download.html . In formats.zip sind Beschreibungen für etliche C64-Datei-Formate. U.a. auch für .cvt .


    Gruß

    Werner