Editing Talk:PS2 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 202: Line 202:
| 0x3B || {{no}} || {{no}} || {{no}} || 0x43FAC ||  ||  
| 0x3B || {{no}} || {{no}} || {{no}} || 0x43FAC ||  ||  
|}{{clear}}
|}{{clear}}
====Function 0x05/0x06====
Well, my suspicion was true about a netemu command (for once in a blue moon). Function 0x05 fixes Tenchu: Wrath of Heaven's freezing issues by hooking it in the same function as the previous 0x0A patches (function is called dma2Exec in Tenchu Kurenai). I am hoping this can fix the Ecole games (finally...), Magic Pengel, Drakan, probably lots of others. Cool!
*Initial testing with function 0x06 seems to fix Spartan: Total Warrior's freezing issues.--[[User:Mrjaredbeta|Mrjaredbeta]] ([[User talk:Mrjaredbeta|talk]]) 17:24, 9 October 2022 (UTC)


====Function 0x0D====
====Function 0x0D====
Line 265: Line 269:


The ingame FMVs with the graphic overlay are still stuttering heavily, though, and I am still unsure why. It seems like the shorter FMVs run fine, and the longer they are they more they have slowdown/stutter. This only applies to the "ingame" FMVs and not the opening ones.
The ingame FMVs with the graphic overlay are still stuttering heavily, though, and I am still unsure why. It seems like the shorter FMVs run fine, and the longer they are they more they have slowdown/stutter. This only applies to the "ingame" FMVs and not the opening ones.
I did some work on it, and it seems to modify read speed. Higher values should give faster read speed. Eventually higher values will give more frequent event checks, but read speed modifier seems to be more probable now when we know default values. To get faster read speed we should use (1, x > 0x400) for CD, and (1, x > 0x1000) for DVD. At this point Shadowman 2 is good test candidate again, just with some really high value. All configs from GX emu looks like they slowing down reads, because values for DVD are below 0x1000, Shadowman2 without config doesn't change anything because this config use default value... Burnout 3 is interesting here, only config that seems to use 0 (yolo read speed) option. --[[User:Kozarovv|Kozarovv]] ([[User talk:Kozarovv|talk]]) 22:24, 3 July 2023 (CEST) <br>
void MECHA_on_state_3(__int64* mecha)
{
  ReadSectorSize = *(mecha + 0x70);
  if ( !ReadSectorSize )
    panic(1u);
   
  do
    current_tb = get_current_timebase()
  while ( !current_tb );
 
  readed_sectors_count = readed_size_in_bytes / ReadSectorSize;
  readed_sectors_count_mul_by_79800000 = 79800000LL * readed_sectors_count
  tb_for_seek_and_read = *(mecha + 0x18);
  skip = current_tb - tb_for_seek_and_read >= readed_sectors_count_mul_by_79800000 / val_from_cmd_0x0C_1)
 
  if ( cmd_0x0C_0 != 1 || val_from_cmd_0x0C_1 == 0 || skip )
  {
    if ( *(mecha + 0xD4) <= BytesToRead && !*(mecha + 0xE4) )
    {
      *(mecha + 0xD4) = readed_size_in_bytes;
      *mecha_state = 4; // Reading done here. Going to next step.
      return;
    }
    panic(1u);
  }
  set_scheduler(
    5uLL,                                                                              // 5 - CDVD event
    tb_for_seek_and_read + readed_sectors_count_mul_by_79800000 / val_from_cmd_0x0C_1,  // When
    &syscall8_200,                                                                      // Event Handler.
    0LL);                                                                              // unk
}
* Netemu does crash when the first param is set to 0x2.--[[User:Agrippa|Agrippa]] ([[User talk:Agrippa|talk]]) 21:03, 7 July 2023 (CEST)
** No idea why, function that check config compare to 2 and panic if greater than. So '''2''' is accepted at least there. This config is used in 4 places. All of them use next part of config only if this one is '''1'''. 3 places check explicitly for '''1''', one place check for '''0'''. Setting '''2''' is weird from code point of view because it's almost like 0, but allow code to do one check in read function, and to be honest this doesn't look like intentional behavior because similar check is performed earlier in previous N command state, and there is handled properly including setting 1F402006 to error code instead of panic. --[[User:Kozarovv|Kozarovv]] ([[User talk:Kozarovv|talk]]) 22:31, 7 July 2023 (CEST)


===ps2_netemu command 0x12===
===ps2_netemu command 0x12===


First 8 bytes of that command are special flags. Not quite sure about bytes 5-8 yet, because at some point they are used to "andc" with first 4 bytes.
Some examples for first 4 bytes:
0x100000  = Different code path for VU0 opcodes that do ADD/SUB with multiply (MSUB, MADDA, etc.).
0x200000  = Run some additional code in VU0 load/store opcodes (ILW, LQI, ISWR, etc.)
0x400000  = Skip emu syscall 3 (3)
0x800000  = Skip emu syscall 3 (4)
0x4000000  = This flag ensure that type 2 config from cmd 0x12 will run. Otherwise it seems to be skipped.
0x8000000  = Run some additional code for VU0 DIV opcode
0x30000000 = Different code path for VU0 MUL opcodes, include opcodes like MSUB for mul part. So 0x30100000 work for mul, and sub part.
0x10000000 and 0x20000000 also work for that purpose, emu just check for any active bits after applying 0x30000000 mask.
Keep in mind that you still need to use at least 8 bytes for cmd 0x12, just use 00 for bytes 5,6,7,8.
Syscall 3 - Enable additional code related to VU0/COP2
  *param = 3 Patch 0x186C10 to NOP
  *param = 4 Patch 0x186C40 to NOP
  *param = anything else LV1 panic
* Do the VU0 accuracy flags need any subcommands? Official 0x12 configs for the State of Emergency/Driving Emotion/The Getaway use 0x00021000 0x00000000 flag.--[[User:Agrippa|Agrippa]] ([[User talk:Agrippa|talk]]) 15:43, 9 March 2022 (UTC)
** Flags are first 2 x 4 bytes of cmd 0x12. Config need at least 8 bytes, or it is ignored. There is no need for any subcommand. I suggest to not mess with second 4 bytes for now, and just use 00 00 00 00 as i'm not sure what is real usage of that yet (seems to be "disabler" mask for first 4 bytes, so they are use only one time). For now most aggressive config that use flags is Marvel Nemesis. After excluding 0x4000000 which trigger type 2 subcmd, config looks like this 00FFF000 00000000. --[[User:Kozarovv|Kozarovv]] ([[User talk:Kozarovv|talk]]) 05:42, 10 March 2022 (UTC)
====type 1====
====type 1====
Playground discussion, unsure about clrlslwi  r11, r0, 16,3 result
Playground discussion, unsure about clrlslwi  r11, r0, 16,3 result
Line 338: Line 324:
seg017:00000000001984C0                bgt      cr6, next_value
seg017:00000000001984C0                bgt      cr6, next_value
</pre>
</pre>
<br>
Leaving old info for now as it have good explanation of code itself. Command patch vu0_jit_data memory directly. For example above patch will write 0x188 to 0x1C018994 address. vu0 jit mem hold info about microprograms, like how many cycles will run, where program start/end, where is ebit, etc. For now is unknown which info is patched, but shift by 3 suggest it will be vu0 address related info. --[[User:Kozarovv|Kozarovv]] ([[User talk:Kozarovv|talk]]) 12:23, 14 June 2023 (CEST)


====type 2====
====type 2====
Line 468: Line 452:
|}
|}
--[[User:Kozarovv|Kozarovv]] ([[User talk:Kozarovv|talk]]) 21:03, 1 October 2022 (UTC)
--[[User:Kozarovv|Kozarovv]] ([[User talk:Kozarovv|talk]]) 21:03, 1 October 2022 (UTC)
Example of recompiled code with enabled cache emulation:  https://pastebin.com/sDwc1MLX
* Every operation with r15 and following r7/r8 loads, compares, and cr operations will be skipped by emitter with 0x21 --> 0
* r15 is loaded with current address (page?), to get full value shift it left by 6 eg.  0x808710 << 6 = 0x2021C400 (shift left by 6 = multiplying by 0x40)
* For small part of code posted on pastebin, cache check is performed 33 times * 8 opcodes = 264 opcodes from 801 are cache checks! A lot of work, a lot of code mostly for nothing.
* Conclusion. Use 0x21 --> 0 whenever you can. iCache emulation is pointless for 99% of games.
* Small oftopic. Every opcode that write to r13 increase emulated cycles. Every opcode writing to r14 modify current r5900 pc. Every branch to 0x3800 mean that event test will be performed.
* Problematic games (have issues with 0x21 enabled): Shadow Hearts 3, Jak & Daxter, VP2, Hot Shots series, Kingdom Hearts. Any game that load additional code overlays and do that custom way, for example Shadow Hearts 3 load code from bin files hidden in cpx files. All those games doesn't really need iCache emulation to work, but emulator seems to have issue with code invalidation. Only small amount of games used this method of loading, so it still should be fine for 99% of games.
--[[User:Kozarovv|Kozarovv]] ([[User talk:Kozarovv|talk]]) 07:32, 22 May 2023 (CEST)
* Radiata does not crash. English patch for FFXII IZJS does crash though (0x21 fixes stuttering in turbo mode).--[[User:Agrippa|Agrippa]] ([[User talk:Agrippa|talk]]) 20:33, 22 May 2023 (CEST)
** Whoops, my bad. Fixed. :P --[[User:Kozarovv|Kozarovv]] ([[User talk:Kozarovv|talk]]) 09:44, 23 May 2023 (CEST)
*** Actually, the icache invalidation issues could explain why the infamous Maori VP2 overlay anti-protection patch is not working on the netemu.--[[User:Agrippa|Agrippa]] ([[User talk:Agrippa|talk]]) 22:14, 15 June 2023 (CEST)
**** His patch is basically self modifying code, so its possible. You can try cmd 0x01 with 0x0E subcommand hook at 0x01feb1c0. This invalidate whole mem every time offset is hit, ensuring that new code that is written from patcher is not in conflict with cache. Also remember that 0x42 is applied only on syscall 7, so if game modify 0x1feb1c0 - 0x1feb2e0 region, it will wipe patcher. And games often memzero whole data memory right after start. This issue don't exist on pcsx2 because it will reapply it on next vsync, while on netemu only 0x09/0x0A patches are reapplied. --[[User:Kozarovv|Kozarovv]] ([[User talk:Kozarovv|talk]]) 15:37, 16 June 2023 (CEST)


===ps2_netemu command 0x22===
===ps2_netemu command 0x22===
Weird command. Sets something 1 (CDVD/MECHA), but seems to never use it.
Weird command. Sets something 1 (CDVD/MECHA), but seems to never use it.  
 
===ps2_netemu command 0x29===
===ps2_netemu command 0x28===
Something related with read time, maybe seek time. First value is meant to be lower than second value, but this is not requirement.
This command is heavily stripped version of command from gxemu. On netemu only option that seems to change anything is 0. From what i gathered in emu, when set to 0 SEEK ncmd will to be ignored and instant command ack is set. When 0 is used cdvd.SeekToSector is not updated from NCMD params. For emulated vm this mean next read command will perform seek to sector from position where last read end. Not sure if i'm understanding that correctly, it seems to be very hacky solution.
Code that use it seems to delay some read/seek operation by multiply of first, or second value depending which sector is currently read (or maybe which part of disc actually). Here is code from one of fuctions that use values from that command, keep in mind that "mecha" is just fancy name for cdvd in that emu.
 
if ((75 * cdvd.CrtSecond + 4500 * cdvd.CrtMinute + cdvd.CrtFrame - 150) >= *(mecha.unk_0x60))
After some more work, its either skip seek, or make seek instant. Still a hack, but may give some loading boosts here and there (and break a lot of stuff too).
    a = *(cmd_0x29_val_2);
else
    a = *(cmd_0x29_val_1);
b = 4835703278458516699;        // read https://munroesj52.github.io/vec__int64__ppc_8h.html (search on page for that number).
c = (79800000 * a * b) >> 64;  // 0x4C1A6C0 (79800000) is value that lv1 repo key be.clock return.
d = c >> 18;                    // This and 2 above are generally used as a division by multiply.
e = get_timebase_reg();
if ( e == 0 )
{
  do
    e = get_timebase_reg();
  while ( e == 0 );
}
f = e - *(mecha.unk_0x24);
if ( f >= d )
{
  MECHA_update_status(mecha);
  result = unlock_sc06(0x8000LL);
}
else
{
    do
    e = get_timebase_reg();
  while ( e == 0 );
  *(mecha.unk_20) = d - f + e;
  *mecha.unk_00 = 5;
  result = unlock_sc06(0x8000LL);
}


===ps2_netemu command 0x2A===
===ps2_netemu command 0x2A===
Line 515: Line 516:
Value from 0x20(r31) is later used in compare. That result in cdvd error, or in setting which seems schedule event to happen after time from timebase pass. This event is netemu syscall 8 (0x200) which is related to all ps2 cdvd reads. Tl;dr is that value give emulator some more time before cdvd error. Weird thing is that PS button fix it.. --[[User:Kozarovv|Kozarovv]] ([[User talk:Kozarovv|talk]]) 07:05, 7 March 2022 (UTC)
Value from 0x20(r31) is later used in compare. That result in cdvd error, or in setting which seems schedule event to happen after time from timebase pass. This event is netemu syscall 8 (0x200) which is related to all ps2 cdvd reads. Tl;dr is that value give emulator some more time before cdvd error. Weird thing is that PS button fix it.. --[[User:Kozarovv|Kozarovv]] ([[User talk:Kozarovv|talk]]) 07:05, 7 March 2022 (UTC)


===ps2_gxemu command 0x19===
===ps2_netemu command 0x3D===
Command disable reads/writes to selected IOP HW registers. Disabled regs are:
Looks like we misunderstood this command earlier, and probably we don't even need it.
 
