KrazyKattapilla

What he said! These exercises for the reader are challenging though

Super - thank you.

Hi, Does the "END" on the last line of the kernel have a special purpose? I seem to be able to compile and run things successfully without it so I'm guessing it's more of an aide-memoir. Simon

Cheers... Possibly - checking the Stella options I had various settings randomized on startup. Putting the "cld" after the code to clear RAM and the TIA registers seems to have done the trick. Thanks for all your help. Simon

Hi Andrew, Thanks for this - very much appreciated. The move away from BPL and BMI didn't help on this occasion but I now have new toys in my 6502 toolbox so all is good. Out of interest is there a time you would recommend using BPL and BMI or are they best avoided? I think I have tracked down the source of my problem. I've tried to illustrate it below with a couple of screen-grabs from Stella's debugger... Here you can see the system state immediately before the SBC at instruction F065 is executed. The accumulator holds $14 and ram address 81 holds $09. Also the carry flag is set. So I'd expect the result of the SBC to be that A contains $0B. However... What actually happens is that the accumulator contains $05. It's probably a coincidence but if the $14 held in A was treated as decimal 14 then the subtraction would be correct. Interestingly this problem isn't consistent. For example, if I load another Rom first and then my binary then things seem to work happily. Any ideas on how to push this forward are much appreciated Simon kernel_q2b.asm kernel_q2b.bin

Hi Folks, Well I've been following this rather excellent series of tutorials (thanks to all involved) and even bought the book! Anyway, I've been working through the second challenge and have hit a bit of an odd bug which I can't seem to fix. My code should display a pacman(ish) figure based on data held in a look-up table. For some vertical positions it works wonderfully like this. But for others I'm getting a shadowy effect like this... Having traced my code with the Stella debugger the problem seems to lie with an unexpected result from the SBC opcode in here... MiddleLines stx COLUP0 ;3 cycles - Player 0 the colour associated with X for this scanline only stx COLUPF ;3 cycles - Do the same for the playfield. Will look like we are on LSD! SLEEP 20 ;20 cycles sta RESP0 ;3 cycles txa ;2 cycles - Load A with the scanline number sec ;2 cycles - clear the carry flag sbc sprite_y ;3 cycles Subtract the Y position of the sprite bmi NotDrawSprite ;2/3 cycles - If the result is negative then it is too early to draw the sprite cmp #9 ;2 cycles - Check if we are past the end of the sprite bpl NotDrawSprite ;2/3 cycles - Yes so too late to draw the sprite tay ;2 cycles - Y now = the line of the sprite we want to draw lda pacman_sprite,y ;4 cycles A = the sprite data to show on this scanline sta GRP0 ;3 cycles - And send it to GRP0 NotDrawSprite sta WSYNC inx cpx #184 bne MiddleLines I've attached the full asm and bin files in the hope that someone will take pity on a 6502 newbie and explain what the problem is and what I can do about it. Many thanks Simon kernel.bin kernel_q2.asm