Flycast: Make libretro reicast work on ARM (iOS/Android) and 32bit PC [$220 awarded]

[twinaphex]

Related to these issues -

https://github.com/libretro/reicast-emulator/issues/11

https://github.com/libretro/reicast-emulator/issues/6

What we expect in order for this bounty to be considered fulfilled:

1. It has to work on ARM Linux with the dynarec.
2. Make it work for 32bit PC. Making it work on either Windows or Linux is enough and would be considered enough for this requirement to be fulfilled..

---

The $220 bounty on this issue has been claimed at Bountysource.

[MastaG]

I'm adding in an extra 50 euros just for the libretro ARM dynarec port.
With the only conditions being that audio is working and we don't need to configure our input controls separately just for reicast.

Keep in mind reicast can already be built for ARM Linux as a standalone binary supporting everything (including sound and rumble support).

FTR, recalbox is already shipping reicast for RetroArch using wrapper scripts.
See: https://github.com/recalbox/recalbox-buildroot/tree/master/package/reicast

[twinaphex]

@MastaG Hi there, cool to see your support.

Let me know when the 50 Euros has been added, I will then retweet it and draw some further attention to it.

[MastaG]

Done :)
Its 70 bucks now.
I hope somebody finds the time.
This would bring dreamcast emulation to a lot of devices.
Also keep in mind reicast is running very very well on ARM already.

[hizzlekizzle]

I made a forum thread to discuss this issue and bounty, as well:
https://forums.libretro.com/t/make-reicast-work-on-arm-and-32-bit-pc/9969

[tabnk]

Nice :)

[alegag]

Did some fixes related to ARM this weekend (see PR #14), but not working on my ARMv7.

I've added to the bounty too, looking forward playing my DC games on my XU4 ;-)

[tabnk]

Hopefully $220 can attract developers to fix 32bit build for PC :)

[gizmo98]

I added a rpi patch https://github.com/libretro/reicast-emulator/pull/18 but i have no clue why i get this error message:

Applying dynarec type hack.
Using Recompiler
Sh4 Reset
Get MemPtr unsupported area : addr=0xA0000000
SIGSEGV @ 0x762a00a4 (signal_handler + 0x0x234ef44) ... 0x762a00a4 -> was not in vram
[libretro INFO] Fatal error : segfault
 in signal_handler -> core/libretro/common.cpp : 389 
DEBUGBREAK!

I also added platform specific versions of ngen_AllocateBlock with arm DynaRBI::Relink()
https://github.com/gizmo98/reicast-emulator/commit/11eca7ce75519cbf83130166b70ec773df4e38eb but the problem persists.

[bassdr]

I have a very similar issue on linux x86_64. SEGFAULT when loading at 0xA0000000 ... should it word on x64 PCs before porting it to arm/x86?

[alegag]

I've seen issues on the main reicast branch about x86_64 problems,
including speed, you should try to compile in 32bits, it's suppose to work
fine (unless your OS is not multilib and don't run 32bits code).

On Sep 12, 2017 21:42, "David Racine" [e-mail] wrote:

I have a very similar issue on linux x86_64. SEGFAULT when loading at
0xA0000000 ... should it word on x64 PCs before porting it to arm/x86?

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/libretro/reicast-emulator/issues/12#issuecomment-329032364,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AUP7h0fQuY9YI9_m0VIPk57P-Z_XRxvCks5shzL5gaJpZM4Mvl8o
.

[bassdr]

Thanks @alegag for the info.
My OS does support multilib, I had to compile both retroarch and reicast_libretro in 32bits... and I did a few tests:

• Both 32 bits and 64 bits give an error Get MemPtr unsupported area : addr=0xA0000000 and crashes right after
  Thread 1 "retroarch" received signal SIGSEGV, Segmentation fault. 0xecbb7d72 in bm_GetCode (addr=2684354560) at core/hw/sh4/dyna/blockmanager.cpp:76 76 return (DynarecCodeEntryPtr)FPCA(addr);
• I also compiled upstream reicast-emulator from their master branch, both 32 and 64 bits, and bad news, this one also gives the same Get MemPtr unsupported area : addr=0xA0000000. gdb also catches many SIGSEGV but the program seem to stay alive after, but the window stays black.
  Thread 1 "reicast.elf" received signal SIGSEGV, Segmentation fault. 0x0000000000aad7ff in bm_GetCode(unsigned int) () at /usr/lib/gcc/x86_64-pc-linux-gnu/5.4.0/include/g++-v5/bits/stl_algo.h:1823 1823 while (__comp(__val, __next)) (gdb) bt #0 0x0000000000aad7ff in bm_GetCode(unsigned int) () at /usr/lib/gcc/x86_64-pc-linux-gnu/5.4.0/include/g++-v5/bits/stl_algo.h:1823 #1 0x0000000000ab7bb3 in ngen_mainloop (v_cntx=0x7fffd3520000) at ../../core/rec-x64/rec_x64.cpp:50 #2 0x00000000004ab888 in recSh4_Run () at ../../core/hw/sh4/dyna/driver.cpp:91 #3 0x0000000000408dc6 in main (argc=2, argv=0x7fffffffd518) at ../../core/linux-dist/main.cpp:467

This is the same crash again. bm_GetCode() seems to be the reason of the segmentation fault... and comes from upstream reicast-emulator. Someone reported something similar, see https://github.com/reicast/reicast-emulator/issues/865

[gizmo98]

Can someone test this branch with a 32bit PC?
https://github.com/gizmo98/reicast-emulator/commits/patch-6

[bassdr]

@gizmo98 You branch does not link on x86 (x86_64 building with -m32 everywhere).

core/rec.o:(.bss+0x4): multiple definition of `ngen_FailedToFindBlock'
core/rec-x86/rec_x86_asm.o:(.data.rel+0x0): first defined here
/usr/lib/gcc/x86_64-pc-linux-gnu/5.4.0/../../../../x86_64-pc-linux-gnu/bin/ld: core/rec-x86/rec_lin86_asm.o: warning: relocation in readonly section `.text'
/usr/lib/gcc/x86_64-pc-linux-gnu/5.4.0/../../../../x86_64-pc-linux-gnu/bin/ld: warning: creating a DT_TEXTREL in a shared object.
collect2: error: ld returned 1 exit status
make: *** [Makefile:561: reicast_libretro.so] Error 1

[gizmo98]

@bassdr please pull latest update and try again.

[bassdr]

@gizmo98 It compiles and link, still crashes when loading. BTW my test game is 'Soul Calibur (USA)[DCCM].cdi'.

Linux paging: 00001000 00001000 00000FFF
MAP 00800000 w/ 25165824
MAP 20000000 w/ 25165824
MAP 04000000 w/ 16777216
MAP 06000000 w/ 16777216
MAP 0C000000 w/ 0
A8
vmem reserve: base: 0xb8700000, aram: 0xd8700000, vram: 0xbc700000, ram: 0xc4700000
Resetting mem
*** Error in `/home/david/projects/libretro/retroarch/retroarch': free(): invalid pointer: 0xd8884008 ***

(gdb) bt
#0  0xf7fd8ae9 in __kernel_vsyscall ()
#1  0xf5d33749 in __GI_raise (sig=6) at ../sysdeps/unix/sysv/linux/raise.c:54
#2  0xf5d34c07 in __GI_abort () at abort.c:89
#3  0xf5d6e380 in __libc_message (do_abort=2, fmt=0xf5e5fb3c "*** Error in `%s': %s: 0x%s ***\n") at ../sysdeps/posix/libc_fatal.c:175
#4  0xf5d74357 in malloc_printerr (action=<optimized out>, str=0xf5e5c6ff "free(): invalid pointer", ptr=<optimized out>, 
    ar_ptr=0xf5ead760 <main_arena>) at malloc.c:5004
