Editing Talk:PS1 Emulation
Jump to navigation
Jump to search
The edit can be undone. Please check the comparison below to verify that this is what you want to do, and then publish the changes below to finish undoing the edit.
| Latest revision | Your text | ||
| Line 178: | Line 178: | ||
</pre> | </pre> | ||
==== Allow non encrypted ISO.BIN.EDAT | ==== Allow non encrypted ISO.BIN.EDAT ==== | ||
For easier config testing. Patch allow to use unencrypted ISO.BIN.EDAT so we don't need to mess with klic. | For easier config testing. Patch allow to use unencrypted ISO.BIN.EDAT so we don't need to mess with klic. ECDSA signature at the end of file is still required! But this can be easily generated with sign3.py from pop-fe. | ||
<br><br> | <br><br> | ||
ps1_netemu.elf 4.86-4.90 offset in raw hex (for Hxd, etc.) | ps1_netemu.elf 4.86-4.90 offset in raw hex (for Hxd, etc.) | ||
0xDDD6C replace 48 07 14 21 to 38 60 00 00 | 0xDDD6C replace 48 07 14 21 to 38 60 00 00 | ||
== | == Commands Info == | ||
=== External Configs === | === External Configs === | ||
Loading external commands is be possible in ps1_netemu. From this we can also figure out that sony call those configs "ad hoc params" which can be little bit misleading. Emulator expect them inside ISO.BIN.EDAT file. Offset depend if "optional header" exist or not. Values are little endian. | Loading external commands is be possible in ps1_netemu. From this we can also figure out that sony call those configs "ad hoc params" which can be little bit misleading. Emulator expect them inside ISO.BIN.EDAT file. Offset depend if "optional header" exist or not. Values are little endian. | ||
* Offset 0x424 or 0x824 in DAT file = Config revision in bcd format, that need to be higher than DB from emu (11624 for 4.86). Safe to use 0x200000. | |||
* Offset 0x424 Config revision in bcd format, that need to be higher than DB from emu (11624 for 4.86). Safe to use 0x200000. | * Offset 0x42C or 0x82C first config command | ||
* Offset 0x42C first config command | * Offset 0x430 or 0x830 param for first command | ||
* Offset 0x430 param for first command | |||
* This repeats 8 times as only 8 commands is supported. | * This repeats 8 times as only 8 commands is supported. | ||
* Command 2 is unsupported. | * Command 2 is unsupported. | ||
| Line 241: | Line 215: | ||
if ( cfg_command - 1 <= 0x3B ) // max cfg nr 0x3C | if ( cfg_command - 1 <= 0x3B ) // max cfg nr 0x3C | ||
{ | { | ||
v245 = cfg_command >> 28; // | v245 = cfg_command >> 28; // Weird. Maybe leftover from 0xX0000000 commands or something. | ||
if ( low_rev || v245 || cfg_command == 2 )// cfg 2 unsupported (replaced in later PSIMG rev with subchannel data), or old config rev, or v245. | if ( low_rev || v245 || cfg_command == 2 )// cfg 2 unsupported (replaced in later PSIMG rev with subchannel data), or old config rev, or v245. | ||
{ | { | ||
| Line 267: | Line 241: | ||
**0 = ? (used by SCPS-18011 Um Jammer Lammy, and SLPS-01818 Langrisser IV & V Final Edition [Disc1of2]) | **0 = ? (used by SCPS-18011 Um Jammer Lammy, and SLPS-01818 Langrisser IV & V Final Edition [Disc1of2]) | ||
In Um Jammer Lammy is used together with command 0x13, so it was a bit doubtful if it was a mistake. But Langrisser IV & V Final Edition [Disc1of2] uses it too and is the only command used by this disc, so it "should" do something. Um Jammer Lammy in netemu 3.40 was fixed only with command 0x0/0x0 (id/data) | In Um Jammer Lammy is used together with command 0x13, so it was a bit doubtful if it was a mistake. But Langrisser IV & V Final Edition [Disc1of2] uses it too and is the only command used by this disc, so it "should" do something. Um Jammer Lammy in netemu 3.40 was fixed only with command 0x0/0x0 (id/data) | ||
=== Command 0x01 (netemu 3.40 up to 4.88) === | === Command 0x01 (netemu 3.40 up to 4.88) === | ||
| Line 636: | Line 609: | ||
Value is integer that is later converted to double float using fcfid, and truncated to single precision by frsp.<br> | Value is integer that is later converted to double float using fcfid, and truncated to single precision by frsp.<br> | ||
I'm not familiar with CELL floating point unit quirks, but value could be just single precision float from the start, why complicate that so much?<br> | I'm not familiar with CELL floating point unit quirks, but value could be just single precision float from the start, why complicate that so much?<br> | ||
_xcdrom_thread related. | |||
=== Command 0x04 (netemu 3.40 up to 4.88) === | === Command 0x04 (netemu 3.40 up to 4.88) === | ||
*Valid values found: 0x4, 0x7, 0x14 (20d), 0x46 (70d), 0x64 (100d), 0xC8 (200d), 0xFFFFFF38 ( | *Valid values found: 0x4, 0x7, 0x14 (20d), 0x46 (70d), 0x64 (100d), 0xC8 (200d), 0xFFFFFF38 (????????) | ||
*Default value: 0 | *Default value: 0 | ||
*_xcdrom_thread related. | *_xcdrom_thread related. | ||
=== Command 0x05 (netemu 3.40 up to 4.88) === | === Command 0x05 (netemu 3.40 up to 4.88) === | ||
| Line 657: | Line 624: | ||
*Default value: 0 | *Default value: 0 | ||
*_xcdrom_thread related. | *_xcdrom_thread related. | ||
=== Command 0x07 (netemu 4.83 up to 4.88) === | === Command 0x07 (netemu 4.83 up to 4.88) === | ||
*Default value: 0 | *Default value: 0 | ||
*_xcdrom_thread related. | *_xcdrom_thread related. | ||
=== Command 0x08 (netemu 3.40 up to 4.88) === | === Command 0x08 (netemu 3.40 up to 4.88) === | ||
| Line 697: | Line 659: | ||
=== Command 0x12 (netemu 4.83 up to 4.88) === | === Command 0x12 (netemu 4.83 up to 4.88) === | ||
*Or command 0x10 (netemu 3.40) | *Or command 0x10 (netemu 3.40) | ||
=== Command 0x13 (netemu 4.83 up to 4.88) === | === Command 0x13 (netemu 4.83 up to 4.88) === | ||
*Default value: 0 | *Default value: 0 | ||
*MDEC related? | *MDEC related? | ||
=== Command 0x14 (netemu 4.83 up to 4.88) === | === Command 0x14 (netemu 4.83 up to 4.88) === | ||
| Line 715: | Line 672: | ||
=== Command 0x16 (netemu 4.83 up to 4.88) === | === Command 0x16 (netemu 4.83 up to 4.88) === | ||
*Default value: 0 | *Default value: 0 | ||
=== Command 0x17 (netemu 4.83 up to 4.88) === | === Command 0x17 (netemu 4.83 up to 4.88) === | ||
| Line 731: | Line 684: | ||
When value is not zero is returned by emulator when game try to read cop0r3 (BPC) register. When value is 0 (default), emulator return real BPC content. | When value is not zero is returned by emulator when game try to read cop0r3 (BPC) register. When value is 0 (default), emulator return real BPC content. | ||
This command can be successfully used for 90% of libcrypt games. More importantly address where magic word is stored is known, so payloads like cobra should be able to just write value there on emulator init. List of magic words is already known, and can be included in cobra source, or as external txt for game managers like webman. | |||
Runtime which read it can be patched directly (example from ps1_netemu 4.86): | |||
<pre> | |||
seg003:00106570 read_cop0r3___BPC: | |||
seg003:00106570 li r3, 0x17 # jumptable 0000000000106538 case 0 | |||
seg003:00106574 bl ReadInternalConfigValue <---------- can be replaced with li r3, magic_word | |||
seg003:00106578 nop | |||
seg003:0010657C cmpdi r3, 0 | |||
seg003:00106580 beq def_106538 # jumptable 0000000000106538 default case, cases 1,2,4,6-8 | |||
seg003:00106584 mr r29, r3 | |||
</pre> | |||
* It seems there is a problem with LC games using the third scheme mentioned [https://problemkaputt.de/psx-spx.htm#cdromprotectionlibcrypt here]. After reading the data contents of subchannel Q, the CRC-16 value is not read at all, but calculated on its own by the driver instead. It does break LC games using this particular scheme (web-found confirmed issues with Ape Escape and Final Fantasy VIII). All three games that are meant to work with this command does use these LC sectors. I think this command was meant to resolve this issue, just a guess.--[[User:Agrippa|Agrippa]] ([[User talk:Agrippa|talk]]) 20:06, 12 June 2022 (UTC) | * It seems there is a problem with LC games using the third scheme mentioned [https://problemkaputt.de/psx-spx.htm#cdromprotectionlibcrypt here]. After reading the data contents of subchannel Q, the CRC-16 value is not read at all, but calculated on its own by the driver instead. It does break LC games using this particular scheme (web-found confirmed issues with Ape Escape and Final Fantasy VIII). All three games that are meant to work with this command does use these LC sectors. I think this command was meant to resolve this issue, just a guess.--[[User:Agrippa|Agrippa]] ([[User talk:Agrippa|talk]]) 20:06, 12 June 2022 (UTC) | ||
=== Command 0x18 (netemu 4.83 up to 4.88) === | === Command 0x18 (netemu 4.83 up to 4.88) === | ||
*Default value: 0 | *Default value: 0 | ||
=== Command 0x19 (netemu 4.83 up to 4.88) === | === Command 0x19 (netemu 4.83 up to 4.88) === | ||
| Line 757: | Line 719: | ||
*Or command 0x18 (netemu 3.40) | *Or command 0x18 (netemu 3.40) | ||
*Or command 0x1A (netemu 3.55 ?) | *Or command 0x1A (netemu 3.55 ?) | ||
*Or command 0x02 (netemu 1.70) - | *Or command 0x02 (netemu 1.70) | ||
Destruction Derby (SCUS-94302) was fixed in netemu 1.70 by using 0x02/0x02 (id/data), and in netemu 4.88 with 0x38/0x02 (id/data). Netemu 1.70 command 0x02 was remapped to netemu 4.88 command 0x1C but are 2 different commands. What happened is sony decided to change the old command by the new command 0x32 (didnt existed in netemu 1.70) at some intermediate revision. The interesting detail of this story is this change in the destruction derby config seems to indicate netemu 4.88 command ids 0x1C and 0x38 with data value 0x2 can be used to solve the same problem. Netemu 4.88 command 0x38 reloads the game with ps1_newemu.self 4.88 that contains another config with the command 0x3/0x2 (id/data)<br> | |||
Old command 0x02 is related to new 0x1C. But it seems that sony decided to split/extend that little bit. Instead of 0x02 there is now 0x1C, 0x1D, 0x1E, so config is now more flexible. All that is "JOY" PSX HW IO related, but "JOY" handle also memory card, so this is no 100% clear which one it helps without more reversing. --kozarovv. | |||
=== Command 0x1E (netemu 4.83 up to 4.88) === | === Command 0x1E (netemu 4.83 up to 4.88) === | ||
*Default value: 0x7D0 | *Default value: 0x7D0 | ||
*xPadThread related. | *xPadThread related. | ||
=== Command 0x21 (netemu 4.83 up to 4.88) === | === Command 0x21 (netemu 4.83 up to 4.88) === | ||
| Line 790: | Line 734: | ||
*Default value: 0x3E8 | *Default value: 0x3E8 | ||
*PS1 GPU related. | *PS1 GPU related. | ||
=== Command 0x23 (netemu 4.83 up to 4.88) === | === Command 0x23 (netemu 4.83 up to 4.88) === | ||
| Line 819: | Line 762: | ||
*Default value: 0 | *Default value: 0 | ||
*PS1 GPU related. | *PS1 GPU related. | ||
=== Command 0x32 (netemu 4.83 up to 4.88) === | === Command 0x32 (netemu 4.83 up to 4.88) === | ||
| Line 852: | Line 789: | ||
*Or command 0x2C in ps1_netemu.self 3.40 | *Or command 0x2C in ps1_netemu.self 3.40 | ||
*Or command 0x2E in ps1_netemu.self 3.55 ? | *Or command 0x2E in ps1_netemu.self 3.55 ? | ||
*Or command 0x15 in ps1_emu.self 4.88 ? | |||
*Valid values found: | *Valid values found: | ||
** | **1 = relaunch the game with ps1_emu.self | ||
**2 = relaunch the game with ps1_newemu.self | |||
**3 = relaunch the game with ps1_netemu.self (value 3 found inside ps1_emu.self) | |||
If the value is different than 0 relaunch the game with a different emu. | |||
* | |||
* | |||
= | |||
**3 | |||
This command doesn't seem to work with the current Cobra version with the latest WebMAN MOD, as well as with IRISMAN's payload. Gaia Seed: Project Seed Trap (SLPS-00624) and Um Jammer Lammy (SCUS-94448) boot in netemu instead of newemu while the PS one Classics versions boot into newemu. Is there any known reason this happens? --[[User:Mrjaredbeta|Mrjaredbeta]] ([[User talk:Mrjaredbeta|talk]]) 18:59, 29 May 2022 (UTC) | |||
=== | === Orphan commands info === | ||
* 0xE param is divider for 0x204CC00 (psx cpu speed), result is stored on fixed address and used by many functions. <!-- we need to move this note to the new page sections and delete this one originally named "Known ps1emu.self commands" --> | |||
* | |||
== Known bugs == | == Known bugs == | ||