search

libretro / FBNeo

FBNeo - We are Team FBNeo.
https://neo-source.com
Other
224 stars 134 forks source link

Elevator Action Returns (elvactr, Taito F3) blackscreens on Wii U (big-endian issue?) #459

Closed vaguerant closed 4 years ago

vaguerant commented 4 years ago

Nothing seems to work at all, it's an immediate black screen and there's no audio either. If the game is responding to controls, it's impossible to tell. From experience emulating this in other cores like the decades-old MAME versions, this is another case where performance on Wii U probably precludes playing this game anyway. Still, assuming this is an endian issue, a fix would likely benefit the more powerful big-endian platforms.

Tested with 7c032d1, commited yesterday and the current nightly as of this report.

barbudreadmon commented 4 years ago

Maybe @crystalct will be interested. Fwiw the soundboard used by taito f3 (es5506) got endian-fixed last week.

barbudreadmon commented 4 years ago

NB : with https://github.com/finalburnneo/FBNeo/commit/3b2050807f75e4bb356121513bfef422ae9cfb57 everything seems ok except coins, i believe there is some shenanigans about DrvCoinWord but i won't have time to look further into it right now.

crystalct commented 4 years ago

After mystwarr, i will take a look at it

crystalct commented 4 years ago

Reading news on the beach, i read that Wii U Is the best consolle for playing retro games....what do you think? What do you use for playing them?

Il dom 9 ago 2020, 18:14 barbudreadmon notifications@github.com ha scritto:

NB : with finalburnneo@3b20508 https://github.com/finalburnneo/FBNeo/commit/3b2050807f75e4bb356121513bfef422ae9cfb57 everything seems ok except coins, i believe there is some shenanigans about DrvCoinWord but i won't have time to look further into it right now.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/libretro/FBNeo/issues/459#issuecomment-671070722, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAMY7LPOLNRQLKDJCXI7N7DR73DMRANCNFSM4PZGHGLQ .

barbudreadmon commented 4 years ago

I use my computer, and arm SoCs from time to time. Saying Wii U is a good console for emulation is an awful joke, let alone the fact that it's another of those big-endian nightmares, the specs are also worse than ps3/xbox360. There are also better choices for emulation in more recent consoles (switch, xbox one; afaik the xbox one doesn't even require any kind of jailbreak to install third-party apps).

vaguerant commented 4 years ago

As someone who does use a Wii U as their primary emulator platform, everything barbudreadmon says is correct. Technically you could argue re: the specs on Wii U vs. PS3/360 due to the multi-core nature of the Wii U CPU, but the deciding factor for an emulator box is the single-core performance, and the Wii U's is poor.

Now, if you're only interested in playing games you can officially buy, the Wii U is probably the best retro gaming platform on the market currently. The eShop is still up and the Virtual Console library is better than you can get on any other console. That's with the note that the original Wii had a larger Virtual Console library, but that shop has been shut down. That said, once you bring hacking and homebrew into it, there's really very little that the Wii U does exceptionally. In terms of the actual advantages you get on Wii U, you've got:

The homebrew community on Wii U is small. Emulation is almost entirely reliant on the RetroArch Wii U port, and you can run RetroArch on basically anything, so you're not gaining anything over other platforms that way--indeed, you're losing out on many cores due to the big-endian and PPC architecture. Meanwhile, on something like the (LE, ARM) Switch, you get cores like pcsx-reARMed for PlayStation emulation. One of the few emulators that was natively ported to Wii U outside of RetroArch, PPSSPP, exists only in an abandoned state with many issues relating to its incomplete big-endian support.

In short, there's really very little that makes the Wii U a good emulator box beyond them being pretty cheap and/or already in the home.

barbudreadmon commented 4 years ago

In short, there's really very little that makes the Wii U a good emulator box beyond them being pretty cheap and/or already in the home.

I think ps3 is even cheaper since they sold a ton of them, i'm sure Wii U will become popular (and pricier ?) after some years, as you said it has pretty much native gamecube/wii support, and also some nice exclusives that have yet to be re-released on switch.

barbudreadmon commented 4 years ago

I'm totally lost about the remaining taito f3 issues, i spent quite some time today testing everything, from what i can tell :

Maybe @dinkc64 can figure out something from this list of game ? Otherwise i'm probably gonna give up.

dinkc64 commented 4 years ago

once I have time - sure :) (working on a huge project w/k054539, have to check out some stuff iq_132 wanted me to check out, then some other stuff 3 other people wanted me to check out),

best regards,

barbudreadmon commented 4 years ago

1 erratum and 1 precision about my previous statement :

barbudreadmon commented 4 years ago

So it appears f3_main_write_byte is writing some crap when comparing ps3 to x86, but currently i've no idea why (NB : it's handled by musashi - the m68k cpu core - which should be endian-safe).

Edit: not sure of anything and kinda lost here, as said in https://github.com/finalburnneo/FBNeo/commit/89fc28a5afb1595975e2fa060f7a3bd07a3e19b6 another driver using kinda similar hardware has no obvious issue.

