Well I can't thank you enough for opening this can of worms.
It has got me fascinated with the build process.

So first thanks for your tips! I got the P2 to compile!
At this point I don't know if it will work because I jumped to another tangent in the process but it did build with both my neocart.x and neocartBank.x

Over the years I kinda automated things in my own broken way so I got less and less familiar with the inner workings of the makefile.
Plus I never really had a good grasp of it to begin with.

That said I am slowly realizing what is going on!

My typical makefile uses neocart.x and I have seperate makefiles for the 4 Banks of gfx data I am using that do indeed use neocartBank.x

I know that the more GFX I compile the larger the P rom gets. Since the GFX were compiled separately and they do not appear to be linked in the makefile that builds the P1 I was curious of how the P1 knows to inflate based on more GFX being built?

I came to realize that the makefiles have a .map file in the linker line. My legacy files of NeoDev don't have that.

-Wl,-T$(BASEDIR)/src/system/neocartBank.x -Xlinker -Map=_bankMap.map

When I cracked the file open the file reads this way. (There is more to the file than what is seen here but I can only guess that the files is generated from "neocart.x" or "neocartBank.x"

Memory Configuration Name Origin Length Attributes roma 0x00000000 0x00100000 xr ram 0x00100000 0x0000f000 xrw romb 0x00200000 0x00100000 xr *default* 0x00000000 0xffffffff Linker script and memory map 0x80000074 .=(0x80000000+SIZEOF_HEADERS)
This leads me to ask based is the configuration above of the output.map file setup to accept 8X the P! or is it limiting the data to only reside in the first 1mb of the P rom?

I would love to unlock romb as I believe I am living a life where roma is doing all the heavy lifting and eventually maxes out at 1mb.

this isn't my first kick at the can.

I exceeded roma here and was confused because I believe there should be more data built into at least the first mb of romb but I was lost then and still am now. lol
Upon reviewing the post I think my confusion was I thought GFX banks were identical to P banks when infact there is a difference.

topics/190747-roma-is-full-banko-section-text#post-7


I believe DATLib does something comparable to the NgDataLinker with the parsemap utility provided. I have been able to access my bank data via including defines with memory locations.

However this now has me fascinated....

In my current case each of my 4 makefiles / .xml files basically create GFX data every 8mbs via adjusting the fillmode then the parsemap utility provides address information that doesn't overlap I guess because the fillmodes have gaps in them.
(I could be wrong with what I'm saying here... factually...I have always been able to build and access all 4 banks of GFX data and reviewing the address information provided in the generated .h files it does not appear that the addresses overlap.)

Why I'm fascinated is because maybe now I can leave the filmodes alone and maybe set them all to something like '256' (Bank 0 has this...just going with that)
I'm think this way because if the rig can accommodate a setup where each mb of P2 points to a different bank information do I need to stagger banks when compiling them?

P2_1 -> Bank0, 0-1mb
P2_2 -> Bank1, 0-1mb
P2_3 -> Bank2, 0-1mb
P2_4 -> Bank3, 0-1mb

Oh wow I still might be able to build map tables into 4 more banks on top of what I already have above! EX:P_5-P8!!!!!?

I am thinking this...
I do realize I am limiting myself (technically P2 can be used for any data) but I would love to see if this rig could work...

P1 is only used for code and hardcoded tables etc
P2 is exclusive to GFX

Would this setup actually allow for the mixing of GFX from different banks in the same scene?
Is the secret in adjusting the neocart.x and neocartBank.x files....

These are mysteries that swirl in my head.

I know that incorporating DATlib is a little off topic as all your work is custom built on top of NeoDev but you ignited a spark and excitement is looming.
Any DATLib users that have mastered the art of romb please chime in if you could help with the working the angles on a 8mb P rom!!!!

I'm hyped up! Thanks for being patient as I stumble ozzyyzzo!