Adding PS1 Core Support

[paulo101977]

• Adding PS1 Core Support
• Fixing an issue in Emulador.cpp that resulted in incorrect resolution during training/integration tool.
• Update README.md
• Adding integration to Metal Slug X on PS1

[MatPoliquin]

Incredible! Thank you very much for this

[MatPoliquin]

There is a build error in the "build tests" part because of a missing makefile:
Makefile.libretro:719: Makefile: No such file or directory
make[3]: *** No rule to make target 'Makefile'. Stop.
TARGET: pcsx_rearmed_libretro.s

[paulo101977]

There is a build error in the "build tests" part because of a missing makefile: Makefile.libretro:719: Makefile: No such file or directory make[3]: *** No rule to make target 'Makefile'. Stop. TARGET: pcsx_rearmed_libretro.s

I'll take a look here and after I fix it I'll upload the code again. But at first there was a makefile in the ps1 folder. I'll clean it and run it again.

[paulo101977]

There is a build error in the "build tests" part because of a missing makefile: Makefile.libretro:719: Makefile: No such file or directory make[3]: *** No rule to make target 'Makefile'. Stop. TARGET: pcsx_rearmed_libretro.s

When I ran cmake and it updated the Makefile, it added folders from my machine instead of relative paths. I will fix this.

[paulo101977]

@MatPoliquin I added the missing Makefile. However, I don't know if the build broke after that.

[MatPoliquin]

@MatPoliquin I added the missing Makefile. However, I don't know if the build broke after that.

I reran the build and it breaks later, here is the output from github copilot, if that is of any help:

The build is failing because make cannot find the target deps/lightning/lib/jit_disasm.o, which is required for pcsx_rearmed_libretro.so. This likely means the jit_disasm.o object file is missing or not being built as expected.

Solution Steps:

1. Check Submodule/Dependency Initialization:
   Ensure that all submodules and dependencies (especially deps/lightning) are initialized and updated before building. Add this to your workflow if missing:

   - name: Update submodules
     run: git submodule update --init --recursive

2. Verify lightning Build Rules:
   Confirm that your build system (CMake/makefiles) includes rules to build deps/lightning/lib/jit_disasm.o.

   • If you use CMake, check that deps/lightning is properly added as a subdirectory and its sources included.
   • If you use make, ensure the relevant rules are not omitted.

   Example for CMakeLists.txt:

   add_subdirectory(deps/lightning)
   # Make sure lightning target outputs jit_disasm.o to the expected location

3. Check File Existence:
   Ensure that deps/lightning/lib/jit_disasm.o exists after the build step for lightning. If it's missing:

   • Check that the source file for jit_disasm (e.g., jit_disasm.c or .cpp) is present in deps/lightning/lib.
   • If the file is missing in the repository, restore it or update the build scripts to not depend on it.

4. Fix Build Path Issues:
   If the build system expects the object file in a specific location, check that the paths are correct and match the build output.

Code Suggestion:
If you're missing a build step, add something like this to your build scripts (example for makefile):

deps/lightning/lib/jit_disasm.o: deps/lightning/lib/jit_disasm.c
	$(CC) -c $< -o $@

Summary:

• Initialize and update submodules.
• Ensure lightning builds jit_disasm.o.
• Confirm the file exists after building lightning.
• Correct build paths if needed.

[paulo101977]

@MatPoliquin I added the missing Makefile. However, I don't know if the build broke after that.

I reran the build and it breaks later, here is the output from github copilot, if that is of any help:

The build is failing because make cannot find the target deps/lightning/lib/jit_disasm.o, which is required for pcsx_rearmed_libretro.so. This likely means the jit_disasm.o object file is missing or not being built as expected.

Solution Steps:

1. Check Submodule/Dependency Initialization:
   Ensure that all submodules and dependencies (especially deps/lightning) are initialized and updated before building. Add this to your workflow if missing:

   - name: Update submodules
     run: git submodule update --init --recursive

2. Verify lightning Build Rules:
   Confirm that your build system (CMake/makefiles) includes rules to build deps/lightning/lib/jit_disasm.o.

   • If you use CMake, check that deps/lightning is properly added as a subdirectory and its sources included.
   • If you use make, ensure the relevant rules are not omitted.

   Example for CMakeLists.txt:

   add_subdirectory(deps/lightning)
   # Make sure lightning target outputs jit_disasm.o to the expected location

3. Check File Existence:
   Ensure that deps/lightning/lib/jit_disasm.o exists after the build step for lightning. If it's missing:

   • Check that the source file for jit_disasm (e.g., jit_disasm.c or .cpp) is present in deps/lightning/lib.
   • If the file is missing in the repository, restore it or update the build scripts to not depend on it.

4. Fix Build Path Issues:
   If the build system expects the object file in a specific location, check that the paths are correct and match the build output.

Code Suggestion:
If you're missing a build step, add something like this to your build scripts (example for makefile):

deps/lightning/lib/jit_disasm.o: deps/lightning/lib/jit_disasm.c
	$(CC) -c $< -o $@

Summary:

• Initialize and update submodules.
• Ensure lightning builds jit_disasm.o.
• Confirm the file exists after building lightning.
• Correct build paths if needed.

I'll adjust it again. I think the same thing happens on my fork. I'll test it there before passing it on to you again.

[MatPoliquin]

@paulo101977 No worries, in case it's of any help you can split this PR into two parts. The main integration on one and tests for the other afterwards.

[paulo101977]

@paulo101977 No worries, in case it's of any help you can split this PR into two parts. The main integration on one and tests for the other afterwards.

Thanks. I haven't looked at it again because I got stuck on some work. I'll check later if it's because I had to run configure inside the ps1 folder. If so, I'll have to add a script to the Makefile to run during the build.

[MatPoliquin]

@paulo101977 Any updates?

[paulo101977]

@paulo101977 Any updates?

Oops, I apologize. Not yet. I'm stuck on a project, and I don't have an estimate of when I'll be able to fix this. I was thinking of making stable-retro accept any libretro core directly, without needing to compile that core.

[victorsevero]

I was thinking of making stable-retro accept any libretro core directly

It sounds tempting, but I'd advise against that, since it would hurt reproducibility and IMO that should be a core design philosophy for a scientific library (also fully deterministic environments is one of Farama Foundation's standards)

[paulo101977]

It sounds tempting, but I'd advise against that, since it would hurt reproducibility and IMO that should be a core design philosophy for a scientific library (also fully deterministic environments is one of Farama Foundation's standards)

A repository could be created to ensure reproducibility, keeping the core version fixed. I'm doing the same for the OpenGL environment I maintain.

[MatPoliquin]

Also with the source code the user can compile it and optimize it for their system

[paulo101977]

Also with the source code the user can compile it and optimize it for their system

But there are numerous ways to optimize with external cores. One example is what I did in my code: allowing the core variables to be set, etc. And nothing prevents an experienced user from compiling their own unique cores...