libretro / beetle-ngp-libretro

Standalone port of Mednafen NGP to the libretro API, itself a fork of Neopop.
GNU General Public License v2.0
11 stars 43 forks source link

After the update to 1.23.0 no longer works on Wiiu #84

Closed ruijtunes closed 4 years ago

ruijtunes commented 4 years ago

After the update to 1.23.0 this core no longer works on Wiiu

Commits on Nov 8, 2019 - 432cb01 Merge pull request #73 from f21red/update to 1.23.0 @hizzlekizzle

The core doesn't crash but the games don't initialize properly, hanging with a pink screen.

newsie-oss commented 4 years ago

Do the core logs print anything? That sounds like an issue with loading the rom header...

ruijtunes commented 4 years ago

In attach are the log files. I don't see any error:

retroarch2020_01_0115_36_01.log retroarch2020_01_0115_37_01.log

newsie-oss commented 4 years ago

Gee, that is weird. My log has something like this, which tells me that the core at least tried to load something.

[libretro INFO] Name:    METALSLUG2ND
[libretro INFO] System:  
[libretro INFO] Color
[libretro INFO] 
[libretro INFO] Catalog:  97 (sub 4)
[libretro INFO] Starting PC:  0x20004B
[libretro INFO] ROM:       4096KiB
ruijtunes commented 4 years ago

I tried again, Here are the output:

[libretro INFO] Name: METALSLUG2ND [libretro INFO] System:
[libretro INFO] Color [libretro INFO] [libretro INFO] Catalog: 24832 (sub 4) [libretro INFO] Starting PC: 0x002000 [libretro INFO] ROM: 4096KiB [libretro INFO] MDFN_MakeFName: sd:/retroarch/cores/savefiles/Metal Slug - 2nd Mission (World) (En,Ja).flash retroarch2020_01_0122_57_07.log

newsie-oss commented 4 years ago

Definitely a byteswapping issue. I think the endian conversion got botched. If you can compile your own code, please try this change:

https://github.com/libretro/beetle-ngp-libretro/edit/master/mednafen/mednafen-endian.h

static INLINE uint16 MDFN_de16lsb(const uint8 *morp)
{
  return le16toh(morp[0]|(morp[1]<<8));
}

static INLINE uint32 MDFN_de32lsb(const uint8 *morp)
{
  return le32toh(morp[0]|(morp[1]<<8)|(morp[2]<<16)|(morp[3]<<24));
}
ruijtunes commented 4 years ago

Sorry I can't compile it myself.

If you send me a rpx I can test it. Thanks

On Thu, Jan 2, 2020 at 12:31 AM newsie-oss notifications@github.com wrote:

Definitely a byteswapping issue. I think the endian conversion got botched. If you can compile your own code, please try this change:

https://github.com/libretro/beetle-ngp-libretro/edit/master/mednafen/mednafen-endian.h

static INLINE uint32 MDFN_de32lsb(const uint8 *morp) {

ifdef MSB_FIRST

return(morp[3]|(morp[2]<<8)|(morp[1]<<16)|(morp[0]<<24));

else

return(morp[0]|(morp[1]<<8)|(morp[2]<<16)|(morp[3]<<24));

endif

}

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/libretro/beetle-ngp-libretro/issues/84?email_source=notifications&email_token=AFB4BWNKI5JDMUZLIUNMBUTQ3UYVFA5CNFSM4KB2E2Y2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEH5PZAA#issuecomment-570096768, or unsubscribe https://github.com/notifications/unsubscribe-auth/AFB4BWPKKGBWXGPYAOESAQLQ3UYVFANCNFSM4KB2E2YQ .

ghost commented 4 years ago

That fix doesn't sound correct. MSB endian is important when we're accessing 2/4/8 bytes from memory. Code snippet says (uint8) 8-bit = 1 byte. Endian-ness shouldn't matter here; always reading bytes in correct order.

If it was uint16, uint32, uint64 then we'd have to reverse the bytes in CPU registers.

static INLINE uint16 MDFN_de16lsb(const uint8 *morp)
{
  return morp[0] | (morp[1]<<8);
}

static INLINE uint32 MDFN_de32lsb(const uint8 *morp)
{
  return morp[0] | (morp[1]<<8) | (morp[2]<<16) | (morp[3]<<24);
}

I'll try compiling a build later.

ghost commented 4 years ago

Try this Wii U build https://github.com/tailshine/beetle-ngp-libretro/blob/wiiu/mednafen_ngp_libretro.7z?raw=true

ruijtunes commented 4 years ago

It’s working fine with this build. 👍

ghost commented 4 years ago

One more test build before PR submission. https://github.com/tailshine/beetle-ngp-libretro/blob/wiiu/mednafen_ngp_libretro_2.7z?raw=true

Power PC may get speed boost. Mine goes some faster but was largely placebo.

edit: How many cores that need endian curing? https://github.com/libretro/beetle-wswan-libretro/blob/master/mednafen/mednafen-endian.h https://github.com/libretro/beetle-vb-libretro/blob/master/mednafen/mednafen-endian.h (** this one's curious looking)

ruijtunes commented 4 years ago

I tested this latest version of ngp core and it works fine.

I have the same problem with vb core after the update to 1.23.0 [libretro INFO] Title:
[libretro INFO] Game ID Code: 1447707205 [libretro INFO] Manufacturer Code: 17730 [libretro INFO] Version: 0 [libretro INFO] ROM: 1024KiB [libretro INFO] [libretro INFO] V810 Emulation Mode: Accurate [libretro INFO] (null)

The WonderSwan core Works.

ghost commented 4 years ago

Thanks for the info. Submitted ngp and wswan (there's some joypad and savestate endian-ness). Will look into vb also.

ghost commented 4 years ago

Is this core broken on Wii U or has it been fixed up??

ruijtunes commented 4 years ago

Has been working well. It was resolved.

ghost commented 4 years ago

Oh, nice. Would someone mind closing the issue?