Difference between revisions of "Talk:PS2 Emulation"

From PS3 Developer wiki
Jump to: navigation, search
m (ps2_netemu command 0x42)
(Shin Sangoku Musou config)
(One intermediate revision by the same user not shown)
Line 1,746: Line 1,746:
Note: This code don't exist in ps2_netemu.
Note: This code don't exist in ps2_netemu.
== Shin Sangoku Musou config ==
This config does something with sceGsSyncPath by storing 0x4 to INTC_STAT before jumping to it (from one of the main function, so only a specific jump to sceGsSyncPath). I am thinking it fixes this: WhECT9RGZ0k (YouTube link)
What could be happening internally for something like this to be fixed? Interrupt delay to avoid an infinite loop or something? The freeze looks similar to something like the Ecole games (Melty Blood) where the game can move slightly after the freeze, or even break out of it entirely (rare).

Revision as of 14:10, 10 August 2022


Game CONFIG commands (notepad and worklog)

All info here related with commands needs to be moved to frontpage at some point

ps2_netemu command 0x1

There are some additional internal patches using CONFIG cmd id 0x01, using subs not available in 0x3B list

condition: 0xBBB5F800, 0x3B949C00, 0x42133A90
  0x18E1F0, sub_4670C (4.70)
  0x348EC8, sub_44338 (4.70)

Function Mapping

ps2_netemu.self contains a table (with entry_length=8 and entry_number=variable) where are listed the function offsets used by config command 0x01

This table is used to assign a funct_id to a funct_offset. The funct_id is given by the position of the entry in the table, so the first entry in the table is funct_id=0x00, second entry is funct_id=0x01 and so on

The purpose of this table is to be able use the same funct_id values in the external CONFIG files for netemu, this way even if the func_offset changes in between versions (internally inside the ps2_netemu.self file structure) the funct_id will be the same. The other ps2 emulator types doesnt have this table (doesnt needs it because doesnt uses external CONFIG files)

  • funct_offset_table location by ps2_netemu versions:
    • Table v1 (the table contains the same data)
      • Firmware:370-374 offset:0x897ED8 length:0x1C8
    • Table v2 (the table contains the same data)
      • Firmware:400-401 offset:0x8970E8 length:0x1C8
    • Table v3 (the table contains the same data)
      • Firmware:410-411 offset:0x8971E8 length:0x1C8
      • Firmware:420-425 offset:0x8972F8 length:0x1C8
    • Table v4
      • Firmwares 4.30 up to 4.76 was not tested (if someone wants to add this info do it here)
    • Table vX (latest)
      • Firmware:478-488 offset:0x8063f8 length:0x1E0

Example from ps2_netemu.self 4.88

Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F

