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 > VRAM Mapping for Sprites in Main Screen

#142025 - conejoroy - Wed Oct 03, 2007 10:27 am

Hello ^^!

It is possible to assign VRAM banks B, E and F (208 Kb) to main sprites? I mean... they can work all together? I was thinking on this allocations:

VRAM_E: 0x06400000 to 0x0640FFFF (well its fixed anyway =p)
VRAM_F: 0x06410000 to 0x06413FFF
VRAM_B: 0x06420000 to 0x0643FFFF

but it leaves a "black hole" between 0x06413FFF and 0x06420000 (48kb)

is it possible to use this arrangement (of course without addressing sprites in that undefined offset)?. I know maybe it's weird, even I don't know if it's possible, but all other vram banks are taken and I need every kb I can get...

Well thanks ^^!!

#142034 - knight0fdragon - Wed Oct 03, 2007 3:50 pm

IIRC on the main screen, only 2 Banks can be used at max, and I think they have to be A and B, but I am not too sure on that one, allowing for a max of 256k.

Sub screen allows only 1 bank at max 128k

look here for more details

http://nocash.emubase.de/gbatek.htm#dsmemorycontrolvram
_________________
http://www.myspace.com/knight0fdragonds

MK DS FC: Dragon 330772 075464
AC WW FC: Anthony SamsClub 1933-3433-9458
MPFH: Dragon 0215 4231 1206

#142040 - keldon - Wed Oct 03, 2007 6:23 pm

I always read that as you can have AB, or EFG. Not sure about B,E and F though. What exactly are you trying to achieve?

#142044 - ingramb - Wed Oct 03, 2007 7:34 pm

From gbatek
Quote:
VRAM SIZE MST OFS ARM9, 2D Graphics Engine A, OBJ-VRAM (max 256K)
A,B 128K 2 0..1 6400000h+(20000h*OFS.0) ;(OFS.1 must be zero)
E 64K 2 - 6400000h
F,G 16K 2 0..3 6400000h+(4000h*OFS.0)+(10000h*OFS.1)

It looks like you could assign B to 6420000h, E to 6400000h, and F to 6410000h. Haven't tried it, but don't see why it couldn't work.

Edit: and reading your message again, this is exactly what you said. But anway, I still think it will work.

#142046 - conejoroy - Wed Oct 03, 2007 8:12 pm

Thanks =)

Yes, it's theoretically possible... I arranged vram that way and it seems to work fine, at least the first bytes at 0x06400000, I didn't test storing/addressing a sprite above the 48kb "black hole".. I'll try that soon ^^

Why to do this? any other vram bank is allocated for other purposes, so either I live with "just" 128Kb of B for Main OBJ, or I try to allocate E and F to use their 80Kb for Main OBJ too; for a total of 208Kb in 2 segments of 128 and 80Kb.

If this works the only "problem" will be the unmapped area between F and B, but that offsets can be avoided. it's like working with 256Kb but with a missing 48kb in the middle xD

It sounds crazy that's why I'm in doubt, but it seems possible =)

#142056 - conejoroy - Thu Oct 04, 2007 12:28 am

Confirmed: it works =P!!

#142058 - knight0fdragon - Thu Oct 04, 2007 12:34 am

if it does work, wouldnt it create holes in your tile indexing?


LOL wow sorry fixed that
_________________
http://www.myspace.com/knight0fdragonds

MK DS FC: Dragon 330772 075464
AC WW FC: Anthony SamsClub 1933-3433-9458
MPFH: Dragon 0215 4231 1206

Last edited by knight0fdragon on Thu Oct 04, 2007 4:45 pm; edited 1 time in total

#142069 - conejoroy - Thu Oct 04, 2007 2:15 am

knight0fdragon wrote:
if it does work, wouldnt it create games in your tile indexing?


Hm... I'm afraid I don't understand what you mean T__T

#142073 - edwdig - Thu Oct 04, 2007 3:20 am

knight0fdragon wrote:
if it does work, wouldnt it create games in your tile indexing?


Assuming he's got a system for dynamically allocating the tiles, the easiest thing to do is create a map large enough for the full 256 KB range, but mark the 48 KB hole as used.

#142111 - knight0fdragon - Thu Oct 04, 2007 4:37 pm

conejoroy wrote:
knight0fdragon wrote:
if it does work, wouldnt it create games in your tile indexing?


Hm... I'm afraid I don't understand what you mean T__T


I meant to say holes not game :-\
The tile index in the OAM memory for each sprite. it is limited to 1023
now if you are using multiple banks, that are not 128k, you will be losing a lot of these indexes.

edwdig wrote:
knight0fdragon wrote:
if it does work, wouldnt it create games in your tile indexing?


Assuming he's got a system for dynamically allocating the tiles, the easiest thing to do is create a map large enough for the full 256 KB range, but mark the 48 KB hole as used.


We are talkin about OAM, not BG
_________________
http://www.myspace.com/knight0fdragonds

MK DS FC: Dragon 330772 075464
AC WW FC: Anthony SamsClub 1933-3433-9458
MPFH: Dragon 0215 4231 1206

#142131 - edwdig - Thu Oct 04, 2007 10:17 pm

knight0fdragon wrote:

The tile index in the OAM memory for each sprite. it is limited to 1023
now if you are using multiple banks, that are not 128k, you will be losing a lot of these indexes.


Yes, he'd lose 192 of them. Considering his VRAM needs, he probably has a lot of relatively large sprites, so it probably isn't that big of a deal.

knight0fdragon wrote:

edwdig wrote:
knight0fdragon wrote:
if it does work, wouldnt it create games in your tile indexing?


Assuming he's got a system for dynamically allocating the tiles, the easiest thing to do is create a map large enough for the full 256 KB range, but mark the 48 KB hole as used.


We are talkin about OAM, not BG


So am I. By "map" I mean "area of memory keeping track of what portions of the tile memory are in use". To be used by his code when determining where he can place sprites in VRAM.

#142396 - conejoroy - Mon Oct 08, 2007 10:38 pm

edwdig wrote:
knight0fdragon wrote:

The tile index in the OAM memory for each sprite. it is limited to 1023
now if you are using multiple banks, that are not 128k, you will be losing a lot of these indexes.


Yes, he'd lose 192 of them. Considering his VRAM needs, he probably has a lot of relatively large sprites, so it probably isn't that big of a deal.


He's right =p I dont have anything below 256 bytes (everything 16x16 or more, 8 bits) so I won't waste any memory indexing at 256 bytes =)

Well I'm glad this worked out just fine, thanks n.n!!