Goodbye fbalpha, welcome fbneo

barbudreadmon

And mesen which is supposed to be the best nes emulator as far as accuracy is concerned is using neither 4:3 nor 8:7, and i don't even understand where this one is coming from.
It definitely looks like a rabbit hole to me, so we'll stay with the current default aspect ratio. Anyway the user can change it to match his taste, either through retroarch settings or through core options (in dipswitches)

sleve_mcdichael

In Space Invaders (invaders.zip) there's a dipswitch setting (enabled by default?) that simulates the colored overlay of the original cabs, turning the bottom portion green where the player's ship and shields are.

Battle Zone (bzone.zip) used a similar colored overlay over a monochrome display, with the top 20% tinted red and the remainder tinted green. In lr-mame2003 it's colored this way already by default but in lr-fbneo it's just displayed in monochrome (white) and I didn't see any way to enable this color overlay in bzone as there is in invaders; is something there, that I've missed or, if not, is this a place I could make such a request?

barbudreadmon

@sleve_mcdichael sure, i'll try to do that soon

barbudreadmon

@sleve_mcdichael the method i used to implement colors in space invaders is not gonna work here, we probably need a real color overlay system in our framework for this one, implementing this will probably take some time and i'm first gonna need advice from our main devs.

barbudreadmon

@sleve_mcdichael bzone has colors now

sleve_mcdichael

@barbudreadmon cheers, thanks!

WeirdH

@barbudreadmon I just found something that might be a bug. Don't know if this is the right place to report, as MAME2003-Plus seems to show the same behavior:

In mpang, when I use the service menu to set coin options to '2 chuters multi', the game plays fine at first, but upon a game over, it shows a glitched (incomplete) screen and softlocks.

The MAME emulation appears to be marked as 'status good' on arcadeitalia, but I don't know if that status takes into account any other settings than default.

barbudreadmon

@WeirdH Did you check if MAME (current) has the same issue ? Tbh, it's a bit weird that mame2003 has the same issue, since mame's and finalburn's cp2 emulation code aren't based on each other, it might be an issue happening on real cabinet (?).

Ashpool

@barbudreadmon Do you have any idea why it is that clrmamepro is building a (neogeo) romset with zero roms reported as missing whence building a non-merged set, but is, when using the option of separate bios files, removing a few roms from the set and then reports them as missing?

miss list for the non-merged build:

 You are missing 0 of 524 known FinalBurn Neo v1.0.0.03 Neogeo Games sets (+ BIOS sets)

and then for the non-merged + separate bios build/scann

 You are missing 14 of 524 known FinalBurn Neo v1.0.0.03 Neogeo Games sets (+ BIOS sets)

19yy
cabalng
cnbe2018
hypernoid
kof97ip
looptris
mslug3x
mslug4lw
mslug5f
mslug5w
ngmontst
santaball
teot
xenocrisis

barbudreadmon

@Ashpool It looks like a clrmamepro bug to me, as far as i can tell there is nothing wrong with our dat file.

The only thing that comes to mind when looking at this list of games is that none of them would be available if you are rebuilding from a MAME set (homebrews and hacks). Aside from that, there is nothing making those games "stand-offish", there are dozens of romsets with similar circumstances that aren't listed here.

Ashpool

@barbudreadmon said in Goodbye fbalpha, welcome fbneo:

It looks like a clrmamepro bug to me

feared so :| Nevertheless, thank you for looking into it!

Ashpool

Oh Well, after some research time, without any success, I'm again asking here and you @barbudreadmon again 1st (because I really don't know in what Forum to ask and where I may find some RTFM-Stuff in regards of context):

Some friend of mine introduces me to "kovplus" from a series, and now I am puzzled/wondering why on current mame (well, not really why), it is listed as preliminary, but on FBNeo as driver = "good". On both sources it is, that CopyProtection/ARM7 Dump is missing -> Mame SRC: "ROM_LOAD( "kov_igs027a.bin", 0x000000, 0x04000, NO_DUMP )", FBNeo SRC: { "kov_igs027a.bin", 0x0004000, 0x00000000, 7 | BRF_PRG | BRF_ESS | BRF_NODUMP }, // 9 Internal ARM7 Rom.

As I am aware that the question: "what exactly does it mean" (for this rom), can only be answered for "this rom" - but can you please hint me to some rtfm stuff or such where I may learn about what the consequences of playing roms with missing dumps/esp. protection based ones may be? Or where the differences between FBN and Mame in regards of the IGS/PGM driver may be (mame is flaging sound as imperfect for pgm; FBN doesn't differentiate beside "driver")? And then there are a lot of PGM ROMs which are flaged as preliminary/imperfect besides the inherited "imperfect sound" from "PGM" (in mame). And as many of those titles are somewhat playable in FBN/mame, what is it the "gamer" may have to be aware of; in regards of playing an imperfect/preliminary emulated title? (Edit: As my friends (or at least some of them) seem to think that they are playing the real McCoy, I want to know of what potential hazards/flaws I may hint 'em to!)

