Ein bissel am Z80 Disassembler weiter gekommen. 
Heute so gecodet...
- syshack
- Thread is Unresolved
-
-
Ein bissel am Z80 Disassembler weiter gekommen.
Gibts am Spectrum auch einen native Assembler? Kann mir gar nicht vorstellen auf einem Speccy zu entwicklen.
-
Wie performant ist es? In meiner Firma habe ich ein Sheet für die Arbeitszeit, da muss ich einmal im Monat die Zeiten anpassen. Wenn ich da 5 Felder von einer Woche in die nächste Woche kopiere, dann denkt Excel locker 5 Minuten nach und ich frage mich ernsthaft was da so lange dauern soll.
Mäßig...
Bei uns geht es hauptsächlich um das Drucken von Packlisten, die der Kunde als Excel haben möchte, bisschen Recordsets durchlaufen, Zeilen zählen, Bereiche (und damit Layouts) kopieren, Zellen füllen.
Gefühlt ist das so eine Sekunde je Teil, gefühlt ist Basic V2 jedenfalls deutlich schneller.
Ich habe früher oft mal grosse Excel Tabellen in VBA traversiert und dann in ein anderes Text Format in eine Datei geschrieben.
In Excel werden ja im Interaktiven und im VBA Modus die Zellen ja neu berechnet, wenn sich was ändert.
Für VBA Modus macht es aber nicht Sinn, diesen Refresh eingeschaltet zu lassen und visuell zu beobachten wie das Makro Zellen selektiert, kopiert oder rumgeschoben werden.
Einfach vor der zeitkritischen Schleife den Refresh ausschalten und nach der Schleife wieder einschalten.
Nicht vergessen, auch in Deinem Exception Handler (On Error Goto...) auch entsprechend wieder einzuschalten, falls ein Fehlerereignis passiert.
Ist ein bisschen wie beim C64 den Bildschirm ausschalten, weil dann schneller...
-
Ein bissel am Z80 Disassembler weiter gekommen.
Gibts am Spectrum auch einen native Assembler? Kann mir gar nicht vorstellen auf einem Speccy zu entwicklen.
-
Einfach vor der zeitkritischen Schleife den Refresh ausschalten und nach der Schleife wieder einschalten.
Macht auch unter .Net Sinn bei längeren Zugriffen auf ListBox & Co. den Refresh auszuschalten.
-
Ein bissel am Z80 Disassembler weiter gekommen.
Gibts am Spectrum auch einen native Assembler? Kann mir gar nicht vorstellen auf einem Speccy zu entwicklen.
https://en.m.wikipedia.org/wiki/Zeus_Assembler
Das müsste passen...
-
Den gibts auch für Windows? Cool! Z80 hat mich eh schon mal interessiert, den werde ich mal ausprobieren. Danke!
-
Den gibts auch für Windows? Cool! Z80 hat mich eh schon mal interessiert, den werde ich mal ausprobieren. Danke!
Wir werden immer mehr.
-
Den gibts auch für Windows? Cool! Z80 hat mich eh schon mal interessiert, den werde ich mal ausprobieren. Danke!
Wir werden immer mehr.
Da sage ich nur: Wehret den Anfängen.
-
Da ich etwas Abwechslung brauche habe ich erst mal nicht an meinem Amigacode weiter gearbeitet. Stattdessen habe ich etwas anderes angefangen, was ich auch schon länger machen wollte und was mir dann bei meinem Amigaprojekt weiter helfen sollte.
In WinUAE gibts ja einen Debugger, der aber entsetzlich zu bedienen ist. Es gibt auch einen GUI Debugger, der aber nur unwesentlich besser ist. Deshalb habe ich gestern damit angefangen an eine neuen Debugger zu arbeiten, der dann hoffentlich in WinUAE integriert wird. Ich finde sowas sollte bei einem gute Emulator dabei sein, aber Toni (der Autor von WinUAE) legt da nicht so grossen Wert drauf, weil da halt auch Zeit frisst.
Die grundlegende GUI habe ich ja schon fertig. Da gabs ein sehr schönes Projekttemplate von MS, das ich als Basis verwende. Aber bevor ich das verwenden kann, muss ich das erstmal in WinUAE so integrieren, dass ich es daraus benutzen kann. Das ist kniffliger als gedacht, weil der WinUAE Code nicht gerade Wartungsfreundlich ist.
Ich hatte ja schon ein paar kleinere Änderungen am bestehenden Debugger gemacht gehabt, die auch angenommen wurden, aber das ist natürlich ein Nummer grösser.
-
Mit der MS Visual Studio Code Extension "AmigaAssembly" hat man eine sehr schöne Debugumgebung. Dies kann ich nur empfehlen. Damit habe ich meine Gam und Intros entwickelt und natürlich auch debugt.
-
Ich habe eine funktionierende Toolchain, da möchte ich ungern wechseln. Welchen Compiler verwendet man bei der Code Extension?
-
Die Extension beinhaltet auch eine komplette Toolchain. Diese ist für MAC und PC
Natürlich ist auf dem MAC nur FA-UAE möglich. Als default ist vasm+vlink enthalten. Kannst auch alles mit make erstellen lassen. Eine ADF inkl. Bootblock ist auch mit einem Klick möglich zu erstellen. Und da man VS Code benutzt ist Git gleich mit am Board. -
Momentan arbeite ich erstmal an de Debugger. Mal sehen wie es läuft, eventuell könnte ich den dann in eine voll integrierte Toolchain ausbauen, aber da sind schon wieder Zukunftsträume.
Mittlerweile ich es ja geschafft meine eigene GUI aufzumachen, aus WinUAE heraus. Anfangs wollte ich den Code direkt ins Projekt einbauen, aber das ist zu kompliziert. Erstens ist die neue GUI wesentlich koplexer und hat daher auch viel mehr Sourcecode und zweitens überlappen sich dann die Resourcen und ich müsste die in die WinUAE Resourcen mergen, wozu ich überhaupt keine Lust habe.
Jetzt habe ich es erstmal so gelöst, dass ich es als DLL baue und die DLL dann dynamisch lade. Das hat den Vorteil dass man die GUI beliebig ersetzen kann und sie ausserdem als eigenständiges Projekt gewartet werden kann. Das war gar nicht ganz so einfach wie ich gedacht hätte, aber zumindest diese Hürde ist schonmal genommen. Also werde ich heute Abend dann mal schauen ob ich zumindest die Registeranzeige und eventuell einen Memorydump hinbekomme.
-
C64Studio um ein paar CPU-Typen erweitert. Bis zum Mega65 sollte jetzt alles gehen. Nur bei dem habe ich ein paar Abweichungen gegenüber ACME. Die möchte ich noch geradeziehen.
-
Das ich schon irgendwas anzeigen kann, war ein Wunschtraum. Erstmal musste ich mir ein Konzept überlegen wie ich mit dem Debugger aus WinUAE kommunizieren kann. Ich habe jetzt die GUI vollständig in eine DLL ausgelagert und dachte, ein paar Exports und Imports und dann kann ich schon loslegen. Ja, denkste. Das hat deutlich länger gedauert als erwartet.
Jetzt bin ich endlich soweit dass die GUI in WinUAE integriert habe. Der Debugger tut zwar noch nichts, aber ich kann ihn schon mal anzeigen und mit WinUAE komunizieren. Jetzt kann ich tatsächlich anfangen schonmal die Register zu übertragen.
-
Hab heute an einem neuen Modulgenerator für meine 64K Karte weitergecodet und eigentlich abgeschlossen.
Beim Test am C64 tauchte dann ein "kleines" Problem auf.
Toll wenn man nicht mehr weiß wie seine eigene Hardware funktioniert
Wahrscheinlich wird es erst nächstes WE fertig - zumindest weiß ich schonmal woran es liegt
Hab heute abend dem coden den Tatort vorgezogen
-
Gestern den halben Tag damit verbracht, die ganzen Scaling-Issues bei C64Studio auszumerzen. Bis auf Kleinigkeiten scheint es auch gelungen.
Damit ist Mega65-Entwicklung auch diversen schrägen Tablets mit Super-DPI problemlos möglich. Hurra!
-
Inspiriert durch den "Heute so gepixelt"-Thread habe ich meinen PETSCII-Converter um Support für die Farben bzw. das BASIC der TED-Reihe (C16/C116/+4) erweitert. Ich musste dabei feststellen, dass mehr Farben nicht automatisch ein besseres Ergebnis liefern, aber für Silouhetten und so sieht es ganz nett aus.
TED-Version:
VIC II-Version:
TED-Version:
VIC II-Version:
-
Ich habe es geschafft, den GDB mit dem echten Amiga über die serielle Schnittstelle zu verbinden. Damit geht sogar der Code-Download auf den Amiga halbwegs flott, da ich bis zu 230KBaud unterstütze.
Allerdings programmiere ich nur ohne OS Unterstützung, also nicht für jedermann die perfekte Lösung.
