Here is the git : fba-libretro
The core is building fine on my linux x86_64 (i still need to try it on my rpi2) and all games i tried (including some added since fba v0.2.97.30) seems to run fine. Feel free to test it, fork it, suggest changes or whatever you want.
oh man, that’s awesome! twinaphex will be thrilled to hear this. He’s been putting off updating it because he’s been too busy working toward the 1.1 release. This saves him the trouble!
The only issue i found is that i can’t build with musashi 3.32 (the m68k emulator in current fba stand alone), so i reverted to musashi 3.3 (used in current fba-libretro). I’ve been trying to put back musashi 3.32 but without success. Anyway games are running fine so i think i’ll let it be.
Do you have this issue in this new implementation?
[QUOTE=sergio-br2;18979]Do you have this issue in this new implementation?
https://github.com/libretro/fba-libretro/issues/16[/QUOTE]
Yes, but it could be because i use the m68k emulator from the old repo since it’s a m68k emulator issue (cf. official fba website), perhaps upgrading to 3.32 would fix it ?
Is Neo Geo CD supported on this version of FBA?
Musashi 3.32 fixed => altered beast fixed. It seems NeoGeo CD doesn’t work.
I noticed today that this new core seems slower (some games running at full speed on my rpi2 with old core won’t run at full speed with this new one). I suppose it is part of the fact that it got 40% bigger than the old one and perhaps it uses some greedier emulators to emulate processors. Any suggestion on what could be done about it ?
Going back to musashi 3.3, removing drivers for consoles and using cps3 drivers from old repo didn’t solve the speed issue…I’ll try porting older versions from stand-alone to see when the issue appeared and perhaps learn why.
So the issue appear with 0.2.97.30 (real one from stand-alone, old libretro repo is actually 0.2.97.28 with improvements from Captain CPS-X if i understood well), i’ll try to update 0.2.97.29 with musashi 3.32 (for altered beast issues) and current rom sets tomorrow.
I can’t compile for windows using MinGW. State.cpp got error: undefined declarations. When I am adding #include <windows.h>, then no errors in compilation, but dll doesnt work with error 0x000012f.
I can’t compile for windows using MinGW. State.cpp got error: undefined declarations. When I am adding #include <windows.h>, then no errors in compilation, but dll doesnt work with error 0x000012f.
Try adding
$(FBA_BURNER_DIR)/state.cpp \
to BURN_BLACKLIST in makefile.libretro And remove your “#include <windows.h>” from state.cpp (which should have no caps). I have no windows atm so i can’t test, but everything is fine on linux with gcc-4.8.3 (except this speed issue on rpi2, but i’m working on it right now).
Don’t forget to report if it worked.
Finally found the issue with cps3 on rpi2 with fba >= 0.2.97.30 : src/cpu/sh2/sh2.cpp With old file, i’m at ~60fps, with new one i’m at ~45fps. Here are the changes between the two of them :
@@ -57,15 +57,16 @@
#define SH2_INT_15 15
#ifndef SH2_INLINE
-#define SH2_INLINE
+#define SH2_INLINE inline
#endif
#if FAST_OP_FETCH
+ static unsigned char * readop_pr; // for FAST_OP_FETCH cpu_readop16()
- #define change_pc(newpc) \
- sh2->pc = (newpc); \
- pSh2Ext->opbase = pSh2Ext->MemMap[ (sh2->pc >> SH2_SHIFT) + SH2_WADD * 2 ]; \
- pSh2Ext->opbase -= (sh2->pc & ~SH2_PAGEM);
+ #define change_pc(newpc) \
+ sh2->pc = (newpc); \
+ readop_pr = pSh2Ext->MemMap[ (sh2->pc >> SH2_SHIFT) + SH2_WADD * 2 ]; \
+ pSh2Ext->opbase = readop_pr - (sh2->pc & ~SH2_PAGEM);
#else
@@ -606,9 +607,9 @@
#if FAST_OP_FETCH
#ifdef LSB_FIRST
-#define cpu_readop16(A) *(unsigned short *)(pSh2Ext->opbase + ((A) ^ 0x02))
+#define cpu_readop16(A) ((uintptr_t)readop_pr >= SH2_MAXHANDLER) ? *(unsigned short *)(pSh2Ext->opbase + ((A) ^ 0x02)) : pSh2Ext->ReadWord[(uintptr_t)readop_pr](A);
#else
-#define cpu_readop16(A) (*(unsigned short *)(pSh2Ext->opbase + ((A))))
+#define cpu_readop16(A) ((uintptr_t)readop_pr >= SH2_MAXHANDLER) ? *(unsigned short *)(pSh2Ext->opbase + ((A))) : pSh2Ext->ReadWord[(uintptr_t)readop_pr](A);
#endif
#else
@@ -617,13 +618,13 @@
{
unsigned char * pr;
pr = pSh2Ext->MemMap[ (A >> SH2_SHIFT) + SH2_WADD * 2 ];
- if ( (unsigned int)pr >= SH2_MAXHANDLER ) {
+ if ( (uintptr_t)pr >= SH2_MAXHANDLER ) {
#ifdef LSB_FIRST
A ^= 2;
#endif
return *((unsigned short *)(pr + (A & SH2_PAGEM)));
}
- return pSh2Ext->ReadWord[(unsigned int)pr](A);
+ return pSh2Ext->ReadWord[pr](A);
}
#endif
@@ -3320,14 +3321,8 @@
do
{
-
- if ( pSh2Ext->suspend ) {
- sh2->sh2_total_cycles += cycles;
- sh2->sh2_icount = 0;
- break;
- }
-
- UINT16 opcode;
+ if (!pSh2Ext->suspend) {
+ UINT16 opcode;
if (sh2->delay) {
//opcode = cpu_readop16(WORD_XOR_BE((UINT32)(sh2->delay & AM)));
@@ -3361,7 +3356,7 @@
case 14<<12: op1110(opcode); break;
default: op1111(opcode); break;
}
-
+ }
#endif
if(sh2->test_irq && !sh2->delay)
I could test if arm is defined and switch between the 2 codes upon that. But i actually think there is something really wrong with the new code that needs to be fixed if i lose 15fps over those few lines. Anyone with better knowledge of C/C++ that could give me a hint ?
In patchnote for v0.2.97.30 :
Fixed idle skip (timers) & crash with FAST_OP_FETCH in SH-2 CPU core [dink]
Oh yeah, if they took out the idle loop skip, that’s bound to have a major negative effect on speed. Maybe something to ifdef and/or make a core option for.
It worked, but I got bugs when playing over internet. Some sounds are broken and in 4players games - second player is controlling a 3rd and 4th players always, First player is controlling 1p. 2nd player in game controlled by no one. (tested on snow bros 2 and original fba-libretro)
Sounds more like a retroarch issue than a core issue, but i’ll check it out when i’m back (i’m at work atm).
I’ll try with a bsnes-like profiling solution, seems like the cleanest way to go