Welcome!

Final Burn Neo => FBN Development => Topic started by: barbudreadmon on March 08, 2015, 09:06:29 AM

Title: Need some help with my libretro port
Post by: barbudreadmon on March 08, 2015, 09:06:29 AM
First, thanks for the new release :).
I've been trying for a few hours to update my libretro port of fba with the new sources, but i encountered a strange issue :

Quote
CXX src/burn/drv/sms/smsfmintf.cpp
In file included from src/burn/drv/sms/smsshared.h:14:0,
                 from src/burn/drv/sms/smsfmintf.cpp:7:
src/burn/drv/sms/sms.h:112:16: erreur: expected initializer before ?gg_port_w?
 void _fastcall gg_port_w(UINT16 port, UINT8 data);
                ^
src/burn/drv/sms/sms.h:113:17: erreur: expected initializer before ?gg_port_r?
 UINT8 _fastcall gg_port_r(UINT16 port);
                 ^
src/burn/drv/sms/sms.h:114:16: erreur: expected initializer before ?ggms_port_w?
 void _fastcall ggms_port_w(UINT16 port, UINT8 data);
And so on...

I did not modify any of the sms sources, they are the same as fba stand-alone (actually, anything not libretro related, except an alternate SH-2 emulator from fba-0.2.97.30 for speed you can enable through make parameters, is the same as stand-alone). Googling this kind of error tells me about a missing semi-colon, but i didn't find it, and i don't think that's the issue here, or you wouldn't be able to build the stand-alone. I could remove sms support (actually i did it to check if everything else was fine, and it was), i don't think that many people use fba-libretro to play sms games, but it would still be sad.
Title: Re: Need some help with my libretro port
Post by: barbudreadmon on March 08, 2015, 09:32:50 AM
By the way, you can download my work from https://github.com/libretro/libretro-fba
Title: Re: Need some help with my libretro port
Post by: dink on March 08, 2015, 11:40:42 AM
oops, I'm sorry, it should have been __fastcall not _fastcall.  Try changing the _fastcall's to __fastcall

best regards,
- dink
Title: Re: Need some help with my libretro port
Post by: barbudreadmon on March 08, 2015, 12:30:00 PM
I noticed and tried that already, but it didn't solve the issue.
Title: Re: Need some help with my libretro port
Post by: dink on March 08, 2015, 01:03:42 PM
try putting #include "driver.h" on a new line after #include "z80_intf.h" ?

best regards,
- dink
Title: Re: Need some help with my libretro port
Post by: dink on March 08, 2015, 01:06:14 PM
Its my first driver, sorry about the troubles!
Title: Re: Need some help with my libretro port
Post by: barbudreadmon on March 08, 2015, 01:50:42 PM
No problem, i'm happy if i can help improving it :).
Still the same issue after including driver.h.

But i noticed a few files were able to compile fine (smssound.cpp for example), i checked their include and noticed tiles_generic.h was included before smsshared.h, so i did the same in every files that failed compiling. Some of them got tiles_generic.h after smsshared.h and failed compiling, one of them got burnint.h conflicting with tiles_generic.h so i removed burnint.h.

Now my core build fine, but i still need to test some sms games to make sure everything is ok.
Title: Re: Need some help with my libretro port
Post by: barbudreadmon on March 08, 2015, 01:55:13 PM
Just moved back with the file where burnint.h and tiles_generic.h were conflicting (smssystem.cpp). The file compile fine if i don't include tiles_generic.h and include burnint.h before smsshared.h.
Title: Re: Need some help with my libretro port
Post by: Romhack on March 08, 2015, 01:56:23 PM
FBA header files doesn't have include guard, you need to be careful when including them.
I always wanted to put #pragma once (or standart include guard with #ifdef and #define) on every header file, but I don't know if Barry would like :S
Title: Re: Need some help with my libretro port
Post by: barbudreadmon on March 08, 2015, 02:01:53 PM
Then perhaps burnint.h (or tiles_generic.h ?) should be included once before sms.h in smsshared.h, and removed from all other sms files ?
Title: Re: Need some help with my libretro port
Post by: barbudreadmon on March 08, 2015, 02:05:02 PM
Actually, having burnint.h included first in the main header file seems mandatory in most (all?) drivers.
Title: Re: Need some help with my libretro port
Post by: barbudreadmon on March 08, 2015, 02:49:46 PM
sms/gg roms are supposed to run fine on fba stand-alone ? They are not WIP ? I just want to make sure the graphical glitches i get on every sms/gg games comes from my modifications :).
Title: Re: Need some help with my libretro port
Post by: dink on March 08, 2015, 04:33:54 PM
Theres only 1 or 2 games with graphics glitches, our driver is pretty damn solid :)
Title: Re: Need some help with my libretro port
Post by: Barry Harris on March 08, 2015, 04:58:43 PM
tiles_generic.h includes burnint.h.

