Moinsen,

ich habe hier mehrere Binärdateien, die ich gerne zusammenfügen möchte. Wenn man sich mein Screenshot anschaut, dann erkennt man, dass beginnend bei Adresse $1F00 der Speicherbereich durchgehend bis auf ein paar Lücken bis einschließlich $3F65 belegt ist. Ich würde gerne den kompletten Datenbereich als ein Segment zusammenfassen. Kann ich das mit dem Super Packer von Jiri Bernasek machen? Im Moment ist mir noch nicht klar, ob die Software die Funktion überhaupt unterstützt.



Viele Grüße
Klaus

ich denke nicht, dass das geht... besser ist es direkt im Emulator dann diesen Block zu speichern...

Superpacker gibt es auch für Windows btw.

http://madteam.atari8.info

Klare Antwort: Jein !

Mit dem A8 Superpacker von Bewesoft klappt es nicht, jedoch geht es problemlos mit dem PC Superpacker von TeBe (=> Funktion Append).

Du hast aber Glück, deine Daten-Segmente sind größtenteils "contiguous" also kontinuierlich, daher kannst du sie mit dem A8 Programm Streamliner von S.Hague zu deutlich weniger Segmenten zusammenfügen.

Moin Klaus,

kfischer hat geschrieben:ich habe hier mehrere Binärdateien, die ich gerne zusammenfügen möchte. Wenn man sich mein Screenshot anschaut, dann erkennt man, dass beginnend bei Adresse $1F00 der Speicherbereich durchgehend bis auf ein paar Lücken bis einschließlich $3F65 belegt ist. Ich würde gerne den kompletten Datenbereich als ein Segment zusammenfassen. Kann ich das mit dem Super Packer von Jiri Bernasek machen? Im Moment ist mir noch nicht klar, ob die Software die Funktion überhaupt unterstützt.

Ich kann es jetzt hier nicht ausprobieren, aber das sollte mit dem XDOS leicht möglich sein (vermutlich auch mit anderen DOS-Versionen). Kaltstart, XDOS booten und die gewünschten(n) Datei(en) mit "LOA <filename>" einladen, dann werden sie nicht gestartet. Evtl. muß noch ein Parameter angegeben werden, schaue einfach in die XDOS-Doku.

Zum Schluß kann man das ganze mit "SAV" abspeichern, siehe Doku.

Gruß, Jürgen

Hallo Klaus

Probier doch mal in (My)DOS:

(In kurzform!! Die Details sollte man sich selber einfallen lassen)

- "C" mit "/A" am Ende. Dies hängt eine Datei an die Erste ("Append"). Eventuell benutzt man Wildcards ("*" oder "?"). Oder,
- "L" mit "/N" am Ende. Die Datei(en) werden dann geladen, aber nicht ausgeführt. Auch hier kannst Du Wildcards benutzen. Oder,
- "N", wie "L" aber jetzt wird zuerst MEM.SAV erstellt.

Tschüß

Mathy

Moin,

danke für die vielen Tipps! Ich habe mal Jürgens Vorschlag unter XDOS probiert:

LOA TEST.OBJ
SAV TEST.OBJ 1F00 3F65

Siehe da es hat geklappt ... der komplette Datenbereich wurde in nur ein Segment zusammengefasst. Im Super Packer noch die RUN-Adresse eingeben, abspeichern, fertig



Wieder was dazu gelernt und sicher wird es auf dieser Art und Weise mit jedem anderen DOS auch funktionieren.

Nochmals vielen Dank

Klaus

P.S.: Nebenbei bemerkt, man kann sich unter XDOS mit dem externen MAP-Befehl auch die Segmente anschauen. Sehr praktisch!

Hi Mathy,

da ich MyDOS auch gerne mag, habe ich das jetzt auch mal darüber probiert. Klappt genauso gut wie mit XDOS:

L (Load Memory)
D1:TEST.OBJ/N

K (Save Memory)
D1:TEST.OBJ,1F00,3F65,,1F00

