gbadev.org forum archive

This is a read-only mirror of the content originally found on forum.gbadev.org (now offline), salvaged from Wayback machine copies. A new forum can be found here.

DS development > possible vram layouts

#170457 - vuurrobin - Sun Sep 27, 2009 2:54 pm

hello everybody,

for my DSOL library, I'm planning to allow different preset vram layouts so that people still have some control over them without actually have to worry about setting them correctly. I already have some layouts, but if someone has improvements or new layouts, I would be glad to hear them.

note that I'm currently only focusing on 2d, so nothing will be mapped to 3d stuff.


the layouts:


standard:
vram A-D will be divided between sprites and backgrounds, vram F-I will be used for extended palettes.
vram E goes unused.
AFAIK, this is what palib has.

background plus:
vram A-B will be used for main backgrounds and vram E for main sprites. the rest is the same as standard.

sprite plus:
vram A-B will be used for main sprites and vram E for main background. the rest is the same as standard.

background max:
vram A-D will be used for main backgrounds, vram E and (hopefully) G for main sprites, vram F for main background extended palettes and vram H-I for sub backgrounds and sprites.

main plus:
vram A-B will be used for main backgrounds, vram C-D for main sprites, vram F-G for extended palettes and H-I for sub background and sub sprites. vram E goes unused.


I think that this are all possible layouts where you can get the most of vram, as far as 2d go (I don't think that most people will use vram as ARM7 work ram).

comments, ideas, improvements or new layouts? post them :)
_________________
my blog:
http://vuurrobin.100webcustomers.com/

Last edited by vuurrobin on Mon Sep 28, 2009 10:11 pm; edited 1 time in total

#170461 - sverx - Mon Sep 28, 2009 10:12 am

Hi
it's since some time I was thinking also to do something similar, so I think we can join efforts, if you don't mind :)

I personally was thinking about giving different choices considering to have BGs and sprite both ON, extended palettes optional. Of course we've got two video engines using the 9 VRAM banks and we should take care of it, you know.

BGs can use 16/32/64/80/96/128/256/384/512 KB on main engine and 32/48/128 KB on sub engine, sprites can use 16/32/64/128/256 on main engine and 16/128 on sub engine (I've still got to check all these configurations, thought... see this -> http://dev-scene.com/NDS/NDS_Tutorials_VramTable )

I was thinking about calling a single function to set up everything at once. Was that your idea too?

#170464 - hacker013 - Mon Sep 28, 2009 7:44 pm

Everybody who uses arm7 sound decoding uses vramd for the arm7, so I think you should keep that option.
_________________
Website / Blog

Let the nds be with you.

#170468 - AntonioND - Mon Sep 28, 2009 9:42 pm

hacker013 wrote:
Everybody who uses arm7 sound decoding uses vramd for the arm7, so I think you should keep that option.

Uhmm... No, not really. In fact, I've only seen VRAM assigned to ARM7 in nds loaders...

#170469 - vuurrobin - Mon Sep 28, 2009 10:10 pm

@sverx, I would be happy to join efforts to find those vram layouts :) .

I think we should always try to use as many vram banks as possible, and to always have some vram mapped to backgrounds and sprites, both main and sub (which I don't think should be that hard). I probably will also allow the user to set its own layout, because I doubt we will find all layouts.

as for the actual implementation, I'm putting every layout in its own function, so it will make it easier to work with. I'm not sure if the user will directly call these functions or that I will create an vramInit function or something.
but I think that our implementation will be somewhat different, seeing as mine will have some DSOL specific stuff ;)
here is an example of such a function:
Code:
void vramLayoutStandard()
{
    vramSetBankA(VRAM_A_MAIN_SPRITE_0x06400000);
   vramSetBankB(VRAM_B_MAIN_BG_0x06000000);
    vramSetBankC(VRAM_C_SUB_BG_0x06200000);
    vramSetBankD(VRAM_D_SUB_SPRITE);

    //not used
    //vramSetBankE();

    vramSetBankF(VRAM_F_BG_EXT_PALETTE);//main background palettes
    vramSetBankG(VRAM_G_SPRITE_EXT_PALETTE);//main sprites palettes
    vramSetBankH(VRAM_H_SUB_BG_EXT_PALETTE);//sub background palettes
    vramSetBankI(VRAM_I_SUB_SPRITE_EXT_PALETTE);//sub sprites palettes


   //allow both tiled and bitmap sprites, and using extended palettes
   oamInit(&oamMain, SpriteMapping_Bmp_1D_128, true);
   oamInit(&oamSub, SpriteMapping_Bmp_1D_128, true);
        //other DSOL specific stuff, like enabling extended sprites
}



I haven't checked them all, but I think you're fairly spot on with those configurations. but now we have to see how we can fit them together.

@hacker013, I think most people will use maxmod, which AFAIK doesn't use the vram. and if people want to use it, then they will have the option to set it themselves.


@AntonioND, what do you mean by nds loaders? are you talking about programs that run *.nds files, like the homebrewmenu?


