C64 Studio - Entwicklungsumgebung

  • C64 Studio - Entwicklungsumgebung

    Mahlzeit:

    Vor lauter Lust und Laune habe ich mal eine Art Entwicklungsumgebung gebastelt. Mir gefällt, daß im Vice ein netter Monitor enthalten ist, aber leider ist der etwas unhandlich geraten. Da der Monitor auch per Remote ansteuerbar ist, dachte ich mir, das versuchst du mal.

    Deshalb habe ich das C64 Studio geschrieben. Das Ganze ist jetzt wohl großteils benutzbar, allerdings wie so oft schön auf mich zugeschnitten. Das Ganze arbeitet mit Vice (mit WinVICE 2.3 getestet) zusammen, basiert auf .NET 2.0. Getestet habe ich das Studio auf Windows 7, sollte aber auf älteren Windowsen auch arbeiten. Mono wird wahrscheinlich aufgrund zweier Hacks nicht funktionieren, da fehlt mir allerdings auch die Testmöglichkeit.

    Was genau ist jetzt das Tolle an dem Tool?

    Man kann durch den eigenen Code debuggen, ähnlich wie man es von "richtigen" Programmierumgebungen kennt. Das setzt allerdings einen installierten Vice voraus. Man kann Variablen ausgeben lassen (rudimentär) und Symbole auffinden lassen. Es gibt einige kleine Haken, bei deaktiviertem True Drive kommt es bei Kernal-Aufrufen gelegentlich dazu, daß ein Step darüber nicht greift. Man kann dann aber im Normalfall entweder etwas später direkt in den Debugger "breaken" oder direkt einen Breakpoint (Debug run/resume to) setzen, der dann greift.

    Da ich für die Debug-Ansicht den Code sowieso großteils parsen muß, habe ich den anfangs verwendeten ACME durch einen eingebauten Assembler ersetzt. Der scheint soweit zu funktionieren (für Project J reicht es), hat aber bestimmt noch einige Macken in Grenzbereichen. Es werden derzeit nur die Makros !binary, !source, !to, !byte, !word und !text unterstützt.

    Es wäre toll, wenn sich jemand das Teil ansehen könnte, und dann auch gerne konstruktive Kritik übt. Es fehlt bestimmt Einiges, das jemand gebrauchen könnte.

    Die aktuelle Version liegt auf georg-rottensteiner.de/files/C64StudioRelease.zip

    Mir derzeit bekannte Bugs:
    -Beim Beginn des Debuggens muss man einmal zusätzlich "Steppen", danach paßt die Ansicht aber zum Zustand.
    -Das !text-Makro geht nicht auf PETSCII ein, es übernimmt die Zeichenwerte direkt von ASCII



    Edit hexagon 20.06.2013: Link angepasst

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von Endurion ()

  • Scheint ja recht viele nützliche Dinge unter einer Oberfläche zu vereinen. Muss ich für mich mal austesten, wenn ich mal wieder an nem Windows-PC sitze, ich kann mir vorstellen, das ist was für mich. :D Danke schonmal im Voraus für die tolle Arbeit! :thumbsup:

  • Ist jetzt nicht spezifisch für den C64 ausgelegt, wenn sich der VC-20-Emulator genauso verhält bezüglich des Monitors müsste es eigentlich gehen.
    Bei dem Monitor gibt es leider ein paar Macken, wo man gegensteuern muss. Kann sein, dass das Studio dabei aus dem Tritt kommt, sollte aber eigentlich nicht.

  • Mannomann, Fehler ohne Ende.
    Jetzt assembliert auch mein häßlicher Joe-Gunn-2-Code damit. Aktuelle Version 0.9e hinter dem Link oben. Böser x64sc, der Sound spielt ganz leise. Ich dachte, das wäre mein Assembler gewesen.

    Neu:

    * Labels in gleicher Zeile wie Code möglich
    * Makro !tx alternativ zu !text
    * Size und Skip-Parameter bei !binary umgesetzt
    * AND, EOR und OR in Expressions erlaubt (zusätzlich zu den C-Operatoren)

  • Endurion schrieb:

    Mono wird wahrscheinlich aufgrund zweier Hacks nicht funktionieren, da fehlt mir allerdings auch die Testmöglichkeit.
    Das ist schade. die da?:

    Quellcode

    1. Calling Method P/Invoke Method P/Invoke Library
    3. bool PreFilterMessage (Message&) IntPtr MainForm.WindowFromPoint (Point) user32.dll
    4. bool PreFilterMessage (Message&) IntPtr MainForm.SendMessage (IntPtr, int, IntPtr, IntPtr) user32.dll
    5. void ForceEmulatorRefresh () bool MainForm.InvalidateRect (IntPtr, IntPtr, bool) user32.dll
    6. void Log (string) int dh.FindWindow (string, string) user32.dll
    7. void Log (string) int dh.SendMessage (int, int, int, int) user32.dll

    -> The Mono Migration Analyzer

    Wäre aber schön wenn es mit Mono laufen würde. Schönes Projekt, btw. Gibts sourcen, kann man mithelfen, fehlts an einem SendMessage zum Linux-VICE? :)


    Mono VirtualPC und VMware Linux von go-mono.com/mono-downloads/download.html.
    VC20+2xC64+3 1/2(*g*)1541+Jede Menge kaputter 2164+CIA's.
    | Tweetme | acm3 | Humbug | Lyx | Art |

  • Hier bekommste nochn Bug gratis dazu.

    btn Compile

    Running build on erste.asm
    Build successful, 0 warnings, 0 errors encountered

    btn "Compile and Run"

    Quellcode

    1. System.NullReferenceException: Object reference not set to an instance of an object.
    2. at C64Studio.MainForm.DebugCompiledFile()
    3. at C64Studio.MainForm.StartCompile()
    4. at C64Studio.MainForm.CompileAndDebug()
    5. at C64Studio.MainForm.ApplyFunction(Function Function)
    6. at C64Studio.MainForm.mainToolDebug_Click(Object sender, EventArgs e)
    7. at System.Windows.Forms.ToolStripItem.RaiseEvent(Object key, EventArgs e)
    8. ...


    Edit:
    Das mit dem Parse for Target kapier ich nich :) bzw. es wird anscheinend nicht mit dem Projekt abgespeichert.
    VC20+2xC64+3 1/2(*g*)1541+Jede Menge kaputter 2164+CIA's.
    | Tweetme | acm3 | Humbug | Lyx | Art |

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von Jedzia ()

  • Au, jemand, der es ausprobiert :)
    Danke für das Feedback!

    Den Bug hab ich inzwischen auch gefunden und behoben.

    Bezüglich Mono kann ich mir auch Scintilla als Problem vorstellen, das bindet wiederrum eine native Scintilla-DLL ein.

    Zusätzlich sind noch eine Menge andere häßlicher Bugs bereinigt und einige Features von ACME mehr mit umgesetzt. Es gibt inzwischen auch einen rudimentären Memory-Viewer.
    Parse for Target wird inzwischen abgespeichert, das !to-Macro im Source übersteuert aber noch.

    Eine neue Version ist hochgeladen.