Topic: Need some help with my libretro port

[barbudreadmon]

I found the issue ! But i'm not sure how i'm supposed to deal with it , let me explain :
i kept the following replacement for FETCH macro in necpriv.h :

Code: [Select]

#define FETCH() ({ UINT8 retval; retval = cpu_readop_arg((Sreg(PS)<<4) + sChipsPtr->ip); bprintf (PRINT_NORMAL, _T("test %d, %d, %d\n"), Sreg(PS)<<4, sChipsPtr->ip, retval); sChipsPtr->ip++; retval; })I modded the following opcode in necinstr.c

Code: [Select]

OP( 0xe2, i_loop   ) { INT8 disp = (INT8)FETCH(); Wreg(CW)--; if (Wreg(CW)) { bprintf (PRINT_NORMAL, _T("test2 %d, %d\n"), nec_state->ip, disp); nec_state->ip = (WORD)(nec_state->ip+disp); bprintf (PRINT_NORMAL, _T("test3 %d\n"), nec_state->ip); /*CHANGE_PC;*/ CLKS(13,13,6); } else CLKS(5,5,3); }

Here come my outputs :
on x86 :

Code: [Select]

RetroArch [libretro DEBUG] :: test 1048560, 1, 0
RetroArch [libretro DEBUG] :: test 1048560, 2, 8
RetroArch [libretro DEBUG] :: test 1048560, 3, 0
RetroArch [libretro DEBUG] :: test 1048560, 4, 63
RetroArch [libretro DEBUG] :: test 258048, 2050, 255
RetroArch [libretro DEBUG] :: test 258048, 2051, 255
RetroArch [libretro DEBUG] :: test 258048, 2053, 254
RetroArch [libretro DEBUG] :: test2 2054, -2
RetroArch [libretro DEBUG] :: test3 2052
RetroArch [libretro DEBUG] :: test 258048, 2053, 254
RetroArch [libretro DEBUG] :: test2 2054, -2
RetroArch [libretro DEBUG] :: test3 2052
RetroArch [libretro DEBUG] :: test 258048, 2053, 254
RetroArch [libretro DEBUG] :: test2 2054, -2
RetroArch [libretro DEBUG] :: test3 2052
RetroArch [libretro DEBUG] :: test 258048, 2053, 254
on arm :

Code: [Select]

RetroArch [libretro DEBUG] :: test 1048560, 1, 0
RetroArch [libretro DEBUG] :: test 1048560, 2, 8
RetroArch [libretro DEBUG] :: test 1048560, 3, 0
RetroArch [libretro DEBUG] :: test 1048560, 4, 63
RetroArch [libretro DEBUG] :: test 258048, 2050, 255
RetroArch [libretro DEBUG] :: test 258048, 2051, 255
RetroArch [libretro DEBUG] :: test 258048, 2053, 254
RetroArch [libretro DEBUG] :: test2 2054, 254
RetroArch [libretro DEBUG] :: test3 2308
RetroArch [libretro DEBUG] :: test 258048, 2309, 0
RetroArch [libretro DEBUG] :: test 258048, 2310, 128
RetroArch [libretro DEBUG] :: test 258048, 2312, 66
RetroArch [libretro DEBUG] :: test 258048, 2313, 0
RetroArch [libretro DEBUG] :: test 258048, 2381, 209
RetroArch [libretro DEBUG] :: test 258048, 2383, 1
RetroArch [libretro DEBUG] :: test 258048, 2385, 255
RetroArch [libretro DEBUG] :: test 258048, 2389, 202
RetroArch [libretro DEBUG] :: test 258048, 2391, 255
RetroArch [libretro DEBUG] :: test 258048, 2395, 3

As you can see, on arm disp in"test2" is the same as retval from "test", which makes perfect sense since disp is kinda the result of this same FETCH, BUT disp is actually the (INT8)cast of this FETCH, and should return -2 as on x86, so basically "INT8 disp = (INT8)FETCH();" on arm is recognized as "INT8 disp = FETCH();".

So, if i replace "#define INT8 char" by "#define INT8 signed char" in nec.cpp (or if i remove it, because it seems to be the default value), rtype works on arm, but i'm not sure it is the proper way of dealing with it, i'm wondering why you defined this ? Is there an issue with nec games on x86/windows if you let the default signed char ? signed char for INT8 works like a charm on rtype with x86/linux too.

[dink]