008063F0                          00 00 00 00 00 04 2F 70          ....../p
00806400  00 00 00 00 00 04 30 34 00 00 00 00 00 04 47 C0  ......04......GÀ
00806410  00 00 00 00 00 04 46 E0 00 00 00 00 00 04 33 84  ......Fà......3„
00806420  00 00 00 00 00 04 74 5C 00 00 00 00 00 04 6D 20  ......t\......m 
00806430  00 00 00 00 00 04 7C 1C 00 00 00 00 00 04 31 00  ......|.......1.
00806440  00 00 00 00 00 04 31 D8 00 00 00 00 00 04 34 48  ......1Ø......4H
00806450  00 00 00 00 00 04 35 20 00 00 00 00 00 04 45 E8  ......5 ......Eè
00806460  00 00 00 00 00 04 45 0C 00 00 00 00 00 04 44 30  ......E.......D0
00806470  00 00 00 00 00 04 42 54 00 00 00 00 00 04 41 70  ......BT......Ap
00806480  00 00 00 00 00 04 40 8C 00 00 00 00 00 04 60 FC  ......@Œ......`ü
00806490  00 00 00 00 00 04 35 E4 00 00 00 00 00 04 7F C4  ......5ä.......Ä
008064A0  00 00 00 00 00 04 5A 1C 00 00 00 00 00 04 55 90  ......Z.......U.
008064B0  00 00 00 00 00 04 6A DC 00 00 00 00 00 04 5F A8  ......jÜ......_¨
008064C0  00 00 00 00 00 04 7A 88 00 00 00 00 00 04 5C 6C  ......zˆ......\l
008064D0  00 00 00 00 00 04 54 C0 00 00 00 00 00 04 53 F0  ......TÀ......Sð
008064E0  00 00 00 00 00 04 53 20 00 00 00 00 00 04 52 50  ......S ......RP
008064F0  00 00 00 00 00 04 51 80 00 00 00 00 00 04 50 B0  ......Q€......P°
00806500  00 00 00 00 00 04 4F E0 00 00 00 00 00 04 4F 10  ......Oà......O.
00806510  00 00 00 00 00 04 4E 40 00 00 00 00 00 04 4D 70  ......N@......Mp
00806520  00 00 00 00 00 04 4C A0 00 00 00 00 00 04 4B D0  ......L ......KÐ
00806530  00 00 00 00 00 04 4B 00 00 00 00 00 00 04 4A 30  ......K.......J0
00806540  00 00 00 00 00 04 49 60 00 00 00 00 00 04 48 90  ......I`......H.
00806550  00 00 00 00 00 04 66 2C 00 00 00 00 00 04 71 14  ......f,......q.
00806560  00 00 00 00 00 04 6F 9C 00 00 00 00 00 04 6E 24  ......oœ......n$
00806570  00 00 00 00 00 04 59 2C 00 00 00 00 00 04 58 48  ......Y,......XH
00806580  00 00 00 00 00 04 57 64 00 00 00 00 00 04 56 80  ......Wd......V€
00806590  00 00 00 00 00 04 75 60 00 00 00 00 00 00 00 00  ......u`........
008065A0  00 00 00 00 00 04 62 18 00 00 00 00 00 04 36 B4  ......b.......6´
008065B0  00 00 00 00 00 04 7D 28 00 00 00 00 00 04 72 98  ......}(......r˜
008065C0  00 00 00 00 00 04 76 74 00 00 00 00 00 04 6B D4  ......vt......kÔ
008065D0  00 00 00 00 00 04 3F AC                          ......?¬
netemu 0x01 gxemu 0x00 softemu 0x00
3.70~4.89 3.70~3.74 4.00~4.01 4.10~4.25 4.78~4.88 4.78~4.82 3.72~4.01
funct_id funct_offset funct_offset funct_offset funct_offset funct_offset funct_offset
0x00 0x46720 0x42E00 0x42EB8 0x42F70 0x36B40 0x2FEF0
0x01 0x42DB0 0x42EC4 0x42F7C 0x43034 0x35FB0 0x31E38
0x02 0x44394 0x4456C 0x44560 0x447C0 0x34068 0x30220
0x03 0x442B4 0x4448C 0x44480 0x446E0 0x34144 0x302FC
0x04 0x43100 0x43214 0x432CC 0x43384 0x33F98 ? 0x30150
0x05 0x46A90 0x46DB4 0x47184 0x4745C 0x36CF8 0x31D08
0x06 0x46D64 0x46AE0 0x46934 0x46D20 0x34224 0x303DC
0x07 0x47134 0x47154 0x47524 0x47C1C 0x37850
0x08 0x42E7C 0x42F90 0x43048 0x43100 0x33DFC 0x2FFB4
0x09 0x42F54 0x43068 0x43120 0x431D8 0x36C04 0x31C14
0x0A 0x431C4 0x432D8 0x43390 0x43448 0x36EF0 0x31FCC
0x0B 0x4329C 0x433B0 0x43468 0x43520 0x34354
0x0C 0x441BC 0x44394 0x44388 0x445E8 0x34424 0x30518
0x0D 0x440E0 0x442B8 0x442AC 0x4450C 0x34520
0x0E 0x44004 0x441DC 0x441D0 0x44430 0x345FC 0x306F0
0x0F 0x43E28 0x44000 0x43FF4 0x44254 0x365F0 0x31124
0x10 0x43D44 0x43F1C 0x43F10 0x44170 0x36510 0x31044
0x11 0x43C64 0x43E3C 0x43E30 0x4408C 0x36430 0x30F64
0x12 0x45CD4 0x45EAC 0x46EA0 0x460FC 0x34DD0 0x311F8
0x13 0x469C0 0x43474 0x46864 0x435E4 0x366C4 0x30C28
0x14 0x4777C 0x4779C 0x478CC 0x47FC4 0x34EDC 0x31304
0x15 0x455F0 0x457C8 0x457BC 0x45A1C 0x3795C 0x327B4
0x16 0x45164 0x4533C 0x45330 0x45590 0x3521C 0x31580
0x17 0x468C8 0x469DC 0x4676C 0x46ADC 0x347D0 0x308C4
0x18 0x45B80 0x45D58 0x45D48 0x45FA8 0x35300 0x31664
0x19 0x4706C 0x46FC0 0x4745C 0x47A88 0x36E28 0x31F04
0x1A 0x45844 0x45A1C 0x45A0C 0x45C6C 0x37614 0x325B4
netemu 0x01 gxemu 0x00 softemu 0x00
3.70~4.89 3.70~3.74 4.00~4.01 4.10~4.25 4.78~4.88 4.78~4.82 3.72~4.01
funct_id funct_offset funct_offset funct_offset funct_offset funct_offset funct_offset
0x1B 0x45094 0x4526C 0x45260 0x454C0 0x35434 0x31798
0x1C 0x44FC4 0x4519C 0x45190 0x453F0 0x354F8 0x30A88
0x1D 0x44EF4 0x450CC 0x450C0 0x45320 0x355BC
0x1E 0x44E24 0x44FFC 0x44FF0 0x45250 0x35680
0x1F 0x44D54 0x44F2C 0x44F20 0x45180 0x35744
0x20 0x44C84 0x44E5C 0x44E50 0x450B0 0x35808
0x21 0x44BB4 0x44D8C 0x44D80 0x44FE0 0x358CC
0x22 0x44AE4 0x44CBC 0x44CB0 0x44F10 0x35990
0x23 0x44A14 0x44BEC 0x44BE0 0x44E40 0x35A54
0x24 0x44944 0x44B1C 0x44B10 0x44D70 0x35B18
0x25 0x44874 0x44A4C 0x44A40 0x44CA0 0x35BDC
0x26 0x447A4 0x4497C 0x44970 0x44BD0 0x35CA0
0x27 0x446D4 0x448AC 0x448A0 0x44B00 0x35D64
0x28 0x44604 0x447DC 0x447D0 0x44A30 0x35E28
0x29 0x44534 0x4470C 0x44700 0x44960 0x35EEC
0x2A 0x44464 0x4463C 0x44630 0x44890 0x35158
0x2B 0x467E4 0x463DC 0x46688 0x4662C 0x34994
0x2C 0x465D0 0x464B4 0x46D28 0x47114 0x36FC8
0x2D 0x47384 0x473A4 0x46BB0 0x46F9C 0x3607C
0x2E 0x47234 0x47254 0x46A38 0x46E24
0x2F 0x45500 0x456D8 0x456CC 0x4592C 0x34A70
0x30 0x4541C 0x455F4 0x455E8 0x45848 0x34B48
0x31 0x45338 0x45510 0x45504 0x45764 0x34C20
0x32 0x45254 0x4542C 0x45420 0x45680 0x34CF8
0x33 0x46E74 0x46EB8 0x47288 0x47560 0x37714
0x34 0x00000 0x00000 0x00000 0x00000
0x35 0x45DF0 0x45FC8 0x46274 0x46218
0x36 0x4336C 0x43544 0x43538 0x436B4
0x37 0x474E0 0x47500 0x47630 0x47D28
0x38 0x46BA0 0x46BF0 0x46FC0 0x47298
0x39 No No No 0x47674
0x3A No No No 0x46BD4
0x3B No No No 0x43FAC

Function 0x0D

What is the purpose of this function? Could it be used as a potential fix for the various DMA issues (similar to the EE timing hack in PCSX2)? I may be wrong, but I think the majority of netemu's emulation problems are caused by DMA issues, which are unfortunately hard to fix.

  • This hack allow to run all spe cores while doing nothing on ppe side. Is like giving spe more time (100 msec). This can be used to fix some timing issues here or there. But if you know game offset that you want to use it, you probably can already fix it in different way. Also this probably won't affect "emulation cycles", so is not like pcsx2 EE timing hack. About pcsx2 EE timing hack.. This is really stupid hack if you ask me. Hack make all events listed [here] to take 8 cycles. No matter that really it was 1, or 2000 cycles, it will make all of that 8 cycles. Idea of that hack is not bad itself, but it is terrible implementation that make a lot of things random. I think that ps2 emu on ps4 do this much better, as you can select only one event, and set cycles for it. While on pcsx2 if you want DMAC_FROM_IPU to take 8 cycles, you also make ALL OTHER events to take 8 cycles. I don't know how lucky that hack is to not break other stuff. --Kozarovv (talk) 07:47, 12 March 2022 (UTC)

ps2_netemu command 0x4

Patch SPE 3 program (eedma) by searching for ila r4, xxxxx, starting at 0x178A0 and replacing them with (0x42000004 | ((value << 7) & 0x1FFFF80)
0x42000004 is ila r4 opcode. Due to opcode encoding example result of that patch with value 0x08 will be 0x42000404 (ila r4, 0x08). There is little bit more than that, but main purpose is just to patch SPE program behavior.

  • What are the valid values? The official config from The Suffering uses a 0x8 value, yet the flashing does still happen. Increasing it to 0x20 seems to fix the flashing.--Agrippa (talk) 14:42, 22 February 2022 (UTC)
    • 0x00 - 0x3FFFF. Well you can use higher values, but it will be truncated by mask to something below 0x40000 anyway. Default is 0x12345 if i understand correctly. --Kozarovv (talk) 16:29, 22 February 2022 (UTC)

ps2_netemu command 0x5

The external config format used by ps2_netemu.self doesnt supports command ID 0x5. But this same command with a different ID (0x4) was used by this game configs embedded inside ps2_gxemu.self: Grand Theft Auto: Liberty City Stories (SLES-54135, SLES-54136, SLUS-21423), Grand Theft Auto: Vice City Stories (SLES-54622, SLES-54623, SLUS-21590), Hunter: The Reckoning Wayward (SLES-51823), Onimusha: Dawn of Dreams (SLPM-66275), Shinseiki Evangelion: Ayanami Ikusei Keikaku with Asuka Hokan Keikaku (SLPM-65340), Tekken Tag Tournament (SLUS-20001). The reason why this command is not supported in the external config files is because the related emulator code is enabled permanently in ps2_netemu.self for all games

This command patches EEDMA SPE program during emulator init (0x1F77C in latest netemu) to set different handling for DIRECT/DIRECTHL VIF1 commands. Weird solution, wasn't better to just change pointers in spe program instead of patching that on init?

  • Is there any way to patch the emulator to prevent that command to apply? I wonder if it is affecting the behaviour of some games.--Agrippa (talk) 20:00, 11 March 2022 (UTC)
    • Yeah, you can patch it on decrypted emu.


91 48 00 00 90 09 00 1C 90 09 00 10 90 09 00 14 90 09 00 18 90 0b 00 1C 90 0b 00 10 90 0b 00 14 90 0b 00 18


91 48 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 60 00 00 00 60 00 00 00

And find

E9 42 8C 20 3C 00 00 01 60 00 72 80 E9 2A 00 00


4E 80 00 20 3C 00 00 01 60 00 72 80 E9 2A 00 00

Now you need to encrypt it with scetool, using original emu as a template.

scetool --template orig_ps2_netemu.self --sce-type=SELF --compress-data=TRUE --encrypt ps2_netemu.elf ps2_netemu.self

Remember to delete netemu from flash, then copy new one. Overwriting can fail as there is not enough space on dev_flash. --Kozarovv (talk) 07:35, 12 March 2022 (UTC)

ps2_netemu command 0x0C

These pairs of parameters: 0x0001 and 0x0400; 0x0001 and 0x0800; 0x0001 and 0x0180 fix few missing sound effects in the Klonoa 2. The side effect is slightly longer loading times in general. This game is known for its various audio buffer issues related to the CDVD speed.

  • I actually suspected this can be some delay for reads, but default value is (1, 0x1000) so doesn't really fit for delay. Since Shadowman 2 use it, and have known CD issue. Testing Shadowman2 without config can be interesting, if i'm right there will be a lot of broken textures right after you take control of main character. With broken Shadowman2 it will be easy to know that lower values are "better" or higher values are "better". That should help to understand what's going on. Assuming that SM2 really break without config... --Kozarovv (talk) 19:10, 3 March 2022 (UTC)
    • Tested Shadowman with and without config. No texture corruption either way, but it seems like the config helps with frame rate issues maybe caused by streaming in contents from the disc? Either that or placebo. --Mrjaredbeta (talk) 02:39, 4 March 2022 (UTC)
      • Well that's "unfortunate" because Shadowman2 would be perfect test case here. I noticed that Shadowma2 have hardcoded bios settings "CDVD_READ_DELAY", so maybe is handled there. --Kozarovv (talk) 19:11, 4 March 2022 (UTC)

It seems like this command can further improve FMVs that still have stuttering issues with command 0x21 enabled. The Fear's opening FMVs are heavily improved with command 0x21 set at 1, but there is still some video slowdown and audio stuttering and popping remaining. With the addition of command 0x0C set to 0x1 and 0x400, the slowdown and stutter is completely fixed. I have only tested 0x400 as a value so far.

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.

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.
  • Do the VU0 accuracy flags need any subcommands? Official 0x12 configs for the State of Emergency/Driving Emotion/The Getaway use 0x00021000 0x00000000 flag.--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. --Kozarovv (talk) 05:42, 10 March 2022 (UTC)

type 1

Playground discussion, unsure about clrlslwi r11, r0, 16,3 result

 Syphon Filter The Omega Strain
 298  00 00 00 00 
 29C  00 00 00 00 
 2A0  01 00>02 00< Type1, Count 2
 2A4  31 00 99 18  
 2A8  32 00 B6 18 

 type 1: (Syphon Filter The Omega Strain	)
	*0x48  | ptr to 1st value *0x2A4 (0x15F)
	*0x50  | count of type values

        (0x18990031 >> 0xC) & 0xFFFF0 = 0x18990
        (0x18B60032 >> 0xC) & 0xFFFF0 = 0x18B60

	store value in [0x18990 + ??? ] 
seg017:0000000000198498 next_value:                             # CODE XREF: read_id0x12_type_1+120�j
seg017:0000000000198498                 lwz       r0, 0(r10)    # -> 0x18990031
seg017:000000000019849C                 addi      r8, r8, 1     # counter
seg017:00000000001984A0                 ld        r29, 0(r31)
seg017:00000000001984A4                 addi      r10, r10, 4   # ptr to next value
seg017:00000000001984A8                 rlwinm    r28, r0, 20,12,27 # r28 = (r0 >> 12) & 0xFFFF0 = (0x18990031 >> 12) & 0xFFFF0 = 0x18990
seg017:00000000001984AC                 clrlslwi  r11, r0, 16,3 # r11 = 0x0031 << 3 = 0x188
seg017:00000000001984B0                 add       r26, r28, r29 # r26 = 0x18990 + ??
seg017:00000000001984B4                 stw       r11, 4(r26)   # store 0x62000? or 0x188? in r26
seg017:00000000001984B8                 lwz       r5, 0x50(r31) # count
seg017:00000000001984BC                 cmplw     cr6, r5, r8
seg017:00000000001984C0                 bgt       cr6, next_value

type 2

Fix for interlocking/synchronization EE with VU0 in micro mode. Usually used with games that are m bit sensitive, or loop endlessly on VU0 due to lack of sync with EE core.

298  00 00 00 04 
29C  00 00 00 00  
2A0  02 00>03 00< Type 2, Count 3
2A4  5F 01 00 00 	
2A8  8D BD 6F 2C 	
2AC  67 03 00 00  	
2B0  02 00>03 00< Type 2, Count 3
2B4  6B 01 00 00 	
2B8  31 35 70 E9 	
2BC  72 03 00 00  	
2C0  03 00>02 00< Type 3, Count 2
2C4  60 9B 39 10 
2C8  18 9C 39 10	

type 2:
	*0x20C | counter
	*0x210 | 1st value: 0x15F      -> only gets compared, if passed check 2nd value
	*0x214 | 2nd value: 0x2C6FBD8D -> only gets compared, if passed use *0x218 + *0x21C
	*0x218 | 1 ( = count - 2)
        *0x21C | ptr to 3rd value *0x2AC (0x367)

First value is VU0 microprogram start address, multiply by 8 to get correct offset in VU0 micro mem. That one is confirmed,
and you can check CMSAR0 register status in pcsx2 when EE hit address from type 3 command to make sure. Now some guessing. 
Second value is probably hash of microprogram (from start address to e bit end). 
Third value can be run cycles before program is force stopped, for example to wait on m bit for EE side to catch, or to stop endless
loop that normally should already end if VU0 didn't run ahead of EE.
Fourth and next values if available can be run cycles for next program runs. 
A lot of guessing here. But looking at games that use it, there is high possibility that is correct.
This command is always used with type 3, or 4. This is probably not required, but without notifying EE side type 2 is useless. 

type 3

 Example Primal
	*0x11B4| counter
	*0x11B8| -1 -> 0x399B60? 
	*0x11BC| 0 -> 0x399B60?
	*0x11C0| ptr to *0x2C4 values
	*0x11C4| count (2)

	r11 = r0 & 0xFFFFFFF = 0x10399B60 & 0xFFFFFFF = 0x399B60
	0x10399C18 & 0xFFFFFFF = 0x399C18

	r3 = r31 >> 28 = 0x10399B60 >> 0x1C = 1
	a check if 1,2

type 4

        cmpwi     cr7, r0, 4
        bne       cr7, panic_dword_1967BC
        srwi      r9, r6, 1     # r9 = r6 >> 1 = count >> 1
        addi      r11, r4, 4
        stw       r9, 0x1238(r31) save count>>1
        std       r11, 0x1240(r31) save ptr to table values start

---big handler, different register settings?---

ps2_netemu command 0x22

Weird command. Sets something 1 (CDVD/MECHA), but seems to never use it.

ps2_netemu command 0x29

Something related with read time, maybe seek time. First value is meant to be lower than second value, but this is not requirement. 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))
    a = *(cmd_0x29_val_2);
    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 )
    e = get_timebase_reg();
  while ( e == 0 );

f = e - *(mecha.unk_0x24);
if ( f >= d )
  result = unlock_sc06(0x8000LL);

    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

Any idea what this command is doing? It seems to be directly related to IPU. I thought it only fixed black screen issues on certain games, but it also fixes Mystery Mayhem’s glitching/freezing/stuttering FMVs.

  • This config skip check of another value, which finally make one of functions to never run. This affect "SYS" thread, and value that is checked seems to be related to EE/COP2 recompilers (pure guess by addresses that write there...). Nothing related directly to IPU, that's for sure. But this is part of emu that i have basically untouched, so i can't tell what its really skipped here. Function that is skipped trigger other functions which read cached mips code. So maybe something related to recompiler flushing, or constant propagation. Hard to tell at this point. For sure this is something i want to look more into, but not yet. --Kozarovv (talk) 05:56, 8 July 2022 (UTC)
    • Gotcha. So, I guess it is indirectly affecting the IPU? Or at least something EE/COP2 touches after IPU stuff. The current games that this command fixes are: All Star Baseball 2004 (GX config), Scooby-Doo! Mystery Mayhem (fixes repeating audio and FMV slowdown), Pro Evolution Soccer 6 (PAL v2.00 and NTSC-J only, unneeded in other versions, fixes black screen after opening FMV), and SCORE International Baja 1000 (fixes black screen after career mode FMV). These are all the currently known uses of the command. --Mrjaredbeta (talk) 02:15, 10 July 2022 (UTC)

ps2_netemu command 0x2E

Without this command applied there is a black screen and no sound after the PS2LOGO, but the game (Growlanser Generations) is working in the background. Pressing the "PS" button fixes it. After applying this command (0x172 parameter) everything works correctly.

  • this (like most "mecha" commands) is messing with timing.
lwz       r0, 0x2C(r31)           # cmd_0x2E
cmpwi     cr7, r0, 0
beq       cr7, cdvd_error_1349B4  # skip cdvd error if cmd not 0.

mftb      r9
cmpwi     cr7, r9, 0
beq       cr7, loc_134988        # Loop until timebase is not 0
clrldi    r0, r0, 32
add       r0, r0, r9
li        r9, 5
std       r0, 0x20(r31)          # cmd_0x2E + timebase
stw       r9, 0(r31)
b         end_134844

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.. --Kozarovv (talk) 07:05, 7 March 2022 (UTC)

ps2_netemu command 0x3D

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.

  • 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.--Agrippa (talk) 10:16, 24 April 2022 (UTC)
    • 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 ). 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.--Agrippa (talk) 18:14, 5 May 2022 (UTC)
        • We figured that out 2000 custom configs too late. :D Anyway, thanks for confirming that. --Kozarovv (talk) 17:30, 9 May 2022 (UTC)

ps2_netemu command 0x42

It seems the overlay is written only once during the bootup. As a consequence, it is vulnerable to the DNAS magic which wipes the memory below 0x20100000. That is why the SRS CUSTOM config does work only with the 0x0A command, as the patches are constantly applied every vsync instead. Does anybody know how do the cheat engines survive the attack? It is completely immune to the memory breakpoints in the PCSX2, so I am not able to see any EE code responsible for it.

  • Not sure if pcsx2 can track breakpoint for uncached address, try same address but without 2 at the start. Also to make sure that game really wipe memory under 0x100000, you can use this line in pnach. patch=0,EE,000FFFF0,word,617A6F6B Because patch=0 apply code only one time right when elf entrypoint is recompiled. So if you can't find patched bytes in debugger, this mean it's wiped at some point. Few things to keep in mind. Pcsx2 don't support breakpoints in interpreter, only recompiler (default setting), When pcsx2 can't catch memory read/write breakpoint, usually this mean that bytes are changed by DMA transfer (incl. SIF from IOP). 0x20100000, and 0x00100000 are exactly the same address in all known ps2 emulators. Only exception is when you enable interpreter + EE cache emulation.
    • I am using the physical address generally. And yeah, that is how I tried it - when the "patch=0" is used, the bytes are wiped at the beginning of execution. Probably when the DNAS libraries are loaded. I suspect the cheat engines hook the syscalls instead, so they could survive this one. Lack of breakpoints in interpreter mode is frustrating (I used the debugger a lot in the PSX mode), but I am using the recompiler of course. At least I figured out an ugly workaround - move the hook from 0x00FF000 to 0x10FF000 before the memory wipe and move it back after. The game I am patching (WRC: Rally Evolved) is a nasty bitch. I wrote a button remap hook, but because of the packed executable file, there is no way to use the PS2 Patch Engine. Moreover, the game does fill the RAM with garbage data, as a result the only safe area to install the hook is below the 0x100000.
      • SRS is annoying indeed. I reversed that, and game is clearing that memory from IOP thru SIF DMA. Not sure if that's worth patching (or that my patch not gonna break other stuff). NOP on 0x144EA8 on EE side, plus patch on that address (0x4C4B0) in IOP memory. Here pattern for easy hex edit to iso:
Search for: D8 FF BD 27 21 20 00 00 07 00 05 3C 00 C0 A5 34
Replace to: 08 00 E0 03 00 00 00 00 07 00 05 3C 00 C0 A5 34

And since we are already here. Do you have any way to test if PS3 accept overlays above 0xFFFFF? When i found this command usage i used parser from PS4 which locked anything above 0xFFFFF as invalid overlay address. But now looking at PS3 code i think range is actually whole EE memory.--Kozarovv (talk) 19:49, 9 August 2022 (UTC)

ps2_netemu command 0x46

  • Soul Calibur III does slow down when looking at the sun regardless if the command is used or not.
  • Gran Turismo 4 does not affect its performance at all when looking at the sun.
  • Valkyrie Profile 2 does not improve its performance by enabling this command. Slowdown in Solde's port could be partially fixed by 0x21 command, interestingly enough. Even though the performance is affected likely by the pseudo stencil shadow buffer instead.
    • Yup, this command is minor optimization. I don't expect some good results with it. I just pointed games that use L2H to "wikify" what this command affect. I think that my hacked new command 0x30 where i backported "HWDisableReadbacks" from pcsx2/aethersx2 should give better boost in those games. As L2H is skipped at all then. If you want to perform some tests to know which games use GS Download, i compiled pcsx2 that print GS DOWNLOAD in log everytime that game ask for it ([[1]] you need resources, and other files from pcsx2 1.7 from github releases). Minor optimization, but worth to use when game overuse downloads (VP2, DDS1).
      • Sony was including this command in configs by default for any L2H title, regardless if it gave any performance improvement or not, it seems.--Agrippa (talk) 14:09, 22 May 2022 (UTC)
  • I have a suspicion that this command fixes some freezing issues in Rogue Galaxy. Does it make sense for it to fix issues like that? I am only basing this off the list as I haven’t encountered any issues with the command on the US version, and the Japanese Director’s Cut is based off that version.
    • It does fix the freeze during loading of the Burial Ground level in the NTSC version of the Tak and the Power of JuJu.--Agrippa (talk) 18:56, 22 May 2022 (UTC)

ps2_netemu command 0x4B and 0x4C

0x4B and 0x4C are the only two unknown commands using two params, maybe this commands are intended to reduce the arithmetic accuracy in a range ? (in other words, param1=start_offset, param2=end_offset)

  • But we know what commands 0x4B/0x4C do, both are described on main ps2 emu page. Btw. There is no option to reduce accuracy. With PS2 floating point unit, every PS2 emulator do this by default. :P I don't think that decreasing accuracy can do anything good. Best you can do is skip calculation of i/o/u/d/si/so/su/sd flags, and few checks like divide/sqrt by 0 or negative. But this really alter result to the point where instead of 0x7FFFFFFF (f_max), you end with 0x00000000. --Kozarovv (talk) 06:06, 13 July 2022 (UTC)

ps2_netemu command 0x4D

Ok, i don't get that config. Here is what happen in assembly:

0xD820   ilhu      r19, 0x7FFF
0xD824   lqr       r20, Q_cfg_0x4D   ; 0x3F800000 in wild arms
0xD82C   iohl      r19, 0xFFFF
0xD834   and       r17, r80, r19     ; r17 = Q & 0x7FFFFFFF mask
0xD840   ceqi      r15, r17, 0       ; r15 = r17 (shortcut to move 0 or value if exist to r15)
0xD844   lqr       r10, ST_Q
0xD84C   cwd       r9, 0x30+var_30+8(sp)
0xD850   rotqbyi   r16, r20, 4      ; load mask from config to r16
0xD858   and       r12, r15, r16    ; tempQ & 0x3F800000 (r15 and with mask from cfg 0x3F800000)
0xD860   or        r5, r80, r12     ; or r80(Q) with r12(Q masked with 0x3F800000)
0xD868   shufb     r7, r5, r10, r9  ; Prepare correct write for Q (r5 stored to r10 + 8)
0xD870   stqr      r7, ST_Q         ; write result as Q value in STQ

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?
This config can be quite important because it should help to fix issues like Galerians Ash without dirty static patches. More games affected: [| List]

  • I tested the 0x3F800000 and 0x71500000 values with Galerians Ash and it did not work at all.--Agrippa (talk) 14:15, 8 March 2022 (UTC)

XMB messages related with PS2 Emulation

Edit-copy purple.svg.png
 <Text name="msg_ps_ps2_upconvert">PS/PS2 - Upscaler</Text>
 <Text name="msg_ps_upconvert">PS - Upscaler</Text>
 <Text name="msg_ps_ps2_smoothing">PS/PS2 - Smoothing</Text>
 <Text name="msg_ps_smoothing">PS - Smoothing</Text>
 <Text name="msg_ps_ps2_smoothing_explanation">Reduces the roughness of the displayed image.</Text>
Edit-copy purple.svg.png
 <Text name="msg_error_cannot_play_ps2disc_scee">This title is not currently compatible with the PS3™ system. Please visit faq.eu.playstation.com/bc for a list of PlayStation®2 format software titles that are compatible, and to update the System Software that will enable your PS3™ system to play additional PlayStation®2 format software titles.</Text>
 <Text name="msg_error_cannot_play_ps2disc_scea">This title is not currently compatible with the PS3™ system. If you update your system software the title may become compatible with your system. Please visit http://www.us.playstation.com/Support/CompatibleStatus to check whether a specific PlayStation®2 format software title is compatible with the PS3™ system.</Text>
 <Text name="msg_error_cannot_play_ps2disc_scej">This title is not currently compatible with the PS3™ system. If you update your system software the title may become compatible with your system. Please visit http://www.jp.playstation.com/ps3/status/ to check whether a specific PlayStation®2 format software title is compatible with the PS3™ system.</Text>
 <Text name="msg_error_cannot_play_ps2disc_scek">This title is not currently compatible with the PS3™ system. If you update your system software the title may become compatible with your system. Please visit http://www.playstation.co.kr/info/bc to check whether a specific PlayStation®2 format software title is compatible with the PS3™ system.</Text>
 <Text name="msg_error_cannot_play_ps2disc_sceasia">This title is not currently compatible with the PS3™ system. If you update your system software the title may become compatible with your system. Please visit http://asia.playstation.com/status to check whether a specific PlayStation®2 format software title is compatible with the PS3™ system.</Text>
 <Text name="msg_cannot_run_ps2_fromat_corretly_stop">A problem has occurred. This PlayStation®2 format software was forced to quit.</Text>
Edit-copy purple.svg.png
 <Text name="msg_setting_file_ps2">Settings File (PlayStation®2)</Text>
 <Text name="msg_your_bb_navigator">Your PlayStation®BB Navigator</Text>
 <Text name="msg_system_driver_ps1">System Driver</Text>
 <Text name="msg_system_driver_ps2">System Driver (PlayStation®2)</Text>
 <Text name="msg_error_cannot_play_ps2_format">This model of the PS3™ system is not compatible with PlayStation®2 format software.</Text>

Obsolete experiments

This is kept here for historical purposes, but needs to be rewritten or deleted

Getting Playstation 2 Software Emulator working

Method (on Firmware 3.55, without! Cobra-USB Dongle or Downgrade) for all consoles (fat & slim).

1. Replace following files on your consoles /dev_flash/
   with the ones included in this archive
2. Get into Factory Service Mode (FSM Tool/Dongle)
3. Insert your Original PS2 Game Disc
4. It will run.

Note: Backups wont work. You're getting the compatibility of the 2.60 software emulator with all of its bugs.

Download: p3dwik-ps2compatfiles.rar
Possible compatibility Lists:


http://www.multi...upload.com/QKK7ETPHXZ boot_ps2-src.rar (1.43 KB)
http://www.multi...upload.com/YCZ63Y6TQ5 boot_ps2.pkg (69.17 KB)

any chance of having this package resigned for 4.21 cfw? might be useful to see if it'll boot ps2_netemu.self LPAR.

(can boot ps2lpar, but also petitboot if otheros installed! 50:50 chance)

boot_ps2 4.xx eboots.zip (153 KB)
installing 3.55 pkg and replacing the eboot and editing the sfo should work.

Enable Playstation 2 on non BC's

[Getting Playstation 2 Software Emulator working]

XMB Game Settings non BC/BC,patched

Service Mode in relation to PS2 emulation tests

  • Service mode resets display settings (on default it uses HDMI with composite on MultiAV connector) - this means that users of Component cables can get garbled screen / no display output (in tests below, the primairy screen) unless using composite wiring/screen (in tests below, the secondairy screen).
  • Service Mode also resets user presets like disc autoboot, so it needs to be disabled again if needed.
  • Any made Virtual Memory Cards previously will be removed and you will have no access to them, nor be able to create one.
  • When PS3 is switching to PS2, connection with Sixaxis / Dualshock 3 will be lost (even when using USB wired connection). In some cases easily resyncable by using PS button, but in other cases the leds stay off and the controller cannot be used (until ps2 mode is exited or console rebooted)
  • As a workaround for above wireless controller issue, you can use an USB2PS2 converter and connect an old PS2 / Dualshock2 controller.

tests on 2000 series PS3 Slim


SKU: 2000 series slim (minver 2.70)
Firmware: 3.55 'Rogero 3.4' mmap114+peek/poke but no SS-patches
Memorycards: MC:PS1 in slot1, MC:PS2 in slot2.
Mainscreen: Component+Composite 576i+P/720i+P//1080i
Sec.screen: Composite 576i
48 titles tested (PAL disc on PAL SKU) // Euss
  • Without Factory Service Mode : gives "Incompatible Data" when inserting PS2 disc
  • When enabling 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 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 LV2Patcher or 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: boot_ps2.pkg and Factory Service Mode seem to enable simulare (it tries to boot it) while boot_ps2.pkg gives you more options e.g. using LV2Patcher. 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

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 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)

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 boot_ps2.pkg gives blackscreen lockup, not reacting on PS button, or powerbutton, requiring removing powercord.

considering titles to test

These have no listed issues:

  • Half-Life
  • Hulk
  • Medal of Honor: Frontline

These have minor issues listed (but should still play):

  • Silent Hill 3
  • Second Sight

tests on CECHC04 (partial BC)

on 3.41 or on 3.55 in normal XMB mode (no disc icon in XMB): boot_ps2.pkg gives 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 "The system was not turned off properly" as if it had experienced poweroff and from there booted back to XMB. It then returns to the XMB, but first gives an error screen, mentioning 0x80028F17 occured (PS2 mode error 0x80028F17 "An error occurred during the start operation (80028F17)," PlayStation 2 disc Boot Error, also related to PS1 PSN games.)

on 3.41 or on 3.55 in normal XMB mode (disc icon in XMB): boot_ps2.pkg gives resetting of date/time/displayoutput (no output on mainscreen), but all connection to any bound bluetooth device is lost, even when connected via USB (need PS button reactivation). The game is playable on secondary screen, and exit to XMB with holding PS button goes without 0x80028F17 errors, but does give the "The system was not turned off properly" error.

no disc icon:

  • Medal of Honor: Rising Sun
  • Half-Life

disc icon:

  • Hulk
  • Second Sight
  • Silent Hill 3

Renaming ps2_netemu to ps2_emu

Tested renaming ps2_netemu.self to ps2_emu.self on CECHB01/rogero 4.21 with dev_blind mounting via multiMAN but boots to black screen, no disc activity, but controller shuts off and is synced. No PS button menu or anything.

boot_ps2.pkg boots, no disc activities, then throws up an error depending if the file is resigned for 4.21 or not. (tried both a resigned and the existing version)

PS2 on non BC HW - Tests

Title DiscID Disc Icon ps2_softemu Remarks
Normal FSM 2.50 2.60 2.70
Action Replay MAX SCED54409
PS2CD icon
Battlefield 2 Modern Combat SLES53729
PS2DVD icon
Constantine SLES52872
PS2DVD icon
Demo Disc 3-073-543-11 PBPX95514
PS2DVD icon
EyeToy Play SCES51513
PS2DVD icon
EyeToy Play 2 SCES52748
PS2DVD icon
EyeToy Play 3 SLES53315
PS2DVD icon
Freedom Fighters SLES51467
PS2DVD icon
Ghost in the Shell Standalone Complex SLES53020
PS2DVD icon
GoldenEye Rogue Agent SLES52974
PS2DVD icon
Guerrilla Strike SLES53344
PS2CD icon
Gunfighter 2 Revenge of Jessy James SLES51289
PS2CD icon
Half Life SLES50504
PS2CD icon
HDLoader -
PS2CD icon
International Golf Pro SLES52349
PS2CD icon
Jet Ion GP SLES50544
PS2CD icon
killer7 SLES53366
PS2DVD icon
Kya Dark Lineage SLES51473
PS2DVD icon
London Racer Destruction Madness SLES53654
PS2CD icon
London Racer Police Madness SLES53536
PS2CD icon
Manhunt SLES52023
PS2DVD icon
Max Play - 10 Classic Retro Games -
PS2CD icon
Medal of Honor European Assault SLES53332
PS2DVD icon
Medal of Honor Frontline SLES50684
PS2DVD icon
Medal of Honor Rising Sun SLES51873
PS2DVD icon
Medal of Honor Vanguard SLES54683
PS2DVD icon
Men in Black II Alien Escape SLES50789
PS2DVD icon
Network Access Disc SCES51578
PS2DVD icon
OPM #66 SCED54409
PS2DVD icon
OPM #67 SCED54410
PS2DVD icon
OPM #68 SCED54412
PS2DVD icon
OPM #69 SCED54413
PS2DVD icon
OPM #70 SCED54415
PS2DVD icon
OPM #72 SCED54417
PS2DVD icon
OPM #73 SCED54418
PS2DVD icon
OPM #74 SCED55113
PS2DVD icon
OPM #75 SCED55114
PS2DVD icon
OPM #77 SCED55117
PS2DVD icon
OPM #79 SCED55119
PS2DVD icon
Perfect Ace Pro Tournament Tennis SLES51735
PS2CD icon
Prisoner of War SLES50397
PS2DVD icon
Ratchet & Clank 3 SCES52456
PS2DVD icon
Red Baron SLES53434
PS2CD icon
SAS Anti-terror Force SLES53435
PS2CD icon
Second Sight SLES52670
PS2DVD icon
Seek and Destroy SLES51603
PS2CD icon
Silent Hill 3 SLES51434
PS2DVD icon
Yes No
Socom US Navy SEALs SCES50928
PS2DVD icon
Socom II US Navy SEALs SCES51904
PS2DVD icon
Socom 3 US Navy SEALs SCES53300
PS2DVD icon
Socom US Navy SEALs Combined Assault SCES54477
PS2DVD icon
Swap Magic 3 plus (PAL version 3.6) CD SCED54409 No - No
Swap Magic 3 plus (PAL version 3.6) DVD SCED54409
PS2DVD icon
Yes No
Tenchu Wrath of Heaven SLES50679
PS2DVD icon
Terminator 3 Rise of the Machines SLES52152
PS2DVD icon
The Great Escape SLES51315
PS2DVD icon
The Hulk SLES51508
PS2DVD icon
Yes No
The Matrix Path of Neo SLES53799
PS2DVD icon
The Plan SLES53965
PS2CD icon
Time Crisis 3 SCES51844
PS2DVD icon
Tom Clancy's Ghost Recon SLES51181
PS2DVD icon
Tom Clancy's Rainbow Six 3 SLES52288
PS2DVD icon
Tom Clancy's Splinter Cell SLES51466
PS2DVD icon
Tom Clancy's Splinter Cell Chaos Theory SLES53007
PS2DVD icon
Tom Clancy's Splinter Cell Pandora Tomorrow SLES52149
PS2DVD icon
Trapt SLES53824
PS2DVD icon

Tests on NON-BC CECHP01/NTSC-U (Firmware 2.60/boot_ps2.pkg)

Amplitude - Intro prompts are completely glitched, unresponsive to controller input.
Backyard Football 2007 - Graphical glitches during menu and gameplay. Frame rate is okay.
Boogie - Intro FMV runs very slow, fails to recognize input after the title screen.
MLB 08: The Show - Intro videos run smoothly. Menus load with no issue. Gameplay is extremely slow with graphical glitches. Network configuration utility is completely garbled.

-- Moose

Comparative listings: http://tortuga-cove.com/forums/viewtopic.php?f=57&t=530

Hidden/Inaccessible menu in ps2_emu

Apparently PS2EMU (CECH A/B) have some hidden menu that is able to print IOP configs from bios (XPARAM.ELF), i didn't found way to get there, my only idea is replacing other menu with that one in jump case at 0x5D980 (emu around 4.78). Case 21, and 22 is what seems to be hidden menu. More info about printed data: https://www.psdevwiki.com/ps3/PS2_Emulation#TitleID.2FDiscID_in_ps2_netemu.self

Crazy Taxi check

Emulators ps2_netemu, and ps2_gxemu (maybe others too), after calculating game hash perform compare check to 0x2BD12D81ED. 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. 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.

CDVD Commands


4.75 and up.

Supported CDVD N Commands:

opd_ptr  num   name
0x934AB0 0x00: N_CD_NOP
0x934AB8 0x01: N_CD_RESET
0x934AC0 0x02: N_CD_STANDBY
0x934AC8 0x03: N_CD_STOP
0x934AD0 0x04: N_CD_PAUSE
0x934AD8 0x05: N_CD_SEEK
0x934AE0 0x06: N_CD_READ
0x934AE8 0x07: N_CD_READ_CDDA
0x934AF0 0x08: N_DVD_READ
0x934AF8 0x09: N_CD_GET_TOC
0x934B00 0x0A: N_CMD_A                      panic
0x934B08 0x0B: N_CMD_B                      panic
0x934B10 0x0C: N_CD_READ_KEY
0x934B18 0x0D: N_CMD_D                      panic
any command above 0x0D                      panic

Supported CDVD S Commands:

opd_ptr  num   name
0x934B20 0x00: SCMD_Return_0
0x934B28 0x01: SCMD_GetDiscType             panic
0x934B30 0x02: SCMD_CdReadSubQ              panic
0x934B38 0x03: SCMD_Mecacon_command         (support 0x00, 0x01 ,0x30, 0x45 sub cmds)
0x934B40 0x04: SCMD_0x04                    panic
0x934B48 0x05: SCMD_CdTrayReqState
0x934B50 0x06: SCMD_CdTrayCtrl
0x934B58 0x07: SCMD_0x07                    panic
0x934B60 0x08: SCMD_CdReadRTC
0x934B68 0x09: SCMD_sceCdWriteRTC
0x934B70 0x0A: SCMD_sceCdReadNVM            panic
0x934B78 0x0B: SCMD_sceCdWriteNVM           panic
0x934B80 0x0C: SCMD_0x0C                    panic
0x934B88 0x0D: SCMD_0x0D                    panic
0x934B90 0x0E: SCMD_0x0E                    panic
0x934B98 0x0F: SCMD_sceCdPowerOff
0x934BA0 0x10: SCMD_0x10                    panic
0x934BA8 0x11: SCMD_0x11                    panic
0x934BB0 0x12: SCMD_sceCdReadILinkId        return zeroed iLinkId
0x934BB8 0x13: SCMD_sceCdWriteILinkID       panic
0x934BC0 0x14: SCMD_CdCtrlAudioDigitalOut   panic
0x934BC8 0x15: SCMD_sceCdForbidDVDP
0x934BD0 0x16: SCMD_AutoAdjustCtrl
0x934BD8 0x17: SCMD_CdReadModelNumber       Return SCPH-50000 (SCMD 0x03(0x00) return Mechacon version 3.9 which is wrong for that model..)
0x934BE0 0x18: SCMD_CdWriteModelNumber      panic
0x934BE8 0x19: SCMD_0x19                    panic
0x934BF0 0x1A: SCMD_sceCdBootCertify
0x934BF8 0x1B: SCMD_sceCdCancelPOffRdy
0x934C00 0x1C: SCMD_sceCdBlueLEDCtl
0x934C08 0x1D: SCMD_cdvdman_call116
0x934C10 0x1E: SCMD_sceRemote2Read
0x934C18 0x1F: SCMD_sceRemote2_7
0x934C20 0x20: SCMD_Return_0
0x934C28 0x21: SCMD_Return_0
0x934C30 0x22: SCMD_Return_0
0x934C38 0x23: SCMD_Return_0
0x934C40 0x24: SCMD_Return_0
0x934C48 0x25: SCMD_Return_0
0x934C50 0x26: SCMD_Return_0
0x934C58 0x27: SCMD_Return_0
0x934C60 0x28: SCMD_Return_0
0x934C68 0x29: SCMD_sceCdNoticeGameStart    panic
0x934C70 0x2A: SCMD_Return_0
0x934C78 0x2B: SCMD_Return_0
0x934C80 0x2C: SCMD_Return_0
0x934C88 0x2D: SCMD_Return_0
0x934C90 0x2E: SCMD_Return_0
0x934C98 0x2F: SCMD_Return_0
0x934CA0 0x30: SCMD_Return_0
0x934CA8 0x31: SCMD_Return_0
0x934CB0 0x32: SCMD_Return_0
0x934CB8 0x33: SCMD_Return_0
0x934CC0 0x34: SCMD_Return_0
0x934CC8 0x35: SCMD_Return_0
0x934CD0 0x36: SCMD_Return_0
0x934CD8 0x37: SCMD_Return_0
0x934CE0 0x38: SCMD_Return_0
0x934CE8 0x39: SCMD_Return_0
0x934CF0 0x3A: SCMD_Return_0
0x934CF8 0x3B: SCMD_Return_0
0x934D00 0x3C: SCMD_Return_0
0x934D08 0x3D: SCMD_Return_0
0x934D10 0x3E: SCMD_Return_0
0x934D18 0x3F: SCMD_Return_0
0x934D20 0x40: SCMD_CdOpenConfig
0x934D28 0x41: SCMD_CdReadConfig
0x934D30 0x42: SCMD_CdWriteConfig
0x934D38 0x43: SCMD_CdCloseConfig
0x934D40 0x44: SCMD_Return_0
0x934D48 0x45: SCMD_Return_0
0x934D50 0x46: SCMD_Return_0
0x934D58 0x47: SCMD_Return_0
0x934D60 0x48: SCMD_Return_0
0x934D68 0x49: SCMD_Return_0
0x934D70 0x4A: SCMD_Return_0
0x934D78 0x4B: SCMD_Return_0
0x934D80 0x4C: SCMD_Return_0
0x934D88 0x4D: SCMD_Return_0
0x934D90 0x4E: SCMD_Return_0
0x934D98 0x4F: SCMD_Return_0
0x934DA0 0x50: SCMD_Return_0
0x934DA8 0x51: SCMD_Return_0
0x934DB0 0x52: SCMD_Return_0
0x934DB8 0x53: SCMD_Return_0
0x934DC0 0x54: SCMD_Return_0
0x934DC8 0x55: SCMD_Return_0
0x934DD0 0x56: SCMD_Return_0
0x934DD8 0x57: SCMD_Return_0
0x934DE0 0x58: SCMD_Return_0
0x934DE8 0x59: SCMD_Return_0
0x934DF0 0x5A: SCMD_Return_0
0x934DF8 0x5B: SCMD_Return_0
0x934E00 0x5C: SCMD_Return_0
0x934E08 0x5D: SCMD_Return_0
0x934E10 0x5E: SCMD_Return_0
0x934E18 0x5F: SCMD_Return_0
0x934E20 0x60: SCMD_Return_0 
0x934E28 0x61: SCMD_Return_0
0x934E30 0x62: SCMD_Return_0
0x934E38 0x63: SCMD_Return_0
0x934E40 0x64: SCMD_Return_0
0x934E48 0x65: SCMD_Return_0
0x934E50 0x66: SCMD_Return_0
0x934E58 0x67: SCMD_Return_0
0x934E60 0x68: SCMD_Return_0
0x934E68 0x69: SCMD_Return_0
0x934E70 0x6A: SCMD_Return_0
0x934E78 0x6B: SCMD_Return_0
0x934E80 0x6C: SCMD_Return_0
0x934E88 0x6D: SCMD_Return_0
0x934E90 0x6E: SCMD_Return_0
0x934E98 0x6F: SCMD_Return_0
0x934EA0 0x70: SCMD_Return_0
0x934EA8 0x71: SCMD_Return_0
0x934EB0 0x72: SCMD_Return_0
0x934EB8 0x73: SCMD_Return_0
0x934EC0 0x74: SCMD_Return_0
0x934EC8 0x75: SCMD_Return_0
0x934ED0 0x76: SCMD_Return_0
0x934ED8 0x77: SCMD_Return_0
0x934EE0 0x78: SCMD_Return_0
0x934EE8 0x79: SCMD_Return_0
0x934EF0 0x7A: SCMD_Return_0
0x934EF8 0x7B: SCMD_Return_0
0x934F00 0x7C: SCMD_Return_0
0x934F08 0x7D: SCMD_Return_0
0x934F10 0x7E: SCMD_Return_0
0x934F18 0x7F: SCMD_Return_0
0x934F20 0x80: SCMD__mechacon_auth_0x80
0x934F28 0x81: SCMD__mechacon_auth_0x81
0x934F30 0x82: SCMD__mechacon_auth_0x82
0x934F38 0x83: SCMD__mechacon_auth_0x83
0x934F40 0x84: SCMD__mechacon_auth_0x84
0x934F48 0x85: SCMD__mechacon_auth_0x85
0x934F50 0x86: SCMD__mechacon_auth_0x86
0x934F58 0x87: SCMD__mechacon_auth_0x87
0x934F60 0x88: SCMD__mechacon_auth_0x88
0x934F68 0x89: SCMD_Return_0
0x934F70 0x8A: SCMD_Return_0
0x934F78 0x8B: SCMD_Return_0
0x934F80 0x8C: SCMD_Return_0
0x934F88 0x8D: SCMD_Return_0
0x934F90 0x8E: SCMD_Return_0
0x934F98 0x8F: SCMD__mechacon_auth_0x8F

N commands handling differ a lot from pcsx2, doing that correctly is important for emulation.
Read model number return SCPH-50000 while returned mechacon version is (not existing?) 3.9.
This model should return Dragon mechacon rev, so 5.0 and up. 
Returned ConsoleID is 00 00 00 00 00 00 00 00 00, this can be issue in corner case where game additionally check for non zero result.
Returned iLinkID is 00 00 00 00 00 00 00 00 00, this break Time Crisis 2,3, and one of Armored Core games on pcsx2, surprisingly netemu run them fine.
Every "mechacon_auth" command return zeroed result with different size. Only exception here is 0x81 which return 1.

EE I/O Handlers list


4.75 and up. Mode (1 = read / 2 = write)

mode size PS2_HW_REG handler_opd
1 4 T0_COUNT stru_723218
2 4 T0_COUNT stru_723290
1 4 T0_MODE stru_723308
2 4 T0_MODE stru_7233E0
1 4 T0_COMP stru_7231A0
2 4 T0_COMP stru_723248
1 4 T0_HOLD stru_723110
2 4 T0_HOLD stru_723128
1 4 T1_COUNT stru_7232F0
2 4 T1_COUNT stru_7233B0
1 4 T1_MODE stru_723278
2 4 T1_MODE stru_723260
1 4 T1_COMP stru_723140
2 4 T1_COMP stru_723380
1 4 T1_HOLD stru_7231E8
2 4 T1_HOLD stru_723200
1 4 T2_COUNT stru_7232D8
2 4 T2_COUNT stru_723398
1 4 T2_MODE stru_723338
2 4 T2_MODE stru_723410
1 4 T2_COMP stru_7231D0
2 4 T2_COMP stru_723368
1 4 T3_COUNT stru_7232C0
2 4 T3_COUNT stru_7233C8
1 4 T3_MODE stru_723320
2 4 T3_MODE stru_7233F8
1 4 T3_COMP stru_7231B8
2 4 T3_COMP stru_723350
1 8 IPU_CMD stru_721910
2 8 IPU_CMD stru_7218F8
1 4 IPU_CTRL stru_721970
2 4 IPU_CTRL stru_721958
1 4 IPU_BP stru_721940
1 8 IPU_TOP stru_721928
2 4 GIF_CTRL stru_7220C0
2 4 GIF_MODE stru_7220A8
1 4 GIF_STAT stru_722000
1 4 GIF_TAG0 stru_721EB0
1 4 GIF_TAG1 stru_721FE8
1 4 GIF_TAG2 stru_721FD0
1 4 GIF_TAG3 stru_721FB8
1 4 GIF_CNT stru_721EC8
1 4 GIF_P3CNT stru_721EE0
1 4 GIF_P3TAG stru_721EF8
1 4 VIF0_STAT stru_721820
2 4 VIF0_FBRST stru_721868
1 4 VIF0_ERR stru_7217A8
2 4 VIF0_ERR stru_721598
1 4 VIF0_MARK stru_721790
2 4 VIF0_MARK stru_7215B0
1 4 VIF0_CYCLE stru_721778
1 4 VIF0_MODE stru_721760
1 4 VIF0_NUM stru_721748
1 4 VIF0_MASK stru_721730
1 4 VIF0_CODE stru_721718
1 4 VIF0_ITOPS stru_721700
1 4 VIF0_ITOP stru_7216E8
1 4 VIF0_R0 stru_7216D0
1 4 VIF0_R1 stru_7216B8
1 4 VIF0_R2 stru_7216A0
1 4 VIF0_R3 stru_721688
1 4 VIF0_C0 stru_721670
1 4 VIF0_C1 stru_721658
1 4 VIF0_C2 stru_721640
1 4 VIF0_C3 stru_721628
1 4 VIF1_STAT stru_722960
2 4 VIF1_STAT stru_722618
2 4 VIF1_FBRST stru_722A98
1 4 VIF1_ERR stru_722948
2 4 VIF1_ERR stru_722630
1 4 VIF1_MARK stru_722930
2 4 VIF1_MARK stru_722648
1 4 VIF1_CYCLE stru_722918
1 4 VIF1_MODE stru_722900
1 4 VIF1_NUM stru_7228E8
1 4 VIF1_MASK stru_7228D0
1 4 VIF1_CODE stru_7228B8
1 4 VIF1_ITOPS stru_7228A0
1 4 VIF1_BASE stru_722888
1 4 VIF1_OFST stru_722870
1 4 VIF1_TOPS stru_722858
1 4 VIF1_ITOP stru_722840
1 4 VIF1_TOP stru_722828
1 4 VIF1_R0 stru_722810
1 4 VIF1_R1 stru_7227F8
1 4 VIF1_R2 stru_7227E0
1 4 VIF1_R3 stru_7227C8
1 4 VIF1_C0 stru_7227B0
1 4 VIF1_C1 stru_722798
1 4 VIF1_C2 stru_722780
1 4 VIF1_C3 stru_722768
2 0x10 VIF0_FIFO stru_721850
1 0x10 VIF1_FIFO stru_722678
2 0x10 VIF1_FIFO stru_722AB0
2 0x10 GIF_FIFO stru_722B40
1 0x10 IPU_Out_FIFO stru_7238A8
2 0x10 IPU_In_FIFO stru_723890
1 4 D0_CHCR stru_721610
2 4 D0_CHCR stru_721880
1 4 D0_MADR stru_721508
2 4 D0_MADR stru_721520
1 4 D0_QWC stru_721808
2 4 D0_QWC stru_721538
1 4 D0_TADR stru_7217F0
2 4 D0_TADR stru_721550
1 4 D0_ASR0 stru_7217D8
2 4 D0_ASR0 stru_721568
1 4 D0_ASR1 stru_7217C0
2 4 D0_ASR1 stru_721580
1 4 D1_CHCR stru_722690
2 4 D1_CHCR stru_722A68
1 4 D1_MADR stru_722A50
2 4 D1_MADR stru_722750
1 4 D1_QWC stru_722A38
2 4 D1_QWC stru_722738
1 4 D1_TADR stru_722A20
2 4 D1_TADR stru_722720
1 4 D1_ASR0 stru_722A08
2 4 D1_ASR0 stru_722708
1 4 D1_ASR1 stru_7229F0
2 4 D1_ASR1 stru_7226F0
1 4 D2_CHCR stru_722B28
2 4 D2_CHCR stru_722B58
1 4 D2_MADR stru_7229D8
2 4 D2_MADR stru_722AE0
1 4 D2_QWC stru_7229C0
2 4 D2_QWC stru_722AC8
1 4 D2_TADR stru_7229A8
2 4 D2_TADR stru_722AF8
1 4 D2_ASR0 stru_722990
2 4 D2_ASR0 stru_7226D8
1 4 D2_ASR1 stru_722978
2 4 D2_ASR1 stru_7226C0
1 4 D3_CHCR stru_723740
2 4 D3_CHCR stru_723800
1 4 D3_MADR stru_7237D0
2 4 D3_MADR stru_723878
1 4 D3_QWC stru_7237B8
2 4 D3_QWC stru_723860
1 4 D4_CHCR stru_7237A0
2 4 D4_CHCR stru_7237E8
1 4 D4_MADR stru_723788
2 4 D4_MADR stru_723848
1 4 D4_QWC stru_723770
2 4 D4_QWC stru_723830
1 4 D4_TADR stru_723758
2 4 D4_TADR stru_723818
1 4 D5_CHCR stru_722498
2 4 D5_CHCR stru_7224C8
1 4 D5_MADR stru_722408
2 4 D5_MADR stru_722390
1 4 D5_QWC stru_722468
2 4 D5_QWC stru_7223F0
1 4 D6_CHCR stru_722480
2 4 D6_CHCR stru_7224B0
1 4 D6_MADR stru_722450
2 4 D6_MADR stru_7223D8
1 4 D6_QWC stru_722420
2 4 D6_QWC stru_7223A8
1 4 unk_1000C430 stru_722438
2 4 unk_1000C430 stru_7223C0
1 4 D7_CHCR stru_7235C0
2 4 D7_CHCR stru_723530
1 4 D7_MADR stru_7235A8
2 4 D7_MADR stru_723500
1 4 D7_QWC stru_723590
2 4 D7_QWC stru_723518
1 4 D8_CHCR stru_7222D0
2 4 D8_CHCR stru_7222E8
1 4 D8_MADR stru_7222B8
2 4 D8_MADR stru_722168
1 4 D8_QWC stru_7222A0
2 4 D8_QWC stru_722180
1 4 D8_SADR stru_722288
2 4 D8_SADR stru_722198
1 4 D9_CHCR stru_722270
2 4 D9_CHCR stru_722318
1 4 D9_MADR stru_722258
2 4 D9_MADR stru_7221F8
1 4 D9_QWC stru_722240
2 4 D9_QWC stru_7221B0
1 4 D9_TADR stru_722228
2 4 D9_TADR stru_7221E0
1 4 D9_SADR stru_722210
2 4 D9_SADR stru_7221C8
1 4 D_CTRL stru_721C28
2 4 D_CTRL stru_721C70
1 4 D_STAT stru_724130
2 4 D_STAT stru_7241A8
1 4 D_PCR stru_724100
2 4 D_PCR stru_7240E8
1 4 D_SQWC stru_722138
2 4 D_SQWC stru_722150
1 4 D_RBSR stru_721BF8
2 4 D_RBSR stru_721B68
1 4 D_RBOR stru_721B80
2 4 D_RBOR stru_721B98
1 4 D_STADR stru_721C40
2 4 D_STADR stru_721BB0
1 4 INTC_STAT stru_724148
2 4 INTC_STAT stru_7241C0
1 4 INTC_MASK stru_724118
2 4 INTC_MASK stru_724160
2 4 KPUTCHAR stru_723B30
1 4 MSCOM stru_723578
2 4 MSCOM stru_723548
1 4 SMCOM stru_723560
1 4 MSFLAG stru_723620
2 4 MSFLAG stru_723680
1 4 SMFLAG stru_723608
2 4 SMFLAG stru_723668
1 4 SIF_CR stru_7235F0
2 4 SIF_CR stru_723650
1 4 unk_1000F260 stru_7235D8
2 4 unk_1000F260 stru_723638
1 4 unk_1000F280 stru_723428
2 4 unk_1000F280 stru_723440
1 4 unk_1000F290 stru_723458
1 4 unk_1000F2A0 stru_723470
2 4 unk_1000F2A0 stru_723488
1 4 unk_1000F2B0 stru_7234A0
2 4 unk_1000F2B0 stru_7234B8
1 4 unk_1000F2C0 stru_7234D0
2 4 unk_1000F2C0 stru_7234E8
1 4 D_ENABLER stru_721C10
2 4 D_ENABLEW stru_721C58
1 8 unk_1000F800 stru_7250C0
2 8 unk_1000F800 stru_7250D8
1 8 unk_1000F810 stru_725150
1 0x10 unk_1000F820 stru_7250F0
1 0x10 unk_1000F830 stru_725108
1 4 unk_1000F860 stru_725120
1 4 unk_1000F880 stru_725138
1 4 unk_1000F8B0 stru_725168
2 8 PMODE stru_721E20
2 8 SMODE1 stru_722060
2 8 SMODE2 stru_721F88
2 8 SRFSH stru_721E38
2 8 SYNCH1 stru_721F70
2 8 SYNCH2 stru_721F58
2 8 SYNCV stru_721F40
2 8 DISPFB1 stru_7220F0
2 8 DISPLAY1 stru_722018
2 8 DISPFB2 stru_7220D8
2 8 DISPLAY2 stru_722078
2 8 EXTBUF stru_721E50
2 8 EXTDATA stru_721E68
2 8 EXTWRITE stru_721E80
2 8 BGCOLOR stru_721E98
1 8 GS_CSR stru_722090
2 8 GS_CSR stru_722120
2 8 GS_IMR stru_722108
2 8 BUSDIR stru_721FA0
1 8 SIGLBLID stru_722030
2 8 SIGLBLID stru_722048

1000F800 to 1000F8B0 seems to be some fake regs for testing purposes. Probably not existing on real PS2.

  • 1000F820 return "DrJock TV Quiz P"
  • 1000F830 return "hD bags few lynx"

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.

  • 1F00F880 return hardcoded value of 0x4457, which match emu revision i'm working on. Can be just coincidence.

Random notes about SPE in ps2_netemu


This is unconfirmed by any code reversing for now, but IOP emulator print messages like:

ERROR: Double ICACHE fault

Which suggest that instruction cache is emulated for IOP. Making this (ps2/gx/net) emu only PS2 emulator that support cache emulation for IOP. For now even most ps1 emulators lack of that feature, and none of known PS2 emulators do that (including Pcsx2/Play!/Dobiestation). With this we can safely assume that also load delay slots are handled correctly here. Unrelated, but is hard to believe that someone implemented icache, but not load delay slots. Which again make it only known emu set that support this afaik.


That one is one of most misleading names in whole emulator..
DMA channels are handled in:

  • 0 - VIF0 on PPU only
  • 1 - VIF1 dma, and VIF1 hw reads/writes including fifo write are handled in SPE3 (EEDMA)
  • 2 - GIF dma handled in SPE3 (EEDMA) incl. fifo write, but most HW reads is not handled here
  • 3 - IPUfrom dma, and whole ipu HW r/w is handled by SPE6
  • 4 - IPUto dma, and whole ipu HW r/w is handled by SPE6
  • 5 - SIF0 dma is handled in PPE, and SPE 0 (IOP)
  • 6 - SIF1 dma is handled in PPE, and SPE 0 (IOP)
  • 7 - SIF2 dma is handled in PPE, and SPE 0 (IOP)
  • 8 - SPRfrom 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. Only VU1 code, VU1 data is handled by SPE2 (VU1), and any VU0 r/w is handled by PPU only.
So is more like "Close to GS" DMA handler.

"EEDMA" is also responsible for handling VIF1 commands, including UNPACKs. In SPE memory structure responsible for that is starting at 0x1910 (0x00), and last entry (0x7F command) is at 0x9810. This make 100 bytes per "slot" for command information, like pointers to registers, masks for unpacks, pointers to function responsible for commands handling, etc. (more info about VIF cmds: https://psi-rockin.github.io/ps2tek/#vifcommands)

VU1 emulation on SPE

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.

In latest ps2_netemu function responsible for translating VU1 code into SPE ready code is located at 0x13C69C


IDEC start code detection

IDEC perform compare to 0 while starting to search code, but not check that required bits are even available in stream. Buffer is not refilled when there is more than 0 bits available (function proceed even if there is only 1 bit available). Next compare whole word to 0, which is wrong thing to do. Specially that whole word can be not even available at this point. More over there is no check that at least 8 "0" bits are in stream that way. So start code detection is totally broken. Surprisingly this seems to be handled properly for BDEC.. This probably break Onimusha DoD, and many other random games.

IPU skip mpeg hack

There are some leftovers of SKIP MPEG hack in SPE 6 (IPU), i'm not sure that is still available.

SPE4 and SPE5

And SPE7, because someone there forgot it doesn't work in retail. :P First thing is that emulator do a lot of setup for SPE7, including creating virtual address to access it (0x40380000 - 0x403BFFFF). Only thing that seems to be missing is actually starting that SPE.

SPE4 (FE) have a lot of PS2 GIF related code, GS downloads function in PPE check something there (BUSY? BUSDIR? DL ready? bit), and if that bit is not 1 loop for 1000000 x 4 cycles and check again. That spe is also place where GIF_TAG# can be read, so last processed tag on GIF unit. That was greatest hint to be honest, there is no reason to send it there if is not processed there. This is also where 0x49 and 0x4D config commands go. And surprisingly they are not really related. But fact is they go thru same parser on SPE side. 11, and 12 from those commands are subcommand on SPE side. 11 take no args that's why 0x49 send 11,0,0. 12 take 1 arg, and that's why 0x4D send 12, param, 0.
SPE5 (BE), well i didn't reversed that one too much. But it seems to have relation with "FE", and with RSX. This is only speculation but it seems that FE and BE are FrontEnd and BackEnd for GIF/GS emulation tandem. My first idea was BlendingEngine, but that doesn't seems to be the case. Well those 2 need more work.

SCANMSK on ps2_netemu

Apparently SCANMSK is not really ignored, GIF process it, update, etc. So is rather not implemented in later parts of code (GS emulation), or this is some other bug. I guess this GIF code is shared with ps2_gxemu, so maybe it is really missing processing on software GS emulation in later stages.

0xD34C     hbrr     loc_D38C, Update_7E98
0xD350     lr       r4, r80
0xD354     lqr      r9, SCANMSK_REG
0xD358     il       r3, 0x22 ; GIF_REG_NR
0xD35C     shlqbyi  r5, r80, 4
0xD360     cwd      r6, 0x30+var_30+0xC(sp)
0xD364     andi     r5, r5, 3 ;        New SCANMSK write
0xD368     rotqbyi  r8, r9, 0xC
0xD36C     ceq      r7, r8, r5
0xD370     brnz     r7, return_D390 ;  branch if old SCANMSK == new
0xD374     lqr      r11, SCANMSK_REG
0xD378     lqd      lr, 0x30+link_reg(sp)
0xD37C     ai       sp, sp, 0x30
0xD380     lqd      r80, var_10(sp)
0xD384     shufb    r10, r5, r11, r6
0xD388     stqr     r10, SCANMSK_REG

0xD38C     br       UpdateGS_7E98

PS2 masterlist with ps2 emu hashes

ps2_netemu supported video modes

Both HDTV modes (0x51 1080i and 0x52 720p) crash the emulator. 0x53 576p mode does not, but the image is squished and displaced (looks like the DW is 2560, instead of 1440 and I cannot find any reliable documentation about this mode). Tested by forcing the values in the sceGsResetGraph function.

  • None of released games support 576p, so they probably didn't bothered. Afaik that mode is not really used for anything in PS2, like some leftover after testing, or something. I remember that older PS2 don't support it at all, so maybe it was planned as new feature? Also does forcing 480p work? I remember that 480p patching from Managunz gave similar result to what you described for 0x53 mode. But maybe its just broken feature in Managunz itself, i never tested manual patch. --Kozarovv (talk) 06:15, 29 March 2022 (UTC)
    • Only the 2.20 BOOT ROM versions and PSX DVR BIOSes support that mode. But in the netemu, I think this mode is not compatible with the real PS2 one. It looks like a regular PAL (0x03) mode to me with a progressive support (SMODE2 INT field set to zero sends correctly a full 576 frame, instead of 288 lines with a PAL 0x03). Judging by the GS DISPLAY registers of OPL's 576p setting, the parameters of this mode should be more similar to the 480p mode than 576i on the real hardware.
      You are right, it is actually the same case with the forced 480p through sceGsResetGraph. If you force this mode and leave the NTSC output buffer sizes, you get a horizontally magnified image (because the MAGH bit is switched in the register and the requested DW is bigger (2560) than expected (1440)). It could be related to the PCRTC/DVE emulation (maybe conversion of VCK units to pixels, I do not know how it does look like on the PS2). At least the parameters of 480p mode seems to follow the correct specifications, in contrary to the 576p.
      Anyway, forcing the 480p mode in the netemu is not needed at all (apart from the issue mentioned earlier). Even using the interlaced modes, it does output a progressive frame with the full height front buffer games. With the half height front buffer games, the deinterlacing quality is pretty good in my opinion, as long as the 50/60 fps is maintained.--Agrippa (talk) 18:03, 30 March 2022 (UTC)

Widescreen support

If the game does retrieve the widescreen flag from the GetOSDConfigParam through the scescfGetAspect function, the results are as follows:

  • Upscaler turned off: widescreen flag set by BIOS,
  • Upscaler turned on - Normal setting (keep original aspect ratio): no flag is set,
  • Upscaler turned on - Full screen setting: widescreen flag set by BIOS.

Assuming the PS3 is connected with the HDMI cable and all HD resolutions are ticked in settings. Probably the widescreen support with the upscaler turned off is dependent on the connection and the PS3 resolution settings.

Emu Patches

Skip demo disc check

Sony is blocking every game which id from SYSTEM.CNF starts with S, and 4th character is D (SLED, SCED, etc.). When demo is detected sys_stat is set to error code, and emulator return to XMB. Patches here remove that restriction. Apparently ps2_emu don't have that check, probably because there was no need for it (compatibility reasons i guess).


search for
41 9E 03 50 39 80 00 00 54 00 06 3E 54 69 38 30

replace to 
60 00 00 00 39 80 00 00 54 00 06 3E 54 69 38 30

in 4.75+ emu: 0x13356C  beq  cr7, demo_check  ---> nop


search for
41 9E 04 50 78 E0 FE A2 78 C9 F6 E2 54 C6 30 32

replace to
60 00 00 00 78 E0 FE A2 78 C9 F6 E2 54 C6 30 32

in 4.75+ emu: 0x8EEA0  beq  cr7, demo_check  ---> nop

Extend config table by 50% in ps2_gxemu

Patch increase config slots count from 0x314(788) to 0x49E (1182), so exactly 50% more than before. Patch is dedicated for advanced users, and there is no profit of using it if we don't plan to add any new configs. We are abusing fact that emulator isn't compiled by usual "GameOS" PS3SDK, and pointers are 8 bytes. Also fact that compiler to keep everything aligned is forced to add 4 zeroed bytes after config count.

8 bytes for hash, 8 bytes for pointer, 4 bytes for count, and 4 bytes of align to make data 0x18 sized. Without that PPC64 will throw exception because that data is read in a loop, so next read will be 8 bytes hash from xxxxx4 address. Sony (LV2/emus/guestOS) compiler isn't aware that emulator need really only 4 bytes for pointer, we have unused 4 bytes. Plus 4 bytes at the end used as alignment.


hash      00 00 00 FF FF FF FF FF
pointer   00 00 00 00 FF FF FF FF
cmd count FF FF FF FF
align     00 00 00 00 (previously we thought that is terminator)


hash      00 00 00 FF FF FF FF FF
pointer   FF FF FF FF
cmd count FF FF FF FF

We have reduced size from 0x18 to 0x10 for single title without losing any data, free 1576 bytes to use :) . After that i wrote small dumper that allowed me to edit table in easy way to recreate new table with empty slots. Hardest part behind us, now just patches to respect new table elements size, and we are done.

4.88.2 Evilnat ps2_gxemu.elf offsets:

0x6F938: 38 00 03 14 --> 38 00 04 9E  (increase loop count)
0x6F950: 39 29 00 18 --> 39 29 00 10  (decrease step incrementer)
0x6F968: 79 59 2E A4
         79 5A 1F 24
         7C 1A C8 50
         79 59 26 E4
         60 00 00 00
         7B 20 00 20                  (change way of config data offset calculation)
0x6F978: EB EB 00 08 --> 83 EB 00 08  (load config data pointer as zero extended word, instead of doubleword)
0x6F998: 80 0B 00 10 --> 80 0B 00 0C  (change load offset for config count)
0x6F9DC: 7D 3A C8 50 --> 7B 29 00 20  (change way of config data offset calculation for config with 2 or more cmds)
0x6F9F8: 80 09 00 10 --> 80 09 00 0C  (change load offset for config count)

For now we can add some configs to table, and use rest of new zeroed space to store configs itself. Alternatively we can use whole new space for extended table, and use language strings for configs itself. But that make things "per region" which i don't like. All that without removing or editing any existing config.

Patch need to be applied directly to decrypted elf file, using ppf-o-matic (select all files to see emus in browser), or other tool.
gxemu.elf MD5 before patch


gxemu.elf MD5 after patch


DL: https://www.mediafire.com/file/kpno5mubyy7q9p0/gx_cfg_ext.ppf/file

SPE programs dumper

Script for IDA to dump SPE programs from PS2 emulators, don't work with ps2_emu. Script is basing on SPE program names to find correct offsets. Due to that is will miss any SPE program which name is not listed inside script. Tested with ps2_gxemu/ps2_softemu/ps2_netemu.


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 use the same functions for FPU, and VU math where possible. This mean that for example FPU cvt.s and VU0 (and) COP2 ITOF0 at some point use exactly same function. Probably only for strictly math part, rest is different of course.
  • Most FPU and COP2 opcodes have "accurate math" path inlined into main opcode function, but inaccurate path is different function which is little bit weird, since inaccurate path is what is used 99% of times.
  • VU0 (micro) NOP have function prologue/epilogue , and additional call in assembly. This is pointless, and potentially burn some PPE cycles for nothing. Probably nothing that can be visible to the naked eye, but still worth to note.

stdu      r1, back_chain(r1)
mflr      r4
std       r4, 0x70+arg_10(r1)
bl        .VU0_NOP_    <--------
ld        r0, 0x70+arg_10(r1)
addi      r1, r1, 0x70
mtlr      r0

.VU0_NOP_: <-------

ld        r11, off_74C4C0       # counter_unk_cycles_2EBBC08
ld        r10, off_74C4C8       # counter_old_unk_cycles_2EBBC0C
lwz       r9, counter_unk_cycles_2EBBC08
addi      r0, r9, 1
stw       r9, counter_old_unk_cycles_2EBBC0C
stw       r0, counter_unk_cycles_2EBBC08
  • 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.

RSX workload on the netemu

Looks like there is a way to overclock the RSX core by 50 or 100 MHz through LV1 patches. Will the netemu benefit from it?

  • 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. --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.--Agrippa (talk) 15:24, 29 May 2022 (UTC)

Netemu load/store with r0 register

Emulator access weird addresses which are interpreted as eg. 0xFFFFFFFFFFFF9480, or load/store like std r14, -0x6B80(r0) which translate to std r14, -FFFF9480(r0), and its sign extended by CPU to 64 bit. 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) wasn't aware. From IBM manual:

ld	RT, Disp(RA)

RT	Specifies target general-purpose register where result of operation is stored.
Disp	Specifies a 16-bit signed number that is a multiple of 4. The assembler divides this number by 4 when generating the instruction.
RA	Specifies source general-purpose register for EA calculation.

But according to the same manual:

If GPR RA is not 0, the EA is the sum of the contents of GPR RA and Disp. If GPR RA is 0, then the EA is Disp. 

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. Now if we remember that emu have mapped "negative address", functions like below starting to make sense.

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        r4, -0x6BD0(r0) # load to r4 from address 0xFFFFFFFFFFFF9430, no matter what r0 actually is at the moment.
ld        r5, -0x6BC8(r0)
ld        r6, -0x6BC0(r0)
ld        r7, -0x6BB8(r0)
ld        r8, -0x6BB0(r0)
ld        r9, -0x6BA8(r0)
ld        r10, -0x6BA0(r0)
ld        r11, -0x6B98(r0)
ld        r12, -0x6B90(r0)

ps2_gxemu external bios/rom loading.

Emulator can load external bios file. File need to be 4 bytes aligned, and 4MB or less size. File name need to be rom.bin (lower case), and probably need to have patched out RDRAM module to success RD check. At least that check is patched in current ps2_gxemu.self rom, maybe is not really needed.

To load bios we need to set emulator status flag bit 2 to true. I'm not sure that is already set, because i don't have memory dump, only elf file. In case is not, we can probably just ignore that check by patch. Emulator read file using lv1_read_remote_file with type 1, and path "rom.bin". So it seems to be relative to emulator self file (dev_flash/ps2emu)? All code is there and is valid, so external bios loading is fully implemented. Only two things required to do that is second bit of status flag set to true, and rom.bin file in correct path.

Note: This code don't exist in ps2_netemu.

Shin Sangoku Musou config

This config does something with sceGsSyncPath by storing 0x4 to INTC_STAT before jumping to it (from one of the main function, so only a specific jump to sceGsSyncPath). I am thinking it fixes this: WhECT9RGZ0k (YouTube link)

What could be happening internally for something like this to be fixed? Interrupt delay to avoid an infinite loop or something? The freeze looks similar to something like the Ecole games (Melty Blood) where the game can move slightly after the freeze, or even break out of it entirely (rare).