The problem is, its just not working like that. Now RUN and STOP work great, so I know jumping in and out the debugger is fine, and I have tested BRK instructions as well and they are okay too. Whenever I hit a break I subtract 2 off the PC (as its moved on entry to the interrupt routine), and I can then resume again.
So far so good.... but if I drop in some more BRK's, they don't seem to be getting hit properly at all. I can't of course debug the stub either so I'm left with just looking at code. I suspect I'll need to start a new, simple project to try and figure out why its not working, as staring at code doesn't seem to help.
So heres the loop Im trying to debug, and its interesting coz aside from not doing much, it shows up several issues.
58D1 CE 15 FF dec $FF15
58D4 A9 01 lda #$01
58D6 A2 02 ldx #$02
58D8 A0 03 ldy #$03
58DA EA nop
58DB CA dex
58DC D0 FC bne $58DA
58DE B9 00 10 lda $1000,y
58E1 88 dey
58E2 4C D1 58 jmp $58D1
First, if I try and single step $58DA, the whole thing dies a horrible death. IF I try and step $58D6, then $FF15 is increased and Y is decreased to 1 (which is impossible).
Its all very odd, but there must be a logical solution - somewhere!
4 comments:
I was pretty sure that BRK, while a 2-byte opcode (ie. BRK with immediate operand), pushes only the PC+1 onto the stack, so the interrupt service routine can have more direct access to the operand.
RTI is supposed to add the other 1, as I recall. In your case, you might have to mess with the stack to recover with a jump. This probably doesn't explain your problem though. Are interrupts still operational ? Are you replacing the original opcode (+1 byte) back when you hit the BRK ?
Not quite enough information...
Whoops, I had that a bit wrong. 1-byte opcode, and the PC on stack skips a 'signature' byte.
Aah, stop writing its when it's it's in your blog dammit ;)
Thats right, BRK adds 2 to the PC address on the stack, but RTI pops the address directoly (unlike RTS).
http://6502.org/tutorials/6502opcodes.html#RTI
I know its returning to the correctly place because if I code up
NOP
BRK
NOP
It then kicks into the debugger on the BRK okay, and because the stack is adjusted, it never gets any further because it keeps hitting the break. I'll have to test this further, but Im pretty sure this case is right. However... I really dont know why the rest of its not working yet.
Post a Comment