KOF 2003 and SVC breaks FBNeo

[ZacharyFoxx]

Sorry, but I will open it again because I did not consider the "answer" in the issue #709 an answer, when I said in that issue which other ROMs as big as KOF2003 worked on the FBNeo core and that the same KOF2003 works on the FBAlpha2012 / FBAlpha2012_Neo core.

I tested other roms on the same core, as well as on another device and also with the FBalpha 2012 core before opening this complaint.

As I said earlier:

• KOF2003 breaks the core FBNeo. The same rom works perfectly with FBA2012/FBA2012_Neo cores.

• The rom version is correct.

• I tried the FBNeo core with other games like garou, kof2000, kof2001 mslug3 and matrimelee and them work perfectly. I tested another big roms like samsho5sp, samsho5, and them also loaded and worked perfectly.

• The only other rom where I found the problem was the svc.

• Core version used: Last one (04/04/2021) and one from 03/23/2021 on OUYA and version c51f30a on Xiaomi Mi Pad 7.9.

• The systems:

  • Device: OUYA
  • System: Android Jelly Bean
  • Version: 4.1
  • Device: Xiaomi Mi Pad 7.9
  • System: Android Nougat
  • Version: 7.1.2

• On OUYA, the ANR option is disable at Developer Menu. Even if i enable it there is no message. On Xiaomi Mi Pad the message is which "RetroArch has stopped", not anything about ANR.

• The size difference between the garou.zip and kof2003.zip roms is 4MB. Between kof2003.zip and samsho5.zip is 1MB. Between svc and samsho5 it is technically zero. If the problem was with Android as it was said:

  • All these big roms would be a problem and small roms would work normally.
  • The problem would also happen with the core fbalpha2012, which did not happen.

[barbudreadmon]

Did i say the problem was the size ? Clearly i don't know.