barbudreadmon

@Ashpool in FBNeo, it does mean the game is supposed to be fully playable from beginning to end.

I'm not entirely sure about the exact meaning in MAME so you might want to ask MAMEdevs, maybe @arcadez2003 or @mahoneyt944 would also be able to answer that question.

As for the missing arm7 dump, it's used to get through the pgm protection, but FBNeo is handling this by using simulation code so it's not a real problem (MAME too but maybe their simulation code isn't up-to-date with ours ?). It is believed that we have all the pgm protections properly simulated but feel free to write a report if you encounter a game crashing.

FBNeo's pgm driver is not based on MAME's, it's the result of FBdevs owning the machine and doing their own research (Jan_Klaassen and IQ_182). It's one of those systems where FBNeo has the lead over MAME.
I know some pgm improvements have been backported from FBNeo to MAME in the past but i think they aren't quite up-to-date with all "recentish" improvements. Due to our incompatible license, they need to ask permission for backporting those improvements from our pgm driver (iirc they never got permission for the ics2115 sound board emulation from Jan_Klaassen, hence why their sound emulation might still be behind), i don't think IQ_182 would refuse but they still need to ask.

G30FF

@barbudreadmon Is it possible to (somewhat) easily port MAME cheats to FBNeo cheat format? I recently found cheats to translate SegaSonic the Hedgehog to english (https://tcrf.net/SegaSonic_the_Hedgehog#Unused_Localization_Version), but they only provide MAME cheats (replace Eggman with Robotnik, english with Robotnik text, and english with Eggman text as three different cheats). I've been trying to do some research on the subject, but haven't found any good resources for this use case, and I don't think anyone else has attempted this. I've tried looking at the MAME cheat format and FBNeo cheat format, and I'm not entirely sure how to convert one to the other, so even a starting point would be helpful if possible. Thank you!

Sorry for necroing this topic, but it seemed the right place to ask this question.

barbudreadmon

@G30FF Yes, it should be fairly easy to port that cheat to our ini format, our init cheat template looks like this :

cheat "name of the cheat"
default 0
0 "Disabled"
1 "Enabled", 0, address1, value1, 0, address2, value2, 0, address3, value3, 0, address4, value4, 0, ...

While MAME's xml cheat template looks like this

...
<action>target_writing_method@address1=value1</action>
<action>target_writing_method@address2=value2</action>
<action>target_writing_method@address3=value3</action>
<action>target_writing_method@address4=value4</action>
...

There is a trick here though because it writes words and not bytes, however our ini engine can only write bytes, but this is nothing you can't handle. Look at

<action>mainpcb:maincpu.mw@95772=9f90</action>

It says it writes the word 0x9f90 at address 0x95772, which also means it writes the byte 0x9f at address 0x95772 and the byte 0x90 at the next address 0x95773, i prefixed all numbers with 0x because they are hexadecimals.

So in FBNeo it will start like this :

...
1 "Enabled", 0, 0x95772, 0x9f, 0, 0x95773, 0x90, 0, ...

The cheat.dat format has a steeper learning curve but is more featured (it can write words among other things), it's probably easier to just use the ini format here.

G30FF

@barbudreadmon This is great info, thank you for the writeup! Using this info I attempted to convert the cheat to the FBNeo .ini format, but I think there may be differences in the memory addresses used by the MAME driver for this game and FBNeo's. I am able to make the old graphics disappear, but the replacements that are supposed to be in the game's code do not appear (sometimes I can make garbled graphics appear in their place, but that's it). It looks like converting the cheats is not as straight forward as I hoped, and I need to do more learning before I take another crack at it. Thank you for your help!

barbudreadmon

@G30FF oops, i did some search and it turns out the nec v60 cpu used by this game needs swapping when writing multibyte cheats, so actually for my previous example it will write 0x90 at 0x95772 and 0x9fat 0x95773.

Also, previously i didn't notice it was using different writing method, but :

mainpcb:maincpu.mb writes a byte
mainpcb:maincpu.mw writes a word
mainpcb:maincpu.md writes a double word

double word is supposed to be 8 characters-long so when you see

<action>mainpcb:maincpu.md@95c18=17235e</action>

It means it writes the double word 0x0017235e at 0x95c18, which would translate to :

0x5e at 0x95c18
0x23 at 0x95c19
0x17 at 0x95c1a (remember we are in hexadecimal when incrementing addresses)
0x00 at 0x95c1b

G30FF

@barbudreadmon That did the trick! I was able to swap out the tutorial text for the english text by converting the cheat using the reversed words like you said. I tested it out with the text on the Tutorial screen, and it's working just fine. I'm working on converting the rest of the cheats as we speak. Thanks again! The only downside is I had to comment out the game's cheats in cheat.dat for FBNeo to read the sonic.ini cheat file, but that's not a huge deal.

barbudreadmon

Some good news for Sega System 32 fans (Golden Axe 2, Jurassic Park, ...), dink found some nice performance optimizations for this driver, so FBNeo should now be a pretty solid choice for those games on pi4.