ludoVIC wrote: ↑
Thu Jan 21, 2021 4:57 am
Each bank has a maximum capacity of 8 KB.
Yes. Keep in mind that this is a NESASM thing though, it's not a universal NES or 6502 thing. Other 6502 assemblers can have variable bank sizes, or not even have the concept of banks at all. This is just the solution NESASM uses to control the size of the binaries it generates.
But, how precisely is this value "filled"?
Do code instructions occupy memory in the bank?
All the code/data you write and/or include after the .bank directive gets put in that bank, starting from the lowest address and going up. If it doesn't fill the whole 8KB, the assembler will pad the remaining space (I think!).
In other words, if I understood correctly, the code itself is structured in pieces, each capable of running a limited about of instructions.
It is possible to jump between these pieces, but only when they are properly arranged in the memory (as the example you mentioned).
NESASM kinda forces you to break things into 8KB chunks, but that's quite a lot of space to fill when you're making a simple game. Most 6502 programs are built from subroutines that are much smaller than that, so you can easily distribute them across the PRG banks in the way that's most convenient for you. If you're not using mappers, it hardly matters where things go, since everything is accessible at all times.
Finally, some banks are not meant to me executed, but rather just to set some "system variable", as the CHR banks.
It has nothing to do with "system variables". CHR-ROM occupies space, and the only way to get space in NESASM is to start a new bank.