RetroArch PS3 beta releases (v1.2.2)

RetroArch Sony consoles
#41

Thanks for the really quick compile, Ezio!

Tried it, it didn’t make any difference.

So it appears that when the source was changed from the original Windows version for the libretro build, the Prosystem .DAT file was incorporated directly into the Database.c file, instead of still being an external reference file. It also appears that the emulator is no longer checking the “Flags” and “Cart Type” values from this data, because the specific games that need info to pass the cart type and video flags to the emulator core aren’t working. Specifically, Kung Fu Master, Rampage, and Double Dragon.

Kung Fu Master needs the flags set to “2” in order to send the correct video mode, other wise the graphics are garbled - even after I changed the value to “2” in the Database.c file to “2” it is still garbled.

Rampage and Double Dragon are both a different bankswitching type cart, and need the cart type set to “6” in the Prosystem.DAT file passed to the emulator to determine the bankswitch mode and start the game. Currently, they don’t start in the PS3/Libretro port, even though that setting is correct in the Database.c file version of the Prosystem.DAT incorporation, but they do work correctly in every other port of Prosystem (Windows, Linux, PSP, Wii)

So it looks as if the incorporation of the Prosystem.DAT info isn’t reading or sending the cart types and flags info to the emulator core after incorporating this data into the Database.c file.

Not that I’m asking to reinvent the wheel here, but keeping the Prosystem.DAT as an external reference file is important, as the Atari 7800 has a very active homebrew and hack game dev scene, and occasionally new entries need to be made the the Prosystem.DAT to ensure compatibility with the emulator. Incorporating the info from Prosystem.dat into the database.c file makes that impossible from the user/game dev end, and requires frequent updates to the GIT then a recompile to keep up with it.

#42

No. The database is completely optional and has nothing to do with how the cores behave.

#43

No,

The Prosystem.DAT file is not optional for Prosystem. Most games will work without it, yes. The games Atari coded work without it, but 3rd party games(Activision, Absolute) and homebrews need the database. Some games (as I’ve explained above) absolutely need to have the flags or cart type info passed to the emulator in order for it to function properly. This is the case with every port of Prosystem, from the original Windows port Greg Stanton wrote 10 years ago, to every other system it’s been ported to. I worked on the PSP port with ZX-81 over at DCemu forums years ago, and this was the case with that port as well. I don’t know enough about what’s been done to alter this version from the original source code, or the libretro API, but I know for an absolute fact the Prosystem.DAT file is necessary.

Below is the original Database.cpp file - which calls out those values from the Prosystem.dat file, which would reside in the install folder of the Prosystem.exe (or the executable for whatever platform it was ported to.) I can’t tell from the coding changes that were made to the source for libretro if these values are being called or not, but based on the performance, they are not.

// ---------------------------------------------------------------------------- // ___ ___ ___ ___ ___ ____ ___ _ _ // // // / / /__ // / / /_ / |/ / // / / \ /__/ ___/ ___/ _/ / / / / emulator // // ---------------------------------------------------------------------------- // Copyright 2005 Greg Stanton // // This program is free software; you can redistribute it and/or modify // it under the terms of the GNU General Public License as published by // the Free Software Foundation; either version 2 of the License, or // (at your option) any later version. // // This program is distributed in the hope that it will be useful, // but WITHOUT ANY WARRANTY; without even the implied warranty of // MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the // GNU General Public License for more details. // // You should have received a copy of the GNU General Public License // along with this program; if not, write to the Free Software // Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. // ---------------------------------------------------------------------------- // Database.cpp // ---------------------------------------------------------------------------- #include “Database.h” #include “Common.h” #define DATABASE_SOURCE “Database.cpp”

bool database_enabled = true; std::string database_filename = “./prosystem.dat”;

static std::string database_GetValue(std::string entry) { int index = entry.rfind(’=’); return entry.substr(index + 1); }

// ---------------------------------------------------------------------------- // Load // ---------------------------------------------------------------------------- bool database_Load(std::string digest) { if(database_enabled) { FILE* file = fopen(database_filename.c_str( ), “r”); if(file == NULL) { return false;
}

