Hallo Besucher, der Thread wurde 2,7k mal aufgerufen und enthält 14 Antworten

letzter Beitrag von GI-Joe am

ACME - externes Programm beim Assemblieren aufrufen

    Moin,


    gibt es bei ACME eigentlich die Möglichkeit, während des Assemblierens Selbiges zu pausieren und ein externes Programm aufzurufen und nach dessen Beenden geht das Assemblieren denn weiter ?


    Ich denke z.B. an den Aufruf eines Packers, der den aktuellen PC oder ne Label-Adresse mit übergeben bekommt.
    Wenn der Packer fertig ist, ist danach die gepackte Filelänge bekannt womit wiederum der Assembliervorgang weiter arbeiten könnte.


    Sowas würde beim Batch-assemblieren von bestimmten Sachen sehr hilfreich sein ^^

    Makefiles sind Dein Freund. :)


    Während des Assembliervorgangs will man eigentlich keine externen Programme aufrufen, denn das würde ja dann einmal pro Pass passieren.
    Und Du willst wirklich keinen Assembler haben, der beliebige Strings aus dem Sourcecode an den Befehlsinterpreter des lokalen Systems weiterreicht - sonst verteilt sofort ein Spaßvogel Sourcecodes, die beim Assemblieren Deine Festplatte löschen. :bgdev


    Beschreib mal, was Du gerade vorhast, das kann man sicher anders lösen.

    Zitat von Mac Bacon

    sonst verteilt sofort ein Spaßvogel Sourcecodes, die beim Assemblieren Deine Festplatte löschen. :bgdev

    Dazu müßte acme auf meinem System unter Admin-Rechten laufen - tut es aber nicht :P


    Zitat von Mac Bacon

    Beschreib mal, was Du gerade vorhast, das kann man sicher anders lösen.

    Hier mein Beispiel:


    ich möchte 3 (oder mehrere) Programme, von denen Art und Größe noch nicht feststehen, auf ein EPROM brennen.
    Dazu programmiere ich mir einen CBM80 - Header mit einem kleinen Menü.
    Dieser Header soll universell sein (ich möchte nicht jedes mal den code ändern müssen, wenn ich andere files nehme)


    Hinter diesem Header kommt das 1. file mit einer länge, die mal so und mal so sein kann. Das file möchte ich aber nochmal durch den exomizer prügeln, um EPROM-Speicherplatz zu sparen.
    Nun muß mein Acme bzw. mein Menü-Code ja wissen, wo im EPROM file 1 endet und file 2 beginnt u.s.w.
    Ich hab das bisher immer mit Labels gemacht, so z.B.


    Ich muß also händisch die Files alle vorbereiten (packen, renamen ....) - funzt auch alles soweit.


    Ich will den shit nun ein bißchen automatisieren, indem ich per batchfile mir von acme den Header-Code machen lasse, dann per

    Code
    1. copy /B header + /B file1.prg + /B file2.prg + /B file3.prg Modulfile.bin

    den ganzen Kram zusammenfüge. Das Problem an der Variante ist, daß die files zwar schön zusammengefügt werden, aber der generierte Header-Code nix von den Anfangs/Endadressen weiß.
    Auch die Anzahl der Files ist variabel, so daß ich jedes mal den Header-Code ändern müßte, wenn ich bei meiner bisherigen Variante (siehe oben) bleiben würde. Über ein for im Batch/shell-script wäre das Handling beliebig vieler Files möglich - geht sowas in acme auch (über spezielle Kommandos) ?


    PS: vergebt mir meine komischen Fragen - ich bin doch Löter und kein Coder ;)

    Nur so als Schnellschuss (es ist schon spät...):

    Nun starte ACME mit dem temporären File. Dein Headercode kann nun auf das Label "FILE_COUNT" zugreifen, welches die Anzahl der Dateien enthält, und findet dann in den Tabellen STARTADRESSEN und ENDADRESSEN die Informationen über die gepackten Files (die direkt hinter der Endadressen-Tabelle abgelegt sind).

    Makefiles sind niemandes Freund :)


    Aber Mac Bacon hat recht, der "Trick" ist das Aufteilen in mehrere Einzelschritte. Wenn man das mal irgendwo wegscriptet ist das dann auch mit einem Aufruf getan. Die Computer sind ja dazu da, Arbeit zu machen, die man ohne nicht hätte.

    Zitat von Endurion

    Makefiles sind niemandes Freund :)

    Danke ! Endlich mal einer der auf meiner Seite ist :whistling:


    Zitat von Endurion

    Wenn man das mal irgendwo wegscriptet ist das dann auch mit einem Aufruf getan. Die Computer sind ja dazu da, Arbeit zu machen, die man ohne nicht hätte.

    Und genau DAS war für mich der Grund, warum ich diesen Thread eröffnet habe ;)



    Zitat von Mac Bacon

    (Batchfiles? Sowas gibts noch?),

    Ja, unter Windows. Ich mach ja eher lieber mit bash/sh rum, aber ich hatte noch keine Zeit/Lust, mein ganzen acme/Vice - Kram vernünftig in Linux einzubaun :S (Vice unter Linux ist leider eher bescheiden, wenn man an drag&drop und sofort funzenden Sound gewohnt ist).



    Vielen Dank, Leute !
    Ich werde in einer ruhigen (Weihnachts-)Stunde mal in mich gehen und versuchen, sowas zu basteln.
    Im Moment lieg ich hier leider noch mit Grippe flach :sleeping:

    Zitat von Endurion

    Wenn du was Bash-Ähnliches haben möchtest, kann ich dir Powershell wärmstens ans Herz legen. Sehr sehr mächtig.

    Davon hab ich auch schon gehört. Ist gut gemeint von Dir aber meine Windows-Zeiten liegen auf dem absterbenen Ast.


    Bash & sh sind auch sehr mächtig und sogut wie überall mit drin. Die machen in meinen Augen mehr Spaß und das Wissen kann man überall anwenden (von der Fritzbox bis zum Rechenzentrum). Da mit steigendem Alter das Lernen erwiesenermaßen immer schwieriger wird, sammle ich lieber Erfahrungen mit den Sachen, die die längste Überlebenschance und den breitesten Nutzen für mich bringen.


    ..... schrieb der, der sich demnächst ein Batch-Script für ACME schreiben will .... :whistling:


    ... aber mal sehn, vielleicht wirds ja doch ein shell-script ;)

    Zitat von Mac Bacon

    Nun starte ACME mit dem temporären File. Dein Headercode kann nun auf das Label "FILE_COUNT" zugreifen, welches die Anzahl der Dateien enthält, und findet dann in den Tabellen STARTADRESSEN und ENDADRESSEN die Informationen über die gepackten Files (die direkt hinter der Endadressen-Tabelle abgelegt sind).

    Klingt logisch, nur hab ich ein paar Schwierigkeiten beim Umsetzen.


    Es sollen nämlich auch gleich noch nur soviel Menü-Einträge mit erzeugt werden - abhängig davon, wie viele files es gibt. Und hier stockt es schonmal bei mir :evil:
    Wie kann ich den Zähler aus der !for-schleife benutzen ? Is vermutlich nur n Sytax-Fehler oder so - naja, bin halt kein ProfiCoder ...
    Ein kläglicher und fehlerhafter Versuch sieht bei mir im Moment so aus:

    Das geht so nicht, da ACME keine Arrays kennt. Aber auch wenn ich Arrays hinzufüge, wird man damit keine festen Labelnamen referenzieren können ("TX(1)" oder "TX[1]" ist was anderes als "TX1").


    Um das Problem zu lösen, müsste man von dem Shellskript zusätzliche Tabellen generieren lassen, z.B. "filename_adresses" (mit Word-Einträgen) und "filename_lengths" (mit Byte-Einträgen), die dann die Anfangsadressen der Dateinamen und deren Länge enthalten. Der Menücode benutzt dann eine Zählvariable, die bis FILE_COUNT zählt und die Dateinamen ausgibt.
    Oder kurz gesagt: Anstatt Extra-Code für jeden Eintrag zu erzeugen, schreib allgemeinen Code, der auf Tabellen zugreift.


    Wo kommt eigentlich die 14 her? Wenn man ein Generatorskript benutzt, fallen solche Limits eigentlich weg.


    Ach ja, und "!ifdef" sollte man nur benutzen, wenn man genau weiß, was man da tut. ;)

    Zitat von Mac Bacon

    Das geht so nicht, da ACME keine Arrays kennt. Aber auch wenn ich Arrays hinzufüge, wird man damit keine festen Labelnamen referenzieren können ("TX(1)" oder "TX[1]" ist was anderes als "TX1").

    Danke, dann brauche ich hier also nicht weiter grübeln :dafuer:

    Zitat von Mac Bacon

    Oder kurz gesagt: Anstatt Extra-Code für jeden Eintrag zu erzeugen, schreib allgemeinen Code, der auf Tabellen zugreift.

    Mache ich dann mal, vielleicht vorher nochmal Gedanken oder ein Flußdiagramm machen, dann muß man nicht soviel Code umkrempeln während des Codens :whistling:


    Zitat von Mac Bacon

    Ach ja, und "!ifdef" sollte man nur benutzen, wenn man genau weiß, was man da tut. ;)

    Ja, steht auch so im Manual :). Überaschenderweise funzte "!ifdef", als ich mal probehalber mit echten Labels (ohne den !for-kram) getestet habe. Egal, zuviel !for und !if .... macht den Code eh unübersichtlich (wenn man so wie ich Disassemblierungen aus einem AR-Monitor gewohnt is ^^ ). Also lass ich´s lieber ...

    Zitat von Mac Bacon

    Wo kommt eigentlich die 14 her? Wenn man ein Generatorskript benutzt, fallen solche Limits eigentlich weg.

    Mehr Einträge passen nicht auf meinen C64 - Screen (ohne daß es hässlich wirkt ;) ) Außerdem hab ich max. ein 64kb EPROM, da reichen 14 Files auch aus (macht durchschnittlich je file 18 Blocks, viel gescheites an PRG´s gibts darunter eh nich ;) ).


    Da komm ich zum nächsten Problem:
    wenn ich *=8000 mache kann ich nur ein max. 32kb großes file erzeugen (logischerweise). Da ich mein EPROM ja über Bankswitching anspreche, reicht das nicht immer aus, mit "!bin" die files einzubinden.


    Ich muß es also so machen, daß ich aus dem asm-sourcecode einen EPROM-Header generiere, der alle Infos über
    Menüeintrag-Name, Adresse des Menüeintrag-Namens,
    Anfangadresse/Länge/Startbank jedes Files im EPROM,
    Anzahl der Files/Menüeinträge,
    enthalten muß.
    Danach muß mein ShellScript den fertigen BIN-Header mit den NutzFiles zusammen-cat´en und auf EPROM-Größe alignen/auffüllen mit $FF-bytes.


    Ich glaube, mindestens 50% meines Hirnschmalzes werd ich wohl in das Shellscript stecken müssen, um die ganzen passenden Parameter für den ASM-Sourcecode richtig aufzubereiten und dort an der richtigen stelle zu injecten bevor der Header-Code dann assembliert wird.
    Ich wollte mir aber erstmal ein asm-Gerüst bauen, damit ich weiß, welche Daten und in welcher Reihenfolge das Shell-Script in den Sourecode liefern muß.
    Ein paar Schritte hast Du mit per "schnellschusss" ja schon geliefert, das hat mich schon ein bißchen zum Denken angeregt :gruebel


    Übrigens hab ich mir schonmal ein kleines Exomizer-Script geschrieben, um Platz auf dem EPROM zu sparen - funzt prima, mal eben z.B. 500 prg´s in einem Rutsch mit Größencheck zu exomizen :).
    Der Code wird wohl auch da mit rein kommen ....


    Hier nur mal die kleine Beschreibung - das Script hängt mit dran - für die, die es interessiert ...


    PS:
    perfekt wäre sowas wie dtvmkfs, um aber sowas zu machen muß man echt ProfiCoder sein.
    Und NEIN, ich werde dieses Projekt nicht in C, Java oder Python oder sonstwas machen, obwohl es für viele vielleicht einfacher wäre.
    Ich kann nur sh/bash und C64asm, und da bin ich auch nur ne 3-4 (wenn man von Schulnoten ausgeht). Leider lässt sich sowas nicht löten, sonst hätte ich es schon fertig :D

    Zitat von GI-Joe

    Außerdem hab ich max. ein 64kb EPROM [...]
    Da komm ich zum nächsten Problem:
    wenn ich *=8000 mache kann ich nur ein max. 32kb großes file erzeugen (logischerweise). Da ich mein EPROM ja über Bankswitching anspreche, reicht das nicht immer aus, mit "!bin" die files einzubinden.

    Du kannst auch 64 KiB in einem Rutsch erzeugen:

    Code
    1. * = 0 ; start at beginning of output buffer
    2. ; but act as if at $8000:
    3. !pseudopc $8000 {
    4. [...hier jetzt den Code einfügen]
    5. }

    Das nur der Vollständigkeit halber, denn es hilft Dir nicht unbedingt weiter: denn Du musst ja trotzdem das Modulbanking beachten: Entweder darf keine Datei über einer Bankgrenze liegen, oder Du musst für diesen Fall entsprechend vorsorgen (also Modulcode schreiben, der damit klarkommt).

    Zitat von GI-Joe

    Ich muß es also so machen, daß ich aus dem asm-sourcecode einen EPROM-Header generiere, der alle Infos über
    Menüeintrag-Name, Adresse des Menüeintrag-Namens,
    Anfangadresse/Länge/Startbank jedes Files im EPROM,
    Anzahl der Files/Menüeinträge,
    enthalten muß.
    Danach muß mein ShellScript den fertigen BIN-Header mit den NutzFiles zusammen-cat´en und auf EPROM-Größe alignen/auffüllen mit $FF-bytes.

    Ich würde immer noch sagen: Lass letzteres ruhig den Assembler machen.

    Zitat von GI-Joe

    Ein paar Schritte hast Du mit per "schnellschusss" ja schon geliefert, das hat mich schon ein bißchen zum Denken angeregt

    Für die Dateinamensgeschichte käme noch hinzu:

    Damit werden weitere Tabellen für die Dateinamenslängen und Dateinamenszeiger angelegt, sowie die Dateinamen selbst eingefügt.

    Zitat von GI-Joe

    Und NEIN, ich werde dieses Projekt nicht in C, Java oder Python oder sonstwas machen, obwohl es für viele vielleicht einfacher wäre.
    Ich kann nur sh/bash und C64asm

    Irgend etwas aktuelleres solltest Du Dir aber vielleicht beizeiten doch aneignen... :bgdev
    Mit bash geht zwar grundsätzlich alles, aber bis man sich da aus der manpage die richtige Syntax herausklamüsert hat, hat man es in Python schon dreimal fertig, und da ist das Lernen der Python-Basics schon eingerechnet. :weg:

    Zitat von Mac Bacon

    Das nur der Vollständigkeit halber, denn es hilft Dir nicht unbedingt weiter: denn Du musst ja trotzdem das Modulbanking beachten: Entweder darf keine Datei über einer Bankgrenze liegen, oder Du musst für diesen Fall entsprechend vorsorgen (also Modulcode schreiben, der damit klarkommt).

    Die Copy-Routine is fertig und funzt auch schon. Ich muß nur die Startbank und die Startadresse innerhalb der Bank und die Länge (HighByte+1) des zu kopierenden Code übergeben, so kann ich die Nutzdaten nahtlos aneinander reihen.

    Zitat von Mac Bacon

    Ich würde immer noch sagen: Lass letzteres ruhig den Assembler machen.


    Nö, das zusammen cat´en lass ich das shellscript machen, sonst müßte ich später, wenn ich größere vielleicht EPROMs als 64kb nehmen möchte, wieder alles umstricken weil der Assembler nur bis 64kb kann (oder nich ?)

    Zitat von Mac Bacon

    Irgend etwas aktuelleres solltest Du Dir aber vielleicht beizeiten doch aneignen... :bgdev
    Mit bash geht zwar grundsätzlich alles, aber bis man sich da aus der manpage die richtige Syntax herausklamüsert hat, hat man es in Python schon dreimal fertig, und da ist das Lernen der Python-Basics schon eingerechnet. :weg:

    Aktuelleres ? Also statt 6202 nun 68000er Assembler ? OCH NÖÖÖÖ :abgelehnt;)
    Python hätte ich in der Tat schon des Öfteren gebrauchen können. Nur der Lust/Zeit/Begreif-faktor is bei mir im Moment noch auf -3.

    Zitat von Mac Bacon

    Für die Dateinamensgeschichte käme noch hinzu:

    Danke ! Langsam wird helle hier im Tunnel 8) Das ist zusammen mit dem "1. Schnellschuss" schonmal ein nettes Grundgerüst worauf man aufbauen kann.
    Ich habe vor, ein TextFile mit "DATEINAME.PRG","MENUEINTRAG" pro Zeile zu machen, aus der das shell-script die daten holen kann (inspiriert durch dtvmkfs.exe). Der Rest der Daten wird dann im shell-script berechnet/ermittelt und in das .asm - Tempfile geschrieben.


    Nu mach ich mir mal manuell 2 "Datensätze" in meinen .asm-code und versuche mal meinen code dahingehend umzubauen.
    Das Schöne is ja auch immer der "lerning by doing" - Effekt bei solch "komplizierten" Kram ^^


    Wenn ich nich weiter komme, meld ich mich nochmal :whistling: