Erstellt: 13. März 2013 (zuletzt geändert: 28. November 2018)

Systemfehler!

Wo einem die Hardware in die Quere kommt!

C64 Studio, AMCE & TASM

Man mag es nicht glauben, aber schon vor dem Pentium-Bug gab es Fehler in der Hardware und auch der C64 blieb davon nicht verschont.

Zero-Page-Adressierung

 ldx #$0a
 lda $ff,X

Der obige Code lädt nicht das Byte von $ff + $0a = $0109 in den Akku, sondern von $09!!

Das liegt daran, dass der 6502/6510 nur das LSB betrachtet.

Man kann mit einer indizierten Zero-Page-Adressierung also die Zero-Page nicht verlassen!

Da diese Adressierung dynamisch verläuft, kann euch der Assembler auf diesen Fehler leider nicht aufmerksam machen.

Die Firma Western Design Center hat einen zum 6502 kompatiblen 16-Bit Nachfolger (den 65816) entwickelt. Dort wurde dieses Verhalten korrigiert. Diese 65816-CPUs sind in sofern interessant, da sie in den SuperCPU-Karten für den C64 verwendet wurden.

Indirekter Jump-Befehl

 jmp ($c0ff)

Bei der indirekten Adressierung, nur beim JMP-Befehl möglich, wird oben zwar das LSB von $c0ff geholt, aber das MSB kommt nicht, wie man eigentlich erwarten würde, von $c100, sondern von $c000!!

Eine indirekte Adressierung beim JMP geht schief, wenn die „Quell-Adresse“ über eine Page-Grenze verläuft!

Im Gegensatz zu eben, ist diese Adressierung eindeutig und ein Assembler kann euch eine entsprechende Warnung anzeigen. Das C64 Studio, ACME und CBM prg Studio machen dies, der Turbo Assembler allerdings nicht.

Anzeige im C64 Studio.
Anzeige im C64 Studio.

Auch dieser Fehler wurde beim 65816 korrigiert!

Falsche Flags im Dezimalmodus (BCD)

Wenn ihr im BCDinfoInfoBinary Coded Digit-Modus rechnet, dann müsst ihr bei einigen Flags aufpassen.

Das Negativ- und OVerflow-Flag wird anhand des Binärwertes, also vor der Umwandlung ins BCD-Format, gesetzt.

Daher führt z. B. eine Addition von %10001000 + %01000000 im BCD-Modus zum Ergebnis %00101000 bei gesetztem Carry-Flag. Soweit ist noch alles korrekt, aber auch das N-Flag wurde gesetzt, was überhaupt nicht passt!

Dieser Fehler wurde ebenfalls beim 65816 korrigiert.

Nur zur Info

Für uns als Assemblerprogrammierer sind die drei Punkte von eben (besonders die ersten beiden) extrem wichtig. Es gibt aber durchaus noch weitere Fehler im C64, auf die man stossen kann.

Hier noch zwei Beispiele:

  • Der „Knackser“ im ersten SID 6581.
    Dieser wurde von den „Soundmagiern“ aber zu ihrem Vorteil genutzt, so dass es später beschwerden gab, als ab 1985 der neue SID 8580 verbaut wurde und die Sounds nicht mehr wie gewünscht klangen.
  • Auch die ersten beiden ROMs hatten so ihre Fehler.
    Rev. 1 wies schwerwiegende Fehler auf: Der Rechner neigte dazu, bei bestimmten Farb- oder Tastenkombinationen hängen zu bleiben! Von Commodore wurde Rev. 1 daher zügig durch Rev. 2 ersetzt, allerdings war man dort evtl. etwas zu flott und erst mit Rev. 3 (wurde mit Abstand am häufigsten verbaut) lief der C64 zuverlässig.
    Wer seinen C64 überprüfen möchte, der gibt einfach direkt nach dem Einschalten POKE 1024,1 ein. Erscheint oben links ein weißes A, handelt es sich um Rev. 1, erscheint kein A (es ist natürlich da, es hat nur die selbe Farbe wie der Hintergrund) handelt es sich um Rev. 2. Da die Meisten, wie erwähnt, Rev. 3 besitzen, wird aber, wie erwartet, ein hellblaues A auftauchen.

Schrott!!Naja...Geht so...Ganz gut...SUPER! (2 Bewertungen | Ø 5,00 von 5 | 100,00%)

Loading...


Zurück

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

Protected by WP Anti Spam