char buffer[256];
while(fgets(buffer, 256, file) != NULL) {
  std::string line = buffer;
  if(line.compare(1, 32, digest.c_str( )) == 0) {
    std::string entry[7];
    for(int index = 0; index < 7; index++) {
      fgets(buffer, 256, file);
      entry[index] = common_Remove(buffer, '

');
}

    cartridge_title = database_GetValue(entry[0]);
    cartridge_type = common_ParseByte(database_GetValue(entry[1]));
    cartridge_pokey = common_ParseBool(database_GetValue(entry[2]));
    cartridge_controller[0] = common_ParseByte(database_GetValue(entry[3]));
    cartridge_controller[1] = common_ParseByte(database_GetValue(entry[4]));
    cartridge_region = common_ParseByte(database_GetValue(entry[5]));
    cartridge_flags = common_ParseUint(database_GetValue(entry[6]));
    break;
  }
}    

fclose(file);

} return true; }

#44

The one i compiled is the prosystem core with the patch #5 applied (it was the latest one out when i posted it on the forum), so no patch #6 and buildfix by Twinaphex are included in the pkg i posted yesterday.

If you need i’ll compile the latest source just get home (in 2-3 hours), just let me know.

#45

Ok - so these games are fully playable in the Windows port of Retroarch/Prosystem, even in the latest nightly update.

So it looks like something with the PS3 port of Retroarch isn’t passing the flags and cart type data properly.

#46

yeah - compile the latest if you can - not sure what else Square changed or updated, might fix it?

#47

No, i don’t think. Anyway here is the prosystem core updated with latest source code available, give it a shot! https://www.sendspace.com/file/pkxstf

#48

You were right, Ezio. The changes I submitted did not fix the issue in the PS3 port.

They do work properly in the Windows port though, and the changes I submitted made the newer hack version games work, that didnt’ work previously. So it appears that the source code change to incorporate the Prosystem.DAT entries into the database.c file works.

It’s just broken in the PS3 compiled Self for some reason. I don’t have a compile environment set up for this, so I can’t test.

When you compile this, do you see any errors in the log for the prosystem core when compiling for PS3? Or is there something in the API that is being skipped or ignored by the PS3 compile environment? Maybe a library update is needed?

#49

This is log i get while compiling prosystem core for ps3 http://pastebin.com/VaztgkAT. I can only see some warnings for unused variables, i never compiled this core for linux or windows so i cannot compare it.

#50

doesn’t look like anything specific in there causing the problem. Not sure why the PS3 port isn’t calling the Database object when it launches a cart.

It defintely works right in the Windows and Android ports.

#51

A couple of things I noticed @Ezio_PS

— Shader’s are missing - (The updater has the feature to download, just does not work on the ps3). I used the shaders from the last official build (v1.0.0.2) and it worked fine. Once you run the app for the first time on the PS3 you can see the folder (empty contents) generate (I can’t recall the exact location off hand)…

– prboom.wad is missing usually comes with the releases. (in past version was located in the “rom” folder within the SSNE10000 directory). That folder is no longer generated by RetroArch so i would suspect it’s a new location. Not really sure, just something i noticed… (prboom.wad may work if user put with rom like other bios type files but not sure for doom been awhile for me)

How did the virtualjaguar core perform? was it able to compile? I have seen two builds of the core for the PS3 one that Rtype gave me and also one that doobz gave me. One ran at a decent speed but had a blue tint on all games (no sound) (3d games did not work at all). Then the other had color but was much slower . Just curious to see how your luck was with it…

Thanks for these compiles, its been great while we wait for the official release.

#52

Thank you to let me know what it’s still missing on the ps3 build, i guess i’m going to add shaders, overlays and rom folder with prboom.wad and the cave story rom in the next beta release.

About virtualjaguar core, i’ve been able to get a working compile but i got a very bad sound and only 12-13 fps while playing Tempest; probably you’re quite interested about it so i could include this core too although it has a low performance on ps3 for the moment.

#53

[QUOTE=Ezio_PS;31307]Thank you to let me know what it’s still missing on the ps3 build, i guess i’m going to add shaders, overlays and rom folder with prboom.wad and the cave story rom in the next beta release.

About virtualjaguar core, i’ve been able to get a working compile but i got a very bad sound and only 12-13 fps while playing Tempest; probably you’re quite interested about it so i could include this core too although it has a low performance on ps3 for the moment.[/QUOTE]

