Action! Speicher reservieren zB für Charset oder PM

[FlorianD]

Hallo,

wer weiss eine gute Methode, in Action! Speicher zu reservieren z.B. für die Verwendung von Zeichensätzen oder PM-Grafikdaten (die ja immer an ganzen Page oder 4-Page Grenzen liegen müssen).

Ich mache das meist so:

Code: Alles auswählen

SET $0E=$5000
SET $491=$5000 ; damit faengt das Programm bei $5000 an

BYTE CHSET=[
INCLUDE "D:FONTDATA.RAW" ; die Daten muessen ATASCII Daten sein, kein Binary!
]


oder so:

Code: Alles auswählen

SET $0E=$5000 ; APPMHI
SET $491=$5000 ; CODEBASE;  damit faengt das Programm bei $5000 an

SET $0E=$5400 ; damit faengt der eigentlich Programmcode bei $5400 an, zwischen $5000 und $5400 sind dann 4 Pages frei
; KEIN SET $491=$5400 - $491 ist CODEBASE, dort, wo der Code beginnt und von wo aus der Befehl "W" im Monitor das Speichern beginnt


Geht das noch besser?

Was scheinbar nicht geht, ist das hier

Code: Alles auswählen

SET $0E=$5000
SET $491=$5000 ; damit faengt das Programm bei $5000 an

BYTE ARRAY CHSET(1024)


das funzt irgendwie nicht, scheinbar legt Action! die Variablen sonstwohin (Edit: dimensionierte Arrays liegen HINTER dem Programmcode, wie im Runtime Package Handbuch beschrieben wird: "Since arrays (other than small BYTE arrays) are allocated semi-dynamically after the end of your program (and may thus occupy the symbol table's space, for example), they do not affect the size of your compiled code.")

[GoodByteXL]

Im Action! Tool Kit ist dafür der Satz an Routinen in ALLOCATE vorgesehen. allerdings erfolgt damit eine dynamische Speicherzuweisung. Ggf. kann man die so einrichten, dass man sie für deinen Zweck nutzen kann.

[GoodByteXL]

Im Action! Tool Kit ist dafür der Satz an Routinen in ALLOCATE vorgesehen. allerdings erfolgt damit eine dynamische Speicherzuweisung. Ggf. kann man die so einrichten, dass man sie für deinen Zweck nutzen kann.

Nachtrag:

Eine Idee dazu wäre das Checken alter Listings in A.N.A.L.O.G. und ANTIC.

Z. B. das Character Set Display Utility in A.N.A.L.O.G. #74 sieht dafür interessant aus.

[mp-one]

Siehe dazu z. B. auch hier: https://atariwiki.org/wiki/Wiki.jsp?page=Load%20Font%20Files%20in%20ACTION

[FlorianD]

Hallo,

danke für die Hinweise, aber das ist nicht das, was ich suche.
Ich will das weder dynamisch allozieren (mit der POKE 106,PEEK(106)-Anz_Pages Methode), noch will ich irgendetwas (Fonts) nachladen - ich will nur 1 Datei, wo alles gleich an der richtigen Stelle drin ist.

[GoodByteXL]

Hallo,

danke für die Hinweise, aber das ist nicht das, was ich suche.
Ich will das weder dynamisch allozieren (mit der POKE 106,PEEK(106)-Anz_Pages Methode), noch will ich irgendetwas (Fonts) nachladen - ich will nur 1 Datei, wo alles gleich an der richtigen Stelle drin ist.

Aber mit dem Herabsetzen der Speicherobergrenze schaffst du doch freien Raum ...
Alternativ bleibt noch Page 6 (falls nicht zu klein) oder Extended Memory per Page Flipping.
Dann gibt es noch Möglichkeiten, ein Image des Hauptspeichers abzulegen und einfach neu einzuladen.

Vielleicht würde es helfen, zu erläutern was genau du vorhast.

[FlorianD]

was ich vermeiden will ist, irgendwo im Programmcode "Data"-Zeilen mit Fontdaten zu haben, die ich dann zur Laufzeit auf Pages kopiere am Ende des Speichers. Bei 4 Zeichensätzen a 1K sind das dann 8K, die benötigt werden. Also 4K verschwendet. Warum nicht gleich direkt irgendwo ablegen und dort nutzen. Das setzt aber voraus, dass die genau an einer Page-Grenze beginnen. Und meine Frage ist, wie man das am besten hinkriegt.
Nachladen fällt aus, ich will am Ende alles in einer Binärdatei haben.

