Debugging Assembly Code

[charlietunaz]

I ran the code below in Classic 99 and I opened the debugger to watch and learn about breakpoints and reading register values.  The program places the ball in the middle of the screen, then moves it down and wraps around to row 1 when it reaches the bottom row.  I placed two breakpoints in A092 (mov  R4,R0) and A09C (ai   R2,>0001).  A092 is right before updating the position of the ball, and A092 is comparing the current position to check if it went past row 24.

I notice the position at R2 is updating fine, however, when I click the Normal Speed option sometimes the program skips one of the breakpoints, and the ball moves two rows at once.  I'm not sure if this is a debugger glitch or there's something in the code that is not right.  I've been clicking carefully using the keyboard and the mouse to make sure I'm not double clicking.  I think the skipping happens in the same places all the time, so it's not random either.

*	CSL 02/22/2021
*	BOUNCING BALL
*		DEF BBALL
		REF VSBW,VMBW,VWTR
MYREG	BSS		>20	
BALL	DATA	>3C7E,>FFFF,>FFFF,>7E3C	*BALL PATTERN
* BALL INITIAL POSITION
ROW		EQU		>C
COL		EQU		>10
*
BBALL	LWPI	MYREG		* PROGRAM START
* CLEAR SCREEN 
		LI		R0,>0		* START OF VDP RAM
		LI		R1,>2000	* PLACE SPACE (>20)
CLEAR	BLWP	@VSBW		
		INC		R0			* NEXT SCREEN POSITION
		CI		R0,>0300	* CK IF LAST POSITION (768)
		JNE		CLEAR		* IF NOT, CONTINUE
* CHANGE SPACE BACKGROUND COLOR TO BLACK		
		LI		R0,>0384	* COLOR ADDRESS FOR SPACE 
		LI		R1,>B100	* COLOR YELLOW (B) ON BLACK (1)
		BLWP	@VSBW
* CHANGE SCREEN COLOR BORDERS
		LI 		R0,>0711		
		BLWP	@VWTR
* DEFINE BALL CHAR		
		LI		R0,>0C00	* PATTERN ADDR FOR CH >80 
		LI		R1,BALL		* DATA
		LI		R2,8		* NUMBER OF BYTES
		BLWP	@VMBW
* SET BALL COLOR		
		LI		R0,>0390	* COLOR ADDRESS
		LI		R1,>B000	* COLOR YELLOW (B) ON TRANSP (0)
		BLWP	@VSBW		
* DISPLAY BALL
		LI		R2,ROW
MBALL	LI		R3,>20
		MPY		R2,R3		* R4 = (ROW * 32)
		AI		R4,COL		* + COL
		MOV		R4,R0		* ROW & COL ADDRESS
		LI		R1,>8000	* PLACE BALL CHAR (>80)
		BLWP	@VSBW
		CLR		R8
*		
DELAY	INC 	R8
		CI		R8,>05DC
		JNE		DELAY
*		
		MOV		R4,R0		
		LI		R1,>2000
		BLWP	@VSBW		* ERASE BALL FROM CUR POS
		AI		R2,>01		* GO DOWN ONE ROW
		CI		R2,>17		* CHECK IF BOTTOM ROW
		JLE		MBALL
		LI		R2,>00
		JMP		MBALL
		END		BBALL

I added a video demonstrating what I wrote above.  Please watch closely at 1:30 and 2:10 how the debugger goes from A092 and skips the breakpoint at A09C.  Then the ball moves twice.

Edited February 24, 2021 by charlietunaz
Added video.

[Asmusr]

Have you tried to use F1 to resume the program instead of selecting Normal speed?

[Tursi]

Yeah, use F1,F2,F3 for operating the debugger, the speed controls are for the running emulation. It's probably still in the process of updating the system when the breakpoint is bypassed.

 

[charlietunaz]

