Homebrew OPEN_AGB_FIRM discussion thread

  • Thread starter Thread starter Pickle_Rick
  • Start date Start date
  • Views Views 349,588
  • Replies Replies 991
  • Likes Likes 35
Here is a thread where two of the most knowledgeable people on the temp @FAST6191 and @KleinesSinchen confim that the Video Paks came on 64MB carts they also talk about how the carts use bank switching to get around the 32MB limit.
As long as they're all movie carts I think we are fine. Interesting fact tho.
 
Although not requiring CIA forwarders is a nice feature... Being compatible with them is certainly important if it ever becomes a true replacement for AGB_FIRM, part of the charm of using a 3DS is precisely having so many systems right in the native home menu.

Plainly impractical. A clever developer could workaround things to make something that looks like what you are thinking, but it just doesn't work like that.

OPEN_AGB_FIRM is a bootable .firm file for luma (or other bootloaders) with enough code to run GBA roms. This means after the bootloader, zero code from ninty runs. So no menu, no NAND, no apps, no cias, nothing. Absolutely zero. Nil. Nay. Nope.

This is meant for you to reboot your system and use a key combination to boot into this, just like you would enter on luma settings or get into gm9. I do agree a favorites list and pretty graphics could improve quality of life so I encourage everyone who has some development knowledge to go download the SDK, go fork the project and get things going. That's the kind of behaviour fueling a scene to greater good.
 
Last edited by Urbanshadow,
  • Like
Reactions: AmandaRose
Is there compatibility difference from the injection method? Or known issues so far?
As far as I tested it has the same performance/compatibility. Besides the savegame detection problem.

Offtopic: Can't the dma330as and ctr_firm_builder have a make install option? It's a pita to do it manually.
 
Last edited by Deleted member 323844,
  • Like
Reactions: VinsCool
I see there is a common theme of discussion in this thread: sizes.

It is not a problem with open_agb_firm! All open_agb_firm does is setup the GBA hardware, and from there it is real GBA hardware with custom-made hardware made to emulate common cartridge accessories, like RTC, along with very popular save storage methods like SRAM and EEPROM.

As for the 256Megabit (32Megabyte) limitation: that goes all the way back to the original GBA hardware. To put it simply, there are not enough lines to select where to read the data from, thus creating an arbitrary limitation.

This is the same reason why a byte can only store from 0 to 255, two bytes combined can represent 0 to 65535, etc. The amount of numbers you can represent is limited by the amount of bits/switches/lines you have, and the amount can be calculated from how many of you have. One byte is 8bits. You can toggle those bits on or off. If we count all possible on and off combinations, we get 256 possible combinations for 8 switches. The reason it's from 0 to 255 instead of 0 to 256 is because 0 is also part of the combination list (all bits are off). If you can't imagine this, have a list of numbers, and start counting from 0, and count 256 numbers. You'll count the 256th number being 255. Just as a sidenote, you can calculate the amount of unique combinations for a given switch count, which is 2 to the power of n, where n is the count of the switches. 2^8 is 256 for example.

Going back to the address line issue: even though a real GBA cart only has a 16bit address bus, it's doing some clever logic inside to decode the 16bit address into two 16bit values. The problem is however not on the cartridge side, but inside the GBA SoC: when Nintendo designed the GBA's memory map, they decided that 25bits of address space is more than enough. If you calculate the amount of bytes you can address with that much, you get that 2^25 / 1024 / 1024 == 32Megabytes.

The reason GBA Video can do more than that is because it actually includes a mapper chip. Mapper chips are special chips which help overcome this exact problem, where due to hardware limitations the system can't address more than a specific size. Usually they work by intercepting when you write into ROM (which stands for READ-ONLY memory). Because you can't rewrite READ-ONLY memory that way, it's perfectly valid to intercept the write, and mapper chips interpret these writes as commands. So by writing special values to special places in the ROM, you can tell the mapper how to setup the 32Megabyte addressible space as if you have soldered in new ROM chips.

tl;dr:
- 3DS contains real GBA hardware
- open_agb_firm is NOT AN EMULATOR!
- 32Megabyte limit is a hardware limitation
- GBA Video contains a special chip to overcome this limitation by letting the video player to tell the chip which parts of the ROM you want to read
 