You don't need both. If a driver uses the Generic Tiles module, then include tiles_generic.h, if it access pBurnDraw directly include burnint.h.
Title: Re: Need some help with my libretro port
Post by: barbudreadmon on March 08, 2015, 05:08:09 PM
I tried tons of combination for including tiles_generic/burnint, all worked with the graphical glitches, so i finally included tiles_generic in smsshared and did some cleanup on other files. I think those glitches comes from elsewhere. Perhaps the attached screenshot could help find the issue ?
Title: Re: Need some help with my libretro port
Post by: barbudreadmon on March 08, 2015, 05:10:34 PM
Also, i commited my changes to git.
Title: Re: Need some help with my libretro port
Post by: barbudreadmon on March 10, 2015, 06:16:03 AM
So, no one knows why the graphics are messed up ?
Title: Re: Need some help with my libretro port
Post by: dink on March 10, 2015, 09:19:33 AM
Im not sure :(
Was anything in the driver changed besides the headers?
Title: Re: Need some help with my libretro port
Post by: barbudreadmon on March 10, 2015, 10:36:19 AM
Nothing
Title: Re: Need some help with my libretro port
Post by: Arcadez on March 10, 2015, 12:56:27 PM
A long shot probably but what platform are you running your build on?? reason i ask is with the xbox port of FBA we have some
problems with games that work on PC FBA not booting due to a lack of available memory the standard mem is 64mb....

Notice the games below they wont boot on the xbox but i used a dual launch method and although they now work you can
see the xbox is just short of enough mem to load the sprites correctly. Although there are xbox consoles that have been modified
to have 128mb mem and the games below work perfectly on those

Alien Challenge

(http://www.fshare.it/image.jpeg?i=7f1418434t4)

Lord Of Gun

(http://www.fshare.it/image.jpeg?i=mb141843428)

So was thinking maybe it's a similar problem with the sms driver in your build on the platform your running it on??
Title: Re: Need some help with my libretro port
Post by: barbudreadmon on March 10, 2015, 01:16:27 PM
That's on linux x86_64. I got the same on linux arm. Got this issue only on sms/gg games so i don't think it's related to memory.
Title: Re: Need some help with my libretro port
Post by: dink on March 10, 2015, 05:57:41 PM
I did some thinking, and perhaps its due to larger than 4 byte int's on a 64bit platform.
Can you try compiling a 32bit executable and see if it works?
Another thing to try (first), in smsrender.cpp, put #define ALIGN_DWORD 1 somewhere near the top.

best regards,
- dink
Title: Re: Need some help with my libretro port
Post by: Barry Harris on March 10, 2015, 06:00:16 PM
I did some thinking, and perhaps its due to larger than 4 byte int's on a 64bit platform.
Can you try compiling a 32bit executable and see if it works?
Another thing to try (first), in smsrender.cpp, put #define ALIGN_DWORD 1 somewhere near the top.

best regards,
- dink

For what it's worth, SMS works fine in Windows 64-bit builds. The driver could do some with variable tidying up though. :)
Title: Re: Need some help with my libretro port
Post by: barbudreadmon on March 10, 2015, 07:47:30 PM
64bit issue, i thought i tried sms/gg on my rpi2 but i was mistaken. The core works fine on my rpi2 (which is arm, not arm64) but not on my 64bit linux desktop.
Title: Re: Need some help with my libretro port
Post by: Barry Harris on March 10, 2015, 08:10:43 PM
64bit issue, i thought i tried sms/gg on my rpi2 but i was mistaken. The core works fine on my rpi2 (which is arm, not arm64) but not on my 64bit linux desktop.

The driver needs updating to support the defined types (INT8, UINT8, INT16, UINT16, etc.).

IIRC there are some *2s in there as well rather than sizeof(INT16) etc. which is very bad for compatibility.
Title: Re: Need some help with my libretro port
Post by: dink on March 11, 2015, 03:58:43 AM
I went through and cleaned up all the variables, check the attachment for the updated files.
Title: Re: Need some help with my libretro port
Post by: barbudreadmon on March 11, 2015, 05:09:33 AM
Thanks, everything seems to work fine now.
Title: Re: Need some help with my libretro port
Post by: dink on March 11, 2015, 06:02:08 AM
Glad to hear! :)
best regards,
- dink
Title: Re: Need some help with my libretro port
Post by: barbudreadmon on March 20, 2015, 06:16:15 PM
I found a new issue in my libretro port and was wondering if someone would be nice enough to help.
Here is the issue : Irem M72, M92 and M107 games work fine on my libretro/x86_64, but display a black screen on libretro/arm. I already tried other irem board, especially M90 which is quite similar to M72, and every games worked perfectly, so i'm pretty sure the issue is within d_m72.cpp, d_m92.cpp and d_m107.cpp . Seems to me like the BURN_ENDIAN_SWAP_INT16 not being inside a #ifndef LSB_FIRST in palette_write could be at fault, but i'm not really sure.
Title: Re: Need some help with my libretro port
Post by: iq_132 on March 20, 2015, 06:32:07 PM
Are you getting sound with the black screen? like the game is playing, but black?
Title: Re: Need some help with my libretro port
Post by: barbudreadmon on March 20, 2015, 07:03:33 PM
no
Title: Re: Need some help with my libretro port
Post by: barbudreadmon on March 23, 2015, 05:26:51 PM
Some update on this issue : it is arm specific, games run well on both x86_64 and x86_32.
Title: Re: Need some help with my libretro port
Post by: barbudreadmon on March 25, 2015, 05:03:31 AM
I was wrong, M92/M107 runs fine on x86_32/x86_64, M72 runs with wrong colors (see the attachment).
Title: Re: Need some help with my libretro port
Post by: barbudreadmon on March 25, 2015, 06:41:56 AM
I also noticed something else while trying to debug : DrvInit seems to run with video_type equal to 0 while running rtype.zip (that's what my printf returned), while
Code: [Select]
switch (video_type)
{
case 0: // m72
video_offsets[0] = video_offsets[1] = 0;
break;

case 1: // rtype
seems to say it should have been equal to 1.
Title: Re: Need some help with my libretro port
Post by: dink on March 25, 2015, 11:42:15 AM
Could the palette be in a different format than what your system is expecting?
It almost looks similar to those issues Gamez Fan was having with his xbox port, but my memory is a little fuzzy.  any ideas iq_132?
Title: Re: Need some help with my libretro port
Post by: Arcadez on March 25, 2015, 11:57:10 AM
Yeah i had the same issues with the Gradius 3 on the xbox game was displaying all in green till IQ_132 reworked the pallete handling
in the Driver As i recall the issue was caused by the xbox not liking certain 32bit defines for the pallette code

i guess it might be a similar problem which is causing the m72 games to be ignoring the greens and reds and just displaying
Blues on certain platforms
Title: Re: Need some help with my libretro port
Post by: barbudreadmon on March 25, 2015, 05:44:47 PM
It's kinda strange you speak about gradius3, i wanted to talk about it after resolving the irem issue (which is the most annoying issue on the libretro port), but i actually have most (all?) konami games, including gradius3, displaying blue/yellow only graphics, on all arch. When was the change on gradius3 graphics ? I would like to try the older version.

By the way, treble winner mentioned something about *2s being bad for compatibility, what does he mean ? Lines like those :
Code: [Select]
UINT16 *p = (UINT16*)DrvPalRAM;?
Title: Re: Need some help with my libretro port
Post by: Romhack on March 25, 2015, 06:21:59 PM
It seems to be problem with color conversion from BGR to RGB.
Title: Re: Need some help with my libretro port
Post by: iq_132 on March 25, 2015, 07:50:58 PM
iirc most of these games have 2 byte (15/16 bit palette colors). This is likely an endian-ness issue with calculating them.
usually the pens (individual colors) are stored in xRRRRRGGGGGBBBBB or xxxxRRRRGGGGBBBB format. if they're byteswapped due to endian-ness, you end up with GGGGBBBBBxRRRRRG or GGGGBBBBxxxxRRRR.  If it's a 32-bit color, you may also be having a problem with (r << 16) | ( g << 8 ) | (b << 0) as far as building a 32 (24) bit color pen.
Title: Re: Need some help with my libretro port
Post by: barbudreadmon on March 26, 2015, 05:00:21 AM
So, on gradius3, how should i change the code to test/correct this issue about endian-ness byteswapping ?
Code: [Select]
static inline void DrvRecalcPalette()
{
UINT8 r,g,b;
UINT16 *p = (UINT16*)DrvPalRAM;
for (INT32 i = 0; i < 0x1000 / 2; i++) {
r = (BURN_ENDIAN_SWAP_INT16(p[i]) >> 10) & 0x1f;
g = (BURN_ENDIAN_SWAP_INT16(p[i]) >>  5) & 0x1f;
b = (BURN_ENDIAN_SWAP_INT16(p[i]) >>  0) & 0x1f;

r = (r << 3) | (r >> 2);
g = (g << 3) | (g >> 2);
b = (b << 3) | (b >> 2);

DrvPalette[i] = (r<<16)+(g<<8)+b;
}
}
Title: Re: Need some help with my libretro port
Post by: barbudreadmon on March 26, 2015, 07:46:18 PM
From your explanation, i thought adding
Code: [Select]
#ifdef LSB_FIRST
p[i] = (p[i] << 8) | (p[i] >> 8);
#endif
in the loop could be the answer, but colors are still a mess and the game is blinking :/
Title: Re: Need some help with my libretro port
Post by: iq_132 on March 29, 2015, 01:15:09 PM
Hmmm... I'm really not sure then. Endian-ness issues aren't really things I've dealt with much.
Title: Re: Need some help with my libretro port
Post by: barbudreadmon on March 29, 2015, 04:21:33 PM
I noticed the lowest part of konami logo on my screen is white while it should be red... It makes no sense if the issue is only a biteswapped color palette. How could 255,0,0 go 255,255,255 ?
Title: Re: Need some help with my libretro port
Post by: barbudreadmon on June 01, 2015, 08:58:21 AM
I gave it a try again today, since people on github tends to report a lot about this. I noticed something interesting : there was no issue with colors on konami games with fba-libretro 0.2.97.31, this issue only appeared on next releases (0.2.97.34/35/36, there was no fba-libretro 0.2.97.32/33). Does it ring any bell ? Was there any major change in that timeframe that could explain those issues ?
Title: Re: Need some help with my libretro port
Post by: Barry Harris on June 01, 2015, 09:58:10 AM
I gave it a try again today, since people on github tends to report a lot about this. I noticed something interesting : there was no issue with colors on konami games with fba-libretro 0.2.97.31, this issue only appeared on next releases (0.2.97.34/35/36, there was no fba-libretro 0.2.97.32/33). Does it ring any bell ? Was there any major change in that timeframe that could explain those issues ?

The most likely thing I can see is this (attached).

Title: Re: Need some help with my libretro port
Post by: barbudreadmon on June 01, 2015, 02:49:19 PM
Going back to "BurnHighCol(r, g, b, 0)" turned the screen from yellow/blue/black to blue/black. Anything else ?
Title: Re: Need some help with my libretro port
Post by: Barry Harris on June 02, 2015, 05:47:36 AM
IIRC, it was one of those games that was a pain in the arse to get right with the changes to the M68K core.

Maybe play with the VBlank timing, or CPU interleave? It's pretty difficult to advise when we don't have access to an affected system.
Title: Re: Need some help with my libretro port
Post by: dink on June 02, 2015, 09:40:20 AM
I kinda remember a problem with the new 68k core and Gradius 2: there was a simple case of the interrupt state not being saved in the savestate, causing the loading savestate to make the game crash to the "rom NG" screen.  Also remember iq_132 did some heavy changes to the loading routines on a lot of konami games to use the new BurnLoadRomExt() function - I can see this causing trouble if not implemented correctly.

best regards,
- dink
Title: Re: Need some help with my libretro port
Post by: iq_132 on June 02, 2015, 04:45:48 PM
Something that may be causing a problem is the color conversion in KonamiBlendCopy which converts rom 32-bit to whatever. Just a possibility.
Title: Re: Need some help with my libretro port
Post by: barbudreadmon on June 07, 2015, 05:13:38 AM
It's pretty difficult to advise when we don't have access to an affected system.
Feel free to build/download retroarch/libretro-fba for your system if you have the time to give it some thought, all CPU/OS seems to be affected with this konami color issue.
Title: Re: Need some help with my libretro port
Post by: Arcadez on June 08, 2015, 06:11:32 PM
I run into the same issues sometimes when porting drivers across to FBL i never know if the palette code will be suitable for the xbox
sometimes i luck out and find a workaround but at the end of the day it's not the FBA dev's problem im not smart enough to recode
to palette handling to xbox standards myself BTW im not having a dig at anyone here just stating my Dev Level!!!

For example i should get this.........

Congo Bongo

(http://www.progettoemma.net/snap/congo/0000.png)

But get this instead :D

(http://www.fshare.it/image.jpeg?i=2o1433801pa)

Obviously the colours aren't mixing correctly somewhere along the line


Title: Re: Need some help with my libretro port
Post by: iq_132 on June 08, 2015, 06:39:14 PM
Add this to your DrvDraw function at the top and let me know how it goes.

Code: [Select]
if (DrvRecalc) {
for (INT32 i = 0; i < 0x200; i++) {
DrvPalette[i] = BurnHighCol((Palette[i] >> 16) & 0xff, (Palette[i] >> 8) & 0xff, Palette[i] & 0xff, 0);
}

DrvRecalc = 0;
}
Title: Re: Need some help with my libretro port
Post by: Arcadez on June 08, 2015, 06:56:59 PM
Thanks alota IQ_132 That did the Trick all games in the zaxxon driver are displaying the correct colours in FBL now!!!!.
Maybe the same code or something similar would work  for the konami games in barbudreadmon's FBA Ports..???

might be worth a try in the Gradius 3 driver

Code: [Select]
static inline void DrvRecalcPalette()
{
UINT8 r,g,b;
UINT16 *p = (UINT16*)DrvPalRAM;
for (INT32 i = 0; i < 0x1000 / 2; i++) {
r = (BURN_ENDIAN_SWAP_INT16(p[i]) >> 10) & 0x1f;
g = (BURN_ENDIAN_SWAP_INT16(p[i]) >>  5) & 0x1f;
b = (BURN_ENDIAN_SWAP_INT16(p[i]) >>  0) & 0x1f;

r = (r << 3) | (r >> 2);
g = (g << 3) | (g >> 2);
b = (b << 3) | (b >> 2);

DrvPalette[i] = (r<<16)+(g<<8)+b;
}
}

static INT32 DrvDraw()
{
if (DrvRecalc) {
for (INT32 i = 0; i < 0x200; i++) {
DrvPalette[i] = BurnHighCol((Palette[i] >> 16) & 0xff, (Palette[i] >> 8) & 0xff, Palette[i] & 0xff, 0);
}

DrvRecalc = 0;
}

//if (DrvRecalc) {
//DrvRecalcPalette(); // Remove as the above code now handles this..???
//}

K052109Write(0x1d80,0x10);
K052109Write(0x1f00,0x32);

K052109UpdateScroll();

if (gradius3_priority == 0)
{
if (nSpriteEnable & 1) K052109RenderLayer(1, K052109_OPAQUE, 2);
if (nSpriteEnable & 2) K052109RenderLayer(2, 0, 4);
if (nSpriteEnable & 4) K052109RenderLayer(0, 0, 1);
}
else
{
if (nSpriteEnable & 1) K052109RenderLayer(0, K052109_OPAQUE, 1);
if (nSpriteEnable & 2) K052109RenderLayer(1, 0, 2);
if (nSpriteEnable & 4) K052109RenderLayer(2, 0, 4);
}

if (nBurnLayer & 8) K051960SpritesRender(-1, -1);

KonamiBlendCopy(DrvPalette);

return 0;
}


Title: Re: Need some help with my libretro port
Post by: iq_132 on June 08, 2015, 07:47:23 PM
Thanks alota IQ_132 That did the Trick all games in the zaxxon driver are displaying the correct colours in FBL now!!!!.
Maybe the same code or something similar would work  for the konami games in barbudreadmon's FBA Ports..???

might be worth a try in the Gradius 3 driver

Code: [Select]
static inline void DrvRecalcPalette()
{
UINT8 r,g,b;
UINT16 *p = (UINT16*)DrvPalRAM;
for (INT32 i = 0; i < 0x1000 / 2; i++) {
r = (BURN_ENDIAN_SWAP_INT16(p[i]) >> 10) & 0x1f;
g = (BURN_ENDIAN_SWAP_INT16(p[i]) >>  5) & 0x1f;
b = (BURN_ENDIAN_SWAP_INT16(p[i]) >>  0) & 0x1f;

r = (r << 3) | (r >> 2);
g = (g << 3) | (g >> 2);
b = (b << 3) | (b >> 2);

DrvPalette[i] = (r<<16)+(g<<8)+b;
}
}

static INT32 DrvDraw()
{
if (DrvRecalc) {
for (INT32 i = 0; i < 0x200; i++) {
DrvPalette[i] = BurnHighCol((Palette[i] >> 16) & 0xff, (Palette[i] >> 8) & 0xff, Palette[i] & 0xff, 0);
}

DrvRecalc = 0;
}

//if (DrvRecalc) {
//DrvRecalcPalette(); // Remove as the above code now handles this..???
//}

K052109Write(0x1d80,0x10);
K052109Write(0x1f00,0x32);

K052109UpdateScroll();

if (gradius3_priority == 0)
{
if (nSpriteEnable & 1) K052109RenderLayer(1, K052109_OPAQUE, 2);
if (nSpriteEnable & 2) K052109RenderLayer(2, 0, 4);
if (nSpriteEnable & 4) K052109RenderLayer(0, 0, 1);
}
else
{
if (nSpriteEnable & 1) K052109RenderLayer(0, K052109_OPAQUE, 1);
if (nSpriteEnable & 2) K052109RenderLayer(1, 0, 2);
if (nSpriteEnable & 4) K052109RenderLayer(2, 0, 4);
}

if (nBurnLayer & 8) K051960SpritesRender(-1, -1);

KonamiBlendCopy(DrvPalette);

return 0;
}




Probably not. The Konami games are a unique case in FBA.
Title: Re: Need some help with my libretro port
Post by: saitoh00 on June 11, 2015, 02:35:44 AM
What could be the problem so that the colors appear differently? In the official version this problem does not occur in the emulator AFBA (android) either.

I wish this problem be corrected, I hope you keep trying to find where is hidden the bug in Konami games, as without their port would not be able to play on many platforms fba.
Title: Re: Need some help with my libretro port
Post by: barbudreadmon on June 20, 2015, 03:38:12 AM
After trying a lot of (complex) stuff like reimplementing old KonamiBlendCopy from the old fba-libretro repository, without success, i tried simply changing :
Code: [Select]
PutPix(pBurnDraw + (i * nBurnBpp), BurnHighCol(bmp[i]>>16, (bmp[i]>>8)&0xff, bmp[i]&0xff, 0));to
Code: [Select]
PutPix(pBurnDraw + (i * nBurnBpp), BurnHighCol(bmp[i]>>16, bmp[i]>>8, bmp[i], 0));in KonamiBlendCopy. For whatever reason, it seems it did the trick. Since i'm still kinda a noob at coding C/C++ and emulators, anyone can explain what those "&0xff" are for ?
Title: Re: Need some help with my libretro port
Post by: saitoh00 on June 20, 2015, 04:01:20 AM
Congratulations!!! I'm so glad you were able to solve the problem, when I have some time I get to test your revision.
Title: Re: Need some help with my libretro port
Post by: iq_132 on June 20, 2015, 07:46:11 AM
After trying a lot of (complex) stuff like reimplementing old KonamiBlendCopy from the old fba-libretro repository, without success, i tried simply changing :
Code: [Select]
PutPix(pBurnDraw + (i * nBurnBpp), BurnHighCol(bmp[i]>>16, (bmp[i]>>8)&0xff, bmp[i]&0xff, 0));to
Code: [Select]
PutPix(pBurnDraw + (i * nBurnBpp), BurnHighCol(bmp[i]>>16, bmp[i]>>8, bmp[i], 0));in KonamiBlendCopy. For whatever reason, it seems it did the trick. Since i'm still kinda a noob at coding C/C++ and emulators, anyone can explain what those "&0xff" are for ?
Each color component in a palette entry is 1 byte in size. An UINT32 (unsigned int) is 4 bytes in size. & 0xff chops off additional data. It's strange, when I added the konami code that mingw I was using had an odd bug that if you didn't chop the data, it would cause a crash. You'll see similar setups in other drivers.
Title: Re: Need some help with my libretro port
Post by: barbudreadmon on June 21, 2015, 05:16:05 AM
I tried to replace your line with :
Code: [Select]
PutPix(pBurnDraw + (i * nBurnBpp), BurnHighCol(bmp[i]>>16,(int)((bmp[i]>>8)&0xff),(int)(bmp[i]&0xff), 0));It works too.
Seems to me like gcc don't consider your r/g/b as INT32 after you chopped data, and that's the real issue.
Title: Re: Need some help with my libretro port
Post by: barbudreadmon on June 21, 2015, 06:30:00 AM
Ok, i did a few changes in libretro-fba, i reverted KonamiBlendCopy to your original function and did the casting into int in the code handling the BurnHighCol function in libretro-fba, seems cleaner now and it should avoid future issues of the same kind.

Thanks for all your help, now i'll try to handle the next important issue (irem games displaying black screen with no sound on arm, feel free to suggest anything that could come to mind about it).
Title: Re: Need some help with my libretro port
Post by: dink on June 21, 2015, 09:02:29 AM
Irem games, now thats a tricky bunch.  m62 should be alright, thought?

One thing to keep in mind re: m72,92,107 - the frame writes out the data to the screen in lines, and DrvDraw() just simply transfers the data to the screen.

Did you try more than one game from each system?  I'm curious if some work/some don't.
Title: Re: Need some help with my libretro port
Post by: barbudreadmon on June 21, 2015, 02:15:45 PM
Tried a few on those (only m72,92,107 are concerned), none worked. Since it's an issue that appear on arm32 and not on x86_64, i was wondering if there was any asm code in those ?
Title: Re: Need some help with my libretro port
Post by: dink on June 21, 2015, 10:27:07 PM
Theres no asm that I can think of, maybe theres something with the vez/nec v.2x-v.3x cpu emulation on arm?  Like an endian issue or something?
Title: Re: Need some help with my libretro port
Post by: barbudreadmon on September 12, 2015, 08:16:48 AM
Today i tried mame078 and mame139 on my rpi2 and there was no issue with irem m72,92,107 games. Do you know which version of mame is irem fba driver based on ?
Title: Re: Need some help with my libretro port
Post by: Arcadez on September 12, 2015, 09:17:48 AM
Today i tried mame078 and mame139 on my rpi2 and there was no issue with irem m72,92,107 games. Do you know which version of mame is irem fba driver based on ?

Irem M62 M63 M72 M90 M92 were added to FBA 0.2.97.09 which was released oct 2011 if those drivers we're ported from the
Currant MAME at that time then it'll be MAME144. M107 however was a more recent FBA addition one other thing of note is the
FBA NEC CPU is pre MAME 123 as it doesnt have the op-code fixes to make Risky Challenge playable so maybe the Irem drivers
are pre MAME 123 also..???

Anyway i dont think the Irem games are the problem i think it's more likely a FBA compatability issue on the Platform your porting to.
Title: Re: Need some help with my libretro port
Post by: iq_132 on September 12, 2015, 09:38:15 AM
FBA NEC CPU is pre MAME 123 as it doesnt have the op-code fixes to make Risky Challenge playable so maybe the Irem drivers
On older FBA versions. The more recent ones have the opcode fixes. (it's pretty much a completely new core)
Title: Re: Need some help with my libretro port
Post by: Arcadez on September 12, 2015, 09:42:30 AM
On older FBA versions. The more recent ones have the opcode fixes. (it's pretty much a completely new core)

Ok Nice one i never knew that i guess i know what i'll be doing this weekend ;)
Title: Re: Need some help with my libretro port
Post by: iq_132 on September 12, 2015, 09:52:32 AM
Ok Nice one i never knew that i guess i know what i'll be doing this weekend ;)
It makes things veeery slow on the xbox. I think someone tried to port it over before.  The newer nec core gives sound to some of the toaplan games too.
Title: Re: Need some help with my libretro port
Post by: Arcadez on September 12, 2015, 10:07:53 AM
It makes things veeery slow on the xbox. I think someone tried to port it over before.  The newer nec core gives sound to some of the toaplan games too.

We have this in FBL already big fella as we got sound in those Toaplan games Like Dogyunn Batsugun V-Five Knuckle Bash etc etc
With regards to Risky Challenge it's not good in FBA it must still be missing those CPU Op-code changes required no big deal im just
shooting the breeze here but if your curious check the intro level then just take a peek at level 1 in MAME and you'll see what i mean

https://www.youtube.com/watch?v=NVUb0kD1P5A (https://www.youtube.com/watch?v=NVUb0kD1P5A)
Title: Re: Need some help with my libretro port
Post by: barbudreadmon on September 13, 2015, 09:00:40 AM
Anyway i dont think the Irem games are the problem i think it's more likely a FBA compatability issue on the Platform your porting to.
What do you mean ? FBA-libretro is working fine on rpi2, except for those 3 irem boards and a few cpu intensive games.
Title: Re: Need some help with my libretro port
Post by: Arcadez on September 13, 2015, 09:14:59 AM
What do you mean ? FBA-libretro is working fine on rpi2, except for those 3 irem boards and a few cpu intensive games.

Well those 3 Irem boards etc etc work in FBA they also work in the xbox FBA port so surely the problem is on the platform
your porting it to eg RPI2 or your libretro interface what else can it be..???
Title: Re: Need some help with my libretro port
Post by: barbudreadmon on September 13, 2015, 12:10:48 PM
Sure, but since it only affects irem games, that's a platform issue on a specific driver, so the issue should be in irem drivers.
Title: Re: Need some help with my libretro port
Post by: dink on September 13, 2015, 02:19:09 PM
I'm curious to know if theres another non-pc system that FBA is ported to that has irem drivers working, I also wonder if there is a way to see if the cpu is doing anything at all, like by checking and logging the memory reads / writes on windows and rpi2, then compare the first couple of each.
Title: Re: Need some help with my libretro port
Post by: dink on September 13, 2015, 02:36:20 PM
to help rule out/in the nec cpu, please try some other nec v2x/v3x games and see if they have problems similar to irem.
try: pre90s/d_dynduke.cpp, pst90s/d_raiden.cpp, and d_raiden2.cpp and let us know.

best regards,
- dink
Title: Re: Need some help with my libretro port
Post by: barbudreadmon on September 13, 2015, 03:42:36 PM
All those games have problems :
-> dynduke games froze on first screen (white with some writings on top-right)
-> raiden 1 games blinked white and black
-> raiden 2 games froze on a black screen (and unlike the other 2, my rpi2 seemed irresponsive for a few seconds)
Title: Re: Need some help with my libretro port
Post by: iq_132 on September 13, 2015, 03:49:34 PM
All those games have problems :
-> dynduke games froze on first screen (white with some writings on top-right)
-> raiden 1 games blinked white and black
-> raiden 2 games froze on a black screen (and unlike the other 2, my rpi2 seemed irresponsive for a few seconds)
I do NOT write endian safe code, nor do I test it with anything but a 32-bit depth or 44100/48000hz frequency. It's just not something I keep in mind, so I would start with that, for sure.
Title: Re: Need some help with my libretro port
Post by: Arcadez on September 13, 2015, 03:58:43 PM
All those games have problems :
-> dynduke games froze on first screen (white with some writings on top-right)
-> raiden 1 games blinked white and black
-> raiden 2 games froze on a black screen (and unlike the other 2, my rpi2 seemed irresponsive for a few seconds)

Right ive got an idea what might be causing this i'll PM ya shortly
Title: Re: Need some help with my libretro port
Post by: barbudreadmon on September 13, 2015, 04:01:47 PM
Linux on arm is supposed to be little endian, same as windows on x86/x86_64
Title: Re: Need some help with my libretro port
Post by: barbudreadmon on September 13, 2015, 05:37:50 PM
It also seems to be unrelated to samplerate and color-depth (hardcoded to 16 bits / 32 Khz in the libretro port but causing no issues on libretro-fba x86_64).
Title: Re: Need some help with my libretro port
Post by: dink on September 13, 2015, 07:04:26 PM
try a little test, put this in DrvFrame(); of d_m72.cpp, and run any game:
Code: [Select]
#ifdef LSB_FIRST
bprintf(0, _T("lf"));
#else
bprintf(0, _T("ll"));
#endif
Title: Re: Need some help with my libretro port
Post by: barbudreadmon on September 14, 2015, 02:58:01 PM
I had to replace this code with
Code: [Select]
#ifdef LSB_FIRST
printf("%s", "lf");
#else
printf("%s", "ll");
#endif
since bprintf wouldn't print anything on retroarch, and it's printing "lf" as expected.
Title: Re: Need some help with my libretro port
Post by: barbudreadmon on September 17, 2015, 02:05:41 AM
Ok, so what we know :
- It is not endian related
- It is not x86 specific instruction related (no ASM code)
- It is probably related to nec V30 cpu (all affected games uses this cpu)
- The cpu emulator is not necessarily the culprit since m90 emulation (which also uses V30) is working

Btw, i saw some INT64 in m72 DrvFrame function, is that not supposed to work only on 64bits machines ?
Title: Re: Need some help with my libretro port
Post by: barbudreadmon on November 09, 2015, 01:43:11 AM
After reading some documentation about what could go wrong when you build x86 targeted code on arm, i've been trying to fix those nec v30 games again.
So right now i'm trying to fix "undefined behavior" in cpu/nec, but it seems i'm doing it wrong, for example i tried replacing
Code: [Select]
#define FETCH() cpu_readop_arg((Sreg(PS)<<4) + sChipsPtr->ip++)by
Code: [Select]
#define FETCH() ({ cpu_readop_arg((Sreg(PS)<<4) + sChipsPtr->ip); sChipsPtr->ip++; })or
Code: [Select]
#define FETCH() ({ sChipsPtr->ip++; cpu_readop_arg((Sreg(PS)<<4) + sChipsPtr->ip); })First threw me a runtime error, second threw me a black screen, any guess on what i should actually write ?
Title: Re: Need some help with my libretro port
Post by: barbudreadmon on November 11, 2015, 04:15:13 AM
Ok, the right way to write this without having "undefined behavior" was to write the following :
Code: [Select]
#define FETCH() ({ UINT8 retval; retval = cpu_readop_arg((Sreg(PS)<<4) + sChipsPtr->ip); sChipsPtr->ip++; retval; })I'll try to fix all those "undefined behavior" warnings (btw, you can enable those warnings by adding "-fsanitize=undefined -Wall" to cflags/cxxflags/ldflags) and see if it fix v30 emulation on arm. I'll propose a patch if it's a success.
Title: Re: Need some help with my libretro port
Post by: barbudreadmon on April 26, 2016, 03:38:55 AM
Hi !

We found a new issue on libretro-fba (the irem on arm issue is still unresolved btw), ironclad will display a black screen with controls and sound working, any idea where i could start searching ?
Title: Re: Need some help with my libretro port
Post by: Arcadez on April 26, 2016, 09:06:05 AM
Hi !

We found a new issue on libretro-fba (the irem on arm issue is still unresolved btw), ironclad will display a black screen with controls and sound working, any idea where i could start searching ?

It's a Neogeo Bios issue the game will only work if the Bios are set to USA or Japan anything else and it wont work correctly
Title: Re: Need some help with my libretro port
Post by: barbudreadmon on April 26, 2016, 10:37:40 AM
Thanks for the quick answer :), this game indeed works with a usa/japan bios.
Title: Re: Need some help with my libretro port
Post by: barbudreadmon on May 05, 2016, 06:09:03 AM
Someone at github told me neounidefaultDIPList was not updated with new unibios 3.2 and it could cause some issues with some demo (spiderman, ...), we applied some fix on libretro-fba there : https://github.com/libretro/libretro-fba/pull/72/commits/96d95eb4dee47216cc1a4c029f078401f5cb01fb
Title: Re: Need some help with my libretro port
Post by: barbudreadmon on May 17, 2016, 07:16:00 AM
I have a new question ! :)

PAGE_SHIFT, PAGE_MASK, PAGE_SIZE, ... are used as constant/macro in a lot of files, but it is causing warnings/errors depending on the platform/toolchain we use to compile libretro-fba, because those names are used by some macro in those toolchains. Would it be safe to prefix all those PAGE_* variables ? Perhaps it would be a good thing to do upstream to improve portability ?

Btw, anyone took a look at my last post ? Don't know if there is actually an issue on fba standalone, but it is worth a look.
Title: Re: Need some help with my libretro port
Post by: dink on May 17, 2016, 07:27:43 AM
Hi, Regarding the previous to the last post, the unibios problem was solved a few weeks back.  I guess it wouldn't hurt to change the defines for the PAGE_* so they don't conflict with system-related things. 

best regards,
- dink
Title: Re: Need some help with my libretro port
Post by: barbudreadmon on October 11, 2016, 05:16:38 PM
Hi !

I've been working on libretro-fba last few days, and i decided to try fixing those irem games on arm again, and after trying to bprint tons of things inside d_m72.cpp on both my pc and my raspberry i think i've finally got some lead ! Here is my custom m72_main_write :
Code: [Select]
void __fastcall m72_main_write(UINT32 address, UINT8 data)
{
bprintf (PRINT_NORMAL, _T("address %d\n"), address);
if ((address & 0xff000) == 0xb0000) {
bprintf (PRINT_NORMAL, _T("protection_write cond\n"));
protection_write(address, data);
return;
}

if ((address & 0xff000) == 0xc8000) {
bprintf (PRINT_NORMAL, _T("palette_write cond 1\n"));
if (address & 1) data = 0xff;
  DrvPalRAM[(address & 0xdff) | 0x0000] = DrvPalRAM[(address & 0xdff) | 0x0200] = data | 0xe0;
palette_write(address, 0);
return;
}

if ((address & 0xff000) == 0xcc000) {
bprintf (PRINT_NORMAL, _T("palette_write cond 2\n"));
if (address & 1) data = 0xff;
  DrvPalRAM[(address & 0xdff) | 0x1000] = DrvPalRAM[(address & 0xdff) | 0x1200] = data | 0xe0;
palette_write(address, 1);
return;
}
}
I noticed the following output while running rtype :
On x86 (working) :
Code: [Select]
RetroArch [libretro DEBUG] :: address 819200
RetroArch [libretro DEBUG] :: palette_write cond 1
RetroArch [libretro DEBUG] :: address 819201
RetroArch [libretro DEBUG] :: palette_write cond 1
RetroArch [libretro DEBUG] :: address 819202
RetroArch [libretro DEBUG] :: palette_write cond 1
RetroArch [libretro DEBUG] :: address 819203
RetroArch [libretro DEBUG] :: palette_write cond 1
RetroArch [libretro DEBUG] :: address 819204
RetroArch [libretro DEBUG] :: palette_write cond 1
RetroArch [libretro DEBUG] :: address 819205
RetroArch [libretro DEBUG] :: palette_write cond 1
RetroArch [libretro DEBUG] :: address 819206
RetroArch [libretro DEBUG] :: palette_write cond 1
RetroArch [libretro DEBUG] :: address 819207
RetroArch [libretro DEBUG] :: palette_write cond 1
RetroArch [libretro DEBUG] :: address 819208
RetroArch [libretro DEBUG] :: palette_write cond 1
RetroArch [libretro DEBUG] :: address 819209
RetroArch [libretro DEBUG] :: palette_write cond 1
RetroArch [libretro DEBUG] :: address 819210
RetroArch [libretro DEBUG] :: palette_write cond 1
RetroArch [libretro DEBUG] :: address 819211
RetroArch [libretro DEBUG] :: palette_write cond 1
RetroArch [libretro DEBUG] :: address 819212
RetroArch [libretro DEBUG] :: palette_write cond 1
RetroArch [libretro DEBUG] :: address 819213
RetroArch [libretro DEBUG] :: palette_write cond 1
RetroArch [libretro DEBUG] :: address 819214
RetroArch [libretro DEBUG] :: palette_write cond 1
RetroArch [libretro DEBUG] :: address 819215
RetroArch [libretro DEBUG] :: palette_write cond 1
RetroArch [libretro DEBUG] :: address 819216
RetroArch [libretro DEBUG] :: palette_write cond 1
RetroArch [libretro DEBUG] :: address 819217
...
On ARM (black screen and no sound):
Code: [Select]
RetroArch [libretro DEBUG] :: address 0
RetroArch [libretro DEBUG] :: address 1
RetroArch [libretro DEBUG] :: address 2
RetroArch [libretro DEBUG] :: address 3
RetroArch [libretro DEBUG] :: address 4
RetroArch [libretro DEBUG] :: address 5
RetroArch [libretro DEBUG] :: address 6
RetroArch [libretro DEBUG] :: address 7
RetroArch [libretro DEBUG] :: address 8
RetroArch [libretro DEBUG] :: address 9
RetroArch [libretro DEBUG] :: address 10
RetroArch [libretro DEBUG] :: address 11
RetroArch [libretro DEBUG] :: address 12
RetroArch [libretro DEBUG] :: address 13
RetroArch [libretro DEBUG] :: address 14
RetroArch [libretro DEBUG] :: address 15
RetroArch [libretro DEBUG] :: address 16
RetroArch [libretro DEBUG] :: address 17
RetroArch [libretro DEBUG] :: address 18
RetroArch [libretro DEBUG] :: address 19
RetroArch [libretro DEBUG] :: address 20
RetroArch [libretro DEBUG] :: address 21
RetroArch [libretro DEBUG] :: address 22
RetroArch [libretro DEBUG] :: address 23
RetroArch [libretro DEBUG] :: address 24
RetroArch [libretro DEBUG] :: address 25
RetroArch [libretro DEBUG] :: address 26
RetroArch [libretro DEBUG] :: address 27
RetroArch [libretro DEBUG] :: address 28
RetroArch [libretro DEBUG] :: address 29
RetroArch [libretro DEBUG] :: address 30
RetroArch [libretro DEBUG] :: address 31
RetroArch [libretro DEBUG] :: address 32
RetroArch [libretro DEBUG] :: address 33
RetroArch [libretro DEBUG] :: address 34
RetroArch [libretro DEBUG] :: address 35
RetroArch [libretro DEBUG] :: address 36
RetroArch [libretro DEBUG] :: address 37
RetroArch [libretro DEBUG] :: address 38
RetroArch [libretro DEBUG] :: address 39
RetroArch [libretro DEBUG] :: address 40
RetroArch [libretro DEBUG] :: address 41
...
The difference seems big enough to be the cause of the whole issue. On ARM it seems very unlikely he would enter any of the conditions in m72_main_write, probably leading to the whole issue. So, after following the track further, i kinda understand there is something wrong happening on ARM in either cpu_writemem20, VezWriteByte, VezWriteWord, VezWriteLong or VezCheatWrite from nec_intf.cpp , but i'm kinda lost at what i should do next to track the issue, do you have any idea ?
Title: Re: Need some help with my libretro port
Post by: dink on October 11, 2016, 06:40:32 PM
I'm trying to deduce something. With your debug code, please run Mr.Heli and post what you get.

Title: Re: Need some help with my libretro port
Post by: barbudreadmon on October 12, 2016, 01:48:36 AM
I edited my last post, some of my output was from another of my bprints, things will be more clear now.
mrheli on x86 (working) :
Code: [Select]
RetroArch [libretro DEBUG] :: address 720896
RetroArch [libretro DEBUG] :: protection_write cond
RetroArch [libretro DEBUG] :: address 720897
RetroArch [libretro DEBUG] :: protection_write cond
RetroArch [libretro DEBUG] :: address 720898
RetroArch [libretro DEBUG] :: protection_write cond
RetroArch [libretro DEBUG] :: address 720899
RetroArch [libretro DEBUG] :: protection_write cond
RetroArch [libretro DEBUG] :: address 720900
RetroArch [libretro DEBUG] :: protection_write cond
RetroArch [libretro DEBUG] :: address 720901
RetroArch [libretro DEBUG] :: protection_write cond
RetroArch [libretro DEBUG] :: address 720902
RetroArch [libretro DEBUG] :: protection_write cond
RetroArch [libretro DEBUG] :: address 720903
RetroArch [libretro DEBUG] :: protection_write cond
RetroArch [libretro DEBUG] :: address 720904
RetroArch [libretro DEBUG] :: protection_write cond
RetroArch [libretro DEBUG] :: address 720905
RetroArch [libretro DEBUG] :: protection_write cond
RetroArch [libretro DEBUG] :: address 720906
RetroArch [libretro DEBUG] :: protection_write cond
RetroArch [libretro DEBUG] :: address 720907
RetroArch [libretro DEBUG] :: protection_write cond
RetroArch [libretro DEBUG] :: address 720908
RetroArch [libretro DEBUG] :: protection_write cond
RetroArch [libretro DEBUG] :: address 720909
RetroArch [libretro DEBUG] :: protection_write cond
RetroArch [libretro DEBUG] :: address 720910
RetroArch [libretro DEBUG] :: protection_write cond
RetroArch [libretro DEBUG] :: address 720911
RetroArch [libretro DEBUG] :: protection_write cond
RetroArch [libretro DEBUG] :: address 720912
RetroArch [libretro DEBUG] :: protection_write cond
RetroArch [libretro DEBUG] :: address 720913
RetroArch [libretro DEBUG] :: protection_write cond
RetroArch [libretro DEBUG] :: address 720914
RetroArch [libretro DEBUG] :: protection_write cond
RetroArch [libretro DEBUG] :: address 720915
RetroArch [libretro DEBUG] :: protection_write cond
RetroArch [libretro DEBUG] :: address 720916
RetroArch [libretro DEBUG] :: protection_write cond
RetroArch [libretro DEBUG] :: address 720917
RetroArch [libretro DEBUG] :: protection_write cond
RetroArch [libretro DEBUG] :: address 720918
RetroArch [libretro DEBUG] :: protection_write cond
RetroArch [libretro DEBUG] :: address 720919
RetroArch [libretro DEBUG] :: protection_write cond
RetroArch [libretro DEBUG] :: address 720920
RetroArch [libretro DEBUG] :: protection_write cond
RetroArch [libretro DEBUG] :: address 720921
RetroArch [libretro DEBUG] :: protection_write cond
RetroArch [libretro DEBUG] :: address 720922
RetroArch [libretro DEBUG] :: protection_write cond
RetroArch [libretro DEBUG] :: address 720923
RetroArch [libretro DEBUG] :: protection_write cond
RetroArch [libretro DEBUG] :: address 720924
RetroArch [libretro DEBUG] :: protection_write cond
RetroArch [libretro DEBUG] :: address 720925
RetroArch [libretro DEBUG] :: protection_write cond
RetroArch [libretro DEBUG] :: address 720926
RetroArch [libretro DEBUG] :: protection_write cond
RetroArch [libretro DEBUG] :: address 720927
RetroArch [libretro DEBUG] :: protection_write cond
RetroArch [libretro DEBUG] :: address 720928
RetroArch [libretro DEBUG] :: protection_write cond
RetroArch [libretro DEBUG] :: address 720929
RetroArch [libretro DEBUG] :: protection_write cond
RetroArch [libretro DEBUG] :: address 720930
RetroArch [libretro DEBUG] :: protection_write cond
RetroArch [libretro DEBUG] :: address 720931
RetroArch [libretro DEBUG] :: protection_write cond
RetroArch [libretro DEBUG] :: address 720932
RetroArch [libretro DEBUG] :: protection_write cond
RetroArch [libretro DEBUG] :: address 720933
RetroArch [libretro DEBUG] :: protection_write cond
RetroArch [libretro DEBUG] :: address 720934
RetroArch [libretro DEBUG] :: protection_write cond
RetroArch [libretro DEBUG] :: address 720935
RetroArch [libretro DEBUG] :: protection_write cond
RetroArch [libretro DEBUG] :: address 720936
RetroArch [libretro DEBUG] :: protection_write cond
RetroArch [libretro DEBUG] :: address 720937
RetroArch [libretro DEBUG] :: protection_write cond
RetroArch [libretro DEBUG] :: address 720938
RetroArch [libretro DEBUG] :: protection_write cond
RetroArch [libretro DEBUG] :: address 720939
RetroArch [libretro DEBUG] :: protection_write cond
RetroArch [libretro DEBUG] :: address 720940
RetroArch [libretro DEBUG] :: protection_write cond
RetroArch [libretro DEBUG] :: address 720941
RetroArch [libretro DEBUG] :: protection_write cond
RetroArch [libretro DEBUG] :: address 720942
RetroArch [libretro DEBUG] :: protection_write cond
RetroArch [libretro DEBUG] :: address 720943
RetroArch [libretro DEBUG] :: protection_write cond
RetroArch [libretro DEBUG] :: address 720944
RetroArch [libretro DEBUG] :: protection_write cond
RetroArch [libretro DEBUG] :: address 720945
RetroArch [libretro DEBUG] :: protection_write cond
RetroArch [libretro DEBUG] :: address 720946
RetroArch [libretro DEBUG] :: protection_write cond
RetroArch [libretro DEBUG] :: address 720947
RetroArch [libretro DEBUG] :: protection_write cond
RetroArch [libretro DEBUG] :: address 720948
RetroArch [libretro DEBUG] :: protection_write cond
...
on ARM (black screen and no sound) :
Code: [Select]
RetroArch [libretro DEBUG] :: address 3
RetroArch [libretro DEBUG] :: address 2
RetroArch [libretro DEBUG] :: address 0
RetroArch [libretro DEBUG] :: address 0
RetroArch [libretro DEBUG] :: address 0
RetroArch [libretro DEBUG] :: address 0
RetroArch [libretro DEBUG] :: address 0
RetroArch [libretro DEBUG] :: address 0
RetroArch [libretro DEBUG] :: address 0
RetroArch [libretro DEBUG] :: address 0
RetroArch [libretro DEBUG] :: address 0
RetroArch [libretro DEBUG] :: address 0
RetroArch [libretro DEBUG] :: address 0
RetroArch [libretro DEBUG] :: address 0
RetroArch [libretro DEBUG] :: address 0
RetroArch [libretro DEBUG] :: address 0
RetroArch [libretro DEBUG] :: address 0
RetroArch [libretro DEBUG] :: address 0
RetroArch [libretro DEBUG] :: address 0
RetroArch [libretro DEBUG] :: address 0
RetroArch [libretro DEBUG] :: address 0
RetroArch [libretro DEBUG] :: address 0
RetroArch [libretro DEBUG] :: address 0
RetroArch [libretro DEBUG] :: address 0
RetroArch [libretro DEBUG] :: address 0
RetroArch [libretro DEBUG] :: address 0
RetroArch [libretro DEBUG] :: address 0
RetroArch [libretro DEBUG] :: address 0
RetroArch [libretro DEBUG] :: address 0
RetroArch [libretro DEBUG] :: address 0
RetroArch [libretro DEBUG] :: address 0
RetroArch [libretro DEBUG] :: address 0
RetroArch [libretro DEBUG] :: address 0
RetroArch [libretro DEBUG] :: address 0
RetroArch [libretro DEBUG] :: address 0
RetroArch [libretro DEBUG] :: address 0
RetroArch [libretro DEBUG] :: address 0
RetroArch [libretro DEBUG] :: address 0
RetroArch [libretro DEBUG] :: address 0
RetroArch [libretro DEBUG] :: address 0
RetroArch [libretro DEBUG] :: address 0
RetroArch [libretro DEBUG] :: address 0
RetroArch [libretro DEBUG] :: address 0
RetroArch [libretro DEBUG] :: address 0
RetroArch [libretro DEBUG] :: address 0
RetroArch [libretro DEBUG] :: address 0
RetroArch [libretro DEBUG] :: address 0
RetroArch [libretro DEBUG] :: address 0
RetroArch [libretro DEBUG] :: address 0
RetroArch [libretro DEBUG] :: address 0
RetroArch [libretro DEBUG] :: address 0
RetroArch [libretro DEBUG] :: address 0
RetroArch [libretro DEBUG] :: address 0
RetroArch [libretro DEBUG] :: address 0
RetroArch [libretro DEBUG] :: address 0
RetroArch [libretro DEBUG] :: address 0
RetroArch [libretro DEBUG] :: address 0
RetroArch [libretro DEBUG] :: address 0
RetroArch [libretro DEBUG] :: address 0
RetroArch [libretro DEBUG] :: address 0
RetroArch [libretro DEBUG] :: address 0
RetroArch [libretro DEBUG] :: address 0
RetroArch [libretro DEBUG] :: address 0
RetroArch [libretro DEBUG] :: address 0
RetroArch [libretro DEBUG] :: address 0
RetroArch [libretro DEBUG] :: address 0
RetroArch [libretro DEBUG] :: address 0
RetroArch [libretro DEBUG] :: address 0
RetroArch [libretro DEBUG] :: address 0
RetroArch [libretro DEBUG] :: address 0
RetroArch [libretro DEBUG] :: address 0
RetroArch [libretro DEBUG] :: address 0
RetroArch [libretro DEBUG] :: address 0
RetroArch [libretro DEBUG] :: address 0
RetroArch [libretro DEBUG] :: address 0
RetroArch [libretro DEBUG] :: address 0
RetroArch [libretro DEBUG] :: address 0
RetroArch [libretro DEBUG] :: address 0
RetroArch [libretro DEBUG] :: address 0
RetroArch [libretro DEBUG] :: address 0
RetroArch [libretro DEBUG] :: address 0
RetroArch [libretro DEBUG] :: address 0
RetroArch [libretro DEBUG] :: address 0
RetroArch [libretro DEBUG] :: address 0
RetroArch [libretro DEBUG] :: address 0
RetroArch [libretro DEBUG] :: address 0
RetroArch [libretro DEBUG] :: address 0
RetroArch [libretro DEBUG] :: address 0
RetroArch [libretro DEBUG] :: address 0
RetroArch [libretro DEBUG] :: address 0
...
Title: Re: Need some help with my libretro port
Post by: barbudreadmon on October 13, 2016, 01:55:20 AM
It seems there is nothing wrong in cpu_writemem20, VezWriteByte, VezWriteWord, VezWriteLong or VezCheatWrite.

I added the following :
Code: [Select]


void cpu_writemem20(UINT32 a, UINT8 d)
{
bprintf (PRINT_NORMAL, _T("cpu_writemem20 %d\n"), a);
a &= 0xFFFFF;

UINT8 * p = VezCurrentCPU->ppMemWrite[ a >> VEZ_MEM_SHIFT ];
if ( p )
*(p + a) = d;
else
VezCurrentCPU->WriteHandler(a, d);
}

void VezWriteByte(UINT32 a, UINT8 d)
{
bprintf (PRINT_NORMAL, _T("VezWriteByte %d\n"), a);
a &= 0xFFFFF;

UINT8 * p = VezCurrentCPU->ppMemWrite[ a >> VEZ_MEM_SHIFT ];
if ( p )
*(p + a) = d;
else
VezCurrentCPU->WriteHandler(a, d);
}

void VezWriteWord(UINT32 a, UINT16 d)
{
bprintf (PRINT_NORMAL, _T("VezWriteWord %d\n"), a);
a &= 0xFFFFF;

UINT16 * p = (UINT16*)VezCurrentCPU->ppMemWrite[ a >> VEZ_MEM_SHIFT ];
if ( p )
*(p + (a / 2)) = d;
else {
VezCurrentCPU->WriteHandler(a, d);
VezCurrentCPU->WriteHandler(a+1, d >> 8);
}
}

void VezWriteLong(UINT32 a, UINT32 d)
{
bprintf (PRINT_NORMAL, _T("VezWriteLong %d\n"), a);
a &= 0xFFFFF;

UINT32 * p = (UINT32*)VezCurrentCPU->ppMemWrite[ a >> VEZ_MEM_SHIFT ];
if ( p )
*(p + (a / 4)) = d;
else {
VezCurrentCPU->WriteHandler(a, d);
VezCurrentCPU->WriteHandler(a+1, d >> 8);
VezCurrentCPU->WriteHandler(a+2, d >> 16);
VezCurrentCPU->WriteHandler(a+3, d >> 24);

}
}
static void VezCheatWrite(UINT32 a, UINT8 d)
{
bprintf (PRINT_NORMAL, _T("VezCheatWrite %d\n"), a);
a &= 0xfffff;

UINT8 * p;

p = VezCurrentCPU->ppMemWrite[ a >> VEZ_MEM_SHIFT ];
if ( p ) *(p + a) = d;

p = VezCurrentCPU->ppMemRead[ a >> VEZ_MEM_SHIFT ];
if ( p ) *(p + a) = d;

p = VezCurrentCPU->ppMemFetch[ a >> VEZ_MEM_SHIFT ];
if ( p ) *(p + a) = d;

p = VezCurrentCPU->ppMemFetchData[ a >> VEZ_MEM_SHIFT ];
if ( p ) *(p + a) = d;

VezCurrentCPU->WriteHandler(a, d);
}
From my outputs, i confirm the "a" argument is already wrong on arm.
So the issue seems to be at the call of those functions in either src/cpu/nec/v25sfr.c or src/cpu/nec/nec.cpp
Title: Re: Need some help with my libretro port
Post by: dink on October 13, 2016, 08:28:27 AM
ahh, yes, the a, a+1,a+2 etc will never work on arm without le2be (or the other way around).  I think the reason some nec-v games work and not others is that the ones that work are only 8bit all-around.  (maybe, its just a theory).  On the other hand, I wonder how the other processors deal with that.  hrmm. 
(I'll post some better/more helpfull info when I can think of it!)

best regards,
- dink
Title: Re: Need some help with my libretro port
Post by: barbudreadmon on October 13, 2016, 02:39:51 PM
ahh, yes, the a, a+1,a+2 etc will never work on arm without le2be (or the other way around).
the raspberry cpu is little endian, same as x86.
I've gone a little further in my tests through bprint : it looks to me like "DefaultBase(Seg)" returns different results from the same input on x86 and arm, i'll try to investigate further later today.
Title: Re: Need some help with my libretro port
Post by: dink on October 13, 2016, 05:47:48 PM
the raspberry cpu is little endian, same as x86.
I've gone a little further in my tests through bprint : it looks to me like "DefaultBase(Seg)" returns different results from the same input on x86 and arm, i'll try to investigate further later today.

I'm a dummy for assuming that, oops :)

you're on the right track though, that's exactly how I'd debug it.

I just looked at nec_intf.cpp:
Code: [Select]
// Handlers
 #ifdef FASTCALL
UINT8 (__fastcall *ReadHandler)(UINT32 a);
void (__fastcall *WriteHandler)(UINT32 a, UINT8 d);
UINT8 (__fastcall *ReadPort)(UINT32 a);
void (__fastcall *WritePort)(UINT32 a, UINT8 d);
 #else
UINT8 (__cdecl *ReadHandler)(UINT32 a);
void (__cdecl *WriteHandler)(UINT32 a, UINT8 d);
UINT8 (__cdecl *ReadPort)(UINT32 a);
void (__cdecl *WritePort)(UINT32 a, UINT8 d);
 #endif

is __fastcall defined on your side?  if it isn't, try defining it in the makefile.  I know that the makefile.sdl defines __fastcall as "" (nothing), this is OK.  just make sure -DFASTCALL is in the c/g++ compiler lines somewhere and try.  (its just an idea)

best regards,
- dink
Title: Re: Need some help with my libretro port
Post by: barbudreadmon on October 13, 2016, 07:18:38 PM
I didn't have (but i have a "undef __fastcall" somewhere, same as sdl), when i try adding it, i have issues building the core :
Code: [Select]
src/cpu/m68k/m68kconf.h:222:25: erreur: expected ?=?, ?,?, ?;?, ?asm? or ?__attribute__? before ?M68KFetchByte?
 unsigned int __fastcall M68KFetchByte(unsigned int a);
                         ^
src/cpu/m68k/m68kconf.h:223:25: erreur: expected ?=?, ?,?, ?;?, ?asm? or ?__attribute__? before ?M68KFetchWord?
 unsigned int __fastcall M68KFetchWord(unsigned int a);
                         ^
src/cpu/m68k/m68kconf.h:224:25: erreur: expected ?=?, ?,?, ?;?, ?asm? or ?__attribute__? before ?M68KFetchLong?
 unsigned int __fastcall M68KFetchLong(unsigned int a);
                         ^
src/cpu/m68k/m68kconf.h:231:33: erreur: expected ?)? before ?*? token
 extern unsigned int (__fastcall *M68KReadByteDebug)(unsigned int);
                                 ^
src/cpu/m68k/m68kconf.h:232:33: erreur: expected ?)? before ?*? token
 extern unsigned int (__fastcall *M68KReadWordDebug)(unsigned int);
                                 ^
src/cpu/m68k/m68kconf.h:233:33: erreur: expected ?)? before ?*? token
 extern unsigned int (__fastcall *M68KReadLongDebug)(unsigned int);
                                 ^
src/cpu/m68k/m68kconf.h:235:25: erreur: expected ?)? before ?*? token
 extern void (__fastcall *M68KWriteByteDebug)(unsigned int, unsigned int);
                         ^
src/cpu/m68k/m68kconf.h:236:25: erreur: expected ?)? before ?*? token
 extern void (__fastcall *M68KWriteWordDebug)(unsigned int, unsigned int);
                         ^
src/cpu/m68k/m68kconf.h:237:25: erreur: expected ?)? before ?*? token
 extern void (__fastcall *M68KWriteLongDebug)(unsigned int, unsigned int);
                         ^
In file included from src/cpu/m68k/m68k.h:383:0,
                 from src/cpu/m68k/m68kcpu.h:29,
                 from src/cpu/m68k/m68kops.c:1:
src/cpu/m68k/m68kconf.h:222:25: erreur: expected ?=?, ?,?, ?;?, ?asm? or ?__attribute__? before ?M68KFetchByte?
 unsigned int __fastcall M68KFetchByte(unsigned int a);
                         ^
src/cpu/m68k/m68kconf.h:223:25: erreur: expected ?=?, ?,?, ?;?, ?asm? or ?__attribute__? before ?M68KFetchWord?
 unsigned int __fastcall M68KFetchWord(unsigned int a);
                         ^
src/cpu/m68k/m68kconf.h:224:25: erreur: expected ?=?, ?,?, ?;?, ?asm? or ?__attribute__? before ?M68KFetchLong?
 unsigned int __fastcall M68KFetchLong(unsigned int a);
                         ^
src/cpu/m68k/m68kconf.h:231:33: erreur: expected ?)? before ?*? token
 extern unsigned int (__fastcall *M68KReadByteDebug)(unsigned int);
                                 ^
