Beiträge von Mac Bacon im Thema „Sammelthread: Lernen aus Fehlern“

    2) BRK und IRQ können exakt gleichzeitig auftreten. Dann wird nicht mal im Statusregister das BRK gekennzeichnet.


    Wegen 2) denke ich, dass ich den BRK gar nicht sicher erkennen kann.

    Dieser konkrete Fall ist tatsächlich gar nicht problematisch, denn der BRK wird ja dann nach der Ausführung des IRQ abgearbeitet. Wenn man BRK stabil bekommen möchte, muss man aber auch im NMI-Handler das BRK-Flag ansehen und ggfs. beachten!

    Achtung: Ich gebe nur wieder, was meine eigenen Experimente ergeben haben- ich behaupte nicht, dass BRK 100% sicher nutzbar ist. :D

    DAVON bin ich wieder abgekommen, weil es meiner Meinung nach den Code eher hässlich aufbläht/auseinanderreißt ohne einen echten Mehrwert zu bieten.

    Hässlich ist es auf jeden Fall, aber es bietet durchaus einen Mehrwert: Die Referenzen sehen so aus wie sonst auch, d.h. "+1" kennzeichnet einen Zugriff auf das High-Byte. Nimmt man stattdessen das Label vor dem Befehl, wird das Lowbyte mit "+1" und das Highbyte mit "+2" referenziert.

    Dass "+1" in meinen Sources immer die gleiche Bedeutung hat, ist mir die Hässlichheit der Labeldefinition wert.

    EDIT: Um on-topic zu bleiben: Ein beliebter vermeidbarer Fehler ist, mit "+1" bei manchen Variablen das Low- und bei manchen das High-Byte zu referenzieren. :D

    Die Textdateien sind wohl Windows 1252, werden aber als UTF-8 interpretiert.

    Das ist... seltsam. Die kompliziertere Kodierung bei UTF-8 gegenüber 1252 oder ISO o.ä. hat nämlich auch einen großen Vorteil: Man kann sofort erkennen, dass eine Datei nicht in UTF-8 kodiert ist, denn jeder einzelne Umlaut in 1252- oder ISO-Kodierung verletzt die UTF-8-Kodierung. Es ist also sehr einfach, direkt nach dem Laden eine entsprechende Meldung anzuzeigen.