"Stabile" illegale Opcodes auf dem C64

Nein, der Thread ist nicht alt; die Zeit vergeht nur zu schnell.

Oxyron schrieb, man solle vom guten alten "LAX #$xx" ($AB) die Finger lassen, weil er instabil sei. Im PDF "NMOS 6510 Unintended Opcodes - no more secrets" steht es genauer. Es passiert A,X:= A OR (UnbekannterWert) AND Operand. "LAX #$00" geht also ohne weiteres und ist wahrscheinlich der häufigste Anwendungsfall. Hatte ich damals beim GCR-Decoden in der Floppy benutzt. Ansonsten muss vorher der Akku #$FF enthalten; dann klappt es auch mit anderen Werten. Genauer gesagt: Mindestens die Bits, die mich interessieren, muss ich im Akku auf 1 setzen, damit sie dann analog zum Operanden nach A und X kopiert werden. Geht es bspw. nur ums untere Nibble, reicht es also, wenn A vorher #$0F war. Ein LAX #$05 würde in dem Fall immer Akku und X mit #$05 versehen, weil #$0F OR (WasAuchImmer) AND #$05 stets #$05 ergibt.

retro-programming.de geht bei dem unbekannten Wert von #$EE aus. Das trifft auf VICE zu, aber nicht auf jeden echten C64. Diese Angabe kann man also zum Programmieren nicht gebrauchen.

Ich denke, "legale" Programmiertricks durch gute Überlegung bringen meistens sowieso viel mehr.

Zitat von atomcode

retro-programming.de geht bei dem unbekannten Wert von #$EE aus. Das trifft auf VICE zu, aber nicht auf jeden echten C64.

Wenn Du die letzte Aussage belegen würdest, wäre Dir groepaz vermutlich sehr dankbar.

>"Das trifft auf VICE zu, .."

Nach LDA #$00 : LAX #$FF befindet sich bei VICE stets $EE in Akku und X.

>".., aber nicht auf jeden echten C64."

Die Aussage stammt von groepaz selbst:

Zitat von groepaz

Do not rely on this value! It may not be stable even on the same chip and depend on

temperature and/or the supplied voltage.

bestätigt durch Oxyron:

Zitat von Oxyron

note to LAX: DO NOT USE!!! On my C128, this opcode is stable, but on my C64-II it loses bits so that the operation

looks like this: ORA #? AND #{imm} TAX.

Zitat von atomcode

Die Aussage stammt von groepaz selbst:

Du hast aber schon die aktuelle Version des Dokuments (von Weihnachten 2020) und das Kapitel auch zuende gelesen?

v0.92 - 24/12/17 meh

Kann kaum glauben bzw. hätte nicht gedacht, dass sich so etwas jetzt noch in der Erkenntnis geändert hat. Muss also erst mal wieder lesen. Da bin ich aber gespannt.

<edit>

So, gelesen, und ehrlich gesagt, überzeugt mich das noch nicht.

Dass der Abschnitt jetzt einen Widerspruch darstellt, weil er den alten Teil nicht überarbeitet hat, ist eine Sache, aber dass allein Wizball der Beweis sein soll, da bin ich skeptisch. Ich werde mir den entsprechenden Code von Wizball auch noch ansehen. Was ist mit der Aussage von Oxyron, die genau dazu passt? Ein einziger Rechner, der sich anders verhält, würde mir reichen, um davon Abstand zu nehmen. Und die Aussage von ihm selbst: "CONST is chip- and/or temperature dependent (common values may be $ee, $00, $ff,…)" .. Wie kam er denn überhaupt darauf, wenn das plötzlich allein aufgrund von Wizball nicht stimmen soll?

Oder warum machen wir nicht einfach mal eine Umfrage hier im Forum. Die Konstante ist ja ganz schnell ermittelt. Wäre doch mal spannend.

Die CPU kommt in Wizball bei $B589 vorbei, sobald man im Get-READY-Screen den Feuerknopf drückt. Ich habe dort sowohl "LDA #$FF" vor dem LAX ausprobiert, sodass nach dem LAX ein $FF in A/X steht, als auch ein "LAX #$00" nach dem LDA, sodass ein $00 in A/X steht. Egal, was man dahin schreibt, einen Unterschied in der Ausführung des Spiels ließ sich nicht ansatzweise bemerken. Das heißt, das Spiel ist an dieser Stelle nicht auf ein $EE in Akku oder X angewiesen.

Zitat von groepaz

and $EE really seems to be the one and only value to make it work correctly

Nö, Herr Groepaz, kann ich nicht bestätigen.

Schon der erste getestete echte C64 zeigt ein variables Verhalten, mit LDA #$00 zwar $EE, aber mit LDA #$0F nicht $EF, sondern $FF.

Es gibt nur zwei illegale Opcode die als wirklich instabil eingestuft sind, und zwar LAX und ANE mit anderen Werten als #$00. In einer Routine zum Spiegeln von Sprites im Multicolormode verwende ich ANE #%11001100, bei Emulatoren läuft alles glatt. Aber wie sieht das ganze auf echter Hardware aus, gibt es da Grafikfehler oder sind die doch hier und da stabil genug. Deshalb meine Frage, hätten einige Mal Lust das auf echter Hardware zu testen.

spritespiegeln.prg

Zitat von atomcode

Schon der erste getestete echte C64 zeigt ein variables Verhalten, mit LDA #$00 zwar $EE, aber mit LDA #$0F nicht $EF, sondern $FF.

Das passt doch zur Beschreibung im "No More Secrets"-Dokument, dem Befehl einfach so aus dem Monitor heraus auszuführen reicht nicht aus um alle Variablen zu kontrollieren:

Zitat von No More Secrets

CONST is chip- and/or temperature dependent (common values may be $ee, $00, $ff,...). Some dependency on the RDY line. Bit 0 and Bit 4 are “weaker” than the other bits, and maydrop to 0 in the first cycle of DMA when RDY goes low.

D.h. es gibt bekannte Einflüsse durch Badlines und die Chiptemperatur.

Auf den Monitor kommt es bzgl. meiner Aussage nach den Ergebnissen ganz offenbar nicht an, und allein um die Ergebnisse geht es ja.

Man kann auch den VIC abschalten und das Ergebnis irgendwo speichern und dann erst nachsehen: Vice verhält sich strickt nach A,X = (A | $EE) & #{imm}. Und echte Geräte eben nicht, Monitor und Badlines hin oder her. Meine Aussage war doch "xyz geht bei dem unbekannten Wert von #$EE aus. Das trifft auf VICE zu, aber nicht auf jeden echten C64."

(btw Das heißt um Gottes Willen nicht, dass ich recht haben muss oder will. Ich lasse mich gern eines besseren belehren, aber Gegen-Belegungen sehe ich auch noch nicht.)

Worum geht es jetzt genau? Dass die Aussage über Vice nicht stimme oder dass die Aussage zu den echten Geräten nicht stimme?

Und bitte hier weiter diskutieren und nicht über PN. Wir sind möglichweise nicht die einzigen, die das interessiert.

Abgesehen davon, dass ich nicht die Zeit habe, immer auf mehreren Hochzeiten gleichzeitig zu tanzen. Nichts für ungut.