src/cpu/m68k/m68kconf.h:232:33: erreur: expected ?)? before ?*? token
 extern unsigned int (__fastcall *M68KReadWordDebug)(unsigned int);
                                 ^
src/cpu/m68k/m68kconf.h:233:33: erreur: expected ?)? before ?*? token
 extern unsigned int (__fastcall *M68KReadLongDebug)(unsigned int);
                                 ^
src/cpu/m68k/m68kconf.h:235:25: erreur: expected ?)? before ?*? token
 extern void (__fastcall *M68KWriteByteDebug)(unsigned int, unsigned int);
                         ^
src/cpu/m68k/m68kconf.h:236:25: erreur: expected ?)? before ?*? token
 extern void (__fastcall *M68KWriteWordDebug)(unsigned int, unsigned int);
                         ^
src/cpu/m68k/m68kconf.h:237:25: erreur: expected ?)? before ?*? token
 extern void (__fastcall *M68KWriteLongDebug)(unsigned int, unsigned int);
Also, i noticed nec_state->sregs[0] always return 0 on arm (for rtype), while it is 16384 on x86
Title: Re: Need some help with my libretro port
Post by: barbudreadmon on October 13, 2016, 07:38:47 PM
I was able to fix the build, but same issue on arm : nec_state->sregs[0] return 0
Title: Re: Need some help with my libretro port
Post by: barbudreadmon on October 14, 2016, 02:15:04 AM
My C/C++ level is too poor to fully understand how this "nec_state->sregs[0]" is handled, i tried adding
Code: [Select]
bprintf (PRINT_NORMAL, _T("Test : %d\n"), nec_state->sregs[0]);after the nec_state_t *nec_state = blahblah in nec.cpp, to see if and when this value get filled on x86, but it seems i only get 0 on both arch. Any suggestion on what i should try to bprint ?

