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. email@example.com SDF Public Access UNIX System - http://sdf.lonestar.org Message was sent through the cbm-hackers mailing listReceived on 2011-09-06 05:00:03
Archive generated by hypermail 2.2.0.