#5  0xf5d74b11 in _int_free (av=<optimized out>, p=<optimized out>, have_lock=<optimized out>) at malloc.c:3865
#6  0x081605a5 in png_reverse_filter_adam7_iterate (data_=<optimized out>, ihdr=<optimized out>, pngp=<optimized out>)
    at libretro-common/formats/png/rpng.c:721
#7  png_reverse_filter_adam7 (data_=<optimized out>, ihdr=<optimized out>, pngp=<optimized out>) at libretro-common/formats/png/rpng.c:735
#8  png_reverse_filter_iterate (rpng=<optimized out>, data=<optimized out>) at libretro-common/formats/png/rpng.c:765
#9  rpng_process_image (rpng=<optimized out>, _data=<optimized out>, size=<optimized out>, width=<optimized out>, height=<optimized out>)
    at libretro-common/formats/png/rpng.c:1106
#10 0x08174634 in image_transfer_process (data=<optimized out>, type=<optimized out>, buf=<optimized out>, len=24538, width=0xf307f248, 
    height=0xf307f244) at libretro-common/formats/image_transfer.c:218
#11 0x0806ab8b in task_image_process (image=<optimized out>, width=<optimized out>, height=<optimized out>) at tasks/task_image.c:93
#12 task_image_iterate_process_transfer (image=<optimized out>) at tasks/task_image.c:136
#13 task_image_load_handler (task=<optimized out>) at tasks/task_image.c:227
#14 0x0806a9ed in task_file_load_handler (task=0x89416c0) at tasks/task_file_transfer.c:103
#15 0x0806453d in threaded_worker (userdata=<optimized out>) at libretro-common/queues/task_queue.c:459
#16 0x08132a84 in thread_wrap (data_=0x83cd350) at libretro-common/rthreads/rthreads.c:142
#17 0xf7c9d22a in start_thread (arg=0xf307fb40) at pthread_create.c:333
#18 0xf5dec4ce in clone () at ../sysdeps/unix/sysv/linux/i386/clone.S:114
(gdb) exit

[kivutar]

Any news on this?

[rcaridade145]

A lot of crashes seem to mention 0xA0000000. That is the address to there the bios is loaded. Or better where one of the mirror for the bios must sit https://github.com/p1pkin/demul/blob/master/Memory.c

[rcaridade145]

@twinaphex Is there any CI to build this ? i mean that because the log @bassdr posted pointed to some problems at libretro-common. On the commit https://github.com/libretro/libretro-common/commit/a2e5a51fae55a62eee186af9987a16496341a251#diff-3cdf6c2957b9f9c33e12d5b84e35253a from 2018/02 those issues seem to me taken care of. Can anyone please try again @bassdr @gizmo98

[7oxicshadow]

I don't want anyone to get excited by this as it is still very early days but I have successfully built a 32bit version of Reicast on Linux (yes linux only at this moment in time).

I need someone with linux experience to test a .so file for me.

I have tried it in a virtual machine and it gets in game but wont show any picture (sound is fine). I think this will be due to a lack of drivers and the library is working as expected.

@twinaphex are you a linux user?

Can anyone recommend an easy place to upload the so file?

[7oxicshadow]

reicast_libretro.zip

Create a backup of your original file and replace it with the one above. Launch a Retroarch and cross your fingers :)

[twinaphex]

Hey, I didn't read this before @7oxicshadow - please forgive me.

I have a Linux machine but it's x86 x64 though. Let me see if I can get a 32bit Linux machine setup in the next few days - is that OK.

[rcaridade145]

@7oxicshadow what distro and hw are you running?

@twinaphex Not sure if you're familiar with https://www.osboxes.org/virtualbox-images/ not sure about 3d support

[rcaridade145]