Edit : btw, since i'm able to build with FASTCALL either on or off, what should i use on the long term ? What's the difference ?
Title: Re: Need some help with my libretro port
Post by: dink on October 14, 2016, 08:51:16 AM
Idea:

find this in necpriv.h:
typedef enum { DS1, PS, SS, DS0 } SREGS;
typedef enum { AW, CW, DW, BW, SP, BP, IX, IY } WREGS;

change it to:
Code: [Select]
typedef enum { DS1 = 0, PS = 1, SS = 2, DS0 = 3 } SREGS;
typedef enum { AW = 0, CW = 1, DW = 2, BW = 3, SP = 4, BP = 5, IX = 6, IY = 7 } WREGS;

For now, put it back to its non-fastcall state.  and/or whenever we get a lead (like above), try both ways :)

best regards,
- dink
Title: Re: Need some help with my libretro port
Post by: barbudreadmon on October 14, 2016, 02:38:38 PM
Sadly, it didn't change anything. "DefaultBase(Seg)" keep returning 0. Those enum are related to how nec_state->sregs is handled ?

I tried to get some explanation on what's the difference between cdecl and fastcall, and i think i understood. What i don't understand is what's the difference between "_fastcall" (present in konami asterix, xexex and gijoe) and "__fastcall", if there is any difference, is that a typo ?

