| Name | Kommentar |
 |
erstellt am 28. November 2020 um 15:52 Uhr MEZ    Ich hoffe wirklich, ich nerve nicht, hier w re n mlich nochmal eine Anregung: Es w re sehr praktisch, k nnte man einfach den Cursor an das Ende einer Zeile setzen und dann unten neben der Zeile und Spalte den OP-Code der Zeile ablesen. Momentan muss ich st ndig bei https://www.retro-programming.de/programming/nachschlagewerk/mnemonics/# mit Strg+F nachgucken, wenn ich f r selbstmodifizierenden Code einen OP-Code nachgucken muss, wenn ich gerade ADC mit X indiziert habe, dann dauert das auch einen Moment. Au erdem wei ich nicht, ob sowas in der Art nicht schon standardm ig existiert, aber w re es nicht unheimlich praktisch, k nnte man z.B. LDA [ADC (),Y] oder LDA #[ADC (),Y] schreiben und k nnte damit den in eckigen Klammern schemenhaft angegebenen OP-Code in den Akku laden? Das w rde nicht nur Zeit sparen, sondern w re auch ohne Kommentare lesbarer. Kommentar von Endurion: Bei dem Debugger-Problem bin ich schon dran, aber ich hab's noch nicht ganz eingekreist. Scheint auf jeden Fall eine Art Racing-Condition zu sein. Wenn ich Debug-Logs aktiviere, ver ndert sich das Verhalten.  Als Nachschlagewerk ist brigens das AAY64 eingebaut, in der Hilfe-Seite ganz unten. Da sind auch alle Mnemonics drin aufgelistet. Noch nicht ganz, was du m chtest, aber schon mal einfacher (bzw. Cursor auf Mnemonic setzen und F1 dr cken) Das andere sind schon sehr spezifische Erweiterungen, das mit den eckigen Klammern k nnte aber sogar vertr glich funktionieren. |
|
erstellt am 26. November 2020 um 8:51 Uhr MEZ Wieder zu deinem letzten Kommentar: Ja, man m sste nat rlich f r ein richtiges Bild, wie es wirklich von VICE kommen w rde, Scanline-IRQs emulieren, aber das meine ich nicht, was ich gerne h tte, w re die Option, sich den BS-Speicher im aktuellen Zustand anzusehen, so, wie es entstehen w rde, w rde die CPU v llig pausieren, nur ohne den VIC, dadurch k nnte man sich Sachen ansehen, bevor sie ber die Scanline laufen, wenn man z.B. irgendwelche Scanline-IRQs hat, die Sprites multiplexen sollen oder wenn sich der Bildschirm schneller aufbauen soll, als der VIC da mit der Scanline dr berfahren kann. F r sowas w rde es ja momentan reichen, bei Debug Memory die entsprechenden Daten, die der VIC lesen w rde, rauszukopieren und dann an einen zweiten virtuellen VIC zu schicken. Oder sehe ich das falsch? Kommentar von Endurion: Ja, das klingt alles gut und sinnvoll. Das geht schon ziemlich in die Richtung des eigenen Emulators. Vielleicht k nnte ich dazu wirklich den im Code vorhandenen, extrem rudiment ren Tiny64 verwenden. Der kann im Moment eigentlich nur die CPU emulieren, aber so halbwegs das Bild daraus zu generieren, w re wohl eine interessante Aufgabe. Ist aber auch wirklich nicht ohne |
|
erstellt am 25. November 2020 um 12:26 Uhr MEZ Irgendwie ist mein alter Kommentar weg, ich hatte mich da nochmal auf deinen letzten Kommentar bezogen, denn es w rde nicht allein reichen, alles anzuhalten, wenn man sehen will, wie sich gerade ein Bild aufbaut, dazu w re es n tig, sich den Bildschirmspeicher im aktuellen RAM so angucken zu k nnen, wie er letztlich auf dem BS zu sehen w re, also im Grunde Debug Memory, nur dass jede Zeile 40 Bytes enth lt. Kommentar von Endurion: Ja, das w ren alles so Dinge, die ich viel besser machen k nnte, wenn die Schnittstelle einfacher w re Den aktuellen Bildschirm aus dem Speicherinhalt zusammenzusetzen ist ja nur bedingt machbar. Das funktioniert bei einfachen Sachen, aber sobald da VIC-Umschaltungen bei bestimmten Zeilen erfolgen, muss man da eine Historie mitziehen. Ach Mann, ich m chte einen Emulator in C# drin haben, wo ich direkt alles anpacken kann. |
 |