That problem is known (https://github.com/libretro/FBNeo/issues/248, https://github.com/libretro/FBNeo/issues/3, + several forum and reddit posts) and completely random, different devices with same android versions would show different results, same device with different retroarch version (32bits & 64bits) would show different results, same device with different controllers would show different results, which makes the fact that it's hardware/setup related a certainty as far as i'm concerned. I already spent enough time trying to solve this shit, it's not my fault if android manufacturers are stupid and randomly close apps, if you still need proof that it's what's happening, just check the 2 logs you posted, they don't stop at the same point, why do you think that is ? If it was the core crashing due to some internal error, it would crash at the same point. I don't know why the "disabling ANR" workaround doesn't work for you, and tbh i couldn't care less, i'm far beyond the point where i want to look into that android bullshit again.

If someone can provide a backtrace showing that it's an issue within the core, i'll be happy to fix it, however considering the known facts, i doubt that'll happen.

[barbudreadmon]

fwiw, i just gave a try to speeding up archives loading, some things felt wasteful. It might make loading marginally faster so it might help with that shitty issue. Whether it does or not, that's the last time i was looking into this.

[ZacharyFoxx]

fwiw, i just gave a try to speeding up archives loading, some things felt wasteful. It might make loading marginally faster so it might help with that shitty issue. Whether it does or not, that's the last time i was looking into this. Hi,

First of all, I would like to apologize for the way I treated your response, I was rude, I'm sorry.

About the last attempt to fix the problem, unfortunately it didn't work, it persists.

I know you said that you would not deal with the case anymore, but here's some information I don't know if you can help with the problem: I ran the retroarch with the log in DEBUG mode, and both on my Xiaomi Mi Pad 7.9 tablet and on OUYA, the DEBUG log always ends at the same point in both:

"[FBNeo] Applied dipswitches from core options Cheat cpu-register INIT. "

The only similarity between the devices is that they use an Nvidia processor and are 32-bit, but speed, amount of memories and even the Android version are different.

I know you mentioned that this is something related to decrypting files, but I don't think it would make much sense since other games that in theory use the same encryption mode, like matrimelee and samsho5, normally run on the core.

The logs are attached.

Thank you very much for the work on the core.

MIPAD-KOF2003.log MIPAD-SVC.log OUYA-SVC-FBNeo.log OUYA-KOF2003-FBNeo.log

[barbudreadmon]

Again, i don't know what this is about, in one of your first logs we can clearly see it's closing before even looking for files, meaning the theory about this issue being about the romsets, their size or their content didn't seem to be valid. Now it goes further, why ? On my android phone i'm able to run those games with both 32-bits & 64-bits retroarch, several other people also confirmed they could run them without issues. I only see randomness here, and trying to debug randomness seriously piss me off, especially when several people also confirmed disabling the ANR shit solved their issue.

FWIW, from where those new logs end, it seems your issue happens in that part of the code, i see two potentially demanding thing :

• it will try to find hiscores for that game in hiscore.dat, i guess looking through that file can potentially take time, so if you got hiscore.dat, maybe it could be worth disabling hiscores to see if it's fixing something
• the actual loading of the game into ram, with decryption and whatever could be necessary to run the game, matrim and samsho5 have a much simpler decryption, this is not even comparable.

This is the decryption callback for kof2003 :

static void kof2003Callback()
{
    INT32 i, j, k;
    for (i = 0; i < 0x100000; i++)
        Neo68KROMActive[i] ^= ~Neo68KROMActive[0x0fffe0 + (i & 0x1f)];

    for (i = 0; i < 0x100000; i++)
            Neo68KROMActive[0x800000 + i] ^= Neo68KROMActive[0x100002 | i];

    for (i = 0x100000; i < 0x800000; i++)
        Neo68KROMActive[i] ^= ~Neo68KROMActive[0x7fffe0 + (i & 0x1f)];

    for (i = 0x100000; i < 0x800000; i += 4) {
        UINT16 rom16 = BURN_ENDIAN_SWAP_INT16(*((UINT16 *)(Neo68KROMActive + i + 1)));
        rom16 = BITSWAP16(rom16, 15, 14, 13, 12, 5, 4, 7, 6, 9, 8, 11, 10, 3, 2, 1, 0);
        *((UINT16 *)(Neo68KROMActive + i + 1)) = BURN_ENDIAN_SWAP_INT16(rom16);
    }

    memmove (Neo68KROMActive + 0x700000, Neo68KROMActive, 0x100000);

    for (i = 0; i < 0x0100000 / 0x10000; i++) {
        j = BITSWAP08(i, 7, 6, 5, 4, 0, 1, 2, 3);
        memmove (Neo68KROMActive + i * 0x010000, Neo68KROMActive + 0x700000 + j * 0x010000, 0x010000);
    }

    memmove (Neo68KROMActive + 0x200000, Neo68KROMActive + 0x100000, 0x600000);

    for (i = 0x200000; i < 0x900000; i += 0x100000)
    {
        for (j = 0; j < 0x100000; j += 0x100)
        {
            k  = (j & 0xf00) ^ 0x00800;
            k |= BITSWAP08(j >> 12, 4, 5, 6, 7, 1, 0, 3, 2 ) << 12;

            memmove (Neo68KROMActive + 0x100000 + j, Neo68KROMActive + i + k, 0x100);
        }

        memmove (Neo68KROMActive + i, Neo68KROMActive + 0x100000, 0x100000);
    }
}

=> hundreds of thousands of memmove + hundreds of thousands bitswapping + hundreds of thousands of other stuff

this is the decryption callback for matrim :

static void PCM2DecryptP()
{
    // Descamble P-ROMs

    UINT8* pTemp = (UINT8*)BurnMalloc(0x400000);

    if (pTemp) {
        memmove(pTemp, Neo68KROMActive + 0x100000, 0x400000);

        for (INT32 i = 0; i < 4; i++) {
            memmove(Neo68KROMActive + 0x100000 + i * 0x100000, pTemp + 0x000000 + (((((i + 2) & 1) << 2) | ((i + 2) & 2)) << 19), 0x80000);
            memmove(Neo68KROMActive + 0x180000 + i * 0x100000, pTemp + 0x080000 + (((((i + 1) & 1) << 2) | ((i + 1) & 2)) << 19), 0x80000);
        }

        BurnFree(pTemp);
    }
}

=> 9 memmove

[barbudreadmon]

it will try to find hiscores for that game in hiscore.dat, i guess looking through that file can potentially take time, so if you got hiscore.dat, maybe it could be worth disabling hiscores to see if it's fixing something

Thinking again about that, it would actually make quite some sense for the shorter loading with fbalpha2012, since fbalpha2012 didn't include any support for hiscore.dat in the neogeo driver. All neogeo games, including kof2003 & svc, were erronously tagged as compatible with hiscore.dat since then (while only a dozen actually exist in hiscore.dat), meaning a useless lookup through hiscore.dat (not a big problem though if your device is not stupid enough to close apps without asking), i just removed them so it should reduce the loading time a bit on setups with hiscore.dat.

[ZacharyFoxx]

Hi barbudreadmon,

I appreciate the explanation. Sorry, I did not post the message wanting you to respond immediately. I agree with you which to be looking for something that appears randomly really stressed and tired.

But if you will allow me, I will ask a question considering everything you have explained here, but you do not need to answer it now.

Actually the kof2003 decryption code is much more complex than the matrimelee and I understood perfectly why it would be a problem and the matrimelee would not.

I went to see the file that has this function and if I looked right it is d_neogeo.cpp. If I understand correctly, if the function is shared, other games use it. Apparently samsho5 uses the same PCM2DecryptP function as matrimelee and it seems that kof2003, svc and mslug5 have their own functions.

I compared it to fbalpha2012 because as I told you, these games work on it.

Comparing the code for kof2003, the only difference is this:

kof2003 fba2012:

        Neo68KROMActive[i] ^= ~Neo68KROMActive[0x7fffe0 + (i & 0x1f)];

    for (i = 0x100000; i < 0x800000; i += 4) {
!       UINT16 rom16 = BURN_ENDIAN_SWAP_INT16(BURN_UNALIGNED_READ16(Neo68KROMActive + i + 1));
        rom16 = BITSWAP16(rom16, 15, 14, 13, 12, 5, 4, 7, 6, 9, 8, 11, 10, 3, 2, 1, 0);
        *((UINT16 *)(Neo68KROMActive + i + 1)) = BURN_ENDIAN_SWAP_INT16(rom16);
    }

kof2003 fbneo:

        Neo68KROMActive[i] ^= ~Neo68KROMActive[0x7fffe0 + (i & 0x1f)];

    for (i = 0x100000; i < 0x800000; i += 4) {
!       UINT16 rom16 = BURN_ENDIAN_SWAP_INT16(*((UINT16 *)(Neo68KROMActive + i + 1)));
        rom16 = BITSWAP16(rom16, 15, 14, 13, 12, 5, 4, 7, 6, 9, 8, 11, 10, 3, 2, 1, 0);
        *((UINT16 *)(Neo68KROMActive + i + 1)) = BURN_ENDIAN_SWAP_INT16(rom16);
    }

Where fbalpha uses "BURN_UNALIGNED_READ16" fbneo uses "UINT16".

In fbalpha2012, kof2003 apparently uses memmove but mslug5 and svc use memcpy

The same difference appears in svc and mslug5:

svc fba2012:

{
UINT16 rom16 = BURN_UNALIGNED_READ16 (Neo68KROMActive + i + 1);
rom16 = BITSWAP16 (BURN_ENDIAN_SWAP_INT16 (rom16), 15, 14, 13, 12, 10, 11, 8, 9, 6, 7, 4, 5, 3, 2, 1, 0);
BURN_UNALIGNED_WRITE16 (Neo68KROMActive + i + 1, BURN_ENDIAN_SWAP_INT16 (rom16));
}

fbneo svc:

{
UINT16 rom16 = * (((UINT16 *) (Neo68KROMActive + i + 1));
rom16 = BITSWAP16 (BURN_ENDIAN_SWAP_INT16 (rom16), 15, 14, 13, 12, 10, 11, 8, 9, 6, 7, 4, 5, 3, 2, 1, 0);
* (((UINT16 *) (Neo68KROMActive + i + 1)) = BURN_ENDIAN_SWAP_INT16 (rom16);
}

mslug5 fba2012:

{
        UINT16 rom16 = BURN_ENDIAN_SWAP_INT16(BURN_UNALIGNED_READ16(Neo68KROMActive + i + 1));
        rom16 = BITSWAP16(rom16, 15, 14, 13, 12, 10, 11, 8, 9, 6, 7, 4, 5, 3, 2, 1, 0);
        BURN_UNALIGNED_WRITE16(Neo68KROMActive + i + 1, BURN_ENDIAN_SWAP_INT16(rom16));
    }

mslug5 fbneo:

{
        UINT16 rom16 = BURN_ENDIAN_SWAP_INT16(*((UINT16 *)(Neo68KROMActive + i + 1)));
        rom16 = BITSWAP16(rom16, 15, 14, 13, 12, 10, 11, 8, 9, 6, 7, 4, 5, 3, 2, 1, 0);
        *((UINT16 *)(Neo68KROMActive + i + 1)) = BURN_ENDIAN_SWAP_INT16(rom16);
    }

Could this be causing the problem?

But again, thank you very much for your work and sorry for the inconvenience.

[barbudreadmon]

Could this be causing the problem?

Definitely not, that code is the same as before :

#define BURN_UNALIGNED_READ16(x) (*(UINT16 *) (x))

We just replaced the macro(s) by the actual code behind it.

Again, the only thing that comes into mind for the difference between fbalpha2012 and now is the hiscore support, i also believe fbalpha2012 was using "raw" functions for opening and reading files, while fbneo is using the libretro "filestream" replacement for compatibility with some platforms (xbox iirc ?), this replacement might be slower.

[barbudreadmon]

i was able to confirm the old fbalpha2012 core doesn't use the libretro filestream stuff, i never benchmarked but i believe using that stuff makes file access a lot slower, the thing is it was forced onto me for compatibility with some platforms and i don't really have a choice but to keep it.

[barbudreadmon]

I managed to disable this filestream stuff specifically on android builds (https://github.com/libretro/FBNeo/commit/68a89a7dd458f843e23f2ac17883d8ba58c1cf2c), it should be ok since i believe android shouldn't be one of the platforms where it's required, let me know if it solves anything. If it doesn't, well, i'm out of idea to make loading faster. Btw, you never told me if you are using hiscores or not.

[ZacharyFoxx]

I managed to disable this filestream stuff specifically on android builds (68a89a7), it should be ok since i believe android shouldn't be one of the platforms where it's required, let me know if it solves anything. If it doesn't, well, i'm out of idea to make loading faster. Btw, you never told me if you are using hiscores or not.

Hi barbudreadmon,

I tested the latest version and .... I had the same result, lol! It will be a mystery, lol =).

I will be using FBalpha2012 as it has the least drawback for me and there is no problem with the CPS-3 games, because in OUYA the CPS-3 games start at 60fps but sometimes there are some drops. And I am testing FBNeo ... it will work on these NeoGeo ROMs =).

I would just like to ask for one more favor, but only if it is possible and you have time: would you like to see an issue that I opened on fbalpha2012 and if you had any idea about where the problem might be?

This is it: https://github.com/libretro/fbalpha2012/issues/103

But only if you can and have availability.

Again I want to thank you for trying to solve this FBNeo problem and thank you for making this nucleus available, thank you very much =).

[barbudreadmon]

CPS-3 games start at 60fps but sometimes there are some drops

Yeah, lots of gfx glitches with CPS3 were fixed over the past 3 years, you need some reasonably good device and that's also why i know the fbalpha2012 core doesn't crash since tons of older pi models users are still using it because of that. Also, let me be clear : absolutely no changes done to the fbalpha2012 core between that working backup from 2020-02-29 and your PR from 4 days ago could explain a cps3 emulation regression, or even affect it a very far-fetched way, i spent some time inspecting git history to make sure of that, so as far as i'm concerned it's no different from the trolling your android device is doing with kof2003/svc and FBNeo. Android is a broken OS, my recommendation is to not use it for emulation if you can avoid it, or to live with its bugs.

[ZacharyFoxx]

CPS-3 games start at 60fps but sometimes there are some drops

Yeah, lots of gfx glitches with CPS3 were fixed over the past 3 years, you need some reasonably good device and that's also why i know the fbalpha2012 core doesn't crash since tons of older pi models users are still using it because of that. Also, let me be clear : absolutely no changes done to the fbalpha2012 core between that working backup from 2020-02-29 and your PR from 4 days ago could explain a cps3 emulation regression, or even affect it a very far-fetched way, i spent some time inspecting git history to make sure of that, so as far as i'm concerned it's no different from the trolling your android device is doing with kof2003/svc and FBNeo. Android is a broken OS, my recommendation is to not use it for emulation if you can avoid it, or to live with its bugs.

Yes, I think this is one of the reasons to keep fbalpha2012, it is lighter and better for weaker devices.

About Android it's not really a question of not being able to avoid it, it's more because of the convenience of being able to stay on the couch playing as if it were on a console.

Before asking you about the fbalpha2012 bug in my issue, I looked at the commits after the release I mentioned and couldn't find anything that could interfere with the cps3 drive. I saw some commits in other files not related to cps3, but they involve cpus from other systems as I understand it.

I can use FBAlpha2012, I just need to do the same workaround that I was using with FBNeo: use the fbalpha2012_cps3 core, which does not present this bug with sfiii. Unfortunately it only has one other bug, including on Linux (I haven't tested it on Windows): it is not creating the .sf files that save the difficulty, speed, etc. settings. Even on Linux it does not generate files in the "saves" directory.

[barbudreadmon]

About Android it's not really a question of not being able to avoid it, it's more because of the convenience of being able to stay on the couch playing as if it were on a console.

Then live with its bugs :). On a sidenote, some android devices appear to be a bit more stable (mine is an old asus zenphone with android 6 and ran those games without issues when it was first reported to me), but i would be totally unable to help you identify them, something i noticed though (but i guess the ouya is putting a stop to that rule) : every reports until now seemed to involve an android device from a chinese brand. Something i'm wondering : are you installing apk yourself or are you using the retroarch stuff from the playstore ? I know differences have been observed between the 2 versions on some cores, maybe that could be the case here ?

[ZacharyFoxx]

About Android it's not really a question of not being able to avoid it, it's more because of the convenience of being able to stay on the couch playing as if it were on a console.

Then live with its bugs :). On a sidenote, some android devices appear to be a bit more stable (mine is an old asus zenphone with android 6 and ran those games without issues when it was first reported to me), but i would be totally unable to help you identify them, something i noticed though (but i guess the ouya is putting a stop to that rule) : every reports until now seemed to involve an android device from a chinese brand. Something i'm wondering : are you installing apk yourself or are you using the retroarch stuff from the playstore ? I know differences have been observed between the 2 versions on some cores, maybe that could be the case here ?

