Actually we are discouraged from modifying it much.
Maister at one point added in some cuesheet autogeneration code and was told to take it out.
It would be nice being able to push upstream at some point though. From that perspective it is good not to diverge too much from mainline.
I’m not really familiar with the codebase of this project however I have a XP 32 system at hand which I use the emulator on so I decided to look at what is causing the crash, I don’t know whenever this is helpful for fixing the crash at the source level, but as far as the faulty ASM code in the compiled PE goes…
First of all, the newest retroarch-phoenix builds crash at the following instruction:
00404D05 |. 83EC 30 SUB ESP,30
00404D08 |. B9 00000000 MOV ECX,0 ; |
00404D0D |. 8B7424 40 MOV ESI,DWORD PTR SS:[ESP+40] ; |
00404D11 |. 0F2805 B0944700 MOVAPS XMM0,DQWORD PTR DS:[4794B0] ; |
00404D18 |. 8B46 0C MOV EAX,DWORD PTR DS:[ESI+C] ; |
00404D1B |. 8B50 10 MOV EDX,DWORD PTR DS:[EAX+10] ; |
00404D1E |. 807A 35 01 CMP BYTE PTR DS:[EDX+35],1 ; |
00404D22 |. 19C0 SBB EAX,EAX ; |
00404D24 |. 25 0000FBFF AND EAX,FFFB0000 ; |
00404D29 |. 05 0000CF00 ADD EAX,0CF0000 ; |
00404D2E |. 807A 05 00 CMP BYTE PTR DS:[EDX+5],0 ; |
00404D32 |. 0FB652 34 MOVZX EDX,BYTE PTR DS:[EDX+34] ; |
00404D36 |. 0F294424 10 MOVAPS DQWORD PTR SS:[ESP+10],XMM0 ; | <- crashes on this instruction
00404D3B |. 0F45C1 CMOVNE EAX,ECX ; |
00404D3E |. 894424 04 MOV DWORD PTR SS:[ESP+4],EAX ; |
00404D42 |. 8D4424 10 LEA EAX,DWORD PTR SS:[ESP+10] ; |
00404D46 |. 895424 08 MOV DWORD PTR SS:[ESP+8],EDX ; |
00404D4A |. 890424 MOV DWORD PTR SS:[ESP],EAX ; |
00404D4D |. FF15 8CD64800 CALL DWORD PTR DS:[<&USER32.AdjustWindowRect>] ; \AdjustWindowRect
A wild guess is that this could be some alignment issue. Older versions (the last version without this crash I’m aware of was WIP3, which I’m using now in conjunction with the newer retroarch EXE) do not include those instructions, perhaps they were compiled with different optimizations? The newer versions appear to initialize the window rectangle with 0, 0, 640, 480 using a single SSE instruction to copy the data from a global, which is the source of the crash, older versions initialize it inline as is visible below.
004034D0 /$ 57 PUSH EDI
004034D1 |. 56 PUSH ESI
004034D2 |. 53 PUSH EBX
004034D3 |. 89CB MOV EBX,ECX
004034D5 |. 83EC 30 SUB ESP,30
004034D8 |. B9 00000000 MOV ECX,0 ; |
004034DD |. 8B7424 40 MOV ESI,DWORD PTR SS:[ESP+40] ; |
004034E1 |. C74424 10 00000000 MOV DWORD PTR SS:[ESP+10],0 ; |
004034E9 |. 8B46 0C MOV EAX,DWORD PTR DS:[ESI+C] ; |
004034EC |. 8B50 10 MOV EDX,DWORD PTR DS:[EAX+10] ; |
004034EF |. 807A 35 01 CMP BYTE PTR DS:[EDX+35],1 ; |
004034F3 |. 19C0 SBB EAX,EAX ; |
004034F5 |. 25 0000FBFF AND EAX,FFFB0000 ; |
004034FA |. 05 0000CF00 ADD EAX,0CF0000 ; |
004034FF |. 807A 05 00 CMP BYTE PTR DS:[EDX+5],0 ; |
00403503 |. 0FB652 34 MOVZX EDX,BYTE PTR DS:[EDX+34] ; |
00403507 |. C74424 14 00000000 MOV DWORD PTR SS:[ESP+14],0 ; |
0040350F |. 0F45C1 CMOVNE EAX,ECX ; |
00403512 |. 894424 04 MOV DWORD PTR SS:[ESP+4],EAX ; |
00403516 |. 8D4424 10 LEA EAX,DWORD PTR SS:[ESP+10] ; |
0040351A |. C74424 18 80020000 MOV DWORD PTR SS:[ESP+18],280 ; |
00403522 |. C74424 1C E0010000 MOV DWORD PTR SS:[ESP+1C],1E0 ; |
0040352A |. 895424 08 MOV DWORD PTR SS:[ESP+8],EDX ; |
0040352E |. 890424 MOV DWORD PTR SS:[ESP],EAX ; |
00403531 |. FF15 C8764A00 CALL DWORD PTR DS:[<&USER32.AdjustWindowRect>] ; \AdjustWindowRect
I couldn’t find any other references to AdjustWindowRect in the executable so I guess the culprit location in the source could be deducted from that.
Nopping out the offending XMM0 move “”“fixes”"" the crash, but it leaves the UI in a malformed state.
When did you pull down the version you tested? I ask because I just uploaded some builds (without incrementing the version number) from Sintendo that I had hoped would fix the issue a couple of days ago.
Regardless, this is helpful information. Thanks for investigating!
The timestamp on the zip indicates 08.09.2013.
k, that’s the newest one, I think, so it seems to still be crashy 
I dug around a bit more and did a little bit of reverse engineering on that faulty segment, initially I’ve created a x86 ASM patch that corrected the problem but was not very elegant, I’ve included it below:
00404D11 /E9 6ADE0600 JMP retroarc.00472B80
00404D16 |90 NOP
00404D17 |90 NOP
00404D18 |8B46 0C MOV EAX,DWORD PTR DS:[ESI+C]
00404D1B |8B50 10 MOV EDX,DWORD PTR DS:[EAX+10]
00404D1E |807A 35 01 CMP BYTE PTR DS:[EDX+35],1
00404D22 |19C0 SBB EAX,EAX
00404D24 |25 0000FBFF AND EAX,FFFB0000
00404D29 |05 0000CF00 ADD EAX,0CF0000
00404D2E |807A 05 00 CMP BYTE PTR DS:[EDX+5],0
00404D32 |0FB652 34 MOVZX EDX,BYTE PTR DS:[EDX+34]
00404D36 |90 NOP
00404D37 |90 NOP
00404D38 |90 NOP
00404D39 |90 NOP
00404D3A |90 NOP
00404D3B |0F45C1 CMOVNE EAX,ECX
00404D3E |894424 04 MOV DWORD PTR SS:[ESP+4],EAX
00404D42 |8D4424 10 LEA EAX,DWORD PTR SS:[ESP+10]
00404D46 |895424 08 MOV DWORD PTR SS:[ESP+8],EDX
00404D4A |890424 MOV DWORD PTR SS:[ESP],EAX
00404D4D |FF15 8CD64800 CALL DWORD PTR DS:[<&USER32.AdjustWindowRect>]
00472B80 C74424 10 00000000 MOV DWORD PTR SS:[ESP+10],0
00472B88 C74424 14 00000000 MOV DWORD PTR SS:[ESP+14],0
00472B90 C74424 18 80020000 MOV DWORD PTR SS:[ESP+18],280
00472B98 C74424 1C E0010000 MOV DWORD PTR SS:[ESP+1C],1E0
00472BA0 ^ E9 7321F9FF JMP retroarc.00404D18
Without the SSE based move it no longer crashes and the UI also looks correct again.
I suspect that turning off SSE instruction generation in the compiler settings (I don’t know how to do this under GCC unfortunately, VC++ has this under extended instruction set settings) the faulty code should no longer be generated.
However, upon closer inspection, the original code used MOVAPS, which expects aligned memory, changing this to its unaligned equivalent, MOVUPS, solved the problem with minimal changes, again I’m not familiar with the usage of GCC in this case, but in VC++ you can force the memory allignment of structures with __declspec(align(#)), GCC should have an equivalent to this.
00404D11 0F1005 B0944700 MOVUPS XMM0,DQWORD PTR DS:[4794B0]
00404D18 8B46 0C MOV EAX,DWORD PTR DS:[ESI+C]
00404D1B 8B50 10 MOV EDX,DWORD PTR DS:[EAX+10]
00404D1E 807A 35 01 CMP BYTE PTR DS:[EDX+35],1
00404D22 19C0 SBB EAX,EAX
00404D24 25 0000FBFF AND EAX,FFFB0000
00404D29 05 0000CF00 ADD EAX,0CF0000
00404D2E 807A 05 00 CMP BYTE PTR DS:[EDX+5],0
00404D32 0FB652 34 MOVZX EDX,BYTE PTR DS:[EDX+34]
00404D36 0F114424 10 MOVUPS DQWORD PTR SS:[ESP+10],XMM0
Ohhh, perhaps we just need to tone down the compiler optimizations for 32-bit. I’ll give that a shot.
@Sargh Would you mind trying this build? I knocked the gcc optimization levels down to -O0 for everything http://www.mediafire.com/download/8wox7t36g2ohhid/retroarch-phoenix-o0.exe It’s just a launcher, so I figured its performance shouldn’t matter.
That new build works fine 
Awesome! Thanks for helping us track down this issue. I’ll get the new build up on the updater and see about getting the reduced optimizations pushed to github.
Huh, that’s weird. The binaries I generated worked just fine on my netbook, and I hadn’t touched the optimization levels.
Stupid head on today, have got Retroarch working on both the Ouya and nVidia Shield and wanted to get it running on the PC so its easier to try out some cd games before transfering, but i cant work out how to select a core, there is nothing in the dl folder, excuse my ignorance, am i missing something here?! Cheers!
Edit: sorry just found the update in the phoenix launcher, why arent the cores included in the main builds?
Bloat. There are many unofficial builds floating around which bundle everything. On consoles and mobile, you don’t really have a choice but to bundle. Doing it manually would require the likes of rooting/adb. Way too inconvenient, even for a power user.
Are there some server problems? I am not able to receive a list in the Phoenix Updater.
I think Maister’s FTP server is running out of file space. It is fairly limited.
Anyway, mudlord offered up a download server with unlimited bandwidth and storage so I will start setting that up. We could use that as a replacement/fallback.
Thx.
In current archive pack http://themaister.net/retroarch-dl/RetroArch-20130927-Win32-megapack.zip missing retroarch-phoenix.exe Why you remove it from package? And yes hunterk build is works fine.
And plese fix url to http://libretro.com/ at http://themaister.net/retroarch.html page coz it’s point at fishing site http://libretro.org/
I have some issue with current genesis_plus_gx_libretro.dll in SDL mode at my hardware. latezt one i found wotks well is v1.7.1. OpenGL seems works fine in any version but my hardware is slowpokeed for OpenGL.
Thanks for pointing that out. Fixed now.
2Maister: who can help me out with genesis libretro? I can use v1.7.1 but maybe there is a bug in latest one? In SDL mode I get blanck screen only.
@berrybear The Phoenix launcher is going away and most of the options are moving into the in-game menu, RGUI.
I’ll see if I can reproduce the SDL issue with genplusgx.