Thanks for the feedback.
1. You're half right. It's Retroarch remapping the controls. The mapping for FBA is right for 6 button games but is remapped for less than that... I haven't figured out how to disable that on Pi4 yet, may have to compare settings with the Pi3 version.
Test/service arn't properly supported as unique inputs by FBA on RA, I think holding coin input should open the test menu for a game though. I may be wrong on this and just missing a config item somewhere though.
I haven't found many games best in FBA on Pi4 yet. CPS3 stuff, Strikers 1945 2 & 3, and Tetris Grand Master 2 (+ now Gaiapolis). There are a few games I have in AdvMAME that may be better off in FBA though...
What CAVE games do you find run better in FBA? I would love to check them out. I have found 172 is the best for most CAVE stuff so far, perfectly possible we're testing diff games too...
Gaiapolis does seem best in FBA, it's also fullspeed in AdvMAME but not as smooth. It may be fullspeed in 172 with overclocking but I didn't check.
2. This ones a known bug, there's a way to open the test/service menu but it's unreliable. I think it's holding start at the Naomi logo... I could be wrong. The test menu doesn't actually seem useful yet anyway. Hopefully something that will improve with emulator updates.
3. This is just emulator mapping and can be fixed in the MAME tab menu, I actually fixed it on another SD card for the 4.3 update but apparantly forgot to copy that file over... my bad.
4. I'll look into it.
5. Different Attract-Mode themes may display better on a vert monitor in 240p (depends on the theme). The default theme is a horizontal theme made for high res... once it's rotated and shrunk to 240p there's not enough screen for it to display really nicely, unfortunately. 480i is still 15k but has more screen real estate so it looks better, still not ideal in vertical though.
My main test monitor works really well with interlacing, I realise this isn't the case for all arcade monitors... it varies wildly from screen to screen. I will try to find some good 240p themes in the future.
6. Yeah that's an old list made for Pi3. New list coming soon when I've tested enough stuff to make it worthwhile. My current advice is use 172 for most games, if they don't work well there try other emulators.
7. I can't agree with this. It's true that 230 is not as fast as 172 in most cases but I wouldn't say it sucks. It runs a lot of stuff fullspeed, particularly if/when the Pi4 is overclocked. I have only found 1 or 2 games that are better in 230 than in 172 but they do exist.
I too have found some odd behaviour for certain roms eg. 1942 in 172 segfaults, but it runs nicely in 203. No idea why this is, most Capcom stuff is great in 172.
U1. Sorry, I forgot to look at the system volume bug. It must be something simple or stupid as it works on the command line...
u2. I'll try to get to WiFi for the next release... I don't use it personally so it's an easy one for me to overlook.
I very much appreciate the feedback and offer of testing. Expect me to contact you about it.
------------------
also @ffollim not to worry. I really do appreciate the feedback, good and bad.
ARpiCADE 4.3 (for RPi4)
Moderator: dee2eR
-
petkorazzi
- Community Member
- Posts: 10
- Joined: Sat Feb 20, 2021 12:08 am
Re: ARpiCADE 4.3 (for RPi4)
You got me thinking about the CAVE stuff (it had been a long time since I did my initial testing and at the time I was even more green to this stuff than I am now), so I decided to do a more proper test across a selection of CAVE shooters. I also took the time to rebuild romsets for .230, .172, and .106 (AdvMAME) to make sure it wasn't some stupidity on my end. The games I'd previously played in FBA were all in the DoDonPachi series, but this time I decided to take a wider selection of CAVE stuff across a broader time frame (listed in chronological order of release):
DoDonPachi (the "base" version, not the OG Japanese "full extent of the jam" rom
ESP Ra.De
DoDonPachi DaiOuJou Black Label
Espgaluda
Mushihimesama
Espgaluda II
Pink Sweets
(Note that I do not have FBA ROMs of the last three, nor do I know if they exist, nor did I legitimately expect CH-3 games to play on a Pi)
Everything up through Espgaluda seems to play just fine on .172; you were totally right there and I don't know why in the past I'd determined that FBA was the way to go with the DDP games. Mushihimesama is close to being playable on .172 and marginally closer on AdvMAME, but there's still a lot of slowdowns whenever a lot of enemies end up on-screen. Espgaluda II is pretty unplayable on both but marginally better on AdvMAME. Pink Sweets oddly generates a Coin Error message when I try to play it on .172 but accepts coin input fine on AdvMAME, however it's pretty unplayable on both (again marginally better on AdvMAME than .172). So hopefully that at least puts the CAVE debate to rest when it comes to FBA for now (unless CH-3 FBA ROMs are a thing).
You were also right about Gaiapolis and AdvMAME. I also found that while the video isn't as smooth on AdvMAME, the actual input latency seems better than FBA. I think I'll keep this one in AdvMAME for now.
Ok, enough game-based shenanigans (that should probably be a separate thread somewhere or something, we can work that out later. Or maybe a Discord?). Back to the 4.3 stuff:
1. Naomi Test Menu Issues
You were right, holding Start at the Naomi logo does open the Test Menu. However, there's no way to actually select an option - the Service Button is what normally scrolls through the options and the Test button selects, but as it sits once you're in the Test Menu the P1 Start button acts as the Test button and no other inputs are recognized - meaning you can only select Exit. In 4.2 I remember kludging my way through keybinds in RetroArch and somehow got the Service and Test buttons bound to keyboard keys as a temporary use case but I forget exactly how I did this and it was pretty awful (something about the RA L3 button being natively bound to one of these if you enable a certain RA option; I can't remember). Additionally, the Test Menu settings weren't saved across play sessions so you'd have to do this every time you opened a Naomi ROM. As things like Free Play and some game settings can be found here, it's nontrivial.
2. MAME .172 Service/Test Buttons
Plugging in a keyboard F2 acts as the Test Button and the 9 key acts as the Service Button. I can remap the Service Button to my cab's button no problem using the MAME menu, but the Test Button does not cooperate (and oddly enough F2 is mapped to two inputs, "Power Off" and "Service"). Even more strangely, pulling up an Input Test screen in a game and pushing F2 doesn't show a Test Button press? Something is very weird here and I'm struggling to find out what's going on. Additionally, changing these mappings doesn't seem to save between sessions - however settings changed in the Test Menu do save between sessions. So it's not the end of the world or anything, but it'd be nice to sort out (I don't have a dedicated keyboard for the ARpiCADE and messing about with it is somewhat annoying).
I'm going to temporarily ignore the FBA issues and focus more on testing games to work in any emulator outside of FBA. I think we all pretty much agree that FBA is a system of last resort anyway, so spending a bunch of development time sorting it out is probably not the best use of time.
Thank you for addressing the other issues as well. Most of them are trivial for my use case (I don't plan on spending much time in attract-mode or adjusting system volume), but the ability to add/remove/change ROMs and/or config file stuff over WiFi would be a pretty huge positive for me.
I'd also like to take a moment to thank you for all the time and improvements you put into this, and to echo ffollim in that I also apologize if I sound too negative. ARpiCADE is great for my use case and I love it. I just want to do anything I can to help it improve.
DoDonPachi (the "base" version, not the OG Japanese "full extent of the jam" rom
ESP Ra.De
DoDonPachi DaiOuJou Black Label
Espgaluda
Mushihimesama
Espgaluda II
Pink Sweets
(Note that I do not have FBA ROMs of the last three, nor do I know if they exist, nor did I legitimately expect CH-3 games to play on a Pi)
Everything up through Espgaluda seems to play just fine on .172; you were totally right there and I don't know why in the past I'd determined that FBA was the way to go with the DDP games. Mushihimesama is close to being playable on .172 and marginally closer on AdvMAME, but there's still a lot of slowdowns whenever a lot of enemies end up on-screen. Espgaluda II is pretty unplayable on both but marginally better on AdvMAME. Pink Sweets oddly generates a Coin Error message when I try to play it on .172 but accepts coin input fine on AdvMAME, however it's pretty unplayable on both (again marginally better on AdvMAME than .172). So hopefully that at least puts the CAVE debate to rest when it comes to FBA for now (unless CH-3 FBA ROMs are a thing).
You were also right about Gaiapolis and AdvMAME. I also found that while the video isn't as smooth on AdvMAME, the actual input latency seems better than FBA. I think I'll keep this one in AdvMAME for now.
Ok, enough game-based shenanigans (that should probably be a separate thread somewhere or something, we can work that out later. Or maybe a Discord?). Back to the 4.3 stuff:
1. Naomi Test Menu Issues
You were right, holding Start at the Naomi logo does open the Test Menu. However, there's no way to actually select an option - the Service Button is what normally scrolls through the options and the Test button selects, but as it sits once you're in the Test Menu the P1 Start button acts as the Test button and no other inputs are recognized - meaning you can only select Exit. In 4.2 I remember kludging my way through keybinds in RetroArch and somehow got the Service and Test buttons bound to keyboard keys as a temporary use case but I forget exactly how I did this and it was pretty awful (something about the RA L3 button being natively bound to one of these if you enable a certain RA option; I can't remember). Additionally, the Test Menu settings weren't saved across play sessions so you'd have to do this every time you opened a Naomi ROM. As things like Free Play and some game settings can be found here, it's nontrivial.
2. MAME .172 Service/Test Buttons
Plugging in a keyboard F2 acts as the Test Button and the 9 key acts as the Service Button. I can remap the Service Button to my cab's button no problem using the MAME menu, but the Test Button does not cooperate (and oddly enough F2 is mapped to two inputs, "Power Off" and "Service"). Even more strangely, pulling up an Input Test screen in a game and pushing F2 doesn't show a Test Button press? Something is very weird here and I'm struggling to find out what's going on. Additionally, changing these mappings doesn't seem to save between sessions - however settings changed in the Test Menu do save between sessions. So it's not the end of the world or anything, but it'd be nice to sort out (I don't have a dedicated keyboard for the ARpiCADE and messing about with it is somewhat annoying).
I'm going to temporarily ignore the FBA issues and focus more on testing games to work in any emulator outside of FBA. I think we all pretty much agree that FBA is a system of last resort anyway, so spending a bunch of development time sorting it out is probably not the best use of time.
Thank you for addressing the other issues as well. Most of them are trivial for my use case (I don't plan on spending much time in attract-mode or adjusting system volume), but the ability to add/remove/change ROMs and/or config file stuff over WiFi would be a pretty huge positive for me.
I'd also like to take a moment to thank you for all the time and improvements you put into this, and to echo ffollim in that I also apologize if I sound too negative. ARpiCADE is great for my use case and I love it. I just want to do anything I can to help it improve.
Re: ARpiCADE 4.3 (for RPi4)
Interesting to hear AdvMAME supports the newer Cave stuff, I had no idea. As some of them are very playable in 172 with the Pi overclocked I'm going to have to check them out in AdvMAME. One game (I forget which offhand) isn't in 172 but is in 174 so it'l be especially interesting if it has it in AdvMAME.
-
petkorazzi
- Community Member
- Posts: 10
- Joined: Sat Feb 20, 2021 12:08 am
Re: ARpiCADE 4.3 (for RPi4)
It turns out it doesn't, and I'm an idiot. I'd mixed up some folders and long story short I'd been running .172 the entire time, and it was my own perspective bias that showed the slight differences. So ignore all that CAVE AdvMAME stuff, lol. I'm going to have to create a more thorough testing methodology before we start working on a compatibility list to make sure I don't repeat these kinds of mistakes.
I've never tried OCing the Pi and I wasn't sure it'd make that much difference. Do you think it can legitimately take a game from unplayable to playable on the Pi 4? This also runs into one downside of the RaspberryJAMMA adapter - there's not an easy way to power a cooling fan for the Pi since the entire GPIO is used for the RJ.
Re: ARpiCADE 4.3 (for RPi4)
It may not have been a bias, I think there's a random (or not yet understood) element to the performance too. Prob when the Pi is doing something in the background affecting the game. I'd sware I have had some times when games ran better than other attempts with the same game.
You may be surprised with the OC results. It's not a cure all but Pi4 OCs very well, you get 30% higher clock speed or similar at a high enough overclock. With the right game it can absolutly make the difference between not quite good enough and damn near perfect.
Using Deathsmiles in MAME172 as an example with stock clocks it usually hovers between 70% and 100% speed in normal gameplay (and it depends heavily on whats on screen so grain of salt), I think I saw a low of 53% during a loading screen.
With the big overclock settings (that are commented out) in config.txt the speed still fluctuates a little but is at 100% a lot more often and fluctuations are between 90% and 100%. Some slower moments in loading screens still happen but the game is way more playable. Results were on 4gig Pi4 with large heatsink/small fan combo. I picked Deathsmiles because I knew it was close but not perfect overclocked, it's on the cusp...
Not OC'd if you use the lock on attack at the first boss you get massive slowdown, with OC it's perfectly usable. With OC it goes from not nearly good enough to still not perfect but very playable, from I wouldn't put that game on my cab to I want the game in my cab and I understand the occasional hiccup will happen.
Generally from what I've seen so far if a game is running at 80-90% without OC it should be fullspeed (or very close) with OC.
Extra test:
Out of curiosity I've just tried a worst case senario style test too. Pi4 1gig, no heatsink, in a small case (limiting airflow), case is upsidedown so the CPU/GPU stack is underneath and the heat from it goes back into the Pi PCB. Oddly enough it wasn't quite as good as the 4gig with tower heatsink and fan (I got some slowdown at the first boss using the lock on attack) but still was much better compared to non OC'd. It may be a heatsink isn't as necesary for overclocking as previously thought. I definately don't think a tower heatsink + fan is necesary, a small passive heatsink is probably close to or just as good (was probably a very different story with early firmware on the Pi though). Honestly not sure the fan adds anything. The worst case test is still running and I haven't seen the thermal indicator icon pop up yet - Deathsmiles attract-Mode is still running between 94% and 100% speed, more often than not it's at 100% (the attract-mode seems liek it may be a little easier on the Pi than actual gameplay). Short of insulating the case to keep the heat in I think it's a pretty decent worse case senario test - most in cab use would have more airflow even without a fan.
EDIT: Deathsmiles seems to be one of the easier late Cave games to run. Some others are not as good.
You may be surprised with the OC results. It's not a cure all but Pi4 OCs very well, you get 30% higher clock speed or similar at a high enough overclock. With the right game it can absolutly make the difference between not quite good enough and damn near perfect.
Using Deathsmiles in MAME172 as an example with stock clocks it usually hovers between 70% and 100% speed in normal gameplay (and it depends heavily on whats on screen so grain of salt), I think I saw a low of 53% during a loading screen.
With the big overclock settings (that are commented out) in config.txt the speed still fluctuates a little but is at 100% a lot more often and fluctuations are between 90% and 100%. Some slower moments in loading screens still happen but the game is way more playable. Results were on 4gig Pi4 with large heatsink/small fan combo. I picked Deathsmiles because I knew it was close but not perfect overclocked, it's on the cusp...
Not OC'd if you use the lock on attack at the first boss you get massive slowdown, with OC it's perfectly usable. With OC it goes from not nearly good enough to still not perfect but very playable, from I wouldn't put that game on my cab to I want the game in my cab and I understand the occasional hiccup will happen.
Generally from what I've seen so far if a game is running at 80-90% without OC it should be fullspeed (or very close) with OC.
Extra test:
Out of curiosity I've just tried a worst case senario style test too. Pi4 1gig, no heatsink, in a small case (limiting airflow), case is upsidedown so the CPU/GPU stack is underneath and the heat from it goes back into the Pi PCB. Oddly enough it wasn't quite as good as the 4gig with tower heatsink and fan (I got some slowdown at the first boss using the lock on attack) but still was much better compared to non OC'd. It may be a heatsink isn't as necesary for overclocking as previously thought. I definately don't think a tower heatsink + fan is necesary, a small passive heatsink is probably close to or just as good (was probably a very different story with early firmware on the Pi though). Honestly not sure the fan adds anything. The worst case test is still running and I haven't seen the thermal indicator icon pop up yet - Deathsmiles attract-Mode is still running between 94% and 100% speed, more often than not it's at 100% (the attract-mode seems liek it may be a little easier on the Pi than actual gameplay). Short of insulating the case to keep the heat in I think it's a pretty decent worse case senario test - most in cab use would have more airflow even without a fan.
EDIT: Deathsmiles seems to be one of the easier late Cave games to run. Some others are not as good.
-
petkorazzi
- Community Member
- Posts: 10
- Joined: Sat Feb 20, 2021 12:08 am
Re: ARpiCADE 4.3 (for RPi4)
Emboldened by your successes I decided to experiment a bit myself. I've got passive heatsinks on my Pi 4 4GB, and uncommented out the "big" overclocking settings (interestingly, the "normal" OC settings don't seem to have a line for GPU OC-ing...is the CPU bottlenecking, or the GPU?). I then threw on two .172 ROMs I knew wouldn't be playable on the stock settings - Mushihimesama (which was close to playable but not quite) and Muchi Muchi Pork! (totally unplayable). I played each game for about 10 minutes and didn't see any overheating indicators.
Mushihimesama definitely went from unplayable to playable with the OC settings. Still some slowdowns when things get hectic, but not so ridiculous it ruins the game. Granted, I only played through a level and a half or so.
Muchi Muchi Pork! had a snowball's chance in Hell of becoming playable and I knew that going in, but I was surprised at how much better it got. There were parts of the game that were completely playable. I'd say it was 70-75% of the way to playable status.
I then wanted to see if it made any difference with Naomi games, and fired up Under Defeat (I've been working on testing all the vertical-orientation Naomi games with ARpiCADE 4.3). Previously it was playable but using a bomb would cause a significant slowdown; with the big OC settings that slowdown is 90% gone and the game in general feels like it's running much smoother. Unfortunately OCing had no effect on the one Naomi game I've found that's totally unplayable - Triggerheart Excelia (though I think this is a Flycast bug and not a performance issue; it's been documented for 3 years or so).
In general I agree that OCing the Pi does make a significant difference, and I'm glad you posting your experienced convinced me to give it a try. I'd still prefer an active cooling solution for peace of mind, but as I've yet to run into any overheating indications I'm probably just being paranoid. I'll try to spend some time this evening on longer-duration playtesting to be sure. If things end up working out OK, it may be worth tracking OC playability in the 4.x compatibility list (I've been playing around with some ideas in keeping track of my own testing but I'll freely admit I'm not good at this kind of organization).
**EDIT** By the way, how are you able to view the game speed while testing? Is there an overlay ability I don't know about?
Mushihimesama definitely went from unplayable to playable with the OC settings. Still some slowdowns when things get hectic, but not so ridiculous it ruins the game. Granted, I only played through a level and a half or so.
Muchi Muchi Pork! had a snowball's chance in Hell of becoming playable and I knew that going in, but I was surprised at how much better it got. There were parts of the game that were completely playable. I'd say it was 70-75% of the way to playable status.
I then wanted to see if it made any difference with Naomi games, and fired up Under Defeat (I've been working on testing all the vertical-orientation Naomi games with ARpiCADE 4.3). Previously it was playable but using a bomb would cause a significant slowdown; with the big OC settings that slowdown is 90% gone and the game in general feels like it's running much smoother. Unfortunately OCing had no effect on the one Naomi game I've found that's totally unplayable - Triggerheart Excelia (though I think this is a Flycast bug and not a performance issue; it's been documented for 3 years or so).
In general I agree that OCing the Pi does make a significant difference, and I'm glad you posting your experienced convinced me to give it a try. I'd still prefer an active cooling solution for peace of mind, but as I've yet to run into any overheating indications I'm probably just being paranoid. I'll try to spend some time this evening on longer-duration playtesting to be sure. If things end up working out OK, it may be worth tracking OC playability in the 4.x compatibility list (I've been playing around with some ideas in keeping track of my own testing but I'll freely admit I'm not good at this kind of organization).
**EDIT** By the way, how are you able to view the game speed while testing? Is there an overlay ability I don't know about?
-
cool_factor
- Legendary Contributor
- Posts: 409
- Joined: Tue Sep 26, 2017 10:55 am
- Location: Fort Worth TX
Re: ARpiCADE 4.3 (for RPi4)
F11 if I remember what Dee2er posted earlier.
-
petkorazzi
- Community Member
- Posts: 10
- Joined: Sat Feb 20, 2021 12:08 am
Re: ARpiCADE 4.3 (for RPi4)
Yep, that did it. Thank you.
Did a bit of a longer-duration test of running the Pi 4 in "big overclock" mode. Played about 45 minutes of Under Defeat and then another 30 minutes of Mushihimesama back-to-back and never got the overheating icon. I did touch my CPU passive heat sink and it was quite hot so I'm not sure I'd want to use this mode in extended play circumstances without a fan, but it clearly works. I also tried playing Mushihimesama with the sound turned off and I found I noticed the occasional slowdowns a lot less this way - I think it's mainly the skipping audio that makes them apparent. Funny how that works.
Karous on Naomi also goes from "playable with occasional slowdowns" to "near-perfect 100%" with OC, so it's definitely helping with not-MAME stuff too.
Reading back through the thread made me realize I have no idea what firmware my Pi 4 is running though, so I might want to look into that.
Re: ARpiCADE 4.3 (for RPi4)
I've added an update to the first post with a quick update patch.
Should fix MAME 172 menus (mostly) and improve Naomi and CPS3 (FBA) 240p performance.
Doesn't fix everything that has been addressed in the thread so far but the improvement to Naomi, Atomiswave and CPS3 makes it worth it.
Should fix MAME 172 menus (mostly) and improve Naomi and CPS3 (FBA) 240p performance.
Doesn't fix everything that has been addressed in the thread so far but the improvement to Naomi, Atomiswave and CPS3 makes it worth it.
Re: ARpiCADE 4.3 (for RPi4)
Guys i purchased another Arpicade Jamma board (5th) and am going to try and upgrade to a PI 4 on this latest purchase. I have a few other Arpicade systems running 3.x versions of Arpicade and i spent a fair amount of time dialing in games with game specific settings for spinner configs, button configs, etc. I would rather not start from scratch and redo all of these game specific settings across the different Mame versions i used for various games. If i keep my ROMs in the same emulator folders, are there not game specific setting files i can just copy to avoid having to manually redo a lot of these? I was thinking these would be ROMName.cfg files or something along those lines. Can anyone shed any light on the paths for such game specific setting files to try and save some time with my upgrade?