Also, i don't know if it could help debugging, but i know for sure https://github.com/libretro/mame2003-libretro/tree/master/src/cpu/nec and https://github.com/libretro/mame2010-libretro/tree/master/src/emu/cpu/nec implementation of nec cpu works on arm.
Title: Re: Need some help with my libretro port
Post by: barbudreadmon on October 15, 2016, 01:48:49 AM
With the following code in necinstr.c :
Code: [Select]
OP( 0x8e, i_mov_sregw ) { UINT16 src; GetModRM; src = GetRMWord(ModRM); CLKR(15,15,7,15,11,5,2,EA);
switch (ModRM & 0x38) {
case 0x00: bprintf (PRINT_NORMAL, _T("op 0x8e : DS1 : %d : %d\n"), DS1, src); Sreg(DS1) = src; break; /* mov es,ew */
case 0x08: Sreg(PS) = src; break; /* mov cs,ew */
case 0x10: Sreg(SS) = src; break; /* mov ss,ew */
case 0x18: bprintf (PRINT_NORMAL, _T("op 0x8e : DS0 : %d : %d\n"), DS0, src); Sreg(DS0) = src; break; /* mov ds,ew */
// default:   logerror("%06x: MOV Sreg - Invalid register\n",PC(nec_state));
}
nec_state->no_interrupt=1;
}
I noticed the following outputs :
on X86 :
Code: [Select]
RetroArch [libretro DEBUG] :: op 0x8e : DS1 : 0 : 49152
RetroArch [libretro DEBUG] :: op 0x8e : DS0 : 3 : 0
RetroArch [libretro DEBUG] :: op 0x8e : DS0 : 3 : 4096
RetroArch [libretro DEBUG] :: op 0x8e : DS0 : 3 : 8192
RetroArch [libretro DEBUG] :: op 0x8e : DS0 : 3 : 12288
RetroArch [libretro DEBUG] :: op 0x8e : DS0 : 3 : 12288
RetroArch [libretro DEBUG] :: op 0x8e : DS1 : 0 : 16384
RetroArch [libretro DEBUG] :: op 0x8e : DS1 : 0 : 16384
RetroArch [libretro DEBUG] :: op 0x8e : DS1 : 0 : 53248
RetroArch [libretro DEBUG] :: op 0x8e : DS1 : 0 : 55296
RetroArch [libretro DEBUG] :: op 0x8e : DS1 : 0 : 57344
RetroArch [libretro DEBUG] :: op 0x8e : DS1 : 0 : 59392
RetroArch [libretro DEBUG] :: op 0x8e : DS1 : 0 : 49152
RetroArch [libretro DEBUG] :: op 0x8e : DS1 : 0 : 51200
RetroArch [libretro DEBUG] :: op 0x8e : DS1 : 0 : 52224
RetroArch [libretro DEBUG] :: op 0x8e : DS1 : 0 : 52224
RetroArch [libretro DEBUG] :: op 0x8e : DS0 : 3 : 4096
RetroArch [libretro DEBUG] :: op 0x8e : DS1 : 0 : 51200
RetroArch [libretro DEBUG] :: op 0x8e : DS0 : 3 : 4096
RetroArch [libretro DEBUG] :: op 0x8e : DS0 : 3 : 16384
RetroArch [libretro DEBUG] :: op 0x8e : DS1 : 0 : 4096
RetroArch [libretro DEBUG] :: op 0x8e : DS1 : 0 : 53248
RetroArch [libretro DEBUG] :: op 0x8e : DS1 : 0 : 55296
RetroArch [libretro DEBUG] :: op 0x8e : DS1 : 0 : 49152
RetroArch [libretro DEBUG] :: op 0x8e : DS0 : 3 : 53248
RetroArch [libretro DEBUG] :: op 0x8e : DS0 : 3 : 53248
RetroArch [libretro DEBUG] :: op 0x8e : DS0 : 3 : 8192
RetroArch [libretro DEBUG] :: op 0x8e : DS1 : 0 : 57344
RetroArch [libretro DEBUG] :: op 0x8e : DS0 : 3 : 16384
RetroArch [libretro DEBUG] :: op 0x8e : DS1 : 0 : 16384
RetroArch [libretro DEBUG] :: op 0x8e : DS1 : 0 : 49152
RetroArch [libretro DEBUG] :: op 0x8e : DS1 : 0 : 4096
RetroArch [libretro DEBUG] :: op 0x8e : DS0 : 3 : 4096
RetroArch [libretro DEBUG] :: op 0x8e : DS1 : 0 : 16384
on ARM :
Code: [Select]
RetroArch [libretro DEBUG] :: op 0x8e : DS1 : 0 : 53248
RetroArch [libretro DEBUG] :: op 0x8e : DS1 : 0 : 55296
RetroArch [libretro DEBUG] :: op 0x8e : DS1 : 0 : 4096
RetroArch [libretro DEBUG] :: op 0x8e : DS0 : 3 : 53248
RetroArch [libretro DEBUG] :: op 0x8e : DS1 : 0 : 3
RetroArch [libretro DEBUG] :: op 0x8e : DS0 : 3 : 53248
RetroArch [libretro DEBUG] :: op 0x8e : DS0 : 3 : 53248
RetroArch [libretro DEBUG] :: op 0x8e : DS0 : 3 : 53248
RetroArch [libretro DEBUG] :: op 0x8e : DS0 : 3 : 53248
RetroArch [libretro DEBUG] :: op 0x8e : DS0 : 3 : 53248
RetroArch [libretro DEBUG] :: op 0x8e : DS0 : 3 : 53248
RetroArch [libretro DEBUG] :: op 0x8e : DS0 : 3 : 53248
RetroArch [libretro DEBUG] :: op 0x8e : DS0 : 3 : 53248
RetroArch [libretro DEBUG] :: op 0x8e : DS0 : 3 : 53248
RetroArch [libretro DEBUG] :: op 0x8e : DS0 : 3 : 53248
RetroArch [libretro DEBUG] :: op 0x8e : DS0 : 3 : 53248
RetroArch [libretro DEBUG] :: op 0x8e : DS0 : 3 : 53248
RetroArch [libretro DEBUG] :: op 0x8e : DS0 : 3 : 53248
RetroArch [libretro DEBUG] :: op 0x8e : DS0 : 3 : 53248
RetroArch [libretro DEBUG] :: op 0x8e : DS0 : 3 : 53248
RetroArch [libretro DEBUG] :: op 0x8e : DS0 : 3 : 53248
RetroArch [libretro DEBUG] :: op 0x8e : DS0 : 3 : 53248
RetroArch [libretro DEBUG] :: op 0x8e : DS0 : 3 : 53248
i notice nec_state->sregs[0] is depleting then the 0x00 case in 0x8e opcode will never run again, and nec_state->sregs[3] will start at 53248 and never change, unlike on x86.

