Ok, why the hell are GBA games so big in megs?

[DeadlyNinja]

Keep in mind that when I say megs, I mean megabits, not megabytes.

I remember during the N64 days, people were complaining about the storage size and cost of making an N64 games. To make a bigger game, you need a bigger cart. A bigger cart would increase the price of the game as well. And of course, there's a limit to how big to can store in a cart. You rarely see that many 256 meg games, let alone 512 megs on the N64. But when the GBA came around, it seems like EVERYONE was spamming megs without any worry. I can understand the advance in technology means cheaper rom prices, but it still doesn't explain a few things about why GBA game as so big.

Let's take the Mario World remake for example. The game was 32 megs compared to to the original 4 meg SNES version. WTF? You're telling me the inclusion of the damn arcade Mario Bros added another 28 megs to the cart? Let's not forget that Super Mario Allstars was but a mere 16 megs with 4 freaking games in one. Why in gods name is the GBA port so big?

When you look at it closer, it makes even less sense considering the GBA graphics are lower resolution than the original SNES -- hell, it wasn't even up to NES standards. I thought lower resolution meant less memory; or do I suck that badly at math?

This isn't just an issue with remakes, either. You take a look at the new games and VERY FEW (not all) seem to be as big as the meg size claims to be. I mean, I can justify Kingdom Hearts due to the FMVs, and even the crappy Disney licensed 64 meg games contains a few short FMV movie clips. I can't say the same for 95% of the GBA library, though.

What exactly is causing GBA games to inflate to such sizes? Is it sloppy programming? Did rom prices fall so low all of a sudden that making a 4 meg game would cost (when I say cost, I'm talking about the cost of the rom, not the cost of developing a game) the same as a 32 meg game?

Someone please enlighten me.

 

[Skrying]

I don't think you realize but the size you're seeing is of the ROM, which means it's the total capacity of the cart and not exactly how much data there "literally" is. It is probably much cheaper to make a ton of one size and put smaller games on those...

 

[I.S.T.]

Plus, 32-bit code is bigger than 16 bit...

 

[DeadlyNinja]

What you said kind of makes sense, but doesn't actually make that much sense.

Again, third parties were all "big cart prices killed my family and raped my first born" during the N64 era, and having to pay for a 64 meg cart even though they only require 16 megs sounds like madness to me. Some games don't seem that much bigger compared to it's predecessor. Take Advance Wars 1 and 2 BOTH on the GBA. The first game on GBA was 32 megs, while the sequel was 64 megs. The sequel only added a few extra characters and 1 single new unit added to the entire game. And even though there are more character portraits, they lost they different the facial expressions compared to the prequel. Now, I'm sure on the outside it might not be that much different, and maybe the programming's been improved, but it is safe to assume graphics and sound take up the most amount of space on any game on any system, correct? Advance Wars is a Nintendo game, they would know how to make the best use out of their hardware.

Plus, 32-bit code is bigger than 16 bit...

Hmm, now that does make sense, but is the GBA really 32 bit? I haven't read any technical docs on it, and probably wouldn't understand it anyway. But then what about the N64? The darn thing is 64 bit, and I find the N64 games of the same size to be much bigger than a game of the same size on the GBA. Although I understand there's quite a bit of difference between using 3D graphics than 2D sprites, especially with animation.

 

[I.S.T.]

It is. Now, that's only part of the reason, mind you... >.>

as for the pricing issue, you're forgetting that as time passes, smaller cart ROMs stop being manufactured, and bigger ones take their place.

 

[Skrying]

It makes perfect sense and it's likely what happened, it's highly advantageous to simply make a cartridge size the vast majority can use and then make slightly larger ones where needed. If your volume was say 80% need 64, 10% larger, and 10% smaller, I think you'd throw that 10% of the smaller into the 80% as producing a second line of 10% would be very expensive.

 

[arjan de lumens]

What exactly is causing GBA games to inflate to such sizes? Is it sloppy programming? Did rom prices fall so low all of a sudden that making a 4 meg game would cost (when I say cost, I'm talking about the cost of the rom, not the cost of developing a game) the same as a 32 meg game?

Someone please enlighten me.

The ROM may be pad-limited - that is, the physical size of the ROM chip is limited not by its megabit capacity but by the number of pins/pads connecting it to the outside world. Once a ROM (or any other chip, for that matter) is pad-limited, reducing its capacity any further will not save any costs.

 

[Fox5]

I think most GBA games were 8 MB or 16MB (multiply by 4 to get megabits). There were a very few 4MB games, and a handful of 32MB. Not sure if any made it to 64MB.
N64 ranged from 8MB to 64MB, with very few 64MB carts.
I think DS has broken the 128MB barrier, albeit they use flash ram right?

Anyhow, I think a new ROM production technology came out around the time of GBA allowing for cheaper ROM costs, along with the just ever decreasing cost of ROM production anyway. 32MB was an additional cost on n64, would have been insanely expensive for SNES, and impossible for the NES, but by the time GBA came around it was affordable.

I wonder why nintendo didn't just go with flashram in their gba carts though? Plenty of rewritable carts would produced for gba (as well as other systems retroactively) using that.

 

[archie4oz]

Hmm, now that does make sense, but is the GBA really 32 bit? I haven't read any technical docs on it, and probably wouldn't understand it anyway. But then what about the N64? The darn thing is 64 bit, and I find the N64 games of the same size to be much bigger than a game of the same size on the GBA. Although I understand there's quite a bit of difference between using 3D graphics than 2D sprites, especially with animation.

Yes it is. No the N64 is noty 64-bit in the sense that it's opcodes are 64-bit or is using 64-bit pointers.

Plus, 32-bit code is bigger than 16 bit...

65C816 code is pretty tight, but then again so is ARM Thumb (which are also 16-bit operands). The ARM binary will be bigger than the MOS binary, but certainly not double.

I wonder why nintendo didn't just go with flashram in their gba carts though? Plenty of rewritable carts would produced for gba (as well as other systems retroactively) using that.

NAND flash would probably come maybe close to masked ROMS in cost, however NAND flash isn't directly addressable (it's accessed in blocks), so you can't execute code directly from an arbitrary address.

 

[Fox5]

NAND flash would probably come maybe close to masked ROMS in cost, however NAND flash isn't directly addressable (it's accessed in blocks), so you can't execute code directly from an arbitrary address.

