# GBA MAX ROM Size?



## YoshiMoshi (Feb 3, 2019)

I am having difficulty fully understanding the maximum (MAX) read only memory (ROM) sizer for game boy advance (GBA) game cartridges.

Many sources online tell me that the GBA cartridge pin out has enough pins for a 24 bit address,
Pins 6-21: AD0-AD15
Pins 22-29: A16-A23

Using some emulator like visual boy advance (VBA) it can be seen that each address stores 16 bits of data, or 2 bytes. ROM files loaded into VBA appear to be nothing about a text file of American Standard Code for Information Interchange (ASCII) characters. Where each ASCII character is translated into 16 bits by the emulator. So the first character is the data stored in the ROM at the first address.

So the MAX ROM size supported by GBA cartridges is therefore
(2^24 addresses) * (16 bits/address) = 268435456 bits
268435456 bits = 268.435456 Mbits
268.435456 Mbits = 33.554432 Mbytes

However several sources online tell me that the MAX ROM size supported by the GBA is 32 Mbytes, yet I calculate 33.54432 Mbytes. I don't understand what I have done wrong. Any help would be appreciated.

Here's a source stating that the MAX ROM size is 32 Mbytes, which is not what I calculated.
https://www.neogaf.com/threads/what...-cartridge-sizes-of-certain-consoles.1069829/
Apparently Kingdom Hearts was 32 Mbytes


----------



## KleinesSinchen (Feb 3, 2019)

Simple: Do not use the decimal system to convert the data units:

1 kB = *1024 *byte (1024 = 2^10)
1 MB= *1024* kB
268435456 / (1024*1024*8) = 32

There are some GBA cartridges (movies) with bank switching - normally not found in GBA games - to achieve 64MB. As far as I know only the movies and no games used bank switching (which was common on GB(C) and NES).


----------



## YoshiMoshi (Feb 3, 2019)

do you know of any pictures showing the memory bank controller used in GBA cartridges (movies)? I'm wondering which one they used in retail games.

268435456 / (1024*1024*8) = 32

(1/268435456 b)(1/8 B/bit)(1/1024 kB/B)(1/1024 MB/kB)

ok got you, i don't know why google was telling me something different

I put into google 268435456 bits to megabytes and it gave me 33.554432


----------



## Coto (Feb 3, 2019)

it's 32 * 1024 * 1024 - 1 as addressable space. (starting from zero). After that there is mirrors of the same
address % (32 * 1024 * 1024 ) from within ROM offsets (at least an emulator behaves like that).

And that's due to how the GBA addressing was built:

*External Memory (Game Pak)*
  08000000-09FFFFFF   Game Pak ROM/FlashROM (max 32MB) - Wait State 0
  0A000000-0BFFFFFF   Game Pak ROM/FlashROM (max 32MB) - Wait State 1
  0C000000-0DFFFFFF   Game Pak ROM/FlashROM (max 32MB) - Wait State 2
  0E000000-0E00FFFF   Game Pak SRAM    (max 64 KBytes) - 8bit Bus width
  0E010000-0FFFFFFF   Not used

Or 1<<24 * 2 - 1 but I think (personal opinion) that was due to ninty standardizing halfwords (2 bytes) as the default transfer unit, because an ARM THUMB (2 bytes, halfword) opcode fits 2 times an ARM opcode (4 bytes, word). The prefetcher is 32bytes (that is 8 words or 16 halfwords). Same for the DMA's which only transfer as words or halfwords. So the bus (the address decoder ) could address hardware better.

source: https://problemkaputt.de/gbatek.htm#gbamemorymap

-

also the first 192 bytes are the gba rom header


----------



## FAST6191 (Feb 3, 2019)

The GBA ROM space is mapped by hardware to 08000000 through 09FFFFFF with a few mirrors in the GBA memory. No sector addressing so 32 megabytes (or 256 megabits if you prefer to go with that measurement method) directly mapped. Most homebrew development, ROM hacking, emulator authoring... guides will stick to this, or indeed even just the 08?????? range as most games were under 16 megs and most pointers only use the 08 values as the waitstates the different mirrors have are of limited use to most people. http://problemkaputt.de/gbatek.htm#gbamemorymap

