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 14: Line 14:
Offset in emu memory (ps1_netemu 4.86) | name | info
Offset in emu memory (ps1_netemu 4.86) | name | info


001B39D0 GP0_commands_table {ParamsCount, OPD}
GP1 CMD parsers
0x10C48C process_GP1_cmd
0x10C5E4 GP1_reset_gpu
0x10C5E4 GP1_reset_gpu
0x10C88C GP1_reset_command_buffer
0x10C88C GP1_reset_command_buffer
Line 77: Line 78:
</pre>
</pre>


=== ps1_emu vs ps1_netemu GPU emulation differences ===
== Command IDs mapping ==
 
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
<pre>
.text:000014D0 E4_cmd:                             
.text:000014D0      il        r56, 0x3FF
.text:000014D4      hbrr      loc_1504, loc_403C
.text:000014D8      rotmi      r54, r12, -10      # r12 = whole 32 bit command
                                                  # r54 = is command shifted by 10 to skip
                                                  # x-cord. So now first bits are y-cord.
.text:000014DC      lqr        r51, xmmword_E520
.text:000014E0      and        r55, r12, r56      # x-cord and with whole 10 bits.
.text:000014E4      cwd        r53, 0xF0+var_F0(sp)
.text:000014E8      cwd        r49, 0xF0+var_F0+8(sp)
.text:000014EC      ai        r52, r55, 1
.text:000014F0      andi      r50, r54, 0x1FF    # y-cord and with 0x1FF, so only 9 bits.
</pre>
 
ps1_netemu
<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
 
== 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 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<br>
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.
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.
== Commands Info ==
=== Other 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" -->


=== Command 0x00 (netemu 3.40 up to 4.88) ===
=== Command 0x00 (netemu 3.40 up to 4.88) ===
*Valid values found
*Valid values found
**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 (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) ===
Line 251: Line 100:


