A bit more fiddling with the test program I shared yesterday and things are becoming clearer. We have a map of most of the basic operations:
So we can single step or trace a few instructions until we hit the RETURN, then the debugger seems to return to address $0127, picks up a HALT instruction and when this is run JzIntv aborts.
If we press Clear or 0 on the left controller there is a pause with no screen updates followed by JzIntv aborting. So I suspect that a similar thing is happening, perhaps the debugger is trying to run to a break point?
Other interesting bits and pieces. As we cycle the focus forward using the lower right action button, after the CPU flags a new field appears below BRKS. This allows the user to set one of 8 variables (A-H) to 0 or 1. I suspect this allows specific breakpoints to be turned on and off. I've not seen a way to set the breakpoint addresses yet. Cycling on past these A-H variables causes the field to disappear again.
The left side of line 5 is confirmed to be a memory inspector / adjuster. When they have the focus it is possible to change both the address being inspected (which causes the associated data value to change) and the value stored at that address. This can be tested by writing the value 9 to address $200 (the first address of screen memory) which causes a blue exclamation mark to be displayed at the top left of the screen:
To the right of the memory inspector is another pair of invisible fields. Only one of these appears at once. They seem to be another memory inspector. The default value of the right address field is $6000. If we change this to $200 and then toggle to the associated data field, we see the value of $9 entered earlier. Further, if we then insert a 4 into this second data field value, we see both the character at the top left of the screen change to a green digit 2 (see image below) and the value reported for address $200 in the left memory inspector change to $94. At this point the distinction between the purpose of the two memory inspectors is unclear.
So, overall things seem to be progressing well. I think the next thing to do is to try to work out why the RETURN instructions are not working correctly.
- Both bottom action buttons = Start the debugger
- Any disc = Show us the game screen while disc held
- Any top action = Executes a single instruction and return to the debugger
- Any bottom left action = Cycle the field focus (yellow highlight) backwards
- Any bottom right action = Cycle the field focus forwards by one
- Left 0-9 = Enter the key value into the least significant digit of the current field, shifting all other digits left
- Left Clear = Execute a single instruction and return to the debugger
- Left Enter = Execute a single instruction and return to the debugger
- Right 1-6 = Enter values A-F into the least significant digit of the current field, shifting all other digits left
- Right 7 = Decrement the value of the current field by 1
- Right 8 = Set the value of the current field to 0
- Right 9 = Increment the value of the current field by 1
- Right Clear = Unknown - crashes
- Right 0 = Unknown - crashes
- Right Enter = Run with trace
; ------------------------------------------------------------------------------
; Periodic debug routine
Debug
BEGIN ;
CALL L_D491 ; call into the debugger
;
NOP ; <<< DEBUGGER STARTS HERE
NOP ;
NOP ;
NOP ;
RETURN ; done
So we can single step or trace a few instructions until we hit the RETURN, then the debugger seems to return to address $0127, picks up a HALT instruction and when this is run JzIntv aborts.
If we press Clear or 0 on the left controller there is a pause with no screen updates followed by JzIntv aborting. So I suspect that a similar thing is happening, perhaps the debugger is trying to run to a break point?
Other interesting bits and pieces. As we cycle the focus forward using the lower right action button, after the CPU flags a new field appears below BRKS. This allows the user to set one of 8 variables (A-H) to 0 or 1. I suspect this allows specific breakpoints to be turned on and off. I've not seen a way to set the breakpoint addresses yet. Cycling on past these A-H variables causes the field to disappear again.
The left side of line 5 is confirmed to be a memory inspector / adjuster. When they have the focus it is possible to change both the address being inspected (which causes the associated data value to change) and the value stored at that address. This can be tested by writing the value 9 to address $200 (the first address of screen memory) which causes a blue exclamation mark to be displayed at the top left of the screen:
To the right of the memory inspector is another pair of invisible fields. Only one of these appears at once. They seem to be another memory inspector. The default value of the right address field is $6000. If we change this to $200 and then toggle to the associated data field, we see the value of $9 entered earlier. Further, if we then insert a 4 into this second data field value, we see both the character at the top left of the screen change to a green digit 2 (see image below) and the value reported for address $200 in the left memory inspector change to $94. At this point the distinction between the purpose of the two memory inspectors is unclear.
So, overall things seem to be progressing well. I think the next thing to do is to try to work out why the RETURN instructions are not working correctly.
Comments
Post a Comment