It is currently Fri Dec 15, 2017 11:03 am

All times are UTC - 7 hours





Post new topic Reply to topic  [ 8 posts ] 
Author Message
PostPosted: Wed Aug 02, 2017 8:07 pm 
Offline
User avatar

Joined: Sun Nov 09, 2008 9:18 pm
Posts: 1013
Location: Pennsylvania, USA
For both my past projects, I'd have .segment "ROMxx" peppered throughout multiple source files, and some equates in the corresponding modules for bank numbers which corresponded to the segment numbers. As you can imagine, that was hard to maintain. Now I'm managing all banks/segments with a single enum, like this:

Code:
//These are all in 8kb units, the smallest mmc3 can swap (i.e. each enum corresponds to a rom number in my cfg file that is an 8kb rom)
.enum
SOUND_ENGINE_BANK
ROBOT_ADVENTURE1_BANK
ROBOT_ADVENTURE2_BANK
ROBOT_ADVENTURE3_BANK
ROBOT_ADVENTURE4_BANK
ROBOT_ADVENTURE5_BANK
ENTITIES_BANK0
UNUSED_BANK7
UNUSED_BANK8
UNUSED_BANK9
UNUSED_BANK10
UNUSED_BANK11
UNUSED_BANK12
UNUSED_BANK13
UNUSED_BANK14
UNUSED_BANK15
UNUSED_BANK16
UNUSED_BANK17
UNUSED_BANK18
UNUSED_BANK19
UNUSED_BANK20
UNUSED_BANK21
UNUSED_BANK22
UNUSED_BANK23
UNUSED_BANK24
UNUSED_BANK25
UNUSED_BANK26
UNUSED_BANK27
UNUSED_BANK28
UNUSED_BANK29
UNUSED_BANK30
UNUSED_BANK31
MAP_BANK0
UNUSED_BANK33
UNUSED_BANK34
UNUSED_BANK35
UNUSED_BANK36
UNUSED_BANK37
UNUSED_BANK38
UNUSED_BANK39
UNUSED_BANK40
UNUSED_BANK41
UNUSED_BANK42
UNUSED_BANK43
UNUSED_BANK44
UNUSED_BANK45
UNUSED_BANK46
UNUSED_BANK47
NAMETABLE_BANK
UNUSED_BANK49
UNUSED_BANK50
UNUSED_BANK51
UNUSED_BANK52
UNUSED_BANK53
UNUSED_BANK54
UNUSED_BANK55
OVERLAY_BANK
UNUSED_BANK57
UNUSED_BANK58
UNUSED_BANK59
UNUSED_BANK60
UNUSED_BANK61
CODE
.endenum


I then use this in conjunction with a macro

Code:

.macro setseg num

    .segment .sprintf("%s%d", "ROM", num)

.endmacro



And use it like this:

Code:

setseg SOUND_ENGINE_BANK

//etc. etc.
.include "envelopes.inc"
.include "sfx.inc"



As a result, I can change the layout of what data is where in the ROM just by rearranging the above enum.

I'm doing something similar for chr-rom as well. Quite convenient.


Top
 Profile  
 
PostPosted: Thu Aug 03, 2017 8:22 am 
Offline
User avatar

Joined: Mon Jan 03, 2005 10:36 am
Posts: 2983
Location: Tampere, Finland
GradualGames wrote:
As a result, I can change the layout of what data is where in the ROM just by rearranging the above enum.

I don't really see why this would be useful. Why does it matter in what order the banks are?

Does your method differ from specifying the bank names in the linker config, other than giving you an easy access to the bank number?

_________________
Download STREEMERZ for NES from fauxgame.com! — Some other stuff I've done: kkfos.aspekt.fi


Top
 Profile  
 
PostPosted: Thu Aug 03, 2017 10:07 am 
Offline
User avatar

Joined: Sun Nov 09, 2008 9:18 pm
Posts: 1013
Location: Pennsylvania, USA
thefox wrote:
GradualGames wrote:
As a result, I can change the layout of what data is where in the ROM just by rearranging the above enum.

I don't really see why this would be useful. Why does it matter in what order the banks are?

Does your method differ from specifying the bank names in the linker config, other than giving you an easy access to the bank number?


In both my past projects, especially late in a project, what would happen is I'd have to rearrange things. Previously I just had ROMxx in my cfg, and .segment "ROMxx" spread throughout multiple source files. Parallel to those, I had equates in include files that corresponded to bank numbers, or bank numbers in lookup tables, etc. This way, I have it all in one place. If a bank overflows, it is easier to move things around, as I can see right away from the enum which things are occupying which roms. I had to inspect the .map file generated by the linker, previously, which wasn't quite as easy to follow. Fewer source files to maintain.

