RetroArch PSL1GHT port project

Zar said:
So, i gave up on building the RSXGL samples .

I just included the libs in psl1ght env and i kept on porting to psl1ght RetroArch. Just to be sure i built the core with psl1ght too (prosystem). Now i have this :

/c/PSDK3v2/ps3dev/ppu/bin/ppu-g++ -o retroarch_ps3.elf -D__CELLOS_LV2__ -D__PSL1GHT__ -L/c/PSDK3v2/ps3dev/portlibs/ppu/lib -L/c/PSDK3v2/ps3dev/ppu/lib -L/c/PSDK3v2/psl1ght/ppu/lib -L. griffin/griffin.o -lretro_ps3 -lEGL -lGL -laudio -liberty -lrsx -lgcm_sys -lnet -lio -lsysutil -lsysmodule -lm -ljpgdec -lpngdec -llv2 -lnet -lnetctl -lsdl
c:/psdk3v2/ps3dev/ppu/bin/../lib/gcc/powerpc64-ps3-elf/4.5.2/../../../../powerpc64-ps3-elf/bin/ld.exe: .\libretro_ps3.a(libretro.o): .opd is not a regular array of opd entries
c:/psdk3v2/ps3dev/ppu/bin/../lib/gcc/powerpc64-ps3-elf/4.5.2/../../../../powerpc64-ps3-elf/bin/ld.exe: .\libretro_ps3.a(Bios.o): .opd is not a regular array of opd entries
c:/psdk3v2/ps3dev/ppu/bin/../lib/gcc/powerpc64-ps3-elf/4.5.2/../../../../powerpc64-ps3-elf/bin/ld.exe: .\libretro_ps3.a(Cartridge.o): .opd is not a regular array of opd entries
c:/psdk3v2/ps3dev/ppu/bin/../lib/gcc/powerpc64-ps3-elf/4.5.2/../../../../powerpc64-ps3-elf/bin/ld.exe: .\libretro_ps3.a(Database.o): .opd is not a regular array of opd entries
c:/psdk3v2/ps3dev/ppu/bin/../lib/gcc/powerpc64-ps3-elf/4.5.2/../../../../powerpc64-ps3-elf/bin/ld.exe: .\libretro_ps3.a(Hash.o): .opd is not a regular array of opd entries
c:/psdk3v2/ps3dev/ppu/bin/../lib/gcc/powerpc64-ps3-elf/4.5.2/../../../../powerpc64-ps3-elf/bin/ld.exe: .\libretro_ps3.a(Maria.o): .opd is not a regular array of opd entries
c:/psdk3v2/ps3dev/ppu/bin/../lib/gcc/powerpc64-ps3-elf/4.5.2/../../../../powerpc64-ps3-elf/bin/ld.exe: .\libretro_ps3.a(Memory.o): .opd is not a regular array of opd entries
c:/psdk3v2/ps3dev/ppu/bin/../lib/gcc/powerpc64-ps3-elf/4.5.2/../../../../powerpc64-ps3-elf/bin/ld.exe: .\libretro_ps3.a(Palette.o): .opd is not a regular array of opd entries
c:/psdk3v2/ps3dev/ppu/bin/../lib/gcc/powerpc64-ps3-elf/4.5.2/../../../../powerpc64-ps3-elf/bin/ld.exe: .\libretro_ps3.a(Pokey.o): .opd is not a regular array of opd entries
c:/psdk3v2/ps3dev/ppu/bin/../lib/gcc/powerpc64-ps3-elf/4.5.2/../../../../powerpc64-ps3-elf/bin/ld.exe: .\libretro_ps3.a(ProSystem.o): .opd is not a regular array of opd entries
c:/psdk3v2/ps3dev/ppu/bin/../lib/gcc/powerpc64-ps3-elf/4.5.2/../../../../powerpc64-ps3-elf/bin/ld.exe: .\libretro_ps3.a(Region.o): .opd is not a regular array of opd entries
c:/psdk3v2/ps3dev/ppu/bin/../lib/gcc/powerpc64-ps3-elf/4.5.2/../../../../powerpc64-ps3-elf/bin/ld.exe: .\libretro_ps3.a(Riot.o): .opd is not a regular array of opd entries
c:/psdk3v2/ps3dev/ppu/bin/../lib/gcc/powerpc64-ps3-elf/4.5.2/../../../../powerpc64-ps3-elf/bin/ld.exe: .\libretro_ps3.a(Sally.o): .opd is not a regular array of opd entries
c:/psdk3v2/ps3dev/ppu/bin/../lib/gcc/powerpc64-ps3-elf/4.5.2/../../../../powerpc64-ps3-elf/bin/ld.exe: .\libretro_ps3.a(Tia.o): .opd is not a regular array of opd entries
​
that's the first time i see this message and google didn't help me... someone can explain me what does it mean and how i can fix this ?