Die Init-Adresse habe ich ausgelassen, aber die Run-Adresse (letzter Parameter) gleich mit eingegeben.
Ich denke, da benötige ich erstmal keine zusätzliche Software.

Gruß
Klaus

P.S.: Hast ne schöne MyDOS-Page, nur DCM-Files nochmal geARCt, finde ich bisschen unpraktisch

Hallo Klaus

Als ich die Seite zusammengestellt habe vor (grob geschätzt) 10 Jahren war Platzsparen noch angesagt. Und ich hatte noch keinen großen Rechner damals. ATR's erstellen konnte man auch am Atari machen, aber nicht so schnell wie heute am Mac (oder diesen anderen Rechner, dessen Namen ich ab und zu absichtlich vergesse). SIO2irgendwas waren seltsam. Deswegen DCM. Wieso dann noch ARC? Keine Ahnung, zu lange her. Aber jetzt noch mal alles umändern? Vorläufig nicht.

Tschüß

Mathy

Moinsen,

kleiner Nachtrag ... leider ist das Programm nicht mehr lauffähig, nach dem es mit MyDOS in den Speicher geladen und wieder auf Disk zurückgespeichert wurde. Offenbar ist das DUP zu groß

Das Beispiel mit XDOS läuft aber.

Gruß
Klaus

Hi,

die Sache hat bislang einen Schönheitsfehler:

Wenn eine Programmdatei mit so vielen Blöcken in den Speicher geladen wird .... was steht dann dort im Speicher, wohin das Programm nichts geladen hat?

Genau, da steht das, was vorher drin stand.

Ich bereinige den Speicher immer, wenn ich so etwas mache. Entweder aus dem Freezer raus den RAM Bereich nullen, in dem die ganzen Winzig-Blöcke liegen, mit dem Monitor des A800Win oder mit einem kleinen ML Programm in z.B. Page 6.

Der Vorteil hiervon ist, daß man nicht plötzlich Müll in einer Grafik, einem Player oder einem Musikstück hat. Nicht alle Programme initialisieren den Speicher, den sie benutzen. Sie gehen unter Umständen davon aus, daß der Anfangswert Null ist.

CU, Erhard

Nun,

es war einmal... vor vielen Jahren, als es noch keine "richtigen" Packer auf dem A8 gab, da wurden Tools geschrieben, die Programme kürzer machen konnten, indem sie einfach die Nullen aus den Programmen entfernten (sog. Bit/Byte Cruncher, wie z.B. The Cruncher von O.Hausiek, The File-Compactor von S.Baucke, etc.). Die Programme wurden dadurch um einiges kürzer, jedoch a) konnten sie zumeist nur noch via Gamedos geladen werden und b) bestanden sie nunmehr aus dutzenden oder gar hunderten Segmenten. Wie es scheint benutzt Homesoft einen solchen Bit-Cruncher, denn die meisten seiner Programme bestehen aus endlos vielen Segmenten. Auffällig ist, dass diese Segmente jedoch nie nahtlos ineinander übergehen, sondern immer einige Lücken (die entfernten Nullen!) aufweisen.

Daneben gibt es A8 Assembler und auch Basic-Compiler (ABC, MMG), die beim Erstellen des COM/OBJ Files dutzende Segmente anfertigen, die nahtlos aneinander anschließen, so wie beim obigen Beispiel von Klaus. Hier kann man sich problemlos mit dem A8 Programm Streamliner behelfen und aus den div. Segmenten ein einziges Segment machen. Bei den übrigen Programmen, die mittels Bit-Cruncher gekürzt wurden, kann man den Superpacker von TeBe (PC-Programm) oder Ataricom von HiasSoft (ebenfalls PC-Programm) oder ähnliche Programme einsetzen. Diese setzen an allen Lücken einfach wieder Nullen ein und kehren somit quasi den vorangegangenen Prozess des Bit-Crunchers um. Das geht sicherer und auch wesentlich schneller und besser, als solche Programme unter A8 DOS neu abzusaven (mittels binary save), da beim A8 DOS nicht unbedingt Nullen erzeugt werden (sondern wie erwähnt, das gesaved wird, was gerade im Speicher ist) und es natürlich nicht möglich ist Programme zu laden und neu zu saven, die das A8 DOS überschreiben (z.B. $1000-3FFF)...