Then i tried :
Code: [Select]
OP( 0x8e, i_mov_sregw ) { UINT16 src; GetModRM; src = GetRMWord(ModRM); bprintf(PRINT_NORMAL, _T("op 0x8e : ModRM : %d : %d\n"), ModRM, src); CLKR(15,15,7,15,11,5,2,EA);
switch (ModRM & 0x38) {
case 0x00: bprintf (PRINT_NORMAL, _T("op 0x8e : DS1 : %d : %d\n"), DS1, src); Sreg(DS1) = src; break; /* mov es,ew */
case 0x08: Sreg(PS) = src; break; /* mov cs,ew */
case 0x10: Sreg(SS) = src; break; /* mov ss,ew */
case 0x18: bprintf (PRINT_NORMAL, _T("op 0x8e : DS0 : %d : %d\n"), DS0, src); Sreg(DS0) = src; break; /* mov ds,ew */
// default:   logerror("%06x: MOV Sreg - Invalid register\n",PC(nec_state));
}
nec_state->no_interrupt=1;
}
And got the following outputs :
X86:
Code: [Select]
RetroArch [libretro DEBUG] :: op 0x8e : ModRM : 192 : 49152
RetroArch [libretro DEBUG] :: op 0x8e : DS1 : 0 : 49152
RetroArch [libretro DEBUG] :: op 0x8e : ModRM : 218 : 0
RetroArch [libretro DEBUG] :: op 0x8e : DS0 : 3 : 0
RetroArch [libretro DEBUG] :: op 0x8e : ModRM : 218 : 4096
RetroArch [libretro DEBUG] :: op 0x8e : DS0 : 3 : 4096
RetroArch [libretro DEBUG] :: op 0x8e : ModRM : 218 : 8192
RetroArch [libretro DEBUG] :: op 0x8e : DS0 : 3 : 8192
RetroArch [libretro DEBUG] :: op 0x8e : ModRM : 218 : 12288
RetroArch [libretro DEBUG] :: op 0x8e : DS0 : 3 : 12288
RetroArch [libretro DEBUG] :: op 0x8e : ModRM : 218 : 12288
RetroArch [libretro DEBUG] :: op 0x8e : DS0 : 3 : 12288
RetroArch [libretro DEBUG] :: op 0x8e : ModRM : 192 : 16384
RetroArch [libretro DEBUG] :: op 0x8e : DS1 : 0 : 16384
RetroArch [libretro DEBUG] :: op 0x8e : ModRM : 192 : 16384
RetroArch [libretro DEBUG] :: op 0x8e : DS1 : 0 : 16384
RetroArch [libretro DEBUG] :: op 0x8e : ModRM : 192 : 53248
RetroArch [libretro DEBUG] :: op 0x8e : DS1 : 0 : 53248
RetroArch [libretro DEBUG] :: op 0x8e : ModRM : 192 : 55296
RetroArch [libretro DEBUG] :: op 0x8e : DS1 : 0 : 55296
RetroArch [libretro DEBUG] :: op 0x8e : ModRM : 192 : 57344
RetroArch [libretro DEBUG] :: op 0x8e : DS1 : 0 : 57344
RetroArch [libretro DEBUG] :: op 0x8e : ModRM : 192 : 59392
RetroArch [libretro DEBUG] :: op 0x8e : DS1 : 0 : 59392
RetroArch [libretro DEBUG] :: op 0x8e : ModRM : 192 : 49152
RetroArch [libretro DEBUG] :: op 0x8e : DS1 : 0 : 49152
RetroArch [libretro DEBUG] :: op 0x8e : ModRM : 192 : 51200
RetroArch [libretro DEBUG] :: op 0x8e : DS1 : 0 : 51200
RetroArch [libretro DEBUG] :: op 0x8e : ModRM : 192 : 52224
RetroArch [libretro DEBUG] :: op 0x8e : DS1 : 0 : 52224
RetroArch [libretro DEBUG] :: op 0x8e : ModRM : 192 : 52224
RetroArch [libretro DEBUG] :: op 0x8e : DS1 : 0 : 52224
RetroArch [libretro DEBUG] :: op 0x8e : ModRM : 216 : 4096
RetroArch [libretro DEBUG] :: op 0x8e : DS0 : 3 : 4096
RetroArch [libretro DEBUG] :: op 0x8e : ModRM : 192 : 51200
RetroArch [libretro DEBUG] :: op 0x8e : DS1 : 0 : 51200
ARM :
Code: [Select]
RetroArch [libretro DEBUG] :: op 0x8e : ModRM : 192 : 53248
RetroArch [libretro DEBUG] :: op 0x8e : DS1 : 0 : 53248
RetroArch [libretro DEBUG] :: op 0x8e : ModRM : 192 : 55296
RetroArch [libretro DEBUG] :: op 0x8e : DS1 : 0 : 55296
RetroArch [libretro DEBUG] :: op 0x8e : ModRM : 192 : 4096
RetroArch [libretro DEBUG] :: op 0x8e : DS1 : 0 : 4096
RetroArch [libretro DEBUG] :: op 0x8e : ModRM : 216 : 53248
RetroArch [libretro DEBUG] :: op 0x8e : DS0 : 3 : 53248
RetroArch [libretro DEBUG] :: op 0x8e : ModRM : 192 : 3
RetroArch [libretro DEBUG] :: op 0x8e : DS1 : 0 : 3
RetroArch [libretro DEBUG] :: op 0x8e : ModRM : 216 : 53248
RetroArch [libretro DEBUG] :: op 0x8e : DS0 : 3 : 53248
RetroArch [libretro DEBUG] :: op 0x8e : ModRM : 216 : 53248
RetroArch [libretro DEBUG] :: op 0x8e : DS0 : 3 : 53248
RetroArch [libretro DEBUG] :: op 0x8e : ModRM : 216 : 53248
RetroArch [libretro DEBUG] :: op 0x8e : DS0 : 3 : 53248
RetroArch [libretro DEBUG] :: op 0x8e : ModRM : 216 : 53248
RetroArch [libretro DEBUG] :: op 0x8e : DS0 : 3 : 53248
RetroArch [libretro DEBUG] :: op 0x8e : ModRM : 216 : 53248
RetroArch [libretro DEBUG] :: op 0x8e : DS0 : 3 : 53248
RetroArch [libretro DEBUG] :: op 0x8e : ModRM : 216 : 53248
RetroArch [libretro DEBUG] :: op 0x8e : DS0 : 3 : 53248
RetroArch [libretro DEBUG] :: op 0x8e : ModRM : 216 : 53248
RetroArch [libretro DEBUG] :: op 0x8e : DS0 : 3 : 53248
RetroArch [libretro DEBUG] :: op 0x8e : ModRM : 216 : 53248
RetroArch [libretro DEBUG] :: op 0x8e : DS0 : 3 : 53248
RetroArch [libretro DEBUG] :: op 0x8e : ModRM : 216 : 53248
RetroArch [libretro DEBUG] :: op 0x8e : DS0 : 3 : 53248
RetroArch [libretro DEBUG] :: op 0x8e : ModRM : 216 : 53248
RetroArch [libretro DEBUG] :: op 0x8e : DS0 : 3 : 53248
RetroArch [libretro DEBUG] :: op 0x8e : ModRM : 216 : 53248
RetroArch [libretro DEBUG] :: op 0x8e : DS0 : 3 : 53248
RetroArch [libretro DEBUG] :: op 0x8e : ModRM : 216 : 53248
Those numbers on arm feels quite strange, do you think i'm on the right track ? Next step would be to check Wreg values ?
Title: Re: Need some help with my libretro port
Post by: barbudreadmon on October 15, 2016, 02:30:00 AM
ModRM never returning anything else than 216 or 192 on arm means Mod_RM.RM.w[ModRM] will never return anything except 0, which means only Wreg(0) is returned as GetRMWord(ModRM) on arm, unlike on x86 where it will use various Wreg(x) because values like 218, 193 or 194 are sometimes returned by ModRM. Sounds like a good culprit ?
Title: Re: Need some help with my libretro port
Post by: barbudreadmon on October 15, 2016, 04:09:10 AM
I went from getModRM to FETCH(), then to cpu_readop_arg, then to cpu_readmem20_arg, there i used the following code :
Code: [Select]
UINT8 cpu_readmem20_arg(UINT32 a)
{
a &= 0xFFFFF;

UINT8 * p = VezCurrentCPU->ppMemFetchData[ a >> VEZ_MEM_SHIFT ];
if ( p ) {
bprintf (PRINT_NORMAL, _T("cpu_readmem20_arg first a: %d, p: %d, result: %d\n"), a, p, *(p + a));
return *(p + a);
}
else {
bprintf (PRINT_NORMAL, _T("cpu_readmem20_arg second a: %d\n"), a, p, *(p + a));
return VezCurrentCPU->ReadHandler(a);
}
}
And noticed something interesting : both arch have the same "a" and "result" for the first 7 call of this function :
Code: [Select]
RetroArch [libretro DEBUG] :: cpu_readmem20_arg first a: 1048561, p: 1915506696, result: 0
RetroArch [libretro DEBUG] :: cpu_readmem20_arg first a: 1048562, p: 1915506696, result: 8
RetroArch [libretro DEBUG] :: cpu_readmem20_arg first a: 1048563, p: 1915506696, result: 0
RetroArch [libretro DEBUG] :: cpu_readmem20_arg first a: 1048564, p: 1915506696, result: 63
RetroArch [libretro DEBUG] :: cpu_readmem20_arg first a: 260098, p: 1915506696, result: 255
RetroArch [libretro DEBUG] :: cpu_readmem20_arg first a: 260099, p: 1915506696, result: 255
RetroArch [libretro DEBUG] :: cpu_readmem20_arg first a: 260101, p: 1915506696, result: 254
Then on X86, every call after the 7th stays the same as the 7th, while on arm, it goes like this :
Code: [Select]
RetroArch [libretro DEBUG] :: cpu_readmem20_arg first a: 260357, p: 1915506696, result: 0
RetroArch [libretro DEBUG] :: cpu_readmem20_arg first a: 260358, p: 1915506696, result: 128
RetroArch [libretro DEBUG] :: cpu_readmem20_arg first a: 260360, p: 1915506696, result: 66
RetroArch [libretro DEBUG] :: cpu_readmem20_arg first a: 260361, p: 1915506696, result: 0
RetroArch [libretro DEBUG] :: cpu_readmem20_arg first a: 260429, p: 1915506696, result: 209
RetroArch [libretro DEBUG] :: cpu_readmem20_arg first a: 260431, p: 1915506696, result: 1
RetroArch [libretro DEBUG] :: cpu_readmem20_arg first a: 260433, p: 1915506696, result: 255
RetroArch [libretro DEBUG] :: cpu_readmem20_arg first a: 260437, p: 1915506696, result: 202
RetroArch [libretro DEBUG] :: cpu_readmem20_arg first a: 260439, p: 1915506696, result: 255
RetroArch [libretro DEBUG] :: cpu_readmem20_arg first a: 260443, p: 1915506696, result: 3
RetroArch [libretro DEBUG] :: cpu_readmem20_arg first a: 260445, p: 1915506696, result: 123
RetroArch [libretro DEBUG] :: cpu_readmem20_arg first a: 260446, p: 1915506696, result: 0
RetroArch [libretro DEBUG] :: cpu_readmem20_arg first a: 260571, p: 1915506696, result: 211
RetroArch [libretro DEBUG] :: cpu_readmem20_arg first a: 260573, p: 1915506696, result: 17
RetroArch [libretro DEBUG] :: cpu_readmem20_arg first a: 260574, p: 1915506696, result: 235
RetroArch [libretro DEBUG] :: cpu_readmem20_arg first a: 260576, p: 1915506696, result: 5
RetroArch [libretro DEBUG] :: cpu_readmem20_arg first a: 260577, p: 1915506696, result: 0
RetroArch [libretro DEBUG] :: cpu_readmem20_arg first a: 260584, p: 1915506696, result: 0
RetroArch [libretro DEBUG] :: cpu_readmem20_arg first a: 260585, p: 1915506696, result: 208
RetroArch [libretro DEBUG] :: cpu_readmem20_arg first a: 260587, p: 1915506696, result: 192
"a" keeps increasing, leading to different results, which would mean "(Sreg(PS)<<4) + sChipsPtr->ip++" return wrong values on arm after this 7th call.

