Beiträge von atomcode

    Was ich am Anfang beim VICE-Monitor gerne gewusst hätte, aber erst sehr spät gelernt habe: Ich hatte den, wenn ich den C64 weiterlaufen lassen wollte, immer mit 'x' geschlossen. Das war recht nervig, weil man dann den Monitor immer wieder öffnen und schließen muss. Irgendwann hat mir jemand verraten, dass man mit 'g' auch den C64 weiterlaufen lassen kann, aber ohne dass sich das Monitor-Fenster wieder schließt. (Keine Ahnung, ob das jetzt jemandem hilft, aber ich wollte es mal loswerden.)

    Das folgt wohl daraus, dass jeder Monitor-Befehl ohne Angabe von Parametern da weitermacht, wo er zuletzt aufgehört hat. Für 'g' ist das der CPU-Counter. Gibt man eine Adresse für 'g' an, bleibt das Fenster auch offen. Der Nutzen hält sich allerdings in Grenzen, da man währenddessen im Monitor ja nichts mehr machen kann. Wenn ich ihn beende, ob mit 'x' oder durch Schließen des Fensters, und dann wieder aufrufe, wird bei mir (V3.7) das Fenster mit dem letzten Inhalt wiederhergestellt. Daraus folgt, dass der einzige Vorteil des "G-Tricks" der ist, dass man den letzten Inhalt des Fensters noch sieht. Aber ok, das kann natürlich auch nützlich sein.

    die Anzeige gibt dir Aufschluss darüber was zu einem bestimmten Zeitpunkt für Werte vorlagen

    Aber dann sollte man es davor platzieren. Mich interessiert nach einem Befehl ja nicht mehr vorrangig, was davor war, sondern was der macht und bewirkt, und wenn ich doch den Wert davor wissen will, könnte ich das in der Zeile davor lesen. Ich lese den Code ja so, dass ich dabei denke, was gerade passiert, und nicht, was passieren soll, und nach einem LDA #$07 habe ich gedanklich im Akku eine 7 und nicht den Wert davor.


    Man will ja mit einem Debugging-Werkzeug etwas erreichen, und da habe ich es lieber pragmatisch orientiert. Das Gleiche mit den Taktzyklen, die ganz am Ende stehen, wo dann augenscheinlich nach einem JMP 2 TZ dazugekommen sind. Das irritiert total und ist m.E. wenig hilfreich, es so zu machen. Endurion hat es ja auch richtig gemacht: Da stehen die Werte sogar davor, und zwar die, die sich auf den jeweiligen Befehl in derselben Zeile beziehen, also bei einem JMP 3 TZ. Überall und jedes Mal am Ende der nächsten Zeile zu schauen, was der Befehl am Anfang der vorherigen Zeile bewirkt hat, da wird man ja bekloppt, und es fördert nur die Chance, sich damit zu verhauen.


    Oder anders gesagt: Wenn man das technisch so genau nehmen will, dann dürfte man den kompletten Befehl selbst auch noch nicht hinschreiben, weil im CPU-Counter der Wert nach dem Lesen des letzten Befehls gerade erst auf den neuen Wert gestellt wurde und das Lesen und Ausführen des nächsten Befehls erst ansteht, genauso, wie die Beeinflussung der Flags durch die Ausführung des Befehls noch ansteht. Beides gleichermaßen Dinge, die passieren, bevor der CPU-Counter auf den nächsten Befehl zeigt. Und die nächste Adresse steht eben erst in der nächsten Zeile. Darum gehört m.E. nicht nur pragmatisch gesehen, sondern sogar technisch gesehen alles in dieselbe Zeile, alles, was passieren wird bis zum nächsten Befehl.

    Dass der neue VICE-Monitor nur noch ein Fenster hat, ist natürlich schade. Und dennoch nutze ich jetzt den und kontrolliere Speicherbereiche dann eben mit dem M-Befehl, und die Register mit R. Da ich jahrelang nur mit der AR6 debuggt hatte, kann ich damit leben. Und bei der CPU-History sehe ich ja, wann und wo was in den Speicher geschrieben wird, und Statusregister und Stackpointer werden da auch angezeigt. Wenn mich ein Lese- oder Schreibzugriff in einem bestimmten Speicherbereich oder das Aufkommen eines bestimmten Wertes an einer Stelle interessiert, kann ich dafür einen Watchpoint setzen.


    Was an der Darstellung der CPU-Register in der History absolut nervt, ist, dass hinter jedem Befehl die Werte von vor dem Befehl angezeigt werden. Wenn also z.B. der Akku eine 5 enthält und dann da steht LDA #$07, dann wird dahinter als Akkuinhalt noch die 5 angezeigt, obwohl er nach dem Befehl doch eine 7 enthält.:facepalm:Da muss man immer umdenken und aufpassen, wenn z.B. nach einer Operation der Akkuinhalt nicht sofort offensichtlich ist.


    Es gibt im VICE-Monitor ja auch noch zusätzliche äußert hilfreiche Funktionen, z.B. die CPU-History. Oder die Stopwatch, um Ausführungszeiten zu messen. Status-Flags kann man mittendrin per "R FL = %xx1xxxxx" ändern, z.B., um den Interrupt zu pausieren.

    Ist später auch mal ein Darkmode für die IDE geplant?

    Du kannst in den Einstellungen bei Environment->Colors->Import Here eins der vorgefertigten Themes einladen, da gibt's auch eins für Dunkel.

    Ich glaube, er meint eher die GUI, die man noch nicht so wirklich auf Dunkel trimmen kann. Ich habe bei mir versucht, das über die Farbkonfiguration zu lösen. Aber das funktioniert nur mehr schlecht als recht, weil man nicht alle Elementarten unabhängig voneinander färben kann. Dazu gibt es noch das Problem mit den Icons, die auf dunklem Grund teils verschwinden. Wäre cool, wenn die nicht einkompiliert würden, sondern extern als streifenförmiges Icon-Image abgelegt wären. Dann könnte das jeder für sich ohne zu Kompilieren ändern und austauschen. Wenn man in den Color-Theme-Settings dann noch den Pfad dahin angeben könnte, bräuchte man das nach einem Update nicht mal erneut zu ersetzen. Mit meinen derzeitigen grauen Farbeinstellungen (dunkler geht nicht, weil auch mancher Text schwarz bleibt) kann ich zwar leben, aber dadurch sind ausgegraute Menüpunkte leider völlig unsichtbar geworden.


    Nach dem Pressen mit einem Heiluftfön über die Stoßverbinder rüber

    Cool, Stoßverbinder und die entsprechende Zange habe ich zwar, aber dass es die auch mit Schlumpfeffekt gibt, wusste ich noch nicht. :thumbup:


    Ich war schon am Überlegen, ob ich in die Unterseite des Kunststoffgestells ein Zugangsloch schneide und danach wieder zuklebe. Hatte es aber mit verschiedenen Zangen und viel Fummelei geschafft. Da zahlt sich das frühere Geduldstraining aus einer Zeit mit Datasette und Kugellabyrinth nochmal aus. :)


    Jetzt hatte ich ja oben gemeckert, dass vieles heute so schlecht reparabel ist. Aber immerhin kann ich positiv hervorheben, dass bei dem Schlauch, der von irgendeiner AEG-Maschine (DE) stammt, während die Zielmaschine von Gorenje (Sitz in SL, hergestellt in DK) ist, der Durchmesser des Außenschlauchs und der Anschlussmuffe des Innenschlauchs und auch die Art und Größe der Kabelschuhe direkt passend waren, was die Sache wiederum erleichtert. Nur die hintere Durchführung musste ich etwas bearbeiten und zwei kleine Löcher ins Gehäuse bohren.


    Für eine freie Marktwirtschaft mit vielen Konkurrenzprodukten ist das schon nicht schlecht, und da geht sicherlich noch mehr, z.B. eine Norm, die beschreibt, dass die wichtigsten internen Kabelenden bis mindestens an die Geräte-Außenkante ausgelegt werden können, sofern sich das Gehäuse nicht ausreichend eröffnen lässt. Hätte ich eine Zeitmaschine, würde ich in der Vergangenheit dafür sorgen, dass ein solches Gesetz erlassen wird, dann wieder nach 2025 zurückreisen, und schwupp, sind die Kabel länger und in wenigen Sekunden mit dem Stecker verbunden. Gruß an alle DOTT-Freunde. ;)

    Und an dem Beispiel kann man dann auch schön sehen, dass es auch von den konkreten Daten abhängt

    Genau, und bei solchen Dingen wie mit den zu erwartenden Daten muss man beim Programmieren auf jeden Fall selbst mitdenken. Wenn ich z.B. weiß, dass die Daten gar nicht größer als 39 werden können, frage ich das auch nicht ab. Ich denke aber, dass das in der Regel nur der Autor wissen kann. Empirische Daten, und wenn sie auch 1000-mal hintereinander unter 40 liegen, sind keine Sicherheit. Und einer KI würde ich diese Entscheidung, ob ich "< 40" abfragen muss, auch nicht überlassen.


    Diese Überlegungen sind primär das, was ich mit "algorithmischer Optimierung" meinte. Vielleicht sollte man dabei eher von "semantischer Optimierung" sprechen. Es war ja nicht unbedingt gemeint, dass man erst einen komplett neuen Floodfill-Algorithmus oder ähnlich erfindet.

    Ist das nur beim VIC so, oder gibt es diesen Effekt bei den anderen Chips auch?

    • Da nur die Adressleitungen A0-A4 am SID anliegen, wiederholen sich die SID-Register alle 32 Byte (hexadezimal $20) im verbleibenden Adressbereich $D420-$D7FF.
    • Mit Hilfe der Adressleitungen A5-A9 kann dieser verbleibende Bereich für Erweiterungen genutzt werden. Beliebte Adressen für einen zweiten SID sind z.B. $D420 oder $D500.

    Also VIC = $D000 bis $D3FF (16 * 2^6 Byte), SID = $D400 bis $D7FF (32 * 2^5 Byte), dann Farb-RAM ab $D800.

    Gerade den Schlauch für die SpüMa aus der Packstation geholt. Werde ich jetzt noch einbauen.

    Hier noch ein paar Bilder.



    Die Kabelschuhe auf den Stecker zu bekommen, war das schwierigste. Das Kunststoffunterteil der Maschine ist aus einem Guss und lässt sich nicht weiter öffnen, keine Serviceklappen auf der Unterseite, und die Kabel sind so kurz, dass man sie nicht weiter herausziehen kann. Ein paar cm mehr hätte es erleichtert. Die Pumpe sitzt irgendwo mittendrin. Keine Chance, die auszutauschen, wenn die hin wäre. Man merkt es immer wieder: Es soll gar nicht repariert werden.


    So, Blech drauf, noch mal laufen lassen, putzen, Ebay.


    Die neue Maschine lebt übrigens fast von Luft und Liebe. 0,55 kWh pro Eco-Durchgang waren angegeben; gemessen hab ich unglaubliche 0,43 kWh. Randvoll, Töpfe und Glas gleichzeitig, alles nach 2 Std. picobello sauber.

    TD1334 und berni Kann man Eure Geschwindigkeitsmesser irgendwo bekommen? Womöglich mit Quellcode? Wollte so was selbst mal machen, für den Kassettenpuffer, SYS X für Start und SYS Y für Stopp, und mit einem Parameter, der angibt, ob dabei Interrupt und/oder VIC abgeschaltet werden sollen. Ich weiß ja nicht, wie Ihr das gemacht habt.