PS: BTW, the elf is generated (not tested)
Click to expand...

Tbh i don't know, but the warnings while compiling can happen so i wouldn't be too worry about them especially if it compiles :P
What are you trying to do? Compiling retroarch and linking the prosystem core to the frontend?
It would be useful to can see the code if it's possible, also in pm. :)

I noticed that prosystem repo hasn't psl1ght target so i added it here. https://github.com/Ezio-PS/prosystem-libretro/commit/5524fbe2a0bbe7f7f2b589bd91584d402831813b
 
Yeah i built the prosystem lib like that too
I try to upload everything on github to show u exactly what i'm doing ..... It will be easier like that.
When I saw these message last night, i had the feeling that was doing bullshit...
 
Okay, i'm going to add the psl1ght target to the missing cores.

If you want you can join #retroarch on freenode server for a more direct comparison, though the forum remains the best choice due to its visibility.
 
Last edited:
  • Like
Reactions: Zar
@Ezio it's better to talk here. I compiled prosystem.SELF with cell SDK and it's working without issue. Then with psl1ght I had a black screen.
Can you explain me how we can debug with netlogger ?



If someone is interressed to help us. I uploaded my current version which is still in WIP.
(It took me a whole day to understand how github is working ...) : https://github.com/Zarh/RetroArch

If someone is interrested to help us. I uploaded the static lib RSXGL that u'll have to copy&paste to ur $PS3DEV directory : https://www.sendspace.com/file/01og10
then do this : http://www.psx-place.com/threads/retroarch-psl1ght-port-project.9636/#post-44100
but to build it with psl1ght use the command "./dist-cores.sh cex-psl1ght"
 
Zar said:
@Ezio it's better to talk here. I compiled prosystem.SELF with cell SDK and it's working without issue. Then with psl1ght I had a black screen.
Click to expand...
Hmm, what do you mean? Did you compile only prosystem core or the whole retroarch with prosystem core using cell sdk?
Using the code you uploaded on github i'm not anymore able to compile for dex-ps3 platform? can you do it?

Edit
It seems that replacing this https://github.com/Zarh/RetroArch/blob/master/dist-scripts/dist-cores.sh#L138 with cd../psl1ght let me compile fine with cell sdk, though i get a pkg renamed retroarch-ps3-cfw-1.3.4 when it shouldn't be renamed, looking at that now.

Edit2
Removing this 2 lines
https://github.com/Zarh/RetroArch/blob/master/dist-scripts/dist-cores.sh#L298
https://github.com/Zarh/RetroArch/blob/master/dist-scripts/dist-cores.sh#L299
it doesnt' rename the debug pkg.
Anyway i noticed it's using scetool to sign the .elf when you try to compile it with dex-ps3 flag, so it needs to be fixed, looking at it.

Edit3
Well, i fixed everything for dex-ps3, let i try it under cygwin to see if it needs those other 2 fixes i used over source code you gave me via pm.
Maybe i'll do a pull request to your fork to let you see what i fixed.
 
Last edited:
  • Like
Reactions: Zar
The error is :

