Talk:PS2 Emulation: Difference between revisions

From PS3 Developer wiki
Jump to navigation Jump to search
 
(23 intermediate revisions by 2 users not shown)
Line 1: Line 1:
==Game CONFIG commands (notepad and worklog)==
==Game CONFIG commands (notepad and worklog)==
All info here related with commands needs to be moved to frontpage at some point
Moved to [[Talk:PS2_Emulation/PS2_Config_Commands]]
==XMB messages related with PS2 Emulation==
{{Boxcode|title=explore_category_sysconf.rco\Text\English.xml|code=<syntaxhighlight lang="xml">
<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>
</syntaxhighlight>}}


===ps2_netemu command 0x1===
{{Boxcode|title=game_ext_plugin.rco\Text\English.xml|code=<syntaxhighlight lang="xml">
There are some additional internal patches using CONFIG cmd id 0x01, using subs not available in 0x3B list
<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>
  condition: 0xBBB5F800, 0x3B949C00, 0x42133A90
<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>
  setting:  
  <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>
  0x18E1F0, sub_4670C (4.70)
  <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>
  0x348EC8, sub_44338 (4.70)
<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>
</syntaxhighlight>}}


====Function Mapping====
{{Boxcode|title=explore_plugin_full.rco\Text\English.xml|code=<syntaxhighlight lang="xml">
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
<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>
</syntaxhighlight>}}


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
==Obsolete experiments==
This is kept here for historical purposes, but needs to be rewritten or deleted


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)
===Getting Playstation 2 Software Emulator working===


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


*funct_offset_table location by ps2_netemu versions:
1. Replace following files on your consoles /dev_flash/
**Table v1 (the table contains the same data)
    with the ones included in this archive
***Firmware:370-374 offset:0x897ED8 length:0x1C8
    p3dwik-ps2compatfiles.rar
**Table v2 (the table contains the same data)
2. Get into Factory Service Mode (FSM Tool/Dongle)
***Firmware:400-401 offset:0x8970E8 length:0x1C8
3. Insert your Original PS2 Game Disc
**Table v3 (the table contains the same data)
4. It will run.
***Firmware:410-411 offset:0x8971E8 length:0x1C8
 
***Firmware:420-425 offset:0x8972F8 length:0x1C8
Note: Backups wont work. You're getting the compatibility of the 2.60 software emulator with all of its bugs.
**Table v4
 