Also, i already tried replacing FETCH()/FETCHWORD() macro by :
Code: [Select]
#define FETCH() fetch(nec_state)
#define FETCHWORD() fetchword(nec_state)
as in the mame2010 nec sources i linked, it didn't change the results

I'll stop my investigation for now, i hope all those data will give you some idea, and thanks for helping me :)

Edit : By the way, my reference game for those tests is always rtype, but for this last test i confirm the same is happening with mrheli.
Edit2 : i did one last test by replacing FETCH() macro by
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; })Seems like "Sreg(PS)<<4" result is fine, but "sChipsPtr->ip" is not (keep increasing on arm while it stays the same on x86).
Title: Re: Need some help with my libretro port
Post by: barbudreadmon on October 16, 2016, 04:49:00 PM
I found the issue :cool: ! But i'm not sure how i'm supposed to deal with it :S , 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.
Title: Re: Need some help with my libretro port
Post by: dink on October 16, 2016, 08:25:42 PM
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

Title: Re: Need some help with my libretro port
Post by: barbudreadmon on October 17, 2016, 01:53:09 AM
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
Title: Re: Need some help with my libretro port
Post by: gxb on October 17, 2016, 09:48:16 AM
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.
Title: Re: Need some help with my libretro port
Post by: barbudreadmon on October 17, 2016, 10:48:02 AM
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
Title: Re: Need some help with my libretro port
Post by: gxb on October 17, 2016, 11:06:08 AM
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.
Title: Re: Need some help with my libretro port
Post by: barbudreadmon on October 17, 2016, 11:34:45 AM
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).
Title: Re: Need some help with my libretro port
Post by: barbudreadmon on October 27, 2016, 06:24:15 AM
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.
Title: Re: Need some help with my libretro port
Post by: dink on October 27, 2016, 08:14:25 AM
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
Title: Re: Need some help with my libretro port
Post by: barbudreadmon on October 27, 2016, 08:48:54 AM
Thanks !
Title: Re: Need some help with my libretro port
Post by: Arcadez on October 27, 2016, 06:32:42 PM
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.
Title: Re: Need some help with my libretro port
Post by: dink on October 27, 2016, 09:42:52 PM
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?
Title: Re: Need some help with my libretro port
Post by: barbudreadmon on October 28, 2016, 03:25:57 AM
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.
Title: Re: Need some help with my libretro port
Post by: dink on October 28, 2016, 08:35:38 AM
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)
Title: Re: Need some help with my libretro port
Post by: Arcadez on October 28, 2016, 09:10:18 AM
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.
Title: Re: Need some help with my libretro port
Post by: barbudreadmon on October 29, 2016, 12:36:49 PM
My bad, i assumed our dipswitch parser was wrong because i saw "Service Mode" as a dipswitch value for "Rematches" in armwrest, and a lot of blank/duplicate values, but after launching fba standalone, i notice the same values for the same dipswitch in armwrest, so it seems our parser is actually ok. Is there an issue in armwrest dipswitches or are those normal values ?
Title: Re: Need some help with my libretro port
Post by: barbudreadmon on November 01, 2016, 09:10:08 AM
Hello,

Mouse controls don't make much sense to me, i don't understand why we have things like "mouse x-axis", "mouse y-axis", "mouse button 1" and "mouse button 2" for player1 when we use "p2 x-axis", "p2 y-axis", "p2 fire 1" and "p2 fire 2" for player2 on the same game, or why sometimes both players will use the same "mouse x-axis", "mouse y-axis", "mouse button 1" and "mouse button 2" controls, it makes things horrible when i'm trying to handle inputs in fbalpha-libretro. So i did the following patch :
http://pastebin.com/raw/VH4B899H
There are also fixes for duplicate szInfo in quartet and ponpoko (i don't really understand how you deal with it in fba standalone, but duplicate szInfo looks like a bad thing to me, and that won't work well in fbalpha-libretro)
Title: Re: Need some help with my libretro port
Post by: dink on November 01, 2016, 01:05:05 PM
My bad, i assumed our dipswitch parser was wrong because i saw "Service Mode" as a dipswitch value for "Rematches" in armwrest, and a lot of blank/duplicate values, but after launching fba standalone, i notice the same values for the same dipswitch in armwrest, so it seems our parser is actually ok. Is there an issue in armwrest dipswitches or are those normal values ?

its actually a bug in the driver, the dip count is wrong for quite a few things d_punchout.cpp, here's a fix: http://pastebin.com/2vWuzmDX

I completely agree with you re: the mouse controls, I think they should be pX x/y-axis instead of mouse x/y-axis, but another dev disagrees with this unfortunately.

re ponpoko and quartet: looks like an oversight, oops! thanks for the heads up.  also, I found that the entry above it has the same issue (Mjleague).

best regards,
- dink
Title: Re: Need some help with my libretro port
Post by: barbudreadmon on November 01, 2016, 01:53:48 PM
I completely agree with you re: the mouse controls, I think they should be pX x/y-axis instead of mouse x/y-axis, but another dev disagrees with this unfortunately.
After trying games like loffire and lghost on standalone, i can understand part of it : having both joystick controls on the same mouse make the first boot easier.

I'll just keep in mind that i have to check and replace those mouse controls for every release ;).

Thanks again !
Title: Re: Need some help with my libretro port
Post by: barbudreadmon on November 06, 2016, 08:47:08 AM
I have an issue with donpachi on arm (and not on x86) : game segfault after i "insert coin". That did not happen with fba 0.2.97.37

My investigation so far :
- i backported my current libretro's code to fba 0.2.97.37, the game won't crash, so this seems to come from fba codebase.
- i checked for "char" variable in m68k, z80, nmk112 ans msm6295, i didn't find any that should cause an issue.
- i tried bprinting a few things in nmk112, and i got really weird results ! Just adding a few bprint in "NMK112_okibank_write" (nothing else) actually fixed the "insert coin" issue, but the game will then segfault when i "press start", as if adding those bprint actually delayed something which would not be properly initialized without those bprint.
- i tried bprinting "(sekAddress / 2) & 0x1f" and "wordValue & 0xff" in d_donpachi.cpp's "donpachiWriteWord", i got different values on arm/x86 after pressing start (i decided to keep bprint in NMK112_okibank_write for now, makes comparing output easier and both issues must be related anyway), which means musashi returns different results for both arch if i understood well, it sounded like a good start for debugging
- i ported fba 0.2.97.37's musashi to current fba (i had to disable megadrive and define bBurnUseASMCPUEmulation to do that), the game still crash.
- i played around with this bBurnUseASMCPUEmulation value (seemed to me like you changed its default value, and i thought it was kinda related to some x86 asm code), the game still crash.

Any of this ring a bell ? I'm kinda at a loss right now :/

Edit : i also tried enabling/disabling FASTCALL, and playing around with CFLAGS's "-OX"
Title: Re: Need some help with my libretro port
Post by: iq_132 on November 06, 2016, 09:34:19 AM
I have an issue with donpachi on arm (and not on x86) : game segfault after i "insert coin". That did not happen with fba 0.2.97.37

My investigation so far :
- i backported my current libretro's code to fba 0.2.97.37, the game won't crash, so this seems to come from fba codebase.
- i checked for "char" variable in m68k, z80, nmk112 ans msm6295, i didn't find any that should cause an issue.
- i tried bprinting a few things in nmk112, and i got really weird results ! Just adding a few bprint in "NMK112_okibank_write" (nothing else) actually fixed the "insert coin" issue, but the game will then segfault when i "press start", as if adding those bprint actually delayed something which would not be properly initialized without those bprint.
- i tried bprinting "(sekAddress / 2) & 0x1f" and "wordValue & 0xff" in d_donpachi.cpp's "donpachiWriteWord", i got different values on arm/x86 after pressing start (i decided to keep bprint in NMK112_okibank_write for now, makes comparing output easier and both issues must be related anyway), which means musashi returns different results for both arch if i understood well, it sounded like a good start for debugging
- i ported fba 0.2.97.37's musashi to current fba (i had to disable megadrive and define bBurnUseASMCPUEmulation to do that), the game still crash.
- i played around with this bBurnUseASMCPUEmulation value (seemed to me like you changed its default value, and i thought it was kinda related to some x86 asm code), the game still crash.

Any of this ring a bell ? I'm kinda at a loss right now :/

Edit : i also tried enabling/disabling FASTCALL, and playing around with CFLAGS's "-OX"
I added an updated Bankswitching system to the MSM6295. I'm going to guess that the problem lies there. :(
Title: Re: Need some help with my libretro port
Post by: barbudreadmon on November 06, 2016, 12:53:08 PM
I added an updated Bankswitching system to the MSM6295. I'm going to guess that the problem lies there. :(
I confirm, speedspn which uses the same msm6295 have the same issue.
Title: Re: Need some help with my libretro port
Post by: barbudreadmon on November 06, 2016, 01:39:10 PM
I enabled debug and modfied this :
Code: [Select]
static inline UINT8 MSM6295ReadData(INT32 nChip, UINT32 nAddress)
{
bprintf(PRINT_ERROR, _T("MSM6295ReadData begin\n"));
nAddress &= 0x3ffff;

if (pBankPointer[nChip][(nAddress >> 8)]) {
bprintf(PRINT_ERROR, _T("MSM6295ReadData 1 : %d\n"), pBankPointer[nChip][(nAddress >> 8)][(nAddress & 0xff)]);
return pBankPointer[nChip][(nAddress >> 8)][(nAddress & 0xff)];
} else {
bprintf(PRINT_ERROR, _T("MSM6295ReadData 2\n"));
return 0;
}
bprintf(PRINT_ERROR, _T("MSM6295ReadData end\n"));
}
it crash after "MSM6295ReadData begin" so i guess
Code: [Select]
pBankPointer[nChip][(nAddress >> 8)][(nAddress & 0xff)]is undefined or something ?

Edit : i confirm always returning 0 solve this issue, except i have no sound :/
Title: Re: Need some help with my libretro port
Post by: iq_132 on November 06, 2016, 02:01:51 PM

try nAddress / 256 instead of >> 8
Title: Re: Need some help with my libretro port
Post by: barbudreadmon on November 06, 2016, 02:15:08 PM
Same issue, i think
Code: [Select]
pBankPointer[nChip][(nAddress >> 8)] exists, it is
Code: [Select]
pBankPointer[nChip][(nAddress >> 8)][(nAddress & 0xff)] that doesn't seem to exist
Title: Re: Need some help with my libretro port
Post by: iq_132 on November 06, 2016, 04:07:38 PM
Same issue, i think
Code: [Select]
pBankPointer[nChip][(nAddress >> 8)] exists, it is
Code: [Select]
pBankPointer[nChip][(nAddress >> 8)][(nAddress & 0xff)] that doesn't seem to exist

I think the problem lies here:

   memset (pBankPointer[nChip], 0, 0x40000/0x100);

try:

   memset (pBankPointer[nChip], 0, (0x40000/0x100) * sizeof(UINT8*));
Title: Re: Need some help with my libretro port
Post by: barbudreadmon on November 06, 2016, 04:24:39 PM
Still no luck :/
I'll try to investigate more tomorrow, perhaps some more output with bprint would help figure out what's happening.
Title: Re: Need some help with my libretro port
Post by: dink on November 06, 2016, 07:24:15 PM
Can you analyze the crash and find which code is causing it?  I know in windows we have DrMingw, which is an amazing tool for finding crash problems.  I'm sure there's something similar for arm, perhaps?

best regards,
- dink
Title: Re: Need some help with my libretro port
Post by: barbudreadmon on November 07, 2016, 09:00:46 AM
i got the same result through gdb :
Code: [Select]
Program received signal SIGSEGV, Segmentation fault.
0x7310656c in MSM6295ReadData (nAddress=<optimized out>, nChip=1)
    at src/burn/snd/msm6295.cpp:73