PARAM.SFO: overwrite VERSION to 01.00. (from 00.01)
>> !ERROR!: ../pkg/ps3/USRDIR/EBOOT.BIN is not a supported NPDRM SELF. (SYS_PROCESS_PARAM is required)
>> !ERROR!: USRDIR/EBOOT.BIN is required.
>> !ERROR!: ../pkg/ps3/USRDIR/cores/prosystem_libretro_ps3.SELF is not an NPDRM SELF.
Illegal Package: USRDIR/EBOOT.BIN is required.
Illegal Package: Should contain at least one of NPDRM file.
​
 
Hmm, has prosystem_libretro_ps3.SELF been compiled with cell sdk? I haven't that error.
In the dex build both cores than eboot can be npdrm and they'll work. (as you know, it's not true for the cex builds).

Anyway I'll change other three little things:
https://github.com/Zarh/RetroArch/blob/master/dist-scripts/dist-cores.sh#L207
here i'll put make_self and not make_self_wc since this latest command doesn't exist in psl1ght, it has been introduced with error in the cex builds, it's just the make_self renamed to make_self_wc.

https://github.com/Zarh/RetroArch/blob/master/dist-scripts/dist-cores.sh#L140
here i'll put sh build_salamander.sh otherwise the command cannot be reknown under cygwin and under linux

https://github.com/Zarh/RetroArch/blob/master/dist-scripts/dist-cores.sh#L205
https://github.com/Zarh/RetroArch/blob/master/dist-scripts/dist-cores.sh#L297
here i'll prefer to use the compression for the fselfs and ndprm ones so you should just add -c before of the path

About debugging, you should use netcat to set up a port on 9001 or whatever the UDP port is, i think @Joonie uses it for debugging purposes on ps3.
 
Last edited:
I am not experienced with the pslight sdk's at all, but wasnt the emulateMii team doing a N64 emulator with pslight? And if so will this project bring N64 support to ps3? I have read a lot about people needing a Dyneric library for ps3 to accomplish this. And it looks like that has been available since 4.21 http://psx-scene.com/forums/content/dynarecps3-support-cfw-421-cex-dex-ingpereira-3061/. Does this mean N64 support is possible with a pslight retroarch port? Sorry for the noob question^_^
 
Death_Dealer said:
I am not experienced with the pslight sdk's at all, but wasnt the emulateMii team doing a N64 emulator with pslight? And if so will this project bring N64 support to ps3? I have read a lot about people needing a Dyneric library for ps3 to accomplish this. And it looks like that has been available since 4.21 http://psx-scene.com/forums/content/dynarecps3-support-cfw-421-cex-dex-ingpereira-3061/. Does this mean N64 support is possible with a pslight retroarch port? Sorry for the noob question^_^
Click to expand...

The dynarec is a big puzzle piece, but it does not complete the puzzle. The only emulator to support that released dynarec was the PS1 emulator that was included in Ing Pereira release there. So it takes some time and development for an emulator to support that dynarec and in most cases a significant rewrite of an emulator.
 
I added some flags to use the new libs GL & EGL see github : https://github.com/Zarh/RetroArch/commit/e75a40e92439ece1711e7a43ba955fac7a967258

