Editing Talk:PS2 Emulation
Jump to navigation
Jump to search
The edit can be undone. Please check the comparison below to verify that this is what you want to do, and then publish the changes below to finish undoing the edit.
Latest revision | Your text | ||
Line 1: | Line 1: | ||
==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 | |||
===ps2_netemu command 0x1=== | |||
There are some additional internal patches using CONFIG cmd id 0x01, using subs not available in 0x3B list | |||
condition: 0xBBB5F800, 0x3B949C00, 0x42133A90 | |||
setting: | |||
0x18E1F0, sub_4670C (4.70) | |||
0x348EC8, sub_44338 (4.70) | |||
====Function Mapping==== | |||
ps2_netemu.self contains a table (with entry_length=8 and entry_number=variable) where are listed the function offsets used by config command 0x01 | |||
This table is used to assign a funct_id to a funct_offset. The funct_id is given by the position of the entry in the table, so the first entry in the table is funct_id=0x00, second entry is funct_id=0x01 and so on | |||
The purpose of this table is to be able use the same funct_id values in the external CONFIG files for netemu, this way even if the func_offset changes in between versions (internally inside the ps2_netemu.self file structure) the funct_id will be the same. The other ps2 emulator types doesnt have this table (doesnt needs it because doesnt uses external CONFIG files) | |||
*funct_offset_table location by ps2_netemu versions: | |||
**Table v1 (the table contains the same data) | |||
***Firmware:370-374 offset:0x897ED8 length:0x1C8 | |||
**Table v2 (the table contains the same data) | |||
***Firmware:400-401 offset:0x8970E8 length:0x1C8 | |||
**Table v3 (the table contains the same data) | |||
***Firmware:410-411 offset:0x8971E8 length:0x1C8 | |||
***Firmware:420-425 offset:0x8972F8 length:0x1C8 | |||
**Table v4 | |||
***Firmwares 4.30 up to 4.76 was not tested (if someone wants to add this info do it here) | |||
**Table vX (latest) | |||
***Firmware:478-488 offset:0x8063f8 length:0x1E0 | |||
Example from ps2_netemu.self 4.88 | |||
<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" | |||
! 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 | |||
|- | |||
| 0x00 || 0x46720 || 0x42E00 || 0x42EB8 || 0x42F70 || 0x36B40 || 0x2FEF0 | |||
|- | |||
| 0x01 || 0x42DB0 || 0x42EC4 || 0x42F7C || 0x43034 || 0x35FB0 || 0x31E38 | |||
|- | |||
| 0x02 || 0x44394 || 0x4456C || 0x44560 || 0x447C0 || 0x34068 || 0x30220 | |||
|- | |||
| 0x03 || 0x442B4 || 0x4448C || 0x44480 || 0x446E0 || 0x34144 || 0x302FC | |||
|- | |||
| 0x04 || 0x43100 || 0x43214 || 0x432CC || 0x43384 || 0x33F98 ? || 0x30150 | |||
|- | |||
| 0x05 || 0x46A90 || 0x46DB4 || 0x47184 || 0x4745C || 0x36CF8 || 0x31D08 | |||
|- | |||
| 0x06 || 0x46D64 || 0x46AE0 || 0x46934 || 0x46D20 || 0x34224 || 0x303DC | |||
|- | |||
| 0x07 || 0x47134 || 0x47154 || 0x47524 || 0x47C1C || 0x37850 || | |||
|- | |||
| 0x08 || 0x42E7C || 0x42F90 || 0x43048 || 0x43100 || 0x33DFC<!--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" | |||
! 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==== | |||
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) | |||
===ps2_netemu command 0x4=== | |||
Patch SPE 3 program (eedma) by searching for ila r4, xxxxx, starting at 0x178A0 and replacing them with (0x42000004 | ((value << 7) & 0x1FFFF80)<br> | |||
0x42000004 is ila r4 opcode. Due to opcode encoding example result of that patch with value 0x08 will be 0x42000404 (ila r4, 0x08). | |||
There is little bit more than that, but main purpose is just to patch SPE program behavior. | |||
* What are the valid values? The official config from The Suffering uses a 0x8 value, yet the flashing does still happen. Increasing it to 0x20 seems to fix the flashing.--[[User:Agrippa|Agrippa]] ([[User talk:Agrippa|talk]]) 14:42, 22 February 2022 (UTC) | |||
** 0x00 - 0x3FFFF. Well you can use higher values, but it will be truncated by mask to something below 0x40000 anyway. Default is 0x12345 if i understand correctly. --[[User:Kozarovv|Kozarovv]] ([[User talk:Kozarovv|talk]]) 16:29, 22 February 2022 (UTC) | |||
===ps2_netemu command 0x5=== | |||
The external config format used by ps2_netemu.self doesnt supports command ID 0x5. But this same command with a different ID (0x4) was used by this game configs embedded inside ps2_gxemu.self: Grand Theft Auto: Liberty City Stories (SLES-54135, SLES-54136, SLUS-21423), Grand Theft Auto: Vice City Stories (SLES-54622, SLES-54623, SLUS-21590), Hunter: The Reckoning Wayward (SLES-51823), Onimusha: Dawn of Dreams (SLPM-66275), Shinseiki Evangelion: Ayanami Ikusei Keikaku with Asuka Hokan Keikaku (SLPM-65340), Tekken Tag Tournament (SLUS-20001). The reason why this command is not supported in the external config files is because the related emulator code is enabled permanently in ps2_netemu.self for all games | |||
This command patches EEDMA SPE program during emulator init (0x1F77C in latest netemu) to set different handling for DIRECT/DIRECTHL VIF1 commands. Weird solution, wasn't better to just change pointers in spe program instead of patching that on init? | |||
* Is there any way to patch the emulator to prevent that command to apply? I wonder if it is affecting the behaviour of some games.--[[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 | |||
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. | |||
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 0x0C=== | |||
These pairs of parameters: 0x0001 and 0x0400; 0x0001 and 0x0800; 0x0001 and 0x0180 fix few missing sound effects in the Klonoa 2. The side effect is slightly longer loading times in general. This game is known for its various audio buffer issues related to the CDVD speed. | |||
* I actually suspected this can be some delay for reads, but default value is (1, 0x1000) so doesn't really fit for delay. Since Shadowman 2 use it, and have known CD issue. Testing Shadowman2 without config can be interesting, if i'm right there will be a lot of broken textures right after you take control of main character. With broken Shadowman2 it will be easy to know that lower values are "better" or higher values are "better". That should help to understand what's going on. Assuming that SM2 really break without config... --[[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. | |||
The ingame FMVs with the graphic overlay are still stuttering heavily, though, and I am still unsure why. It seems like the shorter FMVs run fine, and the longer they are they more they have slowdown/stutter. This only applies to the "ingame" FMVs and not the opening ones. | |||
===ps2_netemu command 0x12=== | |||
First 8 bytes of that command are special flags. Not quite sure about bytes 5-8 yet, because at some point they are used to "andc" with first 4 bytes. | |||
Some examples for first 4 bytes: | |||
0x100000 = Different code path for VU0 opcodes that do ADD/SUB with multiply (MSUB, MADDA, etc.). | |||
0x200000 = Run some additional code in VU0 load/store opcodes (ILW, LQI, ISWR, etc.) | |||
0x400000 = Skip emu syscall 3 (3) | |||
0x800000 = Skip emu syscall 3 (4) | |||
0x4000000 = This flag ensure that type 2 config from cmd 0x12 will run. Otherwise it seems to be skipped. | |||
0x8000000 = Run some additional code for VU0 DIV opcode | |||
0x30000000 = Different code path for VU0 MUL opcodes, include opcodes like MSUB for mul part. So 0x30100000 work for mul, and sub part. | |||
0x10000000 and 0x20000000 also work for that purpose, emu just check for any active bits after applying 0x30000000 mask. | |||
Keep in mind that you still need to use at least 8 bytes for cmd 0x12, just use 00 for bytes 5,6,7,8. | |||
* Do the VU0 accuracy flags need any subcommands? Official 0x12 configs for the State of Emergency/Driving Emotion/The Getaway use 0x00021000 0x00000000 flag.--[[User:Agrippa|Agrippa]] ([[User talk:Agrippa|talk]]) 15:43, 9 March 2022 (UTC) | |||
** Flags are first 2 x 4 bytes of cmd 0x12. Config need at least 8 bytes, or it is ignored. There is no need for any subcommand. I suggest to not mess with second 4 bytes for now, and just use 00 00 00 00 as i'm not sure what is real usage of that yet (seems to be "disabler" mask for first 4 bytes, so they are use only one time). For now most aggressive config that use flags is Marvel Nemesis. After excluding 0x4000000 which trigger type 2 subcmd, config looks like this 00FFF000 00000000. --[[User:Kozarovv|Kozarovv]] ([[User talk:Kozarovv|talk]]) 05:42, 10 March 2022 (UTC) | |||
====type 1==== | |||
Playground discussion, unsure about clrlslwi r11, r0, 16,3 result | |||
<pre> | |||
Syphon Filter The Omega Strain | |||
298 00 00 00 00 | |||
29C 00 00 00 00 | |||
2A0 01 00>02 00< Type1, Count 2 | |||
2A4 31 00 99 18 | |||
2A8 32 00 B6 18 | |||
type 1: (Syphon Filter The Omega Strain ) | |||
*0x48 | ptr to 1st value *0x2A4 (0x15F) | |||
*0x50 | count of type values | |||
(0x18990031 >> 0xC) & 0xFFFF0 = 0x18990 | |||
(0x18B60032 >> 0xC) & 0xFFFF0 = 0x18B60 | |||
store value in [0x18990 + ??? ] | |||
seg017:0000000000198498 next_value: # CODE XREF: read_id0x12_type_1+120�j | |||
seg017:0000000000198498 lwz r0, 0(r10) # -> 0x18990031 | |||
seg017:000000000019849C addi r8, r8, 1 # counter | |||
seg017:00000000001984A0 ld r29, 0(r31) | |||
seg017:00000000001984A4 addi r10, r10, 4 # ptr to next value | |||
seg017:00000000001984A8 rlwinm r28, r0, 20,12,27 # r28 = (r0 >> 12) & 0xFFFF0 = (0x18990031 >> 12) & 0xFFFF0 = 0x18990 | |||
seg017:00000000001984AC clrlslwi r11, r0, 16,3 # r11 = 0x0031 << 3 = 0x188 | |||
seg017:00000000001984B0 add r26, r28, r29 # r26 = 0x18990 + ?? | |||
seg017:00000000001984B4 stw r11, 4(r26) # store 0x62000? or 0x188? in r26 | |||
seg017:00000000001984B8 lwz r5, 0x50(r31) # count | |||
seg017:00000000001984BC cmplw cr6, r5, r8 | |||
seg017:00000000001984C0 bgt cr6, next_value | |||
</pre> | |||
====type 2==== | |||
Fix for interlocking/synchronization EE with VU0 in micro mode. Usually used with games that are m bit sensitive, or loop endlessly on VU0 due to lack of sync with EE core. | |||
<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: | |||
*0x20C | counter | |||
*0x210 | 1st value: 0x15F -> only gets compared, if passed check 2nd value | |||
*0x214 | 2nd value: 0x2C6FBD8D -> only gets compared, if passed use *0x218 + *0x21C | |||
*0x218 | 1 ( = count - 2) | |||
*0x21C | ptr to 3rd value *0x2AC (0x367) | |||
First value is VU0 microprogram start address, multiply by 8 to get correct offset in VU0 micro mem. That one is confirmed, | |||
and you can check CMSAR0 register status in pcsx2 when EE hit address from type 3 command to make sure. Now some guessing. | |||
Second value is probably hash of microprogram (from start address to e bit end). | |||
Third value can be run cycles before program is force stopped, for example to wait on m bit for EE side to catch, or to stop endless | |||
loop that normally should already end if VU0 didn't run ahead of EE. | |||
Fourth and next values if available can be run cycles for next program runs. | |||
A lot of guessing here. But looking at games that use it, there is high possibility that is correct. | |||
This command is always used with type 3, or 4. This is probably not required, but without notifying EE side type 2 is useless. | |||
</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 | |||
---big handler, different register settings?--- | |||
===ps2_netemu command 0x22=== | |||
Weird command. Sets something 1 (CDVD/MECHA), but seems to never use it. | |||
===ps2_netemu command 0x29=== | |||
Something related with read time, maybe seek time. First value is meant to be lower than second value, but this is not requirement. | |||
Code that use it seems to delay some read/seek operation by multiply of first, or second value depending which sector is currently read (or maybe which part of disc actually). Here is code from one of fuctions that use values from that command, keep in mind that "mecha" is just fancy name for cdvd in that emu. | |||
if ((75 * cdvd.CrtSecond + 4500 * cdvd.CrtMinute + cdvd.CrtFrame - 150) >= *(mecha.unk_0x60)) | |||
a = *(cmd_0x29_val_2); | |||
else | |||
a = *(cmd_0x29_val_1); | |||
b = 4835703278458516699; // read https://munroesj52.github.io/vec__int64__ppc_8h.html (search on page for that number). | |||
c = (79800000 * a * b) >> 64; // 0x4C1A6C0 (79800000) is value that lv1 repo key be.clock return. | |||
d = c >> 18; // This and 2 above are generally used as a division by multiply. | |||
e = get_timebase_reg(); | |||
if ( e == 0 ) | |||
{ | |||
do | |||
e = get_timebase_reg(); | |||
while ( e == 0 ); | |||
} | |||
f = e - *(mecha.unk_0x24); | |||
if ( f >= d ) | |||
{ | |||
MECHA_update_status(mecha); | |||
result = unlock_sc06(0x8000LL); | |||
} | |||
else | |||
{ | |||
do | |||
e = get_timebase_reg(); | |||
while ( e == 0 ); | |||
*(mecha.unk_20) = d - f + e; | |||
*mecha.unk_00 = 5; | |||
result = unlock_sc06(0x8000LL); | |||
} | |||
===ps2_netemu command 0x2E=== | |||
Without this command applied there is a black screen and no sound after the PS2LOGO, but the game (Growlanser Generations) is working in the background. Pressing the "PS" button fixes it. After applying this command (0x172 parameter) everything works correctly. | |||
* this (like most "mecha" commands) is messing with timing. | |||
lwz r0, 0x2C(r31) # cmd_0x2E | |||
cmpwi cr7, r0, 0 | |||
beq cr7, cdvd_error_1349B4 # skip cdvd error if cmd not 0. | |||
nop | |||
loc_134988: | |||
mftb r9 | |||
cmpwi cr7, r9, 0 | |||
beq cr7, loc_134988 # Loop until timebase is not 0 | |||
clrldi r0, r0, 32 | |||
add r0, r0, r9 | |||
li r9, 5 | |||
std r0, 0x20(r31) # cmd_0x2E + timebase | |||
stw r9, 0(r31) | |||
b end_134844 | |||
Value from 0x20(r31) is later used in compare. That result in cdvd error, or in setting which seems schedule event to happen after time from timebase pass. This event is netemu syscall 8 (0x200) which is related to all ps2 cdvd reads. Tl;dr is that value give emulator some more time before cdvd error. Weird thing is that PS button fix it.. --[[User:Kozarovv|Kozarovv]] ([[User talk:Kozarovv|talk]]) 07:05, 7 March 2022 (UTC) | |||
===ps2_netemu command 0x3D=== | |||
Looks like we misunderstood this command earlier, and probably we don't even need it. | |||
There seems to be no emu code that make use of it beside printing config revision. This need confirmation on real hardware. In case that missing 0x3D will fail, it will be good to test at least that is really version enforcer, because i can't find part of code that is eventually responsible for that. | |||
* Some time ago I tested the config with version 0x3D89 which contained commands supported from the version 0x40DC onwards. The console hung up right after LV2 reset.--[[User:Agrippa|Agrippa]] ([[User talk:Agrippa|talk]]) 10:16, 24 April 2022 (UTC) | |||
** Any chance you can test this again? Config parser don't have any check for revision, when it hit 0x3D is just storing value on address that seems to be related only to UI/Menu stuff. While i can imagine some check for overall config version (still I searched and it seems to be none), i can't imagine some additional per command revision check. Which is what your test suggest here. Emulator have only one config parser, one config buffer, and one check for command number (0x51 and above still don't trigger panic yet, just ignore command). I also tried to find version numbers of 15686, 16604, 16808, 16916, 17041, 17179, 17277, 17495 in code (as hex of course), and only 17495 is found in function that is not really related to any check (described here at the end: [[Talk:PS2_Emulation#Netemu_2]] ). [[User:Kozarovv|Kozarovv]] ([[User talk:Kozarovv|talk]]) 15:06, 24 April 2022 (UTC)-- | |||
*** You are right. There is no revision check and the 0x3D command is not needed at all for the config to work.--[[User:Agrippa|Agrippa]] ([[User talk:Agrippa|talk]]) 18:14, 5 May 2022 (UTC) | |||
**** We figured that out 2000 custom configs too late. :D Anyway, thanks for confirming that. --[[User:Kozarovv|Kozarovv]] ([[User talk:Kozarovv|talk]]) 17:30, 9 May 2022 (UTC) | |||
===ps2_netemu command 0x46=== | |||
* Soul Calibur III does slow down when looking at the sun regardless if the command is used or not. | |||
* Gran Turismo 4 does not affect its performance at all when looking at the sun. | |||
* Valkyrie Profile 2 does not improve its performance by enabling this command. Slowdown in Solde's port could be partially fixed by 0x21 command, interestingly enough. Even though the performance is affected likely by the pseudo stencil shadow buffer instead. | |||
** Yup, this command is minor optimization. I don't expect some good results with it. I just pointed games that use L2H to "wikify" what this command affect. I think that my hacked new command 0x30 where i backported "HWDisableReadbacks" from pcsx2/aethersx2 should give better boost in those games. As L2H is skipped at all then. If you want to perform some tests to know which games use GS Download, i compiled pcsx2 that print GS DOWNLOAD in log everytime that game ask for it ([[https://www.mediafire.com/file/nnmuvk92pnwb4s4/pcsx2x64-dev_GSDL_print.7z/file|link]] you need resources, and other files from pcsx2 1.7 from github releases). Minor optimization, but worth to use when game overuse downloads (VP2, DDS1). | |||
*** Sony was including this command in configs by default for any L2H title, regardless if it gave any performance improvement or not, it seems.--[[User:Agrippa|Agrippa]] ([[User talk:Agrippa|talk]]) 14:09, 22 May 2022 (UTC) | |||
* I have a suspicion that this command fixes some freezing issues in Rogue Galaxy. Does it make sense for it to fix issues like that? I am only basing this off the list as I haven’t encountered any issues with the command on the US version, and the Japanese Director’s Cut is based off that version. | |||
** It does fix the freeze during loading of the Burial Ground level in the NTSC version of the Tak and the Power of JuJu.--[[User:Agrippa|Agrippa]] ([[User talk:Agrippa|talk]]) 18:56, 22 May 2022 (UTC) | |||
===ps2_netemu command 0x4D=== | |||
Ok, i don't get that config. Here is what happen in assembly: | |||
0xD820 ilhu r19, 0x7FFF | |||
0xD824 lqr r20, Q_cfg_0x4D ; 0x3F800000 in wild arms | |||
0xD82C iohl r19, 0xFFFF | |||
0xD834 and r17, r80, r19 ; r17 = Q & 0x7FFFFFFF mask | |||
0xD840 ceqi r15, r17, 0 ; r15 = r17 (shortcut to move 0 or value if exist to r15) | |||
0xD844 lqr r10, ST_Q | |||
0xD84C cwd r9, 0x30+var_30+8(sp) | |||
0xD850 rotqbyi r16, r20, 4 ; load mask from config to r16 | |||
0xD858 and r12, r15, r16 ; tempQ & 0x3F800000 (r15 and with mask from cfg 0x3F800000) | |||
0xD860 or r5, r80, r12 ; or r80(Q) with r12(Q masked with 0x3F800000) | |||
0xD868 shufb r7, r5, r10, r9 ; Prepare correct write for Q (r5 stored to r10 + 8) | |||
0xD870 stqr r7, ST_Q ; write result as Q value in STQ | |||
I removed irrelevant code that setup RGBA for readability, its not affecting Q. So my point is that all that masked Q is finally ored with r80. So with whole untouched Q value. Doen't that make all those operations irrelevant, or i made some mistake here?<br> | |||
This config can be quite important because it should help to fix issues like Galerians Ash without dirty static patches. More games affected: [[https://github.com/PCSX2/pcsx2/issues/5137 | List]] | |||
* I tested the 0x3F800000 and 0x71500000 values with Galerians Ash and it did not work at all.--[[User:Agrippa|Agrippa]] ([[User talk:Agrippa|talk]]) 14:15, 8 March 2022 (UTC) | |||
==XMB messages related with PS2 Emulation== | ==XMB messages related with PS2 Emulation== | ||
{{Boxcode|title=explore_category_sysconf.rco\Text\English.xml|code=<syntaxhighlight lang="xml"> | {{Boxcode|title=explore_category_sysconf.rco\Text\English.xml|code=<syntaxhighlight lang="xml"> | ||
Line 91: | Line 545: | ||
* Without Factory Service Mode : gives "Incompatible Data" when inserting PS2 disc | * Without Factory Service Mode : gives "Incompatible Data" when inserting PS2 disc | ||
* When enabling [ | * When enabling [http://www.ps3devwiki.com/files/devtools/lv2-v9-pkg/ LV2Patcher] without factory service mode (patch4 set as http://pastie.org/private/jp8zhvuocjz95cfrjm0uzg) : no changes in XMB:Game (still only PS upscaler/smoothing, no PS2 mention at all) | ||
* When enabling [ | * When enabling [http://www.ps3devwiki.com/files/devtools/lv2-v9-pkg/ LV2Patcher] without factory service mode (patch4 set as http://pastie.org/4355919) : gives XMB:Game PS2 smoothing/upscaling options, it also make an inserted disk to be seen as PS2 format. Still same problem of ¨incompatible title¨ and loss of BT/settings. Also after returning to XMB, it no longer sees the disc as PS2 format but as incompatible data (which suggests the lv2 patch is undone, as lv2 is reloaded when returning from the ps2 lpar) | ||
* Using [ | * Using [http://www.ps3devwiki.com/files/OtherOSplusplus/misc/boot_ps2.pkg boot_ps2.pkg] without factory service mode : no resetting of date/time/displayoutput (still output on mainscreen), but all connection to any bound bluetooth device is lost, even when connected via USB (need PS button reactivation), and after a long while comes up with the message that the title is not compatible and that the ps3 needs to be updated (Basic nag screen that is on BC PS3s when inserting a noncompatible title). | ||
* With Factory Service Mode enabled (there are no Xmb options to combinetest with [ | * With Factory Service Mode enabled (there are no Xmb options to combinetest with [http://www.ps3devwiki.com/files/devtools/lv2-v9-pkg/ LV2Patcher] or [http://www.ps3devwiki.com/files/OtherOSplusplus/misc/boot_ps2.pkg boot_ps2.pkg]): gives ´PS2 disc´ detected at disc icon, but starting gives: resetting of date/time/displayoutput (effectively disabling my mainscreen), then all connection to any bound bluetooth device is lost, even when connected via USB (needs multiple PS button reactivation), and after a long while comes up with the message that the title is not compatible and that the ps3 needs to be updated (Basic nag screen that is on BC PS3s when inserting a noncompatible title). | ||
In short: [ | In short: [http://www.ps3devwiki.com/files/OtherOSplusplus/misc/boot_ps2.pkg boot_ps2.pkg] and Factory Service Mode seem to enable simulare (it tries to boot it) while [http://www.ps3devwiki.com/files/OtherOSplusplus/misc/boot_ps2.pkg boot_ps2.pkg] gives you more options e.g. using [http://www.ps3devwiki.com/files/devtools/lv2-v9-pkg/ LV2Patcher]. | ||
Perhaps hardswapping out all the dev_flash ps2 emu files for the same software only emulator would circumvent the 'incompatible title' message. | Perhaps hardswapping out all the dev_flash ps2 emu files for the same software only emulator would circumvent the 'incompatible title' message. | ||
==== Second test: FW 2.70/3.15 ==== | ==== Second test: FW 2.70/3.15 ==== | ||
Silent Hill : gives disk icon "unsupported data" and error message like "This model of the PS3 system is not compatible with Playstation2 format software" when run via disc icon. Using [ | Silent Hill : gives disk icon "unsupported data" and error message like "This model of the PS3 system is not compatible with Playstation2 format software" when run via disc icon. Using [http://www.ps3devwiki.com/files/OtherOSplusplus/misc/boot_ps2.pkg boot_ps2.pkg] gives title not supported error message like "This title is not currently compatible with the PS3 system". | ||
==== Third test: FW 3.55 OtherOS++22GB (with SS Patches) ==== | ==== Third test: FW 3.55 OtherOS++22GB (with SS Patches) ==== | ||
Silent Hill : gives disk icon "unsupported data" and error message like "This model of the PS3 system is not compatible with Playstation2 format software" when run via disc icon. Using [ | Silent Hill : gives disk icon "unsupported data" and error message like "This model of the PS3 system is not compatible with Playstation2 format software" when run via disc icon. Using [http://www.ps3devwiki.com/files/OtherOSplusplus/misc/boot_ps2.pkg boot_ps2.pkg] gives blackscreen lockup, not reacting on PS button, or powerbutton, requiring removing powercord. | ||
Line 306: | Line 760: | ||
ID match US release of Crazy Taxi. This id is kinda special, because Swap Magic CD version, and some other Datel products like Action Replay use Crazy Taxi TOC in their retail discs. | ID match US release of Crazy Taxi. This id is kinda special, because Swap Magic CD version, and some other Datel products like Action Replay use Crazy Taxi TOC in their retail discs. | ||
Is known that they literally ripped part of disc (with key/logo, and TOC), and frankesteined it with own products. | Is known that they literally ripped part of disc (with key/logo, and TOC), and frankesteined it with own products. | ||
So mentioned check first compare hash, and if that match, then run function that perform another check at disc sector 267559 (0x41527), so exactly where main executable is. | So mentioned check first compare hash, and if that match, then run function that perform another check at disc sector 267559 (0x41527), so exactly where main executable is. | ||
I didn't figured out what next, but this is probably anti AR/Datel/SM check. What's weird, there seems to be nothing for TimeSplitters2 which if i recall correctly was used for DVD version of Swap Magic | I didn't figured out what next, but this is probably anti AR/Datel/SM check. What's weird, there seems to be nothing for TimeSplitters2 which if i recall correctly was used for DVD version of Swap Magic. | ||
==CDVD Commands== | ==CDVD Commands== | ||
Line 490: | Line 943: | ||
Every "mechacon_auth" command return zeroed result with different size. Only exception here is 0x81 which return 1. | Every "mechacon_auth" command return zeroed result with different size. Only exception here is 0x81 which return 1. | ||
</pre> | </pre> | ||
==EE I/O Handlers list== | ==EE I/O Handlers list== | ||
Line 1,080: | Line 1,462: | ||
|- | |- | ||
|} | |} | ||
1000F800 to 1000F8B0 seems to be some fake regs for testing purposes. Probably not existing on real PS2. | 1000F800 to 1000F8B0 seems to be some fake regs for testing purposes. Probably not existing on real PS2. | ||
* 1000F820 return "DrJock TV Quiz P" | |||
* 1000F830 return "hD bags few lynx" | |||
* 1000F820 return "DrJock TV Quiz P" | |||
* 1000F830 return "hD bags few lynx" | |||
That make string "DrJock TV Quiz PhD bags few lynx" - This is perfect summary of Sony work. Since correct pangram should use "MrJock". So even here they made mistake. | That make string "DrJock TV Quiz PhD bags few lynx" - This is perfect summary of Sony work. Since correct pangram should use "MrJock". So even here they made mistake. | ||
* | * 1F00F880 return hardcoded value of 0x4457, which match emu revision i'm working on. Can be just coincidence. | ||
==Random notes about SPE in ps2_netemu== | ==Random notes about SPE in ps2_netemu== | ||
===IOP SPE=== | ===IOP SPE=== | ||
This is unconfirmed by any code reversing for now, but IOP emulator print messages like: | This is unconfirmed by any code reversing for now, but IOP emulator print messages like: | ||
Cache write (IOPADDR/LSADDR/SIZE) | Cache write (IOPADDR/LSADDR/SIZE) | ||
Cache read (IOPADDR/LSADDR/SIZE) | Cache read (IOPADDR/LSADDR/SIZE) | ||
ERROR: Double ICACHE fault | 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. | 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=== | ===EEDMA on SPE3=== | ||
Line 1,187: | Line 1,490: | ||
*8 - SPRfrom dma is handled on PPE only it seems | *8 - SPRfrom dma is handled on PPE only it seems | ||
*9 - SPRto dma is handled on PPE only it seems | *9 - SPRto dma is handled on PPE only it seems | ||
Additionally EEDMA handle VU1 code writes/reads | Additionally EEDMA handle VU1 code writes/reads. Only VU1 code, VU1 data is handled by SPE2 (VU1), and any VU0 r/w is handled by PPU only.<br> | ||
So is more like "Close to GS" DMA handler. | So is more like "Close to GS" DMA handler. | ||
Line 1,193: | Line 1,496: | ||
===VU1 emulation on SPE=== | ===VU1 emulation on SPE=== | ||
When I disassembled VU1 SPE program, i noticed that real code is really small part of that. Not much to run real VU recompiler/interpreter. | When I disassembled VU1 SPE program, i noticed that real code is really small part of that. Not much to run real VU recompiler/interpreter. | ||
Then i found out something impressive in my opinion. Real deal is that real code delivered to SPE is created on PPE dynamically based on real PS2 VU1 code. Due to similarity of SPE with VU requested in IBM by Sony at design level, there is no VU1 interpreter or recompiler per se. Emulator take VU1 code, dismount it to parts by OP field types, and reassemble into ready SPE code using ready hex templates. I'm not familiar with professional naming of that operation, but its like ahead of time translation of code. So when VU1 code reach SPE is already translated to SPE opcodes. In other terms, SPE responsible for running VU1 is really running VU1 code in some way. | Then i found out something impressive in my opinion. Real deal is that real code delivered to SPE is created on PPE dynamically based on real PS2 VU1 code. Due to similarity of SPE with VU requested in IBM by Sony at design level, there is no VU1 interpreter or recompiler per se. Emulator take VU1 code, dismount it to parts by OP field types, and reassemble into ready SPE code using ready hex templates. I'm not familiar with professional naming of that operation, but its like ahead of time translation of code. So when VU1 code reach SPE is already translated to SPE opcodes. In other terms, SPE responsible for running VU1 is really running VU1 code in some way. | ||
In latest ps2_netemu function responsible for translating VU1 code into SPE ready code is located at 0x13C69C | In latest ps2_netemu function responsible for translating VU1 code into SPE ready code is located at 0x13C69C | ||
===IPU SPE6=== | ===IPU SPE6=== | ||
Line 1,266: | Line 1,552: | ||
== Emu Patches == | == Emu Patches == | ||
===Skip demo disc check=== | ===Skip demo disc check=== | ||
Line 1,372: | Line 1,621: | ||
B452CCB51348127DAF8A931B621E5E39 | B452CCB51348127DAF8A931B621E5E39 | ||
DL: https://www.mediafire.com/file/kpno5mubyy7q9p0/gx_cfg_ext.ppf/file | DL: https://www.mediafire.com/file/kpno5mubyy7q9p0/gx_cfg_ext.ppf/file | ||
== SPE programs dumper == | == SPE programs dumper == | ||
Line 1,397: | Line 1,630: | ||
== Random ps2_netemu notes == | == Random ps2_netemu notes == | ||
* | * Some members of pcsx2 team think that emulator is heavily based on early pcsx2. After some reversing this seems to be far away from true. But COP2 and VU0 (and only that for now) really are familiar here and there. To the point where i was able to use pcsx2 code to find names/usage of some variables (mVUbranch for example). But VU0/COP2 is for now only part that have obvious pcsx2 similarities. For example VU1 is different story, and don't even share code with VU0 part of emulator as far as i see. | ||
* Emulator use the same functions for FPU, and VU math where possible. This mean that for example FPU cvt.s and VU0 (and) COP2 ITOF0 at some point use exactly same function. Probably only for strictly math part, rest is different of course. | |||
* Most FPU and COP2 opcodes have "accurate math" path inlined into main opcode function, but inaccurate path is different function which is little bit weird, since inaccurate path is what is used 99% of times. | |||
* | * VU0 (micro) NOP have function prologue/epilogue , and additional call in assembly. This is pointless, and potentially burn some PPE cycles for nothing. Probably nothing that can be visible to the naked eye, but still worth to note. | ||
.VU0_NOP: | |||
stdu r1, back_chain(r1) | |||
mflr r4 | |||
std r4, 0x70+arg_10(r1) | |||
bl .VU0_NOP_ <-------- | |||
nop | |||
ld r0, 0x70+arg_10(r1) | |||
addi r1, r1, 0x70 | |||
mtlr r0 | |||
blr | |||
.VU0_NOP_: <------- | |||
ld r11, off_74C4C0 # counter_unk_cycles_2EBBC08 | |||
ld r10, off_74C4C8 # counter_old_unk_cycles_2EBBC0C | |||
lwz r9, counter_unk_cycles_2EBBC08 | |||
addi r0, r9, 1 | |||
stw r9, counter_old_unk_cycles_2EBBC0C | |||
stw r0, counter_unk_cycles_2EBBC08 | |||
blr | |||
* Emulator not only patch SPU programs on init, but also patch own PPU code. Which is hard to understand when you can just make changes in source code... eg. 0x1F128 - 0x1F134 in latest emu. | |||
* Emulator | |||
== RSX workload on the netemu == | == RSX workload on the netemu == | ||
Line 1,478: | Line 1,663: | ||
* Yes, i don't see why not. Assuming that is static patch to elf file, not some cobra style on the fly patch. But don't expect some magic from that. I don't know too much about RSX and not really much about GS. But PS2 emulation is usually limited by CPU power, specially in native resolution. But for example games that need 0x44 cmd, maybe they will work with smoothing now. Maybe some minor slowdowns will be fixed. I still don't know which parts of GS are emulated on RSX, for example softemu used something similar to pcsx2 software render. So there you will get almost nothing from RSX OC. But netemu is different. --[[User:Kozarovv|Kozarovv]] ([[User talk:Kozarovv|talk]]) 04:56, 20 March 2022 (UTC) | * Yes, i don't see why not. Assuming that is static patch to elf file, not some cobra style on the fly patch. But don't expect some magic from that. I don't know too much about RSX and not really much about GS. But PS2 emulation is usually limited by CPU power, specially in native resolution. But for example games that need 0x44 cmd, maybe they will work with smoothing now. Maybe some minor slowdowns will be fixed. I still don't know which parts of GS are emulated on RSX, for example softemu used something similar to pcsx2 software render. So there you will get almost nothing from RSX OC. But netemu is different. --[[User:Kozarovv|Kozarovv]] ([[User talk:Kozarovv|talk]]) 04:56, 20 March 2022 (UTC) | ||
** Tested the 600/750 MHz overclock with a few intensive games (SC3, ToCA3, CMR3, VP2, GT4). Assuming the patches are correctly applied (I have no idea at all), there is no performance boost at all.--[[User:Agrippa|Agrippa]] ([[User talk:Agrippa|talk]]) 15:24, 29 May 2022 (UTC) | ** Tested the 600/750 MHz overclock with a few intensive games (SC3, ToCA3, CMR3, VP2, GT4). Assuming the patches are correctly applied (I have no idea at all), there is no performance boost at all.--[[User:Agrippa|Agrippa]] ([[User talk:Agrippa|talk]]) 15:24, 29 May 2022 (UTC) | ||
== Netemu load/store with r0 register == | == Netemu load/store with r0 register == | ||
Line 1,485: | Line 1,669: | ||
Also easier example (without using negative addressing because this is additional emu quirk..). ld r2, 0x3008(r0). This opcode will load double word from 0x3008 address no matter what we currently have in r0, because RA is 0 which is badly interpreted as r0 base. | Also easier example (without using negative addressing because this is additional emu quirk..). ld r2, 0x3008(r0). This opcode will load double word from 0x3008 address no matter what we currently have in r0, because RA is 0 which is badly interpreted as r0 base. | ||
This is because of PowerPC quirk that i (and apparently IDA | This is because of PowerPC quirk that i (and apparently IDA) wasn't aware. From IBM manual: | ||
ld RT, Disp(RA) | ld RT, Disp(RA) | ||
Line 1,499: | Line 1,683: | ||
Tl;dr is that if RA is 0 (which disassemblers show as r0), then Disp is real load/store address. This is used many times in emu itself to access negative addresses (0xFFFFFFFFxxxxxxxx), and is used in all netemu cmd 0x01 hooks. | Tl;dr is that if RA is 0 (which disassemblers show as r0), then Disp is real load/store address. This is used many times in emu itself to access negative addresses (0xFFFFFFFFxxxxxxxx), and is used in all netemu cmd 0x01 hooks. | ||
While this is more PPC itself than emu stuff, i feel is important to mention this here. | While this is more PPC itself than emu stuff, i feel is important to mention this here. | ||
Now if we remember that emu have mapped "negative address", | Now if we remember that emu have mapped "negative address", functions like below starting to make sense. | ||
std r4, | sub_186A40: # CODE XREF: VIF0_big_jumptable_3026C+FCC↑p | ||
std r0, -0x6BF0(r0) # store r0 on 0xFFFFFFFFFFFF9410, no matter what r0 actually is at the moment. | |||
std r4, -0x6BD0(r0) # store r4 on 0xFFFFFFFFFFFF9430, no matter what r0 actually is at the moment. | |||
std r5, -0x6BC8(r0) | |||
std r6, -0x6BC0(r0) | |||
std r7, -0x6BB8(r0) | |||
std r8, -0x6BB0(r0) | |||
std r9, -0x6BA8(r0) | |||
std r10, -0x6BA0(r0) | |||
std r11, -0x6B98(r0) | |||
std r12, -0x6B90(r0) | |||
mflr r4 | |||
std r1, -0x6BE8(r0) | |||
std r2, -0x6BE0(r0) | |||
std r3, -0x6BD8(r0) | |||
std r4, -0x7F80(r0) | |||
bl .VU0_cmd_0x12_fl_overflow_related | |||
ld r4, -0x7F80(r0) | |||
ld r1, -0x6BE8(r0) | |||
ld r2, -0x6BE0(r0) | |||
ld r3, -0x6BD8(r0) | |||
mtlr r4 | |||
ld r0, -0x6BF0(r0) # load to r0 from address 0xFFFFFFFFFFFF9410, no matter what r0 actually is at the moment. | ld r0, -0x6BF0(r0) # load to r0 from address 0xFFFFFFFFFFFF9410, no matter what r0 actually is at the moment. | ||
ld r4, | ld r4, -0x6BD0(r0) # load to r4 from address 0xFFFFFFFFFFFF9430, no matter what r0 actually is at the moment. | ||
ld r5, -0x6BC8(r0) | |||
ld r6, -0x6BC0(r0) | |||
ld r7, -0x6BB8(r0) | |||
ld r8, -0x6BB0(r0) | |||
ld r9, -0x6BA8(r0) | |||
ld r10, -0x6BA0(r0) | |||
ld r11, -0x6B98(r0) | |||
ld r12, -0x6B90(r0) | |||
blr | |||
== ps2_gxemu external bios/rom loading. == | == ps2_gxemu external bios/rom loading. == | ||
Line 1,548: | Line 1,726: | ||
Note: This code don't exist in ps2_netemu. | Note: This code don't exist in ps2_netemu. | ||