A GBA file is a single .gba image, with a standard Game Pak address space of up to 32 MiB. Hack authors almost always ship UPS or BPS, not a raw overwritten ROM. The patch stores the difference from one exact dump. FireRed is the example I use because the two US revisions do not share a hash: 1.0 is SHA-1 41cb23d8dccc8ebd7c649cd8fbb58eeace6e2fdc and 1.1 is SHA-1 dd5945db9b930750cb39d00c84da8571feebf417. Emerald US is SHA-1 f3ae088181bf583e55daf962a92bb46f4f1d07b7. Those three numbers are the ones I will stand behind. Other hacks name a base in their readme. If that readme is silent, the UPS source check is the test, not a guess.
Save type is orthogonal to the patch format. Commercial carts use SRAM, flash, or EEPROM, and the emulator has to agree. A UPS that changes the game does not by itself change how the save is stored. Projects that want a battery-less cart rewire save routines with a different kind of patch, often discussed as an SRAM or batteryless patch. I keep that on its own page so nobody expects the home button to edit a save chip. If your goal is a hack like a FireRed revision or an Emerald base, you want this page and the matching hack guide.
Header bytes are less dramatic on GBA than on SNES. You rarely strip 512 bytes. You do have to avoid a file that is already patched, a European dump when the author said US, or a zip you forgot to extract. The browser can open a zip and will hash what it finds. I read the CRC the tool prints and compare it with the hack page before I apply anything. A source checksum error is the module working. An apply that finishes on IPS, if someone sent IPS, is not the same reassurance.
After the output downloads, the emulator is mGBA, VBA-M, or a handheld core that accepts a plain .gba. The patcher does not launch them. Related pages are the UPS format guide, the FireRed version guide, the Emerald guide, and the SRAM explanation if the readme mentions batteryless or RTC.
