[Patch] Datel AGP support

[GreyRogue]

I think the only way that line could cause a SegFault is if the .sav file is the less than 512 bytes long (that's the version without the 64KBit fix above).

[JMC47]

You're actually correct; my savefile got wiped out somehow (likely my fault)

Unfortunately, I must have implemented something wrong, (or maybe the patch, or dolphin itself?) is wrong as it fails to read any saves.

edit: I know it's trying to do something because it lags as it tries to load the memory file; just not working right, I guess.

[GreyRogue]

My computer is super slow.  I had Dolphin running on the slowest settings, too.  Somewhere when I was updating to latest, I lost my GC SRAM file, and because the screen is messed up when loading the BIOS, I didn't know that it was waiting for me to press buttons before starting.  I was letting it run over night and was confused why it wasn't continuing.  It took me days of retrying to finally figure it out.  Now that I'm past that, testing/fixing the save issue was much easier.
I missed that the size of the address is too small for anything but the smallest EEPROM.  Here's a patch with that change, plus the others I mentioned earlier.  I tried this with Metroid Fusion, and it looks like it loads/saves correctly.  The other save types need testing, and the Flash ROMs won't work (they need the special commands from that GBATEK document (banking, etc.) to work.
If anyone of the devs wants to to finish up the rest of this, I'm sure they could do so easily.

Edit: Fixed mask in patch.

[JMC47]

Go into Graphics Settings, in the Options Menu and go to the hacks tab and select "External Frame Buffer" as Virtual. That will fix the graphical issues. LLE audio may be needed as well.

If you have any Dolphin questions about setting it up and running things, please let me know; I'm not a total dunce when it comes to that!

Anyway, I'll try out your patch, thanks. If you want the hack that makes the AGP stable, I can give you that, too; then it won't randomly hang any more.

Edit: Even with that patch, I still can't seem to get any games to save. I even tried a suggestion from skidau to rename the files to have no spaces, but, nothing. At best, if there is no save file, it will write 0 KB save files for me.

[JMC47]

Adding another post to say that I'm incorrect. Some games are loading saves now. Not sure which ones and why, though.

Warioware Mega Microgames is working, my two Zelda games aren't. Microgames is a 64KB savefile, where as Zelda Minish Cap appears to be an 8KB savefile?

[GreyRogue]

I tried Metroid Fusion and Zelda Four Swords/A Link To The Past and both work. The sav file must exist and be the correct size before starting (both of these games should be exactly 65536 bytes [64KiB]). I created the save files initially with VBA. From GBATEK, one way to determine the correct type is to try reading the gba file and searching for one of these: EEPROM_Vnnn, SRAM_Vnnn, FLASH_Vnnn, FLASH512_Vnnn, FLASH1M_Vnnn, replacing the 'n' characters with numbers, but some games intentionally lie as a form of copy protection. It's a problem that different gba emulators solve in different ways. I was too lazy to implement any of these, and the code currently requires the file to exist and be the correct size. If one of the other devs wants to improve this, that would be great.

I just looked at VBA's source code. It looks like it always writes that 65536 files for SRAM/FRAM files. It might be okay to always use that size until Flash is implemented (needs bank switching, chip id, erase and write functions).

[Shonumi]

It's actually quicker just to search for the strings "EEPROM", "SRAM", or "FLASH"; you'll see the "_Vnn" soon enough in a hex editor anyway. You may come across some false positives. Megaman & Bass, for example, uses EEPROM, but it has unlockable Robot Master data stored as plaintext in the ROM, so you'll encounter "FLASH"-MAN before "EEPROM". I'm working on GBA emulation atm, but I haven't encountered a game that lied about it's save type (perhaps my code can't be fooled? )

For reference on the sizes

SRAM -> Always 32KB
EEPROM -> 512B or 8KB
FLASH -> 64KB or 128KB

Additional notes. 128KB FLASH saves were notoriously used for the GBA Pokemon games (RSE, FR, LG), though I heard Super Mario Advance 4 also uses it. Most other games just use 64KB. SRAM seems to be the most common by far. I have no idea why VBA or VBA-M is setting SRAM file sizes to 64KB. GBATEK very clearly says SRAM only occupies 0x7FFF bytes (32KB) in memory and it mentions nothing about banking. Seems like no one bothered to change this behavior in VBA-M since it probably never broke anything. GBE+ uses 32KB saves, and I've never had an issue loading or saving SRAM (Metroid Fusion saves just fine, for example).

[JMC47]

I'll try again with Link to the Past/Four Swords; maybe the save file I was using was too old/corrupted (I've been messing with it a lot.)

Minish Cap was using a VBA save file for sure (since I already had one on hand) and isn't working. I'll try it more after work to see if I can nail down what's going on.

[GreyRogue]

First, to JMC47. Yeah, Minish Cap uses EEPROM, and I can't get mine to work as that definitely has errors in the code. I'm trying to fix them now. Also, it looks like my copy of Four Swords is a clone. The real one is supposed to use EEPROM, but my copy looks like its using SRAM. The game code still has the EEPROM_vnnn string, but it doesn't appear to be correct. I guess that's what I get for buying off ebay. I wouldn't be surprised if your Four Swords doesn't work (EEPROM).

It's actually quicker just to search for the strings "EEPROM", "SRAM", or "FLASH"; you'll see the "_Vnn" soon enough in a hex editor anyway. You may come across some false positives. Megaman & Bass, for example, uses EEPROM, but it has unlockable Robot Master data stored as plaintext in the ROM, so you'll encounter "FLASH"-MAN before "EEPROM". I'm working on GBA emulation atm, but I haven't encountered a game that lied about it's save type (perhaps my code can't be fooled? )

You clearly have more experience with GBA than me, so I'll defer your to your expertise. Here's the link I was reading before that was telling about games lying:
http://zork.net/~st/jottings/GBA_saves.html
The note about Top Gun is especially interesting, as it claims to have all three, but if you implement any of the three it stops running (it doesn't have save support). It also says the type for multiple listed games can't be reliably predicted, so I assumed just picking the first didn't always work. Also, I've just discovered some of my games are clones with modified code for different save types (see my note above to JMC47). I don't know if it's important to handle these.

For reference on the sizes

SRAM -> Always 32KB
EEPROM -> 512B or 8KB
FLASH -> 64KB or 128KB

Additional notes. 128KB FLASH saves were notoriously used for the GBA Pokemon games (RSE, FR, LG), though I heard Super Mario Advance 4 also uses it. Most other games just use 64KB. SRAM seems to be the most common by far. I have no idea why VBA or VBA-M is setting SRAM file sizes to 64KB. GBATEK very clearly says SRAM only occupies 0x7FFF bytes (32KB) in memory and it mentions nothing about banking. Seems like no one bothered to change this behavior in VBA-M since it probably never broke anything. GBE+ uses 32KB saves, and I've never had an issue loading or saving SRAM (Metroid Fusion saves just fine, for example).

You're also right on these sizes. I was basing my size statements on the thought that if it works for one of the emulators (VBA in this case), it should work for the code in Dolphin. Doing it the right way is better, though. The size of the file only matters for my code here, because I'm using it to set the address mask and for the number of address bits in EEPROM commands. The EEPROM must be 512 bytes if that's it size. Any of the others can probably be any multiple of 2 at least as big as their actual size. Again, however, right is better.

[JMC47]

Interesting stuff. So flash saving is working, since my 64KB saves are fine?