[FlorianD]

die oben von mir beschriebene Methode ist im Übrigen -wie ich mittlerweile herausfand- genau so auch im Action! Run Time Package beschrieben.
Siehe hier: https://atariwiki.org/wiki/Wiki.jsp?pag ... %20Package

und hier in neuem Layout
https://atariwiki.org/wiki/attach/The%2 ... 0GUIDE.pdf

dort unter "4.1 Directing the Code Storage Address"

[GoodByteXL]

die oben von mir beschriebene Methode ist im Übrigen -wie ich mittlerweile herausfand- genau so auch im Action! Run Time Package beschrieben.
Siehe hier: https://atariwiki.org/wiki/Wiki.jsp?pag ... %20Toolkit

und hier in neuem Layout
https://atariwiki.org/wiki/attach/The%2 ... 0GUIDE.pdf

Ähm, du verweist einmal auf das Toolkit und einmal auf das Run Time Package ...
Zeigst aber nicht was genau du meinst.

Abgesehen davon ist dies das besser lesbare Layout,

Bildschirmfoto vom 2020-03-23 07-23-43.png

(394.91 KiB) Noch nie heruntergeladen

da man in der linken Spalte das Inhaltsverzeichnis neben dem Buch digital nutzen kann.

Es enthält alle Teile zu Action! in einem engl. Manual.

Und, Action! in einem Handbuch gibt es auch in deutscher Fassung.

Daneben sind am Ende der deutschen Fassung jede Menge Quellen in der Anlage L aufgeführt.

[FlorianD]

serifenlose, monospaced Schrift im Blocksatz ... ganz toll zu lesen.
Alles ein Brei, keinerlei Auszeichnungen im Text. Speicheradresse, Code, alles nicht unterscheidbar.

Und das Inhaltsverzeichnis ist immer der wichtigste Teil eines Buches, denn da stehen die meisten Details und der ganze Text drin. /Ironie off.

[CharlieChaplin]

Hmmmm,

wie immer vorweg, ich kann nicht programmieren und weiß nicht ob dir dieser Tip irgendwie weiterhilft. Du willst u.a. mehrere/versch. Daten eines Programmes am Ende als ein Binärfile bzw. COMfile haben (sog. single-file Version) ?

Also, es gibt da neben Packern auch Packer & Linker, z.B. Superpacker für den A8 von Bewesoft oder Superpacker für den PC von TeBe (oder Packer & Linker für den A8 von T.Karwoth). Du kannst damit auch mehrere Daten miteinander verlinken, z.B. lädst du Bild(er) oder Font(s) mit "load Data" ein und setzt sie an eine best. Stelle im Speicher, z.B. $5000. Dein Assembler oder Action Programm muss dann natürlich irgendwo anstelle von Open"D:Filename.Pic" oder Open"D:Filename.Fnt" einen Sprungbefehl nach $5000 beinhalten, an dem deine Daten (Bild oder Font) dank Linker nunmehr stehen.

Auf diese Weise kannst du mehrere Datensegmente aneinander fügen (verlinken) und ggf. mittels Init initialisieren. Am Ende erhälst du dann eine COMpound-Datei, die aus mehreren Datensegmenten besteht und sich ggf. noch packen lässt. Sofern nicht jedes Datensegment mit Init aufgerufen wird ($5000-53FF, Init 5000; 5400-57FF, Init 5400, etc.), kannst du die Datensegmente mittels append zu einem langen Datensegment zusammenfügen (Leerstellen werden dann mit Nullen gefüllt) und dann noch besser packen.

Zum Packer & Linker von T.Karwoth gab es eine genauere Anleitung dazu, wie man sowas macht. Soweit ich mich erinnere war der Packer und Linker beim Macro-Assembler XE (Version 4.32 oder Version 2.1/2.2) von T. Karwoth dabei (ebenso die Anleitung), also mal in der Abbuc PD-Bibliothek danach schauen: PD 297 und PD 368.

EDIT: Anleitung gefunden auf 0368_B.ATR unter dem Namen PLINK.DOC: "Wenn man ein eigenes Programm geschrieben hat..." (MyDOS-Diskette; Textformat ASCII, Startexter, sonstiges?)