***Firmwares 4.30 up to 4.76 was not tested (if someone wants to add this info do it here)
Download: [http://www.sendspace.com/file/bm9z9v p3dwik-ps2compatfiles.rar]<br>
**Table vX (latest)
Possible compatibility Lists:
***Firmware:478-488 offset:0x8063f8 length:0x1E0
* http://tortuga-cove.com/forums/viewtopic.php?f=57&t=530
 
* [[Talk:Emulation#PS2.2FPStwo]]
Example from ps2_netemu.self 4.88
<pre>
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  [email protected]
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                          ......?¬
</pre>


{| class="wikitable" style="float:left; font-size:xx-small; line-height:100%; margin:5px"
====boot_ps2====
! colspan="5" | netemu 0x01 !! gxemu 0x00 !! softemu 0x00
http://foxbrew.org/ps3/otheros-utils/boot_ps2.git <br />
|-
http://www.multi...upload.com/QKK7ETPHXZ boot_ps2-src.rar (1.43 KB) <br />
! [[3.70_CEX|3.70]]~{{latestPS3}} !! [[3.70_CEX|3.70]]~[[3.74_CEX|3.74]] !! [[4.00_CEX|4.00]]~[[4.01_CEX|4.01]] !! [[4.10_CEX|4.10]]~[[4.25_CEX|4.25]] !! [[4.78_CEX|4.78]]~[[4.88_CEX|4.88]] !! [[4.78_CEX|4.78]]~[[4.82_CEX|4.82]] !! [[3.72_CEX|3.72]]~[[4.01_CEX|4.01]]
http://www.multi...upload.com/YCZ63Y6TQ5 boot_ps2.pkg (69.17 KB) <br />
|-
 
! funct_id !! funct_offset !! funct_offset !! funct_offset !! funct_offset !! funct_offset !! funct_offset
any chance of having this package resigned for 4.21 cfw? might be useful to see if it'll boot ps2_netemu.self LPAR.
|-
 
| 0x00 || 0x46720 || 0x42E00 || 0x42EB8 || 0x42F70 || 0x36B40 || 0x2FEF0
(can boot ps2lpar, but also petitboot if otheros installed! 50:50 chance)
|-
 
| 0x01 || 0x42DB0 || 0x42EC4 || 0x42F7C || 0x43034 || 0x35FB0 || 0x31E38
[http://rghost.net/42586725 boot_ps2 4.xx eboots.zip (153 KB)] <br /> installing 3.55 pkg and replacing the eboot and editing the sfo should work.
|-
 
| 0x02 || 0x44394 || 0x4456C || 0x44560 || 0x447C0 || 0x34068 || 0x30220
=== Enable Playstation 2 on non BC's===
|-
 
| 0x03 || 0x442B4 || 0x4448C || 0x44480 || 0x446E0 || 0x34144 || 0x302FC
[[http://www.ps3devwiki.com/index.php?title=Emulation#Getting_Playstation_2_Software_Emulator_working Getting Playstation 2 Software Emulator working]]
|-
 
| 0x04 || 0x43100 || 0x43214 || 0x432CC || 0x43384 || 0x33F98 ? || 0x30150
[[Image:Vsh_ps2_change1.png|left|thumb|400px|XMB Game Settings non BC/BC,patched]]<br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br>
|-
 
| 0x05 || 0x46A90 || 0x46DB4 || 0x47184 || 0x4745C || 0x36CF8 || 0x31D08
==== 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).
| 0x06 || 0x46D64 || 0x46AE0 || 0x46934 || 0x46D20 || 0x34224 || 0x303DC
|-
| 0x07 || 0x47134 || 0x47154 || 0x47524 || 0x47C1C || 0x37850 ||
|-
| 0x08 || 0x42E7C || 0x42F90 || 0x43048 || 0x43100 || 0x33DFC<!--0x33E00 ? (old)--> || 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<!--0x366C4 ? (old)--> || 0x311F8<!--0x30C28 ? (old)-->
|-
| 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<!--0x373FC ? (old)--> || 0x31664
|-
| 0x19 || 0x4706C || 0x46FC0 || 0x4745C || 0x47A88 || 0x36E28 || 0x31F04
|-
| 0x1A || 0x45844 || 0x45A1C || 0x45A0C || 0x45C6C || 0x37614 || 0x325B4
|}


{| class="wikitable" style="float:left; font-size:xx-small; line-height:100%; margin:5px"
* Service Mode also resets user presets like disc autoboot, so it needs to be disabled again if needed.
! colspan="5" | netemu 0x01 !! gxemu 0x00 !! softemu 0x00
|-
! [[3.70_CEX|3.70]]~{{latestPS3}} !! [[3.70_CEX|3.70]]~[[3.74_CEX|3.74]] !! [[4.00_CEX|4.00]]~[[4.01_CEX|4.01]] !! [[4.10_CEX|4.10]]~[[4.25_CEX|4.25]] !! [[4.78_CEX|4.78]]~[[4.88_CEX|4.88]] !! [[4.78_CEX|4.78]]~[[4.82_CEX|4.82]] !! [[3.72_CEX|3.72]]~[[4.01_CEX|4.01]]
|-
! funct_id !! funct_offset !! funct_offset !! funct_offset !! funct_offset !! funct_offset !! funct_offset
|-{{cellcolors|#ddddff}}
| 0x1B || 0x45094 || 0x4526C || 0x45260 || 0x454C0 || 0x35434 || 0x31798
|-{{cellcolors|#ddddff}}
| 0x1C || 0x44FC4 || 0x4519C || 0x45190 || 0x453F0 || 0x354F8 || 0x30A88
|-{{cellcolors|#bbbbff}}
| 0x1D || 0x44EF4 || 0x450CC || 0x450C0 || 0x45320 || 0x355BC ||
|-{{cellcolors|#bbbbff}}
| 0x1E || 0x44E24 || 0x44FFC || 0x44FF0 || 0x45250 || 0x35680 ||
|-{{cellcolors|#ddddff}}
| 0x1F || 0x44D54 || 0x44F2C || 0x44F20 || 0x45180 || 0x35744 ||
|-{{cellcolors|#ddddff}}
| 0x20 || 0x44C84 || 0x44E5C || 0x44E50 || 0x450B0 || 0x35808 ||
|-{{cellcolors|#bbbbff}}
| 0x21 || 0x44BB4 || 0x44D8C || 0x44D80 || 0x44FE0 || 0x358CC ||
|-{{cellcolors|#bbbbff}}
| 0x22 || 0x44AE4 || 0x44CBC || 0x44CB0 || 0x44F10 || 0x35990 ||
|-{{cellcolors|#ddddff}}
| 0x23 || 0x44A14 || 0x44BEC || 0x44BE0 || 0x44E40 || 0x35A54 ||
|-{{cellcolors|#ddddff}}
| 0x24 || 0x44944 || 0x44B1C || 0x44B10 || 0x44D70 || 0x35B18 ||
|-{{cellcolors|#bbbbff}}
| 0x25 || 0x44874 || 0x44A4C || 0x44A40 || 0x44CA0 || 0x35BDC ||
|-{{cellcolors|#bbbbff}}
| 0x26 || 0x447A4 || 0x4497C || 0x44970 || 0x44BD0 || 0x35CA0 ||
|-{{cellcolors|#ddddff}}
| 0x27 || 0x446D4 || 0x448AC || 0x448A0 || 0x44B00 || 0x35D64 ||
|-{{cellcolors|#ddddff}}
| 0x28 || 0x44604 || 0x447DC || 0x447D0 || 0x44A30 || 0x35E28 ||
|-{{cellcolors|#bbbbff}}
| 0x29 || 0x44534 || 0x4470C || 0x44700 || 0x44960 || 0x35EEC ||
|-{{cellcolors|#bbbbff}}
| 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 || {{cellcolors|#CC5555}} 0x00000 || {{cellcolors|#CC5555}} 0x00000 || {{cellcolors|#CC5555}} 0x00000 || {{cellcolors|#CC5555}} 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 ||  ||
|}{{clear}}


====Function 0x0D====
* Any made Virtual Memory Cards previously will be removed and you will have no access to them, nor be able to create one.
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 [[https://github.com/PCSX2/pcsx2/blob/5bdec2f532e94065655032eb6cf7f7715c075e3b/pcsx2/R5900.h#L403 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. --[[User:Kozarovv|Kozarovv]] ([[User talk:Kozarovv|talk]]) 07:47, 12 March 2022 (UTC)


====Function 0x12====
* 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)
The 0x4FC500 EE memory offset is not hardcoded, isn't it? Since this hook fixes other Traveller's Tales games, like Wrath of Cortex, the memory offset should be taken from the opcode itself (if I remember correctly, it is "load word from global pointer").--[[User:Agrippa|Agrippa]] ([[User talk:Agrippa|talk]]) 11:48, 2 October 2022 (UTC)
*Fun(?)fact, it is hardcoded.
oris r0, r0, 0x204F
ori r0, r0, 0xC500.
But i think i know what happen. hook land here (on finding nemo):
lw          $s0, dword_4FC500
bnez        $s0, loc_187568
Notice that config beside 0x4FC500, set $s0 to zero. And here is another fun fact. At least on Nemo this is only place that read from that address. Making patch to 4FC500 meaningless, and not really needed. Assuming that other game doesn't use that exact address, this config is just additionally corrupting some random thing at 0x4FC500. I think that is probably the case also for other Nemo games. To be honest that config can be replaced to just nop that branch there and should do exactly the same thing. ¯\_(ツ)_/¯ --[[User:Kozarovv|Kozarovv]] ([[User talk:Kozarovv|talk]]) 12:23, 2 October 2022 (UTC)
** Hmm, or not exactly the same thing as it also check that COP0 and DMAC stuff. Anyway, i think that patch to EE address do nothing there.
*** NET config for Finding Nemo (SLES-51755) seems to have a 0x42 replacement for 0x01 hook, including the COP0 and D_STAT checks you have mentioned.--[[User:Agrippa|Agrippa]] ([[User talk:Agrippa|talk]]) 13:33, 2 October 2022 (UTC)


====Function 0x35====
* As a workaround for above wireless controller issue, you can use an USB2PS2 converter and connect an old PS2 / Dualshock2 controller.
''Ninkyouden: Toseinin Ichidaiki'' (SLPM-66274) is using command 0x1 with function 0x35 at 0x13ED94...it seems like its executed at the VSync function of the game. This hook is also not in gxemu judging from the table above. No immediate change with or without the command that I can tell. Any idea on what this is doing?
* Function check some bits in GIF, but i don't know what exactly (offset 0x300/0x310 in fe SPU). When bits are 0 command end. When bits are not 0, PPU side of PS3 sleeps 256 cycles, and then check again fe SPU. That loop won't ends unless bits are 0. Just small tip about hooks that are close to VSync. This is not always related to VSync per se. Of course can be, but don't really need to. I mean, if you want to run hook in predictable place, and with similar time steps. VSync is where you hook game code then. --[[User:Kozarovv|Kozarovv]] ([[User talk:Kozarovv|talk]]) 05:31, 22 August 2022 (UTC)
** Yes, I first thought it would be VSync related, but I figured it could be something executed at every VSync like you said. Thanks for checking in on this hook. I am thinking of testing games like Tenchu: Wrath of Heaven and Street Fighter EX3 with this hook to see if anything changes (at least Tenchu's issue is directly related to GIF, SFEX3 not too sure). --[[User:Mrjaredbeta|Mrjaredbeta]] ([[User talk:Mrjaredbeta|talk]]) 00:54, 23 August 2022 (UTC)


===ps2_netemu command 0x5===
==== tests on 2000 series PS3 Slim ====
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
Testplatform:
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) // [[User:Euss|Euss]]


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?
* Without Factory Service Mode : gives "Incompatible Data" when inserting PS2 disc
* 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.--[[User:Agrippa|Agrippa]] ([[User talk:Agrippa|talk]]) 20:00, 11 March 2022 (UTC)
** Yeah, you can patch it on decrypted emu.
Find
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
Replace
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
* 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)
E9 42 8C 20 3C 00 00 01 60 00 72 80 E9 2A 00 00
replace
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.  
* 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)
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. --[[User:Kozarovv|Kozarovv]] ([[User talk:Kozarovv|talk]]) 07:35, 12 March 2022 (UTC)


===ps2_netemu command 0x0B===
* 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).


SRS:Street Racing Syndicate - sector to patch: 3021/1392496 (1.03) or 1402736 (2.00), offset correction: no, PCSX2 log:
* 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).
CDRead: Reading Sector 0003021 (008 Blocks of Size 2048) at Speed=4x(CAV) Spindle=83
WRC: Rally Evolved - sector to patch: 3235/1792256 (1.01), offset correction: no, PCSX2 log:
CDRead: Reading Sector 0003235 (008 Blocks of Size 2048) at Speed=4x(CAV) Spindle=83
Notice the CDRead command instead of DvdRead.
* Not sure this is the case here. But PCSX2 have bug in fastboot, where it always fallback to CDRead for few first reads. To confirm you can launch game with fastboot disabled, pcsx2 now should read those sectors with proper mode. At the second hand.. Maybe that's what happen on PS3? Probably no, as far as i know netemu bios perform something similar to fullboot. But maybe, sony can break unbreakable, and this actually seems to be reasonable explanation. --[[User:Kozarovv|Kozarovv]] ([[User talk:Kozarovv|talk]]) 05:18, 22 August 2022 (UTC)
** That is how it does look like on the newest PCSX2 build at the moment of posting it. It does use a CDRead for few reads after loading an ELF file, even in the full boot mode. --[[User:Agrippa|Agrippa]] ([[User talk:Agrippa|talk]]) 17:27, 22 August 2022 (UTC)
Emulator does panic itself, when two separate 0x0B commands are used.--[[User:Agrippa|Agrippa]] ([[User talk:Agrippa|talk]]) 20:25, 15 November 2022 (UTC)


===ps2_netemu command 0x0C===
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].
Perhaps hardswapping out all the dev_flash ps2 emu files for the same software only emulator would circumvent the 'incompatible title' message.


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... --[[User:Kozarovv|Kozarovv]] ([[User talk: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. --[[User:Mrjaredbeta|Mrjaredbeta]] ([[User talk: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. --[[User:Kozarovv|Kozarovv]] ([[User talk: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.
==== 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".


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.
==== 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.


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)
===== considering titles to test =====
** 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)
* http://en.wikipedia.org/wiki/List_of_PlayStation_3_backward_compatible_PlayStation_2_and_PlayStation_games
 
* http://tortuga-cove.com/forums/viewtopic.php?f=57&t=530
===ps2_netemu command 0x12===
* http://us.playstation.com/support/compatiblestatus/index.htm


====type 1====
These have no listed issues:
Playground discussion, unsure about clrlslwi  r11, r0, 16,3 result
* Half-Life
* Hulk
* Medal of Honor: Frontline
These have minor issues listed (but should still play):
* Silent Hill 3
* Second Sight


<pre>
==== tests on CECHC04 (partial BC) ====
Syphon Filter The Omega Strain
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.'')
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


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.


type 1: (Syphon Filter The Omega Strain )
no disc icon:
*0x48  | ptr to 1st value *0x2A4 (0x15F)
* Medal of Honor: Rising Sun
*0x50  | count of type values
* Half-Life


        (0x18990031 >> 0xC) & 0xFFFF0 = 0x18990
disc icon:
        (0x18B60032 >> 0xC) & 0xFFFF0 = 0x18B60
* Hulk
* Second Sight
* Silent Hill 3


store value in [0x18990 + ??? ]
==== Renaming ps2_netemu to ps2_emu ====
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
</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====
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.


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


<pre>
Primal
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
2CC


type 2:
==== PS2 on non BC HW - Tests ====
*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,
{| class="wikitable sortable"
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).
! rowspan="2" | Title !! rowspan="2" | DiscID !! colspan="2" | Disc Icon !! colspan="3" | ps2_softemu !! rowspan="2" | Remarks
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.
! <abbr title="Normal Mode">Normal</abbr> !! <abbr title="Factory Service Mode">FSM</abbr> !! 2.50 !! 2.60 !! 2.70
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.
</pre>
 
====type 3====
 
<pre>
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
</pre>
 
====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
 
One correct entry is 2x 32 bit. First 32 bits are EE Opcode in little endian, second 32 bits are the same as first 4 bits of type 3 (interlocking). This type of config work in conjunction with type 2 config, and was required because R&C series use EE memory overlays. So type 3 config can't be used here as EE offset change per game level.
 
Here is alternative config for Rayman 3 (SLUS_206.01), this time using type 4 instead of 3. Just to confirm above is true. Untested, because i have no ability to do that.
<pre>
12 00 00 00 0C 00 00 00 00 00 00 04 00 00 00 00
02 00 04 00 00 00 00 00 AE B3 4E 5D 20 02 00 00
46 02 00 00 04 00 04 00 00 30 D3 48 01 00 00 00
00 30 C8 48 01 00 00 00
</pre>
 
===ps2_netemu command 0x17===
This command is used only in Bully which is only known game by R* Vancouver, there is a chance that is only game which need it. But just in case, what game do is MTC0 $zero, Count <br>
And read that at some point. Since we are in recompiler, count is updated only on events. This can create situation where game retrieve 0 value from count reg. Which according to pcsx2 source is wrong ([[https://github.com/PCSX2/pcsx2/blob/b3590430c97e8df170df0c00ebf466ce848edbf9/pcsx2/COP0.cpp#L56 | referred as TIMR]]). To be honest I'm not 100% sure that is issue here. Only other problem i can imagine is potential divide by 0 in emu itself. Anyway, if game do MTC0 zero, Count (00 48 80 40), or any weird operations with Count. This config should be tested.
 
===ps2_netemu command 0x21===
Well, i don't know where to start.. This command with param 0 or 1 at some point prevent writes to TagLo register. Not with MTC0 tho, but during different opcode that is handled separately. I got this unresolved yet, but it seems that is CACHE opcode. That potentially mean ps2_netemu support some parts of instruction cache. But this need to be tested on real hardware. Good candidate here is WRC4. When command 0x21 with 0 or 1 is added to standard config, game should fail to load at all (unless game getting lucky like described in emu bugs section).
*I assume the cache handling would be the cause for games panicking/shutting down when 0x21 is set at 0? I cannot remember correctly if WRC panics (Agrippa would know better), but games like Shadow Hearts 2/3 will shut down after loading a save when instructions are being loaded in the EE memory from outside the main executable. My mind is blanking on other games besides those two, but surely a handful of games I have tested have had shutdowns caused by this command.--[[User:Mrjaredbeta|Mrjaredbeta]] ([[User talk:Mrjaredbeta|talk]]) 20:13, 1 October 2022 (UTC)
** Yes, since that command disable cache handling only partially. There could be some unexpected issues. Problem is that 0x21 do little bit more, and little bit weird. Not gonna lie, cache is new territory for me since i never worked with any emu that support it. PCSX2 support good chunk of cache, but only in interpreter mode, and usually i just patched games to not rely on cache. This is what i got for now.
*** If my memory serves me right:
**** WRC4 - panic at the loading of stages (0x21-0)
**** VP2 - panic at the switching to the battle mode (0x21-0) or player models fail to load in the battle mode (0x21-1)
**** MGS3 - frame rate improvement, at the expense of awfully longer loading times (0x21-0).--[[User:Agrippa|Agrippa]] ([[User talk:Agrippa|talk]]) 11:40, 2 October 2022 (UTC)
**Since it’s worth mentioning, 0x21 set to 0 also fixes the camera angle issue in Radiata Stories after one or two battle sequences.--[[User:Mrjaredbeta|Mrjaredbeta]] ([[User talk:Mrjaredbeta|talk]]) 15:02, 2 October 2022 (UTC)
***I think the issue is not related to the camera at all. It looks similar to the VP2 case I posted earlier - the models fail to load on the post battle screen (shadows are drawn, though). Moreover, various models do disappear for a second in the battle mode too, if I remember correctly. Just a guess, as both games share the same engine.--[[User:Agrippa|Agrippa]] ([[User talk:Agrippa|talk]]) 18:22, 4 October 2022 (UTC)
I messed little bit with this code today, and 0x21_1, plus 0x03 at the same time seems to be most aggressive combo to remove instruction cache emulation. Not sure about compatibility, but this two configs together skip most cache code in emulator. --[[User:Kozarovv|Kozarovv]] ([[User talk:Kozarovv|talk]]) 10:21, 21 October 2022 (UTC)
*Quick test with this, random game (ATV Offroad Fury 4). It seems like 0x21_0 still gave a better improvement to menu FMV playback/stutter than 0x21_1 and 0x03. I didn't notice any change in performance with 0x21_1 in this scenario. Caching is still enabled with IHIN/IXIN with 0x21_0?--[[User:Mrjaredbeta|Mrjaredbeta]] ([[User talk:Mrjaredbeta|talk]]) 00:15, 22 October 2022 (UTC)
**Whoops, sorry i meant 0x21_0 and 0x03. 0x21_1 actually create a lot of additional recompiled code. 0x21_0 is so fast because it skips lookup for cached addresses also outside of general cache opcodes (that how it looks like, i need to do little bit more work here). IHIN/IXIN (hit/index invalidation) can be totally disabled only with 0x03. 0x21 (0/1) still generate a lot of code for IHIN/IXIN when 0x03 is not used, even more that without 0x21. --[[User:Kozarovv|Kozarovv]] ([[User talk:Kozarovv|talk]]) 06:53, 22 October 2022 (UTC)
***Okay, that makes sense. It is difficult to tell if adding 0x03 with 0x21_0 made any difference with this game as FMV is fixed with just 0x21_0, but it may be beneficial to test games that still have FMV playback issues with 0x21_0 enabled (slight desync still with Shadow Hearts).--[[User:Mrjaredbeta|Mrjaredbeta]] ([[User talk:Mrjaredbeta|talk]]) 15:05, 22 October 2022 (UTC)
<br><br>'''Emotion Engine Cache support'''<br>
Apparently, emulator support some parts of cache. More precisely instruction cache. Implementation seems to be simple and not 100% accurate, and there is no data cache support (obviously - speed). Still impressive there is something at all in recompiler.
 
'''Supported opcodes:'''
{| border="1" cellspacing="0" cellpadding="5" border="#999" class="wikitable" style="border:1px solid #999; border-collapse: collapse;"
|-
|-
! Opcode || Info
| Action Replay MAX || SCED54409 ||  || {{ps2cd}} ||  ||  || {{no}} ||  
|-
|-
|r5900 CACHE BXLBT ||  Unsupported, store 0 on COP0 TagLo and TagHi
| Battlefield 2 Modern Combat || SLES53729 ||  || {{ps2dvd}} ||  ||  || {{no}} ||
|-
|-
|r5900 CACHE DXLDT ||  Unsupported, store 0 on COP0 TagLo
| Constantine || SLES52872 ||  || {{ps2dvd}} ||  ||  || {{no}} ||
|-
|-
|r5900 CACHE DXLTG || Unsupported, store 0 on COP0 TagLo
| Demo Disc 3-073-543-11 || PBPX95514 ||  || {{ps2dvd}} ||  ||  || {{no}} ||  
|-
|-
|r5900 CACHE IXLDT ||  Unsupported, store 0 on COP0 TagLo
| EyeToy Play || SCES51513 ||  || {{ps2dvd}} ||  ||  || {{no}} ||
|-
|-
|r5900 CACHE IXLTG ||  Supported, cmd 0x21 (0,1) skip function and store 0 on COP0 TagLo
| EyeToy Play 2 || SCES52748 ||  || {{ps2dvd}} ||  ||  || {{no}} ||
|-
|-
|r5900 CACHE DXWBIN || Not supported at all, empty function.
| EyeToy Play 3 || SLES53315 ||  || {{ps2dvd}} ||  ||  || {{no}} ||  
|-
|-
|r5900 CACHE DXIN ||  Not supported at all, empty function.
| Freedom Fighters || SLES51467 || || {{ps2dvd}} ||  ||  || {{no}} ||
|-
|-
|r5900 CACHE DHWBIN || Not supported at all, empty function.
| Ghost in the Shell Standalone Complex || SLES53020 ||  || {{ps2dvd}} ||  ||  || {{no}} ||  
|-
|-
|r5900 CACHE DHIN ||  Not supported at all, empty function.
| GoldenEye Rogue Agent || SLES52974 || || {{ps2dvd}} ||  ||  || {{no}} ||
|-
|-
|r5900 CACHE DHWOIN || Not supported at all, empty function.
| Guerrilla Strike || SLES53344 ||  || {{ps2cd}} ||  ||  || {{no}} ||  
|-
|-
|r5900 CACHE IHIN ||  Full support, cmd 0x21 (0,1) change path of that opcode, 0x03 practically skip whole op.
| Gunfighter 2 Revenge of Jessy James || SLES51289 || || {{ps2cd}} ||  ||  || {{no}} ||
|-
|-
|r5900 CACHE IXIN ||  Full support, cmd 0x21 (0,1) change path of that opcode, 0x03 practically skip whole op.
| Half Life || SLES50504 ||  ||  {{ps2cd}} || ||  || {{no}} ||
|-
|-
|r5900 CACHE misc ||  Do something, but function is little bit complicated to tell for now that it is something that make sense.
| HDLoader || - ||  || {{ps2cd}} || ||  || {{no}} ||  
|}
|-
--[[User:Kozarovv|Kozarovv]] ([[User talk:Kozarovv|talk]]) 21:03, 1 October 2022 (UTC)
| International Golf Pro || SLES52349 || || {{ps2cd}} || || || {{no}} ||  
 
|-
Example of recompiled code with enabled cache emulation:  https://pastebin.com/sDwc1MLX
| Jet Ion GP || SLES50544 ||  || {{ps2cd}} || || || {{no}} ||
* 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)
| killer7 || SLES53366 || || {{ps2dvd}} || || || {{no}} ||
* 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.
| Kya Dark Lineage || SLES51473 || || {{ps2dvd}} || || || {{no}} ||
* 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.
| London Racer Destruction Madness || SLES53654 || || {{ps2cd}} || || || {{no}} ||
--[[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)
| London Racer Police Madness || SLES53536 || || {{ps2cd}} || || || {{no}} ||
** 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)
| Manhunt || SLES52023 || || {{ps2dvd}} || || || {{no}} ||
**** 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)
|-
 
| Max Play - 10 Classic Retro Games || - || || {{ps2cd}} || || || {{no}} ||
===ps2_netemu command 0x22===
|-
Weird command. Sets something 1 (CDVD/MECHA), but seems to never use it.
| Medal of Honor European Assault || SLES53332 || || {{ps2dvd}} || || || {{no}} ||
 
|-
===ps2_netemu command 0x28===
| Medal of Honor Frontline || SLES50684 || || {{ps2dvd}} || || || {{no}} ||
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.
|-
 
| Medal of Honor Rising Sun || SLES51873 || || {{ps2dvd}} || || || {{no}} ||
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).
|-
 
| Medal of Honor Vanguard || SLES54683 || || {{ps2dvd}} || || || {{no}} ||
===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.
| Men in Black II Alien Escape || SLES50789 || || {{ps2dvd}} || || || {{no}} ||
* 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. --[[User:Kozarovv|Kozarovv]] ([[User talk: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. --[[User:Mrjaredbeta|Mrjaredbeta]] ([[User talk:Mrjaredbeta|talk]]) 02:15, 10 July 2022 (UTC)
| Network Access Disc || SCES51578 || || {{ps2dvd}} || || || {{no}} ||
 
|-
===ps2_netemu command 0x2E===
| OPM #66 || SCED54409 || || {{ps2dvd}} || || || {{no}} ||
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.
| OPM #67 || SCED54410 || || {{ps2dvd}} || || || {{no}} ||
  lwz      r0, 0x2C(r31)          # cmd_0x2E
|-
  cmpwi    cr7, r0, 0
| OPM #68 || SCED54412 || || {{ps2dvd}} || || || {{no}} ||
  beq      cr7, cdvd_error_1349B4  # skip cdvd error if cmd not 0.
|-
nop
| OPM #69 || SCED54413 || || {{ps2dvd}} || || || {{no}} ||
   
|-
  loc_134988:
| OPM #70 || SCED54415 || || {{ps2dvd}} || || || {{no}} ||
  mftb      r9
|-
cmpwi    cr7, r9, 0
| OPM #72 || SCED54417 || || {{ps2dvd}} || || || {{no}} ||
  beq      cr7, loc_134988        # Loop until timebase is not 0
|-
  clrldi    r0, r0, 32
| OPM #73 || SCED54418 || || {{ps2dvd}} || || || {{no}} ||
  add      r0, r0, r9
|-
li        r9, 5
| OPM #74 || SCED55113 || || {{ps2dvd}} || || || {{no}} ||
  std      r0, 0x20(r31)          # cmd_0x2E + timebase
|-
  stw      r9, 0(r31)
| OPM #75 || SCED55114 || || {{ps2dvd}} || || || {{no}} ||
  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.. --[[User:Kozarovv|Kozarovv]] ([[User talk:Kozarovv|talk]]) 07:05, 7 March 2022 (UTC)
| OPM #77 || SCED55117 || || {{ps2dvd}} || || || {{no}} ||
 
|-
===ps2_gxemu command 0x19===
| OPM #79 || SCED55119 || || {{ps2dvd}} || || || {{no}} ||
Command disable reads/writes to selected IOP HW registers. Disabled regs are:
|-
 
| Perfect Ace Pro Tournament Tennis || SLES51735 || || {{ps2cd}} || || || {{no}} ||
* 0x10000000 - 0x10003FFF (DEV9/SPEED/ATA/SMAP)
|-
* 0x1F801460 - 0x1F80147F (Unknown)
| Prisoner of War || SLES50397 || || {{ps2dvd}} || || || {{no}} ||
 
|-
Command is auto applied to titles listed here (duplicates are really there in emu too):
| Ratchet & Clank 3 || SCES52456 || || {{ps2dvd}} || || || {{no}} ||
    Hash          ID                Name
|-
  0x0CD1298155 SLES_540.13 World Snooker Championship 2007
| Red Baron || SLES53434 || || {{ps2cd}} || || || {{no}} ||
0x12C93199A5  SLES_518.40  NHL Hitz Pro
|-
  0x15C93199AD SLES_549.13 Pro Evolution Soccer 2008
| SAS Anti-terror Force || SLES53435 || || {{ps2cd}} || || || {{no}} ||
0x24D92589A5  SLUS_211.86  NBA Ballers - Phenom
|-
  0x2CD12D8125 SLUS_212.35 MLB 2K6
| Second Sight || SLES52670 || || {{ps2dvd}} || || || {{no}} ||
0x34C9359935  SLUS_211.38  X-Men Legends II - Rise of Apocalypse
|-
  0x34C93599E5 SLUS_211.28 Blitz - The League
| Seek and Destroy || SLES51603 || || {{ps2cd}} || || || {{no}} ||
  0x34C93599E5 SLUS_211.28 Blitz - The League
|-
  0x449961C9E5 SLES_542.10 NBA 2K7
| Silent Hill 3 || SLES51434 || || {{ps2dvd}} || {{yes}} || || {{no}} ||
0x4C9169C1CD  SLES_542.46  FIFA '07
|-
  0x4C9169C1D5 SLES_542.45 NHL '07
| Socom US Navy SEALs || SCES50928 || || {{ps2dvd}} || || || {{no}} ||
0x4C9169C1DD  SLES_542.44  FIFA '07
|-
  0x4C9169C1E5 SLES_542.43 FIFA '07
| Socom II US Navy SEALs || SCES51904 || || {{ps2dvd}} || || || {{no}} ||
0x4C9169C1F5  SLES_542.41  FIFA '07
|-
  0x4C9169C1FD SLES_542.40 FIFA '07
| Socom 3 US Navy SEALs || SCES53300 || || {{ps2dvd}} || || || {{no}} ||
0x4CB14DE12D  SLUS_213.74  Marvel - Ultimate Alliance
|-
  0x54A955F915 SLUS_212.74 Outrun 2006 - Coast 2 Coas
| Socom US Navy SEALs Combined Assault || SCES54477 || || {{ps2dvd}} || || || {{no}} ||
  0x5CA15DF165 SLUS_213.01 World Series of Poker
|-
  0x5CA15DF1FD SLUS_212.86 WWE SmackDown! vs RAW 2006
| Swap Magic 3 plus (PAL version 3.6) CD || SCED54409 || || {{no}} || - ||  || {{no}} ||
0x5CA15DF1FD  SLUS_212.86  WWE SmackDown! vs RAW 2006
|-
  0x649965C94D SLUS_214.63 Tom Clancy's Ghost Recon 2
| Swap Magic 3 plus (PAL version 3.6) DVD || SCED54409 || || {{ps2dvd}} || {{yes}} || || {{no}} ||
0x649965C955  SLUS_214.60  NBA Live '07
|-
  0x649965C95D SLUS_214.61 NASCAR '07
| Tenchu Wrath of Heaven || SLES50679 || || {{ps2dvd}} || || || {{no}} ||
0x649965C965  SLUS_214.58  NHL '07
|-
  0x649965C96D SLUS_214.59 NCAA Football '07
| Terminator 3 Rise of the Machines || SLES52152 || || {{ps2dvd}} || || || {{no}} ||
0x6BB149E15D  SLES_531.04  Tom Clancy's Rainbow Six - Lockdown
|-
  0x6C916DC165 SLUS_214.91 World Series of Poker - Tournament of Champions
| The Great Escape || SLES51315 || || {{ps2dvd}} || || || {{no}} ||
  0x6C916DC1A5 SLUS_214.83 Tiger Woods PGA Tour '07
|-
  0x6C916DC1AD SLUS_214.82 NFL Street 3
| The Hulk || SLES51508 || || {{ps2dvd}} || {{yes}} || || {{no}} ||
0x6C916DC1B5  SLUS_214.81  NCAA March Madness '07
|-
0x6C916DC1D5  SLUS_214.77  Madden NFL '07 [Hall of Fame Edition]
| The Matrix Path of Neo || SLES53799 || || {{ps2dvd}} || || || {{no}} ||
  0x6C916DC1DD SLUS_214.76  Madden NFL '07
|-
0x748975D9DD  SLUS_213.83  Fight Night - Round 3
| The Plan || SLES53965 || || {{ps2cd}} || || || {{no}} ||  
  0x7C817DD125 SLUS_214.33 FIFA Soccer '07
|-
0x7C817DD165  SLUS_214.25  NHL 2K7
| Time Crisis 3 || SCES51844 || || {{ps2dvd}} ||  || || {{no}} ||
  0x7C817DD16D SLUS_214.24 NBA 2K7
|-
0x7C817DD175  SLUS_214.27  WWE SmackDown! vs RAW 2007
| Tom Clancy's Ghost Recon || SLES51181 ||  || {{ps2dvd}} || || || {{no}} ||
0x7C817DD1CD  SLUS_214.12  World Championship Poker featuring Howard Lederer - All-In
|-
0x84798529BD  SLUS_205.65  Champions of Norrath
| Tom Clancy's Rainbow Six 3 || SLES52288 ||  || {{ps2dvd}} ||  || || {{no}} ||
  0x8559A109AD uuunnnnnkkk  
|-
0x8579852915  SLUS_215.68  Arena Football - Road to Glory
| Tom Clancy's Splinter Cell || SLES51466 || || {{ps2dvd}} || || || {{no}} ||
  0x8579852965 SLUS_215.82 MVP '07 - NCAA Baseball
|-
  0x8D51A90145 SLES_545.11 UEFA Champions League
| Tom Clancy's Splinter Cell Chaos Theory || SLES53007 ||  || {{ps2dvd}} ||  || || {{no}} ||
0x8D51A901B5  SLES_545.13  UEFA Champions League
|-
  0x8D51A901BD SLES_545.12 UEFA Champions League
| Tom Clancy's Splinter Cell Pandora Tomorrow || SLES52149 || || {{ps2dvd}} || || || {{no}} ||
0x8D718D21BD  SLUS_216.20  NCAA Football '08
|-
  0x9C619D31E5 SLUS_205.41 NBA Ballers
| Trapt || SLES53824 || || {{ps2dvd}} || || || {{no}} ||
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==
{{Boxcode|title=explore_category_sysconf.rco\Text\English.xml|code=<syntaxhighlight lang="xml">
<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>
</syntaxhighlight>}}
 
{{Boxcode|title=game_ext_plugin.rco\Text\English.xml|code=<syntaxhighlight lang="xml">
  <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>
</syntaxhighlight>}}
 
{{Boxcode|title=explore_plugin_full.rco\Text\English.xml|code=<syntaxhighlight lang="xml">
  <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>
</syntaxhighlight>}}
 
==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
    p3dwik-ps2compatfiles.rar
  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: [http://www.sendspace.com/file/bm9z9v p3dwik-ps2compatfiles.rar]<br>
Possible compatibility Lists:
* http://tortuga-cove.com/forums/viewtopic.php?f=57&t=530
* [[Talk:Emulation#PS2.2FPStwo]]
 
 
====boot_ps2====
http://foxbrew.org/ps3/otheros-utils/boot_ps2.git <br />
http://www.multi...upload.com/QKK7ETPHXZ boot_ps2-src.rar (1.43 KB) <br />
http://www.multi...upload.com/YCZ63Y6TQ5 boot_ps2.pkg (69.17 KB) <br />
 
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)
 
[http://rghost.net/42586725 boot_ps2 4.xx eboots.zip (153 KB)] <br /> installing 3.55 pkg and replacing the eboot and editing the sfo should work.


=== Enable Playstation 2 on non BC's===
==== Tests on NON-BC CECHP01/NTSC-U (Firmware 2.60/boot_ps2.pkg) ====
 
<br>
[[http://www.ps3devwiki.com/index.php?title=Emulation#Getting_Playstation_2_Software_Emulator_working Getting Playstation 2 Software Emulator working]]
<br>Amplitude - Intro prompts are completely glitched, unresponsive to controller input.
<br>Backyard Football 2007 - Graphical glitches during menu and gameplay. Frame rate is okay.
<br>Boogie - Intro FMV runs very slow, fails to recognize input after the title screen.
<br>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


[[Image:Vsh_ps2_change1.png|left|thumb|400px|XMB Game Settings non BC/BC,patched]]<br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br>
Comparative listings: http://tortuga-cove.com/forums/viewtopic.php?f=57&t=530


==== Service Mode in relation to PS2 emulation tests ====
==Hidden/Inaccessible menu in ps2_emu==
* 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.
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


* Any made Virtual Memory Cards previously will be removed and you will have no access to them, nor be able to create one.
==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.
<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.


* 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)
==CDVD Commands==
===Netemu===
<pre>
4.75 and up.


* As a workaround for above wireless controller issue, you can use an USB2PS2 converter and connect an old PS2 / Dualshock2 controller.
Supported CDVD N Commands:


==== tests on 2000 series PS3 Slim ====
opd_ptr  num  name
Testplatform:
0x934AB0 0x00: N_CD_NOP
SKU: 2000 series slim (minver 2.70)
0x934AB8 0x01: N_CD_RESET
Firmware: 3.55 'Rogero 3.4' mmap114+peek/poke but no SS-patches
0x934AC0 0x02: N_CD_STANDBY
Memorycards: MC:PS1 in slot1, MC:PS2 in slot2.
0x934AC8 0x03: N_CD_STOP
Mainscreen: Component+Composite 576i+P/720i+P//1080i
0x934AD0 0x04: N_CD_PAUSE
Sec.screen: Composite 576i
0x934AD8 0x05: N_CD_SEEK
48 titles tested (PAL disc on PAL SKU) // [[User:Euss|Euss]]
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


* Without Factory Service Mode : gives "Incompatible Data" when inserting PS2 disc
Supported CDVD S Commands:


* 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)
opd_ptr  num  name
 
0x934B20 0x00: SCMD_Return_0
* 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)
0x934B28 0x01: SCMD_GetDiscType            panic
 
0x934B30 0x02: SCMD_CdReadSubQ              panic
* 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).
0x934B38 0x03: SCMD_Mecacon_command        (support 0x00, 0x01 ,0x30, 0x45 sub cmds)
 
0x934B40 0x04: SCMD_0x04                    panic
* 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).
0x934B48 0x05: SCMD_CdTrayReqState
 
0x934B50 0x06: SCMD_CdTrayCtrl
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].
0x934B58 0x07: SCMD_0x07                    panic
Perhaps hardswapping out all the dev_flash ps2 emu files for the same software only emulator would circumvent the 'incompatible title' message.
0x934B60 0x08: SCMD_CdReadRTC
 
0x934B68 0x09: SCMD_sceCdWriteRTC
 
0x934B70 0x0A: SCMD_sceCdReadNVM            panic
==== Second test: FW 2.70/3.15 ====
0x934B78 0x0B: SCMD_sceCdWriteNVM          panic
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".
0x934B80 0x0C: SCMD_0x0C                    panic
 
0x934B88 0x0D: SCMD_0x0D                    panic
==== Third test: FW 3.55 OtherOS++22GB (with SS Patches) ====
0x934B90 0x0E: SCMD_0x0E                    panic
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.
0x934B98 0x0F: SCMD_sceCdPowerOff
 
0x934BA0 0x10: SCMD_0x10                    panic
 
0x934BA8 0x11: SCMD_0x11                    panic
===== considering titles to test =====
0x934BB0 0x12: SCMD_sceCdReadILinkId        return zeroed iLinkId
* http://en.wikipedia.org/wiki/List_of_PlayStation_3_backward_compatible_PlayStation_2_and_PlayStation_games
0x934BB8 0x13: SCMD_sceCdWriteILinkID      panic
* http://tortuga-cove.com/forums/viewtopic.php?f=57&t=530
0x934BC0 0x14: SCMD_CdCtrlAudioDigitalOut  panic
* http://us.playstation.com/support/compatiblestatus/index.htm
0x934BC8 0x15: SCMD_sceCdForbidDVDP
 
0x934BD0 0x16: SCMD_AutoAdjustCtrl
These have no listed issues:
0x934BD8 0x17: SCMD_CdReadModelNumber      Return SCPH-50000 (SCMD 0x03(0x00) return Mechacon version 3.9 which is wrong for that model..)
* Half-Life
0x934BE0 0x18: SCMD_CdWriteModelNumber      panic
* Hulk
0x934BE8 0x19: SCMD_0x19                    panic
* Medal of Honor: Frontline
0x934BF0 0x1A: SCMD_sceCdBootCertify
These have minor issues listed (but should still play):
0x934BF8 0x1B: SCMD_sceCdCancelPOffRdy
* Silent Hill 3
0x934C00 0x1C: SCMD_sceCdBlueLEDCtl
* Second Sight
0x934C08 0x1D: SCMD_cdvdman_call116
 
0x934C10 0x1E: SCMD_sceRemote2Read
==== tests on CECHC04 (partial BC) ====
0x934C18 0x1F: SCMD_sceRemote2_7
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.'')
0x934C20 0x20: SCMD_Return_0
 
0x934C28 0x21: SCMD_Return_0
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.
0x934C30 0x22: SCMD_Return_0
 
0x934C38 0x23: SCMD_Return_0
no disc icon:
0x934C40 0x24: SCMD_Return_0
* Medal of Honor: Rising Sun
0x934C48 0x25: SCMD_Return_0
* Half-Life
0x934C50 0x26: SCMD_Return_0
 
0x934C58 0x27: SCMD_Return_0
disc icon:
0x934C60 0x28: SCMD_Return_0
* Hulk
0x934C68 0x29: SCMD_sceCdNoticeGameStart    panic
* Second Sight
0x934C70 0x2A: SCMD_Return_0
* Silent Hill 3
0x934C78 0x2B: SCMD_Return_0
 
0x934C80 0x2C: SCMD_Return_0
==== Renaming ps2_netemu to ps2_emu ====
0x934C88 0x2D: SCMD_Return_0
 
0x934C90 0x2E: SCMD_Return_0
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.
0x934C98 0x2F: SCMD_Return_0
 
0x934CA0 0x30: SCMD_Return_0
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)
0x934CA8 0x31: SCMD_Return_0
 
0x934CB0 0x32: SCMD_Return_0
 
0x934CB8 0x33: SCMD_Return_0
==== PS2 on non BC HW - Tests ====
0x934CC0 0x34: SCMD_Return_0
 
0x934CC8 0x35: SCMD_Return_0
{| class="wikitable sortable"
0x934CD0 0x36: SCMD_Return_0
|-
0x934CD8 0x37: SCMD_Return_0
! rowspan="2" | Title !! rowspan="2" | DiscID !! colspan="2" | Disc Icon !! colspan="3" | ps2_softemu !! rowspan="2" | Remarks
0x934CE0 0x38: SCMD_Return_0
|-
0x934CE8 0x39: SCMD_Return_0
! <abbr title="Normal Mode">Normal</abbr> !! <abbr title="Factory Service Mode">FSM</abbr> !! 2.50 !! 2.60 !! 2.70
0x934CF0 0x3A: SCMD_Return_0
|-
0x934CF8 0x3B: SCMD_Return_0
| Action Replay MAX || SCED54409 || || {{ps2cd}} || ||  || {{no}} ||
0x934D00 0x3C: SCMD_Return_0
|-
0x934D08 0x3D: SCMD_Return_0
| Battlefield 2 Modern Combat || SLES53729 || || {{ps2dvd}} || ||  || {{no}} ||
0x934D10 0x3E: SCMD_Return_0
|-
0x934D18 0x3F: SCMD_Return_0
| Constantine || SLES52872 || || {{ps2dvd}} || ||  || {{no}} ||
0x934D20 0x40: SCMD_CdOpenConfig
|-
0x934D28 0x41: SCMD_CdReadConfig
| Demo Disc 3-073-543-11 || PBPX95514 || || {{ps2dvd}} || ||  || {{no}} ||
0x934D30 0x42: SCMD_CdWriteConfig
|-
0x934D38 0x43: SCMD_CdCloseConfig
| EyeToy Play || SCES51513 || || {{ps2dvd}} || ||  || {{no}} ||
0x934D40 0x44: SCMD_Return_0
|-
0x934D48 0x45: SCMD_Return_0
| EyeToy Play 2 || SCES52748 || || {{ps2dvd}} || ||  || {{no}} ||
0x934D50 0x46: SCMD_Return_0
|-
0x934D58 0x47: SCMD_Return_0
| EyeToy Play 3 || SLES53315 || || {{ps2dvd}} || ||  || {{no}} ||
0x934D60 0x48: SCMD_Return_0
|-
0x934D68 0x49: SCMD_Return_0
| Freedom Fighters || SLES51467 || || {{ps2dvd}} || ||  || {{no}} ||
0x934D70 0x4A: SCMD_Return_0
|-
0x934D78 0x4B: SCMD_Return_0
| Ghost in the Shell Standalone Complex || SLES53020 || || {{ps2dvd}} || ||  || {{no}} ||
0x934D80 0x4C: SCMD_Return_0
|-
0x934D88 0x4D: SCMD_Return_0
| GoldenEye Rogue Agent || SLES52974 || || {{ps2dvd}} || ||  || {{no}} ||
0x934D90 0x4E: SCMD_Return_0
|-
0x934D98 0x4F: SCMD_Return_0
| Guerrilla Strike || SLES53344 || || {{ps2cd}} || ||  || {{no}} ||
0x934DA0 0x50: SCMD_Return_0
|-
0x934DA8 0x51: SCMD_Return_0
| Gunfighter 2 Revenge of Jessy James || SLES51289 || || {{ps2cd}} || ||  || {{no}} ||
0x934DB0 0x52: SCMD_Return_0
|-
0x934DB8 0x53: SCMD_Return_0
| Half Life || SLES50504 || || {{ps2cd}} ||  ||  || {{no}} ||
0x934DC0 0x54: SCMD_Return_0
|-
0x934DC8 0x55: SCMD_Return_0
| HDLoader || - || || {{ps2cd}} || ||  || {{no}} ||
0x934DD0 0x56: SCMD_Return_0
|-
0x934DD8 0x57: SCMD_Return_0
| International Golf Pro || SLES52349 || || {{ps2cd}} || ||  || {{no}} ||
0x934DE0 0x58: SCMD_Return_0
|-
0x934DE8 0x59: SCMD_Return_0
| Jet Ion GP || SLES50544 || || {{ps2cd}} || ||  || {{no}} ||
0x934DF0 0x5A: SCMD_Return_0
|-
0x934DF8 0x5B: SCMD_Return_0
| killer7 || SLES53366 || || {{ps2dvd}} || ||  || {{no}} ||
0x934E00 0x5C: SCMD_Return_0
|-
0x934E08 0x5D: SCMD_Return_0
| Kya Dark Lineage || SLES51473 || || {{ps2dvd}} || ||  || {{no}} ||
0x934E10 0x5E: SCMD_Return_0
|-
0x934E18 0x5F: SCMD_Return_0
| London Racer Destruction Madness || SLES53654 || || {{ps2cd}} || ||  || {{no}} ||
0x934E20 0x60: SCMD_Return_0
|-
0x934E28 0x61: SCMD_Return_0
| London Racer Police Madness || SLES53536 || || {{ps2cd}} || ||  || {{no}} ||
0x934E30 0x62: SCMD_Return_0
|-
0x934E38 0x63: SCMD_Return_0
| Manhunt || SLES52023 || || {{ps2dvd}} || ||  || {{no}} ||
0x934E40 0x64: SCMD_Return_0
|-
0x934E48 0x65: SCMD_Return_0
| Max Play - 10 Classic Retro Games || - || || {{ps2cd}} || ||  || {{no}} ||
0x934E50 0x66: SCMD_Return_0
|-
0x934E58 0x67: SCMD_Return_0
| Medal of Honor European Assault || SLES53332 || || {{ps2dvd}} || ||  || {{no}} ||
0x934E60 0x68: SCMD_Return_0
|-
0x934E68 0x69: SCMD_Return_0
| Medal of Honor Frontline || SLES50684 || || {{ps2dvd}} || ||  || {{no}} ||
0x934E70 0x6A: SCMD_Return_0
|-
0x934E78 0x6B: SCMD_Return_0
| Medal of Honor Rising Sun || SLES51873 || || {{ps2dvd}} || ||  || {{no}} ||
0x934E80 0x6C: SCMD_Return_0
|-
0x934E88 0x6D: SCMD_Return_0
| Medal of Honor Vanguard || SLES54683 || || {{ps2dvd}} || ||  || {{no}} ||
0x934E90 0x6E: SCMD_Return_0
|-
0x934E98 0x6F: SCMD_Return_0
| Men in Black II Alien Escape || SLES50789 || || {{ps2dvd}} || ||  || {{no}} ||
0x934EA0 0x70: SCMD_Return_0
|-
0x934EA8 0x71: SCMD_Return_0
| Network Access Disc || SCES51578 || || {{ps2dvd}} || ||  || {{no}} ||
0x934EB0 0x72: SCMD_Return_0
|-
0x934EB8 0x73: SCMD_Return_0
| OPM #66 || SCED54409 || || {{ps2dvd}} || ||  || {{no}} ||
0x934EC0 0x74: SCMD_Return_0
|-
0x934EC8 0x75: SCMD_Return_0
| OPM #67 || SCED54410 || || {{ps2dvd}} || ||  || {{no}} ||
0x934ED0 0x76: SCMD_Return_0
|-
0x934ED8 0x77: SCMD_Return_0
| OPM #68 || SCED54412 || || {{ps2dvd}} || ||  || {{no}} ||
0x934EE0 0x78: SCMD_Return_0
|-
0x934EE8 0x79: SCMD_Return_0
| OPM #69 || SCED54413 || || {{ps2dvd}} || ||  || {{no}} ||
0x934EF0 0x7A: SCMD_Return_0
|-
0x934EF8 0x7B: SCMD_Return_0
| OPM #70 || SCED54415 || || {{ps2dvd}} || ||  || {{no}} ||
0x934F00 0x7C: SCMD_Return_0
|-
0x934F08 0x7D: SCMD_Return_0
| OPM #72 || SCED54417 || || {{ps2dvd}} || ||  || {{no}} ||
0x934F10 0x7E: SCMD_Return_0
|-
0x934F18 0x7F: SCMD_Return_0
| OPM #73 || SCED54418 || || {{ps2dvd}} || ||  || {{no}} ||
0x934F20 0x80: SCMD__mechacon_auth_0x80
|-
0x934F28 0x81: SCMD__mechacon_auth_0x81
| OPM #74 || SCED55113 || || {{ps2dvd}} || ||  || {{no}} ||
0x934F30 0x82: SCMD__mechacon_auth_0x82
|-
0x934F38 0x83: SCMD__mechacon_auth_0x83
| OPM #75 || SCED55114 || || {{ps2dvd}} || ||  || {{no}} ||
0x934F40 0x84: SCMD__mechacon_auth_0x84
|-
0x934F48 0x85: SCMD__mechacon_auth_0x85
| OPM #77 || SCED55117 || || {{ps2dvd}} || ||  || {{no}} ||
0x934F50 0x86: SCMD__mechacon_auth_0x86
|-
0x934F58 0x87: SCMD__mechacon_auth_0x87
| OPM #79 || SCED55119 || || {{ps2dvd}} || ||  || {{no}} ||
0x934F60 0x88: SCMD__mechacon_auth_0x88
|-
0x934F68 0x89: SCMD_Return_0
| Perfect Ace Pro Tournament Tennis || SLES51735 || || {{ps2cd}} || ||  || {{no}} ||
0x934F70 0x8A: SCMD_Return_0
|-
0x934F78 0x8B: SCMD_Return_0
| Prisoner of War || SLES50397 || || {{ps2dvd}} || ||  || {{no}} ||
0x934F80 0x8C: SCMD_Return_0
|-
0x934F88 0x8D: SCMD_Return_0
| Ratchet & Clank 3 || SCES52456 || || {{ps2dvd}} || ||  || {{no}} ||
0x934F90 0x8E: SCMD_Return_0
|-
0x934F98 0x8F: SCMD__mechacon_auth_0x8F
| Red Baron || SLES53434 || || {{ps2cd}} || ||  || {{no}} ||
 
|-
Notes:
| SAS Anti-terror Force || SLES53435 || || {{ps2cd}} || ||  || {{no}} ||
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.
| Second Sight || SLES52670 || || {{ps2dvd}} || ||  || {{no}} ||
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.
| Seek and Destroy || SLES51603 || || {{ps2cd}} || ||  || {{no}} ||
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.
| Silent Hill 3 || SLES51434 || || {{ps2dvd}} || {{yes}} ||  || {{no}} ||
</pre>
|-
 
| Socom US Navy SEALs || SCES50928 || || {{ps2dvd}} || ||  || {{no}} ||
==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.
| Socom II US Navy SEALs || SCES51904 || || {{ps2dvd}} || ||  || {{no}} ||
===Netemu===
|-
Address in memory | r5900 register
| Socom 3 US Navy SEALs || SCES53300 || || {{ps2dvd}} || ||  || {{no}} ||
  FFFFFFFFFFFF8980 |  5900_zero_upper64bits
|-
  FFFFFFFFFFFF8988 |  5900_zero_lower64bits
| Socom US Navy SEALs Combined Assault || SCES54477 || || {{ps2dvd}} || ||  || {{no}} ||
  FFFFFFFFFFFF8990 |  5900_at_reg_upper64
|-
  FFFFFFFFFFFF8998 |  5900_at_reg_lower64
| Swap Magic 3 plus (PAL version 3.6) CD || SCED54409 ||  || {{no}} || - || || {{no}} ||
  FFFFFFFFFFFF89A0 |  5900_v0_reg_upper64
|-
  FFFFFFFFFFFF89A8 |  5900_v0_reg_lower64
| Swap Magic 3 plus (PAL version 3.6) DVD || SCED54409 || || {{ps2dvd}} || {{yes}} ||  || {{no}} ||
  FFFFFFFFFFFF89B0 |  5900_v1_reg_upper64
|-
  FFFFFFFFFFFF89B8 |  5900_v1_reg_lower64
| Tenchu Wrath of Heaven || SLES50679 || || {{ps2dvd}} || ||  || {{no}} ||
  FFFFFFFFFFFF89C0 |  5900_a0_reg_upper64
|-
  FFFFFFFFFFFF89C8 |  5900_a0_reg_lower64
| Terminator 3 Rise of the Machines || SLES52152 || || {{ps2dvd}} || ||  || {{no}} ||
  FFFFFFFFFFFF89D0 |  5900_a1_reg_upper64
|-
  FFFFFFFFFFFF89D8 |  5900_a1_reg_lower64
| The Great Escape || SLES51315 || || {{ps2dvd}} || ||  || {{no}} ||
  FFFFFFFFFFFF89E0 |  5900_a2_reg_upper64
|-
  FFFFFFFFFFFF89E8 |  5900_a2_reg_lower64
| The Hulk || SLES51508 || || {{ps2dvd}} || {{yes}} ||  || {{no}} ||
  FFFFFFFFFFFF89F0 |  5900_a3_reg_upper64
|-
  FFFFFFFFFFFF89F8 |  5900_a3_reg_lower64
| The Matrix Path of Neo || SLES53799 || || {{ps2dvd}} || ||  || {{no}} ||
  FFFFFFFFFFFF8A00 |  5900_t0_reg_upper64
|-
  FFFFFFFFFFFF8A08 |  5900_t0_reg_lower64
| The Plan || SLES53965 || || {{ps2cd}} || ||  || {{no}} ||
  FFFFFFFFFFFF8A10 |  5900_t1_reg_upper64
|-
  FFFFFFFFFFFF8A18 |  5900_t1_reg_lower64
| Time Crisis 3 || SCES51844 || || {{ps2dvd}} || ||  || {{no}} ||
  FFFFFFFFFFFF8A20 |  5900_t2_reg_upper64
|-
  FFFFFFFFFFFF8A28 |  5900_t2_reg_lower64
| Tom Clancy's Ghost Recon || SLES51181 || || {{ps2dvd}} || ||  || {{no}} ||
  FFFFFFFFFFFF8A30 |  5900_t3_reg_upper64
|-
  FFFFFFFFFFFF8A38 |  5900_t3_reg_lower64
| Tom Clancy's Rainbow Six 3 || SLES52288 || || {{ps2dvd}} || ||  || {{no}} ||
  FFFFFFFFFFFF8A40 |  5900_t4_reg_upper64
|-
  FFFFFFFFFFFF8A48 |  5900_t4_reg_lower64
| Tom Clancy's Splinter Cell || SLES51466 || || {{ps2dvd}} || ||  || {{no}} ||
  FFFFFFFFFFFF8A50 |  5900_t5_reg_upper64
|-
  FFFFFFFFFFFF8A58 |  5900_t5_reg_lower64
| Tom Clancy's Splinter Cell Chaos Theory || SLES53007 || || {{ps2dvd}} || ||  || {{no}} ||
  FFFFFFFFFFFF8A60 |  5900_t6_reg_upper64
|-
  FFFFFFFFFFFF8A68 |  5900_t6_reg_lower64
| Tom Clancy's Splinter Cell Pandora Tomorrow || SLES52149 || || {{ps2dvd}} || ||  || {{no}} ||
  FFFFFFFFFFFF8A70 |  5900_t7_reg_upper64
|-
  FFFFFFFFFFFF8A78 |  5900_t7_reg_lower64
| Trapt || SLES53824 || || {{ps2dvd}} || ||  || {{no}} ||
  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..


==== Tests on NON-BC CECHP01/NTSC-U (Firmware 2.60/boot_ps2.pkg) ====
==EE I/O Handlers list==
<br>
===Netemu===
<br>Amplitude - Intro prompts are completely glitched, unresponsive to controller input.
4.75 and up. Mode (1 = read / 2 = write)
<br>Backyard Football 2007 - Graphical glitches during menu and gameplay. Frame rate is okay.
<br>Boogie - Intro FMV runs very slow, fails to recognize input after the title screen.
<br>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
{| class="wikitable sortable"
 
!mode !! size !! PS2_HW_REG !! handler_opd
Comparative listings: http://tortuga-cove.com/forums/viewtopic.php?f=57&t=530
|-
 
| 1 || 4 || T0_COUNT || stru_723218
==Hidden/Inaccessible menu in ps2_emu==
|-
 
| 2 || 4 || T0_COUNT || stru_723290
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
| 1 || 4 || T0_MODE || stru_723308
 
|-
==Crazy Taxi check==
| 2 || 4 || T0_MODE || stru_7233E0
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.
| 1 || 4 || T0_COMP || stru_7231A0
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.
| 2 || 4 || T0_COMP || stru_723248
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.
| 1 || 4 || T0_HOLD || stru_723110
 
|-
==CDVD Commands==
| 2 || 4 || T0_HOLD || stru_723128
===Netemu===
|-
<pre>
| 1 || 4 || T1_COUNT || stru_7232F0
4.75 and up.
|-
 
| 2 || 4 || T1_COUNT || stru_7233B0
Supported CDVD N Commands:
|-
 
| 1 || 4 || T1_MODE || stru_723278
opd_ptr  num  name
|-
0x934AB0 0x00: N_CD_NOP
| 2 || 4 || T1_MODE || stru_723260
0x934AB8 0x01: N_CD_RESET
|-
0x934AC0 0x02: N_CD_STANDBY
| 1 || 4 || T1_COMP || stru_723140
0x934AC8 0x03: N_CD_STOP
|-
0x934AD0 0x04: N_CD_PAUSE
| 2 || 4 || T1_COMP || stru_723380
0x934AD8 0x05: N_CD_SEEK
|-
0x934AE0 0x06: N_CD_READ
| 1 || 4 || T1_HOLD || stru_7231E8
0x934AE8 0x07: N_CD_READ_CDDA
|-
0x934AF0 0x08: N_DVD_READ
| 2 || 4 || T1_HOLD || stru_723200
0x934AF8 0x09: N_CD_GET_TOC
|-
0x934B00 0x0A: N_CMD_A                      panic
| 1 || 4 || T2_COUNT || stru_7232D8
0x934B08 0x0B: N_CMD_B                      panic
|-
0x934B10 0x0C: N_CD_READ_KEY
| 2 || 4 || T2_COUNT || stru_723398
0x934B18 0x0D: N_CMD_D                      panic
|-
any command above 0x0D                      panic
| 1 || 4 || T2_MODE || stru_723338
 
|-
Supported CDVD S Commands:
| 2 || 4 || T2_MODE || stru_723410
 
|-
opd_ptr  num  name
| 1 || 4 || T2_COMP || stru_7231D0
0x934B20 0x00: SCMD_Return_0
|-
0x934B28 0x01: SCMD_GetDiscType            panic
| 2 || 4 || T2_COMP || stru_723368
0x934B30 0x02: SCMD_CdReadSubQ              panic
|-
0x934B38 0x03: SCMD_Mecacon_command        (support 0x00, 0x01 ,0x30, 0x45 sub cmds)
| 1 || 4 || T3_COUNT || stru_7232C0
0x934B40 0x04: SCMD_0x04                    panic
|-
0x934B48 0x05: SCMD_CdTrayReqState
| 2 || 4 || T3_COUNT || stru_7233C8
0x934B50 0x06: SCMD_CdTrayCtrl
|-
0x934B58 0x07: SCMD_0x07                    panic
| 1 || 4 || T3_MODE || stru_723320
0x934B60 0x08: SCMD_CdReadRTC
|-
0x934B68 0x09: SCMD_sceCdWriteRTC
| 2 || 4 || T3_MODE || stru_7233F8
0x934B70 0x0A: SCMD_sceCdReadNVM            panic
|-
0x934B78 0x0B: SCMD_sceCdWriteNVM          panic
| 1 || 4 || T3_COMP || stru_7231B8
0x934B80 0x0C: SCMD_0x0C                    panic
|-
0x934B88 0x0D: SCMD_0x0D                    panic
| 2 || 4 || T3_COMP || stru_723350
0x934B90 0x0E: SCMD_0x0E                    panic
|-
0x934B98 0x0F: SCMD_sceCdPowerOff
| 1 || 8 || IPU_CMD || stru_721910
0x934BA0 0x10: SCMD_0x10                    panic
|-
0x934BA8 0x11: SCMD_0x11                    panic
| 2 || 8 || IPU_CMD || stru_7218F8
0x934BB0 0x12: SCMD_sceCdReadILinkId        return zeroed iLinkId
|-
0x934BB8 0x13: SCMD_sceCdWriteILinkID      panic
| 1 || 4 || IPU_CTRL || stru_721970
0x934BC0 0x14: SCMD_CdCtrlAudioDigitalOut  panic
|-
0x934BC8 0x15: SCMD_sceCdForbidDVDP
| 2 || 4 || IPU_CTRL || stru_721958
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..)
| 1 || 4 || IPU_BP || stru_721940
0x934BE0 0x18: SCMD_CdWriteModelNumber      panic
|-
0x934BE8 0x19: SCMD_0x19                    panic
| 1 || 8 || IPU_TOP || stru_721928
0x934BF0 0x1A: SCMD_sceCdBootCertify
|-
0x934BF8 0x1B: SCMD_sceCdCancelPOffRdy
| 2 || 4 || GIF_CTRL || stru_7220C0
0x934C00 0x1C: SCMD_sceCdBlueLEDCtl
|-
0x934C08 0x1D: SCMD_cdvdman_call116
| 2 || 4 || GIF_MODE || stru_7220A8
0x934C10 0x1E: SCMD_sceRemote2Read
|-
0x934C18 0x1F: SCMD_sceRemote2_7
| 1 || 4 || GIF_STAT || stru_722000
0x934C20 0x20: SCMD_Return_0
|-
0x934C28 0x21: SCMD_Return_0
| 1 || 4 || GIF_TAG0 || stru_721EB0
0x934C30 0x22: SCMD_Return_0
|-
0x934C38 0x23: SCMD_Return_0
| 1 || 4 || GIF_TAG1 || stru_721FE8
0x934C40 0x24: SCMD_Return_0
|-
0x934C48 0x25: SCMD_Return_0
| 1 || 4 || GIF_TAG2 || stru_721FD0
0x934C50 0x26: SCMD_Return_0
|-
0x934C58 0x27: SCMD_Return_0
| 1 || 4 || GIF_TAG3 || stru_721FB8
0x934C60 0x28: SCMD_Return_0
|-
0x934C68 0x29: SCMD_sceCdNoticeGameStart    panic
| 1 || 4 || GIF_CNT || stru_721EC8
0x934C70 0x2A: SCMD_Return_0
|-
0x934C78 0x2B: SCMD_Return_0
| 1 || 4 || GIF_P3CNT || stru_721EE0
0x934C80 0x2C: SCMD_Return_0
|-
0x934C88 0x2D: SCMD_Return_0
| 1 || 4 || GIF_P3TAG || stru_721EF8
0x934C90 0x2E: SCMD_Return_0
|-
0x934C98 0x2F: SCMD_Return_0
| 1 || 4 || VIF0_STAT || stru_721820
0x934CA0 0x30: SCMD_Return_0
|-
0x934CA8 0x31: SCMD_Return_0
| 2 || 4 || VIF0_FBRST || stru_721868
0x934CB0 0x32: SCMD_Return_0
|-
0x934CB8 0x33: SCMD_Return_0
| 1 || 4 || VIF0_ERR || stru_7217A8
0x934CC0 0x34: SCMD_Return_0
|-
0x934CC8 0x35: SCMD_Return_0
| 2 || 4 || VIF0_ERR || stru_721598
0x934CD0 0x36: SCMD_Return_0
|-
0x934CD8 0x37: SCMD_Return_0
| 1 || 4 || VIF0_MARK || stru_721790
0x934CE0 0x38: SCMD_Return_0
|-
0x934CE8 0x39: SCMD_Return_0
| 2 || 4 || VIF0_MARK || stru_7215B0
0x934CF0 0x3A: SCMD_Return_0
|-
0x934CF8 0x3B: SCMD_Return_0
| 1 || 4 || VIF0_CYCLE || stru_721778
0x934D00 0x3C: SCMD_Return_0
|-
0x934D08 0x3D: SCMD_Return_0
| 1 || 4 || VIF0_MODE || stru_721760
0x934D10 0x3E: SCMD_Return_0
|-
0x934D18 0x3F: SCMD_Return_0
| 1 || 4 || VIF0_NUM || stru_721748
0x934D20 0x40: SCMD_CdOpenConfig
|-
0x934D28 0x41: SCMD_CdReadConfig
| 1 || 4 || VIF0_MASK || stru_721730
0x934D30 0x42: SCMD_CdWriteConfig
|-
0x934D38 0x43: SCMD_CdCloseConfig
| 1 || 4 || VIF0_CODE || stru_721718
0x934D40 0x44: SCMD_Return_0
|-
0x934D48 0x45: SCMD_Return_0
| 1 || 4 || VIF0_ITOPS || stru_721700
0x934D50 0x46: SCMD_Return_0
|-
0x934D58 0x47: SCMD_Return_0
| 1 || 4 || VIF0_ITOP || stru_7216E8
0x934D60 0x48: SCMD_Return_0
|-
0x934D68 0x49: SCMD_Return_0
| 1 || 4 || VIF0_R0 || stru_7216D0
0x934D70 0x4A: SCMD_Return_0
|-
0x934D78 0x4B: SCMD_Return_0
| 1 || 4 || VIF0_R1 || stru_7216B8
0x934D80 0x4C: SCMD_Return_0
|-
0x934D88 0x4D: SCMD_Return_0
| 1 || 4 || VIF0_R2 || stru_7216A0
0x934D90 0x4E: SCMD_Return_0
|-
0x934D98 0x4F: SCMD_Return_0
| 1 || 4 || VIF0_R3 || stru_721688
0x934DA0 0x50: SCMD_Return_0
|-
0x934DA8 0x51: SCMD_Return_0
| 1 || 4 || VIF0_C0 || stru_721670
0x934DB0 0x52: SCMD_Return_0
|-
0x934DB8 0x53: SCMD_Return_0
| 1 || 4 || VIF0_C1 || stru_721658
0x934DC0 0x54: SCMD_Return_0
|-
0x934DC8 0x55: SCMD_Return_0
| 1 || 4 || VIF0_C2 || stru_721640
0x934DD0 0x56: SCMD_Return_0
|-
0x934DD8 0x57: SCMD_Return_0
| 1 || 4 || VIF0_C3 || stru_721628
0x934DE0 0x58: SCMD_Return_0
|-
0x934DE8 0x59: SCMD_Return_0
| 1 || 4 || VIF1_STAT || stru_722960
0x934DF0 0x5A: SCMD_Return_0
|-
0x934DF8 0x5B: SCMD_Return_0
| 2 || 4 || VIF1_STAT || stru_722618
0x934E00 0x5C: SCMD_Return_0
|-
0x934E08 0x5D: SCMD_Return_0
| 2 || 4 || VIF1_FBRST || stru_722A98
0x934E10 0x5E: SCMD_Return_0
|-
0x934E18 0x5F: SCMD_Return_0
| 1 || 4 || VIF1_ERR || stru_722948
0x934E20 0x60: SCMD_Return_0
|-
0x934E28 0x61: SCMD_Return_0
| 2 || 4 || VIF1_ERR || stru_722630
0x934E30 0x62: SCMD_Return_0
|-
0x934E38 0x63: SCMD_Return_0
| 1 || 4 || VIF1_MARK || stru_722930
0x934E40 0x64: SCMD_Return_0
|-
0x934E48 0x65: SCMD_Return_0
| 2 || 4 || VIF1_MARK || stru_722648
0x934E50 0x66: SCMD_Return_0
|-
0x934E58 0x67: SCMD_Return_0
| 1 || 4 || VIF1_CYCLE || stru_722918
0x934E60 0x68: SCMD_Return_0
|-
0x934E68 0x69: SCMD_Return_0
| 1 || 4 || VIF1_MODE || stru_722900
0x934E70 0x6A: SCMD_Return_0
|-
0x934E78 0x6B: SCMD_Return_0
| 1 || 4 || VIF1_NUM || stru_7228E8
0x934E80 0x6C: SCMD_Return_0
|-
0x934E88 0x6D: SCMD_Return_0
| 1 || 4 || VIF1_MASK || stru_7228D0
0x934E90 0x6E: SCMD_Return_0
|-
0x934E98 0x6F: SCMD_Return_0
| 1 || 4 || VIF1_CODE || stru_7228B8
0x934EA0 0x70: SCMD_Return_0
|-
0x934EA8 0x71: SCMD_Return_0
| 1 || 4 || VIF1_ITOPS || stru_7228A0
0x934EB0 0x72: SCMD_Return_0
|-
0x934EB8 0x73: SCMD_Return_0
| 1 || 4 || VIF1_BASE || stru_722888
0x934EC0 0x74: SCMD_Return_0
|-
0x934EC8 0x75: SCMD_Return_0
| 1 || 4 || VIF1_OFST || stru_722870
0x934ED0 0x76: SCMD_Return_0
|-
0x934ED8 0x77: SCMD_Return_0
| 1 || 4 || VIF1_TOPS || stru_722858
0x934EE0 0x78: SCMD_Return_0
|-
0x934EE8 0x79: SCMD_Return_0
| 1 || 4 || VIF1_ITOP || stru_722840
0x934EF0 0x7A: SCMD_Return_0
|-
0x934EF8 0x7B: SCMD_Return_0
| 1 || 4 || VIF1_TOP || stru_722828
0x934F00 0x7C: SCMD_Return_0
|-
0x934F08 0x7D: SCMD_Return_0
| 1 || 4 || VIF1_R0 || stru_722810
0x934F10 0x7E: SCMD_Return_0
|-
0x934F18 0x7F: SCMD_Return_0
| 1 || 4 || VIF1_R1 || stru_7227F8
0x934F20 0x80: SCMD__mechacon_auth_0x80
|-
0x934F28 0x81: SCMD__mechacon_auth_0x81
| 1 || 4 || VIF1_R2 || stru_7227E0
0x934F30 0x82: SCMD__mechacon_auth_0x82
|-
0x934F38 0x83: SCMD__mechacon_auth_0x83
| 1 || 4 || VIF1_R3 || stru_7227C8
0x934F40 0x84: SCMD__mechacon_auth_0x84
|-
0x934F48 0x85: SCMD__mechacon_auth_0x85
| 1 || 4 || VIF1_C0 || stru_7227B0
0x934F50 0x86: SCMD__mechacon_auth_0x86
|-
0x934F58 0x87: SCMD__mechacon_auth_0x87
| 1 || 4 || VIF1_C1 || stru_722798
0x934F60 0x88: SCMD__mechacon_auth_0x88
|-
0x934F68 0x89: SCMD_Return_0
| 1 || 4 || VIF1_C2 || stru_722780
0x934F70 0x8A: SCMD_Return_0
|-
0x934F78 0x8B: SCMD_Return_0
| 1 || 4 || VIF1_C3 || stru_722768
0x934F80 0x8C: SCMD_Return_0
|-
0x934F88 0x8D: SCMD_Return_0
| 2 || 0x10 || VIF0_FIFO || stru_721850
0x934F90 0x8E: SCMD_Return_0
|-
0x934F98 0x8F: SCMD__mechacon_auth_0x8F
| 1 || 0x10 || VIF1_FIFO || stru_722678
 
|-
Notes:
| 2 || 0x10 || VIF1_FIFO || stru_722AB0
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.
| 2 || 0x10 || GIF_FIFO || stru_722B40
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.
| 1 || 0x10 || IPU_Out_FIFO || stru_7238A8
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.
| 2 || 0x10 || IPU_In_FIFO || stru_723890
</pre>
|-
 
| 1 || 4 || D0_CHCR || stru_721610
==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.
| 2 || 4 || D0_CHCR || stru_721880
===Netemu===
|-
Address in memory | r5900 register
| 1 || 4 || D0_MADR || stru_721508
FFFFFFFFFFFF8980  | 5900_zero_upper64bits
|-
FFFFFFFFFFFF8988  | 5900_zero_lower64bits
| 2 || 4 || D0_MADR || stru_721520
FFFFFFFFFFFF8990  | 5900_at_reg_upper64
|-
FFFFFFFFFFFF8998  | 5900_at_reg_lower64
| 1 || 4 || D0_QWC || stru_721808
FFFFFFFFFFFF89A0  | 5900_v0_reg_upper64
|-
FFFFFFFFFFFF89A8  | 5900_v0_reg_lower64
| 2 || 4 || D0_QWC || stru_721538
FFFFFFFFFFFF89B0  | 5900_v1_reg_upper64
|-
FFFFFFFFFFFF89B8  | 5900_v1_reg_lower64
| 1 || 4 || D0_TADR || stru_7217F0
FFFFFFFFFFFF89C0  | 5900_a0_reg_upper64
|-
FFFFFFFFFFFF89C8  | 5900_a0_reg_lower64
| 2 || 4 || D0_TADR || stru_721550
FFFFFFFFFFFF89D0  | 5900_a1_reg_upper64
|-
FFFFFFFFFFFF89D8  | 5900_a1_reg_lower64
| 1 || 4 || D0_ASR0 || stru_7217D8
FFFFFFFFFFFF89E0  | 5900_a2_reg_upper64
|-
FFFFFFFFFFFF89E8  | 5900_a2_reg_lower64
| 2 || 4 || D0_ASR0 || stru_721568
FFFFFFFFFFFF89F0  | 5900_a3_reg_upper64
|-
FFFFFFFFFFFF89F8  | 5900_a3_reg_lower64
| 1 || 4 || D0_ASR1 || stru_7217C0
FFFFFFFFFFFF8A00  | 5900_t0_reg_upper64
|-
FFFFFFFFFFFF8A08  | 5900_t0_reg_lower64
| 2 || 4 || D0_ASR1 || stru_721580
FFFFFFFFFFFF8A10  | 5900_t1_reg_upper64
|-
FFFFFFFFFFFF8A18  | 5900_t1_reg_lower64
| 1 || 4 || D1_CHCR || stru_722690
FFFFFFFFFFFF8A20  | 5900_t2_reg_upper64
|-
FFFFFFFFFFFF8A28  | 5900_t2_reg_lower64
| 2 || 4 || D1_CHCR || stru_722A68
FFFFFFFFFFFF8A30  | 5900_t3_reg_upper64
|-
FFFFFFFFFFFF8A38  | 5900_t3_reg_lower64
| 1 || 4 || D1_MADR || stru_722A50
FFFFFFFFFFFF8A40  | 5900_t4_reg_upper64
|-
FFFFFFFFFFFF8A48  | 5900_t4_reg_lower64
| 2 || 4 || D1_MADR || stru_722750
FFFFFFFFFFFF8A50  | 5900_t5_reg_upper64
|-
FFFFFFFFFFFF8A58  | 5900_t5_reg_lower64
| 1 || 4 || D1_QWC || stru_722A38
FFFFFFFFFFFF8A60  | 5900_t6_reg_upper64
|-
FFFFFFFFFFFF8A68  | 5900_t6_reg_lower64
| 2 || 4 || D1_QWC || stru_722738
FFFFFFFFFFFF8A70  | 5900_t7_reg_upper64
|-
FFFFFFFFFFFF8A78  | 5900_t7_reg_lower64
| 1 || 4 || D1_TADR || stru_722A20
FFFFFFFFFFFF8A80  | 5900_s0_reg_upper64
|-
FFFFFFFFFFFF8A88  | 5900_s0_reg_lower64
| 2 || 4 || D1_TADR || stru_722720
FFFFFFFFFFFF8A90  | 5900_s1_reg_upper64
|-
FFFFFFFFFFFF8A98  | 5900_s1_reg_lower64
| 1 || 4 || D1_ASR0 || stru_722A08
FFFFFFFFFFFF8AA0  | 5900_s2_reg_upper64
|-
FFFFFFFFFFFF8AA8  | 5900_s2_reg_lower64
| 2 || 4 || D1_ASR0 || stru_722708
FFFFFFFFFFFF8AB0  | 5900_s3_reg_upper64
|-
FFFFFFFFFFFF8AB8  | 5900_s3_reg_lower64
| 1 || 4 || D1_ASR1 || stru_7229F0
FFFFFFFFFFFF8AC0  | 5900_s4_reg_upper64
|-
FFFFFFFFFFFF8AC8  | 5900_s4_reg_lower64
| 2 || 4 || D1_ASR1 || stru_7226F0
FFFFFFFFFFFF8AD0  | 5900_s5_reg_upper64
|-
FFFFFFFFFFFF8AD8  | 5900_s5_reg_lower64
| 1 || 4 || D2_CHCR || stru_722B28
FFFFFFFFFFFF8AE0  | 5900_s6_reg_upper64
|-
FFFFFFFFFFFF8AE8  | 5900_s6_reg_lower64
| 2 || 4 || D2_CHCR || stru_722B58
FFFFFFFFFFFF8AF0  | 5900_s7_reg_upper64
|-
FFFFFFFFFFFF8AF8  | 5900_s7_reg_lower64
| 1 || 4 || D2_MADR || stru_7229D8
FFFFFFFFFFFF8B00  | 5900_t8_reg_upper64
|-
FFFFFFFFFFFF8B08  | 5900_t8_reg_lower64
| 2 || 4 || D2_MADR || stru_722AE0
FFFFFFFFFFFF8B10  | 5900_t9_reg_upper64
|-
FFFFFFFFFFFF8B18  | 5900_t9_reg_lower64
| 1 || 4 || D2_QWC || stru_7229C0
FFFFFFFFFFFF8B20  | 5900_k0_reg_upper64
|-
FFFFFFFFFFFF8B28  | 5900_k0_reg_lower64
| 2 || 4 || D2_QWC || stru_722AC8
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==
===Netemu===
4.75 and up. Mode (1 = read / 2 = write)
 
{| class="wikitable sortable"
!mode !! size !! PS2_HW_REG !! handler_opd
|-
|-
| 1 || 4 || T0_COUNT || stru_723218
| 1 || 4 || D2_TADR || stru_7229A8
|-
|-
| 2 || 4 || T0_COUNT || stru_723290
| 2 || 4 || D2_TADR || stru_722AF8
|-
|-
| 1 || 4 || T0_MODE || stru_723308
| 1 || 4 || D2_ASR0 || stru_722990
|-
|-
| 2 || 4 || T0_MODE || stru_7233E0
| 2 || 4 || D2_ASR0 || stru_7226D8
|-
|-
| 1 || 4 || T0_COMP || stru_7231A0
| 1 || 4 || D2_ASR1 || stru_722978
|-
|-
| 2 || 4 || T0_COMP || stru_723248
| 2 || 4 || D2_ASR1 || stru_7226C0
|-
|-
| 1 || 4 || T0_HOLD || stru_723110
| 1 || 4 || D3_CHCR || stru_723740
|-
|-
| 2 || 4 || T0_HOLD || stru_723128
| 2 || 4 || D3_CHCR || stru_723800
|-
|-
| 1 || 4 || T1_COUNT || stru_7232F0
| 1 || 4 || D3_MADR || stru_7237D0
|-
|-
| 2 || 4 || T1_COUNT || stru_7233B0
| 2 || 4 || D3_MADR || stru_723878
|-
|-
| 1 || 4 || T1_MODE || stru_723278
| 1 || 4 || D3_QWC || stru_7237B8
|-
|-
| 2 || 4 || T1_MODE || stru_723260
| 2 || 4 || D3_QWC || stru_723860
|-
|-
| 1 || 4 || T1_COMP || stru_723140
| 1 || 4 || D4_CHCR || stru_7237A0
|-
|-
| 2 || 4 || T1_COMP || stru_723380
| 2 || 4 || D4_CHCR || stru_7237E8
|-
|-
| 1 || 4 || T1_HOLD || stru_7231E8
| 1 || 4 || D4_MADR || stru_723788
|-
|-
| 2 || 4 || T1_HOLD || stru_723200
| 2 || 4 || D4_MADR || stru_723848
|-
|-
| 1 || 4 || T2_COUNT || stru_7232D8
| 1 || 4 || D4_QWC || stru_723770
|-
|-
| 2 || 4 || T2_COUNT || stru_723398
| 2 || 4 || D4_QWC || stru_723830
|-
|-
| 1 || 4 || T2_MODE || stru_723338
| 1 || 4 || D4_TADR || stru_723758
|-
|-
| 2 || 4 || T2_MODE || stru_723410
| 2 || 4 || D4_TADR || stru_723818
|-
|-
| 1 || 4 || T2_COMP || stru_7231D0
| 1 || 4 || D5_CHCR || stru_722498
|-
|-
| 2 || 4 || T2_COMP || stru_723368
| 2 || 4 || D5_CHCR || stru_7224C8
|-
|-
| 1 || 4 || T3_COUNT || stru_7232C0
| 1 || 4 || D5_MADR || stru_722408
|-
|-
| 2 || 4 || T3_COUNT || stru_7233C8
| 2 || 4 || D5_MADR || stru_722390
|-
|-
| 1 || 4 || T3_MODE || stru_723320
| 1 || 4 || D5_QWC || stru_722468
|-
|-
| 2 || 4 || T3_MODE || stru_7233F8
| 2 || 4 || D5_QWC || stru_7223F0
|-
|-
| 1 || 4 || T3_COMP || stru_7231B8
| 1 || 4 || D6_CHCR || stru_722480
|-
|-
| 2 || 4 || T3_COMP || stru_723350
| 2 || 4 || D6_CHCR || stru_7224B0
|-
|-
| 1 || 8 || IPU_CMD || stru_721910
| 1 || 4 || D6_MADR || stru_722450
|-
|-
| 2 || 8 || IPU_CMD || stru_7218F8
| 2 || 4 || D6_MADR || stru_7223D8
|-
|-
| 1 || 4 || IPU_CTRL || stru_721970
| 1 || 4 || D6_QWC || stru_722420
|-
|-
| 2 || 4 || IPU_CTRL || stru_721958
| 2 || 4 || D6_QWC || stru_7223A8
|-
|-
| 1 || 4 || IPU_BP || stru_721940
| 1 || 4 || unk_1000C430 || stru_722438
|-
|-
| 1 || 8 || IPU_TOP || stru_721928
| 2 || 4 || unk_1000C430 || stru_7223C0
|-
|-
| 2 || 4 || GIF_CTRL || stru_7220C0
| 1 || 4 || D7_CHCR || stru_7235C0
|-
|-
| 2 || 4 || GIF_MODE || stru_7220A8
| 2 || 4 || D7_CHCR || stru_723530
|-
|-
| 1 || 4 || GIF_STAT || stru_722000
| 1 || 4 || D7_MADR || stru_7235A8
|-
|-
| 1 || 4 || GIF_TAG0 || stru_721EB0
| 2 || 4 || D7_MADR || stru_723500
|-
|-
| 1 || 4 || GIF_TAG1 || stru_721FE8
| 1 || 4 || D7_QWC || stru_723590
|-
|-
| 1 || 4 || GIF_TAG2 || stru_721FD0
| 2 || 4 || D7_QWC || stru_723518
|-
|-
| 1 || 4 || GIF_TAG3 || stru_721FB8
| 1 || 4 || D8_CHCR || stru_7222D0
|-
|-
| 1 || 4 || GIF_CNT || stru_721EC8
| 2 || 4 || D8_CHCR || stru_7222E8
|-
|-
| 1 || 4 || GIF_P3CNT || stru_721EE0
| 1 || 4 || D8_MADR || stru_7222B8
|-
|-
| 1 || 4 || GIF_P3TAG || stru_721EF8
| 2 || 4 || D8_MADR || stru_722168
|-
|-
| 1 || 4 || VIF0_STAT || stru_721820
| 1 || 4 || D8_QWC || stru_7222A0
|-
|-
| 2 || 4 || VIF0_FBRST || stru_721868
| 2 || 4 || D8_QWC || stru_722180
|-
|-
| 1 || 4 || VIF0_ERR || stru_7217A8
| 1 || 4 || D8_SADR || stru_722288
|-
|-
| 2 || 4 || VIF0_ERR || stru_721598
| 2 || 4 || D8_SADR || stru_722198
|-
|-
| 1 || 4 || VIF0_MARK || stru_721790
| 1 || 4 || D9_CHCR || stru_722270
|-
|-
| 2 || 4 || VIF0_MARK || stru_7215B0
| 2 || 4 || D9_CHCR || stru_722318
|-
|-
| 1 || 4 || VIF0_CYCLE || stru_721778
| 1 || 4 || D9_MADR || stru_722258
|-
|-
| 1 || 4 || VIF0_MODE || stru_721760
| 2 || 4 || D9_MADR || stru_7221F8
|-
|-
| 1 || 4 || VIF0_NUM || stru_721748
| 1 || 4 || D9_QWC || stru_722240
|-
|-
| 1 || 4 || VIF0_MASK || stru_721730
| 2 || 4 || D9_QWC || stru_7221B0
|-
|-
| 1 || 4 || VIF0_CODE || stru_721718
| 1 || 4 || D9_TADR || stru_722228
|-
|-
| 1 || 4 || VIF0_ITOPS || stru_721700
| 2 || 4 || D9_TADR || stru_7221E0
|-
|-
| 1 || 4 || VIF0_ITOP || stru_7216E8
| 1 || 4 || D9_SADR || stru_722210
|-
|-
| 1 || 4 || VIF0_R0 || stru_7216D0
| 2 || 4 || D9_SADR || stru_7221C8
|-
|-
| 1 || 4 || VIF0_R1 || stru_7216B8
| 1 || 4 || D_CTRL || stru_721C28
|-
|-
| 1 || 4 || VIF0_R2 || stru_7216A0
| 2 || 4 || D_CTRL || stru_721C70
|-
|-
| 1 || 4 || VIF0_R3 || stru_721688
| 1 || 4 || D_STAT || stru_724130
|-
|-
| 1 || 4 || VIF0_C0 || stru_721670
| 2 || 4 || D_STAT || stru_7241A8
|-
|-
| 1 || 4 || VIF0_C1 || stru_721658
| 1 || 4 || D_PCR || stru_724100
|-
|-
| 1 || 4 || VIF0_C2 || stru_721640
| 2 || 4 || D_PCR || stru_7240E8
|-
|-
| 1 || 4 || VIF0_C3 || stru_721628
| 1 || 4 || D_SQWC || stru_722138
|-
|-
| 1 || 4 || VIF1_STAT || stru_722960
| 2 || 4 || D_SQWC || stru_722150
|-
|-
| 2 || 4 || VIF1_STAT || stru_722618
| 1 || 4 || D_RBSR || stru_721BF8
|-
|-
| 2 || 4 || VIF1_FBRST || stru_722A98
| 2 || 4 || D_RBSR || stru_721B68
|-
|-
| 1 || 4 || VIF1_ERR || stru_722948
| 1 || 4 || D_RBOR || stru_721B80
|-
|-
| 2 || 4 || VIF1_ERR || stru_722630
| 2 || 4 || D_RBOR || stru_721B98
|-
|-
| 1 || 4 || VIF1_MARK || stru_722930
| 1 || 4 || D_STADR || stru_721C40
|-
|-
| 2 || 4 || VIF1_MARK || stru_722648
| 2 || 4 || D_STADR || stru_721BB0
|-
|-
| 1 || 4 || VIF1_CYCLE || stru_722918
| 1 || 4 || INTC_STAT || stru_724148
|-
|-
| 1 || 4 || VIF1_MODE || stru_722900
| 2 || 4 || INTC_STAT || stru_7241C0
|-
|-
| 1 || 4 || VIF1_NUM || stru_7228E8
| 1 || 4 || INTC_MASK || stru_724118
|-
|-
| 1 || 4 || VIF1_MASK || stru_7228D0
| 2 || 4 || INTC_MASK || stru_724160
|-
|-
| 1 || 4 || VIF1_CODE || stru_7228B8
| 2 || 4 || KPUTCHAR || stru_723B30
|-
|-
| 1 || 4 || VIF1_ITOPS || stru_7228A0
| 1 || 4 || MSCOM || stru_723578
|-
|-
| 1 || 4 || VIF1_BASE || stru_722888
| 2 || 4 || MSCOM || stru_723548
|-
|-
| 1 || 4 || VIF1_OFST || stru_722870
| 1 || 4 || SMCOM || stru_723560
|-
|-
| 1 || 4 || VIF1_TOPS || stru_722858
| 1 || 4 || MSFLAG || stru_723620
|-
|-
| 1 || 4 || VIF1_ITOP || stru_722840
| 2 || 4 || MSFLAG || stru_723680
|-
|-
| 1 || 4 || VIF1_TOP || stru_722828
| 1 || 4 || SMFLAG || stru_723608
|-
|-
| 1 || 4 || VIF1_R0 || stru_722810
| 2 || 4 || SMFLAG || stru_723668
|-
|-
| 1 || 4 || VIF1_R1 || stru_7227F8
| 1 || 4 || SIF_CR || stru_7235F0
|-
|-
| 1 || 4 || VIF1_R2 || stru_7227E0
| 2 || 4 || SIF_CR || stru_723650
|-
|-
| 1 || 4 || VIF1_R3 || stru_7227C8
| 1 || 4 || unk_1000F260 || stru_7235D8
|-
|-
| 1 || 4 || VIF1_C0 || stru_7227B0
| 2 || 4 || unk_1000F260 || stru_723638
|-
|-
| 1 || 4 || VIF1_C1 || stru_722798
| 1 || 4 || unk_1000F280 || stru_723428
|-
|-
| 1 || 4 || VIF1_C2 || stru_722780
| 2 || 4 || unk_1000F280 || stru_723440
|-
|-
| 1 || 4 || VIF1_C3 || stru_722768
| 1 || 4 || unk_1000F290 || stru_723458
|-
|-
| 2 || 0x10 || VIF0_FIFO || stru_721850
| 1 || 4 || unk_1000F2A0 || stru_723470
|-
|-
| 1 || 0x10 || VIF1_FIFO || stru_722678
| 2 || 4 || unk_1000F2A0 || stru_723488
|-
|-
| 2 || 0x10 || VIF1_FIFO || stru_722AB0
| 1 || 4 || unk_1000F2B0 || stru_7234A0
|-
|-
| 2 || 0x10 || GIF_FIFO || stru_722B40
| 2 || 4 || unk_1000F2B0 || stru_7234B8
|-
|-
| 1 || 0x10 || IPU_Out_FIFO || stru_7238A8
| 1 || 4 || unk_1000F2C0 || stru_7234D0
|-
|-
| 2 || 0x10 || IPU_In_FIFO || stru_723890
| 2 || 4 || unk_1000F2C0 || stru_7234E8
|-
|-
| 1 || 4 || D0_CHCR || stru_721610
| 1 || 4 || D_ENABLER || stru_721C10
|-
|-
| 2 || 4 || D0_CHCR || stru_721880
| 2 || 4 || D_ENABLEW || stru_721C58
|-
|-
| 1 || 4 || D0_MADR || stru_721508
| 1 || 8 || unk_1000F800 || stru_7250C0
|-
|-
| 2 || 4 || D0_MADR || stru_721520
| 2 || 8 || unk_1000F800 || stru_7250D8
|-
|-
| 1 || 4 || D0_QWC || stru_721808
| 1 || 8 || unk_1000F810 || stru_725150
|-
|-
| 2 || 4 || D0_QWC || stru_721538
| 1 || 0x10 || unk_1000F820 || stru_7250F0
|-
|-
| 1 || 4 || D0_TADR || stru_7217F0
| 1 || 0x10 || unk_1000F830 || stru_725108
|-
|-
| 2 || 4 || D0_TADR || stru_721550
| 1 || 4 || unk_1000F860 || stru_725120
|-
|-
| 1 || 4 || D0_ASR0 || stru_7217D8
| 1 || 4 || unk_1000F880 || stru_725138
|-
|-
| 2 || 4 || D0_ASR0 || stru_721568
| 1 || 4 || unk_1000F8B0 || stru_725168
|-
|-
| 1 || 4 || D0_ASR1 || stru_7217C0
| 2 || 8 || PMODE || stru_721E20
|-
|-
| 2 || 4 || D0_ASR1 || stru_721580
| 2 || 8 || SMODE1 || stru_722060
|-
|-
| 1 || 4 || D1_CHCR || stru_722690
| 2 || 8 || SMODE2 || stru_721F88
|-
|-
| 2 || 4 || D1_CHCR || stru_722A68
| 2 || 8 || SRFSH || stru_721E38
|-
|-
| 1 || 4 || D1_MADR || stru_722A50
| 2 || 8 || SYNCH1 || stru_721F70
|-
|-
| 2 || 4 || D1_MADR || stru_722750
| 2 || 8 || SYNCH2 || stru_721F58
|-
|-
| 1 || 4 || D1_QWC || stru_722A38
| 2 || 8 || SYNCV || stru_721F40
|-
|-
| 2 || 4 || D1_QWC || stru_722738
| 2 || 8 || DISPFB1 || stru_7220F0
|-
|-
| 1 || 4 || D1_TADR || stru_722A20
| 2 || 8 || DISPLAY1 || stru_722018
|-
|-
| 2 || 4 || D1_TADR || stru_722720
| 2 || 8 || DISPFB2 || stru_7220D8
|-
|-
| 1 || 4 || D1_ASR0 || stru_722A08
| 2 || 8 || DISPLAY2 || stru_722078
|-
|-
| 2 || 4 || D1_ASR0 || stru_722708
| 2 || 8 || EXTBUF || stru_721E50
|-
|-
| 1 || 4 || D1_ASR1 || stru_7229F0
| 2 || 8 || EXTDATA || stru_721E68
|-
|-
| 2 || 4 || D1_ASR1 || stru_7226F0
| 2 || 8 || EXTWRITE || stru_721E80
|-
|-
| 1 || 4 || D2_CHCR || stru_722B28
| 2 || 8 || BGCOLOR || stru_721E98
|-
|-
| 2 || 4 || D2_CHCR || stru_722B58
| 1 || 8 || GS_CSR || stru_722090
|-
|-
| 1 || 4 || D2_MADR || stru_7229D8
| 2 || 8 || GS_CSR || stru_722120
|-
|-
| 2 || 4 || D2_MADR || stru_722AE0
| 2 || 8 || GS_IMR || stru_722108
|-
|-
| 1 || 4 || D2_QWC || stru_7229C0
| 2 || 8 || BUSDIR || stru_721FA0
|-
|-
| 2 || 4 || D2_QWC || stru_722AC8
| 1 || 8 || SIGLBLID || stru_722030
|-
|-
| 1 || 4 || D2_TADR || stru_7229A8
| 2 || 8 || SIGLBLID || stru_722048
|-
|-
| 2 || 4 || D2_TADR || stru_722AF8
|}
|-
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.
| 1 || 4 || D2_ASR0 || stru_722990
* 1000F800 do nothing (blr). Have own handler, which suggest it was used for something earlier. [r/w]
|-
* 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] 
| 2 || 4 || D2_ASR0 || stru_7226D8
* 1000F820 return "DrJock TV Quiz P" [r only]
|-
* 1000F830 return "hD bags few lynx" [r only]
| 1 || 4 || D2_ASR1 || stru_722978
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]
| 2 || 4 || D2_ASR1 || stru_7226C0
* 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]
| 1 || 4 || D3_CHCR || stru_723740
 
|-
==Random notes about SPE in ps2_netemu==
| 2 || 4 || D3_CHCR || stru_723800
 
|-
===IOP SPE===
| 1 || 4 || D3_MADR || stru_7237D0
This
|-
SPE run not only dma related stuff, but also fully fledged r3000 instruction interpreter (yes interpreter, not recompiler).
| 2 || 4 || D3_MADR || stru_723878
 
|-
<pre>
| 1 || 4 || D3_QWC || stru_7237B8
  opcode      | address
|-
--------------+-------- 
| 2 || 4 || D3_QWC || stru_723860
r3000_ADDI      0x317C0
|-
r3000_ADDIU    0x31800
| 1 || 4 || D4_CHCR || stru_7237A0
r3000_SLTI      0x31840
|-
r3000_SLTIU    0x31880
| 2 || 4 || D4_CHCR || stru_7237E8
r3000_ANDI      0x318C0
|-
r3000_ORI      0x31900
| 1 || 4 || D4_MADR || stru_723788
r3000_XORI      0x31940
|-
r3000_LUI      0x31980
| 2 || 4 || D4_MADR || stru_723848
r3000_ADD      0x319C0
|-
r3000_ADDU      0x31A00
| 1 || 4 || D4_QWC || stru_723770
r3000_SUB      0x31A40
|-
r3000_SUBU      0x31A80
| 2 || 4 || D4_QWC || stru_723830
r3000_SLT      0x31AC0
|-
r3000_SLTU      0x31B00
| 1 || 4 || D4_TADR || stru_723758
r3000_AND      0x31B40
|-
r3000_OR        0x31B80
| 2 || 4 || D4_TADR || stru_723818
r3000_XOR      0x31BC0
|-
r3000_NOR      0x31C00
| 1 || 4 || D5_CHCR || stru_722498
r3000_SLL      0x31C40
|-
r3000_unk1      0x31C80 Primary opcode field (Bit 26..31) = 0x3E (debug stuff, not existing on real r3000)
| 2 || 4 || D5_CHCR || stru_7224C8
r3000_unk2      0x31CC0 Primary opcode field (Bit 26..31) = 0x3F (debug stuff, not existing on real r3000)
|-
r3000_SRL      0x31D00
| 1 || 4 || D5_MADR || stru_722408
r3000_SRA      0x31D40
|-
r3000_SLLV      0x31D80
| 2 || 4 || D5_MADR || stru_722390
r3000_SRLV      0x31DC0
|-
r3000_SRAV      0x31E00
| 1 || 4 || D5_QWC || stru_722468
r3000_MULT      0x31E40
|-
r3000_MULTU    0x31F00
| 2 || 4 || D5_QWC || stru_7223F0
r3000_DIV      0x31F80
|-
r3000_MFHI      0x32080
| 1 || 4 || D6_CHCR || stru_722480
r3000_MFLO      0x320C0
|-
r3000_MTHI      0x32100
| 2 || 4 || D6_CHCR || stru_7224B0
r3000_MTLO      0x32140
|-
r3000_J        0x32180
| 1 || 4 || D6_MADR || stru_722450
r3000_JAL      0x32200
|-
r3000_JR        0x32280
| 2 || 4 || D6_MADR || stru_7223D8
r3000_JALR      0x322C0
|-
r3000_BEQ      0x32300
| 1 || 4 || D6_QWC || stru_722420
r3000_BNE      0x32340
|-
r3000_BLEZ      0x32380
| 2 || 4 || D6_QWC || stru_7223A8
r3000_BGTZ      0x323C0
|-
r3000_BcondZ    0x32400
| 1 || 4 || unk_1000C430 || stru_722438
r3000_SYSCALL  0x32480
|-
r3000_BREAK    0x324C0
| 2 || 4 || unk_1000C430 || stru_7223C0
r3000_COP_bad  0x32500
|-
r3000_COP0      0x32540
| 1 || 4 || D7_CHCR || stru_7235C0
r3000_bad_op    0x32740
|-
r3000_LB        0x32840
| 2 || 4 || D7_CHCR || stru_723530
r3000_LH        0x32940
|-
r3000_LW        0x32A40
| 1 || 4 || D7_MADR || stru_7235A8
r3000_LBU      0x32B80
|-
r3000_LHU      0x32C80
| 2 || 4 || D7_MADR || stru_723500
r3000_LWL      0x32D80
|-
r3000_LWR      0x32E80
| 1 || 4 || D7_QWC || stru_723590
r3000_SB        0x32F80
|-
r3000_SH        0x33080
| 2 || 4 || D7_QWC || stru_723518
r3000_SW        0x33180
|-
r3000_SWL      0x33300
| 1 || 4 || D8_CHCR || stru_7222D0
r3000_SWR      0x33400
|-
 
| 2 || 4 || D8_CHCR || stru_7222E8
Addresses above ARE NOT the ones in emulator memory, this is local storage address in IOP SPE program!
|-
Opcodes LWCx 0-3, and SWCx 0-3 are not supported at all.
| 1 || 4 || D8_MADR || stru_7222B8
Same goes for general COP 1-3 opcodes, but those cause COPx unusable r3000 exception.
|-
While LWC/SWC are triggering bad opcode exception.
| 2 || 4 || D8_MADR || stru_722168
Not sure if LWC0/SWC0 should be allowed.
|-
COP0 is working in PS2 mode, so those probably shouldn't cause exception.
| 1 || 4 || D8_QWC || stru_7222A0
At the second hand i don't know single IOP module that use that instruction.
|-
</pre>
| 2 || 4 || D8_QWC || stru_722180
 
|-
This is unconfirmed by any code reversing for now, but IOP emulator print messages like:
| 1 || 4 || D8_SADR || stru_722288
Cache write (IOPADDR/LSADDR/SIZE)
|-
Cache read  (IOPADDR/LSADDR/SIZE)
| 2 || 4 || D8_SADR || stru_722198
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.
| 1 || 4 || D9_CHCR || stru_722270
 
|-
===EEDMA on SPE3===
| 2 || 4 || D9_CHCR || stru_722318
That one is one of most misleading names in whole emulator.. <br>
|-
DMA channels are handled in:
| 1 || 4 || D9_MADR || stru_722258
*0 - VIF0 on PPU only
|-
*1 - VIF1 dma, and VIF1 hw reads/writes including fifo write are handled in SPE3 (EEDMA)
| 2 || 4 || D9_MADR || stru_7221F8
*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
| 1 || 4 || D9_QWC || stru_722240
*4 - IPUto dma, and whole ipu HW r/w is handled by SPE6
|-
*5 - SIF0 dma is handled in PPE, and SPE 0 (IOP)
| 2 || 4 || D9_QWC || stru_7221B0
*6 - SIF1 dma is handled in PPE, and SPE 0 (IOP)
|-
*7 - SIF2 dma is handled in PPE, and SPE 0 (IOP)
| 1 || 4 || D9_TADR || stru_722228
*8 - SPRfrom dma is handled on PPE only it seems
|-
*9 - SPRto dma is handled on PPE only it seems
| 2 || 4 || D9_TADR || stru_7221E0
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>
|-
So is more like "Close to GS" DMA handler.
| 1 || 4 || D9_SADR || stru_722210
 
|-
"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)
| 2 || 4 || D9_SADR || stru_7221C8
 
|-
===VU1 emulation on SPE===
| 1 || 4 || D_CTRL || stru_721C28
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>
| 2 || 4 || D_CTRL || stru_721C70
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.
| 1 || 4 || D_STAT || stru_724130
 
|-
In latest ps2_netemu function responsible for translating VU1 code into SPE ready code is located at 0x13C69C
| 2 || 4 || D_STAT || stru_7241A8
<br><br>
|-
SPU registers always follow this layout when VU1 is running:
| 1 || 4 || D_PCR || stru_724100
*r0  - r31 = vf00 - vf31
|-
*r32 - r57 = vi00 - vi25 (vu ctrl regs above vi25 are mapped to vu0 anyway)
| 2 || 4 || D_PCR || stru_7240E8
*r48      = ACC (accessible from VU0 as vi19)
|-
 
| 1 || 4 || D_SQWC || stru_722138
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.
| 2 || 4 || D_SQWC || stru_722150
*0x30004100 = vf16
|-
*0x30004200 = vi00
| 1 || 4 || D_RBSR || stru_721BF8
*0x30004350 = I register (vi21)
|-
etc.
| 2 || 4 || D_RBSR || stru_721B68
 
|-
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).
| 1 || 4 || D_RBOR || stru_721B80
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.
|-
 
| 2 || 4 || D_RBOR || stru_721B98
===IPU SPE6===
|-
====IDEC start code detection====
| 1 || 4 || D_STADR || stru_721C40
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..
| 2 || 4 || D_STADR || stru_721BB0
This probably break Onimusha DoD, and many other random games.
|-
====IPU skip mpeg hack====
| 1 || 4 || INTC_STAT || stru_724148
There are some leftovers of SKIP MPEG hack in SPE 6 (IPU), i'm not sure that is still available.
|-
 
| 2 || 4 || INTC_STAT || stru_7241C0
===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.
| 1 || 4 || INTC_MASK || stru_724118
 
|-
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.<br>
| 2 || 4 || INTC_MASK || stru_724160
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.
|-
 
| 2 || 4 || KPUTCHAR || stru_723B30
==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.
| 1 || 4 || MSCOM || stru_723578
0xD34C    hbrr    loc_D38C, Update_7E98
|-
0xD350    lr      r4, r80
| 2 || 4 || MSCOM || stru_723548
0xD354    lqr      r9, SCANMSK_REG
|-
0xD358    il      r3, 0x22 ; GIF_REG_NR
| 1 || 4 || SMCOM || stru_723560
0xD35C    shlqbyi  r5, r80, 4
|-
0xD360    cwd      r6, 0x30+var_30+0xC(sp)
| 1 || 4 || MSFLAG || stru_723620
0xD364    andi    r5, r5, 3 ;        New SCANMSK write
|-
0xD368    rotqbyi  r8, r9, 0xC
| 2 || 4 || MSFLAG || stru_723680
0xD36C    ceq      r7, r8, r5
|-
0xD370    brnz    r7, return_D390 ;  branch if old SCANMSK == new
| 1 || 4 || SMFLAG || stru_723608
0xD374    lqr      r11, SCANMSK_REG
|-
0xD378    lqd      lr, 0x30+link_reg(sp)
| 2 || 4 || SMFLAG || stru_723668
0xD37C    ai      sp, sp, 0x30
|-
0xD380    lqd      r80, var_10(sp)
| 1 || 4 || SIF_CR || stru_7235F0
0xD384    shufb    r10, r5, r11, r6
|-
0xD388    stqr    r10, SCANMSK_REG
| 2 || 4 || SIF_CR || stru_723650
|-
0xD38C    br      UpdateGS_7E98
| 1 || 4 || unk_1000F260 || stru_7235D8
 
|-
==PS2 masterlist with ps2 emu hashes==
| 2 || 4 || unk_1000F260 || stru_723638
*See: [[PS2_Emulation/PS2_Games_Masterlist]]
|-
 
| 1 || 4 || unk_1000F280 || stru_723428
== ps2_netemu supported video modes ==
|-
 
| 2 || 4 || unk_1000F280 || stru_723440
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. --[[User:Kozarovv|Kozarovv]] ([[User talk:Kozarovv|talk]]) 06:15, 29 March 2022 (UTC)
| 1 || 4 || unk_1000F290 || stru_723458
** 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.<br> 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.<br> 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.--[[User:Agrippa|Agrippa]] ([[User talk:Agrippa|talk]]) 18:03, 30 March 2022 (UTC)
|-
=== Widescreen support ===
| 1 || 4 || unk_1000F2A0 || stru_723470
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,
| 2 || 4 || unk_1000F2A0 || stru_723488
* Upscaler turned on - Normal setting (keep original aspect ratio): no flag is set,
|-
* Upscaler turned on - Full screen setting: widescreen flag set by BIOS.
| 1 || 4 || unk_1000F2B0 || stru_7234A0
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.
|-
 
| 2 || 4 || unk_1000F2B0 || stru_7234B8
== Emu Patches ==
|-
 
| 1 || 4 || unk_1000F2C0 || stru_7234D0
===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!
| 2 || 4 || unk_1000F2C0 || stru_7234E8
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.
| 1 || 4 || D_ENABLER || stru_721C10
<br>https://www.mediafire.com/file/s83lt9zkwlyhpc2/No_Blur.ppf/file
|-
<br><br>MD5 before patch is applied:
| 2 || 4 || D_ENABLEW || stru_721C58
70D22D79A5BB876B8EA2D0FE55D046C7
|-
MD5 after patch is applied:
| 1 || 8 || unk_1000F800 || stru_7250C0
0B632F05371215AA6BE2C976924737AE
|-
Preview:
| 2 || 8 || unk_1000F800 || stru_7250D8
https://ibb.co/9sSjmCm (default netemu)
|-
https://ibb.co/G7t11Nq (No Blur enabled)
| 1 || 8 || unk_1000F810 || stru_725150
 
|-
===Display current PC/RA values for r5900===
| 1 || 0x10 || unk_1000F820 || stru_7250F0
 
|-
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.
| 1 || 0x10 || unk_1000F830 || stru_725108
 
|-
search for (2 times):
| 1 || 4 || unk_1000F860 || stru_725120
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
| 1 || 4 || unk_1000F880 || stru_725138
88 FA 00 02
|-
| 1 || 4 || unk_1000F8B0 || stru_725168
replace to (2 times):
|-
60 00 00 00 60 00 00 00 60 00 00 00 60 00 00 00
| 2 || 8 || PMODE || stru_721E20
60 00 00 00 60 00 00 00 60 00 00 00 80 C0 91 00
|-
80 E0 8B 7C
| 2 || 8 || SMODE1 || stru_722060
|-
search for:
| 2 || 8 || SMODE2 || stru_721F88
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
| 2 || 8 || SRFSH || stru_721E38
B0 43 00
|-
| 2 || 8 || SYNCH1 || stru_721F70
replace to:
|-
50 43 3A 20 25 30 38 58 26 23 78 61 3B 52 41 3A
| 2 || 8 || SYNCH2 || stru_721F58
20 25 30 38 58 00 00 00 00 00 00 00 00 00 00 00
|-
00 00 00
| 2 || 8 || SYNCV || stru_721F40
 
|-
===Skip demo disc check===
| 2 || 8 || DISPFB1 || stru_7220F0
 
|-
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).  
| 2 || 8 || DISPLAY1 || stru_722018
 
|-
ps2_netemu:
| 2 || 8 || DISPFB2 || stru_7220D8
search for
|-
41 9E 03 50 39 80 00 00 54 00 06 3E 54 69 38 30
| 2 || 8 || DISPLAY2 || stru_722078
|-
replace to
| 2 || 8 || EXTBUF || stru_721E50
60 00 00 00 39 80 00 00 54 00 06 3E 54 69 38 30
|-
| 2 || 8 || EXTDATA || stru_721E68
in 4.75+ emu: 0x13356C  beq  cr7, demo_check  ---> nop
|-
   
| 2 || 8 || EXTWRITE || stru_721E80
ps2_gxemu
|-
search for
| 2 || 8 || BGCOLOR || stru_721E98
41 9E 04 50 78 E0 FE A2 78 C9 F6 E2 54 C6 30 32
|-
| 1 || 8 || GS_CSR || stru_722090
replace to
|-
60 00 00 00 78 E0 FE A2 78 C9 F6 E2 54 C6 30 32
| 2 || 8 || GS_CSR || stru_722120
|-
in 4.75+ emu: 0x8EEA0  beq  cr7, demo_check  ---> nop
| 2 || 8 || GS_IMR || stru_722108
 
|-
===Extend config table by 50% in ps2_gxemu===
| 2 || 8 || BUSDIR || stru_721FA0
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.  
| 1 || 8 || SIGLBLID || stru_722030
 
|-
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.
| 2 || 8 || SIGLBLID || stru_722048
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.
|-
 
|}
Now:
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.
hash      00 00 00 FF FF FF FF FF
* 1000F800 do nothing (blr). Have own handler, which suggest it was used for something earlier. [r/w]
pointer  00 00 00 00 FF FF FF FF
* 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]  
cmd count FF FF FF FF
* 1000F820 return "DrJock TV Quiz P" [r only]
align    00 00 00 00 (previously we thought that is terminator)
* 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.  
* 1000F860 seems to return halfword of current pad state (0xFFFF if there is no button input currently). [r only]
* 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==
Compacted:
hash      00 00 00 FF FF FF FF FF
pointer  FF FF FF FF
cmd count FF FF FF FF


===IOP SPE===
We have reduced size from 0x18 to 0x10 for single title without losing any data, free 1576 bytes to use :) .
This
After that i wrote small dumper that allowed me to edit table in easy way to recreate new table with empty slots.
SPE run not only dma related stuff, but also fully fledged r3000 instruction interpreter (yes interpreter, not recompiler).
Hardest part behind us, now just patches to respect new table elements size, and we are done.


<pre>
4.88.2 Evilnat ps2_gxemu.elf offsets:
  opcode      | address
0x6F938: 38 00 03 14 --> 38 00 04 9E  (increase loop count)
--------------+--------  
0x6F950: 39 29 00 18 --> 39 29 00 10 (decrease step incrementer)
r3000_ADDI      0x317C0
0x6F968: 79 59 2E A4
r3000_ADDIU    0x31800
          79 5A 1F 24
r3000_SLTI      0x31840
          7C 1A C8 50
r3000_SLTIU    0x31880
              -->
r3000_ANDI      0x318C0
          79 59 26 E4
r3000_ORI      0x31900
          60 00 00 00
r3000_XORI      0x31940
          7B 20 00 20                  (change way of config data offset calculation)
r3000_LUI      0x31980
0x6F978: EB EB 00 08 --> 83 EB 00 08  (load config data pointer as zero extended word, instead of doubleword)
r3000_ADD      0x319C0
0x6F998: 80 0B 00 10 --> 80 0B 00 0C  (change load offset for config count)
r3000_ADDU      0x31A00
0x6F9DC: 7D 3A C8 50 --> 7B 29 00 20  (change way of config data offset calculation for config with 2 or more cmds)
r3000_SUB      0x31A40
0x6F9F8: 80 09 00 10 --> 80 09 00 0C  (change load offset for config count)
r3000_SUBU      0x31A80
 
r3000_SLT      0x31AC0
For now we can add some configs to table, and use rest of new zeroed space to store configs itself.
r3000_SLTU      0x31B00
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.
r3000_AND      0x31B40
 
r3000_OR        0x31B80
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.<br>
r3000_XOR      0x31BC0
gxemu.elf MD5 before patch
r3000_NOR      0x31C00
38D891A6A67F9275D1B6D18E04BDCAA7
r3000_SLL      0x31C40
gxemu.elf MD5 after patch
r3000_unk1      0x31C80 Primary opcode field (Bit 26..31) = 0x3E (debug stuff, not existing on real r3000)
B452CCB51348127DAF8A931B621E5E39
r3000_unk2      0x31CC0 Primary opcode field (Bit 26..31) = 0x3F (debug stuff, not existing on real r3000)
DL: https://www.mediafire.com/file/kpno5mubyy7q9p0/gx_cfg_ext.ppf/file
r3000_SRL      0x31D00
 
r3000_SRA      0x31D40
===Patch System Manager to allow PS2 emulators Fan Control===
r3000_SLLV      0x31D80
Patch is for LV1 file, should be 4.75+ but it's based on 4.78 LV1 file. '''Don't try to modify your LV1 without hardware flasher!''' This patch enables ability to get fan readings and to set fan speed and policy. This patch doesn't implement fan controls from webman to work in ps2 mode, additional code needs to be patched on PS2 emulators side to make something useful from it.
r3000_SRLV      0x31DC0
 
r3000_SRAV      0x31E00
Search for (4.78 LV1):
r3000_MULT      0x31E40
E8 03 01 C8 54 00 05 EE  2F A0 00 00 41 9E 00 E4
r3000_MULTU    0x31F00
 
r3000_DIV      0x31F80
Replace to (4.78 LV1):
r3000_MFHI      0x32080
E8 03 01 C8 54 00 05 EE  2F A0 00 00 60 00 00 00
r3000_MFLO      0x320C0
 
r3000_MTHI      0x32100
==Inject LIBSD into netemu Bios==
r3000_MTLO      0x32140
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.
r3000_J        0x32180
Offsets for unpacked elf file.
r3000_JAL      0x32200
0x893470: string TBIN --> LIBSD
r3000_JR        0x32280
0x8DC200: Paste LIBSD file here (Ctrl-B in HxD to overwrite old data).
r3000_JALR      0x322C0
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.
r3000_BEQ      0x32300
 
r3000_BNE      0x32340
== SPE programs dumper ==
r3000_BLEZ      0x32380
 
r3000_BGTZ      0x323C0
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.
r3000_BcondZ    0x32400
 
r3000_SYSCALL  0x32480
https://pastebin.com/x8fvY1UL
r3000_BREAK    0x324C0
r3000_COP_bad  0x32500
r3000_COP0      0x32540
r3000_bad_op    0x32740
r3000_LB        0x32840
r3000_LH        0x32940
r3000_LW        0x32A40
r3000_LBU      0x32B80
r3000_LHU      0x32C80
r3000_LWL      0x32D80
r3000_LWR      0x32E80
r3000_SB        0x32F80
r3000_SH        0x33080
r3000_SW        0x33180
r3000_SWL      0x33300
r3000_SWR      0x33400


Addresses above ARE NOT the ones in emulator memory, this is local storage address in IOP SPE program!
== Random ps2_netemu notes ==
Opcodes LWCx 0-3, and SWCx 0-3 are not supported at all.
Same goes for general COP 1-3 opcodes, but those cause COPx unusable r3000 exception.
While LWC/SWC are triggering bad opcode exception.
Not sure if LWC0/SWC0 should be allowed.
COP0 is working in PS2 mode, so those probably shouldn't cause exception.
At the second hand i don't know single IOP module that use that instruction.
</pre>


This is unconfirmed by any code reversing for now, but IOP emulator print messages like:
* 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.
Cache write (IOPADDR/LSADDR/SIZE)
* 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.
Cache read  (IOPADDR/LSADDR/SIZE)
* Emulator is full of unused functions. Everything that is compiled inline its also there as separate unreachable function.
ERROR: Double ICACHE fault
* 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.
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.
* 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===
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.


===EEDMA on SPE3===
r0  = 0x200000000, used when recompiler load something directly from EE memory.
That one is one of most misleading names in whole emulator.. <br>
r13 = Cycles. When recompiled code run, value is frequently compared to value from negmem F000 and event test is triggered depending on compare result.
DMA channels are handled in:
r14 = r5900_current_pc
*0 - VIF0 on PPU only
r15 = r5900 pc >> 6, used for cache checks. r15 is also used as temp register when fallback to interpreter, etc.
*1 - VIF1 dma, and VIF1 hw reads/writes including fifo write are handled in SPE3 (EEDMA)
r16 = r5900_v0_reg_lower64
*2 - GIF dma handled in SPE3 (EEDMA) incl. fifo write, but most HW reads is not handled here
r17 = r5900_v1_reg_lower64
*3 - IPUfrom dma, and whole ipu HW r/w is handled by SPE6
r18 = r5900_a0_reg_lower64
*4 - IPUto dma, and whole ipu HW r/w is handled by SPE6
r19 = r5900_a1_reg_lower64
*5 - SIF0 dma is handled in PPE, and SPE 0 (IOP)
r20 = r5900_a2_reg_lower64
*6 - SIF1 dma is handled in PPE, and SPE 0 (IOP)
r21 = r5900_a3_reg_lower64
*7 - SIF2 dma is handled in PPE, and SPE 0 (IOP)
r31 = r5900_ra_reg_lower64
*8 - SPRfrom dma is handled on PPE only it seems
*9 - SPRto dma is handled on PPE only it seems
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 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>
So is more like "Close to GS" DMA handler.
 
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.
"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)
v0  = 0x0F0E0D0C, 0x0B0A0908, 0x07060504, 0x03020100
 
v2  = 0x80000000, 0x80000000, 0x80000000, 0x80000000
===VU1 emulation on SPE===
v20 = 0xFFFFFFFF, 0x00000000, 0x00000000, 0x00000000
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).
v21 = 0x00000000, 0xFFFFFFFF, 0x00000000, 0x00000000
<br>
v22 = 0x00000000, 0x00000000, 0xFFFFFFFF, 0x00000000
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.
v22 = 0x00000000, 0x00000000, 0x00000000, 0xFFFFFFFF
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.
 
128 bit Altivec registers v24 - v31 are used as COP1 (fpu) regs.
In latest ps2_netemu function responsible for translating VU1 code into SPE ready code is located at 0x13C69C
v24 = f00, f01, f02, f03
<br><br>
v25 = f04, f05, f06, f07
SPU registers always follow this layout when VU1 is running:
v26 = f08, f09, f10, f11
*r0  - r31 = vf00 - vf31
v27 = f12, f13, f14, f15
*r32 - r57 = vi00 - vi25 (vu ctrl regs above vi25 are mapped to vu0 anyway)
v28 = f16, f17, f18, f19
*r48      = ACC (accessible from VU0 as vi19)
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.


Additionally ppu can access those regs with addresses 0x3000xyy0.
=== EE Timers Count Read ===
Where x is 4,5,6, or 7 (mirrors), and yy is reg number in hex.
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.
*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).
=== DataStorage vector hook ===
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.
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 word is ppc instruction that caused exception.
* Code now read extended opcode (XOP) field to figure out instruction type ((code >> 1) & 0x3FF)
* When matching xop 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.


===IPU SPE6===
=== Free sapce in config parser ===
====IDEC start code detection====
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:
IDEC perform compare to 0 while starting to search code, but not check that required bits are even available in stream.  
seg020:000000000012EECC        lwzx      r0, r9, r31
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..  
seg020:000000000012EED0        srwi      r11, r0, 24
This probably break Onimusha DoD, and many other random games.
seg020:000000000012EED4        rlwinm    r9, r0, 8,8,15
====IPU skip mpeg hack====
seg020:000000000012EED8        slwi      r3, r0, 24
There are some leftovers of SKIP MPEG hack in SPE 6 (IPU), i'm not sure that is still available.
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


===SPE4 and SPE5===
== RSX workload on the netemu ==
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.<br>
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?
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.
* 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)
*** 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)


==SCANMSK on ps2_netemu==
== Netemu load/store with r0 register ==
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==
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.
*See: [[PS2_Emulation/PS2_Games_Masterlist]]
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.


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


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.
ld RT, Disp(RA)
* 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. --[[User:Kozarovv|Kozarovv]] ([[User talk: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.<br> 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.<br> 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.--[[User:Agrippa|Agrippa]] ([[User talk:Agrippa|talk]]) 18:03, 30 March 2022 (UTC)
RT Specifies target general-purpose register where result of operation is stored.
=== Widescreen support ===
Disp Specifies a 16-bit signed number that is a multiple of 4. The assembler divides this number by 4 when generating the instruction.
If the game does retrieve the widescreen flag from the GetOSDConfigParam through the scescfGetAspect function, the results are as follows:
RA Specifies source general-purpose register for EA calculation.
* 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 ==
But according to the same manual:


===Display current PC/RA values for r5900===
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.


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.  
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", loads/stores with r0 starting to make sense.  


  search for (2 times):
  std      r4, 0x3008(r0) # store r4 on 0x3008, no matter what r0 actually is at the moment.
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):
  ld        r0, -0x6BF0(r0) # load to r0 from address 0xFFFFFFFFFFFF9410, no matter what r0 actually is at the moment.
  60 00 00 00 60 00 00 00 60 00 00 00 60 00 00 00
ld        r4, 0x3008(r0) # load to r4 from address 0x3008, no matter what r0 actually is at the moment.
  60 00 00 00 60 00 00 00 60 00 00 00 80 C0 91 00
 
  80 E0 8B 7C
== Communication with Graphics Synthesizer in ps2_gxemu ==
 
Communication from emu level is done with rw to special addresses of what seems to be RSX ports.
Emu includes thin translation layer that intercept rw operations to GS privilaged registers.
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.
 
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.
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.
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
   
   
  search for:
  0x40 = CSR
  43 45 4C 4C 3A 20 25 30 32 64 20 C2 B0 43 26 23
  0x41 = IMR
  78 61 3B 52 53 58 3A 20 20 20 25 30 32 64 20 C2
  0x44 = BUSDIR
  B0 43 00
  0x48 = SIGLBLID
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===
== ps2_gxemu external bios/rom loading. ==


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


ps2_netemu:
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.
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
ps2_gxemu
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===
Note: This code don't exist in ps2_netemu.
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.
== Universal DNAS anti-wipe patch ==
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.


Now:
Tested with 2.8.0 and 3.0.0 DNAS libraries. EESYNC wipes the memory from 0x00084000 to 0x00100000. Patch is needed for 0x42 command to work with DNAS games when the overlay is installed in this memory region.
hash      00 00 00 FF FF FF FF FF
<pre>
pointer  00 00 00 00 FF FF FF FF
Original: 18 00 A2 AF 95 00 00 0C 1C 00 A0 AF
  cmd count FF FF FF FF
Patched: 18 00 A2 AF 01 00 02 24 1C 00 A0 AF</pre>
align    00 00 00 00 (previously we thought that is terminator)


Compacted:
== Accurate ADD/SUB ==
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 :) .
Emulator need accurate math for PS2 floating points operations because PS2 FPU/VU are special (partially also PS3 SPEs, but that's story for different wiki page).
After that i wrote small dumper that allowed me to edit table in easy way to recreate new table with empty slots.
PS3 VMX unit in PPU have special compatibility mode with SPU, activated by lv1_set_vmx_graphics_mode(1) hvcall. This is supposed to make floating points operations results as close to SPU as possible. This set default rounding mode to round to zero, denormals are treated as zero, and there are no infinities or NaNs. So practically same mode as PS2 use.
Hardest part behind us, now just patches to respect new table elements size, and we are done.
Every PS2 EE emulator on PS3 use this mode as otherwise many of that need to be done by software which is inconvenient, and tank performance. There are some suggestions that Sony requested this mode from IBM specifically for PS2 emulators. At this point floats should be handled like on PS2 right? Nope.
PS2 FPU/VU is even more "special" than that, and it seems that Sony missed, or IBM wasn't able to implement that. What is so special? Since PS2 guarantee to round to zero, there is no need for 3 guard bits (more precisely guard/round/sticky bits).
Testing shows that PS2 use only 1 of those bits in way known from other platforms. This makes every FPU/VU ADD/SUB/MUL/DIV operation possibly inaccurate on hardware other than PS2.
There is no way to reproduce that on hardware that is not created with that in mind. No matter it is PS3 VMX, or x86/ARM SSE/AVX. This behavior is not reproductible on currently used hardware without software approach.
But this still doesn't sound that bad, how much developers can rely on bit precise floating point results? 80 from 788 ps2_gxemu configs is using accurate math command, and that's only small chunk of what is really needed. Not to mention direct patches like Persona 4, etc, and tons of custom configs.
<br><br>
Here is function used when accurate ADD/SUB math is requested: https://pastebin.com/sX6vfxin This code run for EVERY SINGLE add/sub separately when opcode is in command range.
<br>
Recompiled code for eg. fpu '''add d,c,b''' looks like this:
vaddfp d,c,b


4.88.2 Evilnat ps2_gxemu.elf offsets:
While recompiled code for accurate fpu '''add d,c,b''' looks like this (simplified):
  0x6F938: 38 00 03 14 --> 38 00 04 9E (increase loop count)
  lis a,0xXXXX
  0x6F950: 39 29 00 18 --> 39 29 00 10  (decrease step incrementer)
  ori a,a, 0xXXXX
  0x6F968: 79 59 2E A4
  stvx b,a, 0x0
          79 5A 1F 24
  add a,0x10
          7C 1A C8 50
  stvx c,a, 0x0
              -->
  bla https://pastebin.com/sX6vfxin
          79 59 26 E4
  lis a,0xXXXX
          60 00 00 00
  ori a,a, 0xXXXX
          7B 20 00 20                  (change way of config data offset calculation)
  lvx d,a, 0x0
  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.
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:
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.
0x18726C    li        r9, -1                # --- start of "constants" creation ---
 
0x187270    clrlwi    r9, r9, 1            # r9 = 0x7FFFFFFF
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.<br>
0x187274    stw      r9, 0x20(r31)
gxemu.elf MD5 before patch
0x187278    li        r9, 0xFF
  38D891A6A67F9275D1B6D18E04BDCAA7
0x18727C    stw      r9, 0x24(r31)
gxemu.elf MD5 after patch
0x187280    li        r9, 31
  B452CCB51348127DAF8A931B621E5E39
0x187284    stw      r9, 0x28(r31)
DL: https://www.mediafire.com/file/kpno5mubyy7q9p0/gx_cfg_ext.ppf/file
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.


== SPE programs dumper ==
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:


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.
0x18726C    li        r9, 0x7000
0x187270    lvxl      v16, r9, r0
0x187274    addi      r9, r9, 0x10
0x187278    lvxl      v16, r9, r0


https://pastebin.com/x8fvY1UL
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.


== Random ps2_netemu notes ==
== Ugly fix for HDD whitelisted games loaded through Cobra ==


* 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.
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.
* 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.
<pre>
* 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.
Original: 4B FF 1A 11 38 81 00 A0 38 61 00 AC 4B FF ED 3D
* Emulator is full of unused functions. Everything that is compiled inline its also there as separate unreachable function.
Patched:  60 00 00 00 38 81 00 A0 38 61 00 AC 4B FF ED 3D</pre>
* 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.
== Unknown VIF issue - bad cmd ==
===Registers===
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.
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.
* 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.
* 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.
* 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.


  r0 = 0x200000000, used when recompiler load something directly from EE memory.
Code which handle bad cmd:
  r13 = Cycles. When recompiled code run, value is frequently compared to value from negmem F000 and event test is triggered depending on compare result.
  0x14D00 ila    r4, 0x2000
r14 = r5900_current_pc
  0x14D04  shufb  r2, r104, r104, r89
r15 = r5900 pc >> 6, used for cache checks. r15 is also used as temp register when fallback to interpreter, etc.
  0x14D08 ila    sp, sub_147C0
  r16 = r5900_v0_reg_lower64
  0x14D0C a      r2, r2, r77
  r17 = r5900_v1_reg_lower64
  0x14D10 shufb  r2, r103, r102, r2
  r18 = r5900_a0_reg_lower64
  0x14D14  stqa    r2, VIF1_CODE
  r19 = r5900_a1_reg_lower64
  0x14D18 lqa    r2, VIF1_ERR
  r20 = r5900_a2_reg_lower64
  0x14D1C lqa    r3, VIF1_STAT
  r21 = r5900_a3_reg_lower64
  0x14D20 andi    r2, r2, 4          ; VIF1_ERR.ME1
r31 = r5900_ra_reg_lower64
  0x14D24  ceqi    r2, r2, 0          ; set if bad cmd is unmasked
  0x14D28  selb    r3, r3, r2, r4    ; Set VIF_STAT.ER1 if bad cmd bit mask is not active
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.
  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
  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.
  0x14D38 or      r87, r87, r4      ; Unk flags, stored at 0x290
  v0 = 0x0F0E0D0C, 0x0B0A0908, 0x07060504, 0x03020100
  0x14D3C stqa    r3, VIF1_STAT
  v2 = 0x80000000, 0x80000000, 0x80000000, 0x80000000
  0x14D40 nop
  v20 = 0xFFFFFFFF, 0x00000000, 0x00000000, 0x00000000
  0x14D44 bi      r2
  v21 = 0x00000000, 0xFFFFFFFF, 0x00000000, 0x00000000
*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)
  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.


== RSX workload on the netemu ==
== Games with EE threading/interrupt issues ==


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?
* '''Def Jam: Fight for NY'''
* 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)
** Random hangs on first loading sequence.
** 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)
* '''Visual Mix: Ayumi Hamasaki Dome Tour 2001'''
*** 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)
** Random hangs during loading transitions.
* '''Harry Potter and the Chamber of Secrets'''
** Seems to randomly hang on the last stage of loading (ra=0x19bf70). WaitSema calls spotted during the hang.
* '''Gran Turismo 4'''
** Hangs during the FMV playback on the idle wait loop. Game does wait for the interrupt that does not happen, probably.
***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)
****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)


== Netemu load/store with r0 register ==
Assuming the game programming is right, the underlying issues are data transfer related, probably.


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.
== Games with GS emulation issues ==
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.
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).


This is because of PowerPC quirk that i (and apparently IDA in 64 bit mode) wasn't aware. From IBM manual:
== 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.  


  ld RT, Disp(RA)
  Stuntman US
0x100000-0x1c5e68 - no change
0x1c5e6c - improvement in ApplyTyreForces__5WheelR3CarffG4MAv3N24R4MAm4Rf
  vadd.xyzw vf01, vf01, vf02
0x1c7128 - improvement in Update__5WheelR3CarR4MAm4R4MAv3T3
  vadd.xyzw vf01, vf01, vf02
0x1c727c - imrpovement in Update__5WheelR3CarR4MAm4R4MAv3T3
  vadd.xyzw vf01, vf01, vf02
    - both of the above with the others make most accurate path
    - vm insts 0x1c6e78-0x1c6ecc basically negate this additional accuracy?
0x1c769c-0x211f04 - nothing
0x211f08 - improvement in _dyForwardDynamics__FP10DYdynamicsf
  vadd.xyzw vf02, vf02, vf01
0x211f94 - improvement in dyStepRunge1__FP10DYdynamicsf
  vadd.xyzw vf04, vf04, vf01
0x2140b0-0x215118 - no change
0x215118 - obUpdateTransMatrix__FP8OBobject
    - negates additional accuracy of Update__5WheelR3CarR4MAm4R4MAv3T3?
   
   
  RT Specifies target general-purpose register where result of operation is stored.
  0x215260-0x1ffffff - no change
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:
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)


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.  
== Patches for SCCS region games ==
Most Chinese region games (SCCS) require the ROM2 modules to be present. However, even if they are required by the game in order to boot, they are not needed at all and are fully playable without ROM2 the vast majority of the time. I have compiled patches for all SCCS games that allow each one to at least boot on PS3 and PCSX2 (older versions, or newer ones without the correct BIOS) by simply skipping over the infinite loops the games get caught in: https://www.mediafire.com/file/skdka574f23b96g/SCCS_patches.zip/file


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.  
Mostly untested on PS3, but all have been tested on an older PCSX2 version. 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. In the end, only two games ended up having text bugs due to the character data not being loaded from ROM2:
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.


std      r4, 0x3008(r0) # store r4 on 0x3008, no matter what r0 actually is at the moment.
{| class="wikitable"
|-
ld        r0, -0x6BF0(r0) # load to r0 from address 0xFFFFFFFFFFFF9410, no matter what r0 actually is at the moment.
! Serial Number !! Game !! Bootable (without patch) !! ROM2 required
ld        r4, 0x3008(r0) # load to r4 from address 0x3008, no matter what r0 actually is at the moment.
|-
 
| SCCS-40001 || Ape Escape 2 || No || Yes (missing text)
== ps2_gxemu external bios/rom loading. ==
|-
 
| SCCS-40002 || Devil May Cry 2 (Disc 1) || No || No
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.
|-
 
| SCCS-40003 || Devil May Cry 2 (Disc 2) || No || No
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.
|-
 
| SCCS-40004 || XIGO: Zuihou de Touzi || No || No
Note: This code don't exist in ps2_netemu.
|-
 
| SCCS-40005 || Ico || No || No
== Shin Sangoku Musou config ==
|-
 
| SCCS-40006 || Zhen Sanguo Wushuang 2 || No || No
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)
|-
 
| SCCS-40007 || Arc the Lad: Seirei no Tasogare || No || No
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).
|-
* It does write an interrupt request for the start of the VBlank. Looks like the game does sync with the refresh rate and the game logic (at least the specific function you have mentioned) does break itself when the timing is not right.--[[User:Agrippa|Agrippa]] ([[User talk:Agrippa|talk]]) 14:59, 10 August 2022 (UTC)
| SCCS-40009 || Dragon Ball Z 2 || Yes || No
** Writing to INTC_STAT remove vblank start bit in this case (acknowledge that interrupt happened). But yeah, generally this is timing issue. Probably similar issue to what pcsx2 have: [[https://github.com/PCSX2/pcsx2/issues/5369#issuecomment-1146042222 | here.]] But affect different games due to other differences in emulator. --[[User:Kozarovv|Kozarovv]] ([[User talk:Kozarovv|talk]]) 19:38, 10 August 2022 (UTC)
|-
 
| SCCS-40010 || Super Puzzle Bobble 2 || No || No
== Universal DNAS anti-wipe patch ==
|-
| SCCS-40011 || Armored Core 2: Another Age || No || No
|-
| SCCS-40014 || World Soccer Winning Eleven 7 International || No || No
|-
| SCCS-40015 || Viorate no Atelier: Gramnad no Renkinjutsushi 2 || No || Yes (text bugs)
|-
| SCCS-40016 || Ape Escape: Pumped & Primed || Yes || No
|-
| SCCS-40017 || EyeToy: Play || No || EyeToy game
|-
| SCCS-40018 || Saru EyeToy Oosawagi: Wakki Waki Game Tenkomori!! || No || EyeToy game
|-
| SCCS-40019 || Formula One 04 || No || No (English)
|-
| SCCS-40022 || World Soccer Winning Eleven 8: Asia Championship || No || No
|-
| SCCS-60002 || Gran Turismo 4 || No || No
|}
* 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)
*** "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)


Tested with 2.8.0 and 3.0.0 DNAS libraries. EESYNC wipes the memory from 0x00084000 to 0x00100000. Patch is needed for 0x42 command to work with DNAS games when the overlay is installed in this memory region.
== Removing stuff from ps2 emu page ==
<pre>
Original: 18 00 A2 AF 95 00 00 0C 1C 00 A0 AF
Patched:  18 00 A2 AF 01 00 02 24 1C 00 A0 AF</pre>


== Accurate ADD/SUB ==
I'm thinking about removing some data from PS2 Emulation page. Mostly stuff that is strictly PS2 thing.


Emulator need accurate math for PS2 floating points operations because PS2 FPU/VU are special (partially also PS3 SPEs, but that's story for different wiki page).
*PS2 Memory and Hardware Mapped Registers Layout
PS3 VMX unit in PPU have special compatibility mode with SPU, activated by lv1_set_vmx_graphics_mode(1) hvcall. This is supposed to make floating points operations results as close to SPU as possible. This set default rounding mode to round to zero, denormals are treated as zero, and there are no infinities or NaNs. So practically same mode as PS2 use.
*Video Modes
Every PS2 EE emulator on PS3 use this mode as otherwise many of that need to be done by software which is inconvenient, and tank performance. There are some suggestions that Sony requested this mode from IBM specifically for PS2 emulators. At this point floats should be handled like on PS2 right? Nope.
*<s>Config related info</s> Done.
PS2 FPU/VU is even more "special" than that, and it seems that Sony missed, or IBM wasn't able to implement that. What is so special? Since PS2 guarantee to round to zero, there is no need for 3 guard bits (more precisely guard/round/sticky bits).
 
Testing shows that PS2 use only 1 of those bits in way known from other platforms. This makes every FPU/VU ADD/SUB/MUL/DIV operation possibly inaccurate on hardware other than PS2.
'''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)
There is no way to reproduce that on hardware that is not created with that in mind. No matter it is PS3 VMX, or x86/ARM SSE/AVX. This behavior is not reproductible on currently used hardware without software approach.
* 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)
But this still doesn't sound that bad, how much developers can rely on bit precise floating point results? 80 from 788 ps2_gxemu configs is using accurate math command, and that's only small chunk of what is really needed. Not to mention direct patches like Persona 4, etc, and tons of custom configs.
<br><br>
Here is function used when accurate ADD/SUB math is requested: https://pastebin.com/sX6vfxin This code run for EVERY SINGLE add/sub separately when opcode is in command range.
<br>
Recompiled code for eg. fpu '''add d,c,b''' looks like this:
vaddfp d,c,b


While recompiled code for accurate fpu '''add d,c,b''' looks like this (simplified):
== Floating point arithmetic inaccuracies ==
lis a,0xXXXX
ori a,a, 0xXXXX
stvx b,a, 0x0
add a,0x10
stvx c,a, 0x0
bla https://pastebin.com/sX6vfxin
lis a,0xXXXX
ori a,a, 0xXXXX
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:
While the software emulators are doing a great job with their accurate paths, there are still issues with some games, unfortunately.
0x18726C    li        r9, -1                # --- start of "constants" creation ---
* Stuntman/Driv3r
0x187270    clrlwi    r9, r9, 1            # r9 = 0x7FFFFFFF
Completely broken AI, game is unplayable.
0x187274    stw      r9, 0x20(r31)
* Gran Turismo series
0x187278    li        r9, 0xFF
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.
0x18727C    stw      r9, 0x24(r31)
* Tokyo Xtreme Racer Zero
0x187280    li        r9, 31
It is unconfirmed, but the cars path from PS2 imported replays are played back wrongly in the PCSX2.
0x187284    stw      r9, 0x28(r31)
* PRIDE FC: Fighting Championships
0x187288    li        r9, 23
It seems that y × 1 ≠ y sometimes. Fixed by patching the game code.
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:
== Manipulating r5900 cyclerate ==


0x18726C    li        r9, 0x7000
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.
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.
  _________________________________________________
|  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


== Ugly fix for HDD whitelisted games loaded through Cobra ==
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.


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.
== Emulator status flags ==
<pre>
Original: 4B FF 1A 11 38 81 00 A0 38 61 00 AC 4B FF ED 3D
Patched:  60 00 00 00 38 81 00 A0 38 61 00 AC 4B FF ED 3D</pre>


== Unknown VIF issue - bad cmd ==
We can't really modify this flag from outside on retail emu, but we can always patch function that do init.
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.
===Netemu===
 
Localised at 0x934158 of emu memory.
* 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.
  1       = init done?
* 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.
2        = unk thr sys
* 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)
4        = unk thr sys
* General note. PS2 VIF seems to be broken by design. Manual have following warnings:
8        = unk
** 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.
  10      = run watchpoint opcode (debug halt) 0x11DD80
** In V3_16 format, set the ME1 bit to 1.
  20      = set mecha 0x245828A to 2, and run sc8 (0x200)
** 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.
  40      = some setting for spe0_class0_int_handler
 
  80       = enable cmd 0xF/0x26/0x27 for whole memory range
Code which handle bad cmd:
  200      = set when emulated hardware init is done
  0x14D00  ila    r4, 0x2000
  400      = enable 0x934160 debug flag (watchpoint on ee and on iop)
  0x14D04  shufb  r2, r104, r104, r89
  800      = skip parsing config file
  0x14D08  ila    sp, sub_147C0
  1000     = do cmd 0x1F with 0x3E8(1000) param
  0x14D0C  a       r2, r2, r77
  4000     = enable cmd 0x11 for whole VU0 mem (per range setting is inaccessible from config!)
  0x14D10 shufb  r2, r103, r102, r2
  20000   = skip SCED discs error (more, todo)
  0x14D14  stqa    r2, VIF1_CODE
  40000   = do cmd 0x14
  0x14D18  lqa     r2, VIF1_ERR
  80000    = memory card related (0x12A6D8) also run sc_7(2) in thr hdd
  0x14D1C  lqa     r3, VIF1_STAT
  200000  = do cmd 0x05
  0x14D20  andi   r2, r2, 4          ; VIF1_ERR.ME1
  400000  = enable config cmd 0x10 for whole memory range
  0x14D24  ceqi   r2, r2, 0          ; set if bad cmd is unmasked
  800000  = do cmd 0x12 with 0x2DFF000 flags
  0x14D28 selb    r3, r3, r2, r4    ; Set VIF_STAT.ER1 if bad cmd bit mask is not active
  4000000 = mecha related (todo 0x135664)
  0x14D2C andi    r4, r2, 0x10
  8000000 = run loop that wait for 0xB52BB8 to be non zero
  0x14D30 selb    r2, sp, r39, r2    ; sub_147C0[sp] or (sub_12840 or sub_17700)[r39] depending on ME1 bit // Probably issue starts here.
  10000000 = watchpoint (if thread flag is set)
  0x14D34 lnop
  20000000 = timing setting for media validity check
  0x14D38 or      r87, r87, r4      ; Unk flags, stored at 0x290
  80000000 = show health warning message
  0x14D3C  stqa    r3, VIF1_STAT
   
  0x14D40  nop
  Need work
  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 ==
===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...


* '''Harry Potter and the Chamber of Secrets'''
== Memory Map ==
** Seems to randomly hang on the last stage of loading (ra=0x19bf70). WaitSema calls spotted during the hang.
=== Netemu ===
* '''Gran Turismo 4'''
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.  
** Hangs during the FMV playback on the idle wait loop. Game does wait for the interrupt that does not happen, probably.
***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)
****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)


Assuming the game programming is right, the underlying issues are data transfer related, probably.
{| class="wikitable" style="font-size:small;"
 
|-
== Games with GS emulation issues ==
! Name !! Start EA !! End EA !! Flags !! Notes
Neither performance, nor mipmap and SCANMSK related.
|-
* '''Prince of Persia: Warrior Within'''
| work  
** Weapons' trails are rainbow (fixed by Auto-flush in PCSX2).
|| 0
* '''Lord of the Rings: The Return of the King'''
|| 0x3200000
** Top-left corner issue when the mist/fog is rendered.
|| 3
* '''Dance Summit 2001: Bust-a-Move'''
|| separated into work 0x0-0x300000, ro_work 0x300000-0x800000, and rw_work 0x800000-0x32000000.
** Front buffer is not flushed most of the time. Game seems to apply additional effects there, apart from the downsampling.
|-
* '''Snowblind Engine 2003+ games'''
| menu_heap
** 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).
|| 0xE000000
 
|| 0xE400000
== Stuntman/Driv3r research ==
|| 3
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.
||
 
|-
Stuntman US
| negmem
0x100000-0x1c5e68 - no change
|| 0xFFFFFFFFFFFF0000
|| 0
0x1c5e6c - improvement in ApplyTyreForces__5WheelR3CarffG4MAv3N24R4MAm4Rf
|| 0x10000001
  vadd.xyzw vf01, vf01, vf02
||
0x1c7128 - improvement in Update__5WheelR3CarR4MAm4R4MAv3T3
  vadd.xyzw vf01, vf01, vf02
0x1c727c - imrpovement in Update__5WheelR3CarR4MAm4R4MAv3T3
  vadd.xyzw vf01, vf01, vf02
    - both of the above with the others make most accurate path
    - vm insts 0x1c6e78-0x1c6ecc basically negate this additional accuracy?
0x1c769c-0x211f04 - nothing
0x211f08 - improvement in _dyForwardDynamics__FP10DYdynamicsf
  vadd.xyzw vf02, vf02, vf01
0x211f94 - improvement in dyStepRunge1__FP10DYdynamicsf
  vadd.xyzw vf04, vf04, vf01
0x2140b0-0x215118 - no change
0x215118 - obUpdateTransMatrix__FP8OBobject
    - negates additional accuracy of Update__5WheelR3CarR4MAm4R4MAv3T3?
0x215260-0x1ffffff - no change
 
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 ==
Most Chinese region games (SCCS) require the ROM2 modules to be present. However, even if they are required by the game in order to boot, they are not needed at all and are fully playable without ROM2 the vast majority of the time. I have compiled patches for all SCCS games that allow each one to at least boot on PS3 and PCSX2 (older versions, or newer ones without the correct BIOS) by simply skipping over the infinite loops the games get caught in: https://www.mediafire.com/file/skdka574f23b96g/SCCS_patches.zip/file
 
Mostly untested on PS3, but all have been tested on an older PCSX2 version. 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. In the end, only two games ended up having text bugs due to the character data not being loaded from ROM2:
 
{| class="wikitable"
|-
|-
! Serial Number !! Game !! Bootable (without patch) !! ROM2 required
| ?
|| 0x30000000
|| 0x30008000
|| 0x30000000
|| vu0
|-
|-
| SCCS-40001 || Ape Escape 2 || No || Yes (missing text)
| spu_iop
|| 0x40000000
|| 0x40060000
|| 0xE0000001
||
|-
|-
| SCCS-40002 || Devil May Cry 2 (Disc 1) || No || No
| spu_spu2
|| 0x40080000
|| 0x400E0000
|| 0xE0000001
||
|-
|-
| SCCS-40003 || Devil May Cry 2 (Disc 2) || No || No
| spu_vu1
|| 0x40100000
|| 0x40160000
|| 0xE0000001
||  
|-
|-
| SCCS-40004 || XIGO: Zuihou de Touzi || No || No
| spu_eedma
|| 0x40180000
|| 0x401E0000
|| 0xE0000001
||
|-
|-
| SCCS-40005 || Ico || No || No
| fe
|| 0x40200000
|| 0x40260000
|| 0xE0000001
||  
|-
|-
| SCCS-40006 || Zhen Sanguo Wushuang 2 || No || No
| be
|| 0x40280000
|| 0x402E0000
|| 0xE0000001
||  
|-
|-
| SCCS-40007 || Arc the Lad: Seirei no Tasogare || No || No
| spu_ipu
|| 0x40300000
|| 0x40360000
|| 0xE0000001
||
|-
|-
| SCCS-40009 || Dragon Ball Z 2 || Yes || No
| be
|| 0x40380000
|| 0x403E0000
|| 0xE0000001
|| not working spu be on spe7
|-
|-
| SCCS-40010 || Super Puzzle Bobble 2 || No || No
| SPC_SLB
|| 0x50061000
|| 0x50062000
|| 0xF0000000
|| for spu_iop
|-
|-
| SCCS-40011 || Armored Core 2: Another Age || No || No
|
|| 0x50063000
|| 0x50066000
|| 0xF0000000
||
3000 = SPC_MFC_CNTL
4000 = SPC_PUINT_MB
5000 = SPC_CSR1
|-
|-
| SCCS-40014 || World Soccer Winning Eleven 7 International || No || No
| SPC_CSR
|| 0x50062000
|| 0x50063000
|| 0xF0000000
||
|-
|-
| SCCS-40015 || Viorate no Atelier: Gramnad no Renkinjutsushi 2 || No || Yes (text bugs)
| SPC_SLB
|| 0x500E1000
|| 0x500E2000
|| 0xF0000000
|| for spu_spu2
|-
|-
| SCCS-40016 || Ape Escape: Pumped & Primed || Yes || No
|
|| 0x500E3000
|| 0x500E6000
|| 0xF0000000
||
3000 = SPC_MFC_CNTL
4000 = SPC_PUINT_MB
5000 = SPC_CSR1
|-
|-
| SCCS-40017 || EyeToy: Play || No || EyeToy game
| SPC_CSR
|| 0x500E2000
|| 0x500E3000
|| 0xF0000000
||
|-
|-
| SCCS-40018 || Saru EyeToy Oosawagi: Wakki Waki Game Tenkomori!! || No || EyeToy game
| SPC_SLB
|| 0x50161000
|| 0x50162000
|| 0xF0000000
|| for spu_vu1
|-
|-
| SCCS-40019 || Formula One 04 || No || No (English)
|
|-
|| 0x50163000
| SCCS-40022 || World Soccer Winning Eleven 8: Asia Championship || No || No
|| 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
|-
|-
| SCCS-60002 || Gran Turismo 4 || No || No
|
|}
|| 0x501E3000
* 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)
|| 0x501E6000
** 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)
|| 0xF0000000
*** "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)
||
 
3000 = SPC_MFC_CNTL
== Removing stuff from ps2 emu page ==
4000 = SPC_PUINT_MB
 
5000 = SPC_CSR1
I'm thinking about removing some data from PS2 Emulation page. Mostly stuff that is strictly PS2 thing.
|-
 
| SPC_CSR
*PS2 Memory and Hardware Mapped Registers Layout
|| 0x501E2000
*Video Modes
|| 0x501E3000
*Config related info
|| 0xF0000000
 
||
'''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)
| SPC_SLB
 
|| 0x50261000
== Floating point arithmetic inaccuracies ==
|| 0x50262000
 
|| 0xF0000000
While the software emulators are doing a great job with their accurate paths, there are still issues with some games, unfortunately.
|| for fe
* Stuntman/Driv3r
|-
Completely broken AI, game is unplayable.
|
* Gran Turismo series
|| 0x50263000
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.
|| 0x50266000
* Tokyo Xtreme Racer Zero
|| 0xF0000000
It is unconfirmed, but the cars path from PS2 imported replays are played back wrongly in the PCSX2.
||
* PRIDE FC: Fighting Championships
  3000 = SPC_MFC_CNTL
It seems that y × 1 ≠ y sometimes. Fixed by patching the game code.
  4000 = SPC_PUINT_MB
 
  5000 = SPC_CSR1
== Manipulating r5900 cyclerate ==
|-
 
| SPC_CSR
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.
|| 0x50262000
 
|| 0x50263000
  _________________________________________________
|| 0xF0000000
| Opcode type  |   Netemu/Gxemu  |     PCSX2  |
||
|----------------|------------------|-------------|
|-
| Default opcode |     1 unit      |   9 units  |
| SPC_SLB
| Load/Store    |     2 units      |   14 units  |
|| 0x502E1000
  | Multiply      |    4 units      |  16 units |
|| 0x502E2000
  | Divide        |   37 units      | 112 units  |
|| 0xF0000000
| COP 0          |     1 unit      |   7 units  |
|| for be
| COP 1          | 1 unit(some 2)  |   7 units  |
|-
| COP 2          |     1 unit      |   7 units  |
|  
| NOP            |   0 units(!!!)  |   7? units  |
|| 0x502E3000
---------------------------------------------------
|| 0x502E6000
|| 0xF0000000
Additionally pcsx2 use different cycles for many other opcodes that ps3 emus just count as one.
||
  * MMI      =  14 units
  3000 = SPC_MFC_CNTL
  * MMI Mult =  24 units
  4000 = SPC_PUINT_MB
  * MMI Div  = 176 units
  5000 = SPC_CSR1
  * FPU Mul  =  32 units
|-
| SPC_CSR
At the second hand gx/net emu do some weird shenigans with cycles based on... Opcode number, this is still small unknown here. Yeah...
|| 0x502E2000
  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.
|| 0x502E3000
  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.
|| 0xF0000000
  This code takes 2 cycles (units) per loop in emu:
||
|-
loop_here:
| SPC_SLB
  addiu v0, -1
|| 0x50361000
  nop
|| 0x50362000
  nop
|| 0xF0000000
  nop
|| for spu_ipu
  nop
|-
  nop
|  
  bnez v0, loop_here
|| 0x50363000
 
|| 0x50366000
  I still need to fully confirm that nop isn't handled in some special way elsewhere but looks like it's not.
|| 0xF0000000
||
Underclocking/Overclocking could be done by modifying opcodes at 0x17CEB0, 0x17CFF8, 0x17D4C8.
  3000 = SPC_MFC_CNTL
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.
  4000 = SPC_PUINT_MB
 
  5000 = SPC_CSR1
== Emulator status flags ==
|-
 
| SPC_CSR
We can't really modify this flag from outside on retail emu, but we can always patch function that do init.
|| 0x50362000
===Netemu===
|| 0x50363000
Localised at 0x934158 of emu memory.
|| 0xF0000000
  1        = init done?
||
  2        = unk thr sys
|-
  4        = unk thr sys
| SPC_SLB
8        = unk
|| 0x503E1000
10      = run watchpoint opcode (debug halt) 0x11DD80
|| 0x503E2000
20      = set mecha 0x245828A to 2, and run sc8 (0x200)
|| 0xF0000000
40      = some setting for spe0_class0_int_handler
|| for unused be on spe7
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)
|| 0x503E3000
800      = skip parsing config file
|| 0x503E6000
1000    = do cmd 0x1F with 0x3E8(1000) param
|| 0xF0000000
4000    = enable cmd 0x11 for whole VU0 mem (per range setting is inaccessible from config!)
||
20000    = skip SCED discs error (more, todo)
  3000 = SPC_MFC_CNTL
40000    = do cmd 0x14
  4000 = SPC_PUINT_MB
80000    = memory card related (0x12A6D8) also run sc_7(2) in thr hdd
  5000 = SPC_CSR1
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
| SPC_CSR
|| 0x503E2000
|| 0x503E3000
|| 0xF0000000
||
|-
|-
| work
| GSIF
|| 0
|| 0xA0020000
|| 0x3200000
|| 0xA0028000
|| 3
|| 0x80000000
|| separated into work 0x0-0x300000, ro_work 0x300000-0x800000, and rw_work 0x800000-0x32000000.
|| rsx
|-
|-
| menu_heap
| NL
|| 0xE000000
|| 0xA0009000
|| 0xE400000
|| 0xA000A000
|| 3
|| 0x80000000
||
|| rsx
|-
|-
| negmem
| rsx_driver_info
|| 0xFFFFFFFFFFFF0000
|| 0xA0004000
|| 0
|| 0xA0007000
|| 0x10000001
|| 0x80000000
||
|| rsx
|-
| rsx_dma_ctrl
|| 0xA0030000
|| 0xA0050000
|| 0x80000000
|| rsx
|-
|-
| ?  
| ?  
|| 0x30000000
|| 0xA0008000
|| 0x30008000
|| 0xA0009000
|| 0x30000000
|| 0x80000000
|| vu0
|| rsx
|-
|-
| spu_iop
| ohci_mmio
|| 0x40000000
|| 0x60000000
|| 0x40060000
|| 0x60001000
|| 0xE0000001
|| 0x60000000
||
||
|-
|-
| spu_spu2
| ehci_mmio
|| 0x40080000
|| 0x60200000
|| 0x400E0000
|| 0x60201000
|| 0xE0000001
|| 0x60000000
||
||
|-
|-
| spu_vu1
| ohci_mmio
|| 0x40100000
|| 0x60100000
|| 0x40160000
|| 0x60101000
|| 0xE0000001
|| 0x60000000
||  
||
|-
|-
| spu_eedma
| ehci_mmio
|| 0x40180000
|| 0x60300000
|| 0x401E0000
|| 0x60301000
|| 0xE0000001
|| 0x60000000
||
||
|-
|-
| fe
| base
|| 0x40200000
|| 0x80000000
|| 0x40260000
|| 0x80100000
|| 0xE0000001
|| 0x70000003
||  
|| usb
|-
|-
| be
| rawdata
|| 0x40280000
|| 0x80800000
|| 0x402E0000
|| 0x80900000
|| 0xE0000001
|| 0x70000003
||  
|| usb
|-
|-
| spu_ipu
| iopdata
|| 0x40300000
|| 0x81000000
|| 0x40360000
|| 0x81100000
|| 0xE0000001
|| 0x70000003
||
|| usb
|-
|-
| be
| base
|| 0x40380000
|| 0x82000000
|| 0x403E0000
|| 0x82100000
|| 0xE0000001
|| 0x70000003
|| not working spu be on spe7
|| ehci? usb
|-
|-
| SPC_SLB
| ehci_vars
|| 0x50061000
|| 0x82800000
|| 0x50062000
|| 0x82900000
|| 0xF0000000
|| 0x70000003
|| for spu_iop
|| usb
|-
|-
|
| bchs_pmalloc
|| 0x50063000
|| 0x83000000
|| 0x50066000
|| 0x83100000
|| 0xF0000000
|| 0x70000003
|| usb
|-
| ?
|| 0x83800000
|| 0x83900000
|| 0x70000003
||
||
3000 = SPC_MFC_CNTL
4000 = SPC_PUINT_MB
5000 = SPC_CSR1
|-
|-
| SPC_CSR
| SB_CDVD
|| 0x50062000
|| 0x84000000
|| 0x50063000
|| 0x84100000
|| 0xF0000000
|| 0x70000003
||
||
|-
|-
| SPC_SLB
| SB_HDD
|| 0x500E1000
|| 0x84800000
|| 0x500E2000
|| 0x84900000
|| 0xF0000000
|| 0x70000003
|| for spu_spu2
|-
| 
|| 0x500E3000
|| 0x500E6000
|| 0xF0000000
||
||
3000 = SPC_MFC_CNTL
4000 = SPC_PUINT_MB
5000 = SPC_CSR1
|-
|-
| SPC_CSR
| ?
|| 0x500E2000
|| 0x85000000
|| 0x500E3000
|| 0x85100000
|| 0xF0000000
|| 0x70000003
||
||
|-
|-
| SPC_SLB
| SB_SIO2
|| 0x50161000
|| 0x85800000
|| 0x50162000
|| 0x85900000
|| 0xF0000000
|| 0x70000003
|| for spu_vu1
|| only first 0x4000?
|-
| vrc_area
|| 0x90000000
|| 0x91000000
|| 0xC00000003
|| vu1 recompiler area
|-
|-
|
| ee_cached
|| 0x50163000
|| 0x200000000
|| 0x50166000
|| 0x202000000
|| 0xF0000000
|| 0x100000003
||
||
3000 = SPC_MFC_CNTL
4000 = SPC_PUINT_MB
5000 = SPC_CSR1
|-
|-
| SPC_CSR
| ?
|| 0x50162000
|| 0x211004000
|| 0x50163000
|| 0x211008000
|| 0xF0000000
|| 0x300000000
|| vu1 memory direct rw
|-
| ee_rom
|| 0x21FC00000
|| 0x220000000
|| 0x300000000
||
||
|-
|-
| SPC_SLB
| ee_uncached
|| 0x501E1000
|| 0x220000000
|| 0x501E2000
|| 0x222000000
|| 0xF0000000
|| 0x100000003
|| for spu_eedma
||
|-
|-
|
| ee_uncacc
|| 0x501E3000
|| 0x230000000
|| 0x501E6000
|| 0x232000000
|| 0xF0000000
|| 0x100000003
||
||
3000 = SPC_MFC_CNTL
4000 = SPC_PUINT_MB
5000 = SPC_CSR1
|-
|-
| SPC_CSR
| ee_spr_lo
|| 0x501E2000
|| 0x260000000
|| 0x501E3000
|| 0x260002000
|| 0xF0000000
|| 0x700000000
||
|| weird, that map directly to 0x60000000 ps2 address
|-
|-
| SPC_SLB
| ee_spr_hi
|| 0x50261000
|| 0x270000000
|| 0x50262000
|| 0x270006000
|| 0xF0000000
|| 0x800000000
|| for fe
|| ee scratchpad
|-
|-
|
| ee_kmem0
|| 0x50263000
|| 0x280000000
|| 0x50266000
|| 0x282000000
|| 0xF0000000
|| 0x100000003
||
||
3000 = SPC_MFC_CNTL
4000 = SPC_PUINT_MB
5000 = SPC_CSR1
|-
|-
| SPC_CSR
| ?
|| 0x50262000
|| 0x291004000
|| 0x50263000
|| 0x291008000
|| 0xF0000000
|| 0x300000000
||
|| vu1 data rw in kernel mode
|-
|-
| SPC_SLB
| ?
|| 0x502E1000
|| 0x29FC00000
|| 0x502E2000
|| 0x2A0000000
|| 0xF0000000
|| 0x300000000
|| for be
|| ee_rom in kernel mode
|-
|-
|
| ?
|| 0x502E3000
|| 0x2A0000000
|| 0x502E6000
|| 0x2A2000000
|| 0xF0000000
|| 0x100000003
||
|| ee_uncached in kernel mode
3000 = SPC_MFC_CNTL
4000 = SPC_PUINT_MB
5000 = SPC_CSR1
|-
|-
| SPC_CSR
| ?
|| 0x502E2000
|| 0x2B1004000
|| 0x502E3000
|| 0x2B1008000
|| 0xF0000000
|| 0x300000000
||
|| vu1 data in kernel mode. Uncached, i doubt that is even accessible in ps2.
|-
|-
| SPC_SLB
| ?
|| 0x50361000
|| 0x2BFC00000
|| 0x50362000
|| 0x2C0000000
|| 0xF0000000
|| 0x300000000
|| for spu_ipu
|| ee_rom in uncached kernel mode
|-
|-
|
| ee_dbg
|| 0x50363000
|| 0x2FFFF8000
|| 0x50366000
|| 0x300000000
|| 0xF0000000
|| 0x900000000
||
||
3000 = SPC_MFC_CNTL
4000 = SPC_PUINT_MB
5000 = SPC_CSR1
|-
|-
| SPC_CSR
| iop_mem
|| 0x50362000
|| 0x400000000
|| 0x50363000
|| 0x400200000
|| 0xF0000000
|| 0x400000003
||
||
|-
|-
| SPC_SLB
| iop_rom
|| 0x503E1000
|| 0x4BFC00000
|| 0x503E2000
|| 0x4C0000000
|| 0xF0000000
|| 0x500000001
|| for unused be on spe7
|| kernel mode
|-
|-
|
| iop_kmmio0
|| 0x503E3000
|| 0x4BF800000
|| 0x503E6000
|| 0x4BF810000
|| 0xF0000000
|| 0x500000001
||
|| including iop_spad at first 0x1000
3000 = SPC_MFC_CNTL
4000 = SPC_PUINT_MB
5000 = SPC_CSR1
|-
|-
| SPC_CSR
| ?
|| 0x503E2000
|| 0x4AFC00000
|| 0x503E3000
|| 0x4B0000000
|| 0xF0000000
|| 0x500000001
||
|| iop_rom, uncached?
|-
|-
| GSIF
| iop_kmmio1
|| 0xA0020000
|| 0x4AF800000
|| 0xA0028000
|| 0x4AF810000
|| 0x80000000
|| 0x500000001
|| rsx
|| including iop_spad at first 0x1000
|-
|-
| NL
| spu2_ram
|| 0xA0009000
|| 0x600000000
|| 0xA000A000
|| 0x600400000
|| 0x80000000
|| 0x600000003
|| rsx
|| starting from 0x200000 spu2_ram2
|-
|-
| rsx_driver_info
| ?
|| 0xA0004000
|| 0x800000000
|| 0xA0007000
|| 0x800010000
|| 0x80000000
|| 0x1000000001
|| rsx
||
|-
| rsx_dma_ctrl
|| 0xA0030000
|| 0xA0050000
|| 0x80000000
|| rsx
|-
|-
| ?  
| ?  
|| 0xA0008000
|| 0xC0000000
|| 0xA0009000
|| 0xCF800000
|| 0x80000000
|| 0x1600000003
|| rsx
|-
| ohci_mmio
|| 0x60000000
|| 0x60001000
|| 0x60000000
||
||
|-
|-
| ehci_mmio
| sgs_xdr
|| 0x60200000
|| 0xB4000000
|| 0x60201000
|| 0xB5700000
|| 0x60000000
|| 0x1900000003
||
||
|-
|-
| ohci_mmio
| ?
|| 0x60100000
|| 0x40000000000
|| 0x60101000
|| 0x40000010000
|| 0x60000000
|| 0x1400000001
||
||
|-
|-
| ehci_mmio
| ee_jit_code
|| 0x60300000
|| 0x10000000
|| 0x60301000
|| 0x13000000
|| 0x60000000
|| 0xD00000003
||
|| Recompiled EE code that gets executed.
|-
|-
| base
| vu0_jit_code
|| 0x80000000
|| 0x18000000
|| 0x80100000
|| 0x18400000
|| 0x70000003
|| 0xD00000003
|| usb
|| Recompiled VU0 micro code that is executed.
|-
|-
| rawdata
| vu0_jit_data
|| 0x80800000
|| 0x1C000000
|| 0x80900000
|| 0x1C400000
|| 0x70000003
|| 0xD00000003
|| usb
||
|-
|-
| iopdata
| eeram_jit_lut
|| 0x81000000
|| 0x20000000
|| 0x81100000
|| 0x22000000
|| 0x70000003
|| 0xE00000003
|| usb
|| Lookup Table which holds start addresses of recompiled blocks. If block is not in the table, it gets recompiled right when emulator tries to access it.
|-
|-
| base
| eerom_jit_lut
|| 0x82000000
|| 0x2FC00000
|| 0x82100000
|| 0x30000000
|| 0x70000003
|| 0xE00000003
|| ehci? usb
|| EE ROM Lookup Table which holds start addresses of recompiled blocks. If block is not in the table, it gets recompiled right when emulator tries to access it.
|-
|-
| ehci_vars
| ustack (micro stack)
|| 0x82800000
|| 0xAAA70000000
|| 0x82900000
|| 0xAAA70040000
|| 0x70000003
|| 0x4200000000001
|| usb
|| Thread KRN0:1 (aka BOOT00)
|-
|-
| bchs_pmalloc
| ustack (micro stack)
|| 0x83000000
|| 0xAAA70040000
|| 0x83100000
|| 0xAAA70080000
|| 0x70000003
|| 0x4200010000001
|| usb
|| Thread KRN1:1 (aka BOOT01)
|-
|-
| ?
| ustack (micro stack)
|| 0x83800000
|| 0xAAA70080000
|| 0x83900000
|| 0xAAA700C0000
|| 0x70000003
|| 0x42000B0000001
||
|| VU0 stack (used in EEonBE when VU0 is running)
|-
|-
| SB_CDVD
| ustack (micro stack)
|| 0x84000000
|| 0xAAA700C0000
|| 0x84100000
|| 0xAAA70100000
|| 0x70000003
|| 0x4200030000001
||
|| Thread SYS
|-
|-
| SB_HDD
| ustack (micro stack)
|| 0x84800000
|| 0xAAA70100000
|| 0x84900000
|| 0xAAA70140000
|| 0x70000003
|| 0x4200040000001
||
|| Thread VRC
|-
|-
| ?
| ustack (micro stack)
|| 0x85000000
|| 0xAAA70140000
|| 0x85100000
|| 0xAAA70180000
|| 0x70000003
|| 0x4200050000001
||
|| Thread MECHA
|-
|-
| SB_SIO2
| ustack (micro stack)
|| 0x85800000
|| 0xAAA70180000
|| 0x85900000
|| 0xAAA701C0000
|| 0x70000003
|| 0x4200060000001
|| only first 0x4000?
|| Thread HDD
|-
|-
| vrc_area
| ustack (micro stack)
|| 0x90000000
|| 0xAAA701C0000
|| 0x91000000
|| 0xAAA70200000
|| 0xC00000003
|| 0x4200070000001
|| vu1 recompiler area
|| Thread UI
|-
|-
| ee_cached
| ustack (micro stack)
|| 0x200000000
|| 0xAAA70200000
|| 0x202000000
|| 0xAAA70280000
|| 0x100000003
|| 0x4200090000001
||
|| Thread BL2LNK and BL2MAIN
|-
|-
| ?
| ustack (micro stack)
|| 0x211004000
|| 0xAAA70280000
|| 0x211008000
|| 0xAAA702C0000
|| 0x300000000
|| 0x42000A0000001
|| vu1 memory direct rw
|| Thread USB
|-
|-
| ee_rom
| ustack (micro stack)
|| 0x21FC00000
|| 0xAAA702C0000
|| 0x220000000
|| 0xAAA70300000
|| 0x300000000
|| 0x42000B0000001
||
|| Thread EEonBE
|-
|}
 
=== Gxemu ===
{| class=wikitable style=font-size:small;
|-
|-
| ee_uncached
! Name !! Start EA !! Unk (lpar?) !! Unk !! Notes
|| 0x220000000
|| 0x222000000
|| 0x100000003
||
|-
|-
| ee_uncacc
| work || 0 || 0 || 0 ||
|| 0x230000000
|| 0x232000000
|| 0x100000003
||
|-
|-
| ee_spr_lo
| vu0_direct || 0x30000000 || 0x30000000 || 0x1000000 ||
|| 0x260000000
|| 0x260002000
|| 0x700000000
|| weird, that map directly to 0x60000000 ps2 address
|-
|-
| ee_spr_hi
| ustack || 0xAAA70000000 || 0x4200000000 || 0x1000000 ||
|| 0x270000000
|| 0x270006000
|| 0x800000000
|| ee scratchpad
|-
|-
| ee_kmem0
| transcode|| 0x50000000 || 0xD00000000 || 0 || Recompiled EE code that gets executed.
|| 0x280000000
|| 0x282000000
|| 0x100000003
||
|-
|-
| ?
| transpc|| 0x10000000 || 0xE00000000 || 0 || Lookup Table which holds start addresses of recompiled blocks. If block is not in the table, it gets recompiled right when emulator tries to access it.
|| 0x291004000
|-
|| 0x291008000
| spc|| 0x40000000 || 0xE0000000 || 0x1000000 ||  
|| 0x300000000
|| vu1 data rw in kernel mode
|-
|-
| ?
| rsx|| 0xA0000000 || 0x80000000 || 0x1000000 ||
|| 0x29FC00000
|| 0x2A0000000
|| 0x300000000
|| ee_rom in kernel mode
|-
|-
| ?
| sb_mmio|| 0x60000000 || 0x60000000 || 0x1000000 ||
|| 0x2A0000000
|| 0x2A2000000
|| 0x100000003
|| ee_uncached in kernel mode
|-
|-
| ?
| io_work|| 0x80000000 || 0x70000000 || 0x1000000 ||
|| 0x2B1004000
|| 0x2B1008000
|| 0x300000000
|| vu1 data in kernel mode. Uncached, i doubt that is even accessible in ps2.
|-
|-
| ?
| ee_cached|| 0x200000000 || 0xFF00000000 || 0x1000000 ||
|| 0x2BFC00000
|| 0x2C0000000
|| 0x300000000
|| ee_rom in uncached kernel mode
|-
|-
| ee_dbg
| ee_mmio|| 0x210000000 || 0x300000000 || 0x1000000 ||
|| 0x2FFFF8000
|| 0x300000000  
|| 0x900000000
||
|-
|-
| iop_mem
| ee_uncached|| 0x220000000 || 0x100000000 || 0x1000000 ||
|| 0x400000000
|| 0x400200000
|| 0x400000003
||
|-
|-
| iop_rom
| ee_uncacc|| 0x230000000 || 0x100000000 || 0x1000000 ||
|| 0x4BFC00000
|| 0x4C0000000
|| 0x500000001
|| kernel mode
|-
|-
| iop_kmmio0
| ee_rsvd0 || 0x240000000 || 0xA00000000 || 0x1000000 ||
|| 0x4BF800000
|| 0x4BF810000
|| 0x500000001
|| including iop_spad at first 0x1000
|-
|-
| ?
| ee_rsvd1 || 0x250000000 || 0xA00000000 || 0x1000000 ||
|| 0x4AFC00000
|| 0x4B0000000
|| 0x500000001
|| iop_rom, uncached?
|-
|-
| iop_kmmio1
| ee_spr_lo|| 0x260000000 || 0x700000000 || 0x1000000 ||
|| 0x4AF800000
|| 0x4AF810000
|| 0x500000001
|| including iop_spad at first 0x1000
|-
|-
| spu2_ram
| ee_spr_hi|| 0x270000000 || 0x800000000 || 0x1000000 ||
|| 0x600000000
|| 0x600400000
|| 0x600000003
|| starting from 0x200000 spu2_ram2
|-
|-
| ?
| ee_kmem0 || 0x280000000 || 0xFF00000000 || 0x1000000 ||
|| 0x800000000
|| 0x800010000
|| 0x1000000001
||
|-
|-
| ?
| ee_kmmio0|| 0x290000000 || 0x300000000 || 0x1000000 ||
|| 0xC0000000
|| 0xCF800000
|| 0x1600000003
||
|-
|-
| sgs_xdr
| ee_kmem1 || 0x2A0000000 || 0x100000000 || 0x1000000 ||
|| 0xB4000000
|| 0xB5700000
|| 0x1900000003
||
|-
|-
| ?
| ee_kmmio1|| 0x2B0000000 || 0x300000000 || 0x1000000 ||
|| 0x40000000000
|| 0x40000010000
|| 0x1400000001
||
|-
|-
| ee_jit_code
| ee_krsvd0|| 0x2C0000000 || 0xA00000000 || 0x1000000 ||
|| 0x10000000
|| 0x13000000
|| 0xD00000003
||
|-
|-
| vu0_jit_code
| ee_krsvd1|| 0x2D0000000 || 0xA00000000 || 0x1000000 ||
|| 0x18000000
|| 0x18400000
|| 0xD00000003
||
|-
|-
| vu0_jit_data
| ee_krsvd2|| 0x2E0000000 || 0xA00000000 || 0x1000000 ||
|| 0x1C000000
|| 0x1C400000
|| 0xD00000003
||
|-
|-
| eeram_jit_lut
| ee_dbg || 0x2F0000000 || 0x900000000 || 0x1000000 ||
|| 0x20000000
|| 0x22000000
|| 0xE00000003
||
|-
|-
| eerom_jit_lut
| iop_mem|| 0x400000000 || 0x400000000 || 0x1000000 ||
|| 0x2FC00000
|| 0x30000000
|| 0xE00000003
||
|-
|-
| ustack (micro stack)
| iop_kmmio0 || 0x4B0000000 || 0x500000000 || 0x1000000 ||
|| 0xAAA70000000
|| 0xAAA70040000
|| 0x4200000000001
|| Thread KRN0:1 (aka BOOT00)
|-
|-
| ustack (micro stack)
| iop_kmmio1 || 0x4A0000000 || 0x500000000 || 0x1000000 ||
|| 0xAAA70040000
|| 0xAAA70080000
|| 0x4200010000001
|| Thread KRN1:1 (aka BOOT01)
|-
|-
| ustack (micro stack)
| spu2_mem || 0x600000000 || 0x600000000 || 0x1000000 ||
|| 0xAAA70080000
|| 0xAAA700C0000
|| 0x42000B0000001
|| VU0 stack (used in EEonBE when VU0 is running)
|-
|-
| ustack (micro stack)
| spu2_pcm || 0x800000000 || 0x1000000000 || 0x1000000 ||
|| 0xAAA700C0000
|| 0xAAA70100000
|| 0x4200030000001
|| Thread SYS
|-
|-
| ustack (micro stack)
| rsx_xdr|| 0xA00000000 || 0x1500000000 || 0x1000000 ||
|| 0xAAA70100000
|| 0xAAA70140000
|| 0x4200040000001
|| Thread VRC
|-
|-
| ustack (micro stack)
| rsx_ddr|| 0x900000000 || 0x1600000000 || 0x1000000 ||
|| 0xAAA70140000
|| 0xAAA70180000
|| 0x4200050000001
|| Thread MECHA
|-
|-
| ustack (micro stack)
| vrc_area || 0x90000000 || 0xC00000000 || 0x1000000 ||
|| 0xAAA70180000
|| 0xAAA701C0000
|| 0x4200060000001
|| Thread HDD
|-
|-
| ustack (micro stack)  
| ioptrace || 0x40000000000 || 0x1400000000 || 0x1000000 ||
|| 0xAAA701C0000
|-
|| 0xAAA70200000
|}
|| 0x4200070000001
===Emu===
|| Thread UI
{| class="wikitable" style="font-size:small;"
|-
! Name !! Start EA !! Size !! Flags !! Notes
|-
| work          || 0x0 ||        0x2000000(32MB) || 0x200000000 || 64MB minus below allocations (up to user stack 10). Minimum 32MB.
|-
| spider work  || 0x30000000 ||  0x600000(6MB) ||  0x600000000 || (sb work)
|-
| iop ram      || 0x100000000 || 0x200000(2MB) ||  0x600000000 ||
|-
| ps2 rom      || 0x200000000 || 0x400000(4MB) || 0x600000000 ||
|-
|-
| ustack (micro stack)
| spu2 ram      || 0x70000000 || 0x200000(2MB) || 0x600000000 ||
|| 0xAAA70200000
|| 0xAAA70280000
|| 0x4200090000001
|| Thread BL2LNK and BL2MAIN
|-
|-
| ustack (micro stack)
| spu2 ram2    || 0x70200000 || 0x200000(2MB) || 0x600000000 ||
|| 0xAAA70280000
|| 0xAAA702C0000
|| 0x42000A0000001
|| Thread USB
|-
|-
| ustack (micro stack)
| pcm work      || 0x80000000 || 0x100000(1MB) || 0x600000000 ||
|| 0xAAA702C0000
|| 0xAAA70300000
|| 0x42000B0000001
|| Thread EEonBE
|-
|-
|}
| menu work    || 0x90000000 ||  0x400000(4MB) ||  0x600000000 ||
 
|-
== Negmem ==
| user stack 0  || 0x10100000 ||  0x100000(1MB) ||  0x600000000 ||
 
|-
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!
| user stack 1  || 0x10300000 ||  0x100000(1MB) ||  0x600000000 ||
 
|-
| user stack 2  || 0x10500000 ||  0x100000(1MB) ||  0x600000000 ||
|-
| user stack 3  || 0x10700000 ||  0x100000(1MB) ||  0x600000000 ||
|-
| user stack 4  || 0x10900000 ||  0x100000(1MB) ||  0x600000000 ||
|-
| user stack 5  || 0x10B00000 ||  0x100000(1MB) ||  0x600000000 ||
|-
| user stack 6  || 0x10D00000 ||  0x100000(1MB) ||  0x600000000 ||
|-
| user stack 7  || 0x10F00000 ||  0x100000(1MB) ||  0x600000000 ||
|-
| user stack 8  || 0x11100000 ||  0x100000(1MB) ||  0x600000000 ||
|-
| user stack 9  || 0x11300000 ||  0x100000(1MB) ||  0x600000000 ||
|-
| user stack 10 || 0x11500000 ||  0x100000(1MB) ||  0x600000000 ||
|-
| sb mmio      || 0x20000000 ||          ?(?MB) ||            ? ||
|-
| spc area      || 0x40000000 ||          ?(?MB) ||            ? ||
|-
| rsx mmio      || 0x50000000 ||          ?(?MB) ||            ? ||
|-
| rsx gcmbar1  || 0x60000000 ||          ?(?MB) ||            ? ||
|-
| memcard      || 0x300000000 || 0x1100000(17MB) ||          ? || Allocated much later than above memory.
|-
|}
 
== 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.
Negmem memory map.


Line 3,227: Line 2,848:
Notice that GS Base Fragment program is really not fragment shader, but pixel shader.
Notice that GS Base Fragment program is really not fragment shader, but pixel shader.


===Gxemu===
===Gxemu===
  CG_fp_dilate        F
  CG_fp_dilate        F
  CG_fp_shrink        F
  CG_fp_shrink        F
  CG_fp_adjweave      F
  CG_fp_adjweave      F
  CG_fp_motionadj    F
  CG_fp_motionadj    F
  CG_fp_undither      F
  CG_fp_undither      F
  CG_fp_deinterlace  F  x
  CG_fp_deinterlace  F  x
  CG_fp_weave        F
  CG_fp_weave        F
  CG_fp_edgeinterp    F
  CG_fp_edgeinterp    F
  CG_fp_smooth        F
  CG_fp_smooth        F
  CG_fp_sharpen      F  x
  CG_fp_sharpen      F  x
  CG_fp_upscale_smart F  x
  CG_fp_upscale_smart F  x
  CG_fp_upscale      F  x
  CG_fp_upscale      F  x
  CG_fp_smart        F  x
  CG_fp_smart        F  x
  CG_fp_mofix        F  x
  CG_fp_mofix        F  x
  CG_fp_orientation  F  x
  CG_fp_orientation  F  x
  CG_fp_gradient      F  x
  CG_fp_gradient      F  x
  CG_vpshader        V  x
  CG_vpshader        V  x
  CG_interlace        F
  CG_interlace        F
  CG_fpshader16      F
  CG_fpshader16      F
  CG_fpshader        F  x
  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) ==


Plus 2 unnamed shaders, one F, one V.<br>
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.
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===
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.
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 ==
Is the IOP really fully emulated via software in CECHA/CECHB consoles?


* '''Disable GS downloads.'''<br>
* 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)
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.


===Discussion===
* 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.
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.
** 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)
*Example for TOCA3 SLUS which use hard coded offset:
***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).
004C55F0 00000000
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.
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)

Latest revision as of 18:19, 21 December 2024

Game CONFIG commands (notepad and worklog)[edit source]

Moved to Talk:PS2_Emulation/PS2_Config_Commands

XMB messages related with PS2 Emulation[edit source]

explore_category_sysconf.rco\Text\English.xml
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>
game_ext_plugin.rco\Text\English.xml
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>
explore_plugin_full.rco\Text\English.xml
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[edit source]

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

Getting Playstation 2 Software Emulator working[edit source]

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
   p3dwik-ps2compatfiles.rar
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:


boot_ps2[edit source]

http://foxbrew.org/ps3/otheros-utils/boot_ps2.git
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[edit source]

[Getting Playstation 2 Software Emulator working]

XMB Game Settings non BC/BC,patched


























Service Mode in relation to PS2 emulation tests[edit source]

  • 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[edit source]

Testplatform: 

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[edit source]

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)[edit source]

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[edit source]

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)[edit source]

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[edit source]

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[edit source]

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

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



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[edit source]

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[edit source]

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.
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[edit source]

Netemu[edit source]

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

Notes:
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.

r5900 regs memory map[edit source]

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[edit source]

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[edit source]

Netemu[edit source]

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. Addresses not described below are handled as a unk rw. Which mean they return 0 on read, and do nothing on write.

  • 1000F800 do nothing (blr). Have own handler, which suggest it was used for something earlier. [r/w]
  • 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]
  • 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.

  • 1000F860 seems to return halfword of current pad state (0xFFFF if there is no button input currently). [r only]
  • 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[edit source]

IOP SPE[edit source]

This SPE run not only dma related stuff, but also fully fledged r3000 instruction interpreter (yes interpreter, not recompiler). 

  opcode      | address
--------------+--------  
r3000_ADDI      0x317C0
r3000_ADDIU     0x31800
r3000_SLTI      0x31840
r3000_SLTIU     0x31880
r3000_ANDI      0x318C0
r3000_ORI       0x31900
r3000_XORI      0x31940
r3000_LUI       0x31980
r3000_ADD       0x319C0
r3000_ADDU      0x31A00
r3000_SUB       0x31A40
r3000_SUBU      0x31A80
r3000_SLT       0x31AC0
r3000_SLTU      0x31B00
r3000_AND       0x31B40
r3000_OR        0x31B80
r3000_XOR       0x31BC0
r3000_NOR       0x31C00
r3000_SLL       0x31C40
r3000_unk1      0x31C80 Primary opcode field (Bit 26..31) = 0x3E (debug stuff, not existing on real r3000)
r3000_unk2      0x31CC0 Primary opcode field (Bit 26..31) = 0x3F (debug stuff, not existing on real r3000)
r3000_SRL       0x31D00
r3000_SRA       0x31D40
r3000_SLLV      0x31D80
r3000_SRLV      0x31DC0
r3000_SRAV      0x31E00
r3000_MULT      0x31E40
r3000_MULTU     0x31F00
r3000_DIV       0x31F80
r3000_MFHI      0x32080
r3000_MFLO      0x320C0
r3000_MTHI      0x32100
r3000_MTLO      0x32140
r3000_J         0x32180
r3000_JAL       0x32200
r3000_JR        0x32280
r3000_JALR      0x322C0
r3000_BEQ       0x32300
r3000_BNE       0x32340
r3000_BLEZ      0x32380
r3000_BGTZ      0x323C0
r3000_BcondZ    0x32400
r3000_SYSCALL   0x32480
r3000_BREAK     0x324C0
r3000_COP_bad   0x32500
r3000_COP0      0x32540
r3000_bad_op    0x32740
r3000_LB        0x32840
r3000_LH        0x32940
r3000_LW        0x32A40
r3000_LBU       0x32B80
r3000_LHU       0x32C80
r3000_LWL       0x32D80
r3000_LWR       0x32E80
r3000_SB        0x32F80
r3000_SH        0x33080
r3000_SW        0x33180
r3000_SWL       0x33300
r3000_SWR       0x33400

Addresses above ARE NOT the ones in emulator memory, this is local storage address in IOP SPE program! 
Opcodes LWCx 0-3, and SWCx 0-3 are not supported at all.
Same goes for general COP 1-3 opcodes, but those cause COPx unusable r3000 exception.
While LWC/SWC are triggering bad opcode exception.
Not sure if LWC0/SWC0 should be allowed.
COP0 is working in PS2 mode, so those probably shouldn't cause exception.
At the second hand i don't know single IOP module that use that instruction.

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

Cache write (IOPADDR/LSADDR/SIZE)
Cache read  (IOPADDR/LSADDR/SIZE)
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.

EEDMA on SPE3[edit source]

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, 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.
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[edit source]

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

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[edit source]

IDEC start code detection[edit source]

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[edit source]

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

SPE4 and SPE5[edit source]

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[edit source]

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[edit source]

ps2_netemu supported video modes[edit source]

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[edit source]

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[edit source]

Remove PCRTC Blur for Netemu[edit source]

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.

Patch is for Evilnat 4.90 ps2_netemu.elf file.
https://www.mediafire.com/file/s83lt9zkwlyhpc2/No_Blur.ppf/file

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[edit source]

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[edit source]

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

ps2_netemu: 

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

ps2_gxemu 

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[edit source]

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.

Now: 

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)

Compacted: 

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 

38D891A6A67F9275D1B6D18E04BDCAA7

gxemu.elf MD5 after patch 

B452CCB51348127DAF8A931B621E5E39

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

Patch System Manager to allow PS2 emulators Fan Control[edit source]

Patch is for LV1 file, should be 4.75+ but it's based on 4.78 LV1 file. Don't try to modify your LV1 without hardware flasher! This patch enables ability to get fan readings and to set fan speed and policy. This patch doesn't implement fan controls from webman to work in ps2 mode, additional code needs to be patched on PS2 emulators side to make something useful from it.

Search for (4.78 LV1): 

E8 03 01 C8 54 00 05 EE  2F A0 00 00 41 9E 00 E4

Replace to (4.78 LV1): 

E8 03 01 C8 54 00 05 EE  2F A0 00 00 60 00 00 00

Inject LIBSD into netemu Bios[edit source]

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[edit source]

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.

https://pastebin.com/x8fvY1UL

Random ps2_netemu notes[edit source]

  • 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[edit source]

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. 

r0  = 0x200000000, used when recompiler load something directly from EE memory.
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 = r5900_current_pc
r15 = r5900 pc >> 6, used for cache checks. r15 is also used as temp register when fallback to interpreter, etc. 
r16 = r5900_v0_reg_lower64
r17 = r5900_v1_reg_lower64
r18 = r5900_a0_reg_lower64
r19 = r5900_a1_reg_lower64
r20 = r5900_a2_reg_lower64
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.


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[edit source]

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[edit source]

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 word is ppc instruction that caused exception.
  • Code now read extended opcode (XOP) field to figure out instruction type ((code >> 1) & 0x3FF)
  • When matching xop 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[edit source]

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[edit source]

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)
      • 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. --Kozarovv (talk) 14:48, 29 June 2023 (CEST)

Netemu load/store with r0 register[edit source]

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 in 64 bit mode) 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", loads/stores with r0 starting to make sense. 

std       r4, 0x3008(r0) # store r4 on 0x3008, 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.

Communication with Graphics Synthesizer in ps2_gxemu[edit source]

Communication from emu level is done with rw to special addresses of what seems to be RSX ports. Emu includes thin translation layer that intercept rw operations to GS privilaged registers. 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.

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. 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. 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.[edit source]

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.

Universal DNAS anti-wipe patch[edit source]

Tested with 2.8.0 and 3.0.0 DNAS libraries. EESYNC wipes the memory from 0x00084000 to 0x00100000. Patch is needed for 0x42 command to work with DNAS games when the overlay is installed in this memory region. 

Original: 18 00 A2 AF 95 00 00 0C 1C 00 A0 AF
Patched:  18 00 A2 AF 01 00 02 24 1C 00 A0 AF

Accurate ADD/SUB[edit source]

Emulator need accurate math for PS2 floating points operations because PS2 FPU/VU are special (partially also PS3 SPEs, but that's story for different wiki page). PS3 VMX unit in PPU have special compatibility mode with SPU, activated by lv1_set_vmx_graphics_mode(1) hvcall. This is supposed to make floating points operations results as close to SPU as possible. This set default rounding mode to round to zero, denormals are treated as zero, and there are no infinities or NaNs. So practically same mode as PS2 use. Every PS2 EE emulator on PS3 use this mode as otherwise many of that need to be done by software which is inconvenient, and tank performance. There are some suggestions that Sony requested this mode from IBM specifically for PS2 emulators. At this point floats should be handled like on PS2 right? Nope. PS2 FPU/VU is even more "special" than that, and it seems that Sony missed, or IBM wasn't able to implement that. What is so special? Since PS2 guarantee to round to zero, there is no need for 3 guard bits (more precisely guard/round/sticky bits). Testing shows that PS2 use only 1 of those bits in way known from other platforms. This makes every FPU/VU ADD/SUB/MUL/DIV operation possibly inaccurate on hardware other than PS2. There is no way to reproduce that on hardware that is not created with that in mind. No matter it is PS3 VMX, or x86/ARM SSE/AVX. This behavior is not reproductible on currently used hardware without software approach. But this still doesn't sound that bad, how much developers can rely on bit precise floating point results? 80 from 788 ps2_gxemu configs is using accurate math command, and that's only small chunk of what is really needed. Not to mention direct patches like Persona 4, etc, and tons of custom configs.

Here is function used when accurate ADD/SUB math is requested: https://pastebin.com/sX6vfxin This code run for EVERY SINGLE add/sub separately when opcode is in command range.
Recompiled code for eg. fpu add d,c,b looks like this: 

vaddfp d,c,b

While recompiled code for accurate fpu add d,c,b looks like this (simplified): 

lis a,0xXXXX
ori a,a, 0xXXXX
stvx b,a, 0x0
add a,0x10
stvx c,a, 0x0
bla https://pastebin.com/sX6vfxin
lis a,0xXXXX
ori a,a, 0xXXXX
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[edit source]

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. 

Original: 4B FF 1A 11 38 81 00 A0 38 61 00 AC 4B FF ED 3D
Patched:  60 00 00 00 38 81 00 A0 38 61 00 AC 4B FF ED 3D

Unknown VIF issue - bad cmd[edit source]

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.

  • 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.
  • 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.
  • 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: 

0x14D00  ila     r4, 0x2000
0x14D04  shufb   r2, r104, r104, r89
0x14D08  ila     sp, sub_147C0
0x14D0C  a       r2, r2, r77
0x14D10  shufb   r2, r103, r102, r2
0x14D14  stqa    r2, VIF1_CODE
0x14D18  lqa     r2, VIF1_ERR
0x14D1C  lqa     r3, VIF1_STAT
0x14D20  andi    r2, r2, 4          ; VIF1_ERR.ME1
0x14D24  ceqi    r2, r2, 0          ; set if bad cmd is unmasked
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.--Mrjaredbeta (talk) 03:37, 12 February 2023 (CET)

Games with EE threading/interrupt issues[edit source]

  • Def Jam: Fight for NY
    • Random hangs on first loading sequence.
  • Visual Mix: Ayumi Hamasaki Dome Tour 2001
    • Random hangs during loading transitions.
  • Harry Potter and the Chamber of Secrets
    • Seems to randomly hang on the last stage of loading (ra=0x19bf70). WaitSema calls spotted during the hang.
  • Gran Turismo 4
    • Hangs during the FMV playback on the idle wait loop. Game does wait for the interrupt that does not happen, probably.
      • Game wait in 81FC0 loop or some custom one? Never leave it? --Kozarovv (talk) 19:01, 11 April 2023 (CEST)
        • 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.--Agrippa (talk) 19:39, 11 April 2023 (CEST)

Assuming the game programming is right, the underlying issues are data transfer related, probably.

Games with GS emulation issues[edit source]

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[edit source]

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. 

Stuntman US
0x100000-0x1c5e68 - no change

0x1c5e6c - improvement in ApplyTyreForces__5WheelR3CarffG4MAv3N24R4MAm4Rf
  vadd.xyzw vf01, vf01, vf02
0x1c7128 - improvement in Update__5WheelR3CarR4MAm4R4MAv3T3
  vadd.xyzw vf01, vf01, vf02
0x1c727c - imrpovement in Update__5WheelR3CarR4MAm4R4MAv3T3
  vadd.xyzw vf01, vf01, vf02
    - both of the above with the others make most accurate path
    - vm insts 0x1c6e78-0x1c6ecc basically negate this additional accuracy?

0x1c769c-0x211f04 - nothing

0x211f08 - improvement in _dyForwardDynamics__FP10DYdynamicsf
  vadd.xyzw vf02, vf02, vf01
0x211f94 - improvement in dyStepRunge1__FP10DYdynamicsf
  vadd.xyzw vf04, vf04, vf01

0x2140b0-0x215118 - no change

0x215118 - obUpdateTransMatrix__FP8OBobject
    - negates additional accuracy of Update__5WheelR3CarR4MAm4R4MAv3T3?

0x215260-0x1ffffff - no change

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. --Kozarovv (talk) 20:03, 4 January 2023 (UTC)

Patches for SCCS region games[edit source]

Most Chinese region games (SCCS) require the ROM2 modules to be present. However, even if they are required by the game in order to boot, they are not needed at all and are fully playable without ROM2 the vast majority of the time. I have compiled patches for all SCCS games that allow each one to at least boot on PS3 and PCSX2 (older versions, or newer ones without the correct BIOS) by simply skipping over the infinite loops the games get caught in: https://www.mediafire.com/file/skdka574f23b96g/SCCS_patches.zip/file

Mostly untested on PS3, but all have been tested on an older PCSX2 version. 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. In the end, only two games ended up having text bugs due to the character data not being loaded from ROM2:

Serial Number Game Bootable (without patch) ROM2 required
SCCS-40001 Ape Escape 2 No Yes (missing text)
SCCS-40002 Devil May Cry 2 (Disc 1) No No
SCCS-40003 Devil May Cry 2 (Disc 2) No No
SCCS-40004 XIGO: Zuihou de Touzi No No
SCCS-40005 Ico No No
SCCS-40006 Zhen Sanguo Wushuang 2 No No
SCCS-40007 Arc the Lad: Seirei no Tasogare No No
SCCS-40009 Dragon Ball Z 2 Yes No
SCCS-40010 Super Puzzle Bobble 2 No No
SCCS-40011 Armored Core 2: Another Age No No
SCCS-40014 World Soccer Winning Eleven 7 International No No
SCCS-40015 Viorate no Atelier: Gramnad no Renkinjutsushi 2 No Yes (text bugs)
SCCS-40016 Ape Escape: Pumped & Primed Yes No
SCCS-40017 EyeToy: Play No EyeToy game
SCCS-40018 Saru EyeToy Oosawagi: Wakki Waki Game Tenkomori!! No EyeToy game
SCCS-40019 Formula One 04 No No (English)
SCCS-40022 World Soccer Winning Eleven 8: Asia Championship No No
SCCS-60002 Gran Turismo 4 No No
  • 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. :) --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. --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. --Kozarovv (talk) 17:39, 20 June 2023 (CEST)

Removing stuff from ps2 emu page[edit source]

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 Done.

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 --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. --Mrjaredbeta (talk) 15:12, 16 January 2023 (UTC)

Floating point arithmetic inaccuracies[edit source]

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[edit source]

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[edit source]

We can't really modify this flag from outside on retail emu, but we can always patch function that do init.

Netemu[edit source]

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[edit source]

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[edit source]

Netemu[edit source]

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.

Name Start EA End EA 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 Recompiled EE code that gets executed.
vu0_jit_code 0x18000000 0x18400000 0xD00000003 Recompiled VU0 micro code that is executed.
vu0_jit_data 0x1C000000 0x1C400000 0xD00000003
eeram_jit_lut 0x20000000 0x22000000 0xE00000003 Lookup Table which holds start addresses of recompiled blocks. If block is not in the table, it gets recompiled right when emulator tries to access it.
eerom_jit_lut 0x2FC00000 0x30000000 0xE00000003 EE ROM Lookup Table which holds start addresses of recompiled blocks. If block is not in the table, it gets recompiled right when emulator tries to access it.
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

Gxemu[edit source]

Name Start EA Unk (lpar?) Unk Notes
work 0 0 0
vu0_direct 0x30000000 0x30000000 0x1000000
ustack 0xAAA70000000 0x4200000000 0x1000000
transcode 0x50000000 0xD00000000 0 Recompiled EE code that gets executed.
transpc 0x10000000 0xE00000000 0 Lookup Table which holds start addresses of recompiled blocks. If block is not in the table, it gets recompiled right when emulator tries to access it.
spc 0x40000000 0xE0000000 0x1000000
rsx 0xA0000000 0x80000000 0x1000000
sb_mmio 0x60000000 0x60000000 0x1000000
io_work 0x80000000 0x70000000 0x1000000
ee_cached 0x200000000 0xFF00000000 0x1000000
ee_mmio 0x210000000 0x300000000 0x1000000
ee_uncached 0x220000000 0x100000000 0x1000000
ee_uncacc 0x230000000 0x100000000 0x1000000
ee_rsvd0 0x240000000 0xA00000000 0x1000000
ee_rsvd1 0x250000000 0xA00000000 0x1000000
ee_spr_lo 0x260000000 0x700000000 0x1000000
ee_spr_hi 0x270000000 0x800000000 0x1000000
ee_kmem0 0x280000000 0xFF00000000 0x1000000
ee_kmmio0 0x290000000 0x300000000 0x1000000
ee_kmem1 0x2A0000000 0x100000000 0x1000000
ee_kmmio1 0x2B0000000 0x300000000 0x1000000
ee_krsvd0 0x2C0000000 0xA00000000 0x1000000
ee_krsvd1 0x2D0000000 0xA00000000 0x1000000
ee_krsvd2 0x2E0000000 0xA00000000 0x1000000
ee_dbg 0x2F0000000 0x900000000 0x1000000
iop_mem 0x400000000 0x400000000 0x1000000
iop_kmmio0 0x4B0000000 0x500000000 0x1000000
iop_kmmio1 0x4A0000000 0x500000000 0x1000000
spu2_mem 0x600000000 0x600000000 0x1000000
spu2_pcm 0x800000000 0x1000000000 0x1000000
rsx_xdr 0xA00000000 0x1500000000 0x1000000
rsx_ddr 0x900000000 0x1600000000 0x1000000
vrc_area 0x90000000 0xC00000000 0x1000000
ioptrace 0x40000000000 0x1400000000 0x1000000

Emu[edit source]

Name Start EA Size Flags Notes
work 0x0 0x2000000(32MB) 0x200000000 64MB minus below allocations (up to user stack 10). Minimum 32MB.
spider work 0x30000000 0x600000(6MB) 0x600000000 (sb work)
iop ram 0x100000000 0x200000(2MB) 0x600000000
ps2 rom 0x200000000 0x400000(4MB) 0x600000000
spu2 ram 0x70000000 0x200000(2MB) 0x600000000
spu2 ram2 0x70200000 0x200000(2MB) 0x600000000
pcm work 0x80000000 0x100000(1MB) 0x600000000
menu work 0x90000000 0x400000(4MB) 0x600000000
user stack 0 0x10100000 0x100000(1MB) 0x600000000
user stack 1 0x10300000 0x100000(1MB) 0x600000000
user stack 2 0x10500000 0x100000(1MB) 0x600000000
user stack 3 0x10700000 0x100000(1MB) 0x600000000
user stack 4 0x10900000 0x100000(1MB) 0x600000000
user stack 5 0x10B00000 0x100000(1MB) 0x600000000
user stack 6 0x10D00000 0x100000(1MB) 0x600000000
user stack 7 0x10F00000 0x100000(1MB) 0x600000000
user stack 8 0x11100000 0x100000(1MB) 0x600000000
user stack 9 0x11300000 0x100000(1MB) 0x600000000
user stack 10 0x11500000 0x100000(1MB) 0x600000000
sb mmio 0x20000000 ?(?MB) ?
spc area 0x40000000 ?(?MB) ?
rsx mmio 0x50000000 ?(?MB) ?
rsx gcmbar1 0x60000000 ?(?MB) ?
memcard 0x300000000 0x1100000(17MB) ? Allocated much later than above memory.

Negmem[edit source]

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[edit source]

V for Vertex, F for Fragment, P for Pixel

Netemu[edit source]

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[edit source]

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[edit source]

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.
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[edit source]

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[edit source]

  • Disable GS downloads.

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.

  • Disable PCRTC blur.

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: Link


Discussion[edit source]

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 --Kozarovv (talk) 22:00, 8 August 2023 (CEST)

IOP Handling in ps2_emu? (CECHA/CECHB)[edit source]

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

Retrieved from "http://www.psdevwiki.com/ps3/index.php?title=Talk:PS2_Emulation&oldid=74716"