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

[vaguerant]

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]

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

[barbudreadmon]

NB : with finalburnneo@3b20508 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]

After mystwarr, i will take a look at it

[crystalct]

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 <[email protected]> ha scritto:

…

NB : with ***@***.*** <finalburnneo@3b20508> 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 <#459 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAMY7LPOLNRQLKDJCXI7N7DR73DMRANCNFSM4PZGHGLQ> .

[barbudreadmon]

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]

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:

• near-native GameCube support
• native Wii support
• dual-screen TV & GamePad Nintendo DS emulation

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]

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]

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

• the following games have the coin issue : landmakr, elvactr, gekiridn, dariusgx, dariusg (NB : going into service menu shows that it detects the coin action, the coin sound is even playing, but the coin counter still remains 0, i also tried logging every variable that seemed related to coin but didn't find any difference with x86)
• the following games have gfx issues (scrambled sprites ?) : bubblem, bublbob2, lightbr
• any other game seems to work properly

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

[dinkc64]

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,

• dink

[barbudreadmon]

1 erratum and 1 precision about my previous statement :

• the games that seemed to work might actually still have glitches, ex. in kaiserkn the wheel on select char is not showing :
  
• bubblem doesn't only have gfx glitches, while you get glitches like this on intro
  
  soon after you end up with an error screen and the game will reboot
  

[barbudreadmon]

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 finalburnneo@89fc28a another driver using kinda similar hardware has no obvious issue.

[dinkc64]

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

[crystalct]

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]

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

[barbudreadmon]

@dinkc64 superchs seems ok too with finalburnneo@ee286cc

[barbudreadmon]

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

[crystalct]

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]

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

[dinkc64]

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]

It Is just a plan B :) Il mar 25 ago 2020, 02:55 dinkc64 <[email protected]> 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 <#459 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAMY7LL4KIGE7VQ3PYBF4F3SCMDYTANCNFSM4PZGHGLQ> .

[barbudreadmon]

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]

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]

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 :

FBNeo/src/cpu/m68000_intf.cpp

Lines 460 to 493 in ecce1ad

	inline static void WriteLong(UINT32 a, UINT32 d)
	{
	UINT8* pr;
	a &= nSekAddressMaskActive;
	// bprintf(PRINT_NORMAL, _T("write32 0x%08X\n"), a);
	pr = FIND_W(a);
	if ((uintptr_t)pr >= SEK_MAXHANDLER)
	{
	if (a & 1)
	{
	// bprintf(PRINT_NORMAL, _T("write32 0x%08X 0x%8.8x\n"), a,d);
	d = BURN_ENDIAN_SWAP_INT32(d);
	WriteByte((a + 0), d / 0x1000000);
	WriteByte((a + 1), d / 0x10000);
	WriteByte((a + 2), d / 0x100);
	WriteByte((a + 3), d);
	return;
	}
	else
	{
	d = (d >> 16) | (d << 16);
	*((UINT32*)(pr + (a & SEK_PAGEM))) = BURN_ENDIAN_SWAP_INT32(d);
	return;
	}
	}
	pSekExt->WriteLong[(uintptr_t)pr](a, d);
	}

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

[crystalct]

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

[barbudreadmon]

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]

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 :

• either the way we are endianizing non-aligned in ReadLong is wrong
• or the operations happening between the 2 calls are messing things

[barbudreadmon]

It'll require more tests, but it seems removing the endian macro at

FBNeo/src/cpu/m68000_intf.cpp

Line 429 in ecce1ad

return BURN_ENDIAN_SWAP_INT32(r);

fix this issue
If that's the right fix, then i guess the same should probably be done in ReadWord

[barbudreadmon]

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]

Do you have understuud why certain F3 games dont have that isssue? Il mar 25 ago 2020, 15:26 barbudreadmon <[email protected]> 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 <#459 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAMY7LOVQKAGYDWOK4S2PSTSCO3YNANCNFSM4PZGHGLQ> .

[dinkc64]

dink fixes all

[barbudreadmon]

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 finalburnneo@ce3581e, basically there was a bunch of endian fixes in the m68k cpu core that needed to be removed.

[crystalct]

Dink final touch ^_^

[barbudreadmon]

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]

And we will fix them ;)

[crystalct]

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

[dinkc64]

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]

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]

@crystalct do you have better perf on ps3 ?

[crystalct]

On emulator (compiled mode) a lightning...on real PS3 i Will try it Il mer 26 ago 2020, 11:08 barbudreadmon <[email protected]> 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 <#459 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAMY7LK2KK6EUDVWKFRFGN3SCTGHLANCNFSM4PZGHGLQ> .

[crystalct]

@vaguerant Is It possible run homebrew software on Wii U emulator? Il mer 26 ago 2020, 10:32 vaguerant <[email protected]> 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 <#459 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAMY7LL72KGXKS7VIIJRLTTSCTCC7ANCNFSM4PZGHGLQ> .

[vaguerant]

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]

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 <[email protected]> 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 <#459 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAMY7LLBRW7ZW752VSJMZNLSCTMVZANCNFSM4PZGHGLQ> .

[vaguerant]

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]

@vaguerant could you read this: libretro/mame2003-plus-libretro#883 (comment)