It is currently Sat Oct 21, 2017 8:49 am

All times are UTC - 7 hours





Post new topic Reply to topic  [ 14 posts ] 
Author Message
 Post subject: banking system
PostPosted: Fri Apr 07, 2006 8:19 pm 
Offline
User avatar

Joined: Wed Sep 07, 2005 9:55 am
Posts: 299
Location: Phoenix, AZ
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.


Top
 Profile  
 
 Post subject:
PostPosted: Fri Apr 07, 2006 9:19 pm 
Offline
Site Admin
User avatar

Joined: Mon Sep 20, 2004 6:04 am
Posts: 3470
Location: Indianapolis
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.


Top
 Profile  
 
 Post subject:
PostPosted: Sat Apr 08, 2006 12:49 am 
Offline
User avatar

Joined: Mon Sep 27, 2004 8:33 am
Posts: 3715
Location: Central Texas, USA
A quick scan of the ca65 user's guide reveals that ^ and .BANKBYTE both do what you want.


Top
 Profile  
 
 Post subject:
PostPosted: Sat Apr 08, 2006 1:59 am 
Offline
User avatar

Joined: Fri Nov 12, 2004 2:49 pm
Posts: 7232
Location: Chexbres, VD, Switzerland
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.

_________________
Life is complex: it has both real and imaginary components.


Top
 Profile  
 
 Post subject:
PostPosted: Sun Apr 09, 2006 1:50 am 
Offline
User avatar

Joined: Wed Sep 07, 2005 9:55 am
Posts: 299
Location: Phoenix, AZ
how do those assemblers handle interrupt vectors


Top
 Profile  
 
 Post subject:
PostPosted: Sun Apr 09, 2006 2:41 am 
Offline
User avatar

Joined: Fri Nov 12, 2004 2:49 pm
Posts: 7232
Location: Chexbres, VD, Switzerland
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).

_________________
Life is complex: it has both real and imaginary components.


Top
 Profile  
 
 Post subject:
PostPosted: Sun Apr 09, 2006 4:56 pm 
Offline
User avatar

Joined: Wed Sep 07, 2005 9:55 am
Posts: 299
Location: Phoenix, AZ
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?


Top
 Profile  
 
 Post subject:
PostPosted: Sun Apr 09, 2006 5:52 pm 
Offline
User avatar

Joined: Sun Jun 05, 2005 2:04 pm
Posts: 2131
Location: Minneapolis, Minnesota, United States
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.


Top
 Profile  
 
 Post subject:
PostPosted: Sun Apr 09, 2006 11:47 pm 
Offline
User avatar

Joined: Fri Nov 12, 2004 2:49 pm
Posts: 7232
Location: Chexbres, VD, Switzerland
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.

_________________
Life is complex: it has both real and imaginary components.


Top
 Profile  
 
 Post subject:
PostPosted: Mon Apr 10, 2006 12:06 am 
Offline
Site Admin
User avatar

Joined: Mon Sep 20, 2004 6:04 am
Posts: 3470
Location: Indianapolis
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.


Top
 Profile  
 
 Post subject:
PostPosted: Mon Apr 10, 2006 12:32 am 
Offline
User avatar

Joined: Wed Sep 07, 2005 9:55 am
Posts: 299
Location: Phoenix, AZ
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.


Top
 Profile  
 
 Post subject:
PostPosted: Mon Apr 10, 2006 1:21 am 
Offline
User avatar

Joined: Fri Nov 12, 2004 2:49 pm
Posts: 7232
Location: Chexbres, VD, Switzerland
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.

_________________
Life is complex: it has both real and imaginary components.


Top
 Profile  
 
 Post subject:
PostPosted: Mon Apr 10, 2006 9:59 am 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19113
Location: NE Indiana, USA (NTSC)
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.


Top
 Profile  
 
 Post subject:
PostPosted: Mon Apr 10, 2006 12:52 pm 
Offline
User avatar

Joined: Wed Sep 07, 2005 9:55 am
Posts: 299
Location: Phoenix, AZ
the problem was i over-complicated the situation. after sleeping for awhile i now have a better idea as to handleing the labels.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 14 posts ] 

All times are UTC - 7 hours


Who is online

Users browsing this forum: Bing [Bot], DragonDePlatino and 5 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group