dinkc64 commented 4 years ago

the only other driver with similar hardware would be superchase :)

crystalct commented 4 years ago

Back here... Tested a bit elvactr.... DrvCoinWord[0] and DrvCoinWord[1] are always read and written correctly...on x86 and PS3 and values seems a sort of command (0x00, 0x03 and 0x07). I see 0x07 when insert coin is pushed. But where is memory location where coins are added? Who write there? d_taitof3.cpp contains many games... some of them correct and others no (coins) ... all games uses DrvCoinWord... so weird. I noticed on PS3 at start of elvactr one frame with written EPROM FAIL in red. On x86 no. Could it be a sort of protection to not play game?

barbudreadmon commented 4 years ago

The content of eeprom isn't written properly because f3_main_write_byte is writing some crap.

barbudreadmon commented 4 years ago

@dinkc64 superchs seems ok too with https://github.com/finalburnneo/FBNeo/commit/ee286cc2c5c449f1fd73ef21f86116cffdbe6ee4

barbudreadmon commented 4 years ago

i went a bit further, it seems the issue starts with the interpreter writing some crap into the 0x400000-0x41ffff memory region

crystalct commented 4 years ago

I think there isn't issues inside d_taitof3.cpp about coins.... Anyway i found a workaround: as scfinals i used service insted coin using that kludge and now works. I putted supercupkludge = 1; inside elvactrInit()

dinkc64 commented 4 years ago

crystalct, we need to find the real source of the problem and fix that instead :)

dinkc64 commented 4 years ago

barbudreadmon, nice work :)

regarding "x is writing some crap" - probably the 68k program has partially crashed somehow due to something else being read wrong w/LE->BE issues. erm. I'm again out of ideas, but will keep thinking about it.

crystalct commented 4 years ago

It Is just a plan B :)

Il mar 25 ago 2020, 02:55 dinkc64 notifications@github.com ha scritto:

barbudreadmon, nice work :)

regarding "x is writing some crap" - probably the 68k program has partially crashed somehow due to something else being read wrong w/LE->BE issues. erm. I'm again out of ideas, but will keep thinking about it.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/libretro/FBNeo/issues/459#issuecomment-679439969, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAMY7LL4KIGE7VQ3PYBF4F3SCMDYTANCNFSM4PZGHGLQ .

barbudreadmon commented 4 years ago

There is no plan B here, i did some tests last week, even if you pass the no-coin issue, those games remain unplayable.

crystalct commented 4 years ago

Ok. Who call f3_main_write_byte outside d_taitof3.cpp? m68kcpu.c directly? In other words, where move attentions to investigate?

edit...no... it seems m68000_intf.cpp

barbudreadmon commented 4 years ago

Yes, src/cpu/m68000_intf.cpp and the content of src/cpu/m68k/ are handling that part. I'm trying to find the origin by comparing the variables between x86/ps3, currently i'm there : https://github.com/libretro/FBNeo/blob/ecce1ad3626d8ddfb7ae4efd1534abeea28a2984/src/cpu/m68000_intf.cpp#L460-L493

=> at some point, the value of d arg differ between x86 and ps3

crystalct commented 4 years ago

I suppose you have already noticed that when pSekExt->WriteLong[(uintptr_t)pr](a, d); is reached, d isnt swapped.... weird?

barbudreadmon commented 4 years ago

Nope, it's normal, when pSekExt->WriteLong[(uintptr_t)pr](a, d); is reached, it means it'll use a special handler in the driver, example the one defined by SekSetWriteLongHandler(1, f3_palette_write_long);, in that case the endianess needs to be handled in f3_palette_write_long.

barbudreadmon commented 4 years ago

So the issue happens between ReadLong and WriteLong.

The first occurence of the issue goes like this :

This is what ReadLong log on both arch : ReadLong 4001fb 7f ff ff ff 7fffffff first num is address, 2nd to 5th nums are the readed bytes, 6th num is return value (before endianization)

This is what the next WriteLong writes on each arch : x86 : WriteLong 4001fb 1fffffff ps3 : WriteLong 4001fb bfffff7f

2 theories :

barbudreadmon commented 4 years ago

It'll require more tests, but it seems removing the endian macro at https://github.com/libretro/FBNeo/blob/ecce1ad3626d8ddfb7ae4efd1534abeea28a2984/src/cpu/m68000_intf.cpp#L429 fix this issue If that's the right fix, then i guess the same should probably be done in ReadWord

barbudreadmon commented 4 years ago

That's not a proper fix, the writes are still going bonkers even if elvactr is now playable, and other games with other glitches are still unplayable. But well, there is probably something wrong with unaligned accesses in our musashi cpu core, mame is handling those quite differently : https://github.com/mamedev/mame/blob/65abe0cd888078a242744383c8372c46e87f2090/src/devices/cpu/m68000/m68kcpu.cpp#L1383 It probably also explains why some taito f3 games need kludge on x86.

crystalct commented 4 years ago

