Editor für Relative Dateien

  • Chagizzz schrieb:

    Kann ich nicht die entsprechenden Blocks in der BAM als belegt kennzeichnen und den Rest der Disk wie gewohnt nutzen?
    Sorry, hab mich ein wenig mißverständlich ausgedrückt. Klar, man kann natürlich die Blocks belegen und die restlichen weiter über das Dateisystem benutzen. Es ging nur darum, daß die Textdaten beim Direktzugriff nicht mehr mittels einer Datei verwaltet werden. (Das wäre theoretisch zwar möglich, indem man den Sektoreninhalt auf 254 Bytes begrenzt und die belegten Sektoren wie üblich verkettet. Man könnte sogar dahingehen, diese Sektoren auch als eine Datei anzulegen, diese Datei dann zu Programmbeginn zu scannen und eine zusätzliche Liste der beteiligten Sektoren zu erstellen. Aber das Ganze wird dann schon sehr umständlich.)

    Chagizzz schrieb:

    reden wir hier von dieser ASM-Compo #3: Text Compression Compo?
    Ja, genau. Basic war aber, glaube ich, nicht dabei. Wenn ich mich recht erinnere, verwendete Roland für seinen 1.Platz-Beitrag auch eine erweiterte Form des 4-Bit-Packers. Nope, 5 Bits (Hab auch gerade gesehen, daß mein primitiver 4-Bit-Packer auf Platz 5 kam. Also so schlecht scheint der nicht zu sein. ^^ )

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von M. J. ()

  • domspitze schrieb:

    Bleibt trotzdem die Frage, wie ich das Textimage -jenseits vom Emulator -auf eine bestimmte Blockposition zwinge.
    Eigentlich brauchst Du dafür gar kein Programm wie DirMaster. Das D64-Format ist ja ein sehr einfaches Format. Die ersten 256 Bytes entsprechen genau dem ersten Sektor des ersten Tracks. Die nächsten 256 Bytes sind dann der zweite Sektor des ersten Tracks usw. Du kannst Dir also ein Image in Dein Hilfsprogramm reinladen, direkt die Textdaten an den Anfang des Images kopieren und danach das so geänderte Image zurückschreiben. Wenn Du magst, kannst Du noch zusätzlich in der BAM die Bits anpassen als Kennzeichen, daß diese Sektoren belegt sind. Solange Du aber nichts anderes auf diese Diskette speicherst, wäre es egal. Mit Programmen wie DirMaster arbeite ich so gut wie nie. Da das D64-Format so simpel ist, kann schon der Assembler stattdessen direkt ein fertiges Image auswerfen.
  • domspitze schrieb:

    Nein. Die Einstellungen werden nicht genutzt. Aber ich habe eine Lösung gefunden, um in Laufwerk 9 eine Diskette beim Start einzulegen. Ist blau markiert.
    :thumbup:

    M. J. schrieb:

    Man könnte sogar dahingehen, diese Sektoren auch als eine Datei anzulegen, diese Datei dann zu Programmbeginn zu scannen und eine zusätzliche Liste der beteiligten Sektoren zu erstellen.
    Na so kompliziert klingt das eigentlich nicht. Das Scannen müsste ja nicht Bestandteil des Programms sein.

    M. J. schrieb:

    (Hab auch gerade gesehen, daß mein primitiver 4-Bit-Packer auf Platz 5 kam. Also so schlecht scheint der nicht zu sein. )
    Nö, glaub ich auch nicht. Man muss halt sehen, ob der "Aufwand" sich am Ende lohnt. Sicher könnte spart man etwas ladezeit, aber wenn man immer die nächsten beiden Blöcke bereits eingelesen hat, kann man bei Beginn der Ausgabe von Block 2 ja den nächsten laden.
    carrier lost...
  • M. J. schrieb:

    Das Laden der Daten aus einer REL-Datei (oder generell über das Dateisystem der 1541) ist sehr langsam.
    Nö, wieso? Sobald die REL-Datei geöffnet ist, behält das Laufwerk einen Side-Sektor im RAM und kennt damit die Spur/Sektor-Werte von 120 Datenblöcken. Greift man auf einen anderen 120-Block-Bereich der Datei zu, muss erst ein anderer Side-Sektor geladen werden, aber dessen Position ist ja ebenfalls schon bekannt.
    Das Zugriffsinterface mit 1-basierten Indizes und fester Datensatzgröße ist natürlich krank, aber dafür schreibt man sich Wrapperfunktionen und gut ist (ich empfehle Datensatzgröße 254, aus naheliegenden Gründen ;) ).

    M. J. schrieb:

    Es gibt aber noch einen Grund, warum man einen Direktzugriff verwenden sollte: Man kann dann in dem verbleibenden freien Speicher des C64 einen Sektorcache anlegen, der beim Spielen dafür sorgt, daß weniger nachgeladen werden muß. Die beste Beschleunigung von Diskettenzugriffen ist immer noch, nicht auf Diskette zuzugreifen.
    Gute Idee, aber das hat nichts mit Direktzugriffen zu tun. Einen Cache kann man ebensogut auch für REL-Zugriff oder Einzeldateien implementieren.

    M. J. schrieb:

    Klar, man kann natürlich die Blocks belegen und die restlichen weiter über das Dateisystem benutzen. Es ging nur darum, daß die Textdaten beim Direktzugriff nicht mehr mittels einer Datei verwaltet werden. (Das wäre theoretisch zwar möglich, indem man den Sektoreninhalt auf 254 Bytes begrenzt und die belegten Sektoren wie üblich verkettet. Man könnte sogar dahingehen, diese Sektoren auch als eine Datei anzulegen, diese Datei dann zu Programmbeginn zu scannen und eine zusätzliche Liste der beteiligten Sektoren zu erstellen. Aber das Ganze wird dann schon sehr umständlich.)
    ...und wäre dann genau das, was einem das DOS bereits fix und fertig in Form von REL-Dateien anbietet. :P
    Yes, I'm the guy responsible for the ACME cross assembler
  • Jungs ihr macht mich fertig. Immer wenn ich denke die Lösung wäre gut dann macht ihr mir die andere wieder schmackhaft. Danke für den Input.

    Endurion schrieb:

    @domspitze: Weil ich da gerade zwei Einträge für VICE mit und ohne Truedrive sehe: Du kannst da auch das Floppy-Icon im Toolbar benutzen, damit steuerst du, ob C64Studio die "mit Truedrive" oder "ohne Truedrive"-Parameter an VICE übergibt.
    Die Funktion habe ich noch gar nicht wahrgenommen. Ist aber für mich nicht gut. Wenn ich true drive über das Icon aktiviere gehen die Einstellungen in der Configuration verloren und das D64 wird nicht in Laufwerk 9 geladen. Es wäre gut, wenn in den Configurations noch ein Feld für zusätzliche Parameter der Kommandozeile Vice hätte. Alles weitere dazu schreibe ich in den entsprechenden Thread.
    64er-Zeitschriften gesucht:
    1984: 9 in gutem Zustand

    Ansonsten 64er 1984-1994 sind komplett wieder da. :D

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von domspitze ()

  • Mac Bacon schrieb:

    ...und wäre dann genau das, was einem das DOS bereits fix und fertig in Form von REL-Dateien anbietet.
    Aber nur fast, denn bei REL-Dateien hat man ja weiterhin die feste Recordgröße, die für Ausgabestrings bei einem Adventure und damit Stringlängen zwischen 10 bis 160 (oder mehr) eher ungeeignet ist.

    Mac Bacon schrieb:

    Einen Cache kann man ebensogut auch für REL-Zugriff oder Einzeldateien implementieren.
    Cache bei Einzeldateien? Haben die Einzeldateien verschiedene Längen, stößt man früher oder später auf das Problem des fragmentierten Speichers. Ist auch recht umständlich zu implementieren. Sind die Dateien gleich lang, entspricht dies der vorgestellten zweiten Lösung.
    Und REL-Dateien cachen? Wie das denn? Das Laufwerk selber cacht nur einen Sektor, was aber nicht ausreicht, wenn die Strings an verschiedenen Stellen auf der Diskette liegen. Wenn ich es richtig verstehe, schlägst Du vor, die REL-Datei dazu zu verwenden, Sektoren von 254 Bytes Größe zu imitieren, die dann mit dem beschriebenen Verfahren gecacht werden können. Fragt sich nur: wozu? Was wäre daran einfacher? Da ziehe ich das KISS-Prinzip vor, zumal es kaum Schnellader geben dürfte, die REL-Zugriffe beschleunigen. Bei einem Direktzugriff oder einem Laden von Dateien kann man hingegen sehr einfach einen Schnellader auch nachträglich transparent dazwischenschalten.
  • M. J. schrieb:

    Mac Bacon schrieb:

    ...und wäre dann genau das, was einem das DOS bereits fix und fertig in Form von REL-Dateien anbietet.
    Aber nur fast, denn bei REL-Dateien hat man ja weiterhin die feste Recordgröße, die für Ausgabestrings bei einem Adventure und damit Stringlängen zwischen 10 bis 160 (oder mehr) eher ungeeignet ist.
    Ich glaube wir sind uns einig, dass die feste Recordgröße von REL-Dateien schon immer eine blöde Idee war und 24-Bit-Indizes deutlich besser gewesen wären. Aber wenn man REL-Dateien mit direkten Blockzugriffen vergleicht, sind REL-Dateien in dieser Hinsicht trotzdem besser, da dort die Recordgröße wenigstens noch im Bereich von 2..254 wählbar ist.
    Direkte Blockzugriffe haben dagegen eine unveränderliche implizite Recordgröße von 256 Bytes (bzw. 254, wenn die Blöcke verlinkt sind).
    Natürlich kann man durch eigenen Code eine beliebige andere Unterteilung wählen, aber das gilt halt für beide Möglichkeiten.

    M. J. schrieb:

    Wenn ich es richtig verstehe, schlägst Du vor, die REL-Datei dazu zu verwenden, Sektoren von 254 Bytes Größe zu imitieren, die dann mit dem beschriebenen Verfahren gecacht werden können. Fragt sich nur: wozu? Was wäre daran einfacher?
    • man muss nicht mit Tracks und Sektoren hantieren (z.B. um manuell das Verzeichnis zu überspringen und solche Scherze)
    • man kann die Blockbelegung komplett dem DOS überlassen
    • man ist nicht an ein bestimmtes Diskettenformat und damit an eine Maximalkapazität gebunden

    M. J. schrieb:

    zumal es kaum Schnellader geben dürfte, die REL-Zugriffe beschleunigen.
    Jiffy ist jetzt nicht soo selten...

    Eigentlich wollte ich mich hier gar nicht auf REL-Files versteifen, ich wollte nur die diversen Teilprobleme (Adressierung der Strings, feste vs. dynamische Längen, Caching, Implementation des "Block-Device") sauber voneinander getrennt wissen... :whistling:
    Yes, I'm the guy responsible for the ACME cross assembler
  • Mac Bacon schrieb:

    Direkte Blockzugriffe haben dagegen eine unveränderliche implizite Recordgröße von 256 Bytes
    Yep, weil sie sich an den Sektoren orientieren, die die Grundlage der Disketten bilden. Da Laufwerke nur sektorenweise lesen oder schreiben können, paßt dies halt am besten. Daß REL-Dateien auch andere Recordgrößen haben können, ist für den vorliegenden Fall irrelevant, da die Daten an sich blöderweise keine feste Größe haben. Um sich das Leben zu erleichtern und den Algorithmus (auch fürs Cachen) möglichst zu vereinfachen, bietet es sich an, die Daten in Häppchen mit einem Vielfachen von 256 zu verwalten.

    Mac Bacon schrieb:

    man muss nicht mit Tracks und Sektoren hantieren (z.B. um manuell das Verzeichnis zu überspringen und solche Scherze)
    Das wäre tatsächlich kein großes Problem. Eine kleine Tabelle mit der Anzahl der Sektoren pro Track und einem Test auf den Verzeichnistrack wäre schon alles, was man dafür braucht.

    Mac Bacon schrieb:

    man kann die Blockbelegung komplett dem DOS überlassen
    Wozu braucht man eine Blockbelegung, wenn man das DOS ohnehin umgeht?

    Mac Bacon schrieb:

    man ist nicht an ein bestimmtes Diskettenformat und damit an eine Maximalkapazität gebunden
    Das Diskettenformat der 1541 ist nun schon seit Jahrzehnten festgeschrieben und wird sich auch nicht mehr ändern.

    Mac Bacon schrieb:

    Eigentlich wollte ich mich hier gar nicht auf REL-Files versteifen, ich wollte nur die diversen Teilprobleme (Adressierung der Strings, feste vs. dynamische Längen, Caching, Implementation des "Block-Device") sauber voneinander getrennt wissen...
    Ja, da hast Du recht. Man sollte die verschiedenen Layer wirklich sauber voneinander trennen. Mit klaren Schnittstellen zum nächst unteren Layer wird das Programm dann auch so gestaltet, daß man später frei wechseln kann zwischen REL-Datei, Direktzugriff oder was auch immer.

    Mac Bacon schrieb:

    Jiffy ist jetzt nicht soo selten...
    Schön für die Leute, die es besitzen. Selber habe ich Jiffy noch nie gehabt. Aber der eigentliche Punkt ist, daß Du damit auch indirekt zugibst, daß das ursprüngliche DOS nicht gut ist. Leider ist genau dies meine rein persönliche Einschätzung. Es ist langsam und schlampig programmiert (Jiffy gibt es nicht ohne Grund), aber auch vom prinzipiellen Ansatz her zumindest hinterfragbar. Das betrifft sowohl die Struktur der Disketten als auch die gesamte Konzeption (Verlagerung des Betriebssystems in die Geräte usw.). Aber wahrscheinlich liegt meine eher skeptische Einstellung einfach daran, daß ich ursprünglich vom AppleII komme. Da hat sich keiner Gedanken über REL-Dateien gemacht. Da hat man einen kleinen Lader im Programm gehabt, der fix beliebig Sektoren von Diskette laden konnte und fertig. Und brauchte man ein modernes Betriebssystem, nahm man später dann ProDos, welches u. a. von sich aus die angeschlossenen Geräte blockweise verwaltete.
    Aber keine Bange, ich verstehe Deine Einwände durchaus und finde sie auch berechtigt. :bia Es ist nur so, daß ich persönlich mich schon vor einiger Zeit dazu entschieden habe, dieses 30 Jahre alte schlechte System nach Möglichkeit nicht mehr zu verwenden, sondern lieber auf etwas Maßgeschneidertes zu setzen, was meinen Ansprüchen (z. B. schnelles Laden von Daten bei eingeschaltetem Interrupt) genügt. Nur weil etwas vor 30 Jahren mal so und so war, heißt es für mich nicht, daß ich es immer noch verwenden muß. :weg:
  • Chagizzz schrieb:

    Um die Daten nicht versehentlich zu überschreiben.
    Dazu müßt aber auch irgendwer auf genau diese Diskette schreiben wollen. ^^

    Chagizzz schrieb:

    Ich denke es ging eher darum, wenn man über die 1541 hinaus will.
    Ich verstehe diesen Gedanken durchaus, und der wäre auf heutigen noch in der Weiterentwicklung befindlichen Systemen durchaus berechtigt. (Abgesehen von den ganzen Layern, die einem vom Betriebssystem und Geräteherstellern auferlegt werden.) Leider wird aber der C64 nicht mehr weiterentwickelt. :( Es gibt über die 1541 nicht mehr viel, was man berücksichtigen könnte. Was z. B. den C65 als Zielplattform anbelangt, muß man sich dort keine Gedanken mehr machen um das Nachladen von Diskette. Dort kann man das ganze Programm mit allen Daten direkt in den Speicher laden. Als Magnetscheiben basierter Massenspeicher würde mir nur noch die 1581 einfallen, doch glaube ich nicht, daß selbst diese real als Hardware wirklich weit verbreitet ist. Da wäre die Verwendung eines Steckmoduls als moderner immer noch neu hergestellter Massenspeicher wesentlich sinnvoller, zumal Module nicht nur von Vice und anderen Emulatoren berücksichtigt werden, sondern auch vom TC64. Doch bei Modulen gilt wieder, daß der deren Speicher in Blöcken von 256 und Vielfachem davon organisiert ist und nicht in 254. Wenn man also daran denkt, bei einer großen Datenmenge Module einzusetzen, sollte man REL-Dateien auch umgehen.
    Das Problem ist leider, wie man es auch dreht und wendet, daß wir es bei unseren Schätzchen nicht nur mit alter Hardware, sondern auch mit alter Software zu tun haben. Bei der Hardware sagt man sich als Programmierer: "Okay, die ist so und so gegeben, und ich begreife es als Herausforderung, durch Programmierung das Maximum herauszuholen." Bei der Software aber sagt man sich: "Taugt sie was? Dann kann ich sie gebrauchen. Taugt sie nichts? Dann weg damit." Klar, kann man REL-Dateien gebrauchen und darauf setzen, daß der Benutzer einen modernen Patch namens Jiffy für das alte DOS verwendet, und wenn nicht, halt in die Röhre guckt. Man kann aber auch davon ausgehen, daß das D64-Format DAS weitverbreiteste Format auf dem C64 überhaupt ist, und wenn man will, daß die Leute das Programm benutzen, gar nicht umhin kommt, es zu verwenden. Und dann ist die Frage: Was mache ich als Programmierer damit? Verwende ich die umständliche Software von damals, nur weil sie halt da ist, oder mache ich es auf moderne Art? Es ist eine persönliche Entscheidung, die jeder für sich selber treffen muß (Wo ich stehe, dürfte klar sein. ^^ ), denn letzten Endes gibt es auch hier keine absolut richtige ideale Lösung für alles und jeden. :(
  • M. J. schrieb:

    Dazu müßt aber auch irgendwer auf genau diese Diskette schreiben wollen.
    ... ungezielt schreiben wollen, ja. Das Spiel selbst kann ja Schreiben wo wirklich Platz ist. Also nicht sooo wichtig, stimmt schon.

    Du hast durchaus Recht, was die "spezielle Hardware" angeht. Insbesondere, da es sich um ein Spiel handelt und nicht um "Spezialsoftware", ist evtl. wünschenswert, dass man mit Standardhardware auskommt - ich weiß, da gibt es hier auch andere Meinungen. Wofür hat man die gute Zusatzhardware, wenn man nicht auch da alles herausholt - mit neuer Software.

    M. J. schrieb:

    Bei der Hardware sagt man sich als Programmierer: "Okay, die ist so und so gegeben, und ich begreife es als Herausforderung, durch Programmierung das Maximum herauszuholen."
    :ilikeit: Stimme ich Dir voll zu. Das ist für mich auch der Reiz. Ich kann aber auch verstehen, dass jemand die tolle Zusatzhardware auch gerne ausgereizt haben will.
    Ich meinte hier mit "über die 1541 hinaus" allerdings eventuelle Möglichkeiten von REL-Files außerhalb von .d64, wobei ich eher vermute, dass das mit der Ultimate oder dem sd2iec wohl nicht geht - weiß ich jetzt allerdings nicht.

    Allerdings werden wir etwas OT... :whistling:
    carrier lost...
  • Chagizzz schrieb:

    Ich kann aber auch verstehen, dass jemand die tolle Zusatzhardware auch gerne ausgereizt haben will
    Kann ich auch gut nachvollziehen, zumal es öfters zu dem Henne-Ei-Problem führt: Ohne Software keine Verbreitung der Hardware. Ohne Verbreitung keine Software. Vielleicht ist es am besten, Programme so zu gestalten, daß sie neue Hardware erkennen und dann als Special Feature verwenden (so wie die 2Mhz-Beschleunigung beim C128), aber nicht zwingend eine bestimmte Hardware außerhalb des Standards voraussetzen.

    Chagizzz schrieb:

    Ich meinte hier mit "über die 1541 hinaus" allerdings eventuelle Möglichkeiten von REL-Files außerhalb von .d64, wobei ich eher vermute, dass das mit der Ultimate oder dem sd2iec wohl nicht geht - weiß ich jetzt allerdings nicht.
    Guter Punkt. Weiß ich auch nicht. :nixwiss: Im C64-WIki steht nur "eingeschränkte Unterstützung des REL-Dateiformats".

    Chagizzz schrieb:

    Allerdings werden wir etwas OT...
    Ups. Stimmt. :schande: Ich komme mir bei den vielen Posts auch schon vor wie so ein rechthaberischer Besserwisser. Nicht meine Absicht. :/
    Daher zum Abschluß BTT: Nach Betrachtung aller Vorschläge und Kommentare würde ich wohl die Methode empfehlen, die Textdatei in einzelne gleich lange Teildateien aufzuteilen, die dann in einen Cache geladen werden. Das hat den Vorteil, daß es mit Kernel-Load funktioniert und damit auch mit d81 und diversen Schnelladern zusammenarbeitet. Jedoch wäre es vielleicht besser, die jeweilige Dateigröße eher kleiner zu halten, also zwischen 1 und 2 kb, um den Cache möglichst flexibel zu halten. Außerdem dauert dann das Nachladen eines Teilstücks auch ohne Beschleuniger nicht so lange.
    Und auf jedem Fall den Rat von Mac Bacon folgen und die Bereiche sauber trennen. Das vermeidet unter Umständen später ein mühseliges Umschreiben des Programms.
    Aber nun @domspitze: Gutes Gelingen beim Schreiben des Adventures! Vielleicht magst Du später mal im Forum über die Entwicklung berichten..?
  • Chagizzz schrieb:

    Ich meinte hier mit "über die 1541 hinaus" allerdings eventuelle Möglichkeiten von REL-Files außerhalb von .d64, wobei ich eher vermute, dass das mit der Ultimate oder dem sd2iec wohl nicht geht - weiß ich jetzt allerdings nicht.
    sd2iec hat mit REL-Dateien (bevorzugt als R00 im PC64-Format, weil im Header die Record-Länge steht) direkt auf der SD-Karte keine Probleme(*). Innerhalb von Disk-Images wird REL allerdings nicht unterstützt, weil das Format nun mal ziemlich obskur und ungebräuchlich ist und der ganze (Super-)Side-Sector-Verwaltungskram einiges an Implementierungsaufwand bräuchte.

    (*) Selbst das angeblich problematische CBase läuft, wenn man erstmal dessen Dateireihenfolge-Bugs umschifft hat

    Quellcode

    1. 10 x=rnd(-1963):fori=1to81:y=rnd(1):next
    2. 20 forj=1to5:printchr$(rnd(1)*16+70);:next
    3. 30 printint(rnd(1)*328)-217

    sd2iec Homepage
  • M. J. schrieb:

    Guter Punkt. Weiß ich auch nicht. Im C64-WIki steht nur "eingeschränkte Unterstützung des REL-Dateiformats".

    Unseen schrieb:

    sd2iec hat mit REL-Dateien (bevorzugt als R00 im PC64-Format, weil im Header die Record-Länge steht) direkt auf der SD-Karte keine Probleme(*). Innerhalb von Disk-Images wird REL allerdings nicht unterstützt, weil das Format nun mal ziemlich obskur und ungebräuchlich ist und der ganze (Super-)Side-Sector-Verwaltungskram einiges an Implementierungsaufwand bräuchte.

    (*) Selbst das angeblich problematische CBase läuft, wenn man erstmal dessen Dateireihenfolge-Bugs umschifft hat
    Und wie sieht es dann mit der Beschränkung der Größe aus?
    Maximale Nutzdatengröße: 167.132 Bytes auf 1541-Diskette, 182.880 Bytes auf einer doppelseitigen 1571-Diskette, theoretisch bis zu 23.042.880 Bytes beim erweiterten Format.
    Wäre das dann sozusagen ein erweiteretes theoretisches Format mit immerhin 21 MB?
    Na das wäre ja genau das, worauf ich hier hinaus wollte... (wenn ich im Moment auch gar nicht mehr weiß, wie es dazu kam :gruebel )

    M. J. schrieb:

    Vielleicht ist es am besten, Programme so zu gestalten, daß sie neue Hardware erkennen und dann als Special Feature verwenden (so wie die 2Mhz-Beschleunigung beim C128), aber nicht zwingend eine bestimmte Hardware außerhalb des Standards voraussetzen.
    Ist dann aber auch irgendwie fast doppelte Arbeit - also eigentlich zwei Programme. Und ich kann mir vorstellen, dass es deprimierend ist, wenn man die bessere Umsetzung fertig hat und dann die Standardversion noch fertigstellen muss. Aber gut... wirklich anderes Thema.

    M. J. schrieb:

    Aber nun @domspitze: Gutes Gelingen beim Schreiben des Adventures! Vielleicht magst Du später mal im Forum über die Entwicklung berichten..?


    Würde mich auch interessieren...
    carrier lost...
  • Chagizzz schrieb:

    Und wie sieht es dann mit der Beschränkung der Größe aus?
    Maximale Nutzdatengröße: 167.132 Bytes auf 1541-Diskette, 182.880 Bytes auf einer doppelseitigen 1571-Diskette, theoretisch bis zu 23.042.880 Bytes beim erweiterten Format.
    Wäre das dann sozusagen ein erweiteretes theoretisches Format mit immerhin 21 MB?
    Das "erweiterte Format" wurde mit der 1581 eingeführt, weil das alte Dateigrößenlimit von 170 kB ziemlich blöd ist, wenn die Disk 800 kB fassen kann. Die theoretisch möglichen 23.042.880 Bytes lassen sich aber auch auf einem größeren Laufwerk wie SD2IEC in der Praxis gar nicht erreichen, denn vorher greift schon ein anderes Limit:
    Durch die 16-Bit-Datensatznummer und die 8-Bit-Datensatzgröße sind REL-Dateien automatisch auf etwas weniger als 2^24 Byte (16 Megabyte) beschränkt, mehr gibt das Software-Interface einfach nicht her.

    EDIT: Exakt wären es 65535 * 254 = 16.645.890 Bytes.
    Yes, I'm the guy responsible for the ACME cross assembler
  • Mac Bacon schrieb:

    Durch die 16-Bit-Datensatznummer und die 8-Bit-Datensatzgröße sind REL-Dateien automatisch auf etwas weniger als 2^24 Byte (16 Megabyte) beschränkt, mehr gibt das Software-Interface einfach nicht her.

    EDIT: Exakt wären es 65535 * 254 = 16.645.890 Bytes.
    Knapp 16 MB sind natürlich lächerlich :whistling:

    Im Ernst: Ich find das klingt gar nicht übel. Ich glaub' damit werd' ich irgendwann man experimentieren.
    carrier lost...
  • Unseen schrieb:

    Chagizzz schrieb:

    Ich meinte hier mit "über die 1541 hinaus" allerdings eventuelle Möglichkeiten von REL-Files außerhalb von .d64, wobei ich eher vermute, dass das mit der Ultimate oder dem sd2iec wohl nicht geht - weiß ich jetzt allerdings nicht.
    sd2iec hat mit REL-Dateien (bevorzugt als R00 im PC64-Format, weil im Header die Record-Länge steht) direkt auf der SD-Karte keine Probleme(*). Innerhalb von Disk-Images wird REL allerdings nicht unterstützt, weil das Format nun mal ziemlich obskur und ungebräuchlich ist und der ganze (Super-)Side-Sector-Verwaltungskram einiges an Implementierungsaufwand bräuchte.
    (*) Selbst das angeblich problematische CBase läuft, wenn man erstmal dessen Dateireihenfolge-Bugs umschifft hat
    Ich finde es schade, dass SD2IEC die Nutzung von REL-Dateien in Images nicht unterstützt.

    Liebe Grüße!
    ThomBraxton

    DoReCo #53 am Sa. 17.06.2017