Systemfehler!

Für diesen Beitrag wurde das CBM prg Studio verwendet.
weitersagen ...
Tweet about this on TwitterShare on FacebookShare on Google+Share on LinkedIn

CBM prg StudioWo einem die Hardware in die Quere kommt!

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

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 das CBM prg Studio auf diesen Fehler leider nicht aufmerksam machen. Der Debugger des prg Studios führt den Befehl allerdings korrekt aus.

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

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 das CBM prg Studio zeigt euch eine entsprechende Warnung an.

JMP ($C00FF)

Der integrierte Debugger vom CBM Program Studio führt den Befehl übrigens korrekt aus und auch beim 65816 wurde das 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!

Auch dieser Fehler wurde 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 |

 

weitersagen ...
Tweet about this on TwitterShare on FacebookShare on Google+Share on LinkedIn

Schreibe einen Kommentar

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

Protected by WP Anti Spam