@twinaphex updated the Makefile from my branch (https://github.com/rcaridade145/reicast-emulator/blob/master/Makefile), with some changes namely on Linux, that were present on reicast Makefile and not on LibRetro.

[blackman91]

Wow so does 7oxicshadow core works?

[7oxicshadow]

To be honest I am not sure in what I have achieved so far (if anything).

What I can tell you is that it compiles fine and definitely runs in the sense that I have game audio but I get a black screen, When the black screen is up I can't even get the retroarch menu to appear anymore. It is as if anything to do with the retroarch backend stops responding.

Given the dates of some of the reports in this thread I can't tell if I have actually fixed anything, or its just been that long since someone tried it that actually other fixes (from other contributors) have already made it get this far....

The core that I put up a little while back was built on fedora 27 but it might work on other distros.

[bparker06]

@7oxicshadow I tried your core in a 32-bit qemu VM with virgl. RetroArch otherwise works fine by itself in this VM with normal XMB working with the OpenGL driver under X. My virgl supports 3.0 compat and 3.3 core profiles, as well as ES3... I compiled RA with normal desktop GL support. Here is the log from running a DC game:

http://dpaste.com/05DW456

Basically I get a black screen always. I can hear the swirl bios boot, and then nothing. No input/sound after that, but the CPU stays very active the whole time. Trying to boot a naomi game segfaults before I even hear the bios boot.

[rcaridade145]

@bparker06 can you please try to build the current core on your qemu VM. There are been fixes to the Makefile and @flyinghead has been working like crazy on the gfx part so maybe your problem is already overcome.

[7oxicshadow]

Good news. I have a working (proof of concept) 32bit Linux Reicast core.
(Linux only at this moment in time...)

Could either @bparker06 or @twinaphex test the following .so for me:
Reicast_libretro_working_250718

I have tried it in a 32bit virtual machine but it should work fine.

[twinaphex]

Great to hear - let me try asking again.

[7oxicshadow2]

Ok. I have been working on an older build of libretro/reicast and have just attempted to merge my changes into the latest branch.

I have had to make a couple of trivial changes to get it to build but it appears that some new GL changes causes the core to sigsegv long before the dynarec gets to do anything :(

I have proven that it gets as far as the following function call:

glsm.c -> glsm_state_setup -> glGenVertexArrays(1, &gl_state.vao); //line 2613

After this I am a bit lost as GL stuff is new to me. Could @flyinghead or @twinaphex take a look to see if there is an obvious reason for this to occur?

The log shows:

Sh4 Reset
recSh4 Init
Freeing fpcb
SIGSEGV @ (nil) (signal_handler + 0x0x56a546a0) ... (inl) -> was not in vram
DEBUGBREAK!

My updated branch is here:
Github

[flyinghead]

glGenVertexArrays doesn't exist in GLES2, so it's probably a null pointer hence the SIGSEGV.

All the calls to glGenVertexArrays, glBindVertexArrays and glDeleteVertexArrays should be conditionally compiled with #ifndef HAVE_OPENGLES

[7oxicshadow2]

@flyinghead. Thanks for the advice. I did manage to get further but I suspect there are other GL calls giving me problems. Almost all of the GL calls in gl_create_resources() had to be commented out before it would progress further.

It now loads the rom but crashes again with sigsegv.
I have tried disabling both calls to dc_run() so that just the retroarch UI is being serviced but it still crashes even with that. (I know this normally works because I was exploiting that yesterday to do some debugging).

Speaking of debugging. Is there a guide on how to debug reicast anywhere? From what I have read it exploits the SIGSEGV mechanism for optimisation but as a result makes debugging with GDB incredibly difficult...

[flyinghead]

This is the libretro GL initialization so I suppose it has some issues with GLES2.

Regarding debugging just execute this, or put it in your .gdbinit file:
handle SIGSEGV nostop noprint

[twinaphex]

I haven't really paid attention yet to see if Reicast actually works with GLES2. I suppose I should do that one of these days. I know Reicast OIT definitely won't work, so you will need to use the non-OIT renderer, and then make sure HAVE_GL3 is not defined, and CORE is not defined.

Since this dynarec is meant for 32bit x86, can you just try using desktop GL instead since the main focus is on getting the 32bit dynarec to work? What was the last snapshot in time then when you actually had the 32bit dynarec working? Any github commit on your fork to point to?

[flyinghead]

Actually I thought you were building on ARM. Didn't read the issue title up to the end...
On linux x86 you shouldn't define HAVE_OPENGLES and you should probably define HAVE_GL3.

[7oxicshadow2]

The version that I have done all my testing on is the following:

github

It works fine with default build settings on that build and I assume that is using GLES2?

The commit on my branch is:
my_commit

Where does CORE get defined? I have seen HAVE_CORE?

These are the settings I have in the make file. Looking at them I suspect it is already set to use desktop GL?

DEBUG         := 0
NO_REND       := 0
HAVE_GL       := 1
HAVE_OIT      := 0
HAVE_CORE     := 0
NO_THREADS    := 1
NO_EXCEPTIONS := 0
NO_NVMEM      := 0
NO_VERIFY     := 1
HAVE_GENERIC_JIT   := 1
HAVE_GL3      := 0
FORCE_GLES    := 0
STATIC_LINKING:= 0
HAVE_TEXUPSCALE := 1

[7oxicshadow2]

This zip file is the complete source to my working version.
Just run make in a 32bit linux environment and the resulting ".so" file should work as expected:

32bit_source

Note: The lin86.s assembly file is slightly different to the one in my branch as I had to make it fit with the current code at the time of writing.

[7oxicshadow2]

In order for people to understand why we have been having problems getting 32bit builds in Libretro I will try to give a brief overview.

The non libretro build of reicast effectively starts the dynarec in an infinity loop. Once it is running there is no way of stopping (well there is but it is stubbed out). This is usable in most cases as all you have to do is close the window and execution is forced to break. It will result in a SIGSEGV error but this doesn't really cause any problems.

The Libretro build is different. It has been modified to interrupt the dynarec, process all of the retroarch stuff and then jump back in again in a controlled loop. So if it already works on 64bit why doesn't it work on 32bit? For legacy reasons the 32bit stuff has been done in assembly and is completely independent of the 64 bit and to make things worse there are 3 assembly files all doing the same thing but in a different language for each. 1 for ARM, 1 for Linux and 1 for Windows.

As I am a linux user, I have concentrated on the linux assembly first. The reality is that not only have I had to try and get my head around the assembly language, but I have also had to learn how the libretro api works so i can debug it.

So to the nitty gritty, what did I have to do to make it work?

As you may have noticed, when starting the core the entire interface just goes black and stops responding with only audio doing something. This is because the 32bit libretro build was starting the dynarec and never leaving. As it never leaves, it doesn't process any of the retroarch stuff....

I have modified the assembly so we can leave the dynarec, store any relevent PC variables and then when returning, restore everything and carry on. Just the same way the 64bit process does.

In reality, all I need to do now is modify the windows and ARM builds and it "should" work for all 32bit builds.....

[blackman91]

Genius! go collect that bounty my man.

[7oxicshadow]

Bit too soon for anything like that but we made a good start. There appears to be some issues with the latest code on 32bit at the moment to iron out.

[7oxicshadow2]

@twinaphex How are you building under a windows environment? Visual Studio? Is there a project file anywhere?

Thanks

[twinaphex]

Would this fix your GLES issues?

https://github.com/libretro/reicast-emulator/issues/188

[twinaphex]

@7oxicshadow I use mingw/msys2.

https://docs.libretro.com/compilation/windows/

[7oxicshadow]

@twinaphex Thanks for that.

I have created a windows build to test that is available here:
win_32

Note: This is built against my older build that works. I have not had time to experiment with the latest code yet. I have not been able to test it myself because retroarch just CTD everytime I open it on a windows virtual machine.

If anyone tests it, can you report back if it works or not.

Thanks.

[blackman91]

I tested it and it won't load the core when selecting it in RetroArch load core option, on windows 7 64 bit pc though. Has anyone else tested it?

[twinaphex]

@blackman91 @7oxicshadow

Tested it in 32bit Retroarch on Windows, I get this when starting a game with the core -

reios: Hardware ID is: SEGA SEGAKATANA
reios: Maker ID is: SEGA ENTERPRISES
reios: Device info is: 5B21 GD-ROM1/1
reios: Area symbols is: U
reios: Peripherals is: 07BBA10
reios: Product number is: T1401N
reios: Product version is: V1.000
reios: Release date is: 19990730
reios: Boot filename is: 1ST_READ.BIN
reios: Software company is: SEGA LC-T-14
reios: Software name is: SOULCALIBUR
reios: loading ip.bin from FAD: 45150
reios: bootfile is '1ST_READ.BIN '
reios: iso9660 PVD found
reios: iso9660 root_directory, FAD: 45170, len: 6144
Found 1ST_READ.BIN at 000093
filename len: 14
file LBA: 547203
file LEN: 3679460
* left init*
Segmentation fault

[blackman91]

@twinaphex

Have you tested the linux 32 bit build?
http://www.mediafire.com/file/4nbz088fpi11b7w/reicast_libretro_working_32bit.zip/file

[twinaphex]

I don't have a 32bit Linux configuration setup.

[7oxicshadow]

the 32 bit wimdows build isnt working. i have managed to get a working test environment. There is a function called bm_getcode(). Within it is a reasonalby simple memory read. When ever it attempts read from the variable it crashes.

It is as if it is an unintialised pointer. I am not sure but i suspect that it is related tothe vram stuff. All of the vram initialisation stuff uses a specific windows functions and i think it works differently.

[twinaphex]

I pushed some commits courtesy of @flyinghead. While I cannot get x86 compiling for 32bit Windows right now, he says it should work for Linux at least. Can anybody try that?

[blisstik]

@twinaphex I successfully compiled on my Odroid XU4 using Oroid-RetroArena v1.1 (RetroPie fork for XU4) using lr-reicast.sh from original RetroPie repo with modified make code below:

platform=odroid ARCH=arm BOARD="ODROID-XU3" make

The SO gets created but when I load the core into retroarch (without any games), I get a segmentation fault.

/path/to/retroarch -L /path/to/reicast_libretro.so

I can be a dedicated tester for 32bit ARM Linux with some guidance.

[twinaphex]

Good news, it works now for 32bit Windows!

Performance is a bit better too (tested with Soul Calibur, same stage, same settings) -

264fps - reicast 32bit libretro
201fps - reicast 64bit libretro

[7oxicshadow]

Nice Work. Out of curiosity what does the _Z10 do for the bm_getcode call? For the life of me I couldn't work out why it was failing.

For future proofing it might be worth trying to come up with a better method of referencing the PC without the need for fixed address offsets but thats not important at the moment.

[blackman91]

Nice! Does that mean it can be ported to mobile now?

[flyinghead]

_Z10bm_GetCodej is the decorated name of bm_GetCode
Not sure why this hack
But the main problem was that the win32 exception handler wasn't installed

[7oxicshadow]

@flyinghead Thanks for that. Learn something new everyday

[blisstik]

Rebuilt, using commits from today. Here's a log

Parameters: 
Executing: /opt/retropie/emulators/retroarch/bin/retroarch -L /opt/retropie/libretrocores/lr-reicast/reicast_libretro.so --config /opt/retropie/configs/dreamcast/retroarch.cfg "/home/pigaming/RetroPie/roms/dreamcast/Dolphin Blue.lst" --appendconfig /dev/shm/retroarch.cfg
/opt/retropie/supplementary/runcommand/runcommand.sh: line 1000:  2039 Segmentation fault      /opt/retropie/emulators/retroarch/bin/retroarch -L /opt/retropie/libretrocores/lr-reicast/reicast_libretro.so --config /opt/retropie/configs/dreamcast/retroarch.cfg "/home/pigaming/RetroPie/roms/dreamcast/Dolphin Blue.lst" --appendconfig /dev/shm/retroarch.cfg

[flyinghead]

Quick update:
I believe there's an upstream issue with Naomi games on arm. Last time I tried it crashed at startup. I didn't investigate but it's probably best to test with a DC game instead of a Naomi one for now.

There has been changes upstream regarding position-independent code on arm platforms. This was needed for android mainly but it affects all arm platforms. See https://github.com/reicast/reicast-emulator/commit/5525d5dde23ee28fd0241807c955f5e3cbf03371. These changes have to be backported.

Finally support for GLES2 in the renderer is currently broken: there are syntax errors in the shaders and a couple of things missing (depth_scale uniform in particular).

After fixing all these issues (and a couple more) I got the core to start properly. However, there's a GL issue remaining with some textures missing or with a wrong color. Still investigating this one.

[twinaphex]

I backported this commit now by @flyinghead -

https://github.com/reicast/reicast-emulator/commit/c0c06ed8ffc969650ce18b70050cbd314679f091

You can find that here -

https://github.com/libretro/reicast-emulator/commit/83c57d5da19b848c5aa3a3db62940bffde224b3e

I had to add a few changes to it for GL3, since we have people like @dviola that still want a build option for GL2.x cards as well.

@flyinghead Seems to me like you can go ahead now with your ARM-related commits.

[flyinghead]

This should take care of the rendering problem:
https://github.com/libretro/reicast-emulator/pull/198

[rcaridade145]

Great work @flyinghead and everyone :)

[blisstik]

Tested Crazy Taxi for Dreamcast and it loaded! Naomi games did not load.

[twinaphex]

Yeah, I think it's known about that Naomi currently has issues on ARM.

[twinaphex]

@blisstik You tested this on Odroid XU4?

[blisstik]

@twinaphex yes on an Odroid XU4 - the DC games work but some are slow fps like Virtua Tennis 2 and Crazy Taxi. Marvel vs Capcom 2 works well and other fighting games.

[twinaphex]

Some of the following can improve performance (at the expense of graphics accuracy)-

Disabling DSP
Disabling volume shadows
Disabling RTT

[twinaphex]

I will also add a frameskipping core option soon.

[Sakitoshi]

Tested on a raspberry pi 3 running retropie (up to date) and after a short while with a black screen and no sound (I suppose the emulator is trying to boot) it exits out.
Compiled the core in the raspberry pi itself using this command line:

make platform=rpi3 ARCH=arm

And this is the content of runcommand.log:

Parameters:
Executing: /opt/retropie/emulators/retroarch/bin/retroarch -L /opt/retropie/libretrocores/lr-reicast/reicast_libretro.so --config /opt/retropie/configs/dreamcast/retroarch.cfg "/home/pi/RetroPie/roms/dreamcast/GuiltyGearX.cdi" --appendconfig /dev/shm/retroarch.cfg
[reicast]: Got size: 640 x 480.
Creating dir: /home/pi/RetroPie/BIOS/dc/data
context_reset.
ARM VFP-Run Fast (NFP) enabled !
Linux paging: 00001000 00001000 00000FFF
MAP 00800000 w/ 25165824
MAP 20000000 w/ 25165824
MAP 04000000 w/ 16777216
MAP 06000000 w/ 16777216
MAP 0C000000 w/ 0
A8
vmem reserve: base: 491B0000, aram: 691b0000, vram: 4D1B0000, ram: 551B0000
Resetting mem
Mem alloc successful!Loaded /home/pi/RetroPie/BIOS/dc/dc_boot.bin as bootrom

Loaded /home/pi/RetroPie/BIOS/dc/dc_nvmem.bin as nvram

Sh4 Reset
recSh4 Init
Freeing fpcb
readm helpers: up to 6E3F2250
Shader linking: failed to link
(0 bytes), - -
DEBUGBREAK!

The same game (dreamcast version of guilty gear x) works without issues on standalone reicast.

Thanks for your hard work.

[blisstik]

@twinaphex @flyinghead @7oxicshadow

Update: I did some further testing. I realized I forgot to transfer the naomi_boot.bin into /home/pigaming/RetroPie/BIOS/dc

I launched Dolphin Blue and it WORKED!

Edit: I have not tested audio as the XU4 is connected to a monitor w/o speakers. Will update tomorrow.

[blisstik]

@twinaphex @flyinghead

The commits from 8/11 are causing an issue on the XU4

Parameters: 
Executing: /opt/retropie/emulators/retroarch/bin/retroarch -L /opt/retropie/libretrocores/lr-reicast/reicast_libretro.so --config /opt/retropie/configs/dreamcast/retroarch.cfg "/home/pigaming/RetroPie/roms/dreamcast/Dolphin Blue.lst" --appendconfig /dev/shm/retroarch.cfg
[reicast]: Got size: 640 x 480.
Creating dir: /home/pigaming/RetroPie/BIOS/dc/data
context_reset.
ARM VFP-Run Fast (NFP) enabled !
Linux paging: 00001000 00001000 00000FFF
MAP 00800000 w/ 50331648
MAP 20000000 w/ 50331648
MAP 04000000 w/ 33554432
MAP 06000000 w/ 33554432
MAP 0C000000 w/ 0
A8
vmem reserve: base: 817A0000, aram: a17a0000, vram: 857A0000, ram: 8D7A0000
Resetting mem
Mem alloc successful!Loaded /home/pigaming/RetroPie/BIOS/dc/naomi_boot.bin as bootrom

flash/nvmem is missing, will create new file...Sh4 Reset
recSh4 Init
Freeing fpcb
readm helpers: up to B1A25250
Shader: failed to compile 
0:24: S0032: no default precision defined for variable 'w'
Shader linking: failed to link 
 (47 bytes), - Link failed because of invalid fragment shader. -
VERTEX:
#version 300 es 
#define TARGET_GL GLES3 
#define pp_Gouraud 1 

#define GLES2 0 
#define GLES3 1 
#define GL2 2 
#define GL3 3 

#if TARGET_GL == GL2 
#define highp 
#define lowp 
#define mediump 
#endif 
#if TARGET_GL == GLES2 || TARGET_GL == GL2 
#define in attribute 
#define out varying 
#endif 


#if TARGET_GL == GL3 || TARGET_GL == GLES3 
#if pp_Gouraud == 0 
#define INTERPOLATION flat 
#else 
#define INTERPOLATION smooth 
#endif 
#else 
#define INTERPOLATION 
#endif 

/* Vertex constants*/  
uniform highp vec4      scale; 
uniform highp vec4      depth_scale; 
/* Vertex input */ 
in highp vec4    in_pos; 
in lowp  vec4     in_base; 
in lowp vec4     in_offs; 
in mediump vec2  in_uv; 
/* output */ 
INTERPOLATION out lowp vec4 vtx_base; 
INTERPOLATION out lowp vec4 vtx_offs; 
              out mediump vec2 vtx_uv; 
void main() 
{ 
    vtx_base=in_base; 
    vtx_offs=in_offs; 
    vtx_uv=in_uv; 
    vec4 vpos=in_pos; 
#if TARGET_GL != GLES2 && TARGET_GL != GL2 
   if (isinf(vpos.z)) 
        vpos.w = 1.18e-38; 
    else 
#endif 
        vpos.w = 1.0 / vpos.z; 
#if TARGET_GL != GLES2 
   if (vpos.w < 0.0) { 
      gl_Position = vec4(0.0, 0.0, 0.0, vpos.w); 
         return; 
   } 
   vpos.z = vpos.w; 
#else 
   vpos.z=depth_scale.x+depth_scale.y*vpos.w;  
#endif 
    vpos.xy=vpos.xy*scale.xy-scale.zw;  
    vpos.xy*=vpos.w;  
    gl_Position = vpos; 
}
FRAGMENT:
#version 300 es 
#define TARGET_GL GLES3 

#define GLES2 0 
#define GLES3 1 
#define GL2 2 
#define GL3 3 

#if TARGET_GL == GL2 
#define highp 
#define lowp 
#define mediump 
#endif 
#if TARGET_GL != GLES2 && TARGET_GL != GL2 
out highp vec4 FragColor; 
#define gl_FragColor FragColor 
#endif 

uniform lowp float sp_ShaderColor; 
/* Vertex input*/ 
void main() 
{ 
#if TARGET_GL != GLES2 
    float w = gl_FragCoord.w * 100000.0; 
   gl_FragDepth = log2(1.0 + w) / 34.0; 
#endif 
   gl_FragColor=vec4(0.0, 0.0, 0.0, sp_ShaderColor); 
}
DEBUGBREAK!

[flyinghead]

Pull Request #201 should fix the problem

[Sakitoshi]

@twinaphex @flyinghead

with the latest commits raspberry pi seems to go one step further but still doesn't boot up.

Parameters: 
Executing: /opt/retropie/emulators/retroarch/bin/retroarch -L /opt/retropie/libretrocores/lr-reicast/reicast_libretro.so --config /opt/retropie/configs/dreamcast/retroarch.cfg "/home/pi/RetroPie/roms/dreamcast/GuiltyGearX.cdi" --appendconfig /dev/shm/retroarch.cfg
[reicast]: Got size: 640 x 480.
Creating dir: /home/pi/RetroPie/BIOS/dc/data
context_reset.
ARM VFP-Run Fast (NFP) enabled !
Linux paging: 00001000 00001000 00000FFF
MAP 00800000 w/ 25165824
MAP 20000000 w/ 25165824
MAP 04000000 w/ 16777216
MAP 06000000 w/ 16777216
MAP 0C000000 w/ 0
A8
vmem reserve: base: 491A0000, aram: 691a0000, vram: 4D1A0000, ram: 551A0000
Resetting mem
Mem alloc successful!Loaded /home/pi/RetroPie/BIOS/dc/dc_boot.bin as bootrom

Loaded /home/pi/RetroPie/BIOS/dc/dc_nvmem.bin as nvram

Sh4 Reset
recSh4 Init
Freeing fpcb
readm helpers: up to 6E36E250
glGetError 0x500
Shader linking: failed to link 
 (0 bytes), -  -
VERTEX:

#define TARGET_GL GLES2 
#define pp_Gouraud 1 

#define GLES2 0 
#define GLES3 1 
#define GL2 2 
#define GL3 3 

#if TARGET_GL == GL2 
#define highp 
#define lowp 
#define mediump 
#endif 
#if TARGET_GL == GLES2 || TARGET_GL == GL2 
#define in attribute 
#define out varying 
#endif 


#if TARGET_GL == GL3 || TARGET_GL == GLES3 
#if pp_Gouraud == 0 
#define INTERPOLATION flat 
#else 
#define INTERPOLATION smooth 
#endif 
#else 
#define INTERPOLATION 
#endif 

/* Vertex constants*/  
uniform highp vec4      scale; 
uniform highp vec4      depth_scale; 
/* Vertex input */ 
in highp vec4    in_pos; 
in lowp  vec4     in_base; 
in lowp vec4     in_offs; 
in mediump vec2  in_uv; 
/* output */ 
INTERPOLATION out lowp vec4 vtx_base; 
INTERPOLATION out lowp vec4 vtx_offs; 
              out mediump vec2 vtx_uv; 
void main() 
{ 
    vtx_base=in_base; 
    vtx_offs=in_offs; 
    vtx_uv=in_uv; 
    vec4 vpos=in_pos; 
#if TARGET_GL != GLES2 && TARGET_GL != GL2 
   if (isinf(vpos.z)) 
        vpos.w = 1.18e-38; 
    else 
#endif 
        vpos.w = 1.0 / vpos.z; 
#if TARGET_GL != GLES2 
   if (vpos.w < 0.0) { 
      gl_Position = vec4(0.0, 0.0, 0.0, vpos.w); 
         return; 
   } 
   vpos.z = vpos.w; 
#else 
   vpos.z=depth_scale.x+depth_scale.y*vpos.w;  
#endif 
    vpos.xy=vpos.xy*scale.xy-scale.zw;  
    vpos.xy*=vpos.w;  
    gl_Position = vpos; 
}
FRAGMENT:

#define TARGET_GL GLES2 

#define cp_AlphaTest 1 
#define pp_ClipTestMode -1 
#define pp_UseAlpha 1 
#define pp_Texture 0 
#define pp_IgnoreTexA 0 
#define pp_ShadInstr 2 
#define pp_Offset 0 
#define pp_FogCtrl 3 
#define pp_Gouraud 1 
#define pp_BumpMap 1 
#define PI 3.1415926 

#define GLES2 0 
#define GLES3 1 
#define GL2 2 
#define GL3 3 

#if TARGET_GL == GL2 
#define highp 
#define lowp 
#define mediump 
#endif 
#if TARGET_GL == GLES3 
out highp vec4 FragColor; 
#define gl_FragColor FragColor 
#define FOG_CHANNEL a 
#elif TARGET_GL == GL3 
out highp vec4 FragColor; 
#define gl_FragColor FragColor 
#define FOG_CHANNEL r 
#else 
#define in varying 
#define texture texture2D 
#define FOG_CHANNEL a 
#endif 


#if TARGET_GL == GL3 || TARGET_GL == GLES3 
#if pp_Gouraud == 0 
#define INTERPOLATION flat 
#else 
#define INTERPOLATION smooth 
#endif 
#else 
#define INTERPOLATION 
#endif 

/* Shader program params*/ 
/* gles has no alpha test stage, so its emulated on the shader */ 
uniform lowp float cp_AlphaTestValue; 
uniform lowp vec4 pp_ClipTest; 
uniform lowp vec3 sp_FOG_COL_RAM,sp_FOG_COL_VERT; 
uniform highp float sp_FOG_DENSITY; 
uniform sampler2D tex,fog_table; 
uniform lowp float trilinear_alpha; 
/* Vertex input*/ 
INTERPOLATION in lowp vec4 vtx_base; 
INTERPOLATION in lowp vec4 vtx_offs; 
in mediump vec2 vtx_uv; 
lowp float fog_mode2(highp float w) 
{ 
   highp float z   = clamp(w * sp_FOG_DENSITY, 1.0, 255.9999); 
   highp float exp = floor(log2(z)); 
   highp float m = z * 16.0 / pow(2.0, exp) - 16.0; 
   lowp float idx = floor(m) + exp * 16.0 + 0.5; 
   highp vec4 fog_coef = texture(fog_table, vec2(idx / 128.0, 0.75 - (m - floor(m)) / 2.0)); 
   return fog_coef.FOG_CHANNEL; 
} 
void main() 
{ 
    // Clip outside the box 
    #if pp_ClipTestMode==1 
        if (gl_FragCoord.x < pp_ClipTest.x || gl_FragCoord.x > pp_ClipTest.z 
                || gl_FragCoord.y < pp_ClipTest.y || gl_FragCoord.y > pp_ClipTest.w) 
            discard; 
    #endif 
    // Clip inside the box 
    #if pp_ClipTestMode==-1 
        if (gl_FragCoord.x >= pp_ClipTest.x && gl_FragCoord.x <= pp_ClipTest.z 
                && gl_FragCoord.y >= pp_ClipTest.y && gl_FragCoord.y <= pp_ClipTest.w) 
            discard; 
    #endif 

   lowp vec4 color=vtx_base; 
    #if pp_UseAlpha==0 
        color.a=1.0; 
    #endif
    #if pp_FogCtrl==3 
        color=vec4(sp_FOG_COL_RAM.rgb,fog_mode2(gl_FragCoord.w)); 
    #endif
    #if pp_Texture==1 
    { 
      lowp vec4 texcol=texture(tex, vtx_uv); 

        #if pp_BumpMap == 1 
            float s = PI / 2.0 * (texcol.a * 15.0 * 16.0 + texcol.r * 15.0) / 255.0; 
            float r = 2.0 * PI * (texcol.g * 15.0 * 16.0 + texcol.b * 15.0) / 255.0; 
            texcol.a = clamp(vtx_offs.a + vtx_offs.r * sin(s) + vtx_offs.g * cos(s) * cos(r - 2.0 * PI * vtx_offs.b), 0.0, 1.0); 
            texcol.rgb = vec3(1.0, 1.0, 1.0);    
        #else
            #if pp_IgnoreTexA==1 
                texcol.a=1.0;    
            #endif
         color *= trilinear_alpha; 

            #if cp_AlphaTest == 1 
                if (cp_AlphaTestValue>texcol.a) discard;
            #endif  
        #endif 
      #if pp_ShadInstr==0 
      { 
         color=texcol; 
      } 
      #endif
        #if pp_ShadInstr==1 
        { 
            color.rgb*=texcol.rgb; 
            color.a=texcol.a; 
        } 
        #endif
        #if pp_ShadInstr==2 
        { 
            color.rgb=mix(color.rgb,texcol.rgb,texcol.a); 
        } 
        #endif
        #if  pp_ShadInstr==3 
        { 
            color*=texcol; 
        } 
        #endif

        #if pp_Offset==1 && pp_BumpMap == 0 
        { 
            color.rgb+=vtx_offs.rgb; 
            if (pp_FogCtrl==1) 
                color.rgb=mix(color.rgb,sp_FOG_COL_VERT.rgb,vtx_offs.a); 
        } 
        #endif
    } 
    #endif
    #if pp_FogCtrl==0 
    { 
        color.rgb=mix(color.rgb,sp_FOG_COL_RAM.rgb,fog_mode2(gl_FragCoord.w));  
    } 
    #endif
    #if cp_AlphaTest == 1 
      color.a=1.0; 
    #endif  
   //color.rgb=vec3(gl_FragCoord.w * sp_FOG_DENSITY / 128.0);
#if TARGET_GL != GLES2 
    float w = gl_FragCoord.w * 100000.0; 
    gl_FragDepth = log2(1.0 + w) / 34.0; 
#endif 
   gl_FragColor =color; 
}
DEBUGBREAK!

[flyinghead]

@Sakitoshi were you able to compile and run at this commit: 3d41e1e4baf41c3a94b6d92b4bb2ff8cd3721052 ?
Or is it a regression?

[Sakitoshi]

@flyinghead
just tested with commit 3d41e1e and nothing. tested with crazy taxi, guilty gear x and guilty gear xx ac (a naomi game).
tomorrow I'll test with a fresh installation of retropie to be sure that none of my customizations are interfering, they shouldn't, but still.
this is the crazy taxi log, but they all gave the same error.

Parameters: 
Executing: /opt/retropie/emulators/retroarch/bin/retroarch -L /opt/retropie/libretrocores/lr-reicast/reicast_libretro.so --config /opt/retropie/configs/dreamcast/retroarch.cfg "/home/pi/RetroPie/roms/dreamcast/Crazy.Taxi.(U)-NBS.cdi" --appendconfig /dev/shm/retroarch.cfg
[reicast]: Got size: 640 x 480.
Creating dir: /home/pi/RetroPie/BIOS/dc/data
context_reset.
ARM VFP-Run Fast (NFP) enabled !
Linux paging: 00001000 00001000 00000FFF
MAP 00800000 w/ 25165824
MAP 20000000 w/ 25165824
MAP 04000000 w/ 16777216
MAP 06000000 w/ 16777216
MAP 0C000000 w/ 0
A8
vmem reserve: base: 49210000, aram: 69210000, vram: 4D210000, ram: 55210000
Resetting mem
Mem alloc successful!Loaded /home/pi/RetroPie/BIOS/dc/dc_boot.bin as bootrom

Loaded /home/pi/RetroPie/BIOS/dc/dc_nvmem.bin as nvram

Sh4 Reset
recSh4 Init
Freeing fpcb
readm helpers: up to 6E439250
Shader linking: failed to link 
 (0 bytes), -  -
DEBUGBREAK!

[flyinghead]

There might be an issue with your environment then because I tested this commit on a Pi 3 and it worked for me and for others (ODROID, NES/SNES classic).

[twinaphex]

@Sakitoshi We need more context/information on that shader linking error. You might have to get a full dump of it somehow.

[Sakitoshi]

@flyinghead @twinaphex
you were right, something is wrong with my current environment. I just compiled and tested the latest commit 7191cc4 on a fresh retropie installation and it worked fine with dreamcast and naomi games, albeit slow, but runs.
guilty gear xx ac (naomi game) glitches on the first fight but having it booting up is already good enough.

[twinaphex]

@flyinghead is currently working on multithreaded GL which should hopefully considerably boost performance of reicast on ARM systems and other low powered hardware.

[blackman91]

Wow just realised that there is reicast core for Android on the online updater now, amazing job guys! you have really outdone yourselves.

The core runs on Android but I noticed performance is a lot better on flyinghead/mymaster builds for Android from here:
http://builds.reicast.com/

Is that his multithread work? It runs practically everything fullspeed, great job.

[twinaphex]

Have you enabled multithreading and restarted?

[blackman91]

Is that a core option?

How do I enable it? Also it seems if you press home or recent apps button on Android and go back to reicast it can't resume and it will crash, I think standalone reicast for Android and fh branch recently added so that doesn't happen.

[twinaphex]

Guess I need to add NO_THREADS=0 to the Android Makefile.

[blackman91]

Even NAOMI games run on the Android core, pretty sweet:

[bparker06]

@Deivmsr Please file a separate bug in the RetroArch repo.

[blackman91]

Just realised the FMVs are not showing on any game in the Android core with default settings, you can hear the sound but you get only a black screen, anyone else with this issue?

[blisstik]

@blackman91 I experience the same issue with NFL Blitz 2001 on DC. It's at the very beginning after loading. It doesn't affect gameplay.

[blackman91]

BTW if you experience laggy input when you enable threaded rendering on the Android reicast core, try changing poll type behaviour to early in RetroArch latency settings, that fixes it.

[twinaphex]

OK, so I think we can close this right?

@flyinghead Just out of courtesy, I will ask before assuming but if past correspondences are any indication you don't want this bounty right? If that is the case, would anybody mind if the bounty proceeds go to us (by me filing a submit claim)? The bounty money will then be spent on other things.

[twinaphex]

The people who pledged the money - you can let me know how it should be reallocated as - either you let us decide what to do with it, or you tell us some other issue/bounty it should go towards.

[MastaG]

@twinaphex
Split it with flyinghead (if he wants it) and just spend in on something you like.
Like coke and hookers for example ;)

Just kidding, but for me you don't have to spend it something related to libretro/emulators or something like that.

It's nothing compared to all the work you put into this.
So just take a break, buy yourself something nice or have some fun with family and friends.

But thats my opinion though :)

[twinaphex]

Yeah, I think judging by previous conversations with @flyinghead , his position on these bounties and this other stuff is clear though, so unless he had a change of mind I don't really want to press that too much. If he wants it, he can have it entirely to himself, just for the record.

So you guys just let me know indvidually how we go about reallocating this. I know what MastaG's position on this is now. That leaves @alegag and @computer28. The other bounty backer is myself.

[alegag]

If @flyinghead don't want to cash it, I'm fine for it to be relocated to any issue that would benefit a bounty!

I don't have any specific issue to assign it to myself tho'.

For me, as long as it is good for the project and the people that helps with it, I'm fine !

[flyinghead]

I confirm I don’t want any of this money. Please share it or spend it as you see fit.

[twinaphex]

OK, closing it then and submitting a claim.

[blackman91]

Great work with the Android port. Why won't fh take bounties?

Why are you so cool flyinghead? :)

[twinaphex]

@MastaG and @computer28, still need you guys to accept.

[MastaG]

@twinaphex
Accepted, sorry for the delay