There seems to be no emu code that make use of it beside printing config revision. This need confirmation on real hardware. In case that missing 0x3D will fail, it will be good to test at least that is really version enforcer, because i can't find part of code that is eventually responsible for that.
* 0x10000000 - 0x10003FFF (DEV9/SPEED/ATA/SMAP)
* Some time ago I tested the config with version 0x3D89 which contained commands supported from the version 0x40DC onwards. The console hung up right after LV2 reset.--[[User:Agrippa|Agrippa]] ([[User talk:Agrippa|talk]]) 10:16, 24 April 2022 (UTC)
* 0x1F801460 - 0x1F80147F (Unknown)
** Any chance you can test this again? Config parser don't have any check for revision, when it hit 0x3D is just storing value on address that seems to be related only to UI/Menu stuff. While i can imagine some check for overall config version (still I searched and it seems to be none), i can't imagine some additional per command revision check. Which is what your test suggest here. Emulator have only one config parser, one config buffer, and one check for command number (0x51 and above still don't trigger panic yet, just ignore command). I also tried to find version numbers of 15686, 16604, 16808, 16916, 17041, 17179, 17277, 17495 in code (as hex of course), and only 17495 is found in function that is not really related to any check (described here at the end: [[Talk:PS2_Emulation#Netemu_2]] ). [[User:Kozarovv|Kozarovv]] ([[User talk:Kozarovv|talk]]) 15:06, 24 April 2022 (UTC)--
*** You are right. There is no revision check and the 0x3D command is not needed at all for the config to work.--[[User:Agrippa|Agrippa]] ([[User talk:Agrippa|talk]]) 18:14, 5 May 2022 (UTC)
**** We figured that out 2000 custom configs too late. :D  Anyway, thanks for confirming that. --[[User:Kozarovv|Kozarovv]] ([[User talk:Kozarovv|talk]]) 17:30, 9 May 2022 (UTC)


Command is auto applied to titles listed here (duplicates are really there in emu too):
===ps2_netemu command 0x4D===
     Hash          ID                Name
Ok, i don't get that config. Here is what happen in assembly:
  0x0CD1298155  SLES_540.13  World Snooker Championship 2007
0xD820  ilhu     r19, 0x7FFF
  0x12C93199A5  SLES_518.40  NHL Hitz Pro
  0xD824  lqr      r20, Q_cfg_0x4D  ; 0x3F800000 in wild arms
  0x15C93199AD  SLES_549.13  Pro Evolution Soccer 2008
  0xD82C  iohl      r19, 0xFFFF
  0x24D92589A5  SLUS_211.86  NBA Ballers - Phenom
  0xD834  and      r17, r80, r19    ; r17 = Q & 0x7FFFFFFF mask
  0x2CD12D8125  SLUS_212.35  MLB 2K6
  0xD840  ceqi      r15, r17, 0      ; r15 = r17 (shortcut to move 0 or value if exist to r15)
  0x34C9359935  SLUS_211.38  X-Men Legends II - Rise of Apocalypse
  0xD844  lqr      r10, ST_Q
  0x34C93599E5  SLUS_211.28  Blitz - The League
  0xD84C  cwd      r9, 0x30+var_30+8(sp)
  0x34C93599E5  SLUS_211.28  Blitz - The League
  0xD850  rotqbyi  r16, r20, 4      ; load mask from config to r16
  0x449961C9E5  SLES_542.10  NBA 2K7
  0xD858  and      r12, r15, r16    ; tempQ & 0x3F800000 (r15 and with mask from cfg 0x3F800000)
  0x4C9169C1CD SLES_542.46  FIFA '07
  0xD860  or        r5, r80, r12    ; or r80(Q) with r12(Q masked with 0x3F800000)
  0x4C9169C1D5  SLES_542.45  NHL '07
  0xD868  shufb    r7, r5, r10, r9 ; Prepare correct write for Q (r5 stored to r10 + 8)
0x4C9169C1DD  SLES_542.44  FIFA '07
  0xD870  stqr      r7, ST_Q        ; write result as Q value in STQ
0x4C9169C1E5  SLES_542.43  FIFA '07
I removed irrelevant code that setup RGBA for readability, its not affecting Q. So my point is that all that masked Q is finally ored with r80. So with whole untouched Q value. Doen't that make all those operations irrelevant, or i made some mistake here?<br>
0x4C9169C1F5  SLES_542.41  FIFA '07
This config can be quite important because it should help to fix issues like Galerians Ash without dirty static patches. More games affected: [[https://github.com/PCSX2/pcsx2/issues/5137 | List]]
0x4C9169C1FD  SLES_542.40  FIFA '07
* I tested the 0x3F800000 and 0x71500000 values with Galerians Ash and it did not work at all.--[[User:Agrippa|Agrippa]] ([[User talk:Agrippa|talk]]) 14:15, 8 March 2022 (UTC)
0x4CB14DE12D  SLUS_213.74  Marvel - Ultimate Alliance
0x54A955F915  SLUS_212.74  Outrun 2006 - Coast 2 Coas
0x5CA15DF165  SLUS_213.01  World Series of Poker
0x5CA15DF1FD  SLUS_212.86  WWE SmackDown! vs RAW 2006
0x5CA15DF1FD  SLUS_212.86  WWE SmackDown! vs RAW 2006
0x649965C94D  SLUS_214.63  Tom Clancy's Ghost Recon 2
0x649965C955  SLUS_214.60  NBA Live '07
0x649965C95D  SLUS_214.61  NASCAR '07
0x649965C965  SLUS_214.58  NHL '07
0x649965C96D  SLUS_214.59  NCAA Football '07
0x6BB149E15D  SLES_531.04  Tom Clancy's Rainbow Six - Lockdown
0x6C916DC165  SLUS_214.91  World Series of Poker - Tournament of Champions
0x6C916DC1A5  SLUS_214.83  Tiger Woods PGA Tour '07
0x6C916DC1AD  SLUS_214.82  NFL Street 3
0x6C916DC1B5  SLUS_214.81  NCAA March Madness '07
0x6C916DC1D5  SLUS_214.77  Madden NFL '07 [Hall of Fame Edition]
0x6C916DC1DD  SLUS_214.76  Madden NFL '07
0x748975D9DD  SLUS_213.83  Fight Night - Round 3
0x7C817DD125  SLUS_214.33  FIFA Soccer '07
0x7C817DD165  SLUS_214.25  NHL 2K7
0x7C817DD16D  SLUS_214.24  NBA 2K7
0x7C817DD175  SLUS_214.27  WWE SmackDown! vs RAW 2007
0x7C817DD1CD  SLUS_214.12  World Championship Poker featuring Howard Lederer - All-In
0x84798529BD  SLUS_205.65  Champions of Norrath
0x8559A109AD  uuunnnnnkkk 
0x8579852915  SLUS_215.68  Arena Football - Road to Glory
0x8579852965  SLUS_215.82  MVP '07 - NCAA Baseball
0x8D51A90145  SLES_545.11  UEFA Champions League
0x8D51A901B5  SLES_545.13  UEFA Champions League
0x8D51A901BD  SLES_545.12  UEFA Champions League
0x8D718D21BD  SLUS_216.20  NCAA Football '08
0x9C619D31E5  SLUS_205.41  NBA Ballers
0x9D41B911AD  SLES_544.48  World Series of Poker - Tournament of Champions
0x9D619D31C5  SLUS_215.61  Major League Baseball 2K7
0x9F29357805  SCUS_975.44  NBA '07 featuring The Life Vol.2
0x9F293578E5  SCUS_975.56  MLB '07 - The Show
0xB549B51915  SLUS_216.38  Madden NFL '0
0xB549B51925  SLUS_216.32  NHL 2K8
0xB549B5195D  SLUS_216.47  NHL '08
0xB549B519A5  SLUS_216.48  FIFA Soccer '08
0xB549B519AD  SLUS_216.49  NBA Live '08
0xBC61793025  SCES_532.85  Ratchet - Gladiator
0xBD41BD1105  SLUS_216.69  NBA 2K8
0xC439C569F5  SLUS_208.20  Tom Clancy's Ghost Recon - Jungle Storm
0xC7716D20D5  SCUS_974.01  Hot Shots Golf FORE!
0xC7716D20D5  SCUS_974.01  Hot Shots Golf FORE!
0xCA11E941F5  SLES_516.97  SSX 3
0xCF7965285D  SCUS_973.53  Ratchet and Clank - Up Your Arsenal
0xCF7965285D  SCUS_973.53  Ratchet and Clank - Up Your Arsenal
0xD20911582D  SCES_515.93  Hardware Online Arena [Beta, Promo & Full Release]
0xD7617D308D  SCUS_973.28  Gran Turismo 4
0xE339C1695D  SLES_525.45  Star Wars Battlefront
0xE794CCB06D  PCPX_980.42  Minna no Tennis
0xEA3129608D  SCES_515.78  Network Access Disc [Original, v4.02 & v4.03]
0xEC11ED4115  SLUS_209.73  Champions - Return to Arms
0xEF594508D5  SCUS_975.00  MLB '06 - The Show
0xF409F559AD  SLUS_208.89  MLB Slugfest - Loaded
0xF7415D10E5  SCUS_974.65  Ratchet - Deadlocked
0xF7415D10E5  SCUS_974.65  Ratchet - Deadlocked
As a result config disable HDD/NET capabilities.


==XMB messages related with PS2 Emulation==
==XMB messages related with PS2 Emulation==
Line 689: Line 632:
* Without Factory Service Mode : gives "Incompatible Data" when inserting PS2 disc
* Without Factory Service Mode : gives "Incompatible Data" when inserting PS2 disc


* When enabling [https://web.archive.org/web/*/http://ps3devwiki.com/files/devtools/lv2-v9-pkg/ LV2Patcher] without factory service mode (patch4 set as http://pastie.org/private/jp8zhvuocjz95cfrjm0uzg) : no changes in XMB:Game (still only PS upscaler/smoothing, no PS2 mention at all)
* When enabling [http://www.ps3devwiki.com/files/devtools/lv2-v9-pkg/ LV2Patcher] without factory service mode (patch4 set as http://pastie.org/private/jp8zhvuocjz95cfrjm0uzg) : no changes in XMB:Game (still only PS upscaler/smoothing, no PS2 mention at all)


* When enabling [https://web.archive.org/web/*/http://ps3devwiki.com/files/devtools/lv2-v9-pkg/ LV2Patcher] without factory service mode (patch4 set as http://pastie.org/4355919) : gives XMB:Game PS2 smoothing/upscaling options, it also make an inserted disk to be seen as PS2 format. Still same problem of ¨incompatible title¨ and loss of BT/settings. Also after returning to XMB, it no longer sees the disc as PS2 format but as incompatible data (which suggests the lv2 patch is undone, as lv2 is reloaded when returning from the ps2 lpar)
* When enabling [http://www.ps3devwiki.com/files/devtools/lv2-v9-pkg/ LV2Patcher] without factory service mode (patch4 set as http://pastie.org/4355919) : gives XMB:Game PS2 smoothing/upscaling options, it also make an inserted disk to be seen as PS2 format. Still same problem of ¨incompatible title¨ and loss of BT/settings. Also after returning to XMB, it no longer sees the disc as PS2 format but as incompatible data (which suggests the lv2 patch is undone, as lv2 is reloaded when returning from the ps2 lpar)


* Using [https://web.archive.org/web/*/http://ps3devwiki.com/files/OtherOSplusplus/misc/boot_ps2.pkg boot_ps2.pkg] without factory service mode : no resetting of date/time/displayoutput (still output on mainscreen), but all connection to any bound bluetooth device is lost, even when connected via USB (need PS button reactivation), and after a long while comes up with the message that the title is not compatible and that the ps3 needs to be updated (Basic nag screen that is on BC PS3s when inserting a noncompatible title).  
* Using [http://www.ps3devwiki.com/files/OtherOSplusplus/misc/boot_ps2.pkg boot_ps2.pkg] without factory service mode : no resetting of date/time/displayoutput (still output on mainscreen), but all connection to any bound bluetooth device is lost, even when connected via USB (need PS button reactivation), and after a long while comes up with the message that the title is not compatible and that the ps3 needs to be updated (Basic nag screen that is on BC PS3s when inserting a noncompatible title).  


* With Factory Service Mode enabled (there are no Xmb options to combinetest with [https://web.archive.org/web/*/http://ps3devwiki.com/files/devtools/lv2-v9-pkg/ LV2Patcher] or [https://web.archive.org/web/*/http://ps3devwiki.com/files/OtherOSplusplus/misc/boot_ps2.pkg boot_ps2.pkg]): gives ´PS2 disc´ detected at disc icon, but starting gives: resetting of date/time/displayoutput (effectively disabling my mainscreen), then all connection to any bound bluetooth device is lost, even when connected via USB (needs multiple PS button reactivation), and after a long while comes up with the message that the title is not compatible and that the ps3 needs to be updated (Basic nag screen that is on BC PS3s when inserting a noncompatible title).
* With Factory Service Mode enabled (there are no Xmb options to combinetest with [http://www.ps3devwiki.com/files/devtools/lv2-v9-pkg/ LV2Patcher] or [http://www.ps3devwiki.com/files/OtherOSplusplus/misc/boot_ps2.pkg boot_ps2.pkg]): gives ´PS2 disc´ detected at disc icon, but starting gives: resetting of date/time/displayoutput (effectively disabling my mainscreen), then all connection to any bound bluetooth device is lost, even when connected via USB (needs multiple PS button reactivation), and after a long while comes up with the message that the title is not compatible and that the ps3 needs to be updated (Basic nag screen that is on BC PS3s when inserting a noncompatible title).


In short: [https://web.archive.org/web/*/http://ps3devwiki.com/files/OtherOSplusplus/misc/boot_ps2.pkg boot_ps2.pkg] and Factory Service Mode seem to enable simulare (it tries to boot it) while [https://web.archive.org/web/*/http://ps3devwiki.com/files/OtherOSplusplus/misc/boot_ps2.pkg boot_ps2.pkg] gives you more options e.g. using [https://web.archive.org/web/*/http://ps3devwiki.com/files/devtools/lv2-v9-pkg/ LV2Patcher].
In short: [http://www.ps3devwiki.com/files/OtherOSplusplus/misc/boot_ps2.pkg boot_ps2.pkg] and Factory Service Mode seem to enable simulare (it tries to boot it) while [http://www.ps3devwiki.com/files/OtherOSplusplus/misc/boot_ps2.pkg boot_ps2.pkg] gives you more options e.g. using [http://www.ps3devwiki.com/files/devtools/lv2-v9-pkg/ LV2Patcher].
Perhaps hardswapping out all the dev_flash ps2 emu files for the same software only emulator would circumvent the 'incompatible title' message.
Perhaps hardswapping out all the dev_flash ps2 emu files for the same software only emulator would circumvent the 'incompatible title' message.




==== Second test: FW 2.70/3.15 ====  
==== Second test: FW 2.70/3.15 ====  
Silent Hill : gives disk icon "unsupported data" and error message like "This model of the PS3 system is not compatible with Playstation2 format software" when run via disc icon. Using [https://web.archive.org/web/*/http://ps3devwiki.com/files/OtherOSplusplus/misc/boot_ps2.pkg boot_ps2.pkg] gives title not supported error message like "This title is not currently compatible with the PS3 system".
Silent Hill : gives disk icon "unsupported data" and error message like "This model of the PS3 system is not compatible with Playstation2 format software" when run via disc icon. Using [http://www.ps3devwiki.com/files/OtherOSplusplus/misc/boot_ps2.pkg boot_ps2.pkg] gives title not supported error message like "This title is not currently compatible with the PS3 system".


==== Third test: FW 3.55 OtherOS++22GB (with SS Patches) ====  
==== Third test: FW 3.55 OtherOS++22GB (with SS Patches) ====  
Silent Hill : gives disk icon "unsupported data" and error message like "This model of the PS3 system is not compatible with Playstation2 format software" when run via disc icon. Using [https://web.archive.org/web/*/http://ps3devwiki.com/files/OtherOSplusplus/misc/boot_ps2.pkg boot_ps2.pkg] gives blackscreen lockup, not reacting on PS button, or powerbutton, requiring removing powercord.
Silent Hill : gives disk icon "unsupported data" and error message like "This model of the PS3 system is not compatible with Playstation2 format software" when run via disc icon. Using [http://www.ps3devwiki.com/files/OtherOSplusplus/misc/boot_ps2.pkg boot_ps2.pkg] gives blackscreen lockup, not reacting on PS button, or powerbutton, requiring removing powercord.




Line 904: Line 847:
ID match US release of Crazy Taxi. This id is kinda special, because Swap Magic CD version, and some other Datel products like Action Replay use Crazy Taxi TOC in their retail discs.
ID match US release of Crazy Taxi. This id is kinda special, because Swap Magic CD version, and some other Datel products like Action Replay use Crazy Taxi TOC in their retail discs.
Is known that they literally ripped part of disc (with key/logo, and TOC), and frankesteined it with own products.
Is known that they literally ripped part of disc (with key/logo, and TOC), and frankesteined it with own products.
So mentioned check first compare hash, and if that match, then run function that perform another check at disc sector 267559 (0x41527), so exactly where main executable is.  
So mentioned check first compare hash, and if that match, then run function that perform another check at disc sector 267559 (0x41527), so exactly where main executable is.
I didn't figured out what next, but this is probably anti AR/Datel/SM check. What's weird, there seems to be nothing for TimeSplitters2 which if i recall correctly was used for DVD version of Swap Magic.
I didn't figured out what next, but this is probably anti AR/Datel/SM check. What's weird, there seems to be nothing for TimeSplitters2 which if i recall correctly was used for DVD version of Swap Magic.  
<br>There is also check for 0xE794CCB06D  PCPX_980.42  Minna no Tennis entry, emu also refuse to boot it, and throw the same error as with SwapMagic/SCED discs.


==CDVD Commands==
==CDVD Commands==
Line 1,088: Line 1,030:
Every "mechacon_auth" command return zeroed result with different size. Only exception here is 0x81 which return 1.
Every "mechacon_auth" command return zeroed result with different size. Only exception here is 0x81 which return 1.
</pre>
</pre>
==r5900 regs memory map==
Registers are updated only when recompiler flush them to memory, if there is pending operation on the same register in next instruction, recompiler have no need to update reg before that. So it flush result there.
===Netemu===
Address in memory |  r5900 register
FFFFFFFFFFFF8980  |  5900_zero_upper64bits
FFFFFFFFFFFF8988  |  5900_zero_lower64bits
FFFFFFFFFFFF8990  |  5900_at_reg_upper64
FFFFFFFFFFFF8998  |  5900_at_reg_lower64
FFFFFFFFFFFF89A0  |  5900_v0_reg_upper64
FFFFFFFFFFFF89A8  |  5900_v0_reg_lower64
FFFFFFFFFFFF89B0  |  5900_v1_reg_upper64
FFFFFFFFFFFF89B8  |  5900_v1_reg_lower64
FFFFFFFFFFFF89C0  |  5900_a0_reg_upper64
FFFFFFFFFFFF89C8  |  5900_a0_reg_lower64
FFFFFFFFFFFF89D0  |  5900_a1_reg_upper64
FFFFFFFFFFFF89D8  |  5900_a1_reg_lower64
FFFFFFFFFFFF89E0  |  5900_a2_reg_upper64
FFFFFFFFFFFF89E8  |  5900_a2_reg_lower64
FFFFFFFFFFFF89F0  |  5900_a3_reg_upper64
FFFFFFFFFFFF89F8  |  5900_a3_reg_lower64
FFFFFFFFFFFF8A00  |  5900_t0_reg_upper64
FFFFFFFFFFFF8A08  |  5900_t0_reg_lower64
FFFFFFFFFFFF8A10  |  5900_t1_reg_upper64
FFFFFFFFFFFF8A18  |  5900_t1_reg_lower64
FFFFFFFFFFFF8A20  |  5900_t2_reg_upper64
FFFFFFFFFFFF8A28  |  5900_t2_reg_lower64
FFFFFFFFFFFF8A30  |  5900_t3_reg_upper64
FFFFFFFFFFFF8A38  |  5900_t3_reg_lower64
FFFFFFFFFFFF8A40  |  5900_t4_reg_upper64
FFFFFFFFFFFF8A48  |  5900_t4_reg_lower64
FFFFFFFFFFFF8A50  |  5900_t5_reg_upper64
FFFFFFFFFFFF8A58  |  5900_t5_reg_lower64
FFFFFFFFFFFF8A60  |  5900_t6_reg_upper64
FFFFFFFFFFFF8A68  |  5900_t6_reg_lower64
FFFFFFFFFFFF8A70  |  5900_t7_reg_upper64
FFFFFFFFFFFF8A78  |  5900_t7_reg_lower64
FFFFFFFFFFFF8A80  |  5900_s0_reg_upper64
FFFFFFFFFFFF8A88  |  5900_s0_reg_lower64
FFFFFFFFFFFF8A90  |  5900_s1_reg_upper64
FFFFFFFFFFFF8A98  |  5900_s1_reg_lower64
FFFFFFFFFFFF8AA0  |  5900_s2_reg_upper64
FFFFFFFFFFFF8AA8  |  5900_s2_reg_lower64
FFFFFFFFFFFF8AB0  |  5900_s3_reg_upper64
FFFFFFFFFFFF8AB8  |  5900_s3_reg_lower64
FFFFFFFFFFFF8AC0  |  5900_s4_reg_upper64
FFFFFFFFFFFF8AC8  |  5900_s4_reg_lower64
FFFFFFFFFFFF8AD0  |  5900_s5_reg_upper64
FFFFFFFFFFFF8AD8  |  5900_s5_reg_lower64
FFFFFFFFFFFF8AE0  |  5900_s6_reg_upper64
FFFFFFFFFFFF8AE8  |  5900_s6_reg_lower64
FFFFFFFFFFFF8AF0  |  5900_s7_reg_upper64
FFFFFFFFFFFF8AF8  |  5900_s7_reg_lower64
FFFFFFFFFFFF8B00  |  5900_t8_reg_upper64
FFFFFFFFFFFF8B08  |  5900_t8_reg_lower64
FFFFFFFFFFFF8B10  |  5900_t9_reg_upper64
FFFFFFFFFFFF8B18  |  5900_t9_reg_lower64
FFFFFFFFFFFF8B20  |  5900_k0_reg_upper64
FFFFFFFFFFFF8B28  |  5900_k0_reg_lower64
FFFFFFFFFFFF8B30  |  5900_k1_reg_upper64
FFFFFFFFFFFF8B38  |  5900_k1_reg_lower64
FFFFFFFFFFFF8B40  |  5900_gp_reg_upper64
FFFFFFFFFFFF8B48  |  5900_gp_reg_lower64
FFFFFFFFFFFF8B50  |  5900_sp_reg_upper64
FFFFFFFFFFFF8B58  |  5900_sp_reg_lower64
FFFFFFFFFFFF8B60  |  5900_fp_reg_upper64
FFFFFFFFFFFF8B68  |  5900_fp_reg_lower64
FFFFFFFFFFFF8B70  |  5900_ra_reg_upper64
FFFFFFFFFFFF8B78  |  5900_ra_reg_lower64
FFFFFFFFFFFF9100  |  5900_pc_reg_lower64
Below FFFFFFFFFFFF8B78 you can find COP0, and finally VFxx, and VIxx regs. Todo..


==EE I/O Handlers list==
==EE I/O Handlers list==
Line 1,678: Line 1,549:
|-
|-
|}
|}
1000F800 to 1000F8B0 seems to be some fake regs for testing purposes. Probably not existing on real PS2. Addresses not described below are handled as a unk rw. Which mean they return 0 on read, and do nothing on write.
1000F800 to 1000F8B0 seems to be some fake regs for testing purposes. Probably not existing on real PS2.  
* 1000F800 do nothing (blr). Have own handler, which suggest it was used for something earlier. [r/w]
* 1000F820 return "DrJock TV Quiz P"
* 1000F810 get current ppc time base using mftb opcode, if tb == 0 then loop until its not. Could be useful, tb is used also in scheduler. [r only] 
* 1000F830 return "hD bags few lynx"
* 1000F820 return "DrJock TV Quiz P" [r only]
* 1000F830 return "hD bags few lynx" [r only]
That make string "DrJock TV Quiz PhD bags few lynx" - This is perfect summary of Sony work. Since correct pangram should use "MrJock". So even here they made mistake.  
That make string "DrJock TV Quiz PhD bags few lynx" - This is perfect summary of Sony work. Since correct pangram should use "MrJock". So even here they made mistake.  
* 1000F860 seems to return halfword of current pad state (0xFFFF if there is no button input currently). [r only]
* 1F00F880 return hardcoded value of 0x4457, which match emu revision i'm working on. Can be just coincidence.
* 1000F880 return hardcoded value of 0x4457, which match emu revision i'm working on. Can be just coincidence. [r only]
* 1000F8B0 return unk value. Seems to be related to fe spe. [r only]


==Random notes about SPE in ps2_netemu==
==Random notes about SPE in ps2_netemu==
Line 1,785: Line 1,652:
*8 - SPRfrom dma is handled on PPE only it seems
*8 - SPRfrom dma is handled on PPE only it seems
*9 - SPRto dma is handled on PPE only it seems
*9 - SPRto dma is handled on PPE only it seems
Additionally EEDMA handle VU1 code writes/reads, VU1 code is stored at 0x1A000 of LS in big endian. Only VU1 code, VU1 data is handled by SPE2 (VU1), and any VU0 r/w is handled by PPU only.<br>
Additionally EEDMA handle VU1 code writes/reads. Only VU1 code, VU1 data is handled by SPE2 (VU1), and any VU0 r/w is handled by PPU only.<br>
So is more like "Close to GS" DMA handler.
So is more like "Close to GS" DMA handler.


Line 1,791: Line 1,658:


===VU1 emulation on SPE===
===VU1 emulation on SPE===
VU1 SPE program starts at 0x4000 of LS. Start function is responsible for loading all 128 spe registers with values from memory starting from 0x4230 of LS for r0, ends at 0x4A20 for r127 (r127 is trashed literally in next opcode after that...). This should result in all 0 value regs, excluding r0 which will be set to float(1.0, 0, 0, 0) like ps2 vf00. After that function notify PPE side that its done, and jump to 0x8000, here fun begins. SPE program now clear LS memory from 0x0000 to 0x7FF0, this include VU1 data mem that is located at first 0x4000 bytes. What's more important function that we started at 0x4000 will be deleted. Yup, self modifying code on SPU (good luck for eventual emulator that will try to run ps2_netemu).
<br>
When I disassembled VU1 SPE program, i noticed that real code is really small part of that. Not much to run real VU recompiler/interpreter.
When I disassembled VU1 SPE program, i noticed that real code is really small part of that. Not much to run real VU recompiler/interpreter.
Then i found out something impressive in my opinion. Real deal is that real code delivered to SPE is created on PPE dynamically based on real PS2 VU1 code. Due to similarity of SPE with VU requested in IBM by Sony at design level, there is no VU1 interpreter or recompiler per se. Emulator take VU1 code, dismount it to parts by OP field types, and reassemble into ready SPE code using ready hex templates. I'm not familiar with professional naming of that operation, but its like ahead of time translation of code. So when VU1 code reach SPE is already translated to SPE opcodes. In other terms, SPE responsible for running VU1 is really running VU1 code in some way.
Then i found out something impressive in my opinion. Real deal is that real code delivered to SPE is created on PPE dynamically based on real PS2 VU1 code. Due to similarity of SPE with VU requested in IBM by Sony at design level, there is no VU1 interpreter or recompiler per se. Emulator take VU1 code, dismount it to parts by OP field types, and reassemble into ready SPE code using ready hex templates. I'm not familiar with professional naming of that operation, but its like ahead of time translation of code. So when VU1 code reach SPE is already translated to SPE opcodes. In other terms, SPE responsible for running VU1 is really running VU1 code in some way.


In latest ps2_netemu function responsible for translating VU1 code into SPE ready code is located at 0x13C69C
In latest ps2_netemu function responsible for translating VU1 code into SPE ready code is located at 0x13C69C
<br><br>
SPU registers always follow this layout when VU1 is running:
*r0  - r31 = vf00 - vf31
*r32 - r57 = vi00 - vi25 (vu ctrl regs above vi25 are mapped to vu0 anyway)
*r48      = ACC (accessible from VU0 as vi19)
Additionally ppu can access those regs with addresses 0x3000xyy0.
Where x is 4,5,6, or 7 (mirrors), and yy is reg number in hex.
*0x30004100 = vf16
*0x30004200 = vi00
*0x30004350 = I register (vi21)
etc.
Is worth to note that ppu is not accessing spu regs directly, instead 0x3000x000 is mapped to 0x3F000 of vu1 local store. On real PS2 hardware regs are accessible only when VU1 is stopped so program just dump regs to that location on every vu1 stop (ebit/tbit/force break).
This mapping is added specially for VU0 which can access VU1 registers by use of memory address, when vu0 recompiled program run ppu always load 0x30000000 to r1 to compute address if needed.


===IPU SPE6===
===IPU SPE6===
Line 1,864: Line 1,714:


== Emu Patches ==
== Emu Patches ==
===Remove PCRTC Blur for Netemu===
Adds new config 0x4F (no param) which disables PCRTC blur offset which many games use. Patch additionally changes debug menu entry XOR CSR to NO BLUR setting. XOR CSR from file CONFIG is unaffected and still work as expected. I decided to add this entry in menu because it's nice way to compare how good this setting is when game use blur offset. While games which need XOR CSR have very obvious screen corruptions so there is no need for "live" view for it. New config obviously not work on HEN, but CONFIG files which include 0x4F work fine on HEN, command is just skipped, this keeps configs compatible with all current hacks. Big thanks to mrjaredbeta for testing all of this!
Under the hood code compares DISPLAY1 and DISPLAY2 registers and when DX and DY difference is not greater than 6 it mirrors DISPLAY1 to DISPLAY2. Many checks are added to prevent false detection: PMODE need to have enabled 2 circuits, any of DISPLAY registers can't be all 0's, etc. Detection also works for different DW/DH, for games like Soul Calibur 3. Results really vary per game, many games stays unaffected because they modify OFFSET by GIF 0x18/0x19 commands. Good example of game that is nicely improved is Kingdom Hearts 2.
<br><br>Patch is for Evilnat 4.90 ps2_netemu.elf file.
<br>https://www.mediafire.com/file/s83lt9zkwlyhpc2/No_Blur.ppf/file
<br><br>MD5 before patch is applied:
70D22D79A5BB876B8EA2D0FE55D046C7
MD5 after patch is applied:
0B632F05371215AA6BE2C976924737AE
Preview:
https://ibb.co/9sSjmCm (default netemu)
https://ibb.co/G7t11Nq (No Blur enabled)
===Display current PC/RA values for r5900===
Require '''ps2_netemu''' with 3141card patches to display temperatures (every current cfw have it). Mod update values in crazy interval, this is intended. Because mod is used mostly to figure out when game stuck on specific loop. But this can be easily modified to allow less frequent updates. Please note that PC and RA update only when recompiler registers are flushed to memory, luckily for us this happen on every r5900 branch test.
search for (2 times):
3F 40 02 41 63 5A E3 0C 89 3A 00 00 2F 89 00 00
39 29 FF FF 41 9E 00 7C 99 3A 00 00 88 DA 00 01
88 FA 00 02
replace to (2 times):
60 00 00 00 60 00 00 00 60 00 00 00 60 00 00 00
60 00 00 00 60 00 00 00 60 00 00 00 80 C0 91 00
80 E0 8B 7C
search for:
43 45 4C 4C 3A 20 25 30 32 64 20 C2 B0 43 26 23
78 61 3B 52 53 58 3A 20 20 20 25 30 32 64 20 C2
B0 43 00
replace to:
50 43 3A 20 25 30 38 58 26 23 78 61 3B 52 41 3A
20 25 30 38 58 00 00 00 00 00 00 00 00 00 00 00
00 00 00


===Skip demo disc check===
===Skip demo disc check===
Line 1,970: Line 1,783:
  B452CCB51348127DAF8A931B621E5E39
  B452CCB51348127DAF8A931B621E5E39
DL: https://www.mediafire.com/file/kpno5mubyy7q9p0/gx_cfg_ext.ppf/file
DL: https://www.mediafire.com/file/kpno5mubyy7q9p0/gx_cfg_ext.ppf/file
==Inject LIBSD into netemu Bios==
This patch improves compatibility with homebrew. Many homebrews still need hex edits and supplying X modules on disc. But this patch takes care of LIBSD at least. For example, Multiloader 1.41 with midi player mod now works out of the box.
Offsets for unpacked elf file.
0x893470: string TBIN --> LIBSD
0x8DC200: Paste LIBSD file here (Ctrl-B in HxD to overwrite old data).
TBIN file which is replaced is not used in PS2 mode, we can safely patch it. Same can be done for other emulators, just need correcting offsets.


== SPE programs dumper ==
== SPE programs dumper ==
Line 1,986: Line 1,792:
== Random ps2_netemu notes ==
== Random ps2_netemu notes ==


* Some members of pcsx2 team think that emulator is heavily based on early pcsx2. After some reversing this seems to be far away from true. But COP2 and VU0 (and only that for now) really are familiar here and there. To the point where i was able to use pcsx2 code to find names/usage of some variables (mVUbranch for example). But VU0/COP2 is for now only part that have obvious pcsx2 similarities. For example VU1 is different story, and don't even share code with VU0 part of emulator as far as i see.
* Emulator not only patch SPU programs on init, but also patch own PPU code. Which is hard to understand when you can just make changes in source code... eg. 0x1F128 - 0x1F134 in latest emu.
* Emulator not only patch SPU programs on init, but also patch own PPU code. Which is hard to understand when you can just make changes in source code... eg. 0x1F128 - 0x1F134 in latest emu.
* GUI seems to be tied to GIF/GS emulation. That research was inspired by Dolphin progress report, and it seems to be correct. Fe/be (frontend/backend) spus are involved here. Which explain some UI slowdowns on GIF intensive games.
 
* Emulator is full of unused functions. Everything that is compiled inline its also there as separate unreachable function.
* DEV9 registers are not implemented. Reads return 0, writes are void. In simple words Net and PS2 HDD emulation is impossible. Fun fact is that emu perform meaningless check for HDD supported titles.
* USB registers are IMPLEMENTED and seems to be fully functional on ppe and spe side. We are missing something else here, not sure what.
===Registers===
===Registers===
It seems that emulator try to keep lower 64 bits of some r5900 registers in specific ppc registers. At least at the time when recompiler is running, also when 0x01 command run.
It seems that emulator try to keep lower 64 bits of some r5900 registers in specific ppc registers. At least at the time when recompiler is running, also when 0x01 command run.
This helps little bit with understanding some hooks (0x01 commands). Reason is probably optimization, and cached regs are written only when they need to. At least that how it looks like from analyzing recompiled code.
This helps little bit with understanding some hooks (0x01 commands). Reason is probably optimization, and cached regs are written only when they need to. At least that how it looks like from analyzing recompiled code.


r0  = 0x200000000, used when recompiler load something directly from EE memory.
  r13 = unknown, but always preserved.
  r13 = Cycles. When recompiled code run, value is frequently compared to value from negmem F000 and event test is triggered depending on compare result.  
  r14 = .MIPS_PC_REG
  r14 = r5900_current_pc
  r16 = r5900_v0_reg_lower64_cached
r15 = r5900 pc >> 6, used for cache checks. r15 is also used as temp register when fallback to interpreter, etc.  
  r17 = r5900_v1_reg_lower64_cached
  r16 = r5900_v0_reg_lower64
  r18 = r5900_a0_reg_lower64_cached
  r17 = r5900_v1_reg_lower64
  r19 = r5900_a1_reg_lower64_cached
  r18 = r5900_a0_reg_lower64
  r20 = r5900_a2_reg_lower64_cached
  r19 = r5900_a1_reg_lower64
  r21 = r5900_a3_reg_lower64_cached
  r20 = r5900_a2_reg_lower64
  r31 = r5900_ra_reg_lower64_cached
  r21 = r5900_a3_reg_lower64
  r31 = r5900_ra_reg_lower64
   
   
  Additionally, Onimusha hooks expect r25 to be r5900 s0, and r28 to be r5900 s3. But i didn't found other parts of recompiler that expect the same. So, for now only values above are confirmed.
  Additionally, Onimusha hooks expect r25 to be r5900 s0, and r28 to be r5900 s3. But i didn't found other parts of recompiler that expect the same. So, for now only values above are confirmed.
128 bit Altivec registers v20 - v23 are used to keep masks which is most likely used to extract/select/insert COP1 regs for next operations. Additionally v0, and v2 are used for other constants.
v0  = 0x0F0E0D0C, 0x0B0A0908, 0x07060504, 0x03020100
v2  = 0x80000000, 0x80000000, 0x80000000, 0x80000000
v20 = 0xFFFFFFFF, 0x00000000, 0x00000000, 0x00000000
v21 = 0x00000000, 0xFFFFFFFF, 0x00000000, 0x00000000
v22 = 0x00000000, 0x00000000, 0xFFFFFFFF, 0x00000000
v22 = 0x00000000, 0x00000000, 0x00000000, 0xFFFFFFFF
128 bit Altivec registers v24 - v31 are used as COP1 (fpu) regs.
v24 = f00, f01, f02, f03
v25 = f04, f05, f06, f07
v26 = f08, f09, f10, f11
v27 = f12, f13, f14, f15
v28 = f16, f17, f18, f19
v29 = f20, f21, f22, f23
v30 = f24, f25, f26, f27
v31 = f28, f29, f30, f31
Register that handle ACC is taken from different pool (same pool as all vfXX regs when in COP2 mode) with param 32 as reg nr (not real reg, probably part of one of vXX regs).
Most likely those regs are flushed to memory when COP2 opcode is running, for sure they are flushed when VU0 microprogram is running.
=== EE Timers Count Read ===
Emulator have bizarre behavior for EE Tx Count read (0x10000000, 10000800, etc). In specific situation (related to pending edge triggered irq) instead of Count value emulator returns Mode value. This doesn't look like programming error and can be some kind of ps2 undocumented behavior implementation.
=== DataStorage vector hook ===
What normally should work as DataStorage exception handler is hacked into very ugly dispatcher for EE related handlers. This code is used for example to read/write IPU registers. At the time when vector is reached:
* Emulator preserves few registers on custom stack at 0x800000. Registers seems to be little random, but they are not. This code is launched from recompiled mips code.
* srr0 is backed up to r3 register (address where exception occurred + 4, rfid opcode jump to address from that reg) and since now it is also used as argument for next steps.
* srr0 is given new value of 0x2EFCC which is custom "dispatcher", link register changes to 0x28F8C8 which is return from that custom piece of... code.
* rfid is hit, let's go to our newly hooked srr0 with 0x2EFCC address.
* Time to use address preserved in r3. This address going thru few checks, it needs to be in 0x10000000- 0x12FFFFFF range (EE JIT Code).
* From this address emulator get single word, that word is used to figure out what mips code wanted to do. This isn't simple offset but some kind of custom identifier.
* When matching identifier is found, task is performed. Some tasks just jump to function and do what is needed, some continue that hackfest and instead are injected into recompiled code as branches to functions that will perform what game want them to do.
* blr is hit, remember that link register is patched earlier to 0x28F8C8
* This function restores previously backed up regs and set link register to value returned by hook. That's all.
=== Free sapce in config parser ===
Since CELL B.E. is big endian machine is only natural to Sony to use little endian for CONFIG files and byte reverse every single word for them. :) What's more important for us, CELL have special opcodes for situation like that one, lwbrx and stwbrx (load/store word byte reversed indexed). But compiler decided that it will be better to do old fashioned 8 opcodes load/swap by shifts and masks and 'or'. This leaves us a lot of space when implementing new configs, making things nice and clean without need to jump outside of function, etc. This code:
seg020:000000000012EECC        lwzx      r0, r9, r31
seg020:000000000012EED0        srwi      r11, r0, 24
seg020:000000000012EED4        rlwinm    r9, r0, 8,8,15
seg020:000000000012EED8        slwi      r3, r0, 24
seg020:000000000012EEDC        rlwinm    r0, r0, 24,16,23
seg020:000000000012EEE0        or        r3, r3, r9
seg020:000000000012EEE4        or        r0, r0, r11
seg020:000000000012EEE8        or        r3, r3, r0
seg020:000000000012EEEC        clrldi    r3, r3, 32
Can be replaced by simple:
seg020:000000000012EECC        lwbrx    r3, r9, r31
seg020:000000000012EED0        clrldi    r3, r3, 32


== RSX workload on the netemu ==
== RSX workload on the netemu ==
Line 2,066: Line 1,816:
* Yes, i don't see why not. Assuming that is static patch to elf file, not some cobra style on the fly patch. But don't expect some magic from that. I don't know too much about RSX and not really much about GS. But PS2 emulation is usually limited by CPU power, specially in native resolution. But for example games that need 0x44 cmd, maybe they will work with smoothing now. Maybe some minor slowdowns will be fixed. I still don't know which parts of GS are emulated on RSX, for example softemu used something similar to pcsx2 software render. So there you will get almost nothing from RSX OC. But netemu is different. --[[User:Kozarovv|Kozarovv]] ([[User talk:Kozarovv|talk]]) 04:56, 20 March 2022 (UTC)
* Yes, i don't see why not. Assuming that is static patch to elf file, not some cobra style on the fly patch. But don't expect some magic from that. I don't know too much about RSX and not really much about GS. But PS2 emulation is usually limited by CPU power, specially in native resolution. But for example games that need 0x44 cmd, maybe they will work with smoothing now. Maybe some minor slowdowns will be fixed. I still don't know which parts of GS are emulated on RSX, for example softemu used something similar to pcsx2 software render. So there you will get almost nothing from RSX OC. But netemu is different. --[[User:Kozarovv|Kozarovv]] ([[User talk:Kozarovv|talk]]) 04:56, 20 March 2022 (UTC)
** Tested the 600/750 MHz overclock with a few intensive games (SC3, ToCA3, CMR3, VP2, GT4). Assuming the patches are correctly applied (I have no idea at all), there is no performance boost at all.--[[User:Agrippa|Agrippa]] ([[User talk:Agrippa|talk]]) 15:24, 29 May 2022 (UTC)
** Tested the 600/750 MHz overclock with a few intensive games (SC3, ToCA3, CMR3, VP2, GT4). Assuming the patches are correctly applied (I have no idea at all), there is no performance boost at all.--[[User:Agrippa|Agrippa]] ([[User talk:Agrippa|talk]]) 15:24, 29 May 2022 (UTC)
*** Little bit late, but it seems that GS is almost fully "software" emulated (PPE + BE SPE). It was mistake to not touch ps2_softemu earlier, because that's what helped me to find out that all shaders in netemu are not strictly emulation related. While softemu have Cg shaders for hardware render. --[[User:Kozarovv|Kozarovv]] ([[User talk:Kozarovv|talk]]) 14:48, 29 June 2023 (CEST)


== Netemu load/store with r0 register ==
== Netemu load/store with r0 register ==
Line 2,073: Line 1,822:
Also easier example (without using negative addressing because this is additional emu quirk..). ld r2, 0x3008(r0). This opcode will load double word from 0x3008 address no matter what we currently have in r0, because RA is 0 which is badly interpreted as r0 base.
Also easier example (without using negative addressing because this is additional emu quirk..). ld r2, 0x3008(r0). This opcode will load double word from 0x3008 address no matter what we currently have in r0, because RA is 0 which is badly interpreted as r0 base.


This is because of PowerPC quirk that i (and apparently IDA in 64 bit mode) wasn't aware. From IBM manual:
This is because of PowerPC quirk that i (and apparently IDA) wasn't aware. From IBM manual:


  ld RT, Disp(RA)
  ld RT, Disp(RA)
Line 2,087: Line 1,836:
Tl;dr is that if RA is 0 (which disassemblers show as r0), then Disp is real load/store address. This is used many times in emu itself to access negative addresses (0xFFFFFFFFxxxxxxxx), and is used in all netemu cmd 0x01 hooks.  
Tl;dr is that if RA is 0 (which disassemblers show as r0), then Disp is real load/store address. This is used many times in emu itself to access negative addresses (0xFFFFFFFFxxxxxxxx), and is used in all netemu cmd 0x01 hooks.  
While this is more PPC itself than emu stuff, i feel is important to mention this here.  
While this is more PPC itself than emu stuff, i feel is important to mention this here.  
Now if we remember that emu have mapped "negative address", loads/stores with r0 starting to make sense.  
Now if we remember that emu have mapped "negative address", functions like below starting to make sense.  


  std      r4, 0x3008(r0) # store r4 on 0x3008, no matter what r0 actually is at the moment.
sub_186A40:                            # CODE XREF: VIF0_big_jumptable_3026C+FCC↑p
   
std      r0, -0x6BF0(r0) # store r0 on 0xFFFFFFFFFFFF9410, no matter what r0 actually is at the moment.
  std      r4, -0x6BD0(r0) # store r4 on 0xFFFFFFFFFFFF9430, no matter what r0 actually is at the moment.
  std      r5, -0x6BC8(r0)
std      r6, -0x6BC0(r0)
std      r7, -0x6BB8(r0)
std      r8, -0x6BB0(r0)
std      r9, -0x6BA8(r0)
std      r10, -0x6BA0(r0)
std      r11, -0x6B98(r0)
std      r12, -0x6B90(r0)
mflr      r4
std      r1, -0x6BE8(r0)
std      r2, -0x6BE0(r0)
std      r3, -0x6BD8(r0)
std      r4, -0x7F80(r0)
bl        .VU0_cmd_0x12_fl_overflow_related
ld        r4, -0x7F80(r0)
ld        r1, -0x6BE8(r0)
ld        r2, -0x6BE0(r0)
ld        r3, -0x6BD8(r0)
mtlr      r4
  ld        r0, -0x6BF0(r0) # load to r0 from address 0xFFFFFFFFFFFF9410, no matter what r0 actually is at the moment.
  ld        r0, -0x6BF0(r0) # load to r0 from address 0xFFFFFFFFFFFF9410, no matter what r0 actually is at the moment.
  ld        r4, 0x3008(r0) # load to r4 from address 0x3008, no matter what r0 actually is at the moment.
  ld        r4, -0x6BD0(r0) # load to r4 from address 0xFFFFFFFFFFFF9430, no matter what r0 actually is at the moment.
 
ld        r5, -0x6BC8(r0)
== Communication with Graphics Synthesizer in ps2_gxemu ==
ld        r6, -0x6BC0(r0)
 
ld        r7, -0x6BB8(r0)
Communication from emu level is done with rw to special addresses of what seems to be RSX ports.
ld        r8, -0x6BB0(r0)
Emu includes thin translation layer that intercept rw operations to GS privilaged registers.
ld        r9, -0x6BA8(r0)
Emulator to write or read GS register first need to write register number that we want to access. To do that we use one of two exposed 32 bit ports, separate for reads and writes.
  ld        r10, -0x6BA0(r0)
 
  ld        r11, -0x6B98(r0)
To write GS register first write 64 bit data to write buffer. Separate for lower 32 bit (0xA000304C) and upper (0xA0003048) part of GS write. GS regs are 64 bit while RSX operate on 32 ports.
  ld        r12, -0x6B90(r0)
Finally write translated register number to 0xA0003040. This write starts transfer to GS. To ensure everything went ok emulator performs 32 bit read from 0xA0003000 and check if bit 1 is active.
  blr
This operation is performed in loop up to 1000 times until bit 1 is not 0, if that is not the case in mentioned 1000 loops panic is called.
 
To read GS register first write translated register number to 0xA0003050, then wait for bit 1 of 0xA0003000 to be active. Emulator wait up to 1000 read loops if GS didn't answered in that time emu panic.
Now when bit 1 is not 0, data can be read from 0xA0003058 for upper 32 bits and 0xA000305C for lower 32 bits.
Emulator translate almost all reads to CSR. Only SIGLBLID is readable beside CSR. This is real PS2 GS behavior. Although there is unused runtime that allow read any register. Behavior in that case is unknown.
 
  0x00 = PMODE
  0x01 = SMODE1
  0x02 = SMODE2
0x03 = SRFSH
0x04 = SYNCH1
0x05 = SYNCH2
0x06 = SYNCV
0x07 = DISPFB1
0x08 = DISPLAY1
0x09 = DISPFB2
0x0A = DISPLAY2
0x0B = EXTBUF
0x0C = EXTDATA
0x0D = EXTWRITE
0x0E = BDCOLOR
0x40 = CSR
0x41 = IMR
0x44 = BUSDIR
  0x48 = SIGLBLID


== ps2_gxemu external bios/rom loading. ==
== ps2_gxemu external bios/rom loading. ==
Line 2,177: Line 1,920:
  ori a,a, 0xXXXX
  ori a,a, 0xXXXX
  lvx d,a, 0x0
  lvx d,a, 0x0
Accurate add/sub is really over-complicated, I think is possible to shrink it to prevents slow downs and cache resets when overused. For example instead of creating "constants", we can really use constants from unused memory. On every single accurate add/sub emulator run this code:
0x18726C    li        r9, -1                # --- start of "constants" creation ---
0x187270    clrlwi    r9, r9, 1            # r9 = 0x7FFFFFFF
0x187274    stw      r9, 0x20(r31)
0x187278    li        r9, 0xFF
0x18727C    stw      r9, 0x24(r31)
0x187280    li        r9, 31
0x187284    stw      r9, 0x28(r31)
0x187288    li        r9, 23
0x18728C    stw      r9, 0x2C(r31)
0x187290    li        r9, 0x20 # ' '
0x187294    lvxl      v16, r9, r31          # Load from 0x20(r31)
0x187294                                    # [0x7FFFFFFF, 255, 31, 23]
0x187298    li        r9, 0x97
0x18729C    stw      r9, 0x20(r31)
0x1872A0    clrlslwi  r9, r9, 31,23        # 4B800000 ?
0x1872A4    stw      r9, 0x24(r31)
0x1872A8    li        r9, 25
0x1872AC    stw      r9, 0x28(r31)
0x1872B0    li        r9, -1
0x1872B4    clrrwi    r9, r9, 8            # r9 = 0xFFFFFF00
0x1872B8    stw      r9, 0x2C(r31)
0x1872BC    li        r9, 0x20 # ' '
0x1872C0    lvxl      v15, r9, r31          # Load from 0x20(r31)
0x1872C0                                    # [0x97, 0x4B800000, 25, 0xFFFFFF00]
0x1872C0                                    # End of "constants" creation.
All that to load vector v15 with [0x97, 0x4B800000, 25, 0xFFFFFF00], and v16 with [0x7FFFFFFF, 255, 31, 23]. This is really painful when you need to do that on every accurate add/sub, 22 opcodes, even more cycles. But what if we patch emulator to have those values for example at 0x7000 - 0x701F offset? Then loading constants will be:
0x18726C    li        r9, 0x7000
0x187270    lvxl      v16, r9, r0
0x187274    addi      r9, r9, 0x10
0x187278    lvxl      v16, r9, r0
From 22 opcodes we end up with 4. 18 opcodes less on every accurate add/sub. Additionally we can skip preserving/restoring of LR, CTR, and maybe XER. That give another saving of 12 opcodes. Additional 2 opcodes could be saved by not using r6 as temp for save/restore values. We can reuse r9 instead, so there is no need to preserve/restore old r6. All that shrink add/sub from 216 opcodes to 184. For FPU add/sub even more could be done, but for VU/COP2 its most likely only possible optimisation. Still worth it, should bring noticeable difference in framerate on intensive games that need it.


== Ugly fix for HDD whitelisted games loaded through Cobra ==
== Ugly fix for HDD whitelisted games loaded through Cobra ==
Line 2,218: Line 1,925:
The HDD whitelisted games are crashing when loaded through the Cobra (they do work as a 2P package, but the HDD install prompt does not appear of course). I do not know whether the backwards compatible models are affected. The serial ID is compared in the game_ext_plugin module and currently the webMAN MOD does rename the executable inside the ISO to avoid the check. Here is a patch meant to be done on the fly in the payload when mounting the game. Only the SOCOM games have been tested - the HDD install prompt appears and regardless of what you choose, the game will boot successfully.
The HDD whitelisted games are crashing when loaded through the Cobra (they do work as a 2P package, but the HDD install prompt does not appear of course). I do not know whether the backwards compatible models are affected. The serial ID is compared in the game_ext_plugin module and currently the webMAN MOD does rename the executable inside the ISO to avoid the check. Here is a patch meant to be done on the fly in the payload when mounting the game. Only the SOCOM games have been tested - the HDD install prompt appears and regardless of what you choose, the game will boot successfully.
<pre>
<pre>
Original: 4B FF 1A 11 38 81 00 A0 38 61 00 AC 4B FF ED 3D
Original: 40 FE 00 34 3B FF FE D4 98 1E 00 0B 7F E3 FB 78 48 02 CF 35 3D 60 80 02 2B 83 00 1F 61 6B 8F 00 41 9D 00 78
Patched:  60 00 00 00 38 81 00 A0 38 61 00 AC 4B FF ED 3D</pre>
Patched:  60 00 00 00 3B FF FE D4 98 1E 00 0B 7F E3 FB 78 48 02 CF 35 3D 60 80 02 2B 83 00 1F 61 6B 8F 00 48 00 00 78</pre>


== Unknown VIF issue - bad cmd ==
== Puzzle Quest ==
Emulator seems to do something wrong when bad (unknown) command is sent to VIF. Since all examples are related to VIF1 lets assume that maybe only that part is broken.
This should apply also to netemu, i guess it is still issue. Compatibility list don't have that entry. : https://github.com/PCSX2/pcsx2/issues/6733#issuecomment-1304643183
* The issue is there on netemu, but this method does not seem to fix it. I tried both 0x0A and 0x0B configs as a test.--[[User:Mrjaredbeta|Mrjaredbeta]] ([[User talk:Mrjaredbeta|talk]]) 23:36, 5 November 2022 (UTC)
** Yeah. I decided to look into that, and there seems to be no chance it will run on netemu without massive patch. Game send vif1 command to set mask3, then starts gif transfer and expect it to be timed precise enough to lift that mask and transfer few more qw while unpack on vif going on. Then again set mask by vif1 0x06 command and expect that gif transfer that is going on will be at good place for that mask. I think i can fix this, specially that old pcsx2 is also affected. But this is on "very far away todo list". To make it work, we probably need to split gif transfer, and this is already pain because it's chain transfer. This patch work on pcsx2 because they actually have implemented pretty decent timings, just way they handle intermittent mode make it broken apparently (send most of gif dma transfer anyway, and care more about timing closer to transfer finish). --[[User:Kozarovv|Kozarovv]] ([[User talk:Kozarovv|talk]]) 10:43, 9 November 2022 (UTC)


* Buffy send command 0x12 - At the time when command is sent VIF1_ERR.ME1 bit is not set. Correct behavior will be stall VIF, seems to be broken because stall take too long.
== Games with suspected DMA issues ==
* Jak TPL accidentally send bad data (vectors floats) as cmd - At the time when command is sent VIF1_ERR.ME1 bit is set. Correct behavior will be ignore bad cmd, and handle it as nop, no stall.
List of games with DMA issues that are currently unfixed:
* Formula One 05 bad cmd when entering pitstop - Unknown reason, fixed in pcsx2 at some unknown point. Can be dma issue, but worth to check if netemu is affected in any way (https://github.com/PCSX2/pcsx2/issues/2918)
* General note. PS2 VIF seems to be broken by design. Manual have following warnings:  
** Due to a failure in determining DMAtag Mismatch error, setting ME0 bit to 0 may generate an error even though a correct packet has been transmitted.  Set the ME0 bit to 1 when using it.
** In V3_16 format, set the ME1 bit to 1.
** The ER0 bit cannot be used appropriately due to a failure in determining DMAtag Mismatch error. Mask the DMAtag Mismatch error detection feature by setting VIF0_ERR.ME0 to 1.


Code which handle bad cmd:
* '''Reveal Fantasia (SLPS-25094)'''
0x14D00  ila    r4, 0x2000
** DMA timing issue due to GIF transfers of (mostly) text data, arising from GRBAT_set functions which set data to transfer(?).
0x14D04  shufb  r2, r104, r104, r89
** Recently fixed in PCSX2 with Instant DMA.
0x14D08  ila    sp, sub_147C0
** Currently fixed with added loop on EE so GIF DMA is not overwritten too fast.
0x14D0C  a      r2, r2, r77
* '''Street Fighter EX3 (SLPS-20003, SLUS-20130, SLES-50072)'''
0x14D10  shufb  r2, r103, r102, r2
** DMA timing issue due to GIF transfer of 2D HUD data. Freezes at the start or close to the start of the HUD showing. SLPS-20003 freezes a lot less consistently, most likely timing differences due to unoptimized assembly code.
0x14D14  stqa    r2, VIF1_CODE
** Current fix skips 2D HUD rendering and in turn fixes freezing issues.
0x14D18  lqa    r2, VIF1_ERR
* '''Melty Blood games, Arcana Heart games'''
0x14D1C  lqa    r3, VIF1_STAT
** PCSX2 has similar issue with possible freeze during Actress Again logo intro, but netemu behaves a bit differently. It is most likely fixed with Instant DMA on PCSX2 (needs confirmation).
0x14D20  andi    r2, r2, 4          ; VIF1_ERR.ME1
** Actress Again intro freezes later than PCSX2. Actress Again intro freezes at random points, and some stages/character select/character intros also freeze.
0x14D24  ceqi    r2, r2, 0          ; set if bad cmd is unmasked
** No current fix for netemu.
0x14D28  selb    r3, r3, r2, r4    ; Set VIF_STAT.ER1 if bad cmd bit mask is not active
0x14D2C  andi    r4, r2, 0x10
0x14D30  selb    r2, sp, r39, r2    ; sub_147C0[sp] or (sub_12840 or sub_17700)[r39] depending on ME1 bit // Probably issue starts here.  
0x14D34  lnop
0x14D38  or      r87, r87, r4      ; Unk flags, stored at 0x290
0x14D3C  stqa    r3, VIF1_STAT
0x14D40  nop
0x14D44  bi      r2
*Shoutout to Agrippa for finding where the bad cmd in J&D was sent out. Formula One 05 is affected and results in a freeze when entering the pit stop, but I created a patch a while ago to skip the sending of it, so current config fixes the freeze without issue.--[[User:Mrjaredbeta|Mrjaredbeta]] ([[User talk:Mrjaredbeta|talk]]) 03:37, 12 February 2023 (CET)


== Games with EE threading/interrupt issues ==
All games have been tested with command 0x01 GIF/VIF1 hooks to no avail.


* '''Harry Potter and the Chamber of Secrets'''
* '''Discussion'''
** Seems to randomly hang on the last stage of loading (ra=0x19bf70). WaitSema calls spotted during the hang.
I decided to port RF config to Street Fighter 3 EX (SLUS), this way we should be able to check if that's really timing issue. Config work same way as before 00 20 19 24 is loop count (cur. 0x2000, max 0x7FFF) --[[User:Kozarovv|Kozarovv]] ([[User talk:Kozarovv|talk]]) 18:25, 2 January 2023 (UTC)
* '''Gran Turismo 4'''
0a 00 00 00 07 00 00 00 50 44 16 00 20 ff bd 27
** Hangs during the FMV playback on the idle wait loop. Game does wait for the interrupt that does not happen, probably.
f0 ff 03 08 54 44 16 00 80 00 b5 ff 20 ff bd 27
***Game wait in 81FC0 loop or some custom one? Never leave it? --[[User:Kozarovv|Kozarovv]] ([[User talk:Kozarovv|talk]]) 19:01, 11 April 2023 (CEST)
c0 ff 0f 00 00 00 00 00 00 20 19 24 c4 ff 0f 00
****In the 81FC0 loop. It does leave for a split second indeed, but it is impossible to read the offset. The game is working right in gxemu, I have always wondered if the built-in CDVD emulation may be bugged somehow, introducing new glitches versus gxemu.--[[User:Agrippa|Agrippa]] ([[User talk:Agrippa|talk]]) 19:39, 11 April 2023 (CEST)
00 00 00 00 ff ff 19 14 c8 ff 0f 00 00 00 00 00
ff ff 39 27 cc ff 0f 00 00 00 00 00 16 91 05 08
d0 ff 0f 00 00 00 00 00 80 00 b5 ff


Assuming the game programming is right, the underlying issues are data transfer related, probably.
== Stuntman/Driv3r research ==
 
== Games with GS emulation issues ==
Neither performance, nor mipmap and SCANMSK related.
* '''Prince of Persia: Warrior Within'''
** Weapons' trails are rainbow (fixed by Auto-flush in PCSX2).
* '''Lord of the Rings: The Return of the King'''
** Top-left corner issue when the mist/fog is rendered.
* '''Dance Summit 2001: Bust-a-Move'''
** Front buffer is not flushed most of the time. Game seems to apply additional effects there, apart from the downsampling.
* '''Snowblind Engine 2003+ games'''
** Shows the very last "interlaced" frame when switching back to the interlaced mode from progressive one. I thought it could be a VBLANK issue, but that old frame should be long gone by then. The issue seems to be related to the PCRTC. The SMODE2 register is updated in the VBLANK handler. That old frame is shown when the FFMD bit is switched to 1. Looking for better workarounds than delaying the VSYNC or lowering the resolution in 60 fps mode. By the way, the 0x20 command does work with negative values too. Moreover, the max positive value for NTSC is something like 0x106. Anything higher makes the screen freeze on PS2 logo (but the game is working in the background).
 
== Stuntman/Driv3r research ==
Well, I decided to take another look at this game a few days ago after a weird dream I had. I am glad I did, since I have discovered some new things. This is with 0x0E accuracy adjustments.  
Well, I decided to take another look at this game a few days ago after a weird dream I had. I am glad I did, since I have discovered some new things. This is with 0x0E accuracy adjustments.  


Line 2,305: Line 1,989:


This does not seem to make any stages completable, but it at least helps the AI car in 1-4 get past the indoor section and not get caught up on the turn/area after. Instead, it now hits the orange crate left of the path it is supposed to go. It could potentially have worse effects on other stages as well... Maybe these offsets/functions in particular can help PCSX2 research.
This does not seem to make any stages completable, but it at least helps the AI car in 1-4 get past the indoor section and not get caught up on the turn/area after. Instead, it now hits the orange crate left of the path it is supposed to go. It could potentially have worse effects on other stages as well... Maybe these offsets/functions in particular can help PCSX2 research.
*Try with EU version, you should be able to complete that mission with accu config. I remember that on pcsx2 with hacked vadd almost full EU game is playable. At some point i also hacked dyStepRunge little bit. dyStepRunge1 is less accurate, dyStepRunge5 is most accurate. Game decide which function should be used. But you can patch it to branch always to dyStepRunge5 etc. --[[User:Kozarovv|Kozarovv]] ([[User talk:Kozarovv|talk]]) 20:03, 4 January 2023 (UTC)


== Patches for SCCS region games ==
== Patches for SCCS region games ==
Line 2,354: Line 2,037:
* I believe that real PS2 also need those patches. For OPL, but not only. ROM2 with CH fonts is not existing outside of 3 ps2 models. All of them released only in China, and one of them is still not even dumped (devkit). This ROM2 is even missing in Hong Kong region PS2. Btw. When i implemented ROM2 support in pcsx2, i tested patching game first. Unluckily for netemu, and fortunately for pcsx2. First and only game i tried to patch was Ape Escape 2. :) --[[User:Kozarovv|Kozarovv]] ([[User talk:Kozarovv|talk]]) 12:39, 23 November 2022 (UTC)
* I believe that real PS2 also need those patches. For OPL, but not only. ROM2 with CH fonts is not existing outside of 3 ps2 models. All of them released only in China, and one of them is still not even dumped (devkit). This ROM2 is even missing in Hong Kong region PS2. Btw. When i implemented ROM2 support in pcsx2, i tested patching game first. Unluckily for netemu, and fortunately for pcsx2. First and only game i tried to patch was Ape Escape 2. :) --[[User:Kozarovv|Kozarovv]] ([[User talk:Kozarovv|talk]]) 12:39, 23 November 2022 (UTC)
** Yup, lucky for me I tested Dynasty Warriors 3 first, then Ape Escape 2 was the second if I recall. I was worried but pleasantly surprised by the rest of the results. I assume ROM2 has data for simplified Chinese characters while Hong Kong/Taiwan uses traditional characters, and that’s probably why there is no ROM2 in the HK/TW region. I am not sure why they even included ROM2 in the first place if barely any games utilize it, but oh well. --[[User:Mrjaredbeta|Mrjaredbeta]] ([[User talk:Mrjaredbeta|talk]]) 18:01, 28 November 2022 (UTC)
** Yup, lucky for me I tested Dynasty Warriors 3 first, then Ape Escape 2 was the second if I recall. I was worried but pleasantly surprised by the rest of the results. I assume ROM2 has data for simplified Chinese characters while Hong Kong/Taiwan uses traditional characters, and that’s probably why there is no ROM2 in the HK/TW region. I am not sure why they even included ROM2 in the first place if barely any games utilize it, but oh well. --[[User:Mrjaredbeta|Mrjaredbeta]] ([[User talk:Mrjaredbeta|talk]]) 18:01, 28 November 2022 (UTC)
*** "PS4 seems to not work with these patches. Even the bootable games without patching needed do not work, so I suspect there is some blacklist preventing them from booting on that emulator.". Just for the record, ps4 don't blacklist them. It's issue with cdvdkey (known for PS3 users as "game hash". ;) ). Emulator fail to respond correctly to one of CDVD register reads. Issue is already patched with my ugly hacks (TC:LA-a-like code swap). Your patches are still required on ps4 after fixing other issues. --[[User:Kozarovv|Kozarovv]] ([[User talk:Kozarovv|talk]]) 17:39, 20 June 2023 (CEST)
== Removing stuff from ps2 emu page ==
I'm thinking about removing some data from PS2 Emulation page. Mostly stuff that is strictly PS2 thing.
*PS2 Memory and Hardware Mapped Registers Layout
*Video Modes
*Config related info
'''Video Modes''' listed there are not even supported by emulators without GS, and likely to fail even on PS3 with GS. This is really info for PS2 wiki in my opinion. '''PS2 Memory and Hardware Mapped Registers Layout''' also fit more in PS2 wiki. This is more like general PS2 dev knowledge than emulation related stuff. Eventually keep them as a links to ps2tek or ps2 devwiki, or something. Let me know if you think this is/isn't good idea. For example PS1 page don't list stuff like this, same goes for PSP page. In case of Config stuff. This is crucial part of this page, but i feel that harm general readability. Due to complicated nature of PS2 config descriptions are getting bigger, and bigger. Honestly this is still missing a lot of info because many times we are limiting ourself to not make descriptions too extensive. All that to not flood page too much. Maybe it's time to move most of that to new dedicated page? We can leave some basic info, like that small table, plus some '''BOLD''' link to "advanced page". This should allow to wikify and move some non-config stuff from talk page. This are only ideas, i expect not everyone will be happy about all of them. Lets talk. :P --[[User:Kozarovv|Kozarovv]] ([[User talk:Kozarovv|talk]]) 08:21, 16 January 2023 (UTC)
* I think these are all good ideas. I occasionally use the PS2 register info for help sometimes, but I could easily use PSI’s page for that (https://psi-rockin.github.io/ps2tek/). I agree that it doesn’t really belong on the page. I agree that emulation page is getting extensive, so maybe it would be good to move the config info to a new page. I am not opposed and are all for it. --[[User:Mrjaredbeta|Mrjaredbeta]] ([[User talk:Mrjaredbeta|talk]]) 15:12, 16 January 2023 (UTC)
== Floating point arithmetic inaccuracies ==
While the software emulators are doing a great job with their accurate paths, there are still issues with some games, unfortunately.
* Stuntman/Driv3r
Completely broken AI, game is unplayable.
* Gran Turismo series
An infamous licence demonstration bug - cars deviate from the racing line. It may affect the AI in the race too. Since the GT's AI is retarded, the subject is difficult to confirm.
* Tokyo Xtreme Racer Zero
It is unconfirmed, but the cars path from PS2 imported replays are played back wrongly in the PCSX2.
* PRIDE FC: Fighting Championships
It seems that y × 1 ≠ y sometimes. Fixed by patching the game code.
== Manipulating r5900 cyclerate ==
Cycles are count in function located at 0x17C9D0 (latest netemu). Emitter with addi to r13 register is what we are looking for. Since pcsx2 use different "unit", lets just call cycles here a... unit.
  _________________________________________________
|  Opcode type  |  Netemu/Gxemu  |    PCSX2  |
|----------------|------------------|-------------|
| Default opcode |    1 unit      |    9 units  |
| Load/Store    |    2 units      |  14 units  |
| Multiply      |    4 units      |  16 units  |
| Divide        |    37 units      |  112 units  |
| COP 0          |    1 unit      |    7 units  |
| COP 1          |  1 unit(some 2)  |    7 units  |
| COP 2          |    1 unit      |    7 units  |
| NOP            |  0 units(!!!)  |  7? units  |
---------------------------------------------------
Additionally pcsx2 use different cycles for many other opcodes that ps3 emus just count as one.
  * MMI      =  14 units
  * MMI Mult =  24 units
  * MMI Div  = 176 units
  * FPU Mul  =  32 units
At the second hand gx/net emu do some weird shenigans with cycles based on... Opcode number, this is still small unknown here. Yeah...
  It turns out that emu is not counting nop cycles. Weird shenigans mentioned above check if opcode number is 1, which belongs to ee NOP in internal emu table.
  When opcode is NOP then emulator is not adding even single cycle. This explains a lot of issues with dma and why EE always seemed too fast for DMA and other components.
  This code takes 2 cycles (units) per loop in emu:
loop_here:
  addiu v0, -1
  nop
  nop
  nop
  nop
  nop
  bnez v0, loop_here
I still need to fully confirm that nop isn't handled in some special way elsewhere but looks like it's not.
Underclocking/Overclocking could be done by modifying opcodes at 0x17CEB0, 0x17CFF8, 0x17D4C8.
What has been tested do far is shifting by 1 or 2 to the left (underclock by multiplying passed cycles). Sadly without any possitive result to framerate, shift by 2 was even slower.
== Emulator status flags ==
We can't really modify this flag from outside on retail emu, but we can always patch function that do init.
===Netemu===
Localised at 0x934158 of emu memory.
1        = init done?
2        = unk thr sys
4        = unk thr sys
8        = unk
10      = run watchpoint opcode (debug halt) 0x11DD80
20      = set mecha 0x245828A to 2, and run sc8 (0x200)
40      = some setting for spe0_class0_int_handler
80      = enable cmd 0xF/0x26/0x27 for whole memory range
200      = set when emulated hardware init is done
400      = enable 0x934160 debug flag (watchpoint on ee and on iop)
800      = skip parsing config file
1000    = do cmd 0x1F with 0x3E8(1000) param
4000    = enable cmd 0x11 for whole VU0 mem (per range setting is inaccessible from config!)
20000    = skip SCED discs error (more, todo)
40000    = do cmd 0x14
80000    = memory card related (0x12A6D8) also run sc_7(2) in thr hdd
200000  = do cmd 0x05
400000  = enable config cmd 0x10 for whole memory range
800000  = do cmd 0x12 with 0x2DFF000 flags
4000000  = mecha related (todo 0x135664)
8000000  = run loop that wait for 0xB52BB8 to be non zero
10000000 = watchpoint (if thread flag is set)
20000000 = timing setting for media validity check
80000000 = show health warning message
Need work
===Gxemu===
Localised at 0x3ED0 of emu memory.
1        = init done?
2        = load external bios.rom
4        = run sub_56784 and sub_56A6C
8        = unk
10      = run watchpoint opcode (debug halt) 0x3F02C
20      = set mecha 0x177AA4F to 2, and run sc8 (0x200) ___todo
40      = some setting for spe0_class0_int_handler
80      = enable gx cmd 0xC/0x22/0x23 for whole memory range
200      = check byte 0x6E6302 and do something if 2. Seems to disable media validity test. Set after EE hw init.
400      = set 0x3D60 to 1
800      = skip parsing internal config list
1000    = do gx cmd 0x1C with param 0x3E8 (1000)
4000    = enable cmd 0x0F for whole VU0 mem (per range setting is inaccessible from config!)
10000    = used as a param for sub_40054, unknown. Not available in netemu
20000    = skip auto setting gx cmd 0x19 for games from hashlist, and later in different sub. Also skip setting SCED error.
40000    = do gx cmd 0x12
80000    = skip running unk syscall
100000  = do gx cmd 0x19 (command unavailable in netemu? Looks different)
200000  = do gx cmd 0x04
400000  = enable gx cmd 0x0E for whole memory range
800000  = run sub sub_F1D78, seems to be much more complicated version of what netemu do here.
1000000  = set 0x3D63 to 1
Need even more work...
== Memory Map ==
=== Netemu ===
Tables at main page taken directly from emulator memory seems to be wrong. I double checked this and values are really there, but ea just don't match to what emulator code do (lpars are most likely correct there). So here it is memory map with addresses that emulator use when want to reach any of mentioned regions.
{| class="wikitable" style="font-size:small;"
|-
! Name !! Start !! End !! Flags !! Notes
|-
| work
|| 0
|| 0x3200000
|| 3
|| separated into work 0x0-0x300000, ro_work 0x300000-0x800000, and rw_work 0x800000-0x32000000.
|-
| menu_heap
|| 0xE000000
|| 0xE400000
|| 3
||
|-
| negmem
|| 0xFFFFFFFFFFFF0000
|| 0
|| 0x10000001
||
|-
| ?
|| 0x30000000
|| 0x30008000
|| 0x30000000
|| vu0
|-
| spu_iop
|| 0x40000000
|| 0x40060000
|| 0xE0000001
||
|-
| spu_spu2
|| 0x40080000
|| 0x400E0000
|| 0xE0000001
||
|-
| spu_vu1
|| 0x40100000
|| 0x40160000
|| 0xE0000001
||
|-
| spu_eedma
|| 0x40180000
|| 0x401E0000
|| 0xE0000001
||
|-
| fe
|| 0x40200000
|| 0x40260000
|| 0xE0000001
||
|-
| be
|| 0x40280000
|| 0x402E0000
|| 0xE0000001
||
|-
| spu_ipu
|| 0x40300000
|| 0x40360000
|| 0xE0000001
||
|-
| be
|| 0x40380000
|| 0x403E0000
|| 0xE0000001
|| not working spu be on spe7
|-
| SPC_SLB
|| 0x50061000
|| 0x50062000
|| 0xF0000000
|| for spu_iop
|-
| 
|| 0x50063000
|| 0x50066000
|| 0xF0000000
||
3000 = SPC_MFC_CNTL
4000 = SPC_PUINT_MB
5000 = SPC_CSR1
|-
| SPC_CSR
|| 0x50062000
|| 0x50063000
|| 0xF0000000
||
|-
| SPC_SLB
|| 0x500E1000
|| 0x500E2000
|| 0xF0000000
|| for spu_spu2
|-
| 
|| 0x500E3000
|| 0x500E6000
|| 0xF0000000
||
3000 = SPC_MFC_CNTL
4000 = SPC_PUINT_MB
5000 = SPC_CSR1
|-
| SPC_CSR
|| 0x500E2000
|| 0x500E3000
|| 0xF0000000
||
|-
| SPC_SLB
|| 0x50161000
|| 0x50162000
|| 0xF0000000
|| for spu_vu1
|-
| 
|| 0x50163000
|| 0x50166000
|| 0xF0000000
||
3000 = SPC_MFC_CNTL
4000 = SPC_PUINT_MB
5000 = SPC_CSR1
|-
| SPC_CSR
|| 0x50162000
|| 0x50163000
|| 0xF0000000
||
|-
| SPC_SLB
|| 0x501E1000
|| 0x501E2000
|| 0xF0000000
|| for spu_eedma
|-
| 
|| 0x501E3000
|| 0x501E6000
|| 0xF0000000
||
3000 = SPC_MFC_CNTL
4000 = SPC_PUINT_MB
5000 = SPC_CSR1
|-
| SPC_CSR
|| 0x501E2000
|| 0x501E3000
|| 0xF0000000
||
|-
| SPC_SLB
|| 0x50261000
|| 0x50262000
|| 0xF0000000
|| for fe
|-
| 
|| 0x50263000
|| 0x50266000
|| 0xF0000000
||
3000 = SPC_MFC_CNTL
4000 = SPC_PUINT_MB
5000 = SPC_CSR1
|-
| SPC_CSR
|| 0x50262000
|| 0x50263000
|| 0xF0000000
||
|-
| SPC_SLB
|| 0x502E1000
|| 0x502E2000
|| 0xF0000000
|| for be
|-
| 
|| 0x502E3000
|| 0x502E6000
|| 0xF0000000
||
3000 = SPC_MFC_CNTL
4000 = SPC_PUINT_MB
5000 = SPC_CSR1
|-
| SPC_CSR
|| 0x502E2000
|| 0x502E3000
|| 0xF0000000
||
|-
| SPC_SLB
|| 0x50361000
|| 0x50362000
|| 0xF0000000
|| for spu_ipu
|-
| 
|| 0x50363000
|| 0x50366000
|| 0xF0000000
||
3000 = SPC_MFC_CNTL
4000 = SPC_PUINT_MB
5000 = SPC_CSR1
|-
| SPC_CSR
|| 0x50362000
|| 0x50363000
|| 0xF0000000
||
|-
| SPC_SLB
|| 0x503E1000
|| 0x503E2000
|| 0xF0000000
|| for unused be on spe7
|-
| 
|| 0x503E3000
|| 0x503E6000
|| 0xF0000000
||
3000 = SPC_MFC_CNTL
4000 = SPC_PUINT_MB
5000 = SPC_CSR1
|-
| SPC_CSR
|| 0x503E2000
|| 0x503E3000
|| 0xF0000000
||
|-
| GSIF
|| 0xA0020000
|| 0xA0028000
|| 0x80000000
|| rsx
|-
| NL
|| 0xA0009000
|| 0xA000A000
|| 0x80000000
|| rsx
|-
| rsx_driver_info
|| 0xA0004000
|| 0xA0007000
|| 0x80000000
|| rsx
|-
| rsx_dma_ctrl
|| 0xA0030000
|| 0xA0050000
|| 0x80000000
|| rsx
|-
| ?
|| 0xA0008000
|| 0xA0009000
|| 0x80000000
|| rsx
|-
| ohci_mmio
|| 0x60000000
|| 0x60001000
|| 0x60000000
||
|-
| ehci_mmio
|| 0x60200000
|| 0x60201000
|| 0x60000000
||
|-
| ohci_mmio
|| 0x60100000
|| 0x60101000
|| 0x60000000
||
|-
| ehci_mmio
|| 0x60300000
|| 0x60301000
|| 0x60000000
||
|-
| base
|| 0x80000000
|| 0x80100000
|| 0x70000003
|| usb
|-
| rawdata
|| 0x80800000
|| 0x80900000
|| 0x70000003
|| usb
|-
| iopdata
|| 0x81000000
|| 0x81100000
|| 0x70000003
|| usb
|-
| base
|| 0x82000000
|| 0x82100000
|| 0x70000003
|| ehci? usb
|-
| ehci_vars
|| 0x82800000
|| 0x82900000
|| 0x70000003
|| usb
|-
| bchs_pmalloc
|| 0x83000000
|| 0x83100000
|| 0x70000003
|| usb
|-
| ?
|| 0x83800000
|| 0x83900000
|| 0x70000003
||
|-
| SB_CDVD
|| 0x84000000
|| 0x84100000
|| 0x70000003
||
|-
| SB_HDD
|| 0x84800000
|| 0x84900000
|| 0x70000003
||
|-
| ?
|| 0x85000000
|| 0x85100000
|| 0x70000003
||
|-
| SB_SIO2
|| 0x85800000
|| 0x85900000
|| 0x70000003
|| only first 0x4000?
|-
| vrc_area
|| 0x90000000
|| 0x91000000
|| 0xC00000003
|| vu1 recompiler area
|-
| ee_cached
|| 0x200000000
|| 0x202000000
|| 0x100000003
||
|-
| ?
|| 0x211004000
|| 0x211008000
|| 0x300000000
|| vu1 memory direct rw
|-
| ee_rom
|| 0x21FC00000
|| 0x220000000
|| 0x300000000
||
|-
| ee_uncached
|| 0x220000000
|| 0x222000000
|| 0x100000003
||
|-
| ee_uncacc
|| 0x230000000
|| 0x232000000
|| 0x100000003
||
|-
| ee_spr_lo
|| 0x260000000
|| 0x260002000
|| 0x700000000
|| weird, that map directly to 0x60000000 ps2 address
|-
| ee_spr_hi
|| 0x270000000
|| 0x270006000
|| 0x800000000
|| ee scratchpad
|-
| ee_kmem0
|| 0x280000000
|| 0x282000000
|| 0x100000003
||
|-
| ?
|| 0x291004000
|| 0x291008000
|| 0x300000000
|| vu1 data rw in kernel mode
|-
| ?
|| 0x29FC00000
|| 0x2A0000000
|| 0x300000000
|| ee_rom in kernel mode
|-
| ?
|| 0x2A0000000
|| 0x2A2000000
|| 0x100000003
|| ee_uncached in kernel mode
|-
| ?
|| 0x2B1004000
|| 0x2B1008000
|| 0x300000000
|| vu1 data in kernel mode. Uncached, i doubt that is even accessible in ps2.
|-
| ?
|| 0x2BFC00000
|| 0x2C0000000
|| 0x300000000
|| ee_rom in uncached kernel mode
|-
| ee_dbg
|| 0x2FFFF8000
|| 0x300000000
|| 0x900000000
||
|-
| iop_mem
|| 0x400000000
|| 0x400200000
|| 0x400000003
||
|-
| iop_rom
|| 0x4BFC00000
|| 0x4C0000000
|| 0x500000001
|| kernel mode
|-
| iop_kmmio0
|| 0x4BF800000
|| 0x4BF810000
|| 0x500000001
|| including iop_spad at first 0x1000
|-
| ?
|| 0x4AFC00000
|| 0x4B0000000
|| 0x500000001
|| iop_rom, uncached?
|-
| iop_kmmio1
|| 0x4AF800000
|| 0x4AF810000
|| 0x500000001
|| including iop_spad at first 0x1000
|-
| spu2_ram
|| 0x600000000
|| 0x600400000
|| 0x600000003
|| starting from 0x200000 spu2_ram2
|-
| ?
|| 0x800000000
|| 0x800010000
|| 0x1000000001
||
|-
| ?
|| 0xC0000000
|| 0xCF800000
|| 0x1600000003
||
|-
| sgs_xdr
|| 0xB4000000
|| 0xB5700000
|| 0x1900000003
||
|-
| ?
|| 0x40000000000
|| 0x40000010000
|| 0x1400000001
||
|-
| ee_jit_code
|| 0x10000000
|| 0x13000000
|| 0xD00000003
||
|-
| vu0_jit_code
|| 0x18000000
|| 0x18400000
|| 0xD00000003
||
|-
| vu0_jit_data
|| 0x1C000000
|| 0x1C400000
|| 0xD00000003
||
|-
| eeram_jit_lut
|| 0x20000000
|| 0x22000000
|| 0xE00000003
||
|-
| eerom_jit_lut
|| 0x2FC00000
|| 0x30000000
|| 0xE00000003
||
|-
| ustack (micro stack)
|| 0xAAA70000000
|| 0xAAA70040000
|| 0x4200000000001
|| Thread KRN0:1 (aka BOOT00)
|-
| ustack (micro stack)
|| 0xAAA70040000
|| 0xAAA70080000
|| 0x4200010000001
|| Thread KRN1:1 (aka BOOT01)
|-
| ustack (micro stack)
|| 0xAAA70080000
|| 0xAAA700C0000
|| 0x42000B0000001
|| VU0 stack (used in EEonBE when VU0 is running)
|-
| ustack (micro stack)
|| 0xAAA700C0000
|| 0xAAA70100000
|| 0x4200030000001
|| Thread SYS
|-
| ustack (micro stack)
|| 0xAAA70100000
|| 0xAAA70140000
|| 0x4200040000001
|| Thread VRC
|-
| ustack (micro stack)
|| 0xAAA70140000
|| 0xAAA70180000
|| 0x4200050000001
|| Thread MECHA
|-
| ustack (micro stack)
|| 0xAAA70180000
|| 0xAAA701C0000
|| 0x4200060000001
|| Thread HDD
|-
| ustack (micro stack)
|| 0xAAA701C0000
|| 0xAAA70200000
|| 0x4200070000001
|| Thread UI
|-
| ustack (micro stack)
|| 0xAAA70200000
|| 0xAAA70280000
|| 0x4200090000001
|| Thread BL2LNK and BL2MAIN
|-
| ustack (micro stack)
|| 0xAAA70280000
|| 0xAAA702C0000
|| 0x42000A0000001
|| Thread USB
|-
| ustack (micro stack)
|| 0xAAA702C0000
|| 0xAAA70300000
|| 0x42000B0000001
|| Thread EEonBE
|-
|}
== Negmem ==
Netemu use memory part called internally negmem. Memory is mapped to 0xFFFFFFFFFFFF0000, but emulator take advantage only of memory from 0xFFFFFFFFFFFF8000 to 0xFFFFFFFFFFFFFFFF. Why? Because that range is loadable with single opcode. How? By "r0" loads/stores (https://www.psdevwiki.com/ps3/Talk:PS2_Emulation#Netemu_load.2Fstore_with_r0_register). With that clever way emulator can access high addresses by setting negative offset for r0 register. This range is used for PS2 registers, DMAC status, next event delta, INTC, and many more. That way emu is able to load value from cached ps2 register in single opcode! Very clever idea!
Negmem memory map.
// Accurate Mul/Div
0xFFFFFFFFFFFF8094 = Storage for accurate mul/div
0xFFFFFFFFFFFF8098 = Storage for accurate mul/div
0xFFFFFFFFFFFF809C = Storage for accurate mul/div
// Cycles
0xFFFFFFFFFFFF8110 = r5900_cycles
// Accurate Add/Sub
0xFFFFFFFFFFFF8138 = Storage for accurate add/sub fs, also for result
0xFFFFFFFFFFFF8140 = Storage for accurate add/sub ft
// Cache checks
0xFFFFFFFFFFFF8180
\
  |- 512 entries. 23 bits for PFN + 2 upper bits for Valid, and LFR flags.
  |- Checks are performed for 2 entries at 1 time.
/
0xFFFFFFFFFFFF897C
// r5900 GPRs
0xFFFFFFFFFFFF8980 = r5900_zero_upper64bits
0xFFFFFFFFFFFF8988 = r5900_zero_lower64bits
0xFFFFFFFFFFFF8990 = r5900_at_reg_upper64
0xFFFFFFFFFFFF8998 = r5900_at_reg_lower64
0xFFFFFFFFFFFF89a0 = r5900_v0_reg_upper64
0xFFFFFFFFFFFF89a8 = r5900_v0_reg_lower64
0xFFFFFFFFFFFF89b0 = r5900_v1_reg_upper64
0xFFFFFFFFFFFF89b8 = r5900_v1_reg_lower64
0xFFFFFFFFFFFF89c0 = r5900_a0_reg_upper64
0xFFFFFFFFFFFF89c8 = r5900_a0_reg_lower64
0xFFFFFFFFFFFF89d0 = r5900_a1_reg_upper64
0xFFFFFFFFFFFF89d8 = r5900_a1_reg_lower64
0xFFFFFFFFFFFF89e0 = r5900_a2_reg_upper64
0xFFFFFFFFFFFF89e8 = r5900_a2_reg_lower64
0xFFFFFFFFFFFF89f0 = r5900_a3_reg_upper64
0xFFFFFFFFFFFF89f8 = r5900_a3_reg_lower64
0xFFFFFFFFFFFF8a00 = r5900_t0_reg_upper64
0xFFFFFFFFFFFF8a08 = r5900_t0_reg_lower64
0xFFFFFFFFFFFF8a10 = r5900_t1_reg_upper64
0xFFFFFFFFFFFF8a18 = r5900_t1_reg_lower64
0xFFFFFFFFFFFF8a20 = r5900_t2_reg_upper64
0xFFFFFFFFFFFF8a28 = r5900_t2_reg_lower64
0xFFFFFFFFFFFF8a30 = r5900_t3_reg_upper64
0xFFFFFFFFFFFF8a38 = r5900_t3_reg_lower64
0xFFFFFFFFFFFF8a40 = r5900_t4_reg_upper64
0xFFFFFFFFFFFF8a48 = r5900_t4_reg_lower64
0xFFFFFFFFFFFF8a50 = r5900_t5_reg_upper64
0xFFFFFFFFFFFF8a58 = r5900_t5_reg_lower64
0xFFFFFFFFFFFF8a60 = r5900_t6_reg_upper64
0xFFFFFFFFFFFF8a68 = r5900_t6_reg_lower64
0xFFFFFFFFFFFF8a70 = r5900_t7_reg_upper64
0xFFFFFFFFFFFF8a78 = r5900_t7_reg_lower64
0xFFFFFFFFFFFF8a80 = r5900_s0_reg_upper64
0xFFFFFFFFFFFF8a88 = r5900_s0_reg_lower64
0xFFFFFFFFFFFF8a90 = r5900_s1_reg_upper64
0xFFFFFFFFFFFF8a98 = r5900_s1_reg_lower64
0xFFFFFFFFFFFF8aa0 = r5900_s2_reg_upper64
0xFFFFFFFFFFFF8aa8 = r5900_s2_reg_lower64
0xFFFFFFFFFFFF8ab0 = r5900_s3_reg_upper64
0xFFFFFFFFFFFF8ab8 = r5900_s3_reg_lower64
0xFFFFFFFFFFFF8ac0 = r5900_s4_reg_upper64
0xFFFFFFFFFFFF8ac8 = r5900_s4_reg_lower64
0xFFFFFFFFFFFF8ad0 = r5900_s5_reg_upper64
0xFFFFFFFFFFFF8ad8 = r5900_s5_reg_lower64
0xFFFFFFFFFFFF8ae0 = r5900_s6_reg_upper64
0xFFFFFFFFFFFF8ae8 = r5900_s6_reg_lower64
0xFFFFFFFFFFFF8af0 = r5900_s7_reg_upper64
0xFFFFFFFFFFFF8af8 = r5900_s7_reg_lower64
0xFFFFFFFFFFFF8b00 = r5900_t8_reg_upper64
0xFFFFFFFFFFFF8b08 = r5900_t8_reg_lower64
0xFFFFFFFFFFFF8b10 = r5900_t9_reg_upper64
0xFFFFFFFFFFFF8b18 = r5900_t9_reg_lower64
0xFFFFFFFFFFFF8b20 = r5900_k0_reg_upper64
0xFFFFFFFFFFFF8b28 = r5900_k0_reg_lower64
0xFFFFFFFFFFFF8b30 = r5900_k1_reg_upper64
0xFFFFFFFFFFFF8b38 = r5900_k1_reg_lower64
0xFFFFFFFFFFFF8b40 = r5900_gp_reg_upper64
0xFFFFFFFFFFFF8b48 = r5900_gp_reg_lower64
0xFFFFFFFFFFFF8b50 = r5900_sp_reg_upper64
0xFFFFFFFFFFFF8b58 = r5900_sp_reg_lower64
0xFFFFFFFFFFFF8b60 = r5900_fp_reg_upper64
0xFFFFFFFFFFFF8b68 = r5900_fp_reg_lower64
0xFFFFFFFFFFFF8b70 = r5900_ra_reg_upper64
0xFFFFFFFFFFFF8b78 = r5900_ra_reg_lower64
// r5900 COP0 Registers
0xFFFFFFFFFFFF8b80 = COP0_Index_REG
0xFFFFFFFFFFFF8b84 = COP0_Random_REG (unused)
0xFFFFFFFFFFFF8b88 = COP0_EntryLo0_REG
0xFFFFFFFFFFFF8b8c = COP0_EntryLo1_REG
0xFFFFFFFFFFFF8b90 = COP0_Context_REG
0xFFFFFFFFFFFF8b94 = COP0_PageMask_REG
0xFFFFFFFFFFFF8b98 = COP0_Wired_REG
0xFFFFFFFFFFFF8b9c = COP0_7_REG
0xFFFFFFFFFFFF8ba0 = COP0_BadVAddr_REG
0xFFFFFFFFFFFF8ba4 = COP0_9_REG
0xFFFFFFFFFFFF8ba8 = COP0_EntryHi_REG
0xFFFFFFFFFFFF8bac = COP0_Compare_REG
0xFFFFFFFFFFFF8bb0 = COP0_Status_REG
0xFFFFFFFFFFFF8bb4 = COP0_Cause_REG
0xFFFFFFFFFFFF8bb8 = COP0_EPC_REG
0xFFFFFFFFFFFF8bbc = COP0_15_REG
0xFFFFFFFFFFFF8bc0 = COP0_PRid_REG
0xFFFFFFFFFFFF8bc4 = COP0_17_REG
0xFFFFFFFFFFFF8bc8 = COP0_18_REG
0xFFFFFFFFFFFF8bcc = COP0_19_REG
0xFFFFFFFFFFFF8bd0 = COP0_20_REG
0xFFFFFFFFFFFF8bd4 = COP0_21_REG
0xFFFFFFFFFFFF8bd8 = COP0_22_REG
0xFFFFFFFFFFFF8bdc = COP0_BadPaddr_REG
0xFFFFFFFFFFFF8be0 = COP0_24_REG
0xFFFFFFFFFFFF8be4 = COP0_Perf_REG
0xFFFFFFFFFFFF8be8 = COP0_26_REG
0xFFFFFFFFFFFF8bec = COP0_27_REG
0xFFFFFFFFFFFF8bf0 = COP0_TagLo_REG
0xFFFFFFFFFFFF8bf4 = COP0_TagHi_REG
0xFFFFFFFFFFFF8bf8 = COP0_ErrorEPC_REG
0xFFFFFFFFFFFF8bfc = COP0_31_REG
// r5900 TLB
0xFFFFFFFFFFFF9110 = r5900_tlb
\
  |- 48 entries
/
0xFFFFFFFFFFFF9400 = r5900_tlb_last
// IPU
0xFFFFFFFFFFFF9770 = IPU_cycles_unk
0xFFFFFFFFFFFF9774 = IPU_FFFF9774
0xFFFFFFFFFFFF9778 = IPU_CTRL
0xFFFFFFFFFFFF9780 = IPU_BP
0xFFFFFFFFFFFF9788 = IPU_TOP
0xFFFFFFFFFFFF9790 = IPU_FFFF9790
// Unk
0xFFFFFFFFFFFF97B0 = 0x20000000000
// Dump regs for debug
0xFFFFFFFFFFFF97C8 = Regs for dump
\
  |- Used in sub_11A640, to dump regs, then notify debugger.
/
0xFFFFFFFFFFFF98E0 = Last reg for dump
// Backup Regs
0xFFFFFFFFFFFF9920
\
|- Another region do backup registers.
|- Used mostly when cmd 0x01 is running, but not only then.
/
0xFFFFFFFFFFFF99A0
// uintc (micro intc)
0xFFFFFFFFFFFFF000 = next event test delta (doubleword)
0xFFFFFFFFFFFFF08x = INTC_STAT      bits
0xFFFFFFFFFFFFF09x = INTC_MASK      bits
0xFFFFFFFFFFFFF0Ax = D_STAT.CIS      bits
0xFFFFFFFFFFFFF0Bx = D_STAT.CIM      bits
0xFFFFFFFFFFFFF0Dx = D_PCR.CPC      bits
0xFFFFFFFFFFFFF0E0 = D_PCR          full
0xFFFFFFFFFFFFF0E4 = INTC_STAT      full
0xFFFFFFFFFFFFF0E8 = INTC_MASK      full
0xFFFFFFFFFFFFF0EC = D_STAT          full
0xFFFFFFFFFFFFF0F0 = D_STAT upper 16 bits
== Shaders available in emulators ==
V for Vertex, F for Fragment, P for Pixel
===Netemu===
FontShader  V
FontShader  F
ImageShader  V
ImageShader  F
GaussShader0 V
GaussShader0 F
GaussShader1 V
GaussShader1 F
ScanShader  V
ScanShader  F
additionally 2 unnamed fragment shaders, 1 vertex shader,
and one "hidden" unaligned vertex shader (at 0x950270).
===Softemu===
GS Base Vertex program              V
GS Base Fragment program            P
Page Translate Out Vertex          V
Page Translate In Vertex            V
Page Translate Out Fragment        F
Page Translate Out Fragment_0      F
Page Translate Out PSMCT16 Fragment F
Page Translate Out PSMCT24 Fragment F
Page Translate Out PSMZ16 Fragment  F
Page Translate In Fragment          F
Page Translate In Fragment_0        F
Page Translate In PSMCT16 Fragment  F
Page Translate In PSMZ24 Fragment  F
Page Translate In PSMZ16 Fragment  F
Block PSMCT4 Translate Frag        F
Block PSMCT8 Translate Frag        F
Block PSMCT16 Translate Frag        F
Block PSMCT24 Translate Frag        F
Block PSMCT32 Translate Frag        F
Block PSMZ24 Translate Frag        F
Texture Block Translate Vertex      V
Notice that GS Base Fragment program is really not fragment shader, but pixel shader.
===Gxemu===
CG_fp_dilate        F
CG_fp_shrink        F
CG_fp_adjweave      F
CG_fp_motionadj    F
CG_fp_undither      F
CG_fp_deinterlace  F  x
CG_fp_weave        F
CG_fp_edgeinterp    F
CG_fp_smooth        F
CG_fp_sharpen      F  x
CG_fp_upscale_smart F  x
CG_fp_upscale      F  x
CG_fp_smart        F  x
CG_fp_mofix        F  x
CG_fp_orientation  F  x
CG_fp_gradient      F  x
CG_vpshader        V  x
CG_interlace        F
CG_fpshader16      F
CG_fpshader        F  x
Plus 2 unnamed shaders, one F, one V.<br>
Shaders with "x" are also available in PS1 emulators, and i sucessfully replaced some of them in ps1 emu on rpcs3 for testing purpose.
===Emu===
Ps2emu have available 14 fragment shaders, and 8 vertex shaders. All of them don't give any hint about name or usage.
== Custom command ideas ==
* '''Disable GS downloads.'''<br>
It is definitely a performance improvement for many titles. In theory, easy to implement (force 0x3 TRXDIR value for every 0x1 write instead). The point is, per-game patches are superior and more robust.<br>
* '''Disable PCRTC blur.'''<br>
PCRTC merge circuits are mostly used for pathetic blurry anti-aliasing. Looks awful on modern TV screens (ToCA 3 is unreadable completely). Blending settings are controlled through the PMODE privileged register. Partially implemented here: [[Talk:PS2_Emulation#Remove_PCRTC_Blur_for_Netemu|Link]]
===Discussion===
GS download config is partially done, need little bit more than TRXDIR patch. But this is something we can patch per-game too. Games do very obvious things to reverse VIF1 FIFO, and also BUSDIR write. From there you can disable whole function that need it. Config will be better of course, but HEN users... Anti Blur is kinda easy to do. Writes to DISPLAY1 can write also to 2 and write to 2 also to 1. So they always match, and config implementation will be rather easy. Most games just offset DX/DY, and never touch those regs again. For games that mess with it, more serious approach is needed. But again HEN users are out of luck if we create command for that. It doesn't help that this can be done by EE patches too. What need to be done is removing offset between DISPLAY1 and DISPLAY2.
*Example for TOCA3 SLUS which use hard coded offset:
004C55F0 00000000
004C55F4 00000000
I'm not saying no, but for now i'm kinda lacking of motivation if not so small HEN user base will be out of luck. But more ideas can help with motivation. :P --[[User:Kozarovv|Kozarovv]] ([[User talk:Kozarovv|talk]]) 22:00, 8 August 2023 (CEST)
== IOP Handling in ps2_emu? (CECHA/CECHB) ==
So, I was reading about how the emulation works here, but I'm not sure how the hardware-based emulation works in the IOP part.
The chart clearly shows that IOP is being 100% emulated via software (Cell) on ps2_gxemu and ps2_netemu, but what about ps2_emu? Is it being emulated using hardware like the EE and GS? Or is it software? I couldn't find any physical chip leading to believe the hardware IOP is there (although the PS2 Bridge has a very similar number model), but I'm aware that some games which have IOP issues on ps2_gxemu and ps2_netemu are not affected in ps2_emu. Also some games that could go online were working fine on ps2_emu, but not so in ps2_gxemu and ps2_netemu.
Is the IOP really fully emulated via software in CECHA/CECHB consoles?
* It's emulated. While other emus use new IOP emulator that is fully running on SPE, ps2_emu use IOP emulator running mostly on PPE core. Emulated IOP ram is mapped to 0x100000000 address of emulator memory, and it's accessible by whole emu. Interpreter is quite simple but handle all needed stuff. IOP hardware registers are mapped in emulator memory and read/write handlers are all PPE functions (that includes DEV9, USB, etc.). IOP Timers run on one of SPE cores, which is interesting solution. SPU2 is running on separate SPE core too. IOP side of SIF communication is done thru "SIF" named SPE program, this program is communicating directly with CXD9208GP hardware. This includes 0x1D0000XX, SIF DMAs, etc. That part is generally not part of IOP per se, I'm just mentioning it for clarity. About compatibility. IOP emus in other PS2 emulators on PS3 were rewritten from scratch, i guess that's why they are less accurate. Plus, fact that with real EE Sony was able to drive most timings inside emu by EE vblk/hblk, which simplifies emulated communication. There is not much to do with accurate IOP when your emulated EE timings are off. --[[User:Kozarovv|Kozarovv]] ([[User talk:Kozarovv|talk]]) 20:19, 24 September 2024 (CEST)
* Thank you very much. all of that is pretty informative and fully answers my questions. The last one I have, does this means then that the software emulation that ps2_emu is doing to the IOP part is more accurate than the one DECKARD does on Slims PS2 right? I tried games like Beyond Good & Evil and it seems to run well without the sounds issues that game has on slims models.
** Yeah, looks like it is. Possibly that wasn't the case back in the release days. PS2 emu has been updated many times since launch in 2006, who knows why... You may want to check this compatibility list: https://en.everybodywiki.com/List_of_PlayStation_2_games_compatible_with_PlayStation_3 It's not that accurate because for example Persona 4 entry is partially bullshit because issue with the bar in the lower left-hand corner just can't exist on real EE. But generally, it will give you some info what doesn't worked back then. Entries like Battle Stadium D.O.N, Naruto Shippuden: Ultimate Ninja 5, Orphen: Scion of Sorcery, Wild Arms 5 or Ibara are really interesting, but I'm not sure if they are correct. Back then people recognized PS3 model by HDD size, You can imagine that it's not most accurate way to do that. :D --[[User:Kozarovv|Kozarovv]] ([[User talk:Kozarovv|talk]]) 08:32, 25 September 2024 (CEST)
***Of course, the HDD size is not the reliable way to identify models, especially when you can just swap the HDD haha. Thanks, you gave me a lot of interesting info, checking the compatibility list I saw a lot of interesting cases, perhaps if one day I'm bored enough I will try the examples of games you gave me, and also try some others. Would be fun if ps2_gxemu could be run on CECHA/B models, I'm aware its not possible, at least not right now (I also tried by swapping them in dev_blind with no success, just a black screen crash, but since it's looking for different hardware on the motherboard this was kind of the expected behavior).
In the end, I guess that games like Ratchet & Clank or Tekken Tag Tournament which runs really slow on ps2_gxemu is because Cell can't keep up with the EE emulation.
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)

Templates used on this page:

Retrieved from "http://www.psdevwiki.com/ps3/Talk:PS2_Emulation"