Re: 264 kernals, bugs, ntsc hack, etc.

From: William Levak <wlevak_at_SDF.ORG>
Date: Tue, 6 Sep 2011 04:57:18 +0000 (UTC)
Message-ID: <Pine.NEB.4.64.1109060451240.17917@sdf.lonestar.org>
On Mon, 5 Sep 2011, Gerrit Heitsch wrote:

> On 09/05/2011 08:43 AM, William Levak wrote:
>
>> 
>> If you assemble a one byte op code, there is no problem. It's the 2 and
>> 3 byte op codes that cause the problem. The format of the operand is
>> stored at $79-. If you assemble
>> 
>> LDA $5678
>> 
>> then $0000 is stored at $79-7D, hex "24 30 30 30 30". If the operand is
>> a constant instead of an address, as in
>> 
>> LDA #$00
>> 
>> then #$00 is stored at $79-7C, hex "21 24 30 30". For operands with
>> parenthesis, they are dropped, as in
>> 
>> LDA ($78),Y
>> 
>> Then $00,Y is stored at $79-7D. This gives two combinations for $7A-7B;
>> "24 30" and "30 30". This results in either $304C-4D or $3058-59 being
>> written over.
>
> Hm... So the problem is that $79 contains something non-zero at the wrong 
> moment. Is it possible to prevent the bug from causing problems if the first 
> command after exiting the monitor is 'CLR'? It does write a zero to $79. Or 
> does 'CLR' also trigger the bug?

One byte op codes do not change $79-.  If you had "30 30" at $7A-7B, it 
remains there.

The safe thing would be to zero out $79-7B before exiting.




wlevak@sdf.lonestar.org
SDF Public Access UNIX System - http://sdf.lonestar.org

       Message was sent through the cbm-hackers mailing list
Received on 2011-09-06 05:00:03

Archive generated by hypermail 2.2.0.