It gave me the errors :
Code: 
-- Building core: prosystem --
/c/PSDK3v2/ps3dev/ppu/bin/ppu-gcc -Wall -D__CELLOS_LV2__ -D__PSL1GHT__ -I. -I/c/PSDK3v2/ps3dev/ppu/include -I/c/PSDK3v2/ps3dev/portlibs/ppu/include -I/c/PSDK3v2/psl1ght/ppu/include -I/c/PSDK3v2/psl1ght/ppu/include/simdmath -Ideps/zlib -Idefines -Ideps/zlib -Ilibretro-common/include -DHAVE_LOGGER -DHAVE_FILE_LOGGER -std=gnu99 -DSINC_LOWER_QUALITY -DHAVE_FILE_LOGGER -DHAVE_LOGGER -DHAVE_NETWORKING -DHAVE_NETPLAY -DHAVE_RGUI -DHAVE_XMB -DHAVE_MATERIALUI -DRARCH_INTERNAL -DMSB_FIRST -DHAVE_OPENGL -DHAVE_OPENGLES1 -DHAVE_OPENGL_MODERN -DHAVE_EGL -DHAVE_BB10 -DRARCH_CONSOLE -DRARCH_INTERNAL -DHAVE_MENU -DHAVE_GLSL -DGL3_PROTOTYPES -DCGGL_NO_OPENGL -DHAVE_OVERLAY -DHAVE_HEADSET -DHAVE_GCMGL -DHAVE_FBO -DHAVE_SYSMODULES -DHAVE_RARCH_EXEC -DHAVE_MOUSE  -DHAVE_ZLIB -DHAVE_RPNG -DWANT_ZLIB   -DHAVE_GRIFFIN=1 -DHAVE_SOCKET_LEGACY=1 -DPC_DEVELOPMENT_IP_ADDRESS=\""192.168.1.94"\" -DPC_DEVELOPMENT_UDP_PORT=3490 -Wno-char-subscripts -O0 -g -c -o griffin/griffin.o griffin/griffin.c
In file included from griffin/griffin.c:141:0:
griffin/../gfx/drivers_context/ps3_ctx.c: In function 'gfx_ctx_ps3_get_video_size':
griffin/../gfx/drivers_context/ps3_ctx.c:222:24: warning: unused variable 'ps3'
In file included from griffin/griffin.c:376:0:
griffin/../input/drivers_joypad/ps3_joypad.c: In function 'ps3_joypad_rumble':
griffin/../input/drivers_joypad/ps3_joypad.c:242:4: warning: enumeration value 'RETRO_RUMBLE_DUMMY' not handled in switch
griffin/griffin.c: At top level:
griffin/../gfx/drivers_context/ps3_ctx.c:59:14: warning: 'gfx_ctx_ps3_get_aspect_ratio' defined but not used
griffin/../gfx/drivers/gl.c:1647:13: warning: 'gl_pbo_async_readback' defined but not used
/c/PSDK3v2/ps3dev/ppu/bin/ppu-g++ -O3 -g -o /home/Zar/libretro-super/retroarch/retroarch_psl1ght.elf -D__CELLOS_LV2__ -D__PSL1GHT__ -L/c/PSDK3v2/ps3dev/ppu/lib     -L/c/PSDK3v2/ps3dev/portlibs/ppu/lib     -L/c/PSDK3v2/psl1ght/ppu/lib -L. griffin/griffin.o -lretro_psl1ght -lEGL -lGL -laudio -liberty -lrsx -lgcm_sys -lnet -lnetctl -lio -lsysutil -lsysmodule -lm -ljpgdec -lpngdec -llv2 -lsdl
griffin/griffin.o: In function `egl_get_proc_address':
C:\PSDK3v2\MinGW\msys\1.0\home\Zar\libretro-super\retroarch/griffin/../gfx/common/egl_common.c:64: undefined reference to `.eglGetProcAddress'
griffin/griffin.o: In function `egl_set_swap_interval':
C:\PSDK3v2\MinGW\msys\1.0\home\Zar\libretro-super\retroarch/griffin/../gfx/common/egl_common.c:146: undefined reference to `.eglSwapInterval'
collect2: ld returned 1 exit status
make: *** [/home/Zar/libretro-super/retroarch/retroarch_psl1ght] Error 1
mv: cannot stat `../CORE.SELF': No such file or directory

I checked the functions "eglSwapInterval" and "eglGetProcAddress" are in the header file but it look like they aren't in the static lib...

I tryed to comment these 2 functiun in egl_common.c (just to see if they are usefull...) and then i noticied another bug from gfx/video_driver.c => "video_driver_data = current_video->init(&video, input_get_double_ptr(), input_driver_get_data_ptr());". It go back to XMB too...


Also, I had to removed the flags -DHAVE_SYSUTIL because cellSysutilRegisterCallback make it back to xmb, i don't know why.

PS: I'm starting to give up on porting it, I'm sick and probably not enough skilled to do it :s
 
Taking in consider you linked correctly libEGL.a against it and that we compiled correctly the two static libraries since we got at least the samples working, the undefined references could come from something on the rsxgl source code, we need to understand if and why they aren't being included there.
Meanwhile i'm trying to contact gzorin to see if he get a bit of time to give us some suggestions.
 
  • Like
Reactions: Zar
Hopefully some headway is made on the project, Would be great to see this ported, but only if it were that easy. I know its a difficult task.. Been following the progression. Great work guys and appreciate the efforts
 
Been following too, read every post with interest.
I can also understand the frustration at times, getting error after error becomes daunting eventually...
Porting is not finished, nice progress was made though [emoji6]


Sent from my GT-I9305 using Tapatalk
 
Same here. If this pans out and it's all for something. It will be worth it.
One thought that everyone is probably thinking.. Nightly builds.
 
I investigated and if we remove completly remove the previous function from EGL lib, it compile without any issus, so i guess these function are unused.

But we still have a return to XMB. So, I investigated what was causing the issus inside : "current_video->init" which is in our case &video_gl. So, i commented every function that are causing a return to XMB :
https://github.com/Zarh/RetroArch/commit/25e020e2cfdb96a10f01e19f5ff3f043f97c49f3

from libGL >> gl3.h
- glBlendFunc
- glBlendEquation
- glEnable

local
- gl_set_shader_viewport
- gl_init_textures
- font_driver_init_first

and I had another one but if i remove these functions i have a black screen .

https://github.com/Zarh/RetroArch/commit/a0b145e716917656a7aac766919cc38db237650a

local
- menu_driver_ctl


Perhaps there is an issue with the libGL... I don't know.


To tell you the truth I decided to stop trying to port it to psl1ght. I've got the feeling that i'm not able to do it.


I copy/paste a message that ezio sent me in PM. It may be usefull for someone who want to work on rsxgl.

Hello,

i contacted gzorin and he confirmed me that those two undefined references are coming from some missing functions (eglGetProcAddress() and eglSwapInterval()) into rsxgl code.

eglGetProcAddress is not really important in this case so you could leave it mostly as a stub in case you can't implement it, although an actual implementation would be better ofc.

Anyway gzorin provided me some suggestions about how to implement it, basically there're two ways to do it.

It'd be implemented with the target platform's function to search a loaded executable for a function (dlsym() on unix-ish systems and GetProcAddress() on Win32), gzorin never really looked into what the equivalent function on the PS3 is, how it might work, or whether psl1ght makes it available.
Being sprx the PS3's equivalent to Linux dynamic shared objects, then the functions in the headers 'ppu/include/lv2/prx.h' or 'ppu/include/lv2/prx.h' might provide the equivalent to dlsym(), just look at the Sony's official SDK that may also provide clues as to which function provides this.

The other way to implement that function would be to take a list of all the legal OpenGL functions and, at library initialization time, build a hashmap or something that simply associates the address of each function with its name.

The lack of an implementation of eglGetProcAddress() is a big omission because many intermediate graphics libraries - things like libSDL - depend upon it.

I think the GL driver inside RetroArch only uses it for detecting certain extensions, some of those extensions you'll need to query though.
Click to expand...
 
Oh dear...
I was thinking to myself, if @Zar is giving up, thinking he doesn't have the skills to finish this port, it gives us all an idea of the project's overall level of difficulty...
Still this thread is interesting (as we mentioned before) with always new bits of information to gather...

Sent from my GT-I9305 using Tapatalk
 
i'm not rly a reference, i'm not a real dev, i'm learning to code myself as a hobby, I mean it's not my job.
I'm pretty sure that a real dev can do it :p
 
Zar said:
i'm not rly a reference, i'm not a real dev, i'm learning to code myself as a hobby, I mean it's not my job.
I'm pretty sure that a real dev can do it :p
Click to expand...
I only meant that obviously this will require fairly advanced skills as you might not be a real pro but you're not completely ignorant either.
You have proven that already with nice projects! [emoji4]

Sent from my GT-I9305 using Tapatalk
 
You must log in or register to reply here.

Similar threads

Back
Top