Anleitung zum Packer & Linker

Paklink.jpg (28.78 KiB) 1071-mal betrachtet

Wie du jetzt Speicher in deinem Action Programm für Fonts, PMs oder Bilder reservierst, weiß ich leider nicht... leg doch ein Handtuch hin...

[GoodByteXL]

serifenlose, monospaced Schrift im Blocksatz ... ganz toll zu lesen.
Alles ein Brei, keinerlei Auszeichnungen im Text. Speicheradresse, Code, alles nicht unterscheidbar.

Das trifft nur auf die engl. Version zu, da diese weitestgehend seiten- und oft sogar zeilengleich digitalisiert wurde und dem Layout des Originals folgt. Das erleichtert die Überprüfung, ob denn alle Hinweise wie z. B. die aus den Newslettern oder Bug Sheets schon eingearbeitet sind. Findet sich etwas, kann man schnell sehen, ob es eingefügt werden müsste. Hinweise dazu nehme ich immer gerne an.

Auf die deutsche Ausgabe trifft deine Aussage nicht zu; ist schlicht verkehrt.

Und das Inhaltsverzeichnis ist immer der wichtigste Teil eines Buches, denn da stehen die meisten Details und der ganze Text drin. /Ironie off.

So ist es. Denn wenn man nach Inhalten in einem Buch sucht, erst Klappentext, dann Inhaltsverzeichnis, ggf. Stichwortverzeichnis checken. Aber lesen ist sowieso eine aussterbende Kulturtechnik ...

Daneben sind PDF, die aus Scans per OCR ein 'durchsuchbares Dokument' erstellen, oft sehr fehlerbehaftet, wie ich aus leidvoller Erfahrung weiß. Wenn dann noch die Scans selbst schlecht sind ...

Die beiden von mir verlinkten Handbücher (wie einige andere auch) wurden komplett mit Open Office neu gesetzt und dann als PDF exportiert. Daher kann man darin parallel sowohl im Inhaltsverzeichnis als auch im Text schnell per digitaler Suche arbeiten. Dazu ist das Inhaltsverzeichnis über alle Ebenen so auf- und zuklappbar, wie man es gerade braucht für die Themen, mit denen man sich beim Programmieren befasst. ein Klick und man ist dort, ohne das Inhaltsverzeichnis verlassen zu müssen.

Aber abgesehen davon,

es wäre nett, wenn du deine Hinweise zur Lösung konkretisieren könntest für diejenigen Forenleser, die sich mit Action! befassen.

[FlorianD]

bevor Du hier sowas von Dir gibst

Aber lesen ist sowieso eine aussterbende Kulturtechnik ...

hättest Du ja mal GENAU lesen können, was ich seit Post #1 will. Aber das scheint bei aller "Lesekompetenz" deinerseits nicht durchgedrungen zu sein - obwohl ich es drei Mal erklärt habe.

Und hättest Du meinen letzten Post GENAU gelesen und verstanden, wäre Dir aufgegangen, und ich wiederhole mich hier für Dich nochmal gerne, dass die von mir in Post #1 beschriebene Methode auch die ist, die in den von mir referenzierten Dokumenten empfohlen wird - und das Thema somit geklärt ist.

die oben von mir beschriebene Methode ist im Übrigen -wie ich mittlerweile herausfand- genau so auch im Action! Run Time Package beschrieben.
Siehe hier: https://atariwiki.org/wiki/Wiki.jsp?pag ... %20Package

und hier in neuem Layout
https://atariwiki.org/wiki/attach/The%2 ... 0GUIDE.pdf

dort unter "4.1 Directing the Code Storage Address"

[FlorianD]

Wie du jetzt Speicher in deinem Action Programm für Fonts, PMs oder Bilder reservierst, weiß ich leider nicht... leg doch ein Handtuch hin...

das hatte ich noch nicht probiert... mal gucken ob das geht!

Zu den erwähnten Packern: guter Tipp im Allgemeinen, wußte nicht, dass es solche Utils gibt. Für meinen Zweck aber arg umständlich während der Entwicklung. Compilieren, linken, speichern, Starten würde je Durchgang ewig dauern. Aber um z.B. einen Ladebildschirm/Intro anzufügen, genau die richtige Lösung.