If not even life is perfect and bug-free, imagine the emulators, lol =)!

About the hardware: If they were devices with more buggy chips, with allwinner or rockchip, I would understand to have problems. But both devices use Nvidia's chip, the Tegra. The one on the tablet is the Tegra K1, which precedes the X1 used on the Nintendo Switch, so there's no lack of power to run (I emulate dreamcast on it without problems.). His only disadvantage is that it is not 64 bits, just 32 bits.

About the way I install: In OUYA I use the version downloaded directly from the retroarch website. Just unpack the APK package to include the standard icon used by OUYA and pack it again. On the Tablet I use the PlayStore version, but I installed the version from the website too, with the same result.

But I have some news, good news: the bootleg versions worked. As you said several times that the problem would be decompression, I decided to test the bootleg versions of mslug5, kof2003 and svc and they all worked normally, both on OUYA and on the Tablet Mi Pad. I hadn't tested it because as I said, I understand that OUYA can be a problem, but the tablet has plenty of power.

And what I had said about fbalpha2012_cps3 I confirmed on windows: it does not generate the save files for the machine's settings, whether on Linux, Windows or Android.

I know I already asked and took too much of your time, but could you tell me if it is the core that is responsible for saving such files or is it the retroarch that it generates?

I thought the problem was in the core, because it had the wrong path, I even applied a patch that was applied to fbalpha2012 ( https://github.com/libretro/fbalpha2012_cps3/pull/10 ), but it didn't work.

[barbudreadmon]

I would understand to have problems. But both devices use Nvidia's chip, the Tegra

Imho, that's not chipset issues but OS issues, those brand are probably doing something stupid to tune the OS performance and somehow it backfires on some apps.

I know I already asked and took too much of your time, but could you tell me if it is the core that is responsible for saving such files or is it the retroarch that it generates?

In FBNeo, nvrams are handled by the core through eeprom.cpp or libretro.cpp, in the case of cps3 i believe libretro.cpp is generating a .fs file.

[barbudreadmon]

@ZacharyFoxx i just did another blind attempt at fixing that wrong behavior on android, please let me know if it improves situation with those games

[ZacharyFoxx]

@ZacharyFoxx i just did another blind attempt at fixing that wrong behavior on android, please let me know if it improves situation with those games

Hi,

Sorry for the delay in responding, work overload at the end of May, I just saw your post today.

I will test and tell you.

[ZacharyFoxx]

@ZacharyFoxx i just did another blind attempt at fixing that wrong behavior on android, please let me know if it improves situation with those games

HI.

Tested and the result remains:

• roms kof2003.zip, mslug5.zip and svc.zip do the retroarch crash.
• kf2k3bla.zip, mslug5b.zip and svcboot.zip roms work normally.

[barbudreadmon]

If you are interested in looking once more at this issue, i could add back the verbose stuff i did on the other issue, so that we learn when it's crashing in your case and maybe figure out something from that.

[ZacharyFoxx]

If you are interested in looking once more at this issue, i could add back the verbose stuff i did on the other issue, so that we learn when it's crashing in your case and maybe figure out something from that.

hello @barbudreadmon,

I had downloaded the d5be072 version and tested it today and:

• On Xiaomi Mi Pad: All three roms worked. YES!!!
• On OUYA: KOF2003 and SVC worked without problems. YES!! Metal Slug 5 loaded, but the image was all artifacts. Since UNIBIOS is used, part of its logo is left with artifacts but another part is normal. The bootleg version works without problems.

If you want, I can take a screenshot and generate the log via retroarch and logcat to see if you have any error messages to analyze.

I'd like to ask you a favor: I know you're not the fbalpha2012 core maintainer, but I've also retested fbalpha2012 and even though the retroarch log doesn't give any clues, the Android log via logcat shows a more specific error when I use the rom from sfIII, and only this rom. Could you look and give your opinion?

I know the core is already old, but precisely because it is lighter than the current FBNeo, it's better for older devices. Also, some FBNeo games that were slow, like Gunbird 2, on fbalpha2012 runs without problems.

Could you take a look? No rush, no need to respond quickly.

[barbudreadmon]

If you want, I can take a screenshot and generate the log via retroarch and logcat to see if you have any error messages to analyze.

For now, a screenshot would be welcome.

Again, i'm not gonna look at that fbalpha2012_cps3 core, in the first place you shouldn't be using it, those split cores are for platforms with memory in the 2 digits (3ds, wii), and completely useless in the case of the cps3 one which won't run full speed on those platforms anyway, i can't imagine your android being in that category, so use standard fbalpha2012.

Edit : i ended up taking a quick glance, BurnStateSave (which saves the eeprom) won't work if called after BurnDrvExit (which close everything related to the game), that's probably what's happening since i believe retro_unload_game is called before retro_deinit.

[leoxxx]

So, is your issue the same as mine, unaligned?

[ZacharyFoxx]

If you want, I can take a screenshot and generate the log via retroarch and logcat to see if you have any error messages to analyze.

For now, a screenshot would be welcome.

Again, i'm not gonna look at that fbalpha2012_cps3 core, in the first place you shouldn't be using it, those split cores are for platforms with memory in the 2 digits (3ds, wii), and completely useless in the case of the cps3 one which won't run full speed on those platforms anyway, i can't imagine your android being in that category, so use standard fbalpha2012.

Edit : i ended up taking a quick glance, BurnStateSave (which saves the eeprom) won't work if called after BurnDrvExit (which close everything related to the game), that's probably what's happening since i believe retro_unload_game is called before retro_deinit.

Hi,

About metal slug 5, follow the screenshots:

Android's logcat and retroarch's own log show no problem. The bootleg version works normally as well as the other metal slug.

About the help for the fbalpha2012 core, it wouldn't be about the fbalpha2012_cps3 core, it's for the fbalpha2012 core itself, issue https://github.com/libretro/fbalpha2012/issues/103. Sorry for not explaining clearly..

I'll quickly explain what I found:

The retroarch log gives no clue to the error, but using the Android logcat it shows this error:

signal 7 (SIGBUS), code 1 (BUS_ADRALN), fault addr 6fb96de6 (Disregard the address, it varies from device to device.).

Searching the internet, I found this to be an unaligned mem access problem. This even affects Nvidia Shield.

The QuickNES core had two issues that address this and the solution is in commit 5959457, including the parameter "-DNO_UNALIGNED_ACCESS" in the Android-only build.

Do you see any issues if I make a pull request to include this in fbalpha2012's Android.mk file?

PS: And again, thank you so much for your patience and attention, thank you very much =)!