I see there is a common theme of discussion in this thread: sizes.

It is not a problem with open_agb_firm! All open_agb_firm does is setup the GBA hardware, and from there it is real GBA hardware with custom-made hardware made to emulate common cartridge accessories, like RTC, along with very popular save storage methods like SRAM and EEPROM.

As for the 256Megabit (32Megabyte) limitation: that goes all the way back to the original GBA hardware. To put it simply, there are not enough lines to select where to read the data from, thus creating an arbitrary limitation.

This is the same reason why a byte can only store from 0 to 255, two bytes combined can represent 0 to 65535, etc. The amount of numbers you can represent is limited by the amount of bits/switches/lines you have, and the amount can be calculated from how many of you have. One byte is 8bits. You can toggle those bits on or off. If we count all possible on and off combinations, we get 256 possible combinations for 8 switches. The reason it's from 0 to 255 instead of 0 to 256 is because 0 is also part of the combination list (all bits are off). If you can't imagine this, have a list of numbers, and start counting from 0, and count 256 numbers. You'll count the 256th number being 255. Just as a sidenote, you can calculate the amount of unique combinations for a given switch count, which is 2 to the power of n, where n is the count of the switches. 2^8 is 256 for example.

Going back to the address line issue: even though a real GBA cart only has a 16bit address bus, it's doing some clever logic inside to decode the 16bit address into two 16bit values. The problem is however not on the cartridge side, but inside the GBA SoC: when Nintendo designed the GBA's memory map, they decided that 25bits of address space is more than enough. If you calculate the amount of bytes you can address with that much, you get that 2^25 / 1024 / 1024 == 32Megabytes.

The reason GBA Video can do more than that is because it actually includes a mapper chip. Mapper chips are special chips which help overcome this exact problem, where due to hardware limitations the system can't address more than a specific size. Usually they work by intercepting when you write into ROM (which stands for READ-ONLY memory). Because you can't rewrite READ-ONLY memory that way, it's perfectly valid to intercept the write, and mapper chips interpret these writes as commands. So by writing special values to special places in the ROM, you can tell the mapper how to setup the 32Megabyte addressible space as if you have soldered in new ROM chips.

tl;dr:
- 3DS contains real GBA hardware
- open_agb_firm is NOT AN EMULATOR!
- 32Megabyte limit is a hardware limitation
- GBA Video contains a special chip to overcome this limitation by letting the video player to tell the chip which parts of the ROM you want to read
Exactly what I said about GBA video using bank switching.
 
  • Like
Reactions: Sono
I'm a very lazy person and was wondering if anyone has done a small video showing this working ?
There's not much to see.

Its just a text menu with the list of roms and then the game in fullscreen bilinear filtered. The only difference with an injected game will be the bottom screen.
 
Plainly impractical. A clever developer could workaround things to make something that looks like what you are thinking, but it just doesn't work like that.

OPEN_AGB_FIRM is a bootable .firm file for luma (or other bootloaders) with enough code to run GBA roms. This means after the bootloader, zero code from ninty runs. So no menu, no NAND, no apps, no cias, nothing. Absolutely zero. Nil. Nay. Nope.

This is meant for you to reboot your system and use a key combination to boot into this, just like you would enter on luma settings or get into gm9. I do agree a favorites list and pretty graphics could improve quality of life so I encourage everyone who has some development knowledge to go download the SDK, go fork the project and get things going. That's the kind of behaviour fueling a scene to greater good.

We were thinking of doing something more similar to A9SP or the stock firmlaunch where we just put a bunch of data loaded into FCRAM (aligned to some address), then when open_agb_firm boots it'd just have to check a few locations in memory - FCRAM isn't actually properly cleared on reboot. Don't know how doable it'd be for 32MiB carts, since it needs to be loaded into a single physically contiguous location.

(there's this for reference https://github.com/d0k3/GodMode9/blob/master/arm9/source/godmode.c#L2100)
 
Last edited by Wolfvak, , Reason: added code link
  • Like
Reactions: Nutez and peteruk
Ok, thanks for the polite and speedy reply

I'll have a bash over the weekend
I made a little video xD

XpOhGk0.gif
 

Site & Scene News

Popular threads in this forum