Dumb Question

[neilbaldwin]

Is there a reason that I can't write to RAM in my background loop?

It works fine if I modify some RAM values during VBLANK but doing the same modification in the background loop doesn't change the values.

I'm sure I'm missing something obvious but I can't see.

[Disch]

Do you mean VRAM ($2007)? Can't write to VRAM outside of VBlank unless you disable rendering (disable both BG and sprites via $2001).

There's no reason why you can't write to normal RAM though ($0000-07FF). In fact you certainly should be able to.

[neilbaldwin]

Do you mean VRAM ($2007)? Can't write to VRAM outside of VBlank unless you disable rendering (disable both BG and sprites via $2001).

There's no reason why you can't write to normal RAM though ($0000-07FF). In fact you certainly should be able to.

Yes, normal RAM.

I was just going to come back and update this as it's not the writing of the RAM, it's the fact that my background loop actually doesn't do anything?!

After I've done the initial setup, right after the CLI I just have a loop

MainLoop jmp MainLoop

but it seems it doesn't execute. I tested it by calling my sound update routine and it doesn't make the call.

Am I doing something very stupid?

[neilbaldwin]

Ah, seems it's something to do with the CLI command. If I remove it, the background processing works.

Do you have to do something special in your IRQ routine, even if you're not using the IRQ to do anything? Currently my IRQ routine is just an RTI. Is that wrong?

[Jarhmander]

Is the interrupt vector correctly point to RTI? At the moment the IRQ fires, does the right bank is visible at the end of the memory where interrupt vectors should be read, and when it vectors to the ISR, does the correct bank is 'seen' ?

[tokumaru]

Do you have to do something special in your IRQ routine, even if you're not using the IRQ to do anything?

Nothing special, you can have just an RTI there, like you said. Some people even have the IRQ vector point to the same location as the RESET vector. Ideally, if you're not using IRQs, you'd better prevent them from happening at all.

If you are not using interrupts, why did you have a CLI command anyway? Just use SEI at the start of the program to disable all interrupts. If you do decide to use interrupts though, don't forget to disable DMC IRQs and Frame IRQs if you're not using them.

[Disch]

Forgetting to disable the APU Frame IRQ is the common culprit, here.

Code: Select all

 ; do this at program startup
LDA #%01000000
STA $4017

[neilbaldwin]

Forgetting to disable the APU Frame IRQ is the common culprit, here.

Code: Select all

 ; do this at program startup
LDA #%01000000
STA $4017

You got it

I've just removed the CLI command as I'm not using the IRQ anyway (doing the CLI was just a legacy thing, left over from old reset vector code - force of habit I guess).

But Disch was right - I wasn't disabling the APU frame IRQ - doh!

Thanks for the input everyone.

[tokumaru]

I once had a bunch problems because of Frame IRQs myself... It took me a long time to figure out the problem was such a tiny thing that's so easy to fix.

[Jarhmander]

I assumed that if you used CLI, it is because eventually you'll use interrupts...
The code didn't work because the frame IRQ was never acknowledged.