[ZacharyFoxx]

So, is your issue the same as mine, unaligned?

Yes. The fix was almost perfect, only mslug5 still has some problem.

[barbudreadmon]

The QuickNES core had two issues that address this and the solution is in commit 5959457, including the parameter "-DNO_UNALIGNED_ACCESS" in the Android-only build. Do you see any issues if I make a pull request to include this in fbalpha2012's Android.mk file?

Feel free to try, as i already said i'm not interested by those fbalpha2012 issues, so please don't ask me. Just a quick comment about misalignment though : there are tools to debug them, namely ubsan.

Back to your mslug5 issue, it does look like some kind of memory corruption, i see the ouya has very little memory so maybe android is doing something stupid to keep memory available ? Also, make sure you are using default core options (minus frameskip which i highly recommend to enable considering the framerate i see at top right) and don't have some corrupted mslug5.fs eeprom.

[barbudreadmon]

In Settings > Logging, make sure you set Core Logging Level to 0 (Debug), then post your logs. We might find some BurnMalloc failed to allocate x bytes of memory! messages...

[ZacharyFoxx]

In Settings > Logging, make sure you set Core Logging Level to 0 (Debug), then post your logs. We might find some BurnMalloc failed to allocate x bytes of memory! messages...

Hi,

Ok. I will test it tomorrow and post here!

