Dolphin, the GameCube and Wii emulator - Forums

While working on figuring out how the Datel AGP communication works, I was using Dolphin to step through the Datel AGP disc. I think I've mostly got it figured out now, so I probably won't be working on this code anymore. I thought I'd share it, in case anyone else wanted to finish it/improve it/clean-it up/whatever.
As is, it correctly loads the GBA ROM. I finished before testing out the save function (EEPROM only in this code), so I don't know if it works or not.

I was going to add some information to the wiki for this disc, but I couldn't figure out how to add a new disc. It works to some extent. It requires the BIOS loading (I don't think the disc copies in interrupt handling to 0x80000500, 0x80000c00, etc.). Then, if there are any FIFO errors, just save the state, restart Dolphin and load the state. That will get you all the way to where it loads the cartridge from the AGP EXI/Memory Card device, which loads successfully. I was getting Panic Alerts at this point because the code uses addco. and subfco. opcodes, which apparently aren't supported. I just commented those errors, but full support may or may not be needed for correct operation.

The patch probably should be cleaned-up, but I'm too lazy to work on it now.

This sounds like one of those absolutely insane things to support that I tend to want. Awesome.

Also, if you have a Datel AGP DVD and want to dump the disc to try it out, it won't work because Datel DVDs are tricky.

You will have to patch CleanRip, using a patch provided by the very same greyrogue here (you need to uncomment the parts relevant to the AGP disc).

I Don't know if you're still around, but saving, unfortunately, doesn't work on it and that basically makes it impossible to use it on most games.

Here are my complete notes on the AGP:
http://www.gc-forever.com/forums/viewtop...=26&t=2655

As I said, I stopped working on it once I figured out the protocol. I only implemented (AE) commands 0, 1, 2, 3, 9, A, B, C in the patch. EEProm is only one type of save used by the GBA. Depending on the game, commands 4 and 7 would also be needed (SRAM). Using the information I provided above plus this (check out the SRAM section):
http://problemkaputt.de/gbatek.htm#gbacartridges
should be enough information to get the other types working. Also, I don't remember how far I got with EEProm code in my patch (the EEProm data is also explained in the gbatek link). I think it was loading the save correctly, but I was having problems with some of the commands before it even got to writing the save, so that code is untested.

If the above information isn't enough for one of the devs, feel free to ask me any questions. I might try a further patch at some point if someone else doesn't, but probably not for a while.

At this point, support for the AGP in Dolphin is pretty good. We have a bug with or GPU timing that causes it to randomly crash, but there's a work-around on the issue tracker. The main problem with it is that it can't seem to write or read saves. I'm not a huge GBA person and only have a few popular GBA games, (Metroids, Warioware, Zeldas, Mario Golf) so maybe I'm just running into sram titles; I really don't know.

Here's a site that tells what type of save each game uses.
http://www.advanscene.com/
If you use advanced search, you can search by title or save type (EEPROM, SRAM, FLASH).
I just glanced through the Dolphin's updated code. I noticed that I actually only implemented 512 bytes (4Kbit) EEProm handling. It should be easy to add the other one (64Kbit) by using the size of the save file (note that the save file must be sized correctly, which is not handled by this code) and changing the hard-coded 0x8 and 0x48 referencing m_eeprom_pos in the code for ImmWrite 0xAE0C0000. See the gbatek link for information on the reason why (14 bits of address information instead of 6). The 0x8 changes to 0x10 (2 + 14 bits) and 0x48 changes to 0x50 (2 + 14 + 64) for 64Kbit and similarly (0x47-> 0x4F, 0x3F->0x3FF).

SRAM/FRAM would be pretty easy to add, which is what a lot of the good games use. I think it would be something like this (untested, might want to change variable names or add new ones (eeprom)):

ImmRead()
...
case 0xAE040000:
RomVal1 = (m_eeprom.data())[m_eeprom_pos];
CRC8(&RomVal1, 1);
uData = (RomVal1 << 24) | (m_hash << 16);
m_current_cmd = 0;
break;
...
case 0xAE070000:
case 0xAE0C0000: // code exists in dolphin already
uData = m_hash << 24;
m_current_cmd = 0;
break;

ImmWrite()
...
case 0xAE040000:
m_eeprom_pos= ((_uData & 0xFFFF0000) >> 0x10) & 0x7FFF;
HashCmd = (_uData & 0xFF000000) >> 24;
CRC8(&HashCmd, 1);
HashCmd = (_uData & 0x00FF0000) >> 16;
CRC8(&HashCmd, 1);
break;
case 0xAE070000:
m_eeprom_pos= ((_uData & 0xFFFF0000) >> 0x10) & 0x7FFF;
((m_eeprom.data()))[(m_eeprom_pos)] = (_uData & 0x0000FF00) >> 0x8;
HashCmd = (_uData & 0xFF000000) >> 24;
CRC8(&HashCmd, 1);
HashCmd = (_uData & 0x00FF0000) >> 16;
CRC8(&HashCmd, 1);
HashCmd = (_uData & 0x0000FF00) >> 8;
CRC8(&HashCmd, 1);
break;

FLASH saves are a little bit more complicated, but still doable. Again, see the gbatek link for the specifics.

So most of what I'm running into is actually eeprom 64K. That makes about as much sense really.

Here's a replacement for ImmWrite AE command C that should fix 64Kbit EEProm (untested):
case 0xAE0C0000:
u32 eeprom_address_end = (m_eeprom_size == 512 ? (2+6) : (2+14));
if ((m_eeprom_pos < eeprom_address_end) || (m_eeprom_pos == ((m_eeprom_cmd & EE_READ) ? eeprom_address_end : eeprom_address_end + 0x40)))
{
Mask = (u64)(1 << (eeprom_address_end-(m_eeprom_pos > eeprom_address_end ? eeprom_address_end : m_eeprom_pos)));
if ((_uData >> 16) & 0x1)
m_eeprom_cmd |= Mask;
else
m_eeprom_cmd &= ~Mask;
if (m_eeprom_pos == eeprom_address_end + 0x40)
((u64*)(m_eeprom.data()))[(m_eeprom_cmd >> 1) & (m_eeprom_size == 512 ? 0x3F : 0x3FF)] = m_eeprom_data;
}
else
{
Mask = (u64)(1 << (eeprom_address_end + 0x40 - 1 - m_eeprom_pos));
if ((_uData >> 16) & 0x1)
m_eeprom_data |= Mask;
else
m_eeprom_data &= ~Mask;
}
m_eeprom_pos++;
m_return_pos = 0;
HashCmd = (_uData & 0xFF000000) >> 24;
CRC8(&HashCmd, 1);
HashCmd = (_uData & 0x00FF0000) >> 16;
CRC8(&HashCmd, 1);
break;

The variables can be moved around or made member variables to prevent compiler warnings or prevent unnecessary recalculations. Again this assumes an existing save file of the right size.

I used VBA to create an existing savefile for now. Hopefully they're the same type. Thanks for your patience with me; I'm really not a coder; I just like emulating all these obscure features. As soon as I saw the AGP patch I had to get one to try it.

Edit: I ran into a segfault that I can't really figure out. I don't know if it's an error in the untested code, or I copied around variables wrong to make it compile. Both could be the problem.

https://dl.dropboxusercontent.com/u/4847...fault2.jpg