sdm wrote:1. AOROM switches banks size 32KB - so every bank must be a copy of the RESET code and at the end of each bank Vectors code. Right?
Yes, Reset, NMI and IRQ handlers must be present in every bank, even if they're stubs that simply select the bank where the actual handlers are and jumps to them (if you do switch banks in the NMI or IRQ handlers, you should save the current bank's number on the stack so you can restore it before returning).
Generally, I would like to know how to best prepare this mapper so that I have no problem with 'Label multiply defined' errors (after all, a lot of code will be the same in every bank).
One good way to deal with repeated code is to write it in a separate file and INCLUDE it in the main file as many times as necessary, so that any changes to this code are done in a single place, and automatically reflected in all instances where it's used.
As for repeating labels, I've had to deal with this problem in other assemblers: in ASM6 I did Label = *
instead of Label:
as the former can be done multiple times without errors. In ca65 I use scopes and "copy" the necessary labels to the global scope if they aren't already defined. I'm not sure how to do it in NESASM because I never worked with it, but my first try would be to wrap any repeat label in a block like this:
2. In AOROM, you can control Nametable mirroring directly in code, but I have not found anywhere exactly how (bit 4 controls it, but how do you do it correctly?)
AxROM boards use single-screen mirroring, meaning that at any given time, only 1 name table is visible, mirrored in the 4 NT slots the PPU has. The value you write to bit 4 selects which name table this is.
3. What are the advantages of AOROM versus UxROM? Seems to be more onerous because of the size of the bank switched, but some advantages in that it must be (mirroring control probably is an advantage).
I don't like 1-screen mirroring because you can't do 100% clean horizontal scroll with it unless you do something extreme like hiding the rightmost 8 pixels of the screen using an obscene amount of sprites, so for me the advantage is precisely the 32KB bank size.
Different projects have different requirements, so in some cases you may need access to larger chunks of switchable data, but in other cases, having a fixed 16KB bank might make things easier if 16KB a good part of it is usable through the entire game (e.g. the core engine fits in 16KB). There's no obviously "superior" mapper in this case.
4. I have a Mashou cartridge (BNROM) - Will converting it to AOROM will be limited to changing the CIRAM A10 (nametable mirroring) connection. On the wiki I read "BNROM is the same as AMROM except it uses a fixed horizontal or vertical mirroring".
I personally like (oversize) BNROM better, because I find vertical or horizontal mirroring more useful than single-screen, even if it's fixed. Not having to use 1 of the bits for mirroring means you get twice the banks (16 x 32KB = 512KB) too.
5. By converting the BNROM to 512KB (as in the link below) and changing the CIRAM A10 (nametable mirroring) connection it will be exactly AOROM-512.? (Compatible with commercial AOROM (256KB)
To implement the selectable mirroring you'd have to steal one of the banking bits, so no, you can't make an AOROM-512 using a 4-bit register ('161 chip). You'd either need a second '161 or replace it with a larger register, which means different instructions.