Sprite OAM issue? (updated: bug in own code)

[thefox]

Do you need current_bank at all? Why not just always switch to the requested bank?

...

Another way to handle this is to save the current bank number in a known memory location in each ROM bank. Not really beneficial over using RAM though.

But yeah, I think it's very important to be aware of all sorts of concurrency issues that can arise even in the seemingly simple scenario of two threads (with a special case where only one of them (vblank) can interrupt the other) on a uniprocessor system.

[Movax12]

You could save the bank in an assembler variable. I made a macro called setCodeBank, which allows code to check what bank it is in, plus the assembler can decide if a trampoline call is required, or if it can just jsr to a subroutine. (Each subroutine label is also tagged with a bank number.) This idea could be extended to data to some extent, but you would need to use a variable or mark the bank somehow.

[thefox]

You could save the bank in an assembler variable. I made a macro called setCodeBank, which allows code to check what bank it is in, plus the assembler can decide if a trampoline call is required, or if it can just jsr to a subroutine. (Each subroutine label is also tagged with a bank number.) This idea could be extended to data to some extent, but you would need to use a variable or mark the bank somehow.

Doesn't work when vblank needs to be able to restore the bank (e.g. when banking in a music handler), because the active bank (of the main thread) is only known at runtime.

[sdwave]

I had something similar with bankswitching and interrupt happening mid-switch and causing a bankswitch to the wrong bank. I ended up turning off interrupts when doing the bank switch, and ensuring the switches happened during certain scanlines.

[GradualGames]

I had something similar with bankswitching and interrupt happening mid-switch and causing a bankswitch to the wrong bank. I ended up turning off interrupts when doing the bank switch, and ensuring the switches happened during certain scanlines.

That sounds a bit dangerous, but then I suppose you're using a scanline counter, so it's probably ok. But if you're using a scanline counter, I'm not sure why you'd need to turn off nmi? Nevermind, I don't know enough details about what you're doing. Still, I don't think one should ever need to turn off nmi. graphics, yes, nmi, no. You can just make your nmi a no-op if you need to. (swap out an indirectly called routine?)

...I forgot one more point about making music bankswitching interrupt-safe, and that's if you do ever have moments in your game that cause slowdown---it protects your game from crashing when the sound update continues to run at normal speed every frame. Not that it absolves one from having slowdowns---it's just good to try to make code bullet proof if possible.

[tepples]

Turning off NMI is helpful in games using mappers with 32K bankswitching where not all banks have an NMI handler. Some banks might be full of data that gets copied or decompressed to RAM, such as banks holding CHR data in multicarts.

[GradualGames]

Turning off NMI is helpful in games using mappers with 32K bankswitching where not all banks have an NMI handler. Some banks might be full of data that gets copied or decompressed to RAM, such as banks holding CHR data in multicarts.

Cool, didn't think of that. With games setup like this, I assume there must be times when everything is stopped, including music?

[tepples]

mappers with 32K bankswitching where not all banks have an NMI handler

Cool, didn't think of that. With games setup like this, I assume there must be times when everything is stopped, including music?

Yes. After the player chooses a game from the multicart's menu, it blanks the screen and silences the APU before decompressing 8192 bytes of CHR data.

[Movax12]

You could save the bank in an assembler variable. I made a macro called setCodeBank, which allows code to check what bank it is in, plus the assembler can decide if a trampoline call is required, or if it can just jsr to a subroutine. (Each subroutine label is also tagged with a bank number.) This idea could be extended to data to some extent, but you would need to use a variable or mark the bank somehow.

Doesn't work when vblank needs to be able to restore the bank (e.g. when banking in a music handler), because the active bank (of the main thread) is only known at runtime.

Thinking..
Obviously code can know what bank it is and what bank it is calling at build - as long as NMI doesn't change the bank out from under it this is true. But bankable data cannot be tracked by the same way at build. Perhaps Lua scripting of the recent NintendulatorDX would be able to at least verify that the correct bank was being accessed and alert you if banking code was needed, though unless every code path was taken it wouldn't be able to prove that banking wasn't needed at a given point in code.

[blargg]

Furthermore, saving Y keeps the code correct when you rearrange the banks for watermarking (5040 possibilities for banks 0-6 in UNROM or 1.3 trillion for UOROM).

Nice, didn't think of that. I'm hoping to look into watermarking sometime soon in order to recruit some beta-testers.

Note to beta testers wanting to leak ROM: reorder banks.

One idea I had floating around was to find sequences of code whose order do not matter, re-order them uniquely for each beta tester, and then keep track of which beta tester is associated with which harmless permutation of the code.

So, analyze ROM and randomly reorder routines as well. Could be automated

Seems it'd be simpler to just put some junk code that's executed somewhere in the ROM that's different for each copy. Less risk of breaking something by reordering code.

[tokumaru]

Seems it'd be simpler to just put some junk code that's executed somewhere in the ROM that's different for each copy. Less risk of breaking something by reordering code.

Then 2 beta testers can just compare their ROMs to locate the junk code and modify/clear it before leaking.

[3gengames]

Or you can do like me and rotate the sources for each copy so unless they want to disassemble and rearrange all the subroutines and even meaningless/seemingly meaningless data, they won't be able to do that.