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 for mat 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 $3059-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? Gerrit Message was sent through the cbm-hackers mailing listReceived on 2011-09-05 15:00:03
Archive generated by hypermail 2.2.0.