erstellt am 24. November 2020 um 13:56 Uhr MEZ Uuuuuund .... jetzt ist er wieder da, der Fehler. Mein Programm ist sowas wie lda einHaufenDaten, X sta $02 ;break ;Debug ldy $02 ;break ;Debug inx ;break in einer Schleife und ich konnte im Y-Register andere Werte als bei Debug Memory feststellen. Ich wei nicht, was es ausgel st hat, und es ist tats chlich mitten beim Debuggen passiert, ich hatte gerade damit angefangen, mehrere Fenster zu verwenden. Es nderte sich einfach nichts mehr, beim ffnen eines neuen Fensters sah man dann zwar den korrekten Status, wobei die Bytes, die sich ge ndert hatten, nicht rot markiert waren. Anbei noch eine kleine Anregung: Wie w re es mit einem Debug-Fenster, bei dem man sehen kann, was der VIC ausspucken w rde, w rden sich keine Register ndern? Momentan kann man leider w hrend der Untersuchung eines Breakpoints sich den Bildschirm nicht angucken, was eventuell wegen der Scanline auch nicht zu viel Sinn machen d rfte. Ich w rde das sicherlich fters nutzen. Kommentar von Endurion: Da ist ja wirklich etwas im Argen, ich gucke mal, was ich da gedreht habe. Zum Gl ck habe ich das schon im GIT drin und kann die Historie des Debuggers pr fen. Zu der Ansicht: Ja, das ist extrem unpraktisch, dass VICE da h ngt. Zumindest die alte Version, ich meine, bei der GTK-Version tritt das nicht mehr auf. Auf ganz lange Sicht m chte ich den Emulator ja integriert haben, dann verschwinden eine ganze Reihe Probleme automatisch. Im Moment steuere ich ja nur den externen VICE. |
| |
erstellt am 24. November 2020 um 13:41 Uhr MEZ Tut mir leid, das Problem mit Debug Memory konnte ich leider nicht erneut erzeugen. Ich habe keinen Plan, was es verursacht hat. Allerdings konnte ich einen anderen Bug finden, bei dem ich nicht ganz wei , ob er sich l sen l sst: Wenn man nicht auf "Stop Debugging" dr ckt, sondern einfach VICE schlie t und dann erneut den Debugger startet, ffnet sich ein VICE-Fenster bei den Breakpoints. Ich wei nicht, ob Sie (oder d rfen wir sie duzen? Ich bin mir da nie so ganz sicher) davon schon wissen und ob man einfach nicht VICE schlie en sollte, denn wozu ist dann der Knopf? _(ツ  _/ Kommentar von Endurion: Kann man gerne duzen Das muss ich mal nachstellen, was da schief geht. Eigentlich sollte auf das Gleiche rauskommen. VICE macht dann den Monitor auf, wenn die Remote-Verbindung nicht aufgebaut wurde. Dann steht vermutlich etwas wie "Debug Attempt failed" oder so im Output Display. |
| |
erstellt am 24. November 2020 um 12:32 Uhr MEZ Zu dem Kommentar vom 22. August 2020: Es w re sicherlich auch praktisch, wenn man zu jeder Zeit einfach alle Dateien einer Solution separiert abspeichern k nnte, sodass man, wenn man versehentlich einige Male zur ckgeht und dann etwas ndert und damit die Wiederherstellung nicht mehr funktioniert und das dann dummerweise speichert, man die alten Versionen durchw hlen kann, bis man die intakte alte Version der Datei findet und dann rumkopieren kann. Beim Arbeiten mit Arduino-Programmen habe ich mir immer einen Ordner f r das aktuelle Projekt angelegt und dann die gesamte "Solution" st ndig mithilfe von "Speichern unter" mit aufsteigenden Nummern abgespeichert, sodass sich eine Struktur wie /MeinProjekt MeinProjekt/v1 MeinProjekt/v1/v1.ino (die Hauptdatei bei Arduino-"Solutions") MeinProjekt/v2 MeinProjekt/v2/v2.ino MeinProjekt/v2/datei.h MeinProjekt/v3 MeinProjekt/v3/v3.ino MeinProjekt/v3/datei.h MeinProjekt/v3/konstanten.h MeinProjekt/v3/tabellen/sinustabelle.h usw ergeben hat, jedes Mal wurden die alten Dateien ber "Speichern unter" bernommen. Ich brauche das einfach, da ich ein riesiges Ma an Fehlern mache. Soweit ich das verstehe, geht das nicht so einfach mit Solutions. Au erdem ist es blicherweise so, dass bei "Speichern unter" man direkt zur neuen Datei springt, wenn man also v1.asm als v2.asm speichert und dann nderungen vornimmt und diese mit Strg+S speichert, diese in v2 landen. Ich hoffe, das war nicht zu komisch und ich hoffe auch, dass das nicht so wirkt, als w rde ich das Programm schlecht reden. Ganz im Gegenteil, es hat mir erm glicht, in einer sehr guten Entwicklungsumgebung Assembler zu lernen und ich bin begeistert. Es gibt nur ein paar kleine Dinge, die ich mir besser vorstellen k nnte. Gru Julian Kommentar von Endurion: Ah, da w rde ich in Richtung Source-Code-Verwaltung gehen. Es gab schon ein paar Anfragen in Richtung GIT. Ich berlege ernsthaft, ob ich das einbaue. Das d rfte aber noch ein bi chen dauern |
| |
erstellt am 23. November 2020 um 19:36 Uhr MEZ Hallo, ich wollte einen bug in der neuesten Version des C64 Studios melden: Debug Memory wird irgendwie nicht geupdatet ... man muss auf Add View (das gr ne +) dr cken, damit man die nderungen sieht, und das auch jedes Mal. Das herauszufinden hat mich leider eine Stunde oder so gekostet. Sonst aber ein klasse Programm. Hut ab! Gru Julian Kommentar von Endurion: Danke f r die Info, da gucke ich mal, was ich verbastelt habe. Als Tipp, ein Scrollen im Fenster sollte eigentlich auch einen Refresh erzwingen. |
| |
erstellt am 08. November 2020 um 22:42 Uhr MEZ Hey dude, Hope you're well. I just updated from 6.4 to 6.5 but the status bar at the bottom of the screen says "Malformed update check reply: < br />" Right before I updated 6.4, the status bar just said "checking for update..." but gave no further info. Thanks for a new version! Wouter Kommentar von Endurion: Thanks! There was a PHP upgrade that threw a few warnings, it's fixed now. |
| |
erstellt am 25. September 2020 um 6:23 Uhr MEZ Hi Georg, Will C64 Studio will be forward compatible with MEGA 65 by Trenz Electronics? Which is being released later in 2020! thanks Syed Kommentar von Endurion: Hi Syed, Depends on what you need of it C64Studio is set to the 6510 processor, I haven't tried to use it with Mega65. It's features are all mostly matching the C64s capabilities though. Purely assembling and starting should work without problems though. For debugging you'd need a interface. |
| |
erstellt am 22. August 2020 um 20:49 Uhr MEZ Hallo Georg, danke f r das C64-Studio - macht richtig Spa Leider hat es bei mir gerade beim Suchen&Ersetzen den kompletten Inhalt einer asm-Datei gel scht - frei nach Murphy nat rlich die, an der ich gerade stundenlang gearbeitet hatte  Und so wie es aussieht, ist tats chlich alles weg  Ich h tte da einen Vorschlag: Wie w re es, wenn das Studio in regelm igen Abst nden eine Sicherheitskopie anlegen w rde - so eine Art AutoSave? Dann k nnte man im Fall eines Falles noch was retten. Nochmals vielen Dank f r Deine Arbeit am Studio. Bye, Jens Kommentar von Endurion: Aua, verdammt, das sollte einfach nicht passieren! Die Option mit Autosave kommt sofort auf die Liste, tut mir echt leid! |
|
erstellt am 31. Mai 2020 um 9:05 Uhr MEZ DPI... Was at 125% in 1920x1200 (16:10) I could try it on my 27", that one runs 2560x1440, not sure about the DPI on it And it'sn not only the 'zoomed' pixel window that is strange, also the selected char is 'out of sync' in the char selection, and the blue 'square' that marks the selected char is also smaller than normal, maybe it's 25% smaller, I guess it's actually at 100%, but since the rest was at 125% it will look smaller. DPI = 100% is recommended to use I guess. Kommentar von Endurion: Thanks for checking back! I'll try to check that, maybe I need to actually restart with the other DPI setting to see the effect. |
|
erstellt am 30. Mai 2020 um 19:41 Uhr MEZ DPI settings... Thanks for the tip! Mine was set at 125%, and changing it to 100% fixed the problem with the char editor. I would never have figured that out javascript:setsmile('  ')Kommentar von Endurion: Nice to know it works. Weird though, I couldn't reproduce the problem even with changed DPI settings. Do you maybe have a really high resolution? I know StretchBlt fails after a certain sizing factor. And in this case I'm scaling a 8x8 image. |
| Administration | |