Hallo Besucher, der Thread wurde 479k mal aufgerufen und enthält 4057 Antworten

letzter Beitrag von smithloo am

C64 Studio - Entwicklungsumgebung

  • Ui, das hatte ich auch schon mal überlegt. Gibt es aber im C64Studio derzeit nicht.


    Einen Code festlegen ist ja einfach (* = Adresse), aber den Rest drumherum "fliessen" lassen, ist nicht ohne. Wo kann man "sicher" schneiden? Woher weiß ich, dass ein RTS ein sicherer Schnittpunkt ist?

    Wenn ich einen Block im Source mit !START NAME und !ENDE NAME definiere, dann ersetzt !ENDE NAME quasi die Suche nach einem RTS. Der Block soll ja unabhängig vom Programm nur fest im Speicher definiert ein. Wenn es eine Überlappung gibt dann müsste der Assembler ein JMP "zum Ende dieses Blockes" einbauen. Ich gebe zu, das ist eine echte Herausforderung.

    Was wäre der Benefit? Ich habe einige (richtug gute) Programmschnipsel aus früheren Zeiten, in denen noch mit "schmutzigen" Tricks gearbeitet wurde. Zum Beispiel wurde gerne in dem in Bytes zwischen den Befehl gesprungen. Daraus ergab sich dann für die CPU ein ganz anderer Befehl. Auch selbst modifizierende Programme wurden gern genutzt. Das macht die Portierung oder Integration in anderen Programmen mit Crosscompilern sehr schwierig.
    So könnte ich den Source 1:1 stehen lassen. Ist nicht tragisch. Für mich sollte "nur" Zeit sparen.

    Sicher schneiden wird man nie können, auch der Ansatz mit dem JMP xxxx erstmal gut klingt.


    Was aber wenn kurz vor dem JMP xxxx ein BEQ kommt der sich auf eine Adresse nach dem JMP bezieht. Das wird dann in die Hose gehen. Auf der anderen Seite kann man dass aber dann schnell per Hand reparieren indem man aus dem BEQ ein bne + : JMP xxxx: + macht und schon läuft das wieder.


    dg5kr Wieso disassemblierst du die entsprechenden Routine nicht und passt sie danach noch ein wenig an, wäre doch die sauberste Lösung?

  • Hi Endurion,


    mal eine Frage, Bin ja gerade dabei Boulder Dash im Mega65 in Basic zu schreiben, und hier bin ich im Moment die Grafiken zu überarbeiten. Jetzt meine Frage.

    Da ja im Charset auch Animationen sind und ich die gerne auch machen möchte, fehlt mir leider eine Option um die Animation zu überprüfen, ob sie sauber läuft.

    So eine Option von Anfang Animation bis Ende Animation Einstellung und dies zu testen.

    Oder gibt es das schon und weis es mal wieder nicht. =O


    Gruß

  • Hallo Endurion


    ich hab jetzt mal ein TSB-Programm mit dem Studio entwickelt (oder bin noch dabei). Geht prinzipiell super! :-) Dabei hab ich nach einer Möglichkeit gesucht, das Programm tokenisiert zu speichern, aber nichts gefunden. Hab ich was übersehen? Bei Build&RUN wird es doch tokenisiert an VICE übertragen, oder nicht? Dann hab ich versucht, das Programm über die Zwischenablage in VICE einfließen zu lassen: Geht auch nicht, da immer Großbuchstaben zwischengespeichert werden (selbst wenn man im Studio Kleinbuchstaben aktiviert hat).


    Einen Vorschlag hab ich auch. Könnte man RENUMBER auch von den physischen Programmzeilen (den grünen) ausgehen lassen? Manchmal stellt man im Programm Teile einfach um, genau da wäre es schön, wenn man den Teil umnummerieren könnte. Das geht aber nicht, weil das Programm so ja noch nicht lauffähig wäre (meldet das Studio auch). Wenn man jetzt die Bereichsangabe aus den grünen Zeilennummern nähme, wäre das Problem doch gelöst! Du willst also z.B. die (grünen) Zeilen 53 bis 96 nach Basic-Zeilennummern 4000 ff neu nummerieren. Ginge das?


    Arndt

  • Teilweise umnummerieren (igitt, das schreibt man jetzt so?) geht mit einer Selektion. Die gewünschten Zeilen markieren, rechts-Klick und "Renumber", dann werden nur die betroffenen Zeilen verändert.

    Ich bin mir jetzt nicht sicher, was passiert, wenn diese irgendwo anders referenziert werden; ob die Referenzen dann auch mitgeändert werden.


    Du meinst aber indirekt die Zeilennummern als BASIC-Zeilennummern zu verwenden? Hmm, könnte knifflig werden, wenn sich Zeilen verschieben, dann müssten die Referenzen immer mit verschoben werden.


    Ist das tokenisiert-speichern nicht indirekt das .prg-File, das beim Compile erzeugt wird?

  • Die gewünschten Zeilen markieren, rechts-Klick und "Renumber", dann werden nur die betroffenen Zeilen verändert.

    Dann sagt das Studio, dass das Programm nur im kompilierfähigen Zustand RENUMBERt werden kann (die Zeilennummern sind nicht mehr in der richtigen Reihenfolge). Ich stelle mir vor, wenn ich den Bereich über die grünen Zeilenangaben bestimme, dann setzt sich das Studio über die falsche Reihenfolge weg (die physische Reihenfolge hängt ja nicht von der Nummerierung ab).

    Ist das tokenisiert-speichern nicht indirekt das .prg-File, das beim Compile erzeugt wird?

    Uh, das ist das einzige, was ich nicht ausprobiert habe (da ich unter einem Kompilat was anderes verstehe)! Wo landet das dann?


    Arndt

    (Ah, hab's! Natürlich im gleichen Verzeichnis, wo sonst...?) :-)

  • Ah, das Renumber musst du an der Originalposition machen.

    Aus Sicherheitsgründen verweigert das C64Studio ein Renumber, wenn es nicht sicher alle Referenzen auflösen kann. Lieber ganz oder gar nicht, ein halb renummeriertes Listing hat noch keinem geholfen :)

  • kurze Frage: kann ich im C64Studio bei einem Breakpoint Register on the fly ändern? Gerne würde ich beim Debuggen damit bestimmte Situationen erzeugen. Gleiches gilt für die Speicheranzeige. Danke für sie Antwort.

  • Lynx: Hab mal im Charscreen Export aufgeräumt (war schon längst überfällig), dafür gibt es auch drei neue Optionen beim Export to basic code:

    * Überflüssige Farbwechsel raus (greift nur bei Space und Shift-Space

    * Ausgabe als String statt PRINT-Statements, mit Cursor-Down und Left

    * Ersetzen von Leerzeichen durch Cursor-Rechts


    Erstmal nur auf dem WIP-Link.

  • Gibt es schon Infos über das debugging via Kernal64? Ist da was in Arbeit? Im Hinblick auf die Entwicklung für das WiC64 wäre das schon extrem hilfreich.

  • Hi Endurion,


    Also ich habe mal angefangen eine Char-Animation mit dem Mega 65 im IRQ zu machen.

    IRQ habe ich mit der Hilfe hier aus dem Forum sehr gut hin bekommen.

    Leider wird mein Quellcode irgendwie richtig compiliert, aber sobald ich das Programm im Mega65 starte sind die Adressen für die Chars falsch.

    Hier mal ein Bild vom Compilier

    Hier sind die Adressen von den Chars noch in Ordnung


    Und hier ein Bilck mit dem Monitor


    Hier in der Zeile 1650 fehlt eine Zahl für die Adresse. Normal müsste die Adresse $50498 lauten.

    Jetzt weis ich mal wieder nicht, woran das liegt.

    Habe das vorher mit einer simblen Basic-Programm probiert. Und da lief es ohne Probleme.


    und hier der Assembler-Code

    Hast du vielleicht ein Ahnung woran das liegt.


    Dann noch was anderes.

    Da ich jetzt nicht der Crack bin im Assemblerprogrammierung, kann man diese Routine kürzer schreiben.

    Im Grunde genommen habe ich mein Basicprogramm plump ins Assembler übertragen.


    Gruß

  • Der Mega65 hat zwar mehr als 64K RAM, aber die Opcodes können damit trotzdem nicht umgehen, die können nur max. 64k adressieren.


    Wenn du RAM über 65535 verändern willst, musst du auf die 32-Bit-Zeiger in der Zeropage ausweichen oder mit MAP Bank-switchen.


    Für das erstere wären dass dann die Opcodes mit eckigen Klammern (LDA [$45],Z)

    Bei $45 bis $48 ist dann ein 32-Bit-Pointer, mit Z wird indiziert.

  • Hi Endurion!


    Ich habe einen garstigen Bug.

    Wenn ich auf meinem Laptop (am PC geht's) die Preferences öffne, dann kommt ein Fenster mit allerlei Fehlermeldungen. Da kann ich dann "Weiter" drücken und das Studio stürzt NICHT ab. Aber in die Preferences, um z.B. den VIC20 Emulator als Emulator einzugeben, kann ich leider aber auch nicht.


    LG

    Thomas


    P.S. Bin grad nicht beim Laptop, um Screenshots zu machen, aber eventuell bin ich ja auch nicht der Erste, der einen solchen Bug hat, und du kennst den schon.

  • so, jetzt habe ich alle Daten vom Laptop.


    Informationen über das Aufrufen von JIT-Debuggen

    anstelle dieses Dialogfelds finden Sie am Ende dieser Meldung.


    ************** Ausnahmetext **************

    System.NullReferenceException: Der Objektverweis wurde nicht auf eine Objektinstanz festgelegt.

    bei C64Studio.Settings.RefillAcceleratorList()

    bei C64Studio.Settings..ctor(StudioCore Core, TabPage PageToOpen)

    bei C64Studio.MainForm.filePreferencesToolStripMenuItem_Click(Object sender, EventArgs e)

    bei System.Windows.Forms.ToolStripItem.RaiseEvent(Object key, EventArgs e)

    bei System.Windows.Forms.ToolStripMenuItem.OnClick(EventArgs e)

    bei System.Windows.Forms.ToolStripItem.HandleClick(EventArgs e)

    bei System.Windows.Forms.ToolStripItem.HandleMouseUp(MouseEventArgs e)

    bei System.Windows.Forms.ToolStrip.OnMouseUp(MouseEventArgs mea)

    bei System.Windows.Forms.ToolStripDropDown.OnMouseUp(MouseEventArgs mea)

    bei System.Windows.Forms.Control.WmMouseUp(Message& m, MouseButtons button, Int32 clicks)

    bei System.Windows.Forms.Control.WndProc(Message& m)

    bei System.Windows.Forms.ToolStrip.WndProc(Message& m)

    bei System.Windows.Forms.ToolStripDropDown.WndProc(Message& m)

    bei System.Windows.Forms.Control.ControlNativeWindow.WndProc(Message& m)

    bei System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)



    ************** Geladene Assemblys **************

    mscorlib

    Assembly-Version: 2.0.0.0.

    Win32-Version: 2.0.50727.9151 (WinRelRS6.050727-9100).

    CodeBase: file:///C:/Windows/Microsoft.NET/Framework64/v2.0.50727/mscorlib.dll.

    ----------------------------------------

    C64Studio

    Assembly-Version: 7.1.0.0.

    Win32-Version: 7.1.

    CodeBase: file:///C:/Commodore/C64StudioRelease/C64Studio.exe.

    ----------------------------------------

    System.Windows.Forms

    Assembly-Version: 2.0.0.0.

    Win32-Version: 2.0.50727.9149 (WinRelRS6.050727-9100).

    CodeBase: file:///C:/WINDOWS/assembly/GAC_MSIL/System.Windows.Forms/2.0.0.0__b77a5c561934e089/System.Windows.Forms.dll.

    ----------------------------------------

    System

    Assembly-Version: 2.0.0.0.

    Win32-Version: 2.0.50727.9149 (WinRelRS6.050727-9100).

    CodeBase: file:///C:/WINDOWS/assembly/GAC_MSIL/System/2.0.0.0__b77a5c561934e089/System.dll.

    ----------------------------------------

    System.Drawing

    Assembly-Version: 2.0.0.0.

    Win32-Version: 2.0.50727.9149 (WinRelRS6.050727-9100).

    CodeBase: file:///C:/WINDOWS/assembly/GAC_MSIL/System.Drawing/2.0.0.0__b03f5f7f11d50a3a/System.Drawing.dll.

    ----------------------------------------

    WeifenLuo.WinFormsUI.Docking

    Assembly-Version: 3.0.6.0.

    Win32-Version: 3.0.6.0.

    CodeBase: file:///C:/Commodore/C64StudioRelease/WeifenLuo.WinFormsUI.Docking.DLL.

    ----------------------------------------

    HexBox

    Assembly-Version: 1.5.0.30604.

    Win32-Version: 1.5.0.30604.

    CodeBase: file:///C:/Commodore/C64StudioRelease/HexBox.DLL.

    ----------------------------------------

    FastColoredTextBox

    Assembly-Version: 2.16.11.0.

    Win32-Version: 2.16.11.0.

    CodeBase: file:///C:/Commodore/C64StudioRelease/FastColoredTextBox.DLL.

    ----------------------------------------

    System.Configuration

    Assembly-Version: 2.0.0.0.

    Win32-Version: 2.0.50727.9153 (WinRelRS6.050727-9100).

    CodeBase: file:///C:/WINDOWS/assembly/GAC_MSIL/System.Configuration/2.0.0.0__b03f5f7f11d50a3a/System.Configuration.dll.

    ----------------------------------------

    System.Xml

    Assembly-Version: 2.0.0.0.

    Win32-Version: 2.0.50727.9149 (WinRelRS6.050727-9100).

    CodeBase: file:///C:/WINDOWS/assembly/GAC_MSIL/System.Xml/2.0.0.0__b77a5c561934e089/System.Xml.dll.

    ----------------------------------------

    System.Core

    Assembly-Version: 3.5.0.0.

    Win32-Version: 3.5.30729.9141 built by: WinRelRS6.

    CodeBase: file:///C:/WINDOWS/assembly/GAC_MSIL/System.Core/3.5.0.0__b77a5c561934e089/System.Core.dll.

    ----------------------------------------

    Accessibility

    Assembly-Version: 2.0.0.0.

    Win32-Version: 2.0.50727.9149 (WinRelRS6.050727-9100).

    CodeBase: file:///C:/WINDOWS/assembly/GAC_MSIL/Accessibility/2.0.0.0__b03f5f7f11d50a3a/Accessibility.dll.

    ----------------------------------------

    mscorlib.resources

    Assembly-Version: 2.0.0.0.

    Win32-Version: 2.0.50727.9151 (WinRelRS6.050727-9100).

    CodeBase: file:///C:/Windows/Microsoft.NET/Framework64/v2.0.50727/mscorlib.dll.

    ----------------------------------------

    System.Windows.Forms.resources

    Assembly-Version: 2.0.0.0.

    Win32-Version: 2.0.50727.9149 (WinRelRS6.050727-9100).

    CodeBase: file:///C:/WINDOWS/assembly/GAC_MSIL/System.Windows.Forms.resources/2.0.0.0_de_b77a5c561934e089/System.Windows.Forms.resources.dll.

    ----------------------------------------

    Microsoft.mshtml

    Assembly-Version: 7.0.3300.0.

    Win32-Version: 7.0.3300.0.

    CodeBase: file:///C:/WINDOWS/assembly/GAC/Microsoft.mshtml/7.0.3300.0__b03f5f7f11d50a3a/Microsoft.mshtml.dll.

    ----------------------------------------


    ************** JIT-Debuggen **************

    Um das JIT-Debuggen (Just-In-Time) zu aktivieren, muss in der

    Konfigurationsdatei der Anwendung oder des Computers

    (machine.config) der jitDebugging-Wert im Abschnitt system.windows.forms festgelegt werden.

    Die Anwendung muss mit aktiviertem Debuggen kompiliert werden.


    Zum Beispiel:


    <configuration>

    <system.windows.forms jitDebugging="true" />

    </configuration>


    Wenn das JIT-Debuggen aktiviert ist, werden alle nicht behandelten

    Ausnahmen an den JIT-Debugger gesendet, der auf dem

    Computer registriert ist, und nicht in diesem Dialogfeld behandelt.



  • Hi Endurion!


    Bin gerade an einen neuen BUG im Zusammenhang mit VICE geraten.

    Mit der nicht GTK-Version von VICE funktioniert es problemlos.

    Mit der GTK-Version passiert Folgendes:



    Schließt man das schwarze Monitorfenster mit [x] ganz normal, dann startet auch mein Programm und alles ist normal