Page 1 of 1

Understanding the .bank label a bit better

Posted: Tue Apr 21, 2020 11:28 am
by NeverCameBack
Does the .bank label need to go with a specific location in memory?
Example: Does Bank 0 always need to have .org $8000 below it?

; Sound engine goes here:
.bank 0
.org $8000
.include "sound_engine.asm"

; Nothing here for now:
.bank 1
.org $A000

; RESET, NMI, "Main" program goes here:
.bank 2
.org $C000
.... etc.

It works, but if I change .bank 0 to .bank 1 and vice versa... The program does not run.
It doesn't seem to matter if they are in sequential order or not. I have another working program that goes .bank 4, .bank 0, .bank 1 - and it runs.
Does anyone know why that would be?

Based on this description - the two things I'm switching are in the Game cart ROM region of memory. So why would switching two of them screw things up?

$0000-0800 - Internal RAM, 2KB chip in the NES
$2000-2007 - PPU access ports
$4000-4017 - Audio and controller access ports
$6000-7FFF - Optional WRAM inside the game cart
$8000-FFFF - Game cart ROM

Re: Understanding the .bank label a bit better

Posted: Tue Apr 21, 2020 1:08 pm
by tokumaru
Firstly - always specify the assembler you're using. Each assembler has a different set of directives (.bank is a directive BTW, not a label) that don't always behave the same. From your examples, I assume you're using NESASM.

In NESASM, .bank basically starts a new 8KB block. The number that comes after .bank, AFAIK, is just a number that gets assigned to labels created in that bank, which you can read back to build bankswitch tables and the like. If you're not gonna do that, the numbers probably don't matter (like when you went 4, 0, 1). What I don't know is whether you can use the same bank number twice or 4 times in a row, if the mapper uses 16KB or 32KB banks instead of 8KB like NESASM always assumes.

The .org directive is used to let the emulator know where the code that follows will be mapped in the CPU. You don't get to choose where the code will be mapped to, this is defined by the system (NES) and the mapper (NROM, MMC1, MMC3, etc.), and if you give the assembler the wrong values, the resulting binary will not work correctly. If you switched the .org addresses around, that's probably the reason your ROM didn't work.

Re: Understanding the .bank label a bit better

Posted: Thu Apr 23, 2020 8:11 pm
by NeverCameBack
Thanks - That helps. It is NASM as per Nerdy Nights (my guide). I did get my rom to work eventually, although I had to change the ".inesprg 2 ; 1x 16KB PRG code" directive at the top.

As of now I have a "game" with four screens, and music plays if you press up. But I'm almost out of .CHR space, with 32 KB available using the bank switching method. I'll be attempting the MMC1 mapper to get more screens.

Re: Understanding the .bank label a bit better

Posted: Fri Apr 24, 2020 1:55 am
by Pokun
You mean NESASM. NASM is an x86 assembler.

Getting more than four screens doesn't sound like a reason to start with MMC1 though, or even a discrete mapper. SMB1 uses NROM and has 8 worlds with 4 courses each, and only has the standard 8 kB CHR ROM.

Re: Understanding the .bank label a bit better

Posted: Fri Apr 24, 2020 4:01 am
by tokumaru
Yeah, the number of screens you have is not directly related to the mapper you're using or how much PRG/CHR space you have - it all comes down to how you're storing your data.

NES games aren't supposed to have all new CHR tiles on every screen... In fact, the console is designed for heavy reuse of background/sprite tiles. As Pukun mentioned, SMB has a ton of levels all using the same set of 512 tiles. Sure, SMB looks pretty repetitive, but surely you don't need a new tileset on every screen to add variety to a game!