what would be the better option:
1. use a banking scheme similar to nesasm but more robust, where the assembler takes care of writing the prg and chr banks in the correct order
2. writing a seperate program that reads in a seperate text file which contains the header and the order of the banks. then writing the rom
or if there's better ways, i'm all ears.
I don't understand what it's for, what's the signficance of the order? I'd just assume whatever is at the top of the source file would be the first bank and the bottom the end bank (for .includes and everything).
Or in CA65 you can just make each bank a seperate segment and have it wherever in the source, then the linker puts it where you tell it to with the linker config. This sounds exactly like your 2nd option.
The part that I'm missing with banks, maybe it's in cc65 and I missed it, is a way to get a bank number to use in an equation. So I could do something like LDA #^level_data_index / STA prgbank_select_register. (I used ^ because IIRC that's what x816 used for getting 65816's address above 16-bits). But I can just define that stuff manually, only bad thing is having to change definitions if banks got moved around later.
A quick scan of the ca65 user's guide reveals that ^ and .BANKBYTE both do what you want.
WLA-DX allows you (err... forces you) to definite all emplacement of ROM and RAM bank in a separate file.
Then, your sections are located to the bank you want.
It is a pretty great system.
how do those assemblers handle interrupt vectors
In WLA-DX, you just have to make a section where you have all 3 vectors, and force it to start at $fffa (in the bank you should).
now what if there is only one 16k bank at $8000, it would get loaded into $8000 and $C000...correct? therefore forcing to start at $FFFA wouldn't make much sense seing how the bank would stop at $BFFF. should i auto-detect that and switch the vector table to $BFFA, so when the rom is loaded the vector table would be at $BFFA and $FFFA?
also do the first 2 prg banks(assuming there is 2) get loaded in prg-rom on every mapper or is there some other logic as to what gets loaded at power-on/reset?
never-obsolete wrote:
now what if there is only one 16k bank at $8000, it would get loaded into $8000 and $C000...correct? therefore forcing to start at $FFFA wouldn't make much sense seing how the bank would stop at $BFFF. should i auto-detect that and switch the vector table to $BFFA, so when the rom is loaded the vector table would be at $BFFA and $FFFA?
If there is 16k of PRG ROM, you want to put it in $C000-$FFFF. Just to be safe, and sure of what's going on. It depends on the mapper, actually. If you had 16k of PRG with MMC1, and you had vector adresses pointing to $8000-$BFFF, it would be a big problem. Or at least I'm pretty sure. It has to do with the hardwired bank. With MMC1, the hardwired bank is in $C000-$FFFF. $8000-$BFFF is used for bankswitching. It can be changed so you can switch $C000-$FFFF out and leave $8000-$BFFF as the same bank. I don't know why you'd do this, though.
I don't think the vectors go to $BFFA. I haven't really ever thought about this before. I'd just avoid that all together, and put the bank in $C000-$FFFF.
never-obsolete wrote:
also do the first 2 prg banks(assuming there is 2) get loaded in prg-rom on every mapper or is there some other logic as to what gets loaded at power-on/reset?
The last bank is a hardwired bank, which means the last bank of PRG will always be present. It's different for each mapper. MMC1 loads the last bank into $C000-$FFFF, and puts a random bank into $8000-$BFFF.
If there is only 16kb of PRG, it gets loaded to BOTH $8000-$bfff and $c000-$ffff. It's because the adress line A14 has no effect on the cartridge, so the ROM is mirrored. $bffa and $fffa will acess to the exact same data.
However, the CPU reads its vectors from $fffa anyway, regardless how is mapped the cartridge. So the more logical is to consider your 16kb mapped into $c000-$ffff, and ignore $8000-$bfff, wich actually is just a mirror of $c000-$ffff. But you could also "consider" that your vectors are at $bfffa, that wouldn't be really wrong since the same data is read from $fffa, so the CPU will have acess to your vercors normally. However, I prefer the other way arround because it will work with larger sizes too.
If a newbie belive that the vectors are at $bffa, and then decinde to expand his ROM to 32kb PRG, his rom will crash.
Celius wrote:
MMC1 loads the last bank into $C000-$FFFF, and puts a random bank into $8000-$BFFF.
That's not true with the MMC1A, I'm certain. So you might want to reserve some space in the end of your banks for some boot code, depending on the cart you use.
i've got the bank system figured out and now i have to get the labels working correctly and i'll have a functioning assembler. the biggest problem is with zero page.
The zero page is very simple.
If the high byte of the instruction's adress is zero, just replace the opcode with the zero page adressing and remove the $00.
Memblers wrote:
That's not true with the MMC1A, I'm certain.
If you allege that the MMC1A doesn't power on in the fixed-$C000 state, then someone will need to make a test ROM and try it on a real cart.
the problem was i over-complicated the situation. after sleeping for awhile i now have a better idea as to handleing the labels.