Thank You.

[ZacharyFoxx]

In Settings > Logging, make sure you set Core Logging Level to 0 (Debug), then post your logs. We might find some BurnMalloc failed to allocate x bytes of memory! messages...

Hi,

The log file is attached.

retroarch2021_06_0316_40_46.log

The menu' s bios work without problems:

PS: It's the same bios and rom used in all devices.

[barbudreadmon]

Hmmm nothing unusual in those logs. In core options, could you try disabling 32-bits color depth ?

[ZacharyFoxx]

Hmmm nothing unusual in those logs. In core options, could you try disabling 32-bits color depth ?

I will do this this weekend. I'll try something: install an unofficial lineage in OUYA to see what happens.

[ZacharyFoxx]

Hmmm nothing unusual in those logs. In core options, could you try disabling 32-bits color depth ?

I formatted OUYA to use the unofficial lineage, Android 4.4 (KitKat), and the new FBNeo version crashed with any rom. The log for core was in "debug" and for retroarch only in "error" and it is generated without any information. The same error was repeated with the default OUYA rom. On Xiaomi Mi Pad (Android 7.1) the core works normally. If I think it's valid, I can get the logcat output to see what error Android points to.

[leoxxx]

I think maybe it's the gpu driver error.

[ZacharyFoxx]

Hi @barbudreadmon ,

I know this issue is closed, but I would like to Thank You, again!

Yesterday, after a while, I tried again the FBNeo on OUYA and the Metal Slug 5 worked perfectly and the CPS3 games ran perfectly too!

Again, Thank You =)!

[barbudreadmon]

CPS3 games ran perfectly too!

I implemented a speedhack for those a few months ago, so they should run a fair bit faster than they did.