Homebrew OPEN_AGB_FIRM discussion thread

[Rj.MoG]

This might be a silly question, but will this ever support some type of borders, similar to the 3DS VC? Or is this just bare metal GBA mode access?

Just balls to the wall gba

 

[RadoMiami]

For any first-time users of Open AGB Firm, I recommend that you set the backlight to 64 and out gamma to 1.85 or 1.8. Experiment from there, but don't mess with brightness.

 

[wiceli]

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.

 

[fmkid]

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

 

[wiceli]

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.

 

[Rahkeesh]

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.

 

[Deleted member 323844]

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

 

[Zaphod77]

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?

 

[DSoryu]

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?

This is made from scratch, so OPEN_AGB_FIRM can't even read what a footer generated from an official GBA CIA is.

 

[Zaphod77]

but some pc program should be able to do so. it also affects other options. If this supports save types that original agb_firm does not at all, that's a pretty big improvement.

so it actually supports eeprom v122?

 

[DSoryu]

but some pc program should be able to do so. it also affects other options. If this supports save tpyes that original agb_firm does not at all, that's a pretty big improvement.

so it actually supports eeprom v122?

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.

 

[ghjfdtg]

The "VXXX" names are just SDK strings. There are only 2 EEPROM types (4k and 64k) and both are technically supported but auto detection is very wonky.

 

[Zaphod77]

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.

 

[ghjfdtg]

It can't auto detect based on behavior because it's not emulation at all.

 

[BiggieCheese]

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

 

[Stellar]

I've asked before but I don't think there was an answer back then: is there someplace I can download a database of known savetypes that open_agb_firm can read from and write to?

 

[HTV04]

I've asked before but I don't think there was an answer back then: is there someplace I can download a database of known savetypes that open_agb_firm can read from and write to?

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

 

[ber71]

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.

 

[MultiKoopa]

Is there a compatibility list for this?

 

[Rahkeesh]

The only major compatibility issues seem to be related to detecting the correct save type.