Yup, I realize now that F1 is a pause/continue toggle.  Still the same result; I was just curious about the debugger's operation/behavior, to feel more comfortable with it in case I have to trace a more complex program in the future.  The program as it is, seems to be running normally at regular speed.  Thanks!

[Asmusr]

Maybe you get an interrupt at that point? Try turning off interrupts with LIMI 0.

[senior_falcon]

For what it's worth, I too have found that when break points are really close together, the second one is often skipped.  There seems to be neither rhyme nor reason to it: If I tap F1 really fast it will sometimes break; if I hold down F1 it sometimes breaks; but many other times it just goes past the second break point without stopping.

It could be my equipment: an old Dell rescued from the trash; the old keyboard which in Classic99 sometimes registers a double keypress; or Wndows XP running in a virtual box on a linux OS which is badly in need of updating.

I have learned to live with it, adjusting the break points as needed so it will stop where I want it to.

[RXB]

3 hours ago, senior_falcon said:

For what it's worth, I too have found that when break points are really close together, the second one is often skipped.  There seems to be neither rhyme nor reason to it: If I tap F1 really fast it will sometimes break; if I hold down F1 it sometimes breaks; but many other times it just goes past the second break point without stopping.

It could be my equipment: an old Dell rescued from the trash; the old keyboard which in Classic99 sometimes registers a double keypress; or Wndows XP running in a virtual box on a linux OS which is badly in need of updating.

I have learned to live with it, adjusting the break points as needed so it will stop where I want it to.

Yea the problem is Keypress is repeated so it skips it.

Here is the GPL code to look for Break Key and check it:

[2608] 9138 8E,80,84 G9138  CZ   @RAMTOP           If ERAM exist then
[2609] 913B 71,40           BS   G9140
[2610] 913D 06,91,79        CALL GRMLST            Fake it : move each line to t
[2611]               *                              CRUNCH buffer form ERAM
[2612] 9140 06,6A,74 G9140  CALL LLIST             List the current line
[2613] 9143 03              SCAN                   Test for a break key
[2614] 9144 51,4E           BR   LISTZ3            No key
[2615] 9146 D6,75,02        CEQ  BREAK,@RKEY
[2616] 9149 71,5F           BS   LISTZ4
[2617] 914B 03       LISTZ5 SCAN
[2618] 914C 51,4B           BR   LISTZ5
[2619] 914E 8E,80,84 LISTZ3 CZ   @RAMTOP           If ERAM exists
[2620] 9151 71,56           BS   G9156
[2621] 9153 BD,2E,58        DST  @FAC14,@EXTRAM    Restore the @EXTRAM
[2622] 9156 A7,2E,00 G9156  DSUB 4,@EXTRAM         Pointer to next line
       9159 04
[2623] 915A C5,0E,2E        DCH  @EXTRAM,@CURINC   Display all lines in range
[2624] 915D 51,38           BR   G9138
[2625] 915F 8E,17    LISTZ4 CZ   @DSRFLG           Device I/O -> output last rec
[2626] 9161 51,6D           BR   G916D
[2627] 9163 06,96,A5        CALL OUTREC            Output the last record
[2628] 9166 06,97,5E        CALL IOCALL            Close the device properly
[2629] 9169 01              BYTE CZCLOS
[2630] 916A 05,60,1A        B    TOPL10
[2631] 916D 05,60,12 G916D  B    TOPL15            Restart the variable too

 

[senior_falcon]

Classic99 is a windows program. I am quite sure it does not use the TI keyscan to detect F1 to break or restart the program.

[RXB]

29 minutes ago, senior_falcon said:

Classic99 is a windows program. I am quite sure it does not use the TI keyscan to detect F1 to break or restart the program.

Yea Windows does buffer the keys so thus is terrible at detection of keys and gets it wrong constantly.

Example have to stand on the Print Screen key to get it to work on some applications thanks to windows sucks at how it checks for keys.

[Tursi]

Weird. I do occasionally see missed breakpoints, but usually after some kind of branch. I've never had problems with the keypresses.

 