anyway, I have added another vram layout, main plus:
vram A-B will be used for main backgrounds, vram C-D for main sprites, vram F-G for extended palettes and H-I for sub background and sub sprites. vram E goes unused.
_________________
my blog:
http://vuurrobin.100webcustomers.com/

#170471 - AntonioND - Mon Sep 28, 2009 11:15 pm

vuurrobin wrote:
@AntonioND, what do you mean by nds loaders? are you talking about programs that run *.nds files, like the homebrewmenu?
Yes, that kind of programs Is the only one I've seen that use VRAM for ARM7.

#170475 - Tommmie - Tue Sep 29, 2009 6:29 am

just look at dsorganize or moonshell and you've some other programs that uses vram for sound decoding(and something they call save_malloc).

#170478 - AntonioND - Tue Sep 29, 2009 8:43 am

But most programs don't need that. DSorganize and moonshell are quite special programs.

#170479 - sverx - Tue Sep 29, 2009 9:42 am

vuurrobin wrote:
I think we should always try to use as many vram banks as possible, and to always have some vram mapped to backgrounds and sprites, both main and sub [...]


Personally I think we should define many options and implement them using the fewer vram banks as possible, also leaving bank C and/or bank D free when possible.

I would define some values (defines or enums) both for main and for sub to describe BGs/Sprite/ExtPal configurations, and activate them using a function (or method I guess ;) ) that accepts the two parameters: MAIN and SUB engines mode.

For instance we could have something like

Code:

#define MAIN_BG_128K_SPR_128K             1
#define MAIN_BG_128K_SPR_256K             2
// other ...

#define MAIN_BG_EXT_PAL                   0x100
#define MAIN_SPR_EXT_PAL                  0x200
// ... maybe also BG 'half' extended palette?

// then even define constants for most common ones...?
#define MAIN_BG_128K_SPR_128K_BG_EXT_PAL  (MAIN_BG_128K_SPR_128K | MAIN_BG_EXT_PAL)


and so on, with something similar for SUB engine.

Then the function assigns and activate the vram banks and returns 0 on success and another code on failure (maybe somebody's trying to ask too much...)

Of course we should define how banks will be mapped to modes. I guess you want to start from this, right?

#170488 - hacker013 - Tue Sep 29, 2009 3:23 pm

AntonioND wrote:
But most programs don't need that. DSorganize and moonshell are quite special programs.


I think it is important enough to keep if you ask me ;) And I use it also.
_________________
Website / Blog

Let the nds be with you.

#170530 - vuurrobin - Wed Sep 30, 2009 7:12 pm

@sverx, why would you want to use as fewer vram banks as possible? it seems kind of a waste if you ask me.

using defines like that means that you would have to calculate where to map the vram banks at runtime. this means that the user would have to code, compile and run it just to see if its possible. it would also mean that the user has to check for an error, which it may forget and thus introducing bugs that may be hard to find.

I think that vram layout should be decided during compile time, so it doesn't have to be done at runtime.


hacker013 wrote:
AntonioND wrote:
But most programs don't need that. DSorganize and moonshell are quite special programs.


I think it is important enough to keep if you ask me ;) And I use it also.


anybody that uses vram for ARM7 is modifying the default ARM7 code. if you need an custom ARM7 core, then I think setting the vram banks yourself should be easy compared to the actual ARM7 code. and I already said that I will allow the option to set the vram banks yourself in DSOL.
_________________
my blog:
http://vuurrobin.100webcustomers.com/

#170540 - sverx - Thu Oct 01, 2009 11:56 am

vuurrobin wrote:
using defines like that means that you would have to calculate where to map the vram banks at runtime. this means that the user would have to code, compile and run it just to see if its possible. it would also mean that the user has to check for an error, which it may forget and thus introducing bugs that may be hard to find.

I think that vram layout should be decided during compile time, so it doesn't have to be done at runtime.


I see. So that means to define all the possible (or at least some among the most interesting ones) configurations of BOTH the main and sub engine and give them a name, then create a document where for each configuration we describe how much memory goes to BGs, how much for sprites and so on. Is that your idea?

#170542 - vuurrobin - Thu Oct 01, 2009 1:16 pm

pretty much, yes.


to be honest, I think that the standard layout would be enough for most people (at least for most people comming from palib)
_________________
my blog:
http://vuurrobin.100webcustomers.com/

#170545 - sverx - Thu Oct 01, 2009 4:39 pm

vuurrobin wrote:
I think that the standard layout would be enough for most people (at least for most people comming from palib)


Well, it's 128KB for BGs and 128KB for sprites for both main and sub, and it has all the possible extended palette (BGs/sprite main/sub) activated, so it's very flexible. But I do think some people would need some more memory for the main engine. In one of the projects I'm working on, I'm using 256KB for sprites on main, for instance (well, also 128KB for textures, but it's unrelated) and I had to drop some extended palettes (we don't have 10 banks...).

So now I'm actually quite interested in knowing how other developer mapped the vram banks in their projects...

Anybody?