Emulator Issues #8223
closedDatel AGP requires default exception handlers
0%
Description
The game doesn't install exception handlers on boot like regular games that use the Nintendo SDK.
It instead relies on the handlers that the IPL install upon boot.
It does something odd that involves hitting the exception handlers that needs to be investigated.
Our non-IPL path doesn't install default handlers, but it may end up needing to do so at some point in order to properly support this game.
Since we don't only install a couple exception handlers that only do an rfi the game doesn't continue very far in the boot process without having the actual IPL running.
One could most likely start with investigating the route the game takes through the exception handlers with the IPL and attempting to replicate that without the IPL.
Updated by mimimi almost 10 years ago
Do the exception handlers from normal games work for this? Are they always the same, or are there differences? Could you dump those exception handlers when running any gamecube game, and use them for the Datel-AGP stuff?
Updated by Sonicadvance1 almost 10 years ago
The ones that regular games install with the SDK are the same as the ones that the IPL installs.
Just ripping the ones from the games/IPL don't seem to work, but they do cause a change in behaviour. Also we wouldn't be able to package them in Dolphin.
Creating a default exception handler that saves the required information to the exception frame is fairly easy to do.
Updated by mimimi almost 10 years ago
So, the exception handlers are only half of the issue?
And i wasn't thinking about packing the exception handlers in Dolphin, more like dumping them when running a gamecube game. And then add like a 3rd bios/ipl option that copies those exception handlers to memory.
Well, it seems like somebody needs to debug this to find out what exactly is going on
Updated by pokechu22 over 2 years ago
- Related to Emulator Issues #8179: Datel Discs need INI changes, Bios forced on, LLE audio forced on. added
Updated by pokechu22 over 2 years ago
I investigated this further, and it does seem like they do install exception handlers; they just do it in a somewhat broken way.
The function that copies the exception handlers (or more precisely the function that does dcbst
after they've been copied) contains a sc
instruction instruction, which jumps to the interrupt handler at 00000c00
, which is odd because they also are writing the exception handler at 00000c00
(they copy a single exception handler to each of the exception handlers). The sc
instruction corresponds to ppcsync()
in libogc, which ends up calling this for them. (Libogc's version doesn't exactly match; the official one doesn't save r9
and r10
)
After they've set all of the exception handlers once, they overwrite 00000c00
with a separate one that syncs the instruction cache. Using pure interpreter with a Datel title, you can see some icache-related warnings about that address when booting normally, so I think it only works due to icache.
The IPL also does the same thing where it copies a default exception handler over all of the exception handlers (I think; I haven't checked too closely) and then special-cases 00000c00
afterwards. However, they don't use the sc
instruction to jump to 00000c00
; instead, they use sync
and isync
directly.
The same applies to retail titles (for both GameCube and Wii); OSInit
calls OSExceptionInit
. For each address in __OSExceptionLocations
, that memcpy
s OSExceptionVector
to the address, then calls DCFlushRangeNoSync
, _sync()
[i.e. the sync
instruction], and ICInvalidateRange
. Then OSInit
calls __OSInitSystemCall
, which special-cases 00000c00
with SystemCallVector
. Datel's equivalent to OSExceptionInit
instead calls DCFlushRange
and doesn't call ICInvalidateRange
.
I think that if we provide a default interrupt handler at 00000c00
that does the expected stuff, everything should work fine. And, it would be only 7 instructions, so I don't think it's as big of a deal as needing to provide all of the default exception handlers. I haven't gotten it to work yet though.
Updated by pokechu22 over 2 years ago
After investigating it further, I noticed that the icache message also appears on the jit... but for both the jit and the pure interpreter, it didn't appear when booting via emulated BS2. As it turns out, icache starts disabled when booting booting via emulated BS2, but it's normally enabled when booting from the IPL. Most titles enable icache on startup, but Datel doesn't.
Adding HID0.ICE = true
into CBoot::EmulatedBS2_GC
is enough to get Datel titles to start! Unfortunately they still don't work quite right; textures are completely missing: https://i.imgur.com/BK0Daad.png (except for titles such as "Ultimate Cheats for use with Enter the Matrix" that do all of their rendering in software, which render fine). So, we don't need to provide a default system call interrupt after all (other than the existing rfi
that makes it immediately return)... which I guess makes sense because we ignore the sync
and isync
instructions and the HID0
ABE
(address broadcast enable) bit.
Updated by JMC4789 over 2 years ago
That's weird that they're missing textures now. This is seriously confusing.
Updated by pokechu22 over 2 years ago
- Status changed from Accepted to Fix pending
Updated by pokechu22 over 2 years ago
- Status changed from Fix pending to Fixed
- Fixed in set to 5.0-16737
Updated by pokechu22 over 2 years ago
Here's a detailed writeup of how Datel's code was broken and the above change fixes it: https://gist.github.com/Pokechu22/abed8faefa0afc6dd881a8958e2407fe