Die Binaries sind ja sogar im Paket enthalten. Es wäre eigentlich sinnvoll, den Download Dateien einen anderen Namen zu geben als "source code".
Aber für Windows-Leute ist es halt schon ein wenig ungewohnt, dass die Programmdatei irgendwo in einem Unterverzeichnis sitzt.
Ist ja bei VICE dasselbe, erschwerend dort ist noch, dass in dem BIN Folder zusätzlich Dutzende von DLL's sind.
Bei mir klappt das Login unter Windows.
Was mir aufgefallen ist in letzter Zeit: Der CSDB Browser lässt sich beim 1. Aufruf anfangs vieeeeeeeeeeel Zeit.
Seltsamerweise geht es gleich darauf bei erneutem Aufruf massiv schneller. Selbst wenn ich aus- und wieder einlogge.
Hat wohl mit der VICE Implementation gar nichts zu tun...
- Clocks --> laufen
- Google Maps --> läuft
- RSS --> läuft
- Telnet --> läuft
- Shotgun --> läuft
Nur Kurztests allerdings.
Die VICE Leute haben die Paletten bereits geklaut. 
Das konnte man übrigens auch schon früher, unter WinVICE bis 3.x z.B. in der win_shortcuts.vsc
KEY 0x78 IDM_CART_FREEZE F9
Nur als Info, es soll ja Leute geben die noch an älteren VICE Versionen (vor GTK3) hängen.
Hat jemand einen Torrent davon gesichtet?
//edit: ok, ich mach das jetzt halt per Batch-Download der Links im Beitrag direkt über mir.
Hm. Wusste gar nicht, dass der C128 sowas hat.
https://vice-emu.sourceforge.io/vice_toc.html#TOC20
Da ist jedenfalls auch nichts.
Kann man diesen Monitor eigentlich auch mit der SCPU benutzen?
Die Befehle usw. werden ja korrekt angezeigt, aber weiter als bis hex FFFF kann man ja gar nichts anzeigen. Was soll ich da mit z.B. JSR $3300AA?
Da sitzt eben jeder irgendwo auf einem Berg.
ZitatDa hätte noch viel Arbeit reingehört.
Hm ja. "go to address" tut ja nicht wirklich was... Ich wollte das irgendwie beheben, ist aber nicht ganz trivial. Stinknormale Adressen zwar schon, aber das ganze indizierte Zeugs. 
Die Datei öffnen Dialoge sind einfach überzeugender. Und wenn ich keine neuen Features der Versionen 3.3 und Neuer brauche, warum nicht?
Bei Geos muss man relativ oft Disketten wechseln, da macht das was aus, ob man beim erneuten Wechseln automatisch im letzten Verzeichnis landet oder sich erst durcgklicken muss.
Ok, ist ein Argument. Das ich ja auch verstehe.
Weil die nachfolgenden Versionen nur noch einen Linux-like Kommandozeilen-Debugger haben, während die native Windows-Version einen Fullscreen-Debugger mit vielen Fenstern hatte? So wie Windows-User das eben von einem Debugger erwarten.
Natürlich wirst du jetzt wieder erwidern, dass ein Kommandozeilen-basierter Debugger völlig ausreicht. Da gilt aber nur für Linux-User, die nichts anderes kennen.
Äh nein, ich habe ja bloss Fragen gestellt...
Aber hallo, ich benutze load und store breakpoints gerne, wenn ich wissen will, welcher Code-Teil mir irgendwo Speicher zerschreibt. Dafür ist das genial. Besonders, weil man auch Adress-Bereiche angeben kann.
Aber eben dann wäre es doch auch nett, wenn die erwähnten "vielen Fenster" auch load und store breakpoints anzeigen täte, und man die dort auch setzen könnte.
Man könnte argumentieren, dass man load und store eher nicht in der Disassembly-Ansicht benötigt, sondern auf Labels oder Adressen setzt, wofür sich eine Texteingabe anbietet.
Mag ja sein, ich finde es trotzdem schräg, wenn im Disassembly nur die execute breakpoints angezeigt werden.
Der graphische Debugger war nie fertig und nie "kundentauglich". Er war nur versehentlich in einem Release aktiv geworden, weil jemand
vergessen hatte, vor dem Einchecken das passende #define zu entfernen, um ihn zu deaktivieren.
Das dürfte wohl meine Fragen beantworten. Inzwischjen habe ich auch gesehen, dass es in der v2.3 noch gar keine "load and store" breakpoints gab, und niemand diese einbauen wollte.
Da hätte noch viel Arbeit reingehört.
Das ist Schade.
Nachtag: Übrings mit WInVICE 3.2, per textueller Befehle.
Weshalb denn eigentlich WInVICE 3.2? Das hätte dann ja auch mit neureren Versionen funktioniert?
Im alten nativen WinVICE konnte man ja im Monitor-Disassembly Fenster auch mittels Maus Breakpoints setzen.
Aber eben nur "normale exec" Breakpoints. Daneben gibt es ja aber auch noch "load" und "store".
Zitat`load|store|exec' ist entweder `load', `store' oder `exec' (oder eine
Kombination) und dient zur Angabe, bei welcher Operation der Monitor
anhalten soll.
Diese werden aber im "Disassembly" Fenster weder angezeigt noch kann ich sie setzen.
Ist das einfach "nicht fertig" oder braucht man "load" und "store" zu selten?
Ich habe das nie benutzt, ist mir einfach (erst jetzt 
) aufgefallen.
alls Ihr (so wie ich) einen alternativen WiC64 Server in den Settings abgespeichert habt und dann doch mal wieder auf's Portal wollt,
Man kann diese Sachen ab jetzt im GUI einstellen, getestet hab ich es nicht.
Müsste %appdata%/vice/vice.ini sein.
Das ist in der Tat das Standardverzeichnis.
Allerdings kann die vice.ini auch im Programmordner selber liegen, die wird dann "bevorzugt" verwendet.
Hier gibt es auch wieder das Problem. Starten von WinVice xscpu64 --> Menüprogramm ist da. Reset, kein Autostart mit Menüprogramm (geht auf normale C64 Einschaltmeldung). Wieder Reset, Autostart mit Menüprogramm ist wieder da, usw..
Das sollte gefixt sein in [r44566]
Scheint irgendwie ein Linux Problem zu sein? Was aber schon eher seltsam wäre, sind doch die Entwickler alles Linux-Leute.
https://sourceforge.net/p/vice-emu/bugs/1940/
Kann das unter Windows nach wie vor nicht reproduzieren.
Hier gibt es auch wieder das Problem. Starten von WinVice xscpu64 --> Menüprogramm ist da. Reset, kein Autostart mit Menüprogramm (geht auf normale C64 Einschaltmeldung). Wieder Reset, Autostart mit Menüprogramm ist wieder da, usw..
Hat eventuell was hiermit zu tun: https://sourceforge.net/p/vice-emu/bugs/1949/
Ich hab mal vorübergehend für mich das so "behoben" dass c128ramlink_switch_mode nur ausgeführt wird im x128, nicht aber in allen anderen Emus. Der Bug ist so weg.
Wird wohl nicht lange dauern bis da ein richtiger Fix kommt.
Markiere ich unter Settings/Peripheral Devices/Drive 9 --> "IEC Device" an (True Drive Emulation ist auch gesetzt), dann bleibt auch bei jedem Reset, das LW 09 erhalten. Habe ich jetzt erstmal so gelassen. Die anderen Vicestarter x64sc + x128 funktionieren, auch wenn "IEC Device" nicht markiert ist.......
Wie erhalten?
Eben getestet mit 3.6.1 und 3.7 unter Windows mit meinem billig-Gamepad (XEOX), bei mir klappt alles wie gewünscht.
Sowohl Feuerknöpfe als auch alle Richtungen zeigen keinerlei Auffälligkeiten, getestet mit Joyride 1.6
Habs auch mal ein wenig (also nicht sehr gründlich) getestet in VICE, keine Probleme festgestellt.
Das war ja auch nur ein Vorschlag, ich selber bin ein Fan von symbolischen Keymaps, da bei mir die Zeiten am realen C64 Jahrzehnte zurück liegen.
Wie wäre es hiermit?
So erreicht man Cursor Tasten neben SHIFT indem man SHIFT + Cursor Taste drückt...So bleibt die ofizielle Zuordnung unverändert.
Man kann ja eigentlich fast alles machen... Anstelle von SHIFT könnte man auch ALT-GR oder CTRL nehmen.
/Edit: Geht natürlich auch umgekehrt, Cursor Tasten OBEN mit SHIFT.
Hier benötigt man auch keine spezielle Zuordnung mehr für den C64-Modus.
