[Patch] Datel AGP support

[JMC47]

That fixes everything for me in the games I have.

Tested:

Sonic Advance
The Legend of Zelda - Minish Cap
WarioWare Mega MicroGames
Zelda - The Four Swords (Link to the Past + Four Swords)
Fire Emblem
Mario Golf - Advance Tour (still poorly emulated as ever by the AGP!)
Metroid Zero Mission
Metroid Fusion

[skid]

(02-13-2015, 12:04 PM)GreyRogue Wrote: If you want you can try this one.
If this doesn't work, I might need to change what get returns from the 0x800000.

Nice work.  Would you create a PR with these changes?

[GreyRogue]

So it's been merged into master.

I'm on to other projects, so if anyone wants to make it better, here are some suggestions.
A few increasingly difficult ways to improve it:
I missed one place where I surrounded the if block with {}, but forgot to do so for the single-line else.

Shorten some of the lines using temporary variables (100+ characters/line are a bit much)

Rename some of the variables from m_eeprom_* to m_save_* where appropriate (some really only apply to EEPROM).

Add Flash ROM support. This isn't actually too hard. Reading should already be in place as the 0xAE04 command for SRAM should be identical. It just needs some special handling if the 0xAE07 command has put it in ID mode and an offset (0 or 0x10000) for bank switching. The rest of the special handling goes into the 0xAE07 writes. See the GBATEK document for the cases:
http://problemkaputt.de/gbatek.htm#gbacartbackupflashrom
m_eeprom_pos is already calculated as your lower sixteen bits of address (ignore the 0xE00xxxx prefix just like 0xAE04), and your data is the what's currently being stored in the m_eeprom (save data). Any writes to 0x5555 of 0xAA would need to be temporarily stored until the next write. If the next write is 0x55 to 0x2AAA, then use special handling. Otherwise, write the new non-special data, plus the temporarily stored 0x5555 data. Alternatively, keep track of what type of save it is and use that to react to 0x5555 writes. From the GBATEK document, erases set all data in the specified range to 0xFF. The waiting is done by the emulator, not Dolphin. The same is true for the IME (interrupt control).

Resize the save file if it doesn't exist to the correct size by searching for ("EEPROM_", "SRAM_", "FRAM_" or "FLASH_") in the ROM. There are two choices for EEPROM and FLASH, so this would require some additional logic to handle.

If anyone's feeling especially adventurous, you could implement the GPIO (RTC, Solar, Tilt, Rumble, etc.).
http://problemkaputt.de/gbatek.htm#gbacartioportgpio
I believe this would be done by modifying the 0xAE02 command for reads, and adding support for the 0xAE06 command (see my notes from gcforever for the format) for writes.
http://www.gc-forever.com/forums/viewtopic.php?f=26&t=2655

[JMC47]

With my hacked build to fix the hangs, I've been struggling through some half working games and what not on emulator and comparing it to console. Dolphin emulates it very well! I'm impressed with your work. Thank you so much for reverse engineering and implementing such a neat little device.