Weitere Infos findet man auch im atari-age A8 Forum unter dem Topic "de-segment MAC 65 OBJ files", dort gibt es auch diverse passende Software zum Download (sogar für SpartaDOS oder SDX).

Info zu Streamliner: http://gury.atari8.info/details_source_code/1192.php
oder hier: http://www.mathyvannisselroy.nl/blackbox.htm
(Download am Ende der Info zum Black Box Floppy-Board)
Info zu Ataricom: http://www.horus.com/~hias/atari/#tools-win32
Info zu Superpacker (PC): http://madteam.atari8.info/index.php?prod=uzytki

Moin,

Erhard hat geschrieben:die Sache hat bislang einen Schönheitsfehler:

Wenn eine Programmdatei mit so vielen Blöcken in den Speicher geladen wird .... was steht dann dort im Speicher, wohin das Programm nichts geladen hat?

Das dürfte aber selten zum Tragen kommen. Die wenigsten Programme (erst recht Spiele und Demos) erlauben keine saubere Rückkehr ins DOS, d.h. man muß sowieso einen Kaltstart durchführen. Das Atari Betriebssystem löschen den Speicher mit Nullen beim Kaltstart, so daß im Normalfall eine definierte Grundbedingungen (=Speicher genullt) vorliegt.

Gruß, Jürgen

Hi Jürgen,

tfhh hat geschrieben:Das dürfte aber selten zum Tragen kommen.

Du bist an der falschen Stelle.

Es geht nicht um das Laden eines Multiblock-Programms auf einem frisch gebooteten Rechner.

Es geht um das Ent-Multiblocken auf einem NICHT frisch gestarteten Rechner: Man lädt ein DOS, benutz ein externes COPY Programm, erstellt mit MAKEATR ein ATR auf APE oder dem SIO2USB, schaltet BASIC ein, macht was an seinem BASIC Programm, wo man schon immer mal Zeile 2 Tippen wollte, schaltet BASIC wieder aus und genau jetzt fällt einem ein, daß man das eine megacoole Game, was durch die Multiblock-Technik nur halb so groß ist wie ohne aber dafür doppelt so lange lädt schon immer mal Ent-Multiblocken wollte.

Durch die Vorarbeiten am Rechner steht im Speicher von sagen wir $1F00 bis $BC1F irgendwelcher Schrott. Jetzt lade ich das 2-teilige Multiblock-Programm X.COM mit LOA X.COM in den Speicher und es lädt sich nach $2000 - $21FF und $2280 - $2FFF. Dann speichere ich es mit SAV X.COM 2000 2FFF ab.

Somit habe ich den Schrott, der vorher in $2200 - $227F stand, nun mit in X.COM.

Das megacoole X.COM erstellt einen Player, legt den auf $2200 und kopiert die 20 Byte großen Playerdaten nach $2220 - $2213.

Wie sieht der Player dann wohl aus?

Natürlich hat Charlie recht, daß man für richtige große Programme unter einem DOS gar nicht genug freien Speicher hat, um so vorzugehen. Aber eine ganze Reihe kleinerer Progrämmchen hab ich genau so beackert:

Eben in den Superpacker von BeWe-Soft geladen, damit der Adressbereich und die RUN-Adresse klar sind, mit dem Freezer eben den Speicher genullt, unter DOS einmal eben LOA und SAV, dann das Teil noch mal in den Superpacker von Bewe-Soft geladen, die RUN-Adresse drangehängt und wieder abgespeichert.

Warum so? Weil ich Atari-Sachen gerne auf dem Atari mache und weil ich den PC-Superpacker bis gerade gar nicht kannte.

CU, Erhard