The keys are tracked as an active state via the windows key messages, and special keys like the debugger keys clear that state whether the key is still down or not... so unless you are holding long enough to trigger auto-repeat, I'm surprised that you are having such behaviour.

 

Remember that F1 is Run/Stop, and F2 is step. Don't use F1 to step. Dunno what else you might be seeing.

 

[charlietunaz]

6 minutes ago, Tursi said:

Weird. I do occasionally see missed breakpoints, but usually after some kind of branch. I've never had problems with the keypresses.

 

The keys are tracked as an active state via the windows key messages, and special keys like the debugger keys clear that state whether the key is still down or not... so unless you are holding long enough to trigger auto-repeat, I'm surprised that you are having such behaviour.

 

Remember that F1 is Run/Stop, and F2 is step. Don't use F1 to step. Dunno what else you might be seeing.

 

The problem with stepping using F2 is that when it goes through the delay loop it takes forever.  F1 stops when it reaches the breakpoints.  I guess I could comment the delay just to try it out though.

[Asmusr]

I have tried to assemble the code, and I'm seeing the same issue as charlietunaz (also with LIMI 0).

[HOME AUTOMATION]

On 2/23/2021 at 9:07 PM, charlietunaz said:

* CSL 02/22/2021 * BOUNCING BALL * DEF BBALL REF VSBW,VMBW,VWTR MYREG BSS >20 BALL DATA >3C7E,>FFFF,>FFFF,>7E3C *BALL PATTERN * BALL INITIAL POSITION ROW EQU >C COL EQU >10 * BBALL LWPI MYREG * PROGRAM START * CLEAR SCREEN LI R0,>0 * START OF VDP RAM LI R1,>2000 * PLACE SPACE (>20) CLEAR BLWP @VSBW INC R0 * NEXT SCREEN POSITION CI R0,>0300 * CK IF LAST POSITION (768) JNE CLEAR * IF NOT, CONTINUE * CHANGE SPACE BACKGROUND COLOR TO BLACK LI R0,>0384 * COLOR ADDRESS FOR SPACE LI R1,>B100 * COLOR YELLOW (B) ON BLACK (1) BLWP @VSBW * CHANGE SCREEN COLOR BORDERS LI R0,>0711 BLWP @VWTR * DEFINE BALL CHAR LI R0,>0C00 * PATTERN ADDR FOR CH >80 LI R1,BALL * DATA LI R2,8 * NUMBER OF BYTES BLWP @VMBW * SET BALL COLOR LI R0,>0390 * COLOR ADDRESS LI R1,>B000 * COLOR YELLOW (B) ON TRANSP (0) BLWP @VSBW * DISPLAY BALL LI R2,ROW MBALL LI R3,>20 MPY R2,R3 * R4 = (ROW * 32) AI R4,COL * + COL MOV R4,R0 * ROW & COL ADDRESS LI R1,>8000 * PLACE BALL CHAR (>80) BLWP @VSBW CLR R8 * DELAY INC R8 CI R8,>05DC JNE DELAY * MOV R4,R0 LI R1,>2000 BLWP @VSBW * ERASE BALL FROM CUR POS AI R2,>01 * GO DOWN ONE ROW CI R2,>17 * CHECK IF BOTTOM ROW JLE MBALL LI R2,>00 JMP MBALL END BBALL

...was going to have at it for a moment ...but this code seems terribly misaligned ...don't have the time or patience to fiddle with the keyboard that much!

 

I think I like it a tad better this way(above). Sorry.

 

 

[Asmusr]

Here's the object file.

BBALL-O

[Tursi]

As I noted, I've seen missed breakpoints around branch instructions. Your second breakpoint is right after the BLWP. Try moving it down one instruction and see if that is more reliable. Let me know.

 

 

[HOME AUTOMATION]

Thanks, mine seems to skip as well. >A092 three times in a row, three times out of 20. >A09c twice in a row. Only once, did both instructions trap!

 

 

