Emulator Issues #9470
closedNeoGamma is broken since Dolphin 4.0-5450
0%
Description
[Put Game Name here]
NeoGamma R9 b56
It's a homebrew game launcher that allows to run games with some video mode patches and cheats
[Put Game ID here]
homebrew
[Put MD5 Hash here]
Download:
https://drive.google.com/open?id=0ByQgqzsPdirYQk1EYUtYWnkwRmc
[Description here]
It crashes
[Reproduction steps here]
Just launch the boot.dol in Dolphin
(Enable real xfb to display anything)
[Versions here]
Dolphin 4.0-5429 works
Dolphin 4.0-5443 works
Dolphin 4.0-5445 works
Dolphin 4.0-5450 crashes
Dolphin 4.0-5458 crashes
Dolphin 4.0-5460 crashes
Dolphin 4.0-5470 crashes
Dolphin 4.0-9175 crashes
[PC specs here]
Windows 7 64 bit
Pentium G3258 @4.0Ghz
AMD Radeon HD7790
8 GB RAM
[Anything else here]
PR#1856 broke this
https://github.com/dolphin-emu/dolphin/pull/1856
It's a regression, so maybe this should be fixed before 5.0
Updated by mimimi over 8 years ago
With panic handlers, there's a warning:
Unknown Pointer 0x01800000 PC 0x80e38aec LR 0x80e388cc
Updated by magumagu9 over 8 years ago
The panic generally indicates an attempt to access memory which doesn't exist. For the address 0x01800000 specifically, before 1856 we would just silently use memory which doesn't exist. Dolphin maps 32MB of memory to represent RAM, of which the last 8MB doesn't actually correspond to memory which exists on hardware. See also https://github.com/dolphin-emu/dolphin/blob/418b8c03d54980401214847cf9d8ebbe0ecf166d/Source/Core/Core/HW/Memmap.cpp#L101.
I can't say exactly where this is happening without a stack trace.
Updated by magumagu9 over 8 years ago
Just tried it in a debugger; it appears to be crashing in CWII_IPC_HLE_Device_usb_oh1_57e_305::IOCtlV with nonsense input (trying to invoke an IOCtl which doesn't exist). Someone who knows IOS internals a bit better should probably look at this to see what the best solution is.
Updated by mimimi over 8 years ago
Thanks for looking into it. It's likely trying to call a function from a cIOS. Dolphin should just return the same error a proper IOS returns. Hopefully it works then. If it's really badly coded, for some reason it might think the loaded IOS is a cIOS and insists that cIOS functions work.
Updated by JosJuice over 8 years ago
But why would there be a cIOS function in the Wii Remote code? Don't they generally deal with USB, the disc drive, and things like that?
Updated by JMC4789 over 8 years ago
If it worked before by (more or less) luck, should this still be a milestone current for something with a small usecase? I mean, it sucks that it no longer works, and this is definitely the kind of issue I care about (I've actually run neogamma in Dolphin before) but is it something we want to delay the release over? Is it something that can be fixed easily?
Updated by Fog over 8 years ago
- Status changed from New to Accepted
- Milestone deleted (
Current)
I agree, this shouldn't be a blocker for release.
Updated by mimimi over 8 years ago
@magumagu9:
I've tracked down where the problem occurs in neogamma's source. It's in bwDVD_GetCoverStatus, specifically the line:
int Ret = IOS_Ioctl(__dvd_fd, IOCTL_DI_GetCoverStatus, bufferin, 0x20, bufferout, 0x20);
My suspicion is that IOS_Ioctl is the problem not the IOCTL_DI_GetCoverStatus. If i make bwDVD_GetCoverStatus always return 0, neogamma works. Well, it only works with a gamecube controller, which should be a different issue, and it fails to obviously fails detect if no disc is inserted. If i replace IOCTL_DI_GetCoverStatus with IOCTL_DI_READID(both places) it does crash in the same way.
Edit: For most other stuff, the working stuff, it uses IOS_IoctlAsync.
Updated by magumagu9 over 8 years ago
I tried looking a bit more... now I see what's happening. NeoGamma opens "/dev/di", then closes it (bwDVD_LowClose), then restarts IOS, then tries to use the descriptor as if it were the DVD drive (where at this point, it's actually the Bluetooth module). So it looks like Dolphin is actually behaving correctly as far as that goes.
In terms of IOS error handling, I have no clue how that's supposed to work. I mean, as a hack you can add "if (Memory::Read_U32(_CommandAddress + 0x0C) > 0x02) return GetDefaultReply();" to CWII_IPC_HLE_Device_usb_oh1_57e_305::IOCtlV, but that's probably not correct.
Updated by JMC4789 over 8 years ago
I don't mind a temporary hack if it's no worse than it being totally broken like before.
Updated by JosJuice over 8 years ago
- Status changed from Accepted to Fixed