Openmsx 0.15 trying to compile for ps3 with cell sdk.Help needed

Page 2/2
1 |

By mth

Champion (496)

mth's picture

01-06-2020, 14:52

About the libraries that openMSX uses:

  • SDL2 would require porting, but maybe someone else already did that, since there is a lot of software out there using SDL
  • OpenGL and GLEW are optional: you only need them for the SDLGL-PP renderer
  • libogg, libtheora and libvorbis are optional: you only need them for Laserdisc emulation
  • ALSA is used only on Linux and only for MIDI, so you don't need that
  • SDL2_ttf and FreeType are used to draw text; should be easy to port
  • Tcl is used for the OSD console and scripting, but most of the UI is handled by scripting
  • zlib and libpng probably won't require much porting

I think SDL2 isn't a problem, since even if it would require porting, whether you port SDL2 or you port the graphics, input and audio inside the emulator itself would be roughly the same amount of work.

If you don't have an OpenGL implementation, openMSX would use software scaling, which should work fast enough for 3x scaling (720p) but isn't implemented for 4x scaling. So if you want 1080p output, you'd have to implement a new renderer, which is a lot of work. I don't see how we could avoid that though.

Tcl is probably the most work to port. You could try whether the Jim Interpreter is able to run the scripts included with openMSX and whether it is easier to port than the main Tcl distribution.

The problem with a lightweight core approach is that you would then need to write a launcher to allow users to select a machine and a ROM or disk image to play on it. So while porting openMSX would be easier, you'd have a lot of additional code to write to make it actually usable.

Maybe a good first step would be to install Linux on your PS3/4 and cross-compile openMSX to that, which should be fairly easy.

Also note that openMSX requires a recent C++ compiler, which should not be a problem if you're using open source toolchains that are relatively easy to upgrade. But if you're using some leaked toolchain you found floating on the net (that "SCE CONFIDENTIAL" line is a bit suspicious ;) you may not have support for modern C++.

By psxdev

Resident (38)

psxdev's picture

01-06-2020, 15:51

  • SDL already ported a part of it, however i got rid off it in bluemsx port to use my own native renderer OrbisGL2(raylib inside) GL ES 2 compliant
  • OpenGL no problem OrbisGL2 is GL ES 2 compliant orbisGL2
  • audio libraries port is not a problem for me already have audio running on fmsx and bluemsx port
  • ALSA not needed
  • i have already Freetype ported but it is heavy, orbisGL2 already have replacement inside.
  • Tcl is too much work so it is not an option for me right now. Limits commands parts would be an option perhaps
  • libpng and zlib already ported by me

I know that a lightweight approach need work but some part are already done in my fmsx and bluemsx port. We can't have exact port with all features because some are very platform dependent but i got good results with bluemsx port.

Also some physical cartridge reader stuff is done to play with my original cartridges on PS4. I published some reverse stuff to speak from libsub with old MSX GAME READER, however i would like an open hardware solution for it, if someone is interested to collaborate i am open for proposals.

Did you think about a core set of features to make easier to port for others closed embed solutions(PlayStation families, Nintendo families, XBOX families) in your roadmap?

Consoles are specials in that way, they are not windows or linux where you have all freedom to do things. I understand that main flavour right now is Windows and Linux but Console world is a good target audience.

About Sony, i only work with open solutions, so i don't use official sdk, i only can publish things made with open source toolchain based on clang and open source libraries. Right now there is 2 open flavours openorbis and orbisdev. I am only involved on orbisdev flavour and all libraries and msx ports are compliant with it and availables, and i can give support on them.

The C++ way in open toolchain must be improved and i don't know right now if i can get full support on it, so that is one of the challenges and one of the reason why i only ported fmsx and bluemsx.

About using leaked material from Sony, i am against to use or publish stuff done with that and i don't give support to that.

I promote only use open source solution, and in a few days orbisdev will be ready to do it end to end, signing and generating valid pkg, and orbislink fself loader will be published in that way, the open way.

By mth

Champion (496)

mth's picture

01-06-2020, 17:53

Currently openMSX uses the full desktop GL API instead of GL ES, but we probably don't need any functionality that isn't in GL ES. Running on GL ES is something we want to do, but just haven't had time for yet.

Compiling openMSX with Clang should work fine, we regularly test that on multiple platforms. Provided you have a recent version of Clang, that is.

Most of what we require from the C++ compiler isn't platform specific, so it should just be a matter of having an up-to-date toolchain. However, we do use threading support from STL, that might require platform-specific code if your platform doesn't provide POSIX threads.

I think looking for a simpler Tcl interpreter would be less work than changing all the existing scripts.

We always like seeing openMSX ported to more platforms and devices. At the same time, I don't think we'd want to do mayor rewrites to accomodate that. So we'll have to search for smaller changes we can make to enable ports to more systems. Things like GL ES support I mentioned earlier: that would be a relatively small change in openMSX and would open up a lot more embedded platforms.

By nikodr

Paladin (744)

nikodr's picture

01-06-2020, 22:36

I am going to create a linux system along with the open source sdks for testing.No interest in pirating or creating any sort of problems with leaked sdk.

EDITLAlready did it!So i think i have installed the PSDK3v2 thas has ps1light and everything else.I am tring to install a type of visual studio integration for the ps3 i think they made sometime ago a github with it.

so time to start and try to see what needs to be changed.I will setup the compiler paths and everything and will post any errors i have.

By nikodr

Paladin (744)

nikodr's picture

02-06-2020, 19:16

psxdev can you help by sharing some info regarding a starting point for the creation of a project for ps3 ?I have managed to compile some examples of the sdk but i am a little bit lost as to how achieve the correct management of includes needed to create a proper file in the end.Unlike the ./configure make there is still going on a lot with the needed initialization should i follow the examples of the PSDN3v2 ?

I think if the first includes about the cell ps3 platform are achieved then i could continue trying to ./configure make

By Manuel

Ascended (16974)

Manuel's picture

02-06-2020, 19:27

You don't need the cell processors for openMSX at least.

By nikodr

Paladin (744)

nikodr's picture

02-06-2020, 20:53

Well the thing is that the open source sdk of ps3 has a certain way of header files it needs in order to compile a file that will become a ps3 self or pkg executable. Certain includes and way of arranging it. I am asking psxdev for that. If I can safely create that I can try to fix the missing stuff of libraries etc and check what can be done prior to the configure make .
I will change and configure the build
Binary from x64 to ppc

By psxdev

Resident (38)

psxdev's picture

03-06-2020, 13:45

one step a time. You need a lot of work to create a custom build for platforms not already availables on openmsx build system. Don't expect configure make do the job.

Advice simplify, generate all config for linux(if you can linux under ps3) and check final requirements. I followed this approach for bluemsx on ps4(freebsd) results check https://github.com/psxdev/msxorbis.

You must see the whole picture, to decide the best way to do a port for a platform not supported. You will need to take choices and decide what is needed to change, rewrite or what parts are only need change config files for your target that it is a cross compiling environment not a classical one.

You will need a lot of little pieces, and for open c++ libraries for ps3 i don't remember status if there is some stable environment for that.

Page 2/2
1 |