Hallo Besucher, der Thread wurde 31k mal aufgerufen und enthält 170 Antworten

letzter Beitrag von darkvision am

MegaAssembler V3.7 im Quelltext verfügbar

  • Ich denke diese zip-Datei erfüllt auch ihren Zweck

    Danke. Funktioniert soweit.


    Ich habe nur 2 kleinere Probleme gefunden ;-) .


    1. Der Info-Block des neuen Programms ist 1:1 identisch mit der alten Version (Klasse/Autor/Datum/Uhrzeit)


    2. Das Programm sucht wohl nur auf A: und B: nach dem neuen MegaAss. Das sollte auf A: - D: erweitert werden. So wie ich das sehe, kann der neue MegaAss 4 Laufwerke. Dafür kann ja das "Assembler"-Icon durch ein System-Icon (OK oder YES) ersetzt werden.


    Gruß
    Werner

  • Würde der MegaAss V3.7 auch noch unter Geos laufen?

    Ich hab eben ein "nacktes" GEOS 2,0 getartet, ausser ein paar patches wie "InstallDriveD" ist da nichts von MegaPatch zu sehen un der MA3.7 hat eben sauber ein Programm übersetzt. Ich kann mich auch nicht daran erinnern da jemals speziellen MP-Code eingebunden zu haben.


    Ich häng mal ein paar ScreenShots von meinem DeskAccesory an mit dem ich zwischen geoWrite, geoPaint, MegaAss & Co wechsle. Vielleicht gibt das euch ja ein paar Ideen wie man CallMA aufpeppen könnte ;)



  • Ich würde eine V3.8 bereitstellen wollen, da sind dann die Korrekturen von WWeicht für den 128 enthalten und eine kleinere (kosmetische) Korrektur: Unter "Parameter" gibt es einen Menüeintrag um ein Laufwerk zu wählen:

    Code
    1. "Laufwerk X: Infotexte"


    Das ist verwirrend, da sollte stehen

    Code
    1. "Laufwerk X: AutoAssembler"


    Das ist das Laufwerk von dem MegaAssembler die AutoAssembler-Konfigurationsdateien anzeigt.


    Außerdem würde ich das AutoAss-Template so anpassen das man weiß wann die Datei zu groß wird (g-Pseudo-Opcode, max. 16Kb an Dateinamen sind erlaubt).


    Gibt es sonst noch Fehler oder Korrekturen?

  • Klingt gut, aber wie man das realisieren könnte... hab da zwar schon eine (evtl. relativ einfache) Idee, aber eines nach dem anderen :D


    Hab jetzt erstmal unter VICE MP3 installiert und ein AUTO_EXEC erstellt das die Seriennummer an meinen C64 anpasst damit ich die gleichen Anwendungen wie geoWrite/geoPaint nutzen kann ohne jedes mal über den Editor die GEOS-ID zu ändern (gab da zwar schon ein Tool Names NewID, war aber keine AutoExec).


    Momentan kompiliere ich meine Programme unter VICE, wenn man da den Speed auf 1000% setzt spielt auch 100x TopSym/TopMac keine Rolle :)
    Vor allem der VICE-Monitor ist ja genial zur Fehlersuche :thumbsup:

  • Lass Dir damit Zeit, denn es war ja einfach nur ein Vorschlag bzw eine Anregung von mir.


    Ich arbeite lieber mit echter Commodore bzw CMD Hardware. Auch wenn ich im zumindest im Urlaub unter VICE arbeiten muss, kann ich mich nicht so recht damit anfreunden. Auf der einen Seite fehlt mir da das komplette Commodorefeeling und auf der anderen Seite komme ich mit der Handhabung einfach nicht zurecht :-( Mit dem C128 und SuperCPU128 bin ich persönlich einfach immer schneller am Ziel.


    Pusti64

  • Lass Dir damit Zeit, denn es war ja einfach nur ein Vorschlag bzw eine Anregung von mir.

    Schon OK... Feedback ist doch immer gut. Ich denke da an neue OpCodes die einen Dump des Symbolspeichers erstellen bzw. an Stelle von t "TopSym" den Symbolspeicher aus dem Dump laden. Ich muss mir mal anschauen wie der Symbolspeicher genau verwaltet wird, aber vom Prinzip her könnte das klappen. Dann müsste man nur 1x einen Dump erstellen und sofern sich TopSym/TopMac nicht ändern könnte man an Stelle von geoWrite-Texten einfach die Labels aus einer Binär-Datei laden. Oder aber der Symbolspeicher wird automatisch für jede eingebundene Datei als eine Art Cache-Datei binär abgelegt und falls vorhanden beim nächsten einbinden von TopSym automatisch geladen....


    Ich arbeite lieber mit echter Commodore bzw CMD Hardware.

    Würde ich auch gerne, aber bei den vielen Umbauarbeiten an meinem Konvertierungstool brauch ich einfach alle Quelltextdateien auf einmal geöffnet um Code von a nach b zu kopieren. Wenn das alles mal gemacht ist und funktioniert gehe ich auch wieder ans Original. Schon alleine weil ich dort vor 20Jahren schon am Nachfolger zu MP3 gearbeitet hab. Leider läuft der installiert nur mit der RAMLink weshalb ich das unter VICE nicht nutzen kann (Nachdem ich ein paar Quelltexte angeschaut hab war das wohl zu Testzwecken so gewollt). Daher hab ich dann MP3 unter VICE installiert und dabei ist mir aufgefallen wie altbacken MP3 doch war/ist. Alleine der Editor.... grausam. Naja, da muss ich jetzt durch. Andererseits hat mir das den Monitor von VICE näher gebracht. BreakPoints zu setzen oder schrittweises abarbeiten von Code... geil! Wenn es das nur schon vor 20Jahren gegeben hätte!


    Jetzt Hab ich VICE erst mal die 500%/1000% im Menü beigebracht... Für das kompilieren spart das jetzt ein paar Mausklicks...

  • Was hast bzw hattest Du da in Planung?

    Keine Ahnung mehr... ich sehe nur das der Startvorgang und der Editor auf meiner RAMLink deutlich eleganter aussehen als MP3. Ist leider zu lange her als das ich die "Roadmap" von damals noch klar im Kopf habe. Auf dem Real-C64 sieht der Start von GEOS aber schon mal deutlich anders aus als der Start von GEOS mit MP3 unter VICE :rolleyes:


    Gerade kopiere ich die MP3-Quelltexte auf den PC... wenn das mal durch ist und ich wieder weiß wie ich das Paket kompiliere kann ich vielleicht mehr dazu sagen. Momentan nervt mich GEOS128 zum testen unter VICE. Momentan bekomme ich den gleichen Fehler wie unter G3-64: MegaPatch/G3 findet den Desktop nicht ("Bitte eine Diskette mit 128 Desktop einlegen"). Dabei ist die Datei auf beiden Laufwerken vorhanden.


    Nuja... Wochenende ist rum... Bei MP3 hat sich nicht viel getan, aber wenigstens ist mein Tool zum kopieren von D81-Partitionen von der HD via D81-Images und geoDOS in der preAlpha-Phase. Wenn die kopierten D81-Images mit den Quelltexten sich ohne Fehler nach ASCII/UTF8 übersetzen lassen scheint der erste Test positiv auszufallen :D Mit den Quelltexten am PC kann ich dann zumindest mal den Code als Dokumentation bereitstellen. Wenn ich dann mal weiß wie man den Code übersetzt kann ich auch die geoWrite-Dateien anbieten.


    Auch wenn es gerade etwas ruhiger ist... ich bin bei der Arbeit, geht halt alles etwas langsamer, werde ja auch net jünger :whistling:

  • Hallo Darkvision,
    das klingt alles sehr interessant :-)
    Aber erstmal das Eine (MP3) und dann das Andere ;-)


    Ich bin nun auch nach Tagen endlich wieder dazugekommen, CallMegaAss anzupassen. Bin nun soweit, dass wie von Werner angeregt, GeoPATCH nur unter GEOS128 mit 80 Zeichen zur Auswahl angeboten wird. Fehlt nur noch die die Anpassung auf alle vier Laufwerke. Da ich hier unter Umständen das Rad nicht neu erfinden möchte, meine Frage an Werner.
    Hast Du eventuell eine geeignete Routine in Petto, die Du womöglich schon für eine andere Anwendung verwendet hast? Ansonsten muss ich mir bei Gelegenheit selbst eine entsprechende Routine per driveType-Test schreiben.


    Pusti64

  • Momentan nervt mich GEOS128 zum testen unter VICE. Momentan bekomme ich den gleichen Fehler wie unter G3-64: MegaPatch/G3 findet den Desktop nicht ("Bitte eine Diskette mit 128 Desktop einlegen"). Dabei ist die Datei auf beiden Laufwerken vorhanden.

    Mal ein Schuss ins blaue.


    Ist ein Schreibschutz aktive?


    Starte ich MP3 vom SD2IEC und der Schreibschutz der SD-Karte (kleiner Schieber an der Kartenseite) ist aktiv, startet MP3 auch nicht -> Bitte Diskette mit TopDesk einlegen.
    Schalte ich den Schreibschutz wieder aus, startet MP3 normal.
    Keine Ahnung warum dies so ist.


    Gruss C=Mac.

  • Momentan nervt mich GEOS128 zum testen unter VICE. Momentan bekomme ich den gleichen Fehler wie unter G3-64: MegaPatch/G3 findet den Desktop nicht ("Bitte eine Diskette mit 128 Desktop einlegen"). Dabei ist die Datei auf beiden Laufwerken vorhanden.

    Was sind das für Startdisketten?


    Entweder ist da bei der Installation von MP3 etwas mächtig schief gelaufen oder ...


    MP3 mag es nicht, wenn eine Boot-Disk für ein anderes Laufwerk erstellt wurde. Prominentes Beispiel: Eine Bootdisk CMD-FD-1581 bootet nicht korrekt auf CBM-1581 und umgekehrt. Kann mir zumindest vorstellen dass das ähnlich ist, wenn die Boot-Disk (D81) z.B. von einer RAMLink oder HD stammt ....


    Und auch bei VICE kann ich wohl nicht wirklich helfen. Hier läuft WinVICE 3.2 32 bit (letzte Version von http://vice.pokefinder.org/ vom 20.05.18; die ist etwas neuer als das "offizielle" Release) unter 32bit Win10 1803.
    Die Linux-Versionen kenne ich nicht und kann nicht sagen, ob da was anders ist als bei der Windows-Version.


    Folgendes ist mir bei der WinVersion von X128 (32 bit) aufgefallen:
    - CMD-FD-Emulation läuft hier überhaupt nur, wenn unter "C128 Einstellungen" der "Maschinen Type" auf "International" steht
    - CMD-FD 4000 funktioniert nicht richtig (Bsp: ich formatiere eine D4M mit FD-Tools. Das läuft meist schon nicht korrekt durch oder danach wird die gerade formatierte Disk nicht mehr erkannt,)
    - CMD-FD 2000 funktioniert problemlos und angenehm schnell im C128-Mode und im C64-Mode (GO64) von X128
    - in den C64-Emulatoren funktionieren beide aber relativ langsam





    meine Frage an Werner.
    Hast Du eventuell eine geeignete Routine in Petto, die Du womöglich schon für eine andere Anwendung verwendet hast?

    Nee, nicht wirklich ...


    Folgendes muss passieren:


    1. beim Start des Hilfsprogramms sollte das aktuelle Laufwerk gespeichert werden und beim Beenden über "Abbruch" auch wieder eingestellt werden (damit bei Geos64 das SWAP-File gelöscht wird)
    2. wenn ein Programm (z.B. Assembler) gestartet werden soll muss vorher das SWAP-File (Geos 64) gelöscht werden und dann erst das Programm gestartet werden
    3. der Laufwerkswechsel A - B - A sollte ja schon vorhanden sein, ebenfalls das Löschen des SWAP-Files von A oder B
    4. hier muss doch eigentlich nur jeweils auf Laufwerk C und D erweitert werden


    Ich schaue die nächsten Tage mal, ob ich da was passendes finde (kann etwas dauern) ....


    Gruß
    Werner

  • Beim studieren des MegaPatch-Codes ist mir ein Feature im MegaAss aufgefallen was ich wohl vergessen habe zu dokumentieren:


    Im AutoAssembler-Modus unterstützt MegaAss die Codes $f0 = Quelltext wählen und kompilieren, $00 beendet den Dateinamen, $ff beendet die Dateiliste.


    Daneben gibt es noch $f1: AutoUserJob
    Dabei kann Programm-Code ausgeführt werden der dem Befehlsbyte $f1 folgt. Die Routine muss mit RTS beendet werden da der Code mittels JSR ausgeführt wird. Ein Beispiel findet sich dafür im MegaPatch-Code <mp64_symbol/-A3_Prog.s>: hier wird auf ein anderes Laufwerk gewechselt, eine Datei gelöscht und anschließend weitere Befehle ausgeführt.


    $f5: Linker starten.
    Im gleichen Beispiel wird nach dem Laufwerkswechsel mittels Befehlsbyte $f5 der Linker gestartet. Nach dem Befehlsbyte folgt der Name der linker-Datei im Schema der Quelltextdateien, also $f0,"name",$00.


    $f4: AutoAssembler starten.
    Nachdem eine Datei über den Linker erzeugt wurde kann mittels $f4 zurück zum AutoAssembler gewechselt werden.


    $f3 oder alle anderen Werte führen dazu das der AutoAssembler beendet wird.

  • Ergänzung:
    Bei Verwendung des $f1-Befehls wird in a1L das Quelltext-Laufwerk und a1H das Programmcode-Laufwerk übergeben.
    Vor dem RTS-Befehl muss in a0 ein Zeiger auf das nächste Befehlsbyte gesetzt werden.


    Wenn man den Linker aufruft kann es sinnvoll sein die Zieldatei zu löschen, ansonsten erscheint der Hinweis das die Ziel-Datei bereits existiert. Wenn man mehrere Programme kompiliert und automatisch linken möchte würde das jedes mal den Vorgang unterbrechen. Das oben angeführte Beispiel macht das so.