Nice work buddy!!
char is supposed to be a signed 8bit int, but for some reason on arm it isn't.  and like you said, fix it by defining INT8 as a signed char instead of just char.  Sorry I couldn't have been more help lately, been real busy with the release stuff.  But ya didn't need any, good sleuth work!

best regards,
- dink

[barbudreadmon]

Actually i did the following changes in nec.cpp :

Code: [Select]

#ifdef _WIN32
 #define INT8 char
 #define INT16 short
 #define INT32 int
#endif
Since we doesn't seem to need those defines (gcc already "properly" defining those ?).
I can't tell if they are really needed on win32, i have no windows toolchain.
With those changes, every NEC games seems to work like a charm now on fbalpha-libretro (on both x86_64 and arm, i can't tell for sure about other archs like ppc).

If you are interested in backporting some of the libretro port of fbalpha (changes we did should be harmless to vanilla fbalpha, but again i have no toolchain to confirm this), and since i bumped fbalpha-libretro to the last release a few hours ago, i can provide you with a full patch from fbalpha to fbalpha-libretro.

Edit : here is the full patch : http://pastebin.com/raw/M375nKLD

[gxb]

Actually i did the following changes in nec.cpp :

Code: [Select]

#ifdef _WIN32
 #define INT8 char
 #define INT16 short
 #define INT32 int
#endif
Since we doesn't seem to need those defines (gcc already "properly" defining those ?).
I can't tell if they are really needed on win32, i have no windows toolchain.
With those changes, every NEC games seems to work like a charm now on fbalpha-libretro (on both x86_64 and arm, i can't tell for sure about other archs like ppc).

If you are interested in backporting some of the libretro port of fbalpha (changes we did should be harmless to vanilla fbalpha, but again i have no toolchain to confirm this), and since i bumped fbalpha-libretro to the last release a few hours ago, i can provide you with a full patch from fbalpha to fbalpha-libretro.

Edit : here is the full patch : http://pastebin.com/raw/M375nKLD

Can you backport your codes to libretro/fbalpha2012? The efficiency of FBA 0.2.97.39 has been deteriorated a lot comparing to 0.2.97.30. So libretro_fbalpha2012's performance is much better than fbalpha on Raspberry 2.

[barbudreadmon]

Can you backport your codes to libretro/fbalpha2012? The efficiency of FBA 0.2.97.39 has been deteriorated a lot comparing to 0.2.97.30. So libretro_fbalpha2012's performance is much better than fbalpha on Raspberry 2.

About the libretro part with the core options, we already answered to you on github (i assume gxb = GanXiaobing), so it seriously displease me to see you come here to ask again.
About the game fixes, i'll try.
Anyway there is probably something wrong with either your raspberry or the distro you use on it : last time i checked (v0.2.97.37) my raspberry pi 2 was running most games at full speed with the new core (i only remember some psikyo shmup using SH-2 cpu, i forgot the name, and Jackie Chan fighting games not running at full speed). A wild guess : you should use recalbox instead of retropie (because i keep thinking a distro targeted at armv6 like raspbian is BAD in terms of performance on raspberry pi 2/3 featuring armv7/armv8 with neon, i have kept warning people on github about that for almost 2 years now), and use decent overclocking settings, i ran mine with the following :

Code: [Select]

arm_freq=1100
sdram_freq=500
core_freq=550
over_voltage=6

[gxb]

About the libretro part with the core options, we already answered to you on github (i assume gxb = GanXiaobing), so it seriously displease me to see you come here to ask again.
About the game fixes, i'll try.
Anyway there is probably something wrong with either your raspberry or the distro you use on it : last time i checked (v0.2.97.37) my raspberry pi 2 was running most games at full speed with the new core (i only remember some psikyo shmup using SH-2 cpu, i forgot the name, and Jackie Chan fighting games not running at full speed). A wild guess : you should use recalbox instead of retropie (because i keep thinking a distro targeted at armv6 like raspbian is BAD in terms of performance on raspberry pi 2/3 featuring armv7/armv8 with neon, i have kept warning people on github about that for almost 2 years now), and use decent overclocking settings, i ran mine with the following :

Code: [Select]

arm_freq=1100
sdram_freq=500
core_freq=550
over_voltage=6

I was not asking for dipswtich since I have found a solution to that. I can set the dipswitch and save state with FBA 0.2.97.38, then load state with  FBA 0.2.97.30. What I asked for is game fixes for NEC games. As you know, with versions bump, a lot of changes were made to the codes. So I am afraid merely changing var defining could not work to old resource codes.
For speed deterioration, I think you can try KONAMI's sunset riders with new FBA core and old FBA core. That's an obvious example. It does not only happen on ARM platform, but also on other platforms such as Gamecube/Wii.

[barbudreadmon]

For speed deterioration, I think you can try KONAMI's sunset riders with new FBA core and old FBA core.

You should post that kind of issue on fbalpha-libretro's github. If i'm not aware, i can't think of a fix. That's not the first case of huge speed deterioration i have to fix, as an example there was such an issue on CPS3 between 0.2.97.30 and 0.2.97.31, i thought of a fix, talked about it here, and now the fix is included upstream. That's how things should work, you can't stay forever on a core who got discontinued 4 years ago (it is FBA 0.2.97.24, not FBA 0.2.97.30).

I created the pull request on fbalpha2012-libretro, it should fix the most annoying issues (irem on arm, konami colors, and the bad cflags issue affecting many other games).

[barbudreadmon]

What are :

Code: [Select]

{0x14, 0xff, 0xff, 0x7f, NULL },dipswitches in games like actfancr ?
I had to filter them out since they were causing issues, but i was wondering if it is what i should do.

[dink]

Those are the default dip settings, for when a game starts that hasn't been started before.  Check your parser against ours in burner/win32/inpdipsw.cpp.

{0x14, 0xff, 0xff, 0x7f, NULL         },

0x14 is the position # of DrvDips variable in the input structure.  one of the next 0xff's is to tell the parser that its the default dips, and one of them is the bitmask (check the struct to be sure), the 0x7f is the actual default dip settings.  The description field is usually left NULL for default settings.

If you remove this, chances are the game will break.  delete config/games/actfancr.ini so it uses the defaults and reload your game and see what I mean. 

best regards,
- dink

[barbudreadmon]

Thanks !

[Arcadez]

What are :

Code: [Select]

{0x14, 0xff, 0xff, 0x7f, NULL },dipswitches in games like actfancr ?
I had to filter them out since they were causing issues, but i was wondering if it is what i should do.

Yeah we have a port of FBA on the ole Xbox, and for reasons that would take too long to explain we cant update the dipswitch src
files so quite often when porting the latest drivers across i run into problems with some games due to the dip code in the drivers
being incompatable with the FBL codebase issues like.......

Games not booting , booting upside down, booting with gfx or gameplay problems, locking into service mode or random crashes here and there luckly we have code present in the FBL Src to just disable dip switches in games by romname and that more or less sorts
any of the problems mentioned above i suppose if all else fails you could code something similar yourself.

[dink]

gamezfan why don't you just drop me your code and I'll fix it the right way instead of a silly hack like that?

[barbudreadmon]

Yeah we have a port of FBA on the ole Xbox, and for reasons that would take too long to explain we cant update the dipswitch src
files so quite often when porting the latest drivers across i run into problems with some games due to the dip code in the drivers
being incompatable with the FBL codebase issues like.......

Games not booting , booting upside down, booting with gfx or gameplay problems, locking into service mode or random crashes here and there luckly we have code present in the FBL Src to just disable dip switches in games by romname and that more or less sorts
any of the problems mentioned above i suppose if all else fails you could code something similar yourself.

Well, the windows specific functions in codebase made it too hard for me to understand (yeah i know, i'm quite a noob at c/c++), so for now i'm in kinda the same predicament (at least, those games are launching now). I asked the writer of dipswitch handling in fbalpha-libretro if he could take a look, but he seems quite busy right now.

The code is here if anyone wanna take a look : https://github.com/libretro/fbalpha/blob/master/src/burner/libretro/libretro.cpp (line 451-587)
"dipswitch_core_options" is an array of "dipswitch_core_option", this array is sent to retroarch through the set_environment() function to provide dipswitch selection inside the gui, and applied to game through apply_dipswitch_from_variables() function.

[dink]

barbudreadmon, InpDIPSWResetDIPs() is the function that takes those default values and puts them in the dip input variable for the default setting (pgi->Input.Constant.nConst), the only thing I can think of is that pgi->Input.Constant.nConst isn't getting handled properly somewhere else?  (perhaps)

[Arcadez]

gamezfan why don't you just drop me your code and I'll fix it the right way instead of a silly hack like that?

Well i didn't want to bother ya with it, i've tried already but in FBL there's two src files for the dip inputs one in the FBA side of the
source which is bang upto date more or less and another in the Xbox GUI side of the source which is way older and in some ways
totally different hence i cant get em on a par with each other.

Honestly it would be too much hastle so better to stick with the hacky workaround which does the job 99% of the time.