Do you have understuud why certain F3 games dont have that isssue?

Il mar 25 ago 2020, 15:26 barbudreadmon notifications@github.com ha scritto:

That's not a proper fix, the writes are still going bonkers even if elvactr is now playable, and other games with other glitches are still unplayable. But well, there is probably something wrong with unaligned accesses in our musashi cpu core, mame is handling those quite differently : https://github.com/mamedev/mame/blob/65abe0cd888078a242744383c8372c46e87f2090/src/devices/cpu/m68000/m68kcpu.cpp#L1383 It probably also explains why some taito f3 need kludge on x86.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/libretro/FBNeo/issues/459#issuecomment-680023782, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAMY7LOVQKAGYDWOK4S2PSTSCO3YNANCNFSM4PZGHGLQ .

dinkc64 commented 4 years ago

dink fixes all

barbudreadmon commented 4 years ago

Do you have understuud why certain F3 games dont have that isssue?

That's just because they are accessing memory differently, anyway all issues are finally fixed with https://github.com/finalburnneo/FBNeo/commit/ce3581e41c5f97b7a56afd3c117785aebf11e15f, basically there was a bunch of endian fixes in the m68k cpu core that needed to be removed.

crystalct commented 4 years ago

Dink final touch ^_^

barbudreadmon commented 4 years ago

worst case scenario : some games using the m68k 020 variant cpus that previously worked might break from this, but that would be because they weren't properly fixed in the first place.

crystalct commented 4 years ago

And we will fix them ;)

crystalct commented 4 years ago

Thanks a lot, taito F3 games are very nice!!!

dinkc64 commented 4 years ago

f3 is amazing. I especially like "Grid Seeker: Project Storm Hammer", great music, awesome shooting :) .. and that's just one of them, there's so many more great games!! :D

vaguerant commented 4 years ago

Just confirming that with the latest nightly, Elevator Action (and Taito F3) are running correctly on Wii U. The framerate is a mighty ~18 FPS on Wii U, but everything works.

barbudreadmon commented 4 years ago

@crystalct do you have better perf on ps3 ?

crystalct commented 4 years ago

On emulator (compiled mode) a lightning...on real PS3 i Will try it

Il mer 26 ago 2020, 11:08 barbudreadmon notifications@github.com ha scritto:

@crystalct https://github.com/crystalct do you have better perf on ps3 ?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/libretro/FBNeo/issues/459#issuecomment-680757686, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAMY7LK2KK6EUDVWKFRFGN3SCTGHLANCNFSM4PZGHGLQ .

crystalct commented 4 years ago

@vaguerant Is It possible run homebrew software on Wii U emulator?

Il mer 26 ago 2020, 10:32 vaguerant notifications@github.com ha scritto:

Just confirming that with the latest nightly, Elevator Action (and Taito F3) are running correctly on Wii U. The framerate is a mighty ~18 FPS on Wii U, but everything works.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/libretro/FBNeo/issues/459#issuecomment-680740164, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAMY7LL72KGXKS7VIIJRLTTSCTCC7ANCNFSM4PZGHGLQ .

vaguerant commented 4 years ago

It is, but within some limitations. I'm not a dev and have no experience with Wii U emulation myself, but my understanding is that the open-source Decaf emulator is more often used for homebrew debugging, while the closed-source Cemu is not usually great for homebrew software. The homebrew libraries on Wii use certain instructions that commercial games don't, and rather than aiming to implement a hardware-complete recreation of the Wii U, the Cemu author just implements features as-needed, which leaves its homebrew support less functional than its support for commercial games.

I personally have no idea how well RetroArch runs on either emulator, assuming it runs at all.

crystalct commented 4 years ago

I tired to run RetroArch on Cemu without sucess... Maybe the other emulator....i Will try...Just for curiosity

Il mer 26 ago 2020, 12:03 vaguerant notifications@github.com ha scritto:

It is, but within some limitations. I'm not a dev and have no experience with Wii U emulation myself, but my understanding is that the open-source Decaf emulator is more often used for homebrew debugging, while the closed-source Cemu is not usually great for homebrew software. The homebrew libraries on Wii use certain instructions that commercial games don't, and rather than aiming to implement a hardware-complete recreation of the Wii U, the Cemu author just implements features as-needed, which leaves its homebrew support less functional than its support for commercial games.

I personally have no idea how well RetroArch runs on either emulator, assuming it runs at all.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/libretro/FBNeo/issues/459#issuecomment-680785323, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAMY7LLBRW7ZW752VSJMZNLSCTMVZANCNFSM4PZGHGLQ .

vaguerant commented 4 years ago

Is that the latest version of Cemu? It was just updated in the last week or two to support homebrew compiled with the homebrew WUT library, in order to support aboood40091/sm64-port. Before that update, Cemu couldn't run any homebrew compiled with WUT at all. I have no idea what libraries RetroArch uses on Wii U.

crystalct commented 4 years ago

@vaguerant could you read this: https://github.com/libretro/mame2003-plus-libretro/issues/883#issuecomment-691980770