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) | |||
* | ====Function 0x12==== | ||
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) | |||
* When PS3 is | ====Function 0x35==== | ||
''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=== | |||
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 | |||
48 | |||
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 0x0B=== | |||
SRS:Street Racing Syndicate - sector to patch: 3021/1392496 (1.03) or 1402736 (2.00), offset correction: no, PCSX2 log: | |||
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=== | |||
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=== | ||
====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> | |||
<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==== | |||
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 | |||
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 | |||
|- | |- | ||
| | |r5900 CACHE BXLBT || Unsupported, store 0 on COP0 TagLo and TagHi | ||
|- | |- | ||
| | |r5900 CACHE DXLDT || Unsupported, store 0 on COP0 TagLo | ||
|- | |- | ||
| | |r5900 CACHE DXLTG || Unsupported, store 0 on COP0 TagLo | ||
|- | |- | ||
| | |r5900 CACHE IXLDT || Unsupported, store 0 on COP0 TagLo | ||
|- | |- | ||
| | |r5900 CACHE IXLTG || Supported, cmd 0x21 (0,1) skip function and store 0 on COP0 TagLo | ||
|- | |- | ||
| | |r5900 CACHE DXWBIN || Not supported at all, empty function. | ||
|- | |- | ||
| | |r5900 CACHE DXIN || Not supported at all, empty function. | ||
|- | |- | ||
| | |r5900 CACHE DHWBIN || Not supported at all, empty function. | ||
|- | |- | ||
| | |r5900 CACHE DHIN || Not supported at all, empty function. | ||
|- | |- | ||
| | |r5900 CACHE DHWOIN || Not supported at all, empty function. | ||
|- | |- | ||
| | |r5900 CACHE IHIN || Full support, cmd 0x21 (0,1) change path of that opcode, 0x03 practically skip whole op. | ||
|- | |- | ||
| | |r5900 CACHE IXIN || Full support, cmd 0x21 (0,1) change path of that opcode, 0x03 practically skip whole op. | ||
|- | |- | ||
| | |r5900 CACHE misc || Do something, but function is little bit complicated to tell for now that it is something that make sense. | ||
|} | |||
--[[User:Kozarovv|Kozarovv]] ([[User talk:Kozarovv|talk]]) 21:03, 1 October 2022 (UTC) | |||
| | Example of recompiled code with enabled cache emulation: https://pastebin.com/sDwc1MLX | ||
* Every operation with r15 and following r7/r8 loads, compares, and cr operations will be skipped by emitter with 0x21 --> 0 | |||
| | * r15 is loaded with current address (page?), to get full value shift it left by 6 eg. 0x808710 << 6 = 0x2021C400 (shift left by 6 = multiplying by 0x40) | ||
* For small part of code posted on pastebin, cache check is performed 33 times * 8 opcodes = 264 opcodes from 801 are cache checks! A lot of work, a lot of code mostly for nothing. | |||
* Conclusion. Use 0x21 --> 0 whenever you can. iCache emulation is pointless for 99% of games. | |||
* Small oftopic. Every opcode that write to r13 increase emulated cycles. Every opcode writing to r14 modify current r5900 pc. Every branch to 0x3800 mean that event test will be performed. | |||
| | * Problematic games (have issues with 0x21 enabled): Shadow Hearts 3, Jak & Daxter, VP2, Hot Shots series, Kingdom Hearts. Any game that load additional code overlays and do that custom way, for example Shadow Hearts 3 load code from bin files hidden in cpx files. All those games doesn't really need iCache emulation to work, but emulator seems to have issue with code invalidation. Only small amount of games used this method of loading, so it still should be fine for 99% of games. | ||
--[[User:Kozarovv|Kozarovv]] ([[User talk:Kozarovv|talk]]) 07:32, 22 May 2023 (CEST) | |||
* Radiata does not crash. English patch for FFXII IZJS does crash though (0x21 fixes stuttering in turbo mode).--[[User:Agrippa|Agrippa]] ([[User talk:Agrippa|talk]]) 20:33, 22 May 2023 (CEST) | |||
** Whoops, my bad. Fixed. :P --[[User:Kozarovv|Kozarovv]] ([[User talk:Kozarovv|talk]]) 09:44, 23 May 2023 (CEST) | |||
*** Actually, the icache invalidation issues could explain why the infamous Maori VP2 overlay anti-protection patch is not working on the netemu.--[[User:Agrippa|Agrippa]] ([[User talk:Agrippa|talk]]) 22:14, 15 June 2023 (CEST) | |||
**** His patch is basically self modifying code, so its possible. You can try cmd 0x01 with 0x0E subcommand hook at 0x01feb1c0. This invalidate whole mem every time offset is hit, ensuring that new code that is written from patcher is not in conflict with cache. Also remember that 0x42 is applied only on syscall 7, so if game modify 0x1feb1c0 - 0x1feb2e0 region, it will wipe patcher. And games often memzero whole data memory right after start. This issue don't exist on pcsx2 because it will reapply it on next vsync, while on netemu only 0x09/0x0A patches are reapplied. --[[User:Kozarovv|Kozarovv]] ([[User talk:Kozarovv|talk]]) 15:37, 16 June 2023 (CEST) | |||
===ps2_netemu command 0x22=== | |||
Weird command. Sets something 1 (CDVD/MECHA), but seems to never use it. | |||
===ps2_netemu command 0x28=== | |||
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. | |||
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). | |||
| | |||
===ps2_netemu command 0x2A=== | |||
Any idea what this command is doing? It seems to be directly related to IPU. I thought it only fixed black screen issues on certain games, but it also fixes Mystery Mayhem’s glitching/freezing/stuttering FMVs. | |||
* This config skip check of another value, which finally make one of functions to never run. This affect "SYS" thread, and value that is checked seems to be related to EE/COP2 recompilers (pure guess by addresses that write there...). Nothing related directly to IPU, that's for sure. But this is part of emu that i have basically untouched, so i can't tell what its really skipped here. Function that is skipped trigger other functions which read cached mips code. So maybe something related to recompiler flushing, or constant propagation. Hard to tell at this point. For sure this is something i want to look more into, but not yet. --[[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) | |||
===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 0x4D=== | |||
Leaving this here just in case. Fixed comments version. | |||
0xD7F8 RGBAQ_01_and_11: | |||
0xD7F8 | |||
0xD800 move r80, r3 ; move new values to r80 | |||
0xD820 ilhu r19, 0x7FFF | |||
0xD824 lqr r20, Q_val_cfg_plus4 | |||
0xD82C iohl r19, 0xFFFF | |||
0xD834 and r17, r80, r19 ; r17 = Q & 0x7FFFFFFF | |||
0xD840 ceqi r15, r17, 0 ; if r17 == 0, r15 = 0xFFFFFFF, else 0 | |||
0xD844 lqr r10, ST_Q | |||
0xD84C cwd r9, 0x30+var_30+8(sp) ; Prepare correct write | |||
0xD850 rotqbyi r16, r20, 4 ; load cmd value from config to r16 | |||
0xD858 and r12, r15, r16 ; r15 & value_from_cfg | |||
0xD860 or r5, r80, r12 ; r80(Q) | r12(value from cfg or 0) | |||
0xD868 shufb r7, r5, r10, r9 ; select ST bits + new Q | |||
0xD870 stqr r7, ST_Q ; store result as Q value in STQ | |||
===ps2_gxemu command 0x19=== | |||
Command disable reads/writes to selected IOP HW registers. Disabled regs are: | |||
* 0x10000000 - 0x10003FFF (DEV9/SPEED/ATA/SMAP) | |||
* 0x1F801460 - 0x1F80147F (Unknown) | |||
Command is auto applied to titles listed here (duplicates are really there in emu too): | |||
Hash ID Name | |||
0x0CD1298155 SLES_540.13 World Snooker Championship 2007 | |||
0x12C93199A5 SLES_518.40 NHL Hitz Pro | |||
0x15C93199AD SLES_549.13 Pro Evolution Soccer 2008 | |||
0x24D92589A5 SLUS_211.86 NBA Ballers - Phenom | |||
0x2CD12D8125 SLUS_212.35 MLB 2K6 | |||
0x34C9359935 SLUS_211.38 X-Men Legends II - Rise of Apocalypse | |||
0x34C93599E5 SLUS_211.28 Blitz - The League | |||
0x34C93599E5 SLUS_211.28 Blitz - The League | |||
0x449961C9E5 SLES_542.10 NBA 2K7 | |||
0x4C9169C1CD SLES_542.46 FIFA '07 | |||
0x4C9169C1D5 SLES_542.45 NHL '07 | |||
0x4C9169C1DD SLES_542.44 FIFA '07 | |||
0x4C9169C1E5 SLES_542.43 FIFA '07 | |||
0x4C9169C1F5 SLES_542.41 FIFA '07 | |||
0x4C9169C1FD SLES_542.40 FIFA '07 | |||
0x4CB14DE12D SLUS_213.74 Marvel - Ultimate Alliance | |||
0x54A955F915 SLUS_212.74 Outrun 2006 - Coast 2 Coas | |||
0x5CA15DF165 SLUS_213.01 World Series of Poker | |||
0x5CA15DF1FD SLUS_212.86 WWE SmackDown! vs RAW 2006 | |||
0x5CA15DF1FD SLUS_212.86 WWE SmackDown! vs RAW 2006 | |||
0x649965C94D SLUS_214.63 Tom Clancy's Ghost Recon 2 | |||
0x649965C955 SLUS_214.60 NBA Live '07 | |||
0x649965C95D SLUS_214.61 NASCAR '07 | |||
0x649965C965 SLUS_214.58 NHL '07 | |||
0x649965C96D SLUS_214.59 NCAA Football '07 | |||
0x6BB149E15D SLES_531.04 Tom Clancy's Rainbow Six - Lockdown | |||
0x6C916DC165 SLUS_214.91 World Series of Poker - Tournament of Champions | |||
0x6C916DC1A5 SLUS_214.83 Tiger Woods PGA Tour '07 | |||
0x6C916DC1AD SLUS_214.82 NFL Street 3 | |||
0x6C916DC1B5 SLUS_214.81 NCAA March Madness '07 | |||
0x6C916DC1D5 SLUS_214.77 Madden NFL '07 [Hall of Fame Edition] | |||
0x6C916DC1DD SLUS_214.76 Madden NFL '07 | |||
0x748975D9DD SLUS_213.83 Fight Night - Round 3 | |||
0x7C817DD125 SLUS_214.33 FIFA Soccer '07 | |||
0x7C817DD165 SLUS_214.25 NHL 2K7 | |||
0x7C817DD16D SLUS_214.24 NBA 2K7 | |||
0x7C817DD175 SLUS_214.27 WWE SmackDown! vs RAW 2007 | |||
0x7C817DD1CD SLUS_214.12 World Championship Poker featuring Howard Lederer - All-In | |||
0x84798529BD SLUS_205.65 Champions of Norrath | |||
0x8559A109AD uuunnnnnkkk | |||
0x8579852915 SLUS_215.68 Arena Football - Road to Glory | |||
0x8579852965 SLUS_215.82 MVP '07 - NCAA Baseball | |||
0x8D51A90145 SLES_545.11 UEFA Champions League | |||
0x8D51A901B5 SLES_545.13 UEFA Champions League | |||
0x8D51A901BD SLES_545.12 UEFA Champions League | |||
0x8D718D21BD SLUS_216.20 NCAA Football '08 | |||
0x9C619D31E5 SLUS_205.41 NBA Ballers | |||
0x9D41B911AD SLES_544.48 World Series of Poker - Tournament of Champions | |||
0x9D619D31C5 SLUS_215.61 Major League Baseball 2K7 | |||
0x9F29357805 SCUS_975.44 NBA '07 featuring The Life Vol.2 | |||
0x9F293578E5 SCUS_975.56 MLB '07 - The Show | |||
0xB549B51915 SLUS_216.38 Madden NFL '0 | |||
0xB549B51925 SLUS_216.32 NHL 2K8 | |||
0xB549B5195D SLUS_216.47 NHL '08 | |||
0xB549B519A5 SLUS_216.48 FIFA Soccer '08 | |||
0xB549B519AD SLUS_216.49 NBA Live '08 | |||
0xBC61793025 SCES_532.85 Ratchet - Gladiator | |||
0xBD41BD1105 SLUS_216.69 NBA 2K8 | |||
0xC439C569F5 SLUS_208.20 Tom Clancy's Ghost Recon - Jungle Storm | |||
0xC7716D20D5 SCUS_974.01 Hot Shots Golf FORE! | |||
0xC7716D20D5 SCUS_974.01 Hot Shots Golf FORE! | |||
0xCA11E941F5 SLES_516.97 SSX 3 | |||
0xCF7965285D SCUS_973.53 Ratchet and Clank - Up Your Arsenal | |||
0xCF7965285D SCUS_973.53 Ratchet and Clank - Up Your Arsenal | |||
0xD20911582D SCES_515.93 Hardware Online Arena [Beta, Promo & Full Release] | |||
0xD7617D308D SCUS_973.28 Gran Turismo 4 | |||
0xE339C1695D SLES_525.45 Star Wars Battlefront | |||
0xE794CCB06D PCPX_980.42 Minna no Tennis | |||
0xEA3129608D SCES_515.78 Network Access Disc [Original, v4.02 & v4.03] | |||
0xEC11ED4115 SLUS_209.73 Champions - Return to Arms | |||
0xEF594508D5 SCUS_975.00 MLB '06 - The Show | |||
0xF409F559AD SLUS_208.89 MLB Slugfest - Loaded | |||
0xF7415D10E5 SCUS_974.65 Ratchet - Deadlocked | |||
0xF7415D10E5 SCUS_974.65 Ratchet - Deadlocked | |||
As a result config disable HDD/NET capabilities. | |||
==XMB messages related with PS2 Emulation== | |||
{{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=== | |||
[[http://www.ps3devwiki.com/index.php?title=Emulation#Getting_Playstation_2_Software_Emulator_working Getting Playstation 2 Software Emulator working]] | |||
[[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> | |||
==== Service Mode in relation to PS2 emulation tests ==== | |||
* Service mode resets display settings (on default it uses HDMI with composite on MultiAV connector) - this means that users of Component cables can get garbled screen / no display output (in tests below, the primairy screen) unless using composite wiring/screen (in tests below, the secondairy screen). | |||
* Service Mode also resets user presets like disc autoboot, so it needs to be disabled again if needed. | |||
* Any made Virtual Memory Cards previously will be removed and you will have no access to them, nor be able to create one. | |||
* When PS3 is switching to PS2, connection with Sixaxis / Dualshock 3 will be lost (even when using USB wired connection). In some cases easily resyncable by using PS button, but in other cases the leds stay off and the controller cannot be used (until ps2 mode is exited or console rebooted) | |||
* As a workaround for above wireless controller issue, you can use an USB2PS2 converter and connect an old PS2 / Dualshock2 controller. | |||
==== tests on 2000 series PS3 Slim ==== | |||
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]] | |||
* Without Factory Service Mode : gives "Incompatible Data" when inserting PS2 disc | |||
* When enabling [https://web.archive.org/web/*/http://ps3devwiki.com/files/devtools/lv2-v9-pkg/ LV2Patcher] without factory service mode (patch4 set as http://pastie.org/private/jp8zhvuocjz95cfrjm0uzg) : no changes in XMB:Game (still only PS upscaler/smoothing, no PS2 mention at all) | |||
* When enabling [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) | |||
* 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). | |||
* 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). | |||
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. | |||
==== 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". | |||
==== 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. | |||
===== considering titles to test ===== | |||
* 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 | |||
* http://us.playstation.com/support/compatiblestatus/index.htm | |||
These have no listed issues: | |||
* Half-Life | |||
* Hulk | |||
* Medal of Honor: Frontline | |||
These have minor issues listed (but should still play): | |||
* Silent Hill 3 | |||
* Second Sight | |||
==== tests on CECHC04 (partial BC) ==== | |||
on 3.41 or on 3.55 in normal XMB mode (no disc icon in XMB): boot_ps2.pkg gives no resetting of date/time/displayoutput (still output on mainscreen), but all connection to any bound bluetooth device is lost, even when connected via USB (need PS button reactivation), and after a long while comes up with the message that the "The system was not turned off properly" as if it had experienced poweroff and from there booted back to XMB. It then returns to the XMB, but first gives an error screen, mentioning 0x80028F17 occured (''PS2 mode error 0x80028F17 "An error occurred during the start operation (80028F17)," PlayStation 2 disc Boot Error, also related to PS1 PSN games.'') | |||
on 3.41 or on 3.55 in normal XMB mode (disc icon in XMB): boot_ps2.pkg gives resetting of date/time/displayoutput (no output on mainscreen), but all connection to any bound bluetooth device is lost, even when connected via USB (need PS button reactivation). The game is playable on secondary screen, and exit to XMB with holding PS button goes without 0x80028F17 errors, but does give the "The system was not turned off properly" error. | |||
no disc icon: | |||
* Medal of Honor: Rising Sun | |||
* Half-Life | |||
disc icon: | |||
* Hulk | |||
* Second Sight | |||
* Silent Hill 3 | |||
==== Renaming ps2_netemu to ps2_emu ==== | |||
Tested renaming ps2_netemu.self to ps2_emu.self on CECHB01/rogero 4.21 with dev_blind mounting via multiMAN but boots to black screen, no disc activity, but controller shuts off and is synced. No PS button menu or anything. | |||
boot_ps2.pkg boots, no disc activities, then throws up an error depending if the file is resigned for 4.21 or not. (tried both a resigned and the existing version) | |||
==== PS2 on non BC HW - Tests ==== | |||
{| class="wikitable sortable" | |||
|- | |||
! rowspan="2" | Title !! rowspan="2" | DiscID !! colspan="2" | Disc Icon !! colspan="3" | ps2_softemu !! rowspan="2" | Remarks | |||
|- | |||
! <abbr title="Normal Mode">Normal</abbr> !! <abbr title="Factory Service Mode">FSM</abbr> !! 2.50 !! 2.60 !! 2.70 | |||
|- | |||
| Action Replay MAX || SCED54409 || || {{ps2cd}} || || || {{no}} || | |||
|- | |||
| Battlefield 2 Modern Combat || SLES53729 || || {{ps2dvd}} || || || {{no}} || | |||
|- | |||
| Constantine || SLES52872 || || {{ps2dvd}} || || || {{no}} || | |||
|- | |||
| Demo Disc 3-073-543-11 || PBPX95514 || || {{ps2dvd}} || || || {{no}} || | |||
|- | |||
| EyeToy Play || SCES51513 || || {{ps2dvd}} || || || {{no}} || | |||
|- | |||
| EyeToy Play 2 || SCES52748 || || {{ps2dvd}} || || || {{no}} || | |||
|- | |||
| EyeToy Play 3 || SLES53315 || || {{ps2dvd}} || || || {{no}} || | |||
|- | |||
| Freedom Fighters || SLES51467 || || {{ps2dvd}} || || || {{no}} || | |||
|- | |||
| Ghost in the Shell Standalone Complex || SLES53020 || || {{ps2dvd}} || || || {{no}} || | |||
|- | |||
| GoldenEye Rogue Agent || SLES52974 || || {{ps2dvd}} || || || {{no}} || | |||
|- | |||
| Guerrilla Strike || SLES53344 || || {{ps2cd}} || || || {{no}} || | |||
|- | |||
| Gunfighter 2 Revenge of Jessy James || SLES51289 || || {{ps2cd}} || || || {{no}} || | |||
|- | |||
| Half Life || SLES50504 || || {{ps2cd}} || || || {{no}} || | |||
|- | |||
| HDLoader || - || || {{ps2cd}} || || || {{no}} || | |||
|- | |||
| International Golf Pro || SLES52349 || || {{ps2cd}} || || || {{no}} || | |||
|- | |||
| Jet Ion GP || SLES50544 || || {{ps2cd}} || || || {{no}} || | |||
|- | |||
| killer7 || SLES53366 || || {{ps2dvd}} || || || {{no}} || | |||
|- | |||
| Kya Dark Lineage || SLES51473 || || {{ps2dvd}} || || || {{no}} || | |||
|- | |||
| London Racer Destruction Madness || SLES53654 || || {{ps2cd}} || || || {{no}} || | |||
|- | |||
| London Racer Police Madness || SLES53536 || || {{ps2cd}} || || || {{no}} || | |||
|- | |||
| Manhunt || SLES52023 || || {{ps2dvd}} || || || {{no}} || | |||
|- | |||
| Max Play - 10 Classic Retro Games || - || || {{ps2cd}} || || || {{no}} || | |||
|- | |||
| Medal of Honor European Assault || SLES53332 || || {{ps2dvd}} || || || {{no}} || | |||
|- | |||
| Medal of Honor Frontline || SLES50684 || || {{ps2dvd}} || || || {{no}} || | |||
|- | |||
| Medal of Honor Rising Sun || SLES51873 || || {{ps2dvd}} || || || {{no}} || | |||
|- | |||
| Medal of Honor Vanguard || SLES54683 || || {{ps2dvd}} || || || {{no}} || | |||
|- | |||
| Men in Black II Alien Escape || SLES50789 || || {{ps2dvd}} || || || {{no}} || | |||
|- | |||
| Network Access Disc || SCES51578 || || {{ps2dvd}} || || || {{no}} || | |||
|- | |||
| OPM #66 || SCED54409 || || {{ps2dvd}} || || || {{no}} || | |||
|- | |||
| OPM #67 || SCED54410 || || {{ps2dvd}} || || || {{no}} || | |||
|- | |||
| OPM #68 || SCED54412 || || {{ps2dvd}} || || || {{no}} || | |||
|- | |||
| OPM #69 || SCED54413 || || {{ps2dvd}} || || || {{no}} || | |||
|- | |||
| OPM #70 || SCED54415 || || {{ps2dvd}} || || || {{no}} || | |||
|- | |||
| OPM #72 || SCED54417 || || {{ps2dvd}} || || || {{no}} || | |||
|- | |||
| OPM #73 || SCED54418 || || {{ps2dvd}} || || || {{no}} || | |||
|- | |||
| OPM #74 || SCED55113 || || {{ps2dvd}} || || || {{no}} || | |||
|- | |||
| OPM #75 || SCED55114 || || {{ps2dvd}} || || || {{no}} || | |||
|- | |||
| OPM #77 || SCED55117 || || {{ps2dvd}} || || || {{no}} || | |||
|- | |||
| OPM #79 || SCED55119 || || {{ps2dvd}} || || || {{no}} || | |||
|- | |||
| Perfect Ace Pro Tournament Tennis || SLES51735 || || {{ps2cd}} || || || {{no}} || | |||
|- | |||
| Prisoner of War || SLES50397 || || {{ps2dvd}} || || || {{no}} || | |||
|- | |||
| Ratchet & Clank 3 || SCES52456 || || {{ps2dvd}} || || || {{no}} || | |||
|- | |||
| Red Baron || SLES53434 || || {{ps2cd}} || || || {{no}} || | |||
|- | |||
| SAS Anti-terror Force || SLES53435 || || {{ps2cd}} || || || {{no}} || | |||
|- | |||
| Second Sight || SLES52670 || || {{ps2dvd}} || || || {{no}} || | |||
|- | |||
| Seek and Destroy || SLES51603 || || {{ps2cd}} || || || {{no}} || | |||
|- | |||
| Silent Hill 3 || SLES51434 || || {{ps2dvd}} || {{yes}} || || {{no}} || | |||
|- | |||
| Socom US Navy SEALs || SCES50928 || || {{ps2dvd}} || || || {{no}} || | |||
|- | |||
| Socom II US Navy SEALs || SCES51904 || || {{ps2dvd}} || || || {{no}} || | |||
|- | |||
| Socom 3 US Navy SEALs || SCES53300 || || {{ps2dvd}} || || || {{no}} || | |||
|- | |||
| Socom US Navy SEALs Combined Assault || SCES54477 || || {{ps2dvd}} || || || {{no}} || | |||
|- | |||
| Swap Magic 3 plus (PAL version 3.6) CD || SCED54409 || || {{no}} || - || || {{no}} || | |||
|- | |||
| Swap Magic 3 plus (PAL version 3.6) DVD || SCED54409 || || {{ps2dvd}} || {{yes}} || || {{no}} || | |||
|- | |||
| Tenchu Wrath of Heaven || SLES50679 || || {{ps2dvd}} || || || {{no}} || | |||
|- | |||
| Terminator 3 Rise of the Machines || SLES52152 || || {{ps2dvd}} || || || {{no}} || | |||
|- | |||
| The Great Escape || SLES51315 || || {{ps2dvd}} || || || {{no}} || | |||
|- | |||
| The Hulk || SLES51508 || || {{ps2dvd}} || {{yes}} || || {{no}} || | |||
|- | |||
| The Matrix Path of Neo || SLES53799 || || {{ps2dvd}} || || || {{no}} || | |||
|- | |||
| The Plan || SLES53965 || || {{ps2cd}} || || || {{no}} || | |||
|- | |||
| Time Crisis 3 || SCES51844 || || {{ps2dvd}} || || || {{no}} || | |||
|- | |||
| Tom Clancy's Ghost Recon || SLES51181 || || {{ps2dvd}} || || || {{no}} || | |||
|- | |||
| Tom Clancy's Rainbow Six 3 || SLES52288 || || {{ps2dvd}} || || || {{no}} || | |||
|- | |||
| Tom Clancy's Splinter Cell || SLES51466 || || {{ps2dvd}} || || || {{no}} || | |||
|- | |||
| Tom Clancy's Splinter Cell Chaos Theory || SLES53007 || || {{ps2dvd}} || || || {{no}} || | |||
|- | |||
| Tom Clancy's Splinter Cell Pandora Tomorrow || SLES52149 || || {{ps2dvd}} || || || {{no}} || | |||
|- | |||
| Trapt || SLES53824 || || {{ps2dvd}} || || || {{no}} || | |||
|- | |||
|} | |||
==== Tests on NON-BC CECHP01/NTSC-U (Firmware 2.60/boot_ps2.pkg) ==== | |||
<br> | |||
<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 | ||
Comparative listings: http://tortuga-cove.com/forums/viewtopic.php?f=57&t=530 | |||
==Hidden/Inaccessible menu in ps2_emu== | |||
Apparently PS2EMU (CECH A/B) have some hidden menu that is able to print IOP configs from bios (XPARAM.ELF), i didn't found way to get there, my only idea is replacing other menu with that one in jump case at 0x5D980 (emu around 4.78). Case 21, and 22 is what seems to be hidden menu. | |||
More info about printed data: https://www.psdevwiki.com/ps3/PS2_Emulation#TitleID.2FDiscID_in_ps2_netemu.self | |||
==Crazy Taxi check== | |||
Emulators ps2_netemu, and ps2_gxemu (maybe others too), after calculating game hash perform compare check to 0x2BD12D81ED. | |||
ID match US release of Crazy Taxi. This id is kinda special, because Swap Magic CD version, and some other Datel products like Action Replay use Crazy Taxi TOC in their retail discs. | |||
Is known that they literally ripped part of disc (with key/logo, and TOC), and frankesteined it with own products. | |||
So mentioned check first compare hash, and if that match, then run function that perform another check at disc sector 267559 (0x41527), so exactly where main executable is. | |||
I didn't figured out what next, but this is probably anti AR/Datel/SM check. What's weird, there seems to be nothing for TimeSplitters2 which if i recall correctly was used for DVD version of Swap Magic. | |||
<br>There is also check for 0xE794CCB06D PCPX_980.42 Minna no Tennis entry, emu also refuse to boot it, and throw the same error as with SwapMagic/SCED discs. | |||
== | ==CDVD Commands== | ||
===Netemu=== | ===Netemu=== | ||
Address in memory | r5900 register | <pre> | ||
FFFFFFFFFFFF8980 | 5900_zero_upper64bits | 4.75 and up. | ||
FFFFFFFFFFFF8988 | 5900_zero_lower64bits | |||
FFFFFFFFFFFF8990 | 5900_at_reg_upper64 | Supported CDVD N Commands: | ||
FFFFFFFFFFFF8998 | 5900_at_reg_lower64 | |||
FFFFFFFFFFFF89A0 | 5900_v0_reg_upper64 | opd_ptr num name | ||
FFFFFFFFFFFF89A8 | 5900_v0_reg_lower64 | 0x934AB0 0x00: N_CD_NOP | ||
FFFFFFFFFFFF89B0 | 5900_v1_reg_upper64 | 0x934AB8 0x01: N_CD_RESET | ||
FFFFFFFFFFFF89B8 | 5900_v1_reg_lower64 | 0x934AC0 0x02: N_CD_STANDBY | ||
FFFFFFFFFFFF89C0 | 5900_a0_reg_upper64 | 0x934AC8 0x03: N_CD_STOP | ||
FFFFFFFFFFFF89C8 | 5900_a0_reg_lower64 | 0x934AD0 0x04: N_CD_PAUSE | ||
FFFFFFFFFFFF89D0 | 5900_a1_reg_upper64 | 0x934AD8 0x05: N_CD_SEEK | ||
FFFFFFFFFFFF89D8 | 5900_a1_reg_lower64 | 0x934AE0 0x06: N_CD_READ | ||
FFFFFFFFFFFF89E0 | 5900_a2_reg_upper64 | 0x934AE8 0x07: N_CD_READ_CDDA | ||
FFFFFFFFFFFF89E8 | 5900_a2_reg_lower64 | 0x934AF0 0x08: N_DVD_READ | ||
FFFFFFFFFFFF89F0 | 5900_a3_reg_upper64 | 0x934AF8 0x09: N_CD_GET_TOC | ||
FFFFFFFFFFFF89F8 | 5900_a3_reg_lower64 | 0x934B00 0x0A: N_CMD_A panic | ||
FFFFFFFFFFFF8A00 | 5900_t0_reg_upper64 | 0x934B08 0x0B: N_CMD_B panic | ||
FFFFFFFFFFFF8A08 | 5900_t0_reg_lower64 | 0x934B10 0x0C: N_CD_READ_KEY | ||
FFFFFFFFFFFF8A10 | 5900_t1_reg_upper64 | 0x934B18 0x0D: N_CMD_D panic | ||
FFFFFFFFFFFF8A18 | 5900_t1_reg_lower64 | any command above 0x0D panic | ||
FFFFFFFFFFFF8A20 | 5900_t2_reg_upper64 | |||
FFFFFFFFFFFF8A28 | 5900_t2_reg_lower64 | Supported CDVD S Commands: | ||
FFFFFFFFFFFF8A30 | 5900_t3_reg_upper64 | |||
FFFFFFFFFFFF8A38 | 5900_t3_reg_lower64 | opd_ptr num name | ||
FFFFFFFFFFFF8A40 | 5900_t4_reg_upper64 | 0x934B20 0x00: SCMD_Return_0 | ||
FFFFFFFFFFFF8A48 | 5900_t4_reg_lower64 | 0x934B28 0x01: SCMD_GetDiscType panic | ||
FFFFFFFFFFFF8A50 | 5900_t5_reg_upper64 | 0x934B30 0x02: SCMD_CdReadSubQ panic | ||
FFFFFFFFFFFF8A58 | 5900_t5_reg_lower64 | 0x934B38 0x03: SCMD_Mecacon_command (support 0x00, 0x01 ,0x30, 0x45 sub cmds) | ||
FFFFFFFFFFFF8A60 | 5900_t6_reg_upper64 | 0x934B40 0x04: SCMD_0x04 panic | ||
FFFFFFFFFFFF8A68 | 5900_t6_reg_lower64 | 0x934B48 0x05: SCMD_CdTrayReqState | ||
FFFFFFFFFFFF8A70 | 5900_t7_reg_upper64 | 0x934B50 0x06: SCMD_CdTrayCtrl | ||
FFFFFFFFFFFF8A78 | 5900_t7_reg_lower64 | 0x934B58 0x07: SCMD_0x07 panic | ||
FFFFFFFFFFFF8A80 | 5900_s0_reg_upper64 | 0x934B60 0x08: SCMD_CdReadRTC | ||
FFFFFFFFFFFF8A88 | 5900_s0_reg_lower64 | 0x934B68 0x09: SCMD_sceCdWriteRTC | ||
FFFFFFFFFFFF8A90 | 5900_s1_reg_upper64 | 0x934B70 0x0A: SCMD_sceCdReadNVM panic | ||
FFFFFFFFFFFF8A98 | 5900_s1_reg_lower64 | 0x934B78 0x0B: SCMD_sceCdWriteNVM panic | ||
FFFFFFFFFFFF8AA0 | 5900_s2_reg_upper64 | 0x934B80 0x0C: SCMD_0x0C panic | ||
FFFFFFFFFFFF8AA8 | 5900_s2_reg_lower64 | 0x934B88 0x0D: SCMD_0x0D panic | ||
FFFFFFFFFFFF8AB0 | 5900_s3_reg_upper64 | 0x934B90 0x0E: SCMD_0x0E panic | ||
FFFFFFFFFFFF8AB8 | 5900_s3_reg_lower64 | 0x934B98 0x0F: SCMD_sceCdPowerOff | ||
FFFFFFFFFFFF8AC0 | 5900_s4_reg_upper64 | 0x934BA0 0x10: SCMD_0x10 panic | ||
FFFFFFFFFFFF8AC8 | 5900_s4_reg_lower64 | 0x934BA8 0x11: SCMD_0x11 panic | ||
FFFFFFFFFFFF8AD0 | 5900_s5_reg_upper64 | 0x934BB0 0x12: SCMD_sceCdReadILinkId return zeroed iLinkId | ||
FFFFFFFFFFFF8AD8 | 5900_s5_reg_lower64 | 0x934BB8 0x13: SCMD_sceCdWriteILinkID panic | ||
FFFFFFFFFFFF8AE0 | 5900_s6_reg_upper64 | 0x934BC0 0x14: SCMD_CdCtrlAudioDigitalOut panic | ||
FFFFFFFFFFFF8AE8 | 5900_s6_reg_lower64 | 0x934BC8 0x15: SCMD_sceCdForbidDVDP | ||
FFFFFFFFFFFF8AF0 | 5900_s7_reg_upper64 | 0x934BD0 0x16: SCMD_AutoAdjustCtrl | ||
FFFFFFFFFFFF8AF8 | 5900_s7_reg_lower64 | 0x934BD8 0x17: SCMD_CdReadModelNumber Return SCPH-50000 (SCMD 0x03(0x00) return Mechacon version 3.9 which is wrong for that model..) | ||
FFFFFFFFFFFF8B00 | 5900_t8_reg_upper64 | 0x934BE0 0x18: SCMD_CdWriteModelNumber panic | ||
FFFFFFFFFFFF8B08 | 5900_t8_reg_lower64 | 0x934BE8 0x19: SCMD_0x19 panic | ||
FFFFFFFFFFFF8B10 | 5900_t9_reg_upper64 | 0x934BF0 0x1A: SCMD_sceCdBootCertify | ||
FFFFFFFFFFFF8B18 | 5900_t9_reg_lower64 | 0x934BF8 0x1B: SCMD_sceCdCancelPOffRdy | ||
FFFFFFFFFFFF8B20 | 5900_k0_reg_upper64 | 0x934C00 0x1C: SCMD_sceCdBlueLEDCtl | ||
FFFFFFFFFFFF8B28 | 5900_k0_reg_lower64 | 0x934C08 0x1D: SCMD_cdvdman_call116 | ||
FFFFFFFFFFFF8B30 | 5900_k1_reg_upper64 | 0x934C10 0x1E: SCMD_sceRemote2Read | ||
FFFFFFFFFFFF8B38 | 5900_k1_reg_lower64 | 0x934C18 0x1F: SCMD_sceRemote2_7 | ||
FFFFFFFFFFFF8B40 | 5900_gp_reg_upper64 | 0x934C20 0x20: SCMD_Return_0 | ||
FFFFFFFFFFFF8B48 | 5900_gp_reg_lower64 | 0x934C28 0x21: SCMD_Return_0 | ||
FFFFFFFFFFFF8B50 | 5900_sp_reg_upper64 | 0x934C30 0x22: SCMD_Return_0 | ||
FFFFFFFFFFFF8B58 | 5900_sp_reg_lower64 | 0x934C38 0x23: SCMD_Return_0 | ||
FFFFFFFFFFFF8B60 | 5900_fp_reg_upper64 | 0x934C40 0x24: SCMD_Return_0 | ||
FFFFFFFFFFFF8B68 | 5900_fp_reg_lower64 | 0x934C48 0x25: SCMD_Return_0 | ||
FFFFFFFFFFFF8B70 | 5900_ra_reg_upper64 | 0x934C50 0x26: SCMD_Return_0 | ||
FFFFFFFFFFFF8B78 | 5900_ra_reg_lower64 | 0x934C58 0x27: SCMD_Return_0 | ||
FFFFFFFFFFFF9100 | 5900_pc_reg_lower64 | 0x934C60 0x28: SCMD_Return_0 | ||
Below FFFFFFFFFFFF8B78 you can find COP0, and finally VFxx, and VIxx regs. Todo.. | 0x934C68 0x29: SCMD_sceCdNoticeGameStart panic | ||
0x934C70 0x2A: SCMD_Return_0 | |||
==EE I/O Handlers list== | 0x934C78 0x2B: SCMD_Return_0 | ||
===Netemu=== | 0x934C80 0x2C: SCMD_Return_0 | ||
4.75 and up. Mode (1 = read / 2 = write) | 0x934C88 0x2D: SCMD_Return_0 | ||
0x934C90 0x2E: SCMD_Return_0 | |||
{| class="wikitable sortable" | 0x934C98 0x2F: SCMD_Return_0 | ||
!mode !! size !! PS2_HW_REG !! handler_opd | 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. | |||
</pre> | |||
==r5900 regs memory map== | |||
Registers are updated only when recompiler flush them to memory, if there is pending operation on the same register in next instruction, recompiler have no need to update reg before that. So it flush result there. | |||
===Netemu=== | |||
Address in memory | r5900 register | |||
FFFFFFFFFFFF8980 | 5900_zero_upper64bits | |||
FFFFFFFFFFFF8988 | 5900_zero_lower64bits | |||
FFFFFFFFFFFF8990 | 5900_at_reg_upper64 | |||
FFFFFFFFFFFF8998 | 5900_at_reg_lower64 | |||
FFFFFFFFFFFF89A0 | 5900_v0_reg_upper64 | |||
FFFFFFFFFFFF89A8 | 5900_v0_reg_lower64 | |||
FFFFFFFFFFFF89B0 | 5900_v1_reg_upper64 | |||
FFFFFFFFFFFF89B8 | 5900_v1_reg_lower64 | |||
FFFFFFFFFFFF89C0 | 5900_a0_reg_upper64 | |||
FFFFFFFFFFFF89C8 | 5900_a0_reg_lower64 | |||
FFFFFFFFFFFF89D0 | 5900_a1_reg_upper64 | |||
FFFFFFFFFFFF89D8 | 5900_a1_reg_lower64 | |||
FFFFFFFFFFFF89E0 | 5900_a2_reg_upper64 | |||
FFFFFFFFFFFF89E8 | 5900_a2_reg_lower64 | |||
FFFFFFFFFFFF89F0 | 5900_a3_reg_upper64 | |||
FFFFFFFFFFFF89F8 | 5900_a3_reg_lower64 | |||
FFFFFFFFFFFF8A00 | 5900_t0_reg_upper64 | |||
FFFFFFFFFFFF8A08 | 5900_t0_reg_lower64 | |||
FFFFFFFFFFFF8A10 | 5900_t1_reg_upper64 | |||
FFFFFFFFFFFF8A18 | 5900_t1_reg_lower64 | |||
FFFFFFFFFFFF8A20 | 5900_t2_reg_upper64 | |||
FFFFFFFFFFFF8A28 | 5900_t2_reg_lower64 | |||
FFFFFFFFFFFF8A30 | 5900_t3_reg_upper64 | |||
FFFFFFFFFFFF8A38 | 5900_t3_reg_lower64 | |||
FFFFFFFFFFFF8A40 | 5900_t4_reg_upper64 | |||
FFFFFFFFFFFF8A48 | 5900_t4_reg_lower64 | |||
FFFFFFFFFFFF8A50 | 5900_t5_reg_upper64 | |||
FFFFFFFFFFFF8A58 | 5900_t5_reg_lower64 | |||
FFFFFFFFFFFF8A60 | 5900_t6_reg_upper64 | |||
FFFFFFFFFFFF8A68 | 5900_t6_reg_lower64 | |||
FFFFFFFFFFFF8A70 | 5900_t7_reg_upper64 | |||
FFFFFFFFFFFF8A78 | 5900_t7_reg_lower64 | |||
FFFFFFFFFFFF8A80 | 5900_s0_reg_upper64 | |||
FFFFFFFFFFFF8A88 | 5900_s0_reg_lower64 | |||
FFFFFFFFFFFF8A90 | 5900_s1_reg_upper64 | |||
FFFFFFFFFFFF8A98 | 5900_s1_reg_lower64 | |||
FFFFFFFFFFFF8AA0 | 5900_s2_reg_upper64 | |||
FFFFFFFFFFFF8AA8 | 5900_s2_reg_lower64 | |||
FFFFFFFFFFFF8AB0 | 5900_s3_reg_upper64 | |||
FFFFFFFFFFFF8AB8 | 5900_s3_reg_lower64 | |||
FFFFFFFFFFFF8AC0 | 5900_s4_reg_upper64 | |||
FFFFFFFFFFFF8AC8 | 5900_s4_reg_lower64 | |||
FFFFFFFFFFFF8AD0 | 5900_s5_reg_upper64 | |||
FFFFFFFFFFFF8AD8 | 5900_s5_reg_lower64 | |||
FFFFFFFFFFFF8AE0 | 5900_s6_reg_upper64 | |||
FFFFFFFFFFFF8AE8 | 5900_s6_reg_lower64 | |||
FFFFFFFFFFFF8AF0 | 5900_s7_reg_upper64 | |||
FFFFFFFFFFFF8AF8 | 5900_s7_reg_lower64 | |||
FFFFFFFFFFFF8B00 | 5900_t8_reg_upper64 | |||
FFFFFFFFFFFF8B08 | 5900_t8_reg_lower64 | |||
FFFFFFFFFFFF8B10 | 5900_t9_reg_upper64 | |||
FFFFFFFFFFFF8B18 | 5900_t9_reg_lower64 | |||
FFFFFFFFFFFF8B20 | 5900_k0_reg_upper64 | |||
FFFFFFFFFFFF8B28 | 5900_k0_reg_lower64 | |||
FFFFFFFFFFFF8B30 | 5900_k1_reg_upper64 | |||
FFFFFFFFFFFF8B38 | 5900_k1_reg_lower64 | |||
FFFFFFFFFFFF8B40 | 5900_gp_reg_upper64 | |||
FFFFFFFFFFFF8B48 | 5900_gp_reg_lower64 | |||
FFFFFFFFFFFF8B50 | 5900_sp_reg_upper64 | |||
FFFFFFFFFFFF8B58 | 5900_sp_reg_lower64 | |||
FFFFFFFFFFFF8B60 | 5900_fp_reg_upper64 | |||
FFFFFFFFFFFF8B68 | 5900_fp_reg_lower64 | |||
FFFFFFFFFFFF8B70 | 5900_ra_reg_upper64 | |||
FFFFFFFFFFFF8B78 | 5900_ra_reg_lower64 | |||
FFFFFFFFFFFF9100 | 5900_pc_reg_lower64 | |||
Below FFFFFFFFFFFF8B78 you can find COP0, and finally VFxx, and VIxx regs. Todo.. | |||
==EE I/O Handlers list== | |||
===Netemu=== | |||
4.75 and up. Mode (1 = read / 2 = write) | |||
{| class="wikitable sortable" | |||
!mode !! size !! PS2_HW_REG !! handler_opd | |||
|- | |- | ||
| 1 || 4 || | | 1 || 4 || T0_COUNT || stru_723218 | ||
|- | |- | ||
| | | 2 || 4 || T0_COUNT || stru_723290 | ||
|- | |- | ||
| 1 || 4 || | | 1 || 4 || T0_MODE || stru_723308 | ||
|- | |- | ||
| | | 2 || 4 || T0_MODE || stru_7233E0 | ||
|- | |- | ||
| 1 || 4 || | | 1 || 4 || T0_COMP || stru_7231A0 | ||
|- | |- | ||
| | | 2 || 4 || T0_COMP || stru_723248 | ||
|- | |- | ||
| 1 || 4 || | | 1 || 4 || T0_HOLD || stru_723110 | ||
|- | |- | ||
| | | 2 || 4 || T0_HOLD || stru_723128 | ||
|- | |- | ||
| 1 || 4 || | | 1 || 4 || T1_COUNT || stru_7232F0 | ||
|- | |- | ||
| | | 2 || 4 || T1_COUNT || stru_7233B0 | ||
|- | |- | ||
| 1 || 4 || | | 1 || 4 || T1_MODE || stru_723278 | ||
|- | |- | ||
| | | 2 || 4 || T1_MODE || stru_723260 | ||
|- | |- | ||
| 1 || 4 || | | 1 || 4 || T1_COMP || stru_723140 | ||
|- | |- | ||
| | | 2 || 4 || T1_COMP || stru_723380 | ||
|- | |- | ||
| 1 || 4 || | | 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 || | | 2 || 4 || T2_MODE || stru_723410 | ||
|- | |- | ||
| 1 || | | 1 || 4 || T2_COMP || stru_7231D0 | ||
|- | |- | ||
| 2 || | | 2 || 4 || T2_COMP || stru_723368 | ||
|- | |- | ||
| 1 || 4 || | | 1 || 4 || T3_COUNT || stru_7232C0 | ||
|- | |- | ||
| 2 || 4 || | | 2 || 4 || T3_COUNT || stru_7233C8 | ||
|- | |- | ||
| 1 || 4 || | | 1 || 4 || T3_MODE || stru_723320 | ||
|- | |- | ||
| 2 || 4 || | | 2 || 4 || T3_MODE || stru_7233F8 | ||
|- | |- | ||
| 1 || 4 || | | 1 || 4 || T3_COMP || stru_7231B8 | ||
|- | |- | ||
| 2 || 4 || | | 2 || 4 || T3_COMP || stru_723350 | ||
|- | |- | ||
| 1 || | | 1 || 8 || IPU_CMD || stru_721910 | ||
|- | |- | ||
| 2 || | | 2 || 8 || IPU_CMD || stru_7218F8 | ||
|- | |- | ||
| 1 || 4 || | | 1 || 4 || IPU_CTRL || stru_721970 | ||
|- | |- | ||
| 2 || 4 || | | 2 || 4 || IPU_CTRL || stru_721958 | ||
|- | |- | ||
| 1 || 4 || | | 1 || 4 || IPU_BP || stru_721940 | ||
|- | |- | ||
| | | 1 || 8 || IPU_TOP || stru_721928 | ||
|- | |- | ||
| | | 2 || 4 || GIF_CTRL || stru_7220C0 | ||
|- | |- | ||
| 2 || 4 || | | 2 || 4 || GIF_MODE || stru_7220A8 | ||
|- | |- | ||
| 1 || 4 || | | 1 || 4 || GIF_STAT || stru_722000 | ||
|- | |- | ||
| | | 1 || 4 || GIF_TAG0 || stru_721EB0 | ||
|- | |- | ||
| 1 || 4 || | | 1 || 4 || GIF_TAG1 || stru_721FE8 | ||
|- | |- | ||
| | | 1 || 4 || GIF_TAG2 || stru_721FD0 | ||
|- | |- | ||
| 1 || 4 || | | 1 || 4 || GIF_TAG3 || stru_721FB8 | ||
|- | |- | ||
| | | 1 || 4 || GIF_CNT || stru_721EC8 | ||
|- | |- | ||
| 1 || 4 || | | 1 || 4 || GIF_P3CNT || stru_721EE0 | ||
|- | |- | ||
| | | 1 || 4 || GIF_P3TAG || stru_721EF8 | ||
|- | |- | ||
| 1 || 4 || | | 1 || 4 || VIF0_STAT || stru_721820 | ||
|- | |- | ||
| 2 || 4 || | | 2 || 4 || VIF0_FBRST || stru_721868 | ||
|- | |- | ||
| 1 || 4 || | | 1 || 4 || VIF0_ERR || stru_7217A8 | ||
|- | |- | ||
| 2 || 4 || | | 2 || 4 || VIF0_ERR || stru_721598 | ||
|- | |- | ||
| 1 || 4 || | | 1 || 4 || VIF0_MARK || stru_721790 | ||
|- | |- | ||
| 2 || 4 || | | 2 || 4 || VIF0_MARK || stru_7215B0 | ||
|- | |- | ||
| 1 || 4 || | | 1 || 4 || VIF0_CYCLE || stru_721778 | ||
|- | |- | ||
| | | 1 || 4 || VIF0_MODE || stru_721760 | ||
|- | |- | ||
| 1 || 4 || | | 1 || 4 || VIF0_NUM || stru_721748 | ||
|- | |- | ||
| | | 1 || 4 || VIF0_MASK || stru_721730 | ||
|- | |- | ||
| 1 || 4 || | | 1 || 4 || VIF0_CODE || stru_721718 | ||
|- | |- | ||
| | | 1 || 4 || VIF0_ITOPS || stru_721700 | ||
|- | |- | ||
| 1 || 4 || | | 1 || 4 || VIF0_ITOP || stru_7216E8 | ||
|- | |- | ||
| | | 1 || 4 || VIF0_R0 || stru_7216D0 | ||
|- | |- | ||
| 1 || 4 || | | 1 || 4 || VIF0_R1 || stru_7216B8 | ||
|- | |- | ||
| | | 1 || 4 || VIF0_R2 || stru_7216A0 | ||
|- | |- | ||
| 1 || 4 || | | 1 || 4 || VIF0_R3 || stru_721688 | ||
|- | |- | ||
| | | 1 || 4 || VIF0_C0 || stru_721670 | ||
|- | |- | ||
| 1 || 4 || | | 1 || 4 || VIF0_C1 || stru_721658 | ||
|- | |- | ||
| | | 1 || 4 || VIF0_C2 || stru_721640 | ||
|- | |- | ||
| 1 || 4 || | | 1 || 4 || VIF0_C3 || stru_721628 | ||
|- | |- | ||
| | | 1 || 4 || VIF1_STAT || stru_722960 | ||
|- | |- | ||
| | | 2 || 4 || VIF1_STAT || stru_722618 | ||
|- | |- | ||
| 2 || 4 || | | 2 || 4 || VIF1_FBRST || stru_722A98 | ||
|- | |- | ||
| 1 || 4 || | | 1 || 4 || VIF1_ERR || stru_722948 | ||
|- | |- | ||
| 2 || 4 || | | 2 || 4 || VIF1_ERR || stru_722630 | ||
|- | |- | ||
| 1 || 4 || | | 1 || 4 || VIF1_MARK || stru_722930 | ||
|- | |- | ||
| 2 || 4 || | | 2 || 4 || VIF1_MARK || stru_722648 | ||
|- | |- | ||
| 1 || 4 || | | 1 || 4 || VIF1_CYCLE || stru_722918 | ||
|- | |- | ||
| | | 1 || 4 || VIF1_MODE || stru_722900 | ||
|- | |- | ||
| 1 || 4 || | | 1 || 4 || VIF1_NUM || stru_7228E8 | ||
|- | |- | ||
| | | 1 || 4 || VIF1_MASK || stru_7228D0 | ||
|- | |- | ||
| 1 || 4 || | | 1 || 4 || VIF1_CODE || stru_7228B8 | ||
|- | |- | ||
| | | 1 || 4 || VIF1_ITOPS || stru_7228A0 | ||
|- | |- | ||
| 1 || 4 || | | 1 || 4 || VIF1_BASE || stru_722888 | ||
|- | |- | ||
| | | 1 || 4 || VIF1_OFST || stru_722870 | ||
|- | |- | ||
| 1 || 4 || | | 1 || 4 || VIF1_TOPS || stru_722858 | ||
|- | |- | ||
| | | 1 || 4 || VIF1_ITOP || stru_722840 | ||
|- | |- | ||
| 1 || 4 || | | 1 || 4 || VIF1_TOP || stru_722828 | ||
|- | |- | ||
| | | 1 || 4 || VIF1_R0 || stru_722810 | ||
|- | |- | ||
| 1 || 4 || | | 1 || 4 || VIF1_R1 || stru_7227F8 | ||
|- | |- | ||
| | | 1 || 4 || VIF1_R2 || stru_7227E0 | ||
|- | |- | ||
| 1 || 4 || | | 1 || 4 || VIF1_R3 || stru_7227C8 | ||
|- | |- | ||
| | | 1 || 4 || VIF1_C0 || stru_7227B0 | ||
|- | |- | ||
| 1 || 4 || | | 1 || 4 || VIF1_C1 || stru_722798 | ||
|- | |- | ||
| | | 1 || 4 || VIF1_C2 || stru_722780 | ||
|- | |- | ||
| 1 || 4 || | | 1 || 4 || VIF1_C3 || stru_722768 | ||
|- | |- | ||
| 2 || | | 2 || 0x10 || VIF0_FIFO || stru_721850 | ||
|- | |- | ||
| 1 || | | 1 || 0x10 || VIF1_FIFO || stru_722678 | ||
|- | |- | ||
| 2 || | | 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 || | | 2 || 4 || D2_TADR || stru_722AF8 | ||
|- | |- | ||
| 1 || 4 || | | 1 || 4 || D2_ASR0 || stru_722990 | ||
|- | |- | ||
| 2 || 4 || | | 2 || 4 || D2_ASR0 || stru_7226D8 | ||
|- | |- | ||
| 1 || 4 || | | 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 || | | 1 || 4 || D4_QWC || stru_723770 | ||
|- | |- | ||
| 2 || 4 || | | 2 || 4 || D4_QWC || stru_723830 | ||
|- | |- | ||
| 1 || 4 || | | 1 || 4 || D4_TADR || stru_723758 | ||
|- | |- | ||
| 2 || 4 || | | 2 || 4 || D4_TADR || stru_723818 | ||
|- | |- | ||
| 1 || 4 || | | 1 || 4 || D5_CHCR || stru_722498 | ||
|- | |- | ||
| 2 || 4 || | | 2 || 4 || D5_CHCR || stru_7224C8 | ||
|- | |- | ||
| 1 || 4 || | | 1 || 4 || D5_MADR || stru_722408 | ||
|- | |- | ||
| 2 || 4 || | | 2 || 4 || D5_MADR || stru_722390 | ||
|- | |- | ||
| 1 || | | 1 || 4 || D5_QWC || stru_722468 | ||
|- | |- | ||
| 2 || | | 2 || 4 || D5_QWC || stru_7223F0 | ||
|- | |- | ||
| 1 || | | 1 || 4 || D6_CHCR || stru_722480 | ||
|- | |- | ||
| | | 2 || 4 || D6_CHCR || stru_7224B0 | ||
|- | |- | ||
| 1 || | | 1 || 4 || D6_MADR || stru_722450 | ||
|- | |- | ||
| | | 2 || 4 || D6_MADR || stru_7223D8 | ||
|- | |- | ||
| 1 || 4 || | | 1 || 4 || D6_QWC || stru_722420 | ||
|- | |- | ||
| | | 2 || 4 || D6_QWC || stru_7223A8 | ||
|- | |- | ||
| | | 1 || 4 || unk_1000C430 || stru_722438 | ||
|- | |- | ||
| 2 || | | 2 || 4 || unk_1000C430 || stru_7223C0 | ||
|- | |- | ||
| | | 1 || 4 || D7_CHCR || stru_7235C0 | ||
|- | |- | ||
| 2 || | | 2 || 4 || D7_CHCR || stru_723530 | ||
|- | |- | ||
| | | 1 || 4 || D7_MADR || stru_7235A8 | ||
|- | |- | ||
| 2 || | | 2 || 4 || D7_MADR || stru_723500 | ||
|- | |- | ||
| | | 1 || 4 || D7_QWC || stru_723590 | ||
|- | |- | ||
| 2 || | | 2 || 4 || D7_QWC || stru_723518 | ||
|- | |- | ||
| | | 1 || 4 || D8_CHCR || stru_7222D0 | ||
|- | |- | ||
| 2 || | | 2 || 4 || D8_CHCR || stru_7222E8 | ||
|- | |- | ||
| | | 1 || 4 || D8_MADR || stru_7222B8 | ||
|- | |- | ||
| 2 || | | 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 || | | 2 || 4 || D8_SADR || stru_722198 | ||
|- | |- | ||
| | | 1 || 4 || D9_CHCR || stru_722270 | ||
|- | |- | ||
| 2 || | | 2 || 4 || D9_CHCR || stru_722318 | ||
|- | |- | ||
| 1 || | | 1 || 4 || D9_MADR || stru_722258 | ||
|- | |- | ||
| 2 || | | 2 || 4 || D9_MADR || stru_7221F8 | ||
|- | |- | ||
| | | 1 || 4 || D9_QWC || stru_722240 | ||
|- | |- | ||
| 2 || | | 2 || 4 || D9_QWC || stru_7221B0 | ||
|- | |- | ||
| 1 || | | 1 || 4 || D9_TADR || stru_722228 | ||
|- | |- | ||
| 2 || | | 2 || 4 || D9_TADR || stru_7221E0 | ||
|- | |- | ||
|} | | 1 || 4 || D9_SADR || stru_722210 | ||
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] | | 2 || 4 || D9_SADR || stru_7221C8 | ||
* 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] | | 1 || 4 || D_CTRL || stru_721C28 | ||
* 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. | | 2 || 4 || D_CTRL || stru_721C70 | ||
* 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] | | 1 || 4 || D_STAT || stru_724130 | ||
* 1000F8B0 return unk value. Seems to be related to fe spe. [r only] | |- | ||
| 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== | ||
===IOP SPE=== | |||
This | |||
SPE run not only dma related stuff, but also fully fledged r3000 instruction interpreter (yes interpreter, not recompiler). | |||
<pre> | |||
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. | |||
</pre> | |||
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=== | |||
That one is one of most misleading names in whole emulator.. <br> | |||
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.<br> | |||
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=== | ||
VU1 SPE program starts at 0x4000 of LS. Start function is responsible for loading all 128 spe registers with values from memory starting from 0x4230 of LS for r0, ends at 0x4A20 for r127 (r127 is trashed literally in next opcode after that...). This should result in all 0 value regs, excluding r0 which will be set to float(1.0, 0, 0, 0) like ps2 vf00. After that function notify PPE side that its done, and jump to 0x8000, here fun begins. SPE program now clear LS memory from 0x0000 to 0x7FF0, this include VU1 data mem that is located at first 0x4000 bytes. What's more important function that we started at 0x4000 will be deleted. Yup, self modifying code on SPU (good luck for eventual emulator that will try to run ps2_netemu). | |||
<br> | |||
When I disassembled VU1 SPE program, i noticed that real code is really small part of that. Not much to run real VU recompiler/interpreter. | |||
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 | |||
<br><br> | |||
SPU registers always follow this layout when VU1 is running: | |||
*r0 - r31 = vf00 - vf31 | |||
*r32 - r57 = vi00 - vi25 (vu ctrl regs above vi25 are mapped to vu0 anyway) | |||
*r48 = ACC (accessible from VU0 as vi19) | |||
Additionally ppu can access those regs with addresses 0x3000xyy0. | |||
Where x is 4,5,6, or 7 (mirrors), and yy is reg number in hex. | |||
*0x30004100 = vf16 | |||
*0x30004200 = vi00 | |||
*0x30004350 = I register (vi21) | |||
etc. | |||
Is worth to note that ppu is not accessing spu regs directly, instead 0x3000x000 is mapped to 0x3F000 of vu1 local store. On real PS2 hardware regs are accessible only when VU1 is stopped so program just dump regs to that location on every vu1 stop (ebit/tbit/force break). | |||
This mapping is added specially for VU0 which can access VU1 registers by use of memory address, when vu0 recompiled program run ppu always load 0x30000000 to r1 to compute address if needed. | |||
=== | ===IPU SPE6=== | ||
====IDEC start code detection==== | |||
IDEC perform compare to 0 while starting to search code, but not check that required bits are even available in stream. | |||
Buffer is not refilled when there is more than 0 bits available (function proceed even if there is only 1 bit available). Next compare whole word to 0, which is wrong thing to do. Specially that whole word can be not even available at this point. More over there is no check that at least 8 "0" bits are in stream that way. So start code detection is totally broken. Surprisingly this seems to be handled properly for BDEC.. | |||
This probably break Onimusha DoD, and many other random games. | |||
====IPU skip mpeg hack==== | |||
There are some leftovers of SKIP MPEG hack in SPE 6 (IPU), i'm not sure that is still available. | |||
===SPE4 and SPE5=== | |||
And SPE7, because someone there forgot it doesn't work in retail. :P First thing is that emulator do a lot of setup for SPE7, including creating virtual address to access it (0x40380000 - 0x403BFFFF). Only thing that seems to be missing is actually starting that SPE. | |||
SPE4 (FE) have a lot of PS2 GIF related code, GS downloads function in PPE check something there (BUSY? BUSDIR? DL ready? bit), and if that bit is not 1 loop for 1000000 x 4 cycles and check again. That spe is also place where GIF_TAG# can be read, so last processed tag on GIF unit. That was greatest hint to be honest, there is no reason to send it there if is not processed there. This is also where 0x49 and 0x4D config commands go. And surprisingly they are not really related. But fact is they go thru same parser on SPE side. 11, and 12 from those commands are subcommand on SPE side. 11 take no args that's why 0x49 send 11,0,0. 12 take 1 arg, and that's why 0x4D send 12, param, 0.<br> | |||
SPE5 (BE), well i didn't reversed that one too much. But it seems to have relation with "FE", and with RSX. This is only speculation but it seems that FE and BE are FrontEnd and BackEnd for GIF/GS emulation tandem. My first idea was BlendingEngine, but that doesn't seems to be the case. Well those 2 need more work. | |||
==SCANMSK on ps2_netemu== | |||
Apparently SCANMSK is not really ignored, GIF process it, update, etc. So is rather not implemented in later parts of code (GS emulation), or this is some other bug. I guess this GIF code is shared with ps2_gxemu, so maybe it is really missing processing on software GS emulation in later stages. | |||
0xD34C hbrr loc_D38C, Update_7E98 | |||
0xD350 lr r4, r80 | |||
0xD354 lqr r9, SCANMSK_REG | |||
0xD358 il r3, 0x22 ; GIF_REG_NR | |||
0xD35C shlqbyi r5, r80, 4 | |||
0xD360 cwd r6, 0x30+var_30+0xC(sp) | |||
0xD364 andi r5, r5, 3 ; New SCANMSK write | |||
0xD368 rotqbyi r8, r9, 0xC | |||
0xD36C ceq r7, r8, r5 | |||
0xD370 brnz r7, return_D390 ; branch if old SCANMSK == new | |||
0xD374 lqr r11, SCANMSK_REG | |||
0xD378 lqd lr, 0x30+link_reg(sp) | |||
0xD37C ai sp, sp, 0x30 | |||
0xD380 lqd r80, var_10(sp) | |||
0xD384 shufb r10, r5, r11, r6 | |||
0xD388 stqr r10, SCANMSK_REG | |||
0xD38C br UpdateGS_7E98 | |||
==PS2 masterlist with ps2 emu hashes== | |||
*See: [[PS2_Emulation/PS2_Games_Masterlist]] | |||
== ps2_netemu supported video modes == | |||
Both HDTV modes (0x51 1080i and 0x52 720p) crash the emulator. 0x53 576p mode does not, but the image is squished and displaced (looks like the DW is 2560, instead of 1440 and I cannot find any reliable documentation about this mode). Tested by forcing the values in the sceGsResetGraph function. | |||
* None of released games support 576p, so they probably didn't bothered. Afaik that mode is not really used for anything in PS2, like some leftover after testing, or something. I remember that older PS2 don't support it at all, so maybe it was planned as new feature? Also does forcing 480p work? I remember that 480p patching from Managunz gave similar result to what you described for 0x53 mode. But maybe its just broken feature in Managunz itself, i never tested manual patch. --[[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) | |||
=== Widescreen support === | |||
If the game does retrieve the widescreen flag from the GetOSDConfigParam through the scescfGetAspect function, the results are as follows: | |||
* Upscaler turned off: widescreen flag set by BIOS, | |||
* Upscaler turned on - Normal setting (keep original aspect ratio): no flag is set, | |||
* Upscaler turned on - Full screen setting: widescreen flag set by BIOS. | |||
Assuming the PS3 is connected with the HDMI cable and all HD resolutions are ticked in settings. Probably the widescreen support with the upscaler turned off is dependent on the connection and the PS3 resolution settings. | |||
== Emu Patches == | |||
===Display current PC/RA values for r5900=== | |||
Require '''ps2_netemu''' with 3141card patches to display temperatures (every current cfw have it). Mod update values in crazy interval, this is intended. Because mod is used mostly to figure out when game stuck on specific loop. But this can be easily modified to allow less frequent updates. Please note that PC and RA update only when recompiler registers are flushed to memory, luckily for us this happen on every r5900 branch test. | |||
search for (2 times): | |||
3F 40 02 41 63 5A E3 0C 89 3A 00 00 2F 89 00 00 | |||
39 29 FF FF 41 9E 00 7C 99 3A 00 00 88 DA 00 01 | |||
88 FA 00 02 | |||
replace to (2 times): | |||
60 00 00 00 60 00 00 00 60 00 00 00 60 00 00 00 | |||
60 00 00 00 60 00 00 00 60 00 00 00 80 C0 91 00 | |||
80 E0 8B 7C | |||
search for: | |||
43 45 4C 4C 3A 20 25 30 32 64 20 C2 B0 43 26 23 | |||
78 61 3B 52 53 58 3A 20 20 20 25 30 32 64 20 C2 | |||
B0 43 00 | |||
replace to: | |||
50 43 3A 20 25 30 38 58 26 23 78 61 3B 52 41 3A | |||
20 25 30 38 58 00 00 00 00 00 00 00 00 00 00 00 | |||
00 00 00 | |||
== | ===Skip demo disc check=== | ||
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=== | |||
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.<br> | |||
gxemu.elf MD5 before patch | |||
38D891A6A67F9275D1B6D18E04BDCAA7 | |||
gxemu.elf MD5 after patch | |||
B452CCB51348127DAF8A931B621E5E39 | |||
DL: https://www.mediafire.com/file/kpno5mubyy7q9p0/gx_cfg_ext.ppf/file | |||
== SPE programs dumper == | |||
Script for IDA to dump SPE programs from PS2 emulators, don't work with ps2_emu. Script is basing on SPE program names to find correct offsets. Due to that is will miss any SPE program which name is not listed inside script. Tested with ps2_gxemu/ps2_softemu/ps2_netemu. | |||
https://pastebin.com/x8fvY1UL | |||
== Random ps2_netemu notes == | |||
* Some members of pcsx2 team think that emulator is heavily based on early pcsx2. After some reversing this seems to be far away from true. But COP2 and VU0 (and only that for now) really are familiar here and there. To the point where i was able to use pcsx2 code to find names/usage of some variables (mVUbranch for example). But VU0/COP2 is for now only part that have obvious pcsx2 similarities. For example VU1 is different story, and don't even share code with VU0 part of emulator as far as i see. | |||
* Emulator not only patch SPU programs on init, but also patch own PPU code. Which is hard to understand when you can just make changes in source code... eg. 0x1F128 - 0x1F134 in latest emu. | |||
* 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. | |||
===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. | |||
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. | |||
== RSX workload on the netemu == | |||
Looks like there is a way to overclock the RSX core by 50 or 100 MHz through LV1 patches. Will the netemu benefit from it? | |||
* Yes, i don't see why not. Assuming that is static patch to elf file, not some cobra style on the fly patch. But don't expect some magic from that. I don't know too much about RSX and not really much about GS. But PS2 emulation is usually limited by CPU power, specially in native resolution. But for example games that need 0x44 cmd, maybe they will work with smoothing now. Maybe some minor slowdowns will be fixed. I still don't know which parts of GS are emulated on RSX, for example softemu used something similar to pcsx2 software render. So there you will get almost nothing from RSX OC. But netemu is different. --[[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. | |||
== Netemu load/store with r0 register == | |||
Emulator access weird addresses which are interpreted as eg. 0xFFFFFFFFFFFF9480, or load/store like std r14, -0x6B80(r0) which translate to std r14, -FFFF9480(r0), and its sign extended by CPU to 64 bit. | |||
Also easier example (without using negative addressing because this is additional emu quirk..). ld r2, 0x3008(r0). This opcode will load double word from 0x3008 address no matter what we currently have in r0, because RA is 0 which is badly interpreted as r0 base. | |||
This is because of PowerPC quirk that i (and apparently IDA in 64 bit mode) wasn't aware. From IBM manual: | |||
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. | 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. | |||
== ps2_gxemu external bios/rom loading. == | |||
Emulator can load external bios file. File need to be 4 bytes aligned, and 4MB or less size. File name need to be rom.bin (lower case), and probably need to have patched out RDRAM module to success RD check. At least that check is patched in current ps2_gxemu.self rom, maybe is not really needed. | |||
To load bios we need to set emulator status flag bit 2 to true. I'm not sure that is already set, because i don't have memory dump, only elf file. In case is not, we can probably just ignore that check by patch. Emulator read file using lv1_read_remote_file with type 1, and path "rom.bin". So it seems to be relative to emulator self file (dev_flash/ps2emu)? All code is there and is valid, so external bios loading is fully implemented. Only two things required to do that is second bit of status flag set to true, and rom.bin file in correct path. | |||
Note: This code don't exist in ps2_netemu. | |||
== Shin Sangoku Musou config == | |||
This config does something with sceGsSyncPath by storing 0x4 to INTC_STAT before jumping to it (from one of the main function, so only a specific jump to sceGsSyncPath). I am thinking it fixes this: WhECT9RGZ0k (YouTube link) | |||
What could be happening internally for something like this to be fixed? Interrupt delay to avoid an infinite loop or something? The freeze looks similar to something like the Ecole games (Melty Blood) where the game can move slightly after the freeze, or even break out of it entirely (rare). | |||
* 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) | |||
** 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) | |||
== Universal DNAS anti-wipe patch == | |||
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. | |||
<pre> | <pre> | ||
Original: 18 00 A2 AF 95 00 00 0C 1C 00 A0 AF | Original: 18 00 A2 AF 95 00 00 0C 1C 00 A0 AF | ||
| Line 1,675: | Line 2,176: | ||
* '''Dance Summit 2001: Bust-a-Move''' | * '''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. | ** Front buffer is not flushed most of the time. Game seems to apply additional effects there, apart from the downsampling. | ||
== Stuntman/Driv3r research == | == Stuntman/Driv3r research == | ||
| Line 1,765: | Line 2,264: | ||
*PS2 Memory and Hardware Mapped Registers Layout | *PS2 Memory and Hardware Mapped Registers Layout | ||
*Video Modes | *Video Modes | ||
* | *Config related info | ||
'''Video Modes''' listed there are not even supported by emulators without GS, and likely to fail even on PS3 with GS. This is really info for PS2 wiki in my opinion. '''PS2 Memory and Hardware Mapped Registers Layout''' also fit more in PS2 wiki. This is more like general PS2 dev knowledge than emulation related stuff. Eventually keep them as a links to ps2tek or ps2 devwiki, or something. Let me know if you think this is/isn't good idea. For example PS1 page don't list stuff like this, same goes for PSP page. In case of Config stuff. This is crucial part of this page, but i feel that harm general readability. Due to complicated nature of PS2 config descriptions are getting bigger, and bigger. Honestly this is still missing a lot of info because many times we are limiting ourself to not make descriptions too extensive. All that to not flood page too much. Maybe it's time to move most of that to new dedicated page? We can leave some basic info, like that small table, plus some '''BOLD''' link to "advanced page". This should allow to wikify and move some non-config stuff from talk page. This are only ideas, i expect not everyone will be happy about all of them. Lets talk. :P --[[User:Kozarovv|Kozarovv]] ([[User talk:Kozarovv|talk]]) 08:21, 16 January 2023 (UTC) | '''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) | ||
| Line 1,786: | Line 2,285: | ||
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. | 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 | | | Opcode type | Netemu/Gxemu | PCSX2 | | ||
|----------------| | |----------------|-----------------|-------------| | ||
| Default opcode | 1 unit | | Default opcode | 1 unit | 9 units | | ||
| Load/Store | 2 units | | Load/Store | 2 units | 14 units | | ||
| Multiply | 4 units | | Multiply | 4 units | 16 units | | ||
| Divide | 37 units | | Divide | 37 units | 112 units | | ||
| COP 0 | 1 unit | | COP 0 | 1 unit | 7 units | | ||
| COP 1 | 1 unit(some 2) | | COP 1 | 1 unit(some 2) | 7 units | | ||
| COP 2 | 1 unit | | COP 2 | 1 unit | 7 untis | | ||
-------------------------------------------------- | |||
Additionally pcsx2 use different cycles for many other opcodes that ps3 emus just count as one. | Additionally pcsx2 use different cycles for many other opcodes that ps3 emus just count as one. | ||
| Line 1,806: | Line 2,304: | ||
At the second hand gx/net emu do some weird shenigans with cycles based on... Opcode number, this is still small unknown here. Yeah... | At the second hand gx/net emu do some weird shenigans with cycles based on... Opcode number, this is still small unknown here. Yeah... | ||
Underclocking/Overclocking could be done by modifying opcodes at 0x17CEB0, 0x17CFF8, 0x17D4C8. | |||
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. | 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. | ||
| Line 2,019: | Line 2,503: | ||
4000 = SPC_PUINT_MB | 4000 = SPC_PUINT_MB | ||
5000 = SPC_CSR1 | 5000 = SPC_CSR1 | ||
|| | |||
|- | |- | ||
| SPC_CSR | | SPC_CSR | ||
| Line 2,040: | Line 2,525: | ||
4000 = SPC_PUINT_MB | 4000 = SPC_PUINT_MB | ||
5000 = SPC_CSR1 | 5000 = SPC_CSR1 | ||
|| | |||
|- | |- | ||
| SPC_CSR | | SPC_CSR | ||
| Line 2,425: | Line 2,911: | ||
|| | || | ||
|- | |- | ||
| eerom_jit_lut | | eerom_jit_lut | ||
|| 0x2FC00000 | || 0x2FC00000 | ||
|| 0x30000000 | || 0x30000000 | ||
|| 0xE00000003 | || 0xE00000003 | ||
|| | |||
|- | |||
| ? | |||
|| 0xAAA700C0000 | |||
|| 0xAAA70100000 | |||
|| 0x4200030000001 | |||
|| | |||
|- | |||
| ? | |||
|| 0xAAA70100000 | |||
|| 0xAAA70140000 | |||
|| 0x4200040000001 | |||
|| | |||
|- | |||
| ? | |||
|| 0xAAA70140000 | |||
|| 0xAAA70180000 | |||
|| 0x4200050000001 | |||
|| | |||
|- | |||
| ? | |||
|| 0xAAA70180000 | |||
|| 0xAAA701C0000 | |||
|| 0x4200060000001 | |||
|| | |||
|- | |||
| ? | |||
|| 0xAAA701C0000 | |||
|| 0xAAA70200000 | |||
|| 0x4200070000001 | |||
|| | |||
|- | |||
| ? | |||
|| 0xAAA70200000 | |||
|| 0xAAA70280000 | |||
|| 0x4200090000001 | |||
|| | |||
|- | |||
| ? | |||
|| 0xAAA70280000 | |||
|| 0xAAA702C0000 | |||
|| 0x42000A0000001 | |||
|| | |||
|- | |||
| ? | |||
|| 0xAAA70080000 | |||
|| 0xAAA700C0000 | |||
|| 0x42000B0000001 | |||
|| | |||
|- | |||
| ? | |||
|| 0xAAA702C0000 | |||
|| 0xAAA70300000 | |||
|| 0x42000B0000001 | |||
|| | |||
|- | |||
| ? | |||
|| 0xAAA70000000 | |||
|| 0xAAA70040000 | |||
|| 0x4200000000001 | |||
|| | |||
|- | |||
| ? | |||
|| 0xAAA70040000 | |||
|| 0xAAA70080000 | |||
|| 0x4200010000001 | |||
|| | || | ||
|- | |- | ||
|} | |} | ||
| Line 2,670: | Line 3,156: | ||
0xFFFFFFFFFFFFF0EC = D_STAT full | 0xFFFFFFFFFFFFF0EC = D_STAT full | ||
0xFFFFFFFFFFFFF0F0 = D_STAT upper 16 bits | 0xFFFFFFFFFFFFF0F0 = D_STAT upper 16 bits | ||