*edit* Is there some simpler way to do what I'm saying all from the cfg file or something? Like creating an equate alongside each memory area definition that gets exported from the cfg file...?


Top
 Profile  
 
PostPosted: Thu Aug 03, 2017 10:21 am 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19347
Location: NE Indiana, USA (NTSC)
Instead of calling the segment for a particular bank ROM23 in the SEGMENTS, you might call the segment LEVELDEFS. Then you can use the bank= property in MEMORY to associate a bank number with each memory area, which you can retrieve using <.bank(some_label) in other files that import some_label. (Bank numbers are allowed to be greater than 255, such as to incorporate information about a memory area other than just its bank number. The < is to tell the assembler that only the low 8 bits are important for purposes of range checking.)


Top
 Profile  
 
PostPosted: Thu Aug 03, 2017 1:00 pm 
Offline
User avatar

Joined: Sun Nov 09, 2008 9:18 pm
Posts: 1013
Location: Pennsylvania, USA
tepples wrote:
Instead of calling the segment for a particular bank ROM23 in the SEGMENTS, you might call the segment LEVELDEFS. Then you can use the bank= property in MEMORY to associate a bank number with each memory area, which you can retrieve using <.bank(some_label) in other files that import some_label. (Bank numbers are allowed to be greater than 255, such as to incorporate information about a memory area other than just its bank number. The < is to tell the assembler that only the low 8 bits are important for purposes of range checking.)


Interesting, wasn't aware of this feature. I kinda like the enum approach I came up with just cause it's a little cleaner to look at. I don't particularly like mucking with my cfg file.


Top
 Profile  
 
PostPosted: Fri Aug 04, 2017 1:07 am 
Offline
User avatar

Joined: Fri Feb 27, 2009 2:35 pm
Posts: 215
Location: Fort Wayne, Indiana
I made one main file for the project that lists all the banks and .includes, and all of the .segment stuff is kept out of the actual source files, at least without .pushseg and .popseg.

I make defines for individual resources I want within the banks (so I can move them to whatever bank and it doesn't matter, since that will update anything looking for it), and I switch to the bank that has the resource I want, though this means that I can end up doing unnecessary switching when the next thing I need is in the same bank as the one I was in.


Top
 Profile  
 
PostPosted: Fri Aug 04, 2017 7:09 am 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10164
Location: Rio de Janeiro - Brazil
NovaSquirrel wrote:
I made one main file for the project that lists all the banks and .includes, and all of the .segment stuff is kept out of the actual source files

Same here. Looking at the main file I see the structure of the entire ROM, and if I want to move something to another bank, I move the includes.

Quote:
I make defines for individual resources I want within the banks (so I can move them to whatever bank and it doesn't matter, since that will update anything looking for it)

There's no need for this, since ca65 can handle banks semi-automatically, like tepples said.


Top
 Profile  
 
PostPosted: Fri Aug 04, 2017 12:03 pm 
Offline
User avatar

Joined: Sun Nov 09, 2008 9:18 pm
Posts: 1013
Location: Pennsylvania, USA
GradualGames wrote:
tepples wrote:
Instead of calling the segment for a particular bank ROM23 in the SEGMENTS, you might call the segment LEVELDEFS. Then you can use the bank= property in MEMORY to associate a bank number with each memory area, which you can retrieve using <.bank(some_label) in other files that import some_label. (Bank numbers are allowed to be greater than 255, such as to incorporate information about a memory area other than just its bank number. The < is to tell the assembler that only the low 8 bits are important for purposes of range checking.)


Interesting, wasn't aware of this feature. I kinda like the enum approach I came up with just cause it's a little cleaner to look at. I don't particularly like mucking with my cfg file.


I think I finally understand how this works now. Any symbol defined within a given .segment will return the bank assigned within the cfg file with .bank, so you don't have to manually maintain individual bank #'s for individual bits of data, just use .bank. Right? I think I'll move to this...the enum approach above still requires me in some cases to create additional equates to smaller chunks of data which share the same bank...This way all you have to do is move your data/tables/code wherever you want and .bank will give you the right bank, no fiddling needed.

I should probably keep posting my other horrible ca65 hacks so I can learn the right way to use it :lol:


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

All times are UTC - 7 hours


Who is online

Users browsing this forum: Revenant and 8 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