Editor für Relative Dateien

Zitat von Chagizzz

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.)

Zitat von Chagizzz

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. )

Zitat von domspitze

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.

Zitat von Mac Bacon

...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.

Zitat von Mac Bacon

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.

Zitat von Mac Bacon

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.

Zitat von Mac Bacon

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.

Zitat von Mac Bacon

man kann die Blockbelegung komplett dem DOS überlassen

Wozu braucht man eine Blockbelegung, wenn man das DOS ohnehin umgeht?

Zitat von Mac Bacon

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.

Zitat von Mac Bacon

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.

Zitat von Mac Bacon

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. 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ß.

Zitat von Chagizzz

Um die Daten nicht versehentlich zu überschreiben.

Dazu müßt aber auch irgendwer auf genau diese Diskette schreiben wollen.

Zitat von Chagizzz

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.

Zitat von Chagizzz

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.

Zitat von Chagizzz

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. Im C64-WIki steht nur "eingeschränkte Unterstützung des REL-Dateiformats".

Zitat von Chagizzz

Allerdings werden wir etwas OT...

Ups. Stimmt. 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..?