Understanding the .bank label a bit better

Are you new to 6502, NES, or even programming in general? Post any of your questions here. Remember - the only dumb question is the question that remains unasked.

Moderator: Moderators

Post Reply
User avatar
NeverCameBack
Posts: 41
Joined: Mon Feb 24, 2020 12:22 am

Understanding the .bank label a bit better

Post by NeverCameBack » Tue Apr 21, 2020 11:28 am

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

User avatar
tokumaru
Posts: 11866
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Re: Understanding the .bank label a bit better

Post by tokumaru » Tue Apr 21, 2020 1:08 pm

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.

User avatar
NeverCameBack
Posts: 41
Joined: Mon Feb 24, 2020 12:22 am

Re: Understanding the .bank label a bit better

Post by NeverCameBack » Thu Apr 23, 2020 8:11 pm

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.

Pokun
Posts: 1512
Joined: Tue May 28, 2013 5:49 am
Location: Hokkaido, Japan

Re: Understanding the .bank label a bit better

Post by Pokun » Fri Apr 24, 2020 1:55 am

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.

User avatar
tokumaru
Posts: 11866
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Re: Understanding the .bank label a bit better

Post by tokumaru » Fri Apr 24, 2020 4:01 am

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!

Post Reply