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 http://www.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

    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.

    Die einzigsten VM's die hier laufen sind alles Linux-Guests auf Linux-Host. Ich hab sowas lieber nativ.
    Notfalls würde ich auch Java in kauf nehmen. ^^

    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)

    Quote from Endurion

    Mono wird wahrscheinlich aufgrund zweier Hacks nicht funktionieren, da fehlt mir allerdings auch die Testmöglichkeit.

    Das ist schade. die da?:


    Code
    1. Calling Method P/Invoke Method P/Invoke Library
    4. bool PreFilterMessage (Message&) IntPtr MainForm.WindowFromPoint (Point) user32.dll
    5. bool PreFilterMessage (Message&) IntPtr MainForm.SendMessage (IntPtr, int, IntPtr, IntPtr) user32.dll
    6. void ForceEmulatorRefresh () bool MainForm.InvalidateRect (IntPtr, IntPtr, bool) user32.dll
    7. void Log (string) int dh.FindWindow (string, string) user32.dll
    8. 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 http://www.go-mono.com/mono-downloads/download.html.

    Hier bekommste nochn Bug gratis dazu.


    btn Compile


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


    btn "Compile and Run"


    Code
    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.

    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.

    Quote from AntaBaka

    Was bei der aktuellen Begrenzung auf 250KB pro Anhang nicht so einfach ist.


    In diesem Fall sollte man mal generell über diese Begrenzung nachdenken und über weitere Downloadquellen (für die F64 Nutzer). Ist aber nur ein Vorschlag. :)

    Endurion bietet es ja über seine Website und nicht irgendeinem suspekten Filehoster an. Ich sehe da kein Problem bzgl. geringer Haltezeit.