=== 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>
The command data contains an offset that points to an area where are stored a list of sectors (4 bytes each), there are only 3 games using this command and are libcrypt protected: MediEvil (SCES-00311), Vagrant Story (SLES-02754), and Crash Team Racing (SCES-02105)<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>
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>
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>
The official format seems to include a lot more sectors which purpose is unknown<br>
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>
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)
<u>Crash Team Racing</u> [http://redump.org/disc/798/ SCES-02105] (at absolute offset 0x1627E4 in ps1_netemu.self 4.88)
<small><pre style="height:410px">
<small><pre style="height:410px">
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 398: Line 246:
</pre></small>
</pre></small>


<u>MediEvil</u> [http://redump.org/disc/592/ SCES-00311] (at absolute offset 0x16298C in ps1_netemu.self 4.83-4.88)
<u>MediEvil</u> [http://redump.org/disc/592/ SCES-00311] (at absolute offset 0x16298C in ps1_netemu.self 4.88)
<small><pre style="height:275px">
<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 487: Line 335:
</pre></small>
</pre></small>


<u>Vagrant Story</u> [http://redump.org/disc/9978/ SLES-02754] (at absolute offset 0x162A8C in ps1_netemu.self 4.83-4.88)
<u>Vagrant Story</u> [http://redump.org/disc/9978/ SLES-02754] (at absolute offset 0x162A8C in ps1_netemu.self 4.88)
<small><pre style="height:350px">
<small><pre style="height:350px">
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 612: Line 460:
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>
*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)
_xcdrom_thread related.
'''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)
*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.
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) ===
=== Command 0x05 (netemu 3.40 up to 4.88) ===
Line 633: Line 475:
*Default value: 0
*Default value: 0
*_xcdrom_thread related.
*_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) ===
=== Command 0x07 (netemu 4.83 up to 4.88) ===
*Default value: 0
*Default value: 0
*_xcdrom_thread related.
*_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) ===
=== Command 0x08 (netemu 3.40 up to 4.88) ===
Line 654: Line 491:


=== Command 0x0E (netemu 4.83 up to 4.88) ===
=== Command 0x0E (netemu 4.83 up to 4.88) ===
*Or command 0x0C (netemu 3.40)
*Default value: 0x1F4
*Default value: 0x1F4
*_xcdrom_thread related.
*_xcdrom_thread related.


=== Command 0x0F (netemu 4.83 up to 4.88) ===
=== Command 0x0F (netemu 4.83 up to 4.88) ===
*Or command 0x0D (netemu 3.40)
*Default value: 0xFA
*Default value: 0xFA
*_xcdrom_thread related.
*_xcdrom_thread related.
Line 670: Line 505:
*Default value: 0x7D
*Default value: 0x7D
*_xcdrom_thread related.
*_xcdrom_thread related.
=== 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) ===
=== Command 0x13 (netemu 4.83 up to 4.88) ===
*Default value: 0
*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) ===
=== Command 0x14 (netemu 4.83 up to 4.88) ===
Line 691: Line 517:
=== Command 0x16 (netemu 4.83 up to 4.88) ===
=== Command 0x16 (netemu 4.83 up to 4.88) ===
*Default value: 0
*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 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 2.10 up to 4.88)
*Or command 0x07 (newemu 2.10)
*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).
In ps1_netemu there is possbility 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) ===
=== 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
*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) ===
=== Command 0x19 (netemu 4.83 up to 4.88) ===
Line 726: Line 540:
=== Command 0x1B (netemu 4.83 up to 4.88) ===
=== Command 0x1B (netemu 4.83 up to 4.88) ===
*Default value: 0x3E8
*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) ===
=== Command 0x1E (netemu 4.83 up to 4.88) ===
*Default value: 0x7D0
*Default value: 0x7D0
*xPadThread related.
*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) ===
=== Command 0x21 (netemu 4.83 up to 4.88) ===
Line 766: Line 552:
*Default value: 0x3E8
*Default value: 0x3E8
*PS1 GPU related.
*PS1 GPU related.
Seems to fix slowdown in Rapid Racer (SCPS-10060) with value 0x320.


=== Command 0x23 (netemu 4.83 up to 4.88) ===
=== Command 0x23 (netemu 4.83 up to 4.88) ===
Line 784: Line 569:
*PS1 GPU related.
*PS1 GPU related.


=== Command 0x2B (netemu 4.83 up to 4.88) ===
=== Command 0x2B(netemu 4.83 up to 4.88) ===
*Default value: 0
*Default value: 0
*PS1 GPU related.
*PS1 GPU related.
Line 795: Line 580:
*Default value: 0
*Default value: 0
*PS1 GPU related.
*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) ===
=== Command 0x32 (netemu 4.83 up to 4.88) ===
Line 826: Line 605:


=== Command 0x38 (netemu 4.83 up to 4.88) ===
=== Command 0x38 (netemu 4.83 up to 4.88) ===
*Or command 0x2C in ps1_netemu.self 3.40
*Or command 0x15 in ps1_emu.self 4.88 ?
*Or command 0x2E in ps1_netemu.self 3.55 ?
*Valid values found:
*Valid values found:
**0/1/2/3
**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.


if (cfg == 0)
== Possible Cobra implementation issues ==
    stay_netemu
Every CFW which use cobra module potentially can be affected by nasty bug that is there probably even before 7.00.<br>
So the deal is patch in cobra that allow skip region check, example based on ps1_emu.  
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) ===
<pre>SprxPatch ps1_emu_patches[] =
PS1 SPU DMA related config. Seems to change some cycles calculation.
{
*Default value: 0
{ ps1_emu_get_region_offset, LI(R29, 0x82), &condition_true }, /* regions 0x80-0x82 bypass region check. */
*Valid values: 0/1
{ 0 }
};
</pre>


== Ps1_emu Commands Info ==
While patch actually skip region check, is also skipping part of code where region of ps3 is stored for future usage. And probably set whole emulation to JPN<br>
This can be important because function that cobra patch, probably is responsible for selecting region of ps1_rom. <br>
There is a string in emulator JJJJAEJEAEJJEJJA which seems to be selector for bios/rom region based on target ID ([[Product_Code]]).
<pre>J    J    J    J    A    E    J    E    A    E    J    J    E    J    J    A
0x80 0x81 0x82 0x83 0x84 0x85 0x86 0x87 0x88 0x89 0x8A 0x8B 0x8C 0x8D 0x8E 0x8F</pre>


=== Command 0x15 (ps1emu 4.83 up to 4.88) ===
Hard patch to 0x82 potentially lead to known PAL games frame pacing issues, and to desynced audio, and maybe more. While i can't test that i'm 100% sure that better solution here will be read third character of Title ID from SYSTEM.CNF file of disc/iso, and then patching same place with<br> ps1_emu_get_region_offset, LI(R29, title_id_based_region), &condition_true . <br>
*Valid values found:
Generally if title have E then patch to ANY EU target ID, similar for US, for titles where U or E isn't found just use default J target ID.
**3 (launch game using ps1_netemu)
Above is based on static elf analyse, so i can't tell 100% that is an issue, but it looks like it in emu code.
**Different values are ignored


== Ps1_newemu Commands Info ==
* Is that patch being applied every time, even on the PAL region console? I have never noticed any issues and I was playing the PAL games mostly. The only thing I noticed is the slowed and pitched down licence screen when the PAL game is launched through the ps1_netemu. --[[User:Agrippa|Agrippa]] ([[User talk:Agrippa|talk]]) 17:40, 6 January 2022 (UTC)
* Ok, I have tested the Ape Escape PAL menu theme. There is neither any slowdown, nor pitch difference using either ps1_emu or ps1_netemu. As far as I know, no games are affected, because there are no multi region PS1 games ever released. As the video mode is set before the boot, everything seems to be ok. The cracktros are affected though, because they read that 0xBFC7FF52 offset to determine the video mode, causing the audio to be slower indeed. And it seems the ps1_netemu has got an internal audio pitch compensation, as the licence screen is pitched down (and every cracktro too). The proper patch is needed for the sake of completeness. --[[User:Agrippa|Agrippa]] ([[User talk:Agrippa|talk]]) 18:51, 1 February 2022 (UTC)


=== Command 0x18 (ps1newemu 4.83 up to 4.88) ===
== ps1_emu vs ps1_netemu GPU emulation differences ==
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 ==
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_netemu.elf ===
ps1_emu
==== Cdr int reads with nonstandard index ====
<pre>
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.
.text:000014D0 E4_cmd:                             
.text:000014D0      il        r56, 0x3FF
.text:000014D4      hbrr      loc_1504, loc_403C
.text:000014D8      rotmi      r54, r12, -10      # r12 = whole 32 bit command
                                                  # r54 = is command shifted by 10 to skip
                                                  # x-cord. So now first bits are y-cord.
.text:000014DC      lqr        r51, xmmword_E520
.text:000014E0      and        r55, r12, r56      # x-cord and with whole 10 bits.
.text:000014E4      cwd        r53, 0xF0+var_F0(sp)
.text:000014E8      cwd        r49, 0xF0+var_F0+8(sp)
.text:000014EC      ai        r52, r55, 1
.text:000014F0      andi      r50, r54, 0x1FF    # y-cord and with 0x1FF, so only 9 bits.
</pre>


0xD81F0 read_0x1F801803:
ps1_netemu
0xD81F0  lwz      r0, (.1F801800 - 0x2E8480)(r8)
<pre>
0xD81F4  clrlwi    r0, r0, 30        # cdrom.index & 3
.text:00003338 E4_cmd:                        
0xD81F8  cmpwi    cr7, r0, 0        # cdrom.index = 0
.text:00003338      rotmi      r18, r12, -10      # r12 = whole 32 bit command
0xD81FC  beq       cr7, read_interrupt_enable_register
                                                  # r18 = is command shifted by 10 to skip
0xD8200  cmpwi    cr7, r0, 1        # cdrom.index = 1
                                                  # x-cord. So now first bits are y-cord.
0xD8204  beq      cr7, read_interrupt_flag_register
.text:0000333C      hbrr       loc_3384, loc_3328
0xD8208  li       r3, 0            # return 0 if index was 2 or 3
.text:00003340      il        r19, 0x3FF
0xD820C  lwz      r7, off_1BC0D4
.text:00003344      lqr        r39, xmmword_150D0
0xD8210  clrldi    r3, r3, 32
.text:00003348      il        r8, 0x200
0xD8214  dcbt      0, r7
.text:0000334C      lqr        r33, xmmword_150E0
0xD8218  blr
.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.


This can be fixed by simple patch from
==Patches==
0xD81F4  clrlwi    r0, r0, 30  #hex 54 00 07 BE
====Disable Dithering====
0xD8264  clrlwi    r0, r0, 30  #hex 54 00 07 BE
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>
to
For ps1_emu.elf
0xD81F4  clrlwi    r0, r0, 31  #hex 54 00 07 FE
<pre>
0xD8264  clrlwi    r0, r0, 31  #hex 54 00 07 FE
search for: 23 EC A4 04 23 E3 3B 85  33 7E 26 00 32 05 86 00 0F 3D C6 11
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.
replace to: 23 EC A4 04 23 E3 3B 85  33 7E 26 00 32 05 86 00 40 80 00 11
</pre>


==== Bad encoding of malformed conditional branch 0 ====
For ps1_netemu.elf
Emulator don't ignore few bits, and expect they are 0. While real hardware seems to don't care about them.  
<pre>
<pre>
  31..26 |25..21|20..16|15..11|10..6 |  5..0  |
search for: 7C 38 41 94 20 7F F4 94 0F 3D C6 3C 12 7F F3 8A
  6bit  | 5bit | 5bit | 5bit | 5bit |  6bit  |
replace to: 7C 38 41 94 20 7F F4 94 40 80 00 3C 12 7F F3 8A
  -------+------+------+------+------+--------+------------
  000001 | rs  | 0XXX0| <--immediate16bit--> | bltz
  000001 | rs  | 0XXX1| <--immediate16bit--> | bgez
  000001 | rs  | 1XXX0| <--immediate16bit--> | bltzal
  000001 | rs  | 1XXX1| <--immediate16bit--> | bgezal
</pre>
</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.
For ps1_newemu.elf
<pre>
<pre>
r24 hold 20..16 bits extracted from opcode.
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
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>
</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 ==
Patch for rpcs3 (newemu only) for testing purpose.
<pre>
Version: 1.2


List of GTE commands is available at 0x001B345C in ps1_netemu 4.86. List include following data {CommandFunctionOPD, Cycles}.
SPU-f3d8be702bf4cb8545656e37c29fcc6201a57991:
Emulator handle only commands listed below (CMD, addr in emu).
  "Disable Dithering":
 
    Games:
<pre>
      All:
.GTE_RTPS 0xC4500
        All: [ All ]
.GTE_MVMVA 0xC4C00
    Author: "kozarovv"
.GTE_SQR_sf 0xC5168
    Patch Version: 1.0
.GTE_NCLIP 0xC527C
    Patch:
.GTE_AVSZ3 0xC5338
      - [ be32, 0xFB0, 0x40800058 ]
.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>
</pre>


== CD Drive Commands ==
==Psxtract==
I updated psxtract to support proper subchannel data extraction for single, and multi discs.
Based on most feature rich version from https://github.com/DeadlySystem/psxtract-2 github. Since i don't have github anymore, i think this is good place to share it.
Only Windows version is updated! Linux code is not touched (i have no way to test).
Please mirror or even make pr on github if that's prefered.


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).
* Download (source plus exe): https://www.mediafire.com/file/ytg875p1a6ph89f/psxtract-2-master.zip/file


<pre>
== ps1_rom.bin ==
.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.
This file can be replaced by any ps1 rom image (incl. DTL models), and by most of PS2 rom images (maybe by all, deckard models untested). Replacing to bios from PS1 restore Sony logo at start up. That also should allow to run ps1 menu alone, but that's untested. Props to Jabu, iirc he figured out running Sony startup screen ages ago.
</pre>
Emulator have bug (netemu at least), that load whole 4MB file. They probably not changed that after stripping file from 4MB to 512KB. So any PS1/PS2(no deckard) bios image can be used unless is 4MB or less. All of that load games just fine.
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"