Homebrew OPEN_AGB_FIRM discussion thread

AmandaRose

Do what I do. Hold tight and pretend it’s a plan
Member
Joined
Aug 19, 2015
Messages
10,190
Trophies
1
Location
Glasgow
Website
www.rockstarnorth.com
XP
16,146
Country
United Kingdom

Urbanshadow

Well-Known Member
Member
Joined
Oct 16, 2015
Messages
1,578
Trophies
0
Age
33
XP
1,723
Country
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,

VinsCool

Persona Secretiva Felineus
Global Moderator
Joined
Jan 7, 2014
Messages
14,600
Trophies
4
Location
Another World
Website
www.gbatemp.net
XP
25,207
Country
Canada
  • Like
Reactions: AmandaRose

Deleted member 323844

Well-Known Member
Member
Joined
Feb 17, 2013
Messages
802
Trophies
1
XP
2,335
Country
Spain
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

Sono

cripple piss
Developer
Joined
Oct 16, 2015
Messages
2,820
Trophies
2
Location
home
XP
9,310
Country
Hungary
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
 

AmandaRose

Do what I do. Hold tight and pretend it’s a plan
Member
Joined
Aug 19, 2015
Messages
10,190
Trophies
1
Location
Glasgow
Website
www.rockstarnorth.com
XP
16,146
Country
United Kingdom
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

Wolfvak

nyaa~
Member
Joined
Oct 25, 2015
Messages
918
Trophies
1
XP
3,386
Country
Uruguay
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

Deleted member 323844

Well-Known Member
Member
Joined
Feb 17, 2013
Messages
802
Trophies
1
XP
2,335
Country
Spain
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

General chit-chat
Help Users
    ButterScott101 @ ButterScott101: +1