As the GBA header kind of has to be there unless you load one thing and softboot into another, or maybe boot from the link port and jump across, then you have a little bit less space in practical terms but that is getting picky at this point.

While bankswitching was known (the NES uses it extensively) it was not used by commercial games other than those video files KleinesSinchen mentioned. https://mgba.io/2015/10/20/dumping-the-undumped/ is indeed the main link for info on that, though there is some source at the end of that which has more still.

NOR era flash carts often exceeded this size but it was usually done by setting pages and rebooting. Later flash carts of the NAND-PSRAM (later SD/CF-PSRAM) would copy things around to fast memory and then rebooting (soft or hard depending upon cart/loader/user). I don't know what communications these tended to use offhand to set things, though I don't think it was save bus based.

There were some homebrew programs which exceeded this limit. Pogoshell is probably the most notable. This required cart specific read code to handle, and needed to be baked in, so naturally was limited in the number of carts with support for such things. Today most just go with http://kuwanger.altervista.org/gba/pogoshell/ if they want such things.
Other homebrew things existed as well. Among the more notable would be the EZ3 (note this is different to EZ 3 in 1 expansion pack, which in turn had some fun with this for the 3 in 1+ that sported 512Mbit of NOR and multi loader kernels that got trialled briefly for the EZ5*, and rudolph's attempts to add it to GBA exploader) for which you can find the SDK still
https://ezflash.sosuke.com/viewtopic.php?t=150
PCEadvance got a version supporting the turboCD/PCE-CD because of the extra memory.
The GBAMP and probably Nintendo's play yan also have things here. Supercard and M3/G6 did also have some things here but nothing was released or done with them really.
By the time the DS rolled around nobody cared, though we did repeat the custom code and developer source release problem for the reading of flash carts and ultimately saw the advent of DLDI. Technically there are GBA versions of DLDI as well but very little ever did anything here -- some proof of concept emulators and I think I save dumper from the guy that actually made DLDI http://www.chishm.com/SendSave/index.html#cart_save

*I forget the version numbers, however the 3 in 1 plus family did not have the same amount of SRAM as NOR carts of the GBA era which meant two pokemon games could not happen at once and the EZTeam decided not to make pokemon an even bigger headache for them.

But yeah for most emulators, flash carts and practical purposes you have 32 megabytes of memory for a GBA cart. You can make any homebrew that size and as long as it fits on the cart (there are some smaller ones) it should not be a problem, and if you want to expand a commercial GBA ROM then go for it -- no banks/HiROM-LoROM/mbcs/... will get in your way on the GBA.


----------



## KleinesSinchen (Feb 3, 2019)

YoshiMoshi said:


> do you know of any pictures showing the memory bank controller used in GBA cartridges (movies)?



Took a while. I have too much stuff and constantly have to search for things;
The chip on the right is the mapper.


----------



## YoshiMoshi (Feb 3, 2019)

Wow. Well thanks for all the help! I understand now the MAX ROM size and there's lots of other helpful information that you guys posted for me. Thanks a bunch!


----------



## pumpkineater (Aug 19, 2019)

so how many games can u load? 
i have from a to Z gba roms , and only read till K


----------



## FAST6191 (Aug 19, 2019)

pumpkineater said:


> so how many games can u load?
> i have from a to Z gba roms , and only read till K



This thread is more about the maximum size of a GBA ROM that homebrew, hacking or otherwise can make use of.

Your question (assuming it is the same one from IRC) is how many ROMS can GBARunner2 view in its file selection option -- many embedded devices will have limits here as they don't have enough memory or coders did not expect people to want thousands of games. I don't know what goes there but seems like you have your answer (however many are in your collection before it lands somewhere in K). This might however be how many it can view in a single directory so either lose ones you don't care about or put things in their own collections in their own directories to make it have to read less.


----------