73 return pBankPointer[nChip][(nAddress >> 8)][(nAddress & 0xff)];
Title: Re: Need some help with my libretro port
Post by: barbudreadmon on November 07, 2016, 10:43:45 AM
Better when built with -O0 :
Code: [Select]
0x729025c4 in MSM6295ReadData (nChip=1, nAddress=72)
    at src/burn/snd/msm6295.cpp:73
73 return pBankPointer[nChip][(nAddress >> 8)][(nAddress & 0xff)];
Title: Re: Need some help with my libretro port
Post by: barbudreadmon on November 07, 2016, 11:20:14 AM
Even better, which a breakpoint at this line and some print :
Code: [Select]
Breakpoint 1, MSM6295ReadData (nChip=1, nAddress=72)
    at src/burn/snd/msm6295.cpp:73
73 return pBankPointer[nChip][(nAddress >> 8)][(nAddress & 0xff)];
(gdb) print nChip
$1 = 1
(gdb) print (nAddress >> 8)
$2 = 0
(gdb) print (nAddress & 0xff)
$3 = 72
(gdb) print pBankPointer[nChip][(nAddress >> 8)][(nAddress & 0xff)]
Cannot access memory at address 0x3020448
Title: Re: Need some help with my libretro port
Post by: Barry Harris on November 07, 2016, 11:59:52 AM
nAddress is a UINT32.

Instead of;

Code: [Select]
(nAddress >> 8)
try;

Code: [Select]
((nAddress & 0xffff) >> 8)
Title: Re: Need some help with my libretro port
Post by: barbudreadmon on November 07, 2016, 02:24:27 PM
Still the same issue/values, i also tried to print the following values :
Code: [Select]
(gdb) print pBankPointer[nChip][((nAddress & 0xff) >> 8)]
$5 = (UINT8 *) 0x3020400 <error: Cannot access memory at address 0x3020400>
(gdb) print pBankPointer[nChip][1]
$7 = (UINT8 *) 0x72120500 "\n\001\222\032\202\300\036\201\260J5\004\062C\"0\211\312λ\273\274\260\251\061\026\023Q\"\023  \201\211\t\271\253\253\272\273\253\230\201\021\064%\"32\020\211\212\253ʺʩ\250\t\"\223#J\202\252.\263\311\071\247\001Q\022!(\211\255\254ʻ\252\261\211b\003AQ\002"
(gdb) print pBankPointer[nChip][2]
$8 = (UINT8 *) 0x72040600 "\003\002\002\002\002\002\003\003"
Seems to me like anything else than "pBankPointer[nChip][1]" and "pBankPointer[nChip][2]" will return the same "Cannot access memory at address 0x3020400".
Also, i mentioned :
Quote
- i tried bprinting a few things in nmk112, and i got really weird results ! Just adding a few bprint in "NMK112_okibank_write" (nothing else) actually fixed the "insert coin" issue, but the game will then segfault when i "press start", as if adding those bprint actually delayed something which would not be properly initialized without those bprint.
Could this pBankPointer pointer be filled by another process, which "doesn't run fast enough" ?
Title: Re: Need some help with my libretro port
Post by: dink on November 07, 2016, 05:52:58 PM
Try some debug code in nmk112.cpp to see what's getting mapped, then we can see why its not getting mapped. (might have to change all %X to %x depending on compiler).  Then post the log here, I'll compare it with mine.
Title: Re: Need some help with my libretro port
Post by: barbudreadmon on November 08, 2016, 02:38:26 PM
Here is the output when i press nothing (game will crash after a few seconds when the game reach the title screen) :
Code: [Select]
RetroArch [libretro DEBUG] :: chip 0 rom 72119008 start 0 end FFFF
RetroArch [libretro DEBUG] :: chip 0 rom 72119008 start 10000 end 1FFFF
RetroArch [libretro DEBUG] :: chip 0 rom 72119008 start 20000 end 2FFFF
RetroArch [libretro DEBUG] :: chip 0 rom 72119008 start 30000 end 3FFFF
RetroArch [libretro DEBUG] :: chip 1 rom 72019408 start 400 end FFFF
RetroArch [libretro DEBUG] :: chip 1 rom 72019008 start 0 end FF
RetroArch [libretro DEBUG] :: chip 1 rom 72019008 start 10000 end 1FFFF
RetroArch [libretro DEBUG] :: chip 1 rom 72019108 start 100 end 1FF
RetroArch [libretro DEBUG] :: chip 1 rom 72019008 start 20000 end 2FFFF
RetroArch [libretro DEBUG] :: chip 1 rom 72019208 start 200 end 2FF
RetroArch [libretro DEBUG] :: chip 1 rom 72019008 start 30000 end 3FFFF
RetroArch [libretro DEBUG] :: chip 1 rom 72019308 start 300 end 3FF
RetroArch [libretro DEBUG] :: chip 0 rom 72119008 start 0 end FFFF
RetroArch [libretro DEBUG] :: chip 0 rom 72119008 start 10000 end 1FFFF
RetroArch [libretro DEBUG] :: chip 0 rom 72119008 start 20000 end 2FFFF
RetroArch [libretro DEBUG] :: chip 0 rom 72119008 start 30000 end 3FFFF
RetroArch [libretro DEBUG] :: chip 1 rom 72019408 start 400 end FFFF
RetroArch [libretro DEBUG] :: chip 1 rom 72019008 start 0 end FF
RetroArch [libretro DEBUG] :: chip 1 rom 72019008 start 10000 end 1FFFF
RetroArch [libretro DEBUG] :: chip 1 rom 72019108 start 100 end 1FF
RetroArch [libretro DEBUG] :: chip 1 rom 72019008 start 20000 end 2FFFF
RetroArch [libretro DEBUG] :: chip 1 rom 72019208 start 200 end 2FF
RetroArch [libretro DEBUG] :: chip 1 rom 72019008 start 30000 end 3FFFF
RetroArch [libretro DEBUG] :: chip 1 rom 72019308 start 300 end 3FF
RetroArch [libretro DEBUG] :: chip 1 rom 72020108 start 10000 end 1FFFF
RetroArch [libretro DEBUG] :: chip 1 rom 72020208 start 100 end 1FF
RetroArch [libretro DEBUG] :: chip 1 rom 72020108 start 10000 end 1FFFF
RetroArch [libretro DEBUG] :: chip 1 rom 72020208 start 100 end 1FF
RetroArch [libretro DEBUG] :: chip 1 rom 72020108 start 10000 end 1FFFF
RetroArch [libretro DEBUG] :: chip 1 rom 72020208 start 100 end 1FF
RetroArch [libretro DEBUG] :: chip 1 rom 72010500 start 400 end FFFF
RetroArch [libretro DEBUG] :: chip 1 rom 72010100 start 0 end FF
RetroArch [libretro DEBUG] :: chip 1 rom 72050400 start 10000 end 1FFFF
RetroArch [libretro DEBUG] :: chip 1 rom 72050500 start 100 end 1FF
RetroArch [libretro DEBUG] :: chip 1 rom 72040400 start 20000 end 2FFFF
RetroArch [libretro DEBUG] :: chip 1 rom 72040600 start 200 end 2FF
RetroArch [libretro DEBUG] :: chip 1 rom 3050400 start 30000 end 3FFFF
RetroArch [libretro DEBUG] :: chip 1 rom 3050700 start 300 end 3FF
RetroArch [libretro DEBUG] :: chip 1 rom 3020800 start 400 end FFFF
RetroArch [libretro DEBUG] :: chip 1 rom 3020400 start 0 end FF
"rom" value seems strange.
Title: Re: Need some help with my libretro port
Post by: dink on November 08, 2016, 03:07:45 PM
Yea, the last couple values are funky, hrm,  lets see here....
Title: Re: Need some help with my libretro port
Post by: dink on November 08, 2016, 03:39:48 PM
in d_donpachi.cpp function LoadRoms(), check the return values for BurnLoadRom() for the samples:
// Load MSM6295 ADPCM data
INT32 rc =BurnLoadRom(MSM6295ROM + 0x000000, 6, 1); // OKI #1 ONLY
bprintf(0, _T("loadrom  0 rc = %d"), rc);
rc = BurnLoadRom(MSM6295ROM + 0x100000, 7, 1); // OKI #0 & #1
bprintf(0, _T("loadrom  1 rc = %d"), rc);

If they seem OK, try putting tons of debug code in nmk112.cpp to see where those odd addresses (3050400 etc) are coming from, for example put debug code in NMK112_init() also.

best regards,
- dink
Title: Re: Need some help with my libretro port
Post by: dink on November 08, 2016, 10:22:31 PM
I see a problem in nmk112.cpp, there's a bit of an out-of-bounds issue.

see:
d_donpachi.cpp:
Code: [Select]
case 0xB00020:
case 0xB00021:
case 0xB00022:
case 0xB00023:
case 0xB00024:
case 0xB00025:
case 0xB00026:
case 0xB00027:
case 0xB00028:
case 0xB00029:
case 0xB0002A:
case 0xB0002B:
case 0xB0002C:
case 0xB0002D:
case 0xB0002E:
case 0xB0002F: {
NMK112_okibank_write((sekAddress / 2) & 0x1f, byteValue);
break;
}

and nmk112.cpp in devices:
Code: [Select]
static UINT8 page_mask;
static UINT8 current_bank[8];
static UINT32 romlen[2];
static UINT8 *romdata[2];

void NMK112_okibank_write(INT32 offset, UINT8 data)
{
current_bank[offset] = data;

explanation: current_bank is overflowing into the romlen and romdata variables, corrupting them.

try: edit: don't do this - see next message!
static UINT8 current_bank[8]; -> static UINT8 current_bank[0x20];

best regards,
- dink
Title: Re: Need some help with my libretro port
Post by: dink on November 08, 2016, 10:39:10 PM
Sorry, I'm wrong about the error being in nmk112.cpp.  The problem is definitely happening in nmk112.cpp by an overflow of the variable array, but, the overflow & bug is coming from d_donpachi.cpp.
find: (hint, there are 2 occurrences of this)
NMK112_okibank_write((sekAddress / 2) & 0x1f, byteValue);

replace with: (0x1f -> 0x07)
NMK112_okibank_write((sekAddress / 2) & 0x07, byteValue);

edit: funny trivia: my inputs kept getting corrupted when I played Donpachi.  I was starting to think that fixing this was impossible, but, I'm happy to say this solved the problem for me. yay!
edit #2: don't forget to revert your nmk112.cpp back to the release version.

best regards,
- dink
Title: Re: Need some help with my libretro port
Post by: barbudreadmon on November 08, 2016, 11:01:49 PM
Thanks, that fixed it :). I'll check if i can find something similar in speedspn.

Edit: Nevermind, someone reported speedspn having the same issue as donpachi (actually the same guy reported both), but i don't have his issue so i think it's setup related.
Title: Re: Need some help with my libretro port
Post by: dink on November 08, 2016, 11:35:35 PM
awesome, glad it worked out!

regarding speedspn, it doesn't have any sounds on my side, so there definitely is something wrong here.  I will look into it tomorow (its getting late).  also the sounds work fine an old fba binary. hrmm.

best regards,
- dink
Title: Re: Need some help with my libretro port
Post by: barbudreadmon on November 09, 2016, 01:29:42 AM
My bad, there does seem to be an issue with speedspn, the following crash will happen when not built with "-DFBA_DEBUG" :
Code: [Select]
Program received signal SIGSEGV, Segmentation fault.
0x00007fffdcec8a90 in MSM6295Command (nChip=0, nCommand=2 '\002') at src/burn/snd/msm6295.cpp:396
396 nSampleStart  = MSM6295ReadData(nChip, (MSM6295[nChip].nSampleInfo & 0x03ff) + 0) << 17;
The crash happen on my x86 (_64) too.
Title: Re: Need some help with my libretro port
Post by: dink on November 09, 2016, 08:18:06 AM
For SpeedSpin:
in oki_setbank() replace the SetBank() call with:
   MSM6295SetBank(0, DrvSndROM + ((data & 3) * 0x20000), 0x20000, 0x3ffff);
in DrvInit() under MSM6295Init() add a new line:
   MSM6295SetBank(0, DrvSndROM, 0, 0x3ffff);
Title: Re: Need some help with my libretro port
Post by: barbudreadmon on November 09, 2016, 02:31:16 PM
Fixed, thanks :)
Title: Re: Need some help with my libretro port
Post by: dink on November 09, 2016, 08:23:20 PM
you're welcome :)
Title: Re: Need some help with my libretro port
Post by: barbudreadmon on November 12, 2016, 02:44:14 AM
Following the discussion on dipswitches from 2 weeks ago, the author of dipswitch handling on fbalpha-libretro applied the following patch to dataeast/actfancr and pre90s/snk because he thinks there is something wrong : https://github.com/libretro/fbalpha/commit/21c7f77a1c8b4de368299882985f19982c3682a2.patch
Title: Re: Need some help with my libretro port
Post by: dink on November 12, 2016, 08:44:15 AM
RE: Dips, he's right.  sometimes while we're writing a driver things get overlooked, thanks very much for the patches.
edit: actually theres a lot more broken dips in there, I went through and checked them all and fixed them.  here's the updates...

best regards,
- dink
Title: Re: Need some help with my libretro port
Post by: barbudreadmon on November 12, 2016, 09:46:54 AM
edit: actually theres a lot more broken dips in there, I went through and checked them all and fixed them.  here's the updates...
I'm not surprised, the games he fixed was from a short list of suspicious games i mentioned while checking for dipswitch issues.
Thanks for the updates :).
Title: Re: Need some help with my libretro port
Post by: barbudreadmon on November 13, 2016, 02:33:57 AM
fbalpha-libretro now output some debug information when something goes wrong while parsing dipswitches (https://github.com/libretro/fbalpha/commit/912777ba73c14cc64fa6d103d44e5ec8a644b454), i wrote some batch script to run all arcade games and collect those output, here it is if you are interested :
http://pastebin.com/raw/iixAc50n