Hmm, didn't Nintendo switch to flash with the DS anyway though? I've gotta say though, with what little assembly programming I've done (MIPS) and thinking about having to deal with memory management on a system with as low memory as the GBA...it just sounds painful.

 

[see colon]

Hmm, didn't Nintendo switch to flash with the DS anyway though? I've gotta say though, with what little assembly programming I've done (MIPS) and thinking about having to deal with memory management on a system with as low memory as the GBA...it just sounds painful.

Exactly. That's why the DS has so much RAM (compared to the GBA).

 

[Cheezdoodles]

When you look at it closer, it makes even less sense considering the GBA graphics are lower resolution than the original SNES -- hell, it wasn't even up to NES standards. I thought lower resolution meant less memory; or do I suck that badly at math?

What resolution the game is rendered in is irrelevant for how big the game is, only how much RAM you use for framebuffers.

Ofcourse if they have lower resolution textures than the SNES, then it should take less space.

 

[fearsomepirate]

What resolution the game is rendered in is irrelevant for how big the game is

It is for 2D games where you use smaller sprites and backgrounds at a lower resolution.

 

[swaaye]

Yes it is. No the N64 is noty 64-bit in the sense that it's opcodes are 64-bit or is using 64-bit pointers.

VR4300 is a 64-bit CPU, but N64 was using it in its 32-bit mode, correct? It made little sense back then to use 64-bit data types and addressing for games. It also would've had big consequences for cache hit rate and the already crappy CPU->RAM access performance. (correct me if i'm way off course here lol)