tricky wrote:
What was the bug and how did you find it?
Good question. I was using the wrong branch instruction in the y axis part of the sprite movement routine. I used BCS instead of BCC when determining whether I needed to move down the screen to the next char row (snippet below).
I tracked it by using debugger in B-Em + pencil and paper. Previously, I had been trying to use just the debugger on mylaptop whilst on my commute to work..kept running out of time and forgetting what I was doing each time I tried to carry on!
At home, by scribbling notes and referring to the Mode 5 screen layout in Adv user guide, plus the debug output I could see what was happening.
I put a Break at the start of the MoveSprite routine and Watched for writes of updates to the screen address the routine was outputting to the Sprite structure. By checking the addr of the PC register from the Watch output, I was able to see where the writes were occurring and work it out from there.
..I should say also that I redirected the verbose B-Em assembled output to a text file which gives the memory address of each instruction.
Speaking of verbose .. above is a bit waffly but maybe it will be of use to others. Might even be a useful little tutorial in it perhaps!.
Code:
ldy #SS_CurrScrAddr
lda (SprStructPtr), Y
clc
adc tmp
sta tmp2 ; addr + y move amount
and #&7 ;
cmp #&8
bcc posyWithinChar ; changed from incorrect bcs to bcc on 19th may.. we need to be checking that 3 lsbs are <=7 (<8) as each char row is 8 pixels deep. so if we are the 8th pixel down in a char row, and we want to go one pixel lower, we need to cross in to the next char row - thus increment hi byte of scr addr, and then decrement by 8 pixels