This is also a mystery...

 

 

 

I created the .jpg seen in the post, at 2:08pm. definitely not 12 hours ago!

 

Since the post I'm responding to, wont be available for another 1 1/2 Hrs...

 

...If your reading this before 4pm, you're probably seeing a mirage.

 

    P.S. I really aught to stop jaunting from post-to-post.?

[Asmusr]

40 minutes ago, Tursi said:

As I noted, I've seen missed breakpoints around branch instructions. Your second breakpoint is right after the BLWP. Try moving it down one instruction and see if that is more reliable. Let me know.

I thought the same and tried that, but it didn't help in my case. For me it misses something like 3 out of four of the second breakpoint. 

Edited February 26, 2021 by Asmusr

[Tursi]

So I dug into this a bit, since it does hit me sometimes too, and my theory about branches holds no water. I found it and fixed it - there was a race with the Windows message pump. Basically, hitting F1 to continue would update the internal emulation state, resume the CPU, etc, and send a message off to update the Window menu state. If you breakpointed again before Windows processed the message, the CPU would be stopped correctly, then Windows would receive the "hey, we're playing again" message, and start the CPU back up.

 

The fix was to differentiate between command messages and visual update messages, already done in a few places. The next update is nearly ready and should be out this weekend, hopefully.

 

[Asmusr]

1 hour ago, Tursi said:

So I dug into this a bit, since it does hit me sometimes too, and my theory about branches holds no water. I found it and fixed it - there was a race with the Windows message pump. Basically, hitting F1 to continue would update the internal emulation state, resume the CPU, etc, and send a message off to update the Window menu state. If you breakpointed again before Windows processed the message, the CPU would be stopped correctly, then Windows would receive the "hey, we're playing again" message, and start the CPU back up.

 

The fix was to differentiate between command messages and visual update messages, already done in a few places. The next update is nearly ready and should be out this weekend, hopefully.

 

Great you found it. I rarely had the need for multiple breakpoints, so I guess that's why I haven't seen this before. The reason I mentioned interrupts (besides the point that you should never access the VDP with interrupts turned on) is that I have a vague idea that sometimes I have missed a breakpoint if I continued execution at the same time as there was an interrupt, but I really don't know.

[charlietunaz]

1 hour ago, Tursi said:

So I dug into this a bit, since it does hit me sometimes too, and my theory about branches holds no water. I found it and fixed it - there was a race with the Windows message pump. Basically, hitting F1 to continue would update the internal emulation state, resume the CPU, etc, and send a message off to update the Window menu state. If you breakpointed again before Windows processed the message, the CPU would be stopped correctly, then Windows would receive the "hey, we're playing again" message, and start the CPU back up.

 

The fix was to differentiate between command messages and visual update messages, already done in a few places. The next update is nearly ready and should be out this weekend, hopefully.

 

That's great, thank you for looking into this!

[charlietunaz]

14 hours ago, HOME AUTOMATION said:

...was going to have at it for a moment ...but this code seems terribly misaligned ...don't have the time or patience to fiddle with the keyboard that much!

 

I think I like it a tad better this way(above). Sorry.

 

 

Well, apparently another glitch, but on this page maybe? because my code looks aligned from here.  I copied and pasted it straight from Notepadd++ using the <code> tag on this page.

[+9640News]

Likely, it is the use of the tab character which will not translate to a specified number of spaces.

[Tursi]

1 hour ago, Asmusr said:

Great you found it. I rarely had the need for multiple breakpoints, so I guess that's why I haven't seen this before. The reason I mentioned interrupts (besides the point that you should never access the VDP with interrupts turned on) is that I have a vague idea that sometimes I have missed a breakpoint if I continued execution at the same time as there was an interrupt, but I really don't know.

Yeah, I can't see any evidence for that. I wouldn't rule it out, but interrupts are triggered on the same thread as the breakpoints, so it SHOULD be okay.