Homebrew OPEN_AGB_FIRM discussion thread
- Thread starter Pickle_Rick
- Start date
- Views 244,520
- Replies 911
- Likes 35
Could someone clearly explain how to change the brightness? I see no configuration file in the source code, someone said that there is a commit that produced a configuration file, I see none. The games are too dark, the normal full brightness is cut in half, hardly enjoyable gameplay. Thx.
When you use for the first time the open_agb_firm.firm a file called config.ini is created onto the "sd:/3ds/open_agb_firm/" path. Then you can edit the respective parameters on that file using a simple text editor
Okay, thanks, changing backlit from 40 to 50 solved the problem! Now is everything perfect. By the way the main benefit of the OPEN_AGB_FIRM is the sound, it is great now, before all the emulators including VJ had the crackling sound that really sucked. No one mentions it for some reason.
The crackling sound is a result of games not running fullspeed and the emulators not interpolating the difference. So its really more of a speed than an audio problem. This also varies greatly from game to game as some run perfect on mGBA and others are a stuttery mess and everything inbetween.
New commit: Converted most I/O reg defines to structs for better optimization.
Compiled (1/2/3 are the three filters): https://archive.org/download/strannoCOMPrepo/open_agb_firm.49820dc.7z
Compiled (1/2/3 are the three filters): https://archive.org/download/strannoCOMPrepo/open_agb_firm.49820dc.7z
Anyone who has a WORKING cia from a rom should be able to id the savetype properly for open_agb_firm purposes, unless there's something i'm misunderstanding. the cia converters expect there to be a footer to identify save type.
I also remember there being some deal that only one type of eeprom save is actually supported by AGB_FIRM to begin with. (EEPROM_V124). Stuff that uses v122 (annoyingly common) will simply not save properly without patching the game itself.
does open_agb_firm get around that, and support other eeprom types that agb_firm does not?
I also remember there being some deal that only one type of eeprom save is actually supported by AGB_FIRM to begin with. (EEPROM_V124). Stuff that uses v122 (annoyingly common) will simply not save properly without patching the game itself.
does open_agb_firm get around that, and support other eeprom types that agb_firm does not?
This is made from scratch, so OPEN_AGB_FIRM can't even read what a footer generated from an official GBA CIA is.
Those PC programs can only read/write the information as a setting, then is the AGB_FIRM what reads and knows how to execute those instructions. OPEN_AGB_FIRM, however, can´t do that and won't in any future soon as its main goal is to work completely different and in its own way.
Well, there's a number of possibilities.
1) game has 1 sdk string, and saves. This is what we hope. but the sdk string won't always reveal the size. emulators generally can just read the protocol during initialization and pick the right size when more than one are possible. We probably don't need to check a database, BUT....
2) same, but the game actually has a smaller save type, and it's doing an antipiracy check. for this case we need an exception list to catch those games that lie.
3) game has one sdk string, but it's just AP and the cart doesn't have any save. it expects the save to fail. this also needs an exception. Any save type can cause this.
4) game has multiple sdk strings, and doesn't actually save. it's all antipiracy. Because there are multiple strings, we KNOW we need to check the database.
5) game has multiple sdk strings, but only one of them is real, and the rest are antipiracy. We know we need to check the database.
There's also the wrinkle of flash manufacturer. I dunno if any games actually check the flash manufacturer for antipiracy, but you need to emulate a manufacturer supported in that SDK version or the game cannot save.
If we can reliably determine the SDK version from inspecting the .gba file, we can pick a supported manufacturer code. Hopefully the manufacturer is never actually used as antipiracy...
i suspect this list of exceptions by 4 character game code will be of use. these are games that vba-m can't autodetect properly.
vba seems to have some heuristics for how to handle multi strings. It processes them in the order it finds them.
Flash overrides no other strings. If ANY other strings are first, it's ignored.
SRAM overrides all others EXCEPT flash with a number, which is not overrode.
EEPROM overrides flash WITHOUT a number, but not flash WITH a number or SRAM.
Default flash size is 0x10000, unless it's FLASH1m, then it gets set to 0x20000.
But there are also overrides for the autodetection, based on 4 character game code from the rom header area. They are all listed in vba-over.ini in the source.
Classic nes/fc series games need special support, because they mirror the program rom 4 times (nothing else actually does this). as noted the are all eeprom4 EXCEPT for Zelda2, which is eeprom64.
This particular heuristic seems to give the smallest number of false positives. you can then check vb_over.ini to work out the overrides. there are only 103 of them.
VBA (and most other emulators) actually decides what the size of the eeprom is at first read. This seems to work. could OPEN_AGB_FIRM do the same thing, or is there some reason it won't work?
if (cpuDmaCount == 0x11 || cpuDmaCount == 0x51) {
if (eepromBits == 0x11) {
eepromInUse = true;
eepromSize = SIZE_EEPROM_8K;
as for flash manufacturers, i'm guessing this is already solved, since vba just uses one for small flash and one for large flash, so its' probably doing the same thing.
vba does sometimes autodetect the RTC. it never autodetects a sensor.
The pokemon games all lie about their flash size as a form of antipiracy, and actually use the bigger one.
Other games lie about their flash size and actually use the smaller one.
Top gun is the only multi string game that doesn't actually save.
the 103 figure includes undetected RTCs. 32 of them are pokemon games.
1) game has 1 sdk string, and saves. This is what we hope. but the sdk string won't always reveal the size. emulators generally can just read the protocol during initialization and pick the right size when more than one are possible. We probably don't need to check a database, BUT....
2) same, but the game actually has a smaller save type, and it's doing an antipiracy check. for this case we need an exception list to catch those games that lie.
3) game has one sdk string, but it's just AP and the cart doesn't have any save. it expects the save to fail. this also needs an exception. Any save type can cause this.
4) game has multiple sdk strings, and doesn't actually save. it's all antipiracy. Because there are multiple strings, we KNOW we need to check the database.
5) game has multiple sdk strings, but only one of them is real, and the rest are antipiracy. We know we need to check the database.
There's also the wrinkle of flash manufacturer. I dunno if any games actually check the flash manufacturer for antipiracy, but you need to emulate a manufacturer supported in that SDK version or the game cannot save.
If we can reliably determine the SDK version from inspecting the .gba file, we can pick a supported manufacturer code. Hopefully the manufacturer is never actually used as antipiracy...
i suspect this list of exceptions by 4 character game code will be of use. these are games that vba-m can't autodetect properly.
vba seems to have some heuristics for how to handle multi strings. It processes them in the order it finds them.
Flash overrides no other strings. If ANY other strings are first, it's ignored.
SRAM overrides all others EXCEPT flash with a number, which is not overrode.
EEPROM overrides flash WITHOUT a number, but not flash WITH a number or SRAM.
Default flash size is 0x10000, unless it's FLASH1m, then it gets set to 0x20000.
But there are also overrides for the autodetection, based on 4 character game code from the rom header area. They are all listed in vba-over.ini in the source.
Classic nes/fc series games need special support, because they mirror the program rom 4 times (nothing else actually does this). as noted the are all eeprom4 EXCEPT for Zelda2, which is eeprom64.
This particular heuristic seems to give the smallest number of false positives. you can then check vb_over.ini to work out the overrides. there are only 103 of them.
VBA (and most other emulators) actually decides what the size of the eeprom is at first read. This seems to work. could OPEN_AGB_FIRM do the same thing, or is there some reason it won't work?
if (cpuDmaCount == 0x11 || cpuDmaCount == 0x51) {
if (eepromBits == 0x11) {
eepromInUse = true;
eepromSize = SIZE_EEPROM_8K;
as for flash manufacturers, i'm guessing this is already solved, since vba just uses one for small flash and one for large flash, so its' probably doing the same thing.
vba does sometimes autodetect the RTC. it never autodetects a sensor.
The pokemon games all lie about their flash size as a form of antipiracy, and actually use the bigger one.
Other games lie about their flash size and actually use the smaller one.
Top gun is the only multi string game that doesn't actually save.
the 103 figure includes undetected RTCs. 32 of them are pokemon games.
Last edited by Zaphod77,
Sounds very, very cool. Are there any known compatibility issues that aren’t present in games played via the official agb_firm?
--------------------- MERGED ---------------------------
Also there was something I was morbidly curious about, is it technically possible for the ARM7 to be forced to run at DS mode speeds (about 34 MHz) prior to starting a GBA game? Not like it matters since most games probably wouldn’t benefit from the increased clock speed and doing so would be more likely to cause timing issues if anything, but it’d be interesting to see how some of the weird, less performant games like the DOOM ports behave when the CPU’s “overclocked” like that
--------------------- MERGED ---------------------------
Also there was something I was morbidly curious about, is it technically possible for the ARM7 to be forced to run at DS mode speeds (about 34 MHz) prior to starting a GBA game? Not like it matters since most games probably wouldn’t benefit from the increased clock speed and doing so would be more likely to cause timing issues if anything, but it’d be interesting to see how some of the weird, less performant games like the DOOM ports behave when the CPU’s “overclocked” like that
This functionality may be implemented very soon.
https://github.com/profi200/open_agb_firm/pull/35
https://github.com/profi200/open_agb_firm/pull/35
Last edited by HTV04,
Just found this,
https://github.com/d0k3/OldLoader
which, perhaps, may be useful in order to load oaf from the already booted OS. Some polishing would be needed, of course.
https://github.com/d0k3/OldLoader
which, perhaps, may be useful in order to load oaf from the already booted OS. Some polishing would be needed, of course.
Similar threads
- No one is chatting at the moment.