not sure if roms folder is the default location now in v1.2.2., worth a try but I am not sure. As in v1.0.0.2 that folder would self-generate and now that folder does not (when the other folders generate on first boot).

Yea tempest i never worked to well, anything 3dish did not work well. I think a few games were playable but its been so long.

Quake is missing, but i think you mentioned that one had issues at the moment. If Cave Story is added nxengine core is needed (which i am sure you know :slight_smile: ). NeoPop but that one has had issues… Other then those i think you have everything.

#54

Hi!

Cheat’s dont seem to work. When i open a .CHT file, it doesn’t detect the cheats. Can you look into it? Running the newest beta :).

#55

[QUOTE=STLcardsWS;31322]not sure if roms folder is the default location now in v1.2.2., worth a try but I am not sure. As in v1.0.0.2 that folder would self-generate and now that folder does not (when the other folders generate on first boot).

Yea tempest i never worked to well, anything 3dish did not work well. I think a few games were playable but its been so long.

Quake is missing, but i think you mentioned that one had issues at the moment. If Cave Story is added nxengine core is needed (which i am sure you know :slight_smile: ). NeoPop but that one has had issues… Other then those i think you have everything.[/QUOTE]

Are you sure that retroarch v1.0.0.2 self-generates the rom folder? I tried to compile that old version and i didn’t notice it, also looking into the code i can’t find it, anyway it’s quite easy to implement that folder, though i’d prefer not to include it letting so the choice of it to the final user. Do you agree? :slight_smile:

Quake and Neopop have some known issues, it’s not so easy to figure out them, however i’m always looking for a solution, but still no result. :frowning:

About Cave Story, the nxengine core is already included in the betas and it works great, it’s only missing the rom that i’ll include in the next build.

[QUOTE=mrkoelie;31388]Hi!

Cheat’s dont seem to work. When i open a .CHT file, it doesn’t detect the cheats. Can you look into it? Running the newest beta :).[/QUOTE]

I just tested the cheats in these latest 4 days, but still nothing, the cheat list isn’t shown up once you load the cheat file, i only added the cheats path to the executable, but i’m not sure if i go adding it to the next build since the cheats aren’t working. Still no luck with them :frowning:

#56

I should not of said self generate for that folder. (it may). but its a folder that was in the release. As these were the location for the prboom.wad and the cavestory (game) files… I was thinking it self generated like the other folders but it may not. but download an official link or mirror of v1.0.0.2 and you will see the roms folder with those files.

#57

Ah okay, i downloaded the official 1.0.0.2 version and checked those files and the roms folder, so i decide including them to the beta releases too. You’ll find them and some new cores in this new beta release.

Beta 1.7 https://www.sendspace.com/file/xjrzyb

Changelog

Added VirtualJaguar core, no bios required Added Mednafen PCFX core, it needs bios in the system/custom folder Update Prosystem core to latest available source code Update Stella core to latest available source code (from 3.4.1 to 3.9.3 version) Update Italian translation Added shaders Added overlays (borders included) Added rom folder Added prboom.wad Added cave story game files

Note

Virtual Jaguar core has poor performance, 12-16 fps and very bad audio. Mednafen PCFX could have a laggy sound, but it’s above 25 fps at least. Cave story game files and prboom.wad are placed into dev_hdd0/games/SNES1000/USRDIR/cores/roms

#58

Any chance you can add Colecovision, Intellivision and Magnavox Odyssey 2 cores in a future release?

#59

When i try to build bluemsx core for ps3 i get an error: L0039: reference to undefined symbol, so at the moment it cannot be built but it could be fixed in near future. About o2em core it compiles for ps3, i need only get a bit of free time to test whether it works or not, while for intellivision you should try the mame core, it should be able to emulate intellivision, not sure though.

#60

[QUOTE=Ezio_PS;31697]When i try to build bluemsx core for ps3 i get an error: L0039: reference to undefined symbol, so at the moment it cannot be built but it could be fixed in near future. About o2em core it compiles for ps3, i need only get a bit of free time to test whether it works or not, while for intellivision you should try the mame core, it should be able to emulate intellivision, not sure though.[/QUOTE]

I tried the Mame core with Intellivision Roms and it doesn’t work. Atari 5200 a possibility?