Editing Talk:PS1 Emulation

Jump to navigation Jump to search
Warning: You are not logged in. Your IP address will be publicly visible if you make any edits. If you log in or create an account, your edits will be attributed to your username, along with other benefits.

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 1: Line 1:
== Memory Map ==  
== PS1 Emulator Types and Revisions ==
For now here, i will move when finished.
<div>
Based on ps1_netemu 4.86.
<div style="float:top; text-align:center;">'''PS1 Emulators Types and Revisions'''</div>
* emu memory 0x770780 - 0x97077F = PS1 RAM (80000000 - 801FFFFF)
<div style="float:left; width:25%;">
* emu memory 0x970780 - 0x970B7F = PS1 Scratchpad (1F800000 - 1F8003FF)
{| class="wikitable" style="font-size:xx-small;"
* emu memory 0x970B80 - 0xD70B80 = PS1 ROM (1FC00000 - 1FFFFFFF) (only 512kb used)
|+ ps1_emu.elf (decrypted)
! Firmware !! Bytes !! MD5 !! Timestamp !! <abbr title="Revision">Rev</abbr>
|-
! [[1.00_AV|1.00 AV]]
| 10 296 408 || 981A7428C2A59219FA05861EDEEDBD4A || 06/10/04/12:16 || ?
|-
! [[1.02_CEX|1.02]]
| 10.296.408 || C5FE03742A951194C336EE33783F5CD6 || 06/10/21/00:01 || ?
|-
! [[1.10_CEX|1.10]]
| 10.296.408 || C9C9D7D2E36F3E3579A5DF713E9ABE1E || 06/11/09/06:09 || ?
|-
! [[1.11_CEX|1.11]]
| 10.296.408 || 26271CCA29B77483DC3D7FDDE7B9CC3C || 06/11/21/17:55 || ?
|-
! [[1.30_CEX|1.30]]
| 10.296.496 || E7932EC24E72B3005EE152B141A63690 || 06/12/05/05:34 || ?
|-
! [[1.31_CEX|1.31]]
| 10.296.496 || 2244DE70C85093D7E37BC3D3F4278BE1 || 06/12/12/18:48 || ?
|-
! [[1.32_CEX|1.32]]
| 10.296.496 || 601BCADBBBC0A2D0433C932A2D67C4EF || 06/12/18/05:55 || ?
|-
! [[1.50_CEX|1.50]]
| 10.303.536 || F8050B006CDFCC64DF742D7BBDC03130 || 07/01/18/22:53 || ?
|-
! ?
| ? || ? || ? || ?
|-
! ?
| ? || ? || ? || ?
|-
! ?
| ? || ? || ? || ?
|-
! [[1.90_CEX|1.90]]
| 6.974.864 || 478CFED0F7EE13C94F01C2A246C83D45 || 07/07/21/06:45 || ?
|-
! ?
| ? || ? || ? || ?
|-
| colspan="5" style="background:#ff8080; text-align:center; line-height:75%" | stripped/extracted rom/bios
|-
! [[2.10_CEX|2.10]]
| ? || ? || ? || ?
|-
! ?
| ? || ? || ? || ?
|-
! [[3.40_CEX|3.40]]
| 2.824.576 || A6ABFB04739575E2264A4D3FEB2A9CBF || 10/06/23/15:45 || ?
|-
! ?
| ? || ? || ? || ?
|-
! [[3.66_CEX|3.66]]
| 2.824.832 || 95399A202003E216794511BD2D2E9DF6 || 11/06/16/03:52 || ?
|-{{cellcolors|#bbbbff}}
! [[3.70_CEX|3.70]]
| rowspan="3" | 2.824.920 || 045D81147B9BDFB8C8A416FD5F5A0C56 || 11/08/05/03:42 || rowspan="3" | same
|-{{cellcolors|#bbbbff}}
! ~
| colspan="2" style="text-align:center; background-color:#bbbbff;" | ''Any''
|-{{cellcolors|#bbbbff}}
! [[3.72_CEX|3.72]]
| C745A30231103B83F04539021E4878FC || 11/09/14/01:17
|-{{cellcolors|#ddddff}}
! [[3.73_CEX|3.73]]
| rowspan="2" | 2.824.920 || EB3AFF30B3206CFA6A8962AB393F773E || 11/10/04/12:55 || rowspan="2" | same
|-{{cellcolors|#ddddff}}
! [[3.74_CEX|3.74]]
| E2A77C3DC9FD5AD4264341196462D096 || 11/10/25/00:38
|-{{cellcolors|#bbbbff}}
! [[4.00_CEX|4.00]]
| rowspan="3" | 2.829.784 || 94A8E6A8063C08FAD8CA9B340CCCAE67 || 11/11/22/03:17 || rowspan="3" | same
|-{{cellcolors|#bbbbff}}
! ~
| colspan="2" style="text-align:center; background-color:#bbbbff;" | ''Any''
|-{{cellcolors|#bbbbff}}
! [[4.11_CEX|4.11]]
| 02B7F6D5F517959161B2154135D4B3BC || 12/02/11/07:13
|-
! [[4.15_CEX|4.15]]
| ? || ? || ? || ?
|-{{cellcolors|#ddddff}}
! [[4.20_CEX|4.20]]
| rowspan="2" | 2.829.912 || 3778948C92F5FA12CB0AABE65BEE5465 || 12/06/15/02:09 || rowspan="2" | same
|-{{cellcolors|#ddddff}}
! [[4.21_CEX|4.21]]
| B7B662397E3FFDD7C11F9617C1B41856 || 12/06/30/01:13
|-
! [[4.23_SEX|4.23 S]]
| 2.829.912 || 6E74CC51E0C6462DF1F9278ED9DB9593 || 12/07/31/00:22 || ?
|-
! [[4.25_CEX|4.25]]
| 2.829.912 || 03EA65C3EA3F8DB04F236C49C6B6C0E1 || 12/09/07/07:03 || <abbr title="same code than 4.20 CEX and 4.21 CEX.... but different than the 4.23 SEX in between, grrrr">same</abbr>
|-
! ?
| ? || ? || ? || ?
|-
! ?
| ? || ? || ? || ?
|-
! ?
| ? || ? || ? || ?
|-
! [[4.78_CEX|4.78]]
| 2.765.488 || 354F1DEEDCA3C4CFA1B49B6B28B1648D || 15/12/17/01:18 || ?
|-
! [[4.80_CEX|4.80]]
| ? || ? || ? || ?
|-
! [[4.81_CEX|4.81]]
| 2.765.616 || 2123E3D6A8E81647CB41F51AFEE6CCD6 || 16/10/24/19:23 || ?
|-
! colspan="5" style="background:#80ff80; line-height:75%" | Abandoned (last revision)
|-{{cellcolors|#ddddff}}
! [[4.82_CEX|4.82]]
| rowspan="3" | 2.765.616 || 64BFA4DBD595A20E317B2189B54BF673 || 17/08/24/15:42 || rowspan="3" | Same
|-
! ~
| colspan="2" style="text-align:center; background-color:#ddddff;" | ''Any''
|-
! [[4.88_CEX|4.88]]
| style="background-color:#ddddff;" | 0C553CE93A2A6322E16636DD76D75E32 || style="background-color:#ddddff;" | 21/04/12/11:34
|}
<span style="font-size:small">
{{widedot}}'''Decrypted (elf)''': changes <abbr title="When comparing two decrypted files of the same revision from different firmwares the only differences are the build label (1 area with size 0x20) and the target firmware (1 area with size 0x2)">every firmware version</abbr><br>
{{widedot}}'''<abbr title="0x20 bytes">Build label</abbr>''': yes, with timestamp, search for '''-sgpu-sspu-sli4'''<br>
{{widedot}}'''<abbr title="2 bytes">Target Firmware</abbr>''': yes repeated '''one''' time<br>
{{widedot}}'''Revision''': unknown
</span>
</div>
<div style="float:left; width:25%;">
{| class="wikitable" style="font-size:xx-small;"
|+ ps1_netemu.elf (decrypted)
! Firmware !! Bytes !! MD5 !! Timestamp !! <abbr title="Revision">Rev</abbr>
|-
! [[1.00_CEX|1.00]] ~ [[1.60_CEX|1.60]]
| colspan="4" {{no}}
|-
! [[1.70_CEX|1.70]]
| ? || ? || ? || ?
|-
! ?
| ? || ? || ? || ?
|-
! ?
| ? || ? || ? || ?
|-
! [[1.90_CEX|1.90]]
| 6.853.368 || 8A5A3676B461C97A9A467D5651D6EAAD || 07/07/21/06:47 || ?
|-
! ?
| ? || ? || ? || ?
|-
| colspan="5" style="background:#ff8080; text-align:center; line-height:75%" | stripped/extracted rom/bios
|-
! [[2.10_CEX|2.10]]
| ? || ? || ? || ?
|-
! ?
| ? || ? || ? || ?
|-
! [[3.40_CEX|3.40]]
| 2.971.288 || FD32C7B7CBA2639FC8DB9EB615A16461 || 10/06/23/15:46 || ?
|-
! ?
| ? || ? || ? || ?
|-
! [[3.66_CEX|3.66]]
| 2.971.976 || 9586FC8B121E59526C31405DCFFB79CA || 11/06/16/03:54 || ?
|-{{cellcolors|#bbbbff}}
! [[3.70_CEX|3.70]]
| rowspan="3" | 2.972.168 || AA1DB63461EE0BE021ED45F85A6EECE0 || 11/08/05/03:43 || rowspan="3" | same
|-{{cellcolors|#bbbbff}}
! ~
| colspan="2" style="text-align:center; background-color:#bbbbff;" | ''Any''
|-{{cellcolors|#bbbbff}}
! [[3.72_CEX|3.72]]
| 32F45129EC2844D419582912E54CEB22 || 11/09/14/01:18
|-{{cellcolors|#ddddff}}
! [[3.73_CEX|3.73]]
| rowspan="2" | 2.972.168 || 17063FFAB205B72ABF7F59582B8A7988 || 11/10/04/12:56 || rowspan="2" | same
|-{{cellcolors|#ddddff}}
! [[3.74_CEX|3.74]]
| 89C03D80ACE7C4FA914DD699621EB4F8 || 11/10/25/00:40
|-{{cellcolors|#bbbbff}}
! [[4.00_CEX|4.00]]
| rowspan="2" | 2.977.128 || DBB8FB62BE3F2064D31332FCB7575DF1 || 11/11/22/03:19 || rowspan="2" | same
|-{{cellcolors|#bbbbff}}
! [[4.01_CEX|4.01]]
| 9E60379FA979B0440C27C6AEE38754AF || 11/12/23/01:10
|-{{cellcolors|#ddddff}}
! [[4.10_CEX|4.10]]
| rowspan="2" | 2.977.208 || B3CD41AB8235906AB41D3DA18D04F00E || 12/02/05/23:19 || rowspan="2" | same
|-{{cellcolors|#ddddff}}
! [[4.11_CEX|4.11]]
| 4DDF2C3289AD9BEDF0719DBE1BDA971C || 12/02/11/07:15
|-
! [[4.15_CEX|4.15]]
| ? || ? || ? || ?
|-{{cellcolors|#bbbbff}}
! [[4.20_CEX|4.20]]
| rowspan="2" | 2.977.432 || 363A2D5EE2246E9CEFCBF1078593C771 || 12/06/15/02:10 || rowspan="2" | same
|-{{cellcolors|#bbbbff}}
! [[4.21_CEX|4.21]]
| 5E08C86EC07E4F227D3591DD9530CC95 || 12/06/30/01:15
|-
! [[4.23_SEX|4.23 S]]
| 2.977.416 || 149E5E6AD727B1B37E29D4E8D15D5BB0 || 12/07/31/00:23 || ?
|-
! [[4.25_CEX|4.25]]
| 2.977.432 || 295B61D9EEE704077FEC870C8EAC7D35 || 12/09/07/07:04 || <abbr title="same code than 4.20 CEX and 4.21 CEX.... but different than the 4.23 SEX in between, grrrr">same</abbr>
|-
! ?
| ? || ? || ? || ?
|-
! ?
| ? || ? || ? || ?
|-
! ?
| ? || ? || ? || ?
|-
! [[4.78_CEX|4.78]]
| 2.913.480 || 398A7CA9F0E8449E15FCB33B87C96194 || 15/12/17/01:19 || ?
|-
! [[4.80_CEX|4.80]]
| ? || ? || ? || ?
|-
! [[4.81_CEX|4.81]]
| 2.913.656 || 8765A00EE467B8635A13ECCBB1F85B89 || 16/10/24/19:24 || ?
|-
! [[4.82_CEX|4.82]]
| 2.913.752 || FCEB6595F9F8E5C77BA36C73C38397D9 || 17/08/24/15:43 || ?
|-
! colspan="5" style="background:#80ff80; line-height:75%" | Abandoned (last revision)
|-{{cellcolors|#ddddff}}
! [[4.83_CEX|4.83]]
| rowspan="3" | 2.913.992 || CA9509623B9885E18D12E14FA1488EEF || 18/09/02/18:03 || rowspan="3" | Same
|-
! ~
| colspan="2" style="text-align:center; background-color:#ddddff;" | ''Any''
|-
! [[4.88_CEX|4.88]]
| style="background-color:#ddddff;" | D3283D3F3B5CDF68113560829530E7B3 || style="background-color:#ddddff;" | 21/04/12/11:34
|}
<span style="font-size:small">
{{widedot}}'''Decrypted (elf)''': changes <abbr title="When comparing two decrypted files of the same revision from different firmwares the only differences are the build label (1 area with size 0x20) and the target firmware (2 areas with size 0x2)">every firmware version</abbr><br>
{{widedot}}'''<abbr title="0x20 bytes">Build label</abbr>''': yes, with timestamp, search for '''-sgpu-sli4'''<br>
{{widedot}}'''<abbr title="2 bytes">Target Firmware</abbr>''': yes repeated '''two''' times<br>
{{widedot}}'''Revision''': unknown
</span>
</div><div style="float:left; width:25%;">
{| class="wikitable" style="font-size:xx-small;"
|+ ps1_newemu.elf (decrypted)
! Firmware !! Bytes !! MD5 !! Timestamp !! <abbr title="Revision">Rev</abbr>
|-
! [[1.00_CEX|1.00]] ~ [[2.01_CEX|2.01]]
| colspan="4" {{no}}
|-
! [[2.10_CEX|2.10]]
| ? || ? || ? || ?
|-
! ?
| ? || ? || ? || ?
|-
! [[3.40_CEX|3.40]]
| 2.708.856 || C866D54E85BAA06D111C8300F9EA85F1 || 10/06/23/15:51 || ?
|-
! ?
| ? || ? || ? || ?
|-
! [[3.66_CEX|3.66]]
| 2.708.864 || 9AB86CFAEB12675F3DB08FCAA3541534 || 11/06/16/03:54 || ?
|-{{cellcolors|#bbbbff}}
! [[3.70_CEX|3.70]]
| rowspan="3" | 2.708.880 || 7AB7C32901778E3F0C9B8DB45296821B || 11/08/05/03:44 || rowspan="3" | same
|-{{cellcolors|#bbbbff}}
! ~
| colspan="2" style="text-align:center; background-color:#bbbbff;" | ''Any''
|-{{cellcolors|#bbbbff}}
! [[3.72_CEX|3.72]]
| 2863E9B70B4FB6C5A0938FF508C46057 || 11/09/14/01:18
|-{{cellcolors|#ddddff}}
! [[3.73_CEX|3.73]]
| rowspan="2" | 2.708.880 || 871E256771632569D664FF2A1ECE82C3 || 11/10/04/12:57 || rowspan="2" | same
|-{{cellcolors|#ddddff}}
! [[3.74_CEX|3.74]]
| 8A8AC80CBA58561CC754C6CF66B059AB || 11/10/25/00:40
|-{{cellcolors|#bbbbff}}
! [[4.00_CEX|4.00]]
| rowspan="2" | 2.713.832 || F9E840430B2BC982CB1A71B7BDD7FC35 || 11/11/22/03:19 || rowspan="2" | same
|-{{cellcolors|#bbbbff}}
! [[4.01_CEX|4.01]]
| 953090CBCB96626899731B711B3D5B6A || 11/12/23/01:11
|-{{cellcolors|#ddddff}}
! [[4.10_CEX|4.10]]
| rowspan="2" | 2.713.720 || 47E7FA52DB7BDEDF2187EB02D868834D || 12/02/05/23:20 || rowspan="2" | same
|-{{cellcolors|#ddddff}}
! [[4.11_CEX|4.11]]
| 8A90DB2A206BE79423A99D4CF2458241 || 12/02/11/07:16
|-
! [[4.15_CEX|4.15]]
| ? || ? || ? || ?
|-{{cellcolors|#bbbbff}}
! [[4.20_CEX|4.20]]
| rowspan="2" | 2.713.904 || 8AC80356D1EFDDCFF7A7AD82136137D2 || 12/06/15/02:11 || rowspan="2" | same
|-{{cellcolors|#bbbbff}}
! [[4.21_CEX|4.21]]
| E482927E47B00C1478313E343DD652C4 || 12/06/30/01:15
|-
! [[4.23_SEX|4.23 S]]
| 2.713.888 || A2CF9C4C00B40779FB5C529849E0D6A4 || 12/07/31/00:24 || ?
|-
! [[4.25_CEX|4.25]]
| 2.713.904 || 24107753F0B02075DAB20492BA67167D || 12/09/07/07:05 || <abbr title="same code than 4.20 CEX and 4.21 CEX.... but different than the 4.23 SEX in between, grrrr">same</abbr>
|-
! ?
| ? || ? || ? || ?
|-
! ?
| ? || ? || ? || ?
|-
! ?
| ? || ? || ? || ?
|-
! [[4.78_CEX|4.78]]
| 2.649.144 || BF78A0DC74084B43777A7F8CE6C7B66A || 15/12/17/01:20 || ?
|-
! [[4.80_CEX|4.80]]
| ? || ? || ? || ?
|-
! [[4.81_CEX|4.81]]
| 2.649.272 || 0C76DE974439B12546EA494639C8EE9A || 16/10/24/19:25 || ?
|-
! colspan="5" style="background:#80ff80; line-height:75%" | Abandoned (last revision)
|-{{cellcolors|#ddddff}}
! [[4.82_CEX|4.82]]
| rowspan="3" | 2.649.288 || C5957F268EE9E1429DE3AF0BC15F1395 || 17/08/24/15:44 || rowspan="3" | Same
|-
! ~
| colspan="2" style="text-align:center; background-color:#ddddff;" | ''Any''
|-
! [[4.88_CEX|4.88]]
| style="background-color:#ddddff;" | 4002EC6CB88F5D2D5E7DF0B0F80A6A0A || style="background-color:#ddddff;" | 21/04/12/11:35
|}
<span style="font-size:small">
{{widedot}}'''Decrypted (elf)''': changes <abbr title="When comparing two decrypted files of the same revision from different firmwares the only differences are the build label (1 area with size 0x20) and the target firmware (2 areas with size 0x2)">every firmware version</abbr><br>
{{widedot}}'''<abbr title="0x20 bytes">Build label</abbr>''': yes, with timestamp, search for '''-sgpu-sspu-sli4'''<br>
{{widedot}}'''<abbr title="2 bytes">Target Firmware</abbr>''': yes repeated '''two''' times<br>
{{widedot}}'''Revision''': unknown
</span>
</div><div style="float:left; width:25%;">
{| class="wikitable" style="font-size:xx-small;"
|+ ps1_rom.bin
! Firmware !! Bytes !! MD5 !! <abbr title="Revision">Rev</abbr>
|-
! [[1.00_CEX|1.00]] ~ [[2.01_CEX|2.01]]
| colspan="4" {{no}}
|-
! [[2.10_CEX|2.10]]
| ? || ? || ?
|-
! ?
| ? || ? || ?
|-
! [[3.40_CEX|3.40]] ~ [[3.74_CEX|3.74]]
| 4.089.584 || FBB5F59EC332451DEBCCF1E377017237 || ?
|-
! [[4.00_CEX|4.00]] ~ [[4.88_CEX|4.88]]
| 524.288 || 81BBE60BA7A3D1CEA1D48C14CBCC647B || ?
|}
<span style="font-size:small">
{{widedot}}'''Format''': Not compiled or encrypted for every firmware<br>
{{widedot}}'''Build label''': unknown<br>
{{widedot}}'''Revision''': unknown
</span>
</div>
</div>
<br style="clear: both;" />


== GPU related info ==
== Command IDs mapping ==
<pre>
All the PS1 emulators have some game settings hardcoded inside them organized in a table using a hierarchy, pretty much the same structure used by ps2_gxemu.self and ps2_softemu.self to store the CONFIGS<br>
Highly recommended to visit site below to understand this info:
There is a point of the hierarchy where is indicated the number of commands and the offset where are located. Every command is composed by ID[4] and data[4] (where the data coould be another offset to load more data from a deeper level of the hierarchy)<br>
http://problemkaputt.de/psx-spx.htm#gpustatusregister
That IDs differs in between the PS1 emulator versions because are not a direct ID, it seems every ID is mapped to a different ID (probably static and common for all emu versions) in a separated table
http://problemkaputt.de/psx-spx.htm#gpudisplaycontrolcommandsgp1
 
Offset in emu memory (ps1_netemu 4.86) | name | info
 
001B39D0 GP0_commands_table {ParamsCount, OPD}
0x10C5E4 GP1_reset_gpu
0x10C88C GP1_reset_command_buffer
0x10C940 GP1_acknowledge_gpu_IRQ1
0x10C968 GP1_display_enable
0x10C9A4 GP1_dma_direction___data_request
0x10CA20 GP1_display_mode
0x10CAEC GP1_get_gpu_info
0x10CB00 GP1_horizontal_display_range
0x10CB30 GP1_vertical_display_range
0x10CB60 GP1_start_of_display_area_in_VRAM
0x10CBD8 dma_dir_GPUREADtoCPU
0x10CD34 dma_dir_Off
 
Emulated GPU important data addresses.
0xD70BE4 E2_REG (used for immediate response by GPUINFO request)\
0xD70BE8 E3_REG (used for immediate response by GPUINFO request) \ Set by GP0 Ex cmds.
0xD70BEC E4_REG (used for immediate response by GPUINFO request) /
0xD70BF0 E5_REG (used for immediate response by GPUINFO request)/
0xD70C1C GP1_get_gpu_info_request (data supplied in GP1 0x10-0x1F cmd)
0xD70C20 GPUSTAT_r (PS1 GPU status register 1F801814 in read mode)
0xD70C24 dma_dir__data_req (from GP1 0x04 cmd)
0xD70C28 - 0xD70DA0 UNCONFIRMED seems to be GP0 fifo on PPU side, but need some reversing to confirm.
0xD70DA4 display_enable_request (based on GP1 0x03 cmd)
0xD70DA8 start_of_display_area_in_VRAM__X (from GP1 0x05 cmd)
0xD70DAC start_of_display_area_in_VRAM__Y (from GP1 0x05 cmd)
0xD70DB0 H_display_range_X1 (from GP1 0x06 cmd)
0xD70DB4 H_display_range_X2 (from GP1 0x06 cmd)
0xD70DB8 V_display_range_Y1 (from GP1 0x07 cmd)
0xD70DBC V_display_range_Y2 (from GP1 0x07 cmd)
0xD70DC0 H_resolution_1 (from GP1 0x08 cmd)
0xD70DC4 V_resolution (from GP1 0x08 cmd)
0xD70DC8 video_mode___is_pal (from GP1 0x08 cmd)
0xD70DCC display_area_color_depth (from GP1 0x08 cmd)
0xD70DD0 vertical_interlace (from GP1 0x08 cmd)
0xD70DD4 H_resolution_2 (from GP1 0x08 cmd)
0xD70DD8 reverse_flag (from GP1 0x08 cmd)
0xD70DEC display_enable (from GP1 0x03 cmd)
0xD70DF0 display_params_change_requested (1 when old display_mode != new from cmd 0x08)
0xD70DF4 display_mode (whole 8 bits of GP1 0x08)
 
 
Config GPU related commands.
Some values are not directly from cfg (are shifted before writing here, etc.).
0xD70E14 set_by_cmd_21
0xD70E18 set_by_cmd_22
0xD70E1C set_by_cmd_23
0xD70E20 set_by_cmd_24
0xD70E24 set_by_cmd_25
0xD70E28 set_by_cmd_26
0xD70E2C set_by_cmd_27
0xD70E30 set_by_cmd_28
0xD70E34 set_by_cmd_29
0xD70E38 set_by_cmd_2B
0xD70E3C set_by_cmd_2C
0xD70E40 set_by_cmd_2D
0xD70E44 set_by_cmd_2E
0xD70E48 set_by_cmd_2F
0xD70E4C set_by_cmd_20
0xD70E50 set_by_cmd_31
0xD70E54 set_by_cmd_30
</pre>
 
=== ps1_emu vs ps1_netemu GPU emulation differences ===
 
In some cracktros (Spyro 3, Sydney 2000, NFS Porsche 2000) the GP0 command E4h (E4080200) draws the image on the wrong coordinates, causing the frozen image of the zoomed PS1 licence screen. According to this [https://psx-spx.consoledev.net/graphicsprocessingunitgpu/#gp0e4h-set-drawing-area-bottom-right-x2y2 info], that command does make use of the newer 2MB VRAM GPU coordinates. Restricting the drawing area to the lower coordinates does fix the image. It looks like a lot of emulators are affected by this, either the Sony ones (ps1_emu on PS3, PS1 on PS2 hardware emulator, POPS on PSP) or the homebrew pSX 1.13. The ps1_netemu is displaying the image correctly. Does it mean the ps1_netemu emulate a different, newer GPU or just increase the emulation accuracy in general (assuming these cracktros work fine even on the oldest PSX released EDIT: I have found reports they are picky even on the original PS1 hardware too.)?
* Yes, this should fail also on old PS1 GPU. I can also confirm that PS1DRV (at least before deckard PS2 models) emulate old GPU model.
As for PS3. ps1_emu, and ps1_newemu emulate old GPU, ps1_netemu emulate new GPU at least partially. Also small tip, all emulators have pair of 2 embed
SPE ELFs. One is SPU emulator, second is GPU emulator. All of them have debug symbols.


ps1_emu
====How hardcoded config is read based on ps1emu.====
Like mentioned above config is created from 2x u32 values. Lets call first value command, and second value param.<br>
Command is used to calculate address for param, and only param is stored on obtained address.<br>
Emulator then check for params, and if found (usually when not zero) apply settings based on them.<br>
<pre>
<pre>
.text:000014D0 E4_cmd:                             
0x10BC8                lwz      r0, 0(r9)      # load HASH
.text:000014D0     il        r56, 0x3FF
0x10BCC                cmpw      cr7, r0, r27    # compare title HASH with one from DB
.text:000014D4     hbrr       loc_1504, loc_403C
0x10BD0                bne      cr7, loc_10BB8  # loop till HASH found
.text:000014D8     rotmi      r54, r12, -10       # r12 = whole 32 bit command
0x10BD4                slwi     r0, r10, 4      # config number << 4 to get offset from first entry in table
                                                  # r54 = is command shifted by 10 to skip
0x10BD8                addi     r24, r1, 0xAB0+var_A40
                                                  # x-cord. So now first bits are y-cord.
0x10BDC                extsw    r0, r0
.text:000014DC     lqr       r51, xmmword_E520
0x10BE0                clrldi    r3, r24, 32
.text:000014E0     and        r55, r12, r56      # x-cord and with whole 10 bits.
0x10BE4                add       r29, r0, r8    # r29 now points to game entry in config table
.text:000014E4      cwd        r53, 0xF0+var_F0(sp)
0x10BE8                lwz      r4, 4(r29)     # load pointer to game ID
.text:000014E8      cwd        r49, 0xF0+var_F0+8(sp)
0x10BEC                bl        sub_137FF8
.text:000014EC     ai        r52, r55, 1
0x10BF0                nop
.text:000014F0     andi       r50, r54, 0x1FF     # y-cord and with 0x1FF, so only 9 bits.
0x10BF4                lwz      r28, 8(r29)
0x10BF8                cmpwi    cr7, r28, 0
0x10BFC                ble       cr7, loc_10C58  # check config count is not 0 or less
0x10C00                lwz      r26, 0xC(r29)  # r26 is now pointer to configs for game
0x10C04                li        r30, 0
0x10C08                li        r29, 0
0x10C0C                lwz      r25, off_17B5D8 # "core.c: CoreCheckTitle: param[%d] = 0x%"...
0x10C10
0x10C10 read_conf_loop:                          # CODE XREF: CoreCheckTitle+2DC↓j
0x10C10                add      r11, r30, r26  # r11 is now pointer to currently read config for game
0x10C14                addi     r29, r29, 1    # count...
0x10C18                clrldi    r11, r11, 32
0x10C1C                mr       r3, r25        # just for print
0x10C20                addi     r30, r30, 8    # add 8 so next time in loop we read new config (4),
0x10C20                                          # and new params (4) if game have more than one config
0x10C24                lwz      r4, 0(r11)     # load command
0x10C28                lwz      r0, 4(r11)     # load params
0x10C2C                slwi     r9, r4, 2      # r9 = r4 << 2 so shift our command to the left by 2, and store in r9
0x10C30                clrldi    r5, r0, 32      # just print again
0x10C34                addi     r9, r9, 0x10    # add 0x10 to shifted command value
0x10C34                                          # to create address where param of config will be stored
0x10C38                extsw    r4, r4
0x10C3C                extsw    r9, r9
0x10C40                add       r9, r9, r31     # r31 is value that change between emu versions.
0x10C40                                          # That way emulator can keep correct config IDs without changes to table.
0x10C40                                          # r31 0x2B0930 + what we currently have in r9 after previous calculations.
0x10C44                stw      r0, 4(r9)      # Store param on finally calculated address + 4. For example for config 04
0x10C44                                          # address will be 0x2B0954.
0x10C48                bl        print_
0x10C4C                nop
0x10C50                cmpw      cr7, r28, r29  # r28 overall config count
0x10C50                                          # r29 currently read count
0x10C54                bne      cr7, read_conf_loop
</pre>
</pre>
====Known ps1emu.self commands====
* 0xB param is magic word for libcrypt, but emulator seems to not use it at all(?).
* 0xE param is divider for 0x204CC00 (psx cpu speed), result is stored on fixed address and used by many functions.
* 0x15 when param is set to 3, force game reload with ps1netemu. Is not known what other param values do.
* 0x19 is related to cdrom, xCdromRead use it as first argument.


ps1_netemu
== Commands Info ==
<pre>
.text:00003338 E4_cmd:                         
.text:00003338      rotmi      r18, r12, -10      # r12 = whole 32 bit command
                                                  # r18 = is command shifted by 10 to skip
                                                  # x-cord. So now first bits are y-cord.
.text:0000333C      hbrr      loc_3384, loc_3328
.text:00003340      il        r19, 0x3FF
.text:00003344      lqr        r39, xmmword_150D0
.text:00003348      il        r8, 0x200
.text:0000334C      lqr        r33, xmmword_150E0
.text:00003350      and        r44, r12, r19      # x-cord and with whole 10 bits.
.text:00003354      cwd        r42, arg_0+0xC(sp)
.text:00003358      and        r43, r18, r19      # y-cord and with 0x3FF, so whole 10 bits.
</pre>
---kozarovv.
 
== PS1 I/O handlers ==
List of functions that are responsible for interpreting HW registers reads/writes. Based on 4.86 ps1_netemu.
<pre>
timers_hwreg_write_handler  0xC2CC0
timers_hwreg_read_handler  0xC2F80
dma_hw_read_handler        0xD09C8
dma_hw_write_handler        0xD0E18
spu_hwreg_write_handler    0xD1E68
spu_hwreg_read_handler      0xD1FF8
joy_hwreg_write_handler    0xD44A8
joy_hwreg_read_handler      0xD49F8
sio_hwreg_write_handler    0xD758C
sio_hwreg_read_handler      0xD7620
cdr_hwreg_read_handler      0xD80A0
cdr_hwreg_write_handler    0xE8598
mdec_hwreg_write_handler    0xE9A18
mdec_hwreg_read_handler    0xEA2F0
i_ctrl_hwreg_read_handler  0x10577C
i_ctrl_hwreg_write_handler  0x1063AC
gpu_hwreg_read_handler      0x10BF40
gpu_hwreg_write_handler    0x10C48C
</pre>
 
== Experimental Patches ==
This patches are intended to be applyed to the PS1 emulators
 
==== Disable Dithering ====
Always set bit 9 in GP0 E1 command to 0. Patches apply to SPE PS1 GPU emulation program. Based on 4.86, but should be valid for all firmwares since 4.6x<br><br>
For ps1_emu.elf
<pre>
search for: 23 EC A4 04 23 E3 3B 85  33 7E 26 00 32 05 86 00 0F 3D C6 11
replace to: 23 EC A4 04 23 E3 3B 85  33 7E 26 00 32 05 86 00 40 80 00 11
</pre>
 
For ps1_netemu.elf
<pre>
search for: 7C 38 41 94 20 7F F4 94 0F 3D C6 3C 12 7F F3 8A
replace to: 7C 38 41 94 20 7F F4 94 40 80 00 3C 12 7F F3 8A
</pre>
 
For ps1_newemu.elf
<pre>
search for: 20 7F FD 4C 23 9D C5 85  32 05 B2 80 12 05 B2 0B 0F 3D C6 58
replace to: 20 7F FD 4C 23 9D C5 85  32 05 B2 80 12 05 B2 0B 40 80 00 58
</pre>
 
Patch for rpcs3 (newemu only) for testing purpose.
<pre>
Version: 1.2
 
SPU-f3d8be702bf4cb8545656e37c29fcc6201a57991:
  "Disable Dithering":
    Games:
      All:
        All: [ All ]
    Author: "kozarovv"
    Patch Version: 1.0
    Patch:
      - [ be32, 0xFB0, 0x40800058 ]
</pre>
 
==== Allow non encrypted ISO.BIN.EDAT and skip signature check (RPCS3 only) ====
For easier config testing. Patch allow to use unencrypted ISO.BIN.EDAT so we don't need to mess with klic. Also ECDSA signature at the end of file is no longer required. So we can ftp configs as is, for faster testing. Warning! This patch break official ps1_classics.
<br><br>
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
0xE13C4 replace 60 00 00 00 to 38 60 00 00
 
==== GTE Automatic Widescreen Hack ====
Automatic widescreen without per game patches. Work only for 3D elements (like 95% of available widescreen patches).<br>
Tested on both RPCS3 and real PS3 (CFW only, but can be added to hen).<br>
ps1_netemu.elf 4.86 - 4.91 offsets in raw hex (for Hxd, etc.)
0x2BDA4 original code:
    7C 69 1B 78 3C 60 80 54 2F 89 00 00 60 63 00 10
    40 9E 00 14 3C 60 80 54 60 63 00 02 7C 63 07 B4
    4E 80 00 20 A0 09 00 02 2F 80 00 00 41 9E FF F0
    C0 02 A3 D8 FF 81 00 00 41 9D FF DC C0 02 A3 DC
    38 60 00 00 FF 81 00 00 41 9C FF CC D0 29 00 6C
    4B FF FF CC
replace to:
    78 C0 F8 42 78 C6 F0 82 7C C6 02 14 7D 08 32 14
    48 0C 47 7E 78 E9 F8 42 78 E7 F0 82 7C E9 3A 14
    7C C6 3A 14 48 0C 65 66 79 00 F8 42 79 08 F0 82
    7D 08 02 14 7C C6 42 14 48 0C 69 0A 79 00 F8 42
    79 08 F0 82 7D 08 02 14 7C C6 42 14 48 0C 6C 6A
    60 00 00 00
0xB4778  original code: 7D 08 32 14 replace to: 48 03 BD A6
0xB6560  original code: 7C C6 3A 14 replace to: 48 03 BD BA
0xB6904  original code: 7C C6 42 14 replace to: 48 03 BD CE
0xB6C64  original code: 7C C6 42 14 replace to: 48 03 BD E2
 
== Ps1_netemu Commands Info ==
 
=== 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.
The offsets below are the offsets from the start of the PSISOIMG section. This data starts at absolute file offset 0x424 for single disk games that do not use a PSTITLEIMG section. For games that do have a PSTITLEIMG section, the absolute offset will be shifted by 0x400 bytes, i.e. to offset 0x824 and similar.
* 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 first config command
* Offset 0x430 param for first command
* This repeats 8 times as only 8 commands is supported.
* Command 2 is unsupported.
* Command 0 is unsupported because $ony made mistake in parser.
* Command 0x17 is supported, but there is different official way to inject it, and it is libcrypt key so there is no point to do it this way.
This probably repeats for multidiscs, but for now let's figure out single discs first.
<br>Function that search for configs look like this:
case 9:
  if ( *(&0x161FD80) ) 1570FA0(base) + AEDE0(offset in ISO.BIN.DAT or PSISOIMG? ) = 161FD80 in 4.86 ps1_netemu
  {
    cfg_rev = get_cfg_rev_from_PSIMG();
    db_rev = get_titledb_rev();
    decimal_16 = ret_32() >> 1;
    tty_print("ad hoc param: %x <%x>\n", cfg_rev, db_rev);
    if ( decimal_16 )
    {
      low_rev = cfg_rev < db_rev;          // Check is opposite to ps2_netemu, only config version higher than included db will pass.
                                            // Which mean config need to be higher version than emu database.
      for ( i = 0; i < decimal_16; i += 2 ) // up to 8 configs supported (8 commands + 8 values)
      {
        cfg_command = read_cfg_from_PSIMG(i);
        _cfg_value = read_cfg_from_PSIMG(i + 1);
        if ( cfg_command - 1 <= 0x3B )      // max cfg nr 0x3C
        {
          v245 = cfg_command >> 28;        // Most likely check for wrong endianess. Configs are LE and are byte reversed before we end up here.
          if ( low_rev || v245 || cfg_command == 2 )// cfg 2 unsupported (replaced in later PSIMG rev with subchannel data), or old config rev, or v245.
          {
            tty_print("%x: %2d=0x%08x ***\n", v245 & 0xF, cfg_command, _cfg_value); // Ignore cfg
          }
          else
          {
            cfg_value = _cfg_value;
            tty_print("%x: %2d=0x%08x\n", 0LL, cfg_command, _cfg_value);
            WriteInternalConfigValue(cfg_command, cfg_value);
          }
        }
      }
    }
  }
 
=== Command IDs mapping ===
The command IDs differs in between the PS1 emulator types and versions because are an indirect ID, it seems every command ID is mapped to a static ID in a separated table<br>
The command ID's varies in between firmware versions, most probably because new functions was added every few versions, reorganized, etc... and this changes created a "displacement" of the old commands that causes them to increase his ID<br>
The command ID's varies in between firmware versions, most probably because new functions was added every few versions, reorganized, etc... and this changes created a "displacement" of the old commands that causes them to increase his ID<br>
At the time of writing this we dont know how to map that variable ID's to an static ID (that could be valid for all firmware versions), so by now in this list is needed to indicate the firmware version where the command ID was found<br>
At the time of writing this we dont know how to map that variable ID's to an static ID (that could be valid for all firmware versions), so by now in this list is needed to indicate the firmware version where the command ID was found
Coincidentially there are a few commands that preserves his ID in between emulator types and revisions, most probably is because are the first commands implemented and the variable ID given to them is a very low value, so always was kept at a low position in the commands list and was not disturbed by the modifications made to the other commands.
 
=== Command 0x00 (netemu 3.40 up to 4.88) ===
*Valid values found
**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)
*Um Jammer Lammy (SCPS-18011) uses somewhat new external config revision (11580) in official classic's external config, but only uses command 0x13. Keep in mind the game was released Febuary 27, 2008, so package was possibly updated with new config at some point, and then in internal table, so maybe it once had a different config command in config table and 0x00 nullified it. Langrisser IV (SLPS-01818) has old config revision (5713) and uses command 0x03 set to 0x3E8, so just default. Maybe internal config for Langrisser IV is empty config just to also nullify external config? --[[User:Mrjaredbeta|Mrjaredbeta]] ([[User talk:Mrjaredbeta|talk]]) 03:32, 1 September 2023 (CEST)


=== Command 0x01 (netemu 3.40 up to 4.88) ===
=== Command 0x01 (netemu 3.40 up to 4.88) ===
Used by SLPM_865.49, SLPM_865.50, SLPS_017.16, SLPS_004.16, SLUS_004.33)
*Valid values found
*Valid values found
**1 = ? (used by SLPS_004.16, SLUS_004.33)
**2 (in SLPM_865.49, SLPM_865.50, SLPS_017.16)
**2 = ? (used by SLPM_865.49, SLPM_865.50, SLPS_017.16)
**1 (in SLPS_004.16, SLUS_004.33)


=== Command 0x02 (netemu 3.40 up to 4.88) ===
=== Command 0x02 (netemu 3.40 up to 4.88) ===
There are only 3 games using this command and are libcrypt protected games:, Crash Team Racing (SCES-02105), MediEvil (SCES-00311), and Vagrant Story (SLES-02754)<br>
Coincidentially this is one of the few commands that preserves his ID in between firmware versions, most probably is because it was one of the first commands implemented (is either the second or the third from the whole command list) and the variable ID given to it is a very low value (so always was kept at a low position in the commands list and was not disturbed by the modifications made to the other commands)<br>
The command data contains an offset that points to an area where are stored a list of sectors (4 bytes each). When the emulator starts reading the list it doesnt knows how long is it so it reads groups of 4 bytes consecutivelly until it finds the value 00000000 that works as a terminator, the presence of this terminator at the end of the sector list is mandatory. Worth to note that list is more extensive than redump libcrypt one, but they match to some extend. Probably redump store only sectors really needed to run game correctly, while Sony decided to keep them all. Command is used only with LC1 games (Redump is wrong about medievil, is LC1).<br>
Is used to load a list of sectors, there are only 3 games using it (and the 3 games are libcrypt protected), as example this is the data loaded by Medievil (SCES_003.11), located at absolute offset 0x16298C in ps1_netemu.self from firmware 4.88
The libcrypt protection is related with subchannel data stored by sectors, in redump.org this data is managed with the SBI files, displayed in a hexeditor view in each specific game page. If we convert the data from the official format to decimal and we compare it with the sector numbers in the redump.org SBI file it can be seen all the libcrypt protected sectors from the SBI file are included in the official format<br>
<pre>
The official format seems to include a lot more sectors which purpose is unknown<br>
There seems to be way to supply that data/command from external file. Some research by "Fedor Wearing A Fedora" [https://www.psx-place.com/threads/ps1-libcrypt-support-on-ps3-official-emus-research-thread.35836/page-13#post-318218 here] and [https://www.psx-place.com/threads/ps1-libcrypt-support-on-ps3-official-emus-research-thread.35836/page-13#post-318506 here]<br>
 
<u>Crash Team Racing</u> [http://redump.org/disc/798/ SCES-02105] (at absolute offset 0x1627E4 in ps1_netemu.self 4.83-4.88)
<small><pre style="height:410px">
Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F
 
001627E0              00 00 06 A3 00 00 0E 21 00 00 17 79      ...£...!...y
001627F0  00 00 29 CB 00 00 2B 21 00 00 2E 22 00 00 31 31  ..)Ë..+!..."..11
00162800  00 00 37 19 00 00 37 1E 00 00 38 35 00 00 38 95  ..7...7...85..8•
00162810  00 00 38 9A 00 00 3A D0 00 00 3A D5 00 00 3B 1A  ..8š..:Ð..:Õ..;.
00162820  00 00 3B 1F 00 00 3B D0 00 00 3B D5 00 00 3C 12  ..;...;Ð..;Õ..<.
00162830  00 00 3C 17 00 00 3D 0C 00 00 3D 11 00 00 3F 27  ..<...=...=...?'
00162840  00 00 3F 2C 00 00 48 91 00 00 55 35 00 00 57 A1  ..?,..H‘..U5..W¡
00162850  00 00 58 38 00 00 59 38 00 00 5B 67 00 00 62 A9  ..X8..Y8..[g..b©
00162860  00 00 62 C5 00 00 78 4F 00 00 78 CA 00 00 7E 94  ..bÅ..xO..xÊ..~”
00162870  00 00 90 30 00 00 9A D5 00 00 9E 05 00 00 A4 3D  ...0..šÕ..ž...¤=
00162880  00 00 A4 42 00 00 A5 C0 00 00 A5 C5 00 00 A8 04  ..¤B..¥À..¥Å..¨.
00162890  00 00 A8 09 00 00 A8 A9 00 00 A8 AE 00 00 A9 5A  ..¨...¨©..¨®..©Z
001628A0  00 00 A9 5F 00 00 A9 90 00 00 A9 95 00 00 AA 72  ..©_..©...©•..ªr
001628B0  00 00 AA 77 00 00 AD 18 00 00 AD 1D 00 00 C5 5C  ..ªw........Å\
001628C0  00 00 EC 56 00 00 FB CA 00 01 04 52 00 01 04 7C  ..ìV..ûÊ...R...|
001628D0  00 01 08 F4 00 01 22 A3 00 01 26 79 00 01 2F 8B  ...ô.."£..&y../‹
001628E0  00 01 2F A6 00 01 2F CE 00 01 53 A8 00 01 79 10  ../¦../Î..S¨..y.
001628F0  00 01 86 0D 00 01 C3 96 00 01 CD 83 00 01 EA 08  ..†...Ö..̓..ê.
00162900  00 01 F6 92 00 02 02 57 00 02 1C 08 00 02 53 85  ..ö’...W......S…
00162910  00 02 91 5D 00 02 93 8F 00 02 93 A6 00 02 AB 93  ..‘]..“...“¦..«“
00162920  00 02 AB FB 00 02 BC 8C 00 02 CA 39 00 02 D2 17  ..«û..¼Œ..Ê9..Ò.
00162930  00 02 F1 35 00 03 16 06 00 03 4A 45 00 03 4C B6  ..ñ5......JE..L¶
00162940  00 03 68 26 00 03 6B 1D 00 03 92 B8 00 03 92 F2  ..h&..k...’¸..’ò
00162950  00 03 9B 5D 00 03 A7 76 00 03 BA 90 00 03 C5 1A  ..›]..§v..º...Å.
00162960  00 03 C5 41 00 03 C5 A3 00 03 FC F1 00 03 FD DA  ..ÅA..Å£..üñ..ýÚ
00162970  00 04 14 C2 00 04 1F 49 00 04 26 57 00 04 87 5F  ...Â...I..&W..‡_
00162980  00 04 8E 65 00 04 C0 DA 00 00 00 00              ..Že..ÀÚ....
 
 
000006A3
00000E21
00001779
000029CB
00002B21
00002E22
00003131
00003719 --- to decimal ---> 14105 (mentioned in the redump SBI file)
0000371E --- to decimal ---> 14110 (mentioned in the redump SBI file)
00003835
00003895 --- to decimal ---> 14485 (mentioned in the redump SBI file)
0000389A --- to decimal ---> 14490 (mentioned in the redump SBI file)
00003AD0 --- to decimal ---> 15056 (mentioned in the redump SBI file)
00003AD5 --- to decimal ---> 15061 (mentioned in the redump SBI file)
00003B1A --- to decimal ---> 15130 (mentioned in the redump SBI file)
00003B1F --- to decimal ---> 15135 (mentioned in the redump SBI file)
00003BD0 --- to decimal ---> 15312 (mentioned in the redump SBI file)
00003BD5 --- to decimal ---> 15317 (mentioned in the redump SBI file)
00003C12 --- to decimal ---> 15378 (mentioned in the redump SBI file)
00003C17 --- to decimal ---> 15383 (mentioned in the redump SBI file)
00003D0C --- to decimal ---> 15628 (mentioned in the redump SBI file)
00003D11 --- to decimal ---> 15633 (mentioned in the redump SBI file)
00003F27 --- to decimal ---> 16167 (mentioned in the redump SBI file)
00003F2C --- to decimal ---> 16172 (mentioned in the redump SBI file)
00004891
00005535
000057A1
00005838
00005938
00005B67
000062A9
000062C5
0000784F
000078CA
00007E94
00009030
00009AD5
00009E05
0000A43D --- to decimal ---> 42045 (mentioned in the redump SBI file)
0000A442 --- to decimal ---> 42050 (mentioned in the redump SBI file)
0000A5C0 --- to decimal ---> 42432 (mentioned in the redump SBI file)
0000A5C5 --- to decimal ---> 42437 (mentioned in the redump SBI file)
0000A804 --- to decimal ---> 43012 (mentioned in the redump SBI file)
0000A809 --- to decimal ---> 43017 (mentioned in the redump SBI file)
0000A8A9 --- to decimal ---> 43177 (mentioned in the redump SBI file)
0000A8AE --- to decimal ---> 43182 (mentioned in the redump SBI file)
0000A95A --- to decimal ---> 43354 (mentioned in the redump SBI file)
0000A95F --- to decimal ---> 43359 (mentioned in the redump SBI file)
0000A990 --- to decimal ---> 43408 (mentioned in the redump SBI file)
0000A995 --- to decimal ---> 43413 (mentioned in the redump SBI file)
0000AA72 --- to decimal ---> 43634 (mentioned in the redump SBI file)
0000AA77 --- to decimal ---> 43639 (mentioned in the redump SBI file)
0000AD18 --- to decimal ---> 44312 (mentioned in the redump SBI file)
0000AD1D --- to decimal ---> 44317 (mentioned in the redump SBI file)
0000C55C
0000EC56
0000FBCA
00010452
0001047C
000108F4
000122A3
00012679
00012F8B
00012FA6
00012FCE
000153A8
00017910
0001860D
0001C396
0001CD83
0001EA08
0001F692
00020257
00021C08
00025385
0002915D
0002938F
000293A6
0002AB93
0002ABFB
0002BC8C
0002CA39
0002D217
0002F135
00031606
00034A45
00034CB6
00036826
00036B1D
000392B8
000392F2
00039B5D
0003A776
0003BA90
0003C51A
0003C541
0003C5A3
0003FCF1
0003FDDA
000414C2
00041F49
00042657
0004875F
00048E65
0004C0DA
00000000
</pre></small>
 
<u>MediEvil</u> [http://redump.org/disc/592/ SCES-00311] (at absolute offset 0x16298C in ps1_netemu.self 4.83-4.88)
<small><pre style="height:275px">
Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F
Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F


Line 443: Line 481:
00162A70  00 02 E1 3A 00 02 F2 18 00 02 FC C8 00 03 51 CF  ..á:..ò...üÈ..QÏ
00162A70  00 02 E1 3A 00 02 F2 18 00 02 FC C8 00 03 51 CF  ..á:..ò...üÈ..QÏ
00162A80  00 03 52 AA 00 03 72 3F 00 00 00 00              ..Rª..r?....
00162A80  00 03 52 AA 00 03 72 3F 00 00 00 00              ..Rª..r?....
</pre>


 
The libcrypt protection is related with subchannel data stored by sectors, in redump this data is managed with the SBI files, displayed in a hexeditor view in the game page http://redump.org/disc/592/<br>
If we convert the data from the official format to decimal and we compare it with the sector numbers in the SBI file it can be seen the 16 libcrypt protected sectors from the SBI file are included in the official format<br>
The official format seems to include a lot more sectors which purpose is unknown<br>
This is the medievil data from the official format, converted to decimal, and marked the sectors that matches with the SBI file in redump
<pre>
00000615 --- to decimal ---> 1557
00000615 --- to decimal ---> 1557
00002A75 --- to decimal ---> 10869
00002A75 --- to decimal ---> 10869
Line 509: Line 552:
0003723F --- to decimal ---> 225855
0003723F --- to decimal ---> 225855
00000000
00000000
</pre></small>
</pre>
 
<u>Vagrant Story</u> [http://redump.org/disc/9978/ SLES-02754] (at absolute offset 0x162A8C in ps1_netemu.self 4.83-4.88)
<small><pre style="height:350px">
Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F
 
00162A80                                      00 00 14 B5              ...µ
00162A90  00 00 38 F3 00 00 38 F8 00 00 39 39 00 00 39 3E  ..8ó..8ø..99..9>
00162AA0  00 00 3A 33 00 00 3A 38 00 00 3A D0 00 00 3A D5  ..:3..:8..:Ð..:Õ
00162AB0  00 00 3B 1A 00 00 3B 1F 00 00 3B 8A 00 00 3B 8F  ..;...;...;Š..;.
00162AC0  00 00 3B D0 00 00 3B D5 00 00 3F 27 00 00 3F 2C  ..;Ð..;Õ..?'..?,
00162AD0  00 00 3F AA 00 00 90 84 00 00 A6 54 00 00 A6 59  ..?ª...„..¦T..¦Y
00162AE0  00 00 A6 AF 00 00 A6 B4 00 00 A7 3D 00 00 A7 42  ..¦¯..¦´..§=..§B
00162AF0  00 00 A8 04 00 00 A8 09 00 00 A8 A9 00 00 A8 AE  ..¨...¨...¨©..¨®
00162B00  00 00 A9 19 00 00 A9 1E 00 00 A9 5A 00 00 A9 5F  ..©...©...©Z..©_
00162B10  00 00 AD 18 00 00 AD 1D 00 00 BD D6 00 00 BE B1  ........½Ö..¾±
00162B20  00 00 BF AC 00 00 C9 BC 00 00 E5 11 00 01 07 06  ..¿¬..ɼ..å.....
00162B30  00 01 0C 80 00 01 18 E0 00 01 1E 36 00 01 41 46  ...€...à...6..AF
00162B40  00 01 55 E7 00 01 71 BF 00 01 D2 F5 00 01 D8 B5  ..Uç..q¿..Òõ..ص
00162B50  00 01 E4 5A 00 01 E6 29 00 01 F1 FD 00 01 FE B9  ..äZ..æ)..ñý..þ¹
00162B60  00 02 40 5D 00 02 59 9A 00 02 59 ED 00 02 5A 2F  ...]..Yš..Yí..Z/
00162B70  00 02 8B F6 00 02 8C A0 00 02 8C C2 00 02 A0 62  ..‹ö..Œ ..ŒÂ.. b
00162B80  00 02 DD 59 00 02 FD F1 00 03 0B FC 00 03 0C 26  ..ÝY..ýñ...ü...&
00162B90  00 03 9A B1 00 03 A9 E1 00 03 BC 7F 00 03 E1 B9  ..š±..©á..¼...á¹
00162BA0  00 03 E2 08 00 03 F8 8F 00 04 01 72 00 04 05 91  ..â...ø....r...‘
00162BB0  00 04 13 8F 00 04 3E D8 00 04 40 DC 00 04 48 94  ......>Ø...Ü..H”
00162BC0  00 04 67 FB 00 04 78 2C 00 04 8A CE 00 04 B4 A0  ..gû..x,..ŠÎ..´
00162BD0  00 04 B9 60 00 04 BE 93 00 04 C3 0C 00 04 CB 0E  ..¹`..¾“..Ã...Ë.
00162BE0  00 04 CB C9 00 04 D5 C8 00 00 00 00              ..ËÉ..ÕÈ....
 
 
000014B5
000038F3 --- to decimal ---> 14579 (mentioned in the redump SBI file)
000038F8 --- to decimal ---> 14584 (mentioned in the redump SBI file)
00003939 --- to decimal ---> 14649 (mentioned in the redump SBI file)
0000393E --- to decimal ---> 14654 (mentioned in the redump SBI file)
00003A33 --- to decimal ---> 14899 (mentioned in the redump SBI file)
00003A38 --- to decimal ---> 14904 (mentioned in the redump SBI file)
00003AD0 --- to decimal ---> 15056 (mentioned in the redump SBI file)
00003AD5 --- to decimal ---> 15061 (mentioned in the redump SBI file)
00003B1A --- to decimal ---> 15130 (mentioned in the redump SBI file)
00003B1F --- to decimal ---> 15135 (mentioned in the redump SBI file)
00003B8A --- to decimal ---> 15242 (mentioned in the redump SBI file)
00003B8F --- to decimal ---> 15247 (mentioned in the redump SBI file)
00003BD0 --- to decimal ---> 15312 (mentioned in the redump SBI file)
00003BD5 --- to decimal ---> 15317 (mentioned in the redump SBI file)
00003F27 --- to decimal ---> 16167 (mentioned in the redump SBI file)
00003F2C --- to decimal ---> 16172 (mentioned in the redump SBI file)
00003FAA
00009084
0000A654 --- to decimal ---> 42580 (mentioned in the redump SBI file)
0000A659 --- to decimal ---> 42585 (mentioned in the redump SBI file)
0000A6AF --- to decimal ---> 42671 (mentioned in the redump SBI file)
0000A6B4 --- to decimal ---> 42676 (mentioned in the redump SBI file)
0000A73D --- to decimal ---> 42813 (mentioned in the redump SBI file)
0000A742 --- to decimal ---> 42818 (mentioned in the redump SBI file)
0000A804 --- to decimal ---> 43012 (mentioned in the redump SBI file)
0000A809 --- to decimal ---> 43017 (mentioned in the redump SBI file)
0000A8A9 --- to decimal ---> 43177 (mentioned in the redump SBI file)
0000A8AE --- to decimal ---> 43182 (mentioned in the redump SBI file)
0000A919 --- to decimal ---> 43289 (mentioned in the redump SBI file)
0000A91E --- to decimal ---> 43294 (mentioned in the redump SBI file)
0000A95A --- to decimal ---> 43354 (mentioned in the redump SBI file)
0000A95F --- to decimal ---> 43359 (mentioned in the redump SBI file)
0000AD18 --- to decimal ---> 44312 (mentioned in the redump SBI file)
0000AD1D --- to decimal ---> 44317 (mentioned in the redump SBI file)
0000BDD6
0000BEB1
0000BFAC
0000C9BC
0000E511
00010706
00010C80
000118E0
00011E36
00014146
000155E7
000171BF
0001D2F5
0001D8B5
0001E45A
0001E629
0001F1FD
0001FEB9
0002405D
0002599A
000259ED
00025A2F
00028BF6
00028CA0
00028CC2
0002A062
0002DD59
0002FDF1
00030BFC
00030C26
00039AB1
0003A9E1
0003BC7F
0003E1B9
0003E208
0003F88F
00040172
00040591
0004138F
00043ED8
000440DC
00044894
000467FB
0004782C
00048ACE
0004B4A0
0004B960
0004BE93
0004C30C
0004CB0E
0004CBC9
0004D5C8
00000000
</pre></small>


=== Command 0x03 (netemu 3.40 up to 4.88) ===
=== Command 0x03 (netemu 3.40 up to 4.88) ===
*Valid values found: 0x32 (50d), 0xC8 (200d), 0x12C (300d), 0x1F4 (500d), 0x258 (600d), 0x2BC (700d), 0x320 (800d), 0x384 (900d), 0x44C (1100d), 0x4B0 (1200d), 0x578 (1400d), 0x5DC (1500d), 0x708 (1800d)<br>
Command ID 0x03 seems to match too in between firmware 3.55 and 4.88
*Default value: 0x3E8
*_xcdrom_thread related.
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>
*Possible disc read speed delay or adjustment. Larger value results in slower loading times. --[[User:Mrjaredbeta|Mrjaredbeta]] ([[User talk:Mrjaredbeta|talk]]) 03:21, 1 September 2023 (CEST)
'''Custom Usage:'''
*Param 0x384 (900d) fixes Vampire Hunter D (SLUS-01138) hanging issues.
*Param 0x1F4 (500d) fixes Medievil 2 audio and hanging issues.


=== 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 (-200d)
Command ID 0x04 seems to match too in between firmware 3.55 and 4.88
*Default value: 0
*_xcdrom_thread related.
Possible seek delay/adjustment.<br>
'''Custom Usage:'''
*Param 0x64 and above fixes Transformers: Beast Wars Transmetals (SLUS-01160). 0x14 also gets past initial main menu screen, but hangs when loading into a stage. Param 0xC8 is probably safest.
 
=== Command 0x05 (netemu 3.40 up to 4.88) ===
<strike>The game configs inside ps1_netemu.self 3.40 doesnt seems to use this command, so is not posible to see if it matches in between 3.40 and 3.55/4.88</strike> but we can assume is the same ID through netemu 3.40 up to 4.88 because higher command IDs (such 0x08) maintained his ID since 3.40
*Default value: 0
*_xcdrom_thread related.
 
=== Command 0x06 (netemu 4.83 up to 4.88) ===
*Default value: 0
*_xcdrom_thread related.
'''Custom Usage:'''
*Param 0x01 fixes Shrek Treasure Hunt (SLUS-01463) minigame loading screen hangs.
*Param 0x01 fixes Fear Effect (SLUS-00920) hang when pressing START at menu screen.
 
=== Command 0x07 (netemu 4.83 up to 4.88) ===
*Default value: 0
*_xcdrom_thread related.
'''Custom Usage:'''
*Param 0x01 fixes Fear Effect (SLUS-00920) other issues in main menu, such as graphical corruption in options screens, and returning to options screen after viewing credits.
 
=== Command 0x08 (netemu 3.40 up to 4.88) ===
*Valid values found: 0xC8 (200d), 0x12C (300d), 0x1F4 (500d), 0x2BC (700d), 0x320 (800d). It seems to be an small selection of the same values used by command 0x03
*Default value: 0x3E8
*_xcdrom_thread related.
 
=== Command 0x0B (netemu 4.83 up to 4.88) ===
*Or command 0x09 (netemu 3.40)
*Valid values found: 0x27104E95 (in netemu 3.40 and 4.88). It seems to be composed by 2 values of 2 bytes size: 0x2710(hex)=10000(dec). And 0x4E95(hex)=20117(dec)
The command data  seems to be a bit special, is a value higher than any other command, but is the same value along different ps1_netemu.self revisions, so is not an offset. There is only one game using this command: [https://psxdatacenter.com/games/J/L/SLPS-03012.html SLPS_030.12]
 
=== Command 0x0E (netemu 4.83 up to 4.88) ===
*Or command 0x0C (netemu 3.40)
*Default value: 0x1F4
*_xcdrom_thread related.
 
=== Command 0x0F (netemu 4.83 up to 4.88) ===
*Or command 0x0D (netemu 3.40)
*Default value: 0xFA
*_xcdrom_thread related.
 
=== Command 0x10 (netemu 4.83 up to 4.88) ===
*Default value: 0xFA
*_xcdrom_thread related.


=== Command 0x11 (netemu 4.83 up to 4.88) ===
=== Command 0x05 (netemu 3.55 up to 4.88) ===
*Default value: 0x7D
Command ID 0x05 seems to match too in between firmware 3.55 and 4.88<br>
*_xcdrom_thread related.
The game configs inside ps1_netemu.self 3.40 doesnt seems to use this command
 
=== Command 0x12 (netemu 4.83 up to 4.88) ===
*Or command 0x10 (netemu 3.40)
Command value are flags/settings to alter cdrom behavior.
*0x800 = Different code path for MotorOn/Pause/SetSession cdrom commands. // Need more work, flag affect more than that.
 
=== Command 0x13 (netemu 4.83 up to 4.88) ===
*Default value: 0
*MDEC related?
'''Custom Usage:'''
*Param 0x01 fixes Roland Garros French Open 2001 (SLES-03449) hang when loading into a match.
*Param 0x01 fixes Fear Effect (SLUS-00920) hang when pressing START at menu screen (sometimes).
 
=== Command 0x14 (netemu 4.83 up to 4.88) ===
*Default value: 4
 
=== Command 0x15 (netemu 4.83 up to 4.88) ===
*Default value: 4
 
=== Command 0x16 (netemu 4.83 up to 4.88) ===
*Default value: 0
*DMA timing related.
'''Custom Usage:'''
*Param 0x32 is enough to fix International Superstar Soccer (SLES-02550) black screen after PlayStation logo.
*Param 0x08 is enough to fix Vampire Hunter D’s main menu flashing.


=== Command 0x17 (netemu 4.83 up to 4.88) ===
=== Command 0x17 (netemu 4.83 up to 4.88) ===
*Or command 0x0B (netemu 1.70)
*Or command 0x0A (netemu 2.10)
*Or command 0x15 (netemu 3.40 up to 3.55)
*Or command 0x15 (netemu 3.40 up to 3.55)
*Or command 0x0B (emu 1.70 up to 4.88)
*Or command 0x0B (emu 3.40 up to 4.88)
*Or command 0x07 (newemu 2.10)
*Or command 0x0A (newemu 3.40 up to 4.88)
*Or command 0x0A (newemu 3.40 up to 4.88)
This is the libcrypt magic word. This command is used only in 3 games (SCES_016.95, SLES_019.07, SLES_013.01). see: [[PS1 Custom Patches]]
This is the libcrypt magic word. This command is used only in 3 games (SCES_016.95, SLES_019.07, SLES_013.01). see: [[PS1 Custom Patches]]
In ps1_netemu there is possibility to setup that command from one of ps1 classic files (PSISOIMG0000 / PSTITLEIMG000000 related).
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.
* 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) ===
Substrat cycles from mdec_block_copy_out_callback delta. When mdec is decoding blocks, copy out happen on every completed 6th block. This is hardcoded to take 0xB00 (2816) cycles in ps1_netemu. By using this config we can make this value less than default, which in turn "overclock" mdec decoding as every 6xblock will be decoded faster. Duckstation by default use value 0xA80 (2688 (448 x 6 blocks)). So to make config that will replicate this behavior we need set config value to 0x80 (0xB00 - 0x80 = 0xA80).
*Default value: 0
*Valid values range: 0x000 - 0xB00
*Higher values are ignored and 0 is set (just like when you use 0xB00 value), making MDEC instant.
=== Command 0x19 (netemu 4.83 up to 4.88) ===
*Default value: 4
*Set in same place where bios image is loaded, and region check/patch is performed.
=== Command 0x1A (netemu 4.83 up to 4.88) ===
Set PS1 PS1 Scratchpad address 0x1F800000 - 0x1F8003FF to given 4 bytes value. Only one game use this, game seems to expect memory initialized to 0xFFFFFFFF, while never do this.
*Default value: 0
=== Command 0x1B (netemu 4.83 up to 4.88) ===
*Default value: 0x3E8
Multiplier for GTE commands cycles. Value from config is multiplied by 256, and then divided by 1000.
For example Battle Arena Toshinden use 0xC8 which result in 0x33(51) as value that is later used.
Default value 0x3E8 end as 0x100(256).
=== Command 0x1C (netemu 4.83 up to 4.88) ===
*Or command 0x18 (netemu 3.40)
*Or command 0x1A (netemu 3.55 ?)
*Or command 0x02 (netemu 1.70) - possibly different command
Param flags:
*1 = unk.
*2 = Set Vibration to Off (menu to set it to On is still accessible, but command seems to also skip initializing of vibration internal struct/settings).
=== Command 0x1D (netemu 4.83 up to 4.88) ===
*Default value: 0
*Correct values 0 / 1 / 2
Config seems to setup default gamepads layout for multitap.
*0 = <0, 2, 4, 6, 1, 3, 5, 7>
*1 = <0, 2, 3, 4, 1, 5, 6, 7>
*2 = <0, 1, 2, 3, 4, 5, 6, 7>
Sync order of controllers is always the same regardless of parameter set (1/1-A, 2/2-A, 1-B, 2-B, 1-C, 2-C, 1-D). Therefore, change is only reflected internally in emulated game. For example, Crash Bash needs parameter 2 for controllers to be set properly in game, but order in which controllers physically connect is not changed.
=== Command 0x1E (netemu 4.83 up to 4.88) ===
*Default value: 0x7D0
*xPadThread related.
=== Command 0x20 (netemu 4.83 up to 4.88) ===
GPU multi command (bifield)
*Default value: 0
*0x08 = Always set Vertical Interlace bit in GPUSTAT to 0 on GP1 (08h) command.
*0x40 = Is not exactly known what happen under the hood, but this command allow to play 50Hz titles in 60Hz with correct speed.
=== Command 0x21 (netemu 4.83 up to 4.88) ===
*Default value: 0x3E8
*PS1 GPU related.
=== Command 0x22 (netemu 4.83 up to 4.88) ===
*Default value: 0x3E8
*PS1 GPU related.
Seems to fix slowdown in Rapid Racer (SCPS-10060) with value 0x320.
=== Command 0x23 (netemu 4.83 up to 4.88) ===
*Default value: 0x3E8
*PS1 GPU related.
=== Command 0x24 (netemu 4.83 up to 4.88) ===
*Default value: 7
*PS1 GPU related.
=== Command 0x25 (netemu 4.83 up to 4.88) ===
*Default value: 0
*PS1 GPU related.
=== Command 0x2A (netemu 4.83 up to 4.88) ===
*Default value: 0
*PS1 GPU related.
=== Command 0x2B (netemu 4.83 up to 4.88) ===
*Default value: 0
*PS1 GPU related.
=== Command 0x2C (netemu 4.83 up to 4.88) ===
*Default value: 0
*PS1 GPU related.
=== Command 0x2D (netemu 4.83 up to 4.88) ===
*Default value: 0
*PS1 GPU related.
=== Command 0x31 (netemu 4.83 up to 4.88) ===
GPU multi command (bitfield)
*0x02 = Enable Vertical Interlace bit in GP1 (08h) command in SPE writes (in renderer only). Emulator by default use hack where VI bit is ALWAYS disabled in spe.
Note from nocash docs about Vertical Interlace: ''"'''Interlace must be enabled to see all lines in 480-lines mode''' (interlace is causing ugly flickering, so a non-interlaced low resolution image is typically having better quality than a high resolution interlaced image, a pretty bad example are the intro screens shown by the BIOS).''"<br>
This suggest that games which eventually need 0x31, 0x02 will be ones that send GP1 commands with active bit 2(Vertical Resolution 1=480) and 5(Vertical Interlace) at the same time. Otherwise image will be cropped, or badly interlaced. FF8 use this on "Published by..." screen, you can notice weird interlacing when subtitles fade-in without command.
=== Command 0x32 (netemu 4.83 up to 4.88) ===
Pad vibration related, seems to be big motor strength used in cellPadSetActDirect if value is less than one of function arguments. Default value set in xPadThread Init is 0x40(64).
=== Command 0x33 (netemu 4.83 up to 4.88) ===
Value is integer that is later converted to double float using fcfid, and truncated to single precision by frsp.<br>
Pad vibration related, seems to be used to calculate big motor strength used later in cellPadSetActDirect, if other conditions are met. Default value set in xPadThread Init is 0x4B0(1200).
=== Command 0x36 (netemu 4.83 up to 4.88) ===
*Maximum value 7
*PSX HW regs access related
*Valid values found:
**1 = ?
**2 = ?
**4 = ?
Multiple instances accepted, and not overwrite itself.
=== Command 0x37 (netemu 4.83 up to 4.88) ===
*Default value: 1
*Valid values found:
**2 = ?
**4 = ?
Something related to I_STAT (PSX Interrupt status register).
=== Command 0x38 (netemu 4.83 up to 4.88) ===
*Or command 0x2C in ps1_netemu.self 3.40
*Or command 0x2E in ps1_netemu.self 3.55 ?
*Valid values found:
**0/1/2/3
if (cfg == 0)
    stay_netemu
if (boot_not_from_disc_drive)
    if (cfg & 2)
        boot_newemu
if (boot_from_disc_drive)
    if (cfg & 1)
        boot_ps1emu
    else
        stay_netemu
// Boot is considered to be from disc if argv with game path is empty. Which make 0x38 with param 0x01 inaccessible, because there is no way to start disc game with netemu in official way (excluding games that ps1_emu launch with 0x15 cmd to ps1_netemu).
=== Command 0x3B (netemu 4.83 up to 4.88) ===
PS1 SPU DMA related config. Seems to change some cycles calculation.
*Default value: 0
*Valid values: 0/1
== Ps1_emu Commands Info ==
=== Command 0x15 (ps1emu 4.83 up to 4.88) ===
*Valid values found:
**3 (launch game using ps1_netemu)
**Different values are ignored
== Ps1_newemu Commands Info ==
=== Command 0x18 (ps1newemu 4.83 up to 4.88) ===
Supposed to launch game using different emulator, but all paths do nothing.
*Valid values found:
**3 (Do nothing, but with print! [https://imgflip.com/i/7x4j2p 1])
**Different values do nothing
== Known bugs ==
=== ps1_netemu.elf ===
==== Cdr int reads with nonstandard index ====
Emulator ignore interrupt flag register and interrupt enable register reads if cdrom index is 2, or 3. Reads like that are undocummented behavior, but confirmed to be successful on real hardware. Also Nocash docs, and Duckstation source handle that correctly, and i remember there are games which used that.
0xD81F0 read_0x1F801803:
0xD81F0  lwz      r0, (.1F801800 - 0x2E8480)(r8)
0xD81F4  clrlwi    r0, r0, 30        # cdrom.index & 3
0xD81F8  cmpwi    cr7, r0, 0        # cdrom.index = 0
0xD81FC  beq      cr7, read_interrupt_enable_register
0xD8200  cmpwi    cr7, r0, 1        # cdrom.index = 1
0xD8204  beq      cr7, read_interrupt_flag_register
0xD8208  li        r3, 0            # return 0 if index was 2 or 3
0xD820C  lwz      r7, off_1BC0D4
0xD8210  clrldi    r3, r3, 32
0xD8214  dcbt      0, r7
0xD8218  blr
This can be fixed by simple patch from
0xD81F4  clrlwi    r0, r0, 30  #hex 54 00 07 BE
0xD8264  clrlwi    r0, r0, 30  #hex 54 00 07 BE
to
0xD81F4  clrlwi    r0, r0, 31  #hex 54 00 07 FE
0xD8264  clrlwi    r0, r0, 31  #hex 54 00 07 FE
This change cdrom.index & 3, into cdrom.index & 1. This way index 2, and 3 will be respected as 0, and 1. Sadly there is no easy hex pattern, so patch need to be done manually. Memory offsets for 4.86.
==== Bad encoding of malformed conditional branch 0 ====
Emulator don't ignore few bits, and expect they are 0. While real hardware seems to don't care about them.
<pre>
  31..26 |25..21|20..16|15..11|10..6 |  5..0  |
  6bit  | 5bit | 5bit | 5bit | 5bit |  6bit  |
  -------+------+------+------+------+--------+------------
  000001 | rs  | 0XXX0| <--immediate16bit--> | bltz
  000001 | rs  | 0XXX1| <--immediate16bit--> | bgez
  000001 | rs  | 1XXX0| <--immediate16bit--> | bltzal
  000001 | rs  | 1XXX1| <--immediate16bit--> | bgezal
</pre>
Problem start when bits 17,18,19 are not zero. Emulator don't clear those bits, and explicitly check only for 0x0,0x1,0x10,0x11.
<pre>
r24 hold 20..16 bits extracted from opcode.
0x107958 bcondz_107958:                          # CODE XREF: r3000_opcode_table+12C↑j
0x107958                cmpwi    cr7, r24, 1  # jumptable 001067D4 case BcondZ
0x10795C                beq      cr7, loc_107E98
0x107960                cmplwi    cr7, r24, 1
0x107964                blt      cr7, loc_107E78
0x107968                cmpwi    cr7, r24, 0x10
0x10796C                beq      cr7, loc_1082A4
0x107970                cmpwi    cr7, r24, 0x11
0x107974                beq      cr7, loc_10821C
</pre>
Correct solution here will be patch to AND r24 with 0x11 first, to clear meaningless bits before comparison.
This is reason why emulator fail this "Branch Advance" CPU test: https://emulation.gametechwiki.com/index.php/PS1_Tests#CPU . Possibly standard "Branch" test is failed for the same reason.
== GTE commands ==
List of GTE commands is available at 0x001B345C in ps1_netemu 4.86. List include following data {CommandFunctionOPD, Cycles}.
Emulator handle only commands listed below (CMD, addr in emu).
<pre>
.GTE_RTPS 0xC4500
.GTE_MVMVA 0xC4C00
.GTE_SQR_sf 0xC5168
.GTE_NCLIP 0xC527C
.GTE_AVSZ3 0xC5338
.GTE_AVSZ4 0xC5420
.GTE_OP_sf 0xC5518
.GTE_GPF_sf 0xC5678
.GTE_GPL_sf 0xC58C8
.GTE_RTPT 0xC6288
.GTE_NCT 0xC7710
.GTE_NCS 0xC8AD8
.GTE_CC 0xC91E8
.GTE_NCCT 0xC9748
.GTE_NCCS 0xCADF8
.GTE_DCPL 0xCB5F8
.GTE_DPCS 0xCBAD8
.GTE_CDP 0xCBF80
.GTE_NCDT 0xCC760
.GTE_NCDS 0xCE5F8
.GTE_INTPL 0xCF078
.GTE_DPCT 0xCF540
</pre>
== CD Drive Commands ==
List of CD commands is available at 001B365C in ps1_netemu 4.86. List include following data {Respond INT count (minus INT3), CMD_nr, Function OPD}. Emulator handle only commands listed below (CMD, addr in emu).
<pre>
.cdr_cmd_Sync 0xD8290
.cdr_cmd_Reset 0xD8368
.cdr_cmd_Test 0xD8478
.cdr_cmd_Getparam 0xD8798
.cdr_cmd_Setmode 0xD8918
.cdr_cmd_Init 0xDBC48
.cdr_cmd_MotorOn 0xDD0C0
.cdr_cmd_SeekP 0xDD3D0
.cdr_cmd_Play 0xDD67C
.cdr_cmd_ReadS 0xDD8E8
.cdr_cmd_Backward 0xDDBD0
.cdr_cmd_Pause 0xDDF58
.cdr_cmd_GetTD 0xDE1F8
.cdr_cmd_Getstat 0xDE598
.cdr_cmd_GetlocP 0xDE728
.cdr_cmd_ReadN 0xDEDD0
.cdr_cmd_SetSession 0xDF130
.cdr_cmd_Mute 0xDF970
.cdr_cmd_SeekL 0xDFBAC
.cdr_cmd_Setloc 0xDFE58
.cdr_cmd_Demute 0xE03E0
.cdr_cmd_Setfilter 0xE0618
.cdr_cmd_Forward 0xE0878
.cdr_cmd_GetlocL 0xE0B98
.cdr_cmd_Stop 0xE0FF0
.cdr_cmd_GetTN 0xE1298
.cdr_cmd_GetID 0xE1544
.cdr_cmd_ReadTOC 0xE1C58
Commands 0x17, 0x18, 0x1D are handled as cmd_Sync. Commands above 0x1E seems to be not supported.
</pre>
Please note that all contributions to PS3 Developer wiki are considered to be released under the GNU Free Documentation License 1.2 (see PS3 Developer wiki:Copyrights for details). If you do not want your writing to be edited mercilessly and redistributed at will, then do not submit it here.
You are also promising us that you wrote this yourself, or copied it from a public domain or similar free resource. Do not submit copyrighted work without permission!

To protect the wiki against automated edit spam, we kindly ask you to solve the following hCaptcha:

Cancel Editing help (opens in new window)
Retrieved from "http://www.psdevwiki.com/ps3/Talk:PS1_Emulation"