Yes, thank you , I agree... maybe the same thing happens here... it reaches the rts at the bottom and then pulls $37 and $C0 off the stack and goes to $C201 ???? Why?????????????????????????tokumaru wrote:RTS without JSR is indeed a nasty bug, you have to be careful about that. If a return address wasn't put on the stack, the RTS will get anything that is at the top of the stack and jump to a bad location.
Then $C201 is listed as "UNDEFINED" (because that instruction starts at $C200) and so then it runs an incorrect byte again ($C203, shows "PLP"). Then it runs the code at $C204
sta $0029. Something happens next I don't understand why! It ends up at $C336 RTI and never does anything else...
Code: Select all
0C15E see:
0C15E
0C15E A0 00 ldy #$00
0C160 A2 00 ldx #$00
0C162 A9 91 lda #<lvl1Screen1start
0C164 85 10 sta $10
0C166 A9 C8 lda #>lvl1Screen1start
0C168 85 11 sta $11
0C16A
0C16A
0C16A A9 20 lda #$20
0C16C 8D 06 20 sta $2006;Sets the high byte of the address $2007 will write to.
0C16F A9 00 lda #$00
0C171 8D 06 20 sta $2006;Sets the low bylte of the address $2007 will write to.
0C174
0C174 ;a is still 0
0C174 85 20 sta r
0C176 48 pha ;--------------------------->
0C177
0C177 B6 10 -- ldx ($10), y
0C179 BD 57 C3 lda MetatileTile0, x
0C17C 8D 07 20 sta $2007;Writes to PPU address $2000. (which is the first tile of the first name table)
0C17F BD 36 C4 lda MetatileTile1, x
0C182 8D 07 20 sta $2007;Writes to PPU address $2001. (which is the tile to the right of the first tile)
0C185 C8 iny
0C186 E6 20 inc r
0C188 ; pla ;<--------------------------
0C188 ; tax
0C188 ; inx
0C188 ; txa
0C188 ; pha ;-------------------------->
0C188 A5 20 lda r
0C18A 29 0F and #00001111b
0C18C F0 03 beq + ;branch if it a multiple of 16
0C18E 4C 77 C1 jmp --
0C191
0C191
0C191 C8 + iny
0C192
0C192 B6 10 - ldx ($10), y
0C194 BD 15 C5 lda MetatileTile2, x
0C197 8D 07 20 sta $2007;Writes to PPU address $2010. (which is the third tile, first tile on second row, of the first name table)
0C19A BD F4 C5 lda MetatileTile3, x
0C19D 8D 07 20 sta $2007;Writes to PPU address $2011. (which is the tile to the right of the third tile)
0C1A0 C8 iny
0C1A1 E6 20 inc r
0C1A3 ; pla ;<--------------------------
0C1A3 ; tax
0C1A3 ; inx
0C1A3 ; txa
0C1A3 ; pha ;--------------------------->
0C1A3 A5 20 lda r
0C1A5 C9 F0 cmp #11110000b ;if (r >= 240)
0C1A7 90 07 bcc +done
0C1A9 29 0F and #00001111b
0C1AB F0 CA beq --
0C1AD 4C 92 C1 jmp -
0C1B0
0C1B0 +done:
0C1B0 60 rts 0C1B1
No, break on bad opcode isn't checked. No, right before the rti is an rts.Kasumi wrote:I'm not 100% clear. You're saying fceux's debugger is stopping your code at $C336 despite you not having any active breakpoints? That's pretty strange. Is break on bad opcode checked? That's about my only guess. Are there any problems on a different emulator? Does anything else "run into" that RTI?
Something like:
?Code: Select all
NMI: ;NMI code here, without an rti IRQ RTI