[GPU] Missing `PM4_EVENT_WRITE_CFL` / 0x59 opcode, causing XEX1 titles to hang

[emoose]

ATM XEX1 titles will hang with Unimplemented GPU OPCODE: 0x59, but did some testing at https://github.com/emoose/xenia/issues/46 with a couple beta titles, seem to have them running without major issues.

E.g. Football Manager 2005 (2005-08-08) (beta):

Didn't take too much thankfully, found two different methods that could let it work:

• Change VdGetGraphicsAsicID to return 0x10, which makes XEX1 titles use 0x58 instead of 0x59
• Add PM4_EVENT_WRITE_CFL (0x59) to CommandProcessor::ExecutePacketType3, running same code as PM4_EVENT_WRITE_SHD (0x58)

The first option probably isn't a good idea since it seems retail kernel always returns 0x11 for it (same as Xenia), the second option does seems to work fine (as used in the pic above), but no idea if Xenia should maybe be implementing it differently to _SHD (though from the dolphin XEX comparison in the link it seems to treat them pretty much the same :shrug; )

Kinda interesting that Xenia never had to implement that already, guess no retail titles ever make use of it, must have been dropped during beta->final for some reason (or maybe on beta kits EVENT_WRITE_SHD was originally 0x59?)

[gibbed]

Do XEX1 files have versioned imports like XEX2 files do?

I haven't personally looked at the XEX1 format yet.

[emoose]

Yep it's mostly the same as XEX2 besides security info having some fields moved around IIRC, other than that I think all the other headers match up.

eg here's log output for the football manager XEX1:

i> 0000A3DC Module \Device\Harddisk0\Partition1\fm.exe:
    Module Flags: 00000001
Security Header:
     Image Flags: 00000000
    Load Address: 82000000
      Image Size: 013B0000
    Export Table: 830DBA8C
Optional Header Count: 11
  XEX_HEADER_FILE_FORMAT_INFO (TODO):
  XEX_HEADER_ORIGINAL_BASE_ADDRESS: 00400000
  XEX_HEADER_ENTRY_POINT: 82908A10
  XEX_HEADER_IMAGE_BASE_ADDRESS: 82000000
  XEX_HEADER_IMPORT_LIBRARIES:
    xam.xex - 142 imports
      Version: 0.0.1838.32
      Min Version: 0.0.1838.32
    xboxkrnl.exe - 310 imports
      Version: 0.0.1838.32
      Min Version: 0.0.1838.32
  Unknown Header 00010400
  XEX_HEADER_CHECKSUM_TIMESTAMP (TODO):
  XEX_HEADER_STATIC_LIBRARIES:
    XRTLLBB  : 2.0.1838.0
    XAPILIB  : 2.0.1838.0
    XBOXKRNL : 2.0.1838.0
    D3D9     : 2.0.1838.0
    D3DX9    : 2.0.1838.0
    XGRAPHC  : 2.0.1838.0
    XNET     : 2.0.1838.0
    XAUD     : 2.0.1838.0
    LIBC     : 2.0.1838.0
    XRTLLBB  : 2.0.1838.0
  XEX_HEADER_TLS_INFO:
          Slot Count: 64
    Raw Data Address: 00000000
           Data Size: 0
       Raw Data Size: 0
  XEX_HEADER_DEFAULT_STACK_SIZE: 262144
  XEX_HEADER_GAME_RATINGS (TODO):

There's also some formats even earlier than XEX1 like XEX%, not sure if there's much chance of Xenia supporting those though since the import ordinals in those were a lot different IIRC (think one version even had XAM split into separate modules too :/)

---

Tried out a few more XEX1 titles, Condemned (2005-08-10) seems to have some code that makes it crash:

if ( VdGetGraphicsAsicID(v10) >= 0x10 )
    sub_825F9610(a1);

That sub_825F9610 func goes on to call VdIsHSIOTrainingSucceeded/VdReadWriteHSIOCalibrationFlag then crashes sometime after it - changing AsicID to 0xF lets it skip that call and lets it get to intro screens fine, but then crashes later on when trying to show menu :(

(adding a stub for VdReadWriteHSIOCalibrationFlag to return 1 also lets it skip the first crash without needing to change AsicID, but still gets the same menu crash.)

Another title Ninja Reflex (2007-11-17) would hang when using AsicID 0x11 + CommandProcessor::ExecutePacketType3, though changing to AsicID 0x10/0xF made Xenia crash immediately with log mentioning ERR[D3D]: Unexpected vblank/scanline interrupt!, so guess AsicID 0x10 probably makes some things get handled differently.

Juiced 2 (2005-09-01) with AsicID 0x11 + ExecutePacketType3 makes a ton of threads and then host crashes with DbgBreakpoint in log, AsicID 0x10 made it crash with ERR[D3D]: Unexpected vblank/scanline interrupt! instead.

Last XEX1 title I tried was Tiger Woods PGA Tour 06 (2005-08-25) which includes two XEX1s (release/debug), both with xbdm.xex imports, release just guest crashes immediately without much log output other than the crash dump, while debug host crashes with an attempt to read \data\bin\render.ini (non-existent) followed by DbgBreakpoint, no difference changing AsicID or creating the INI it looked for.

These could just be bad builds though (don't think these were ever tested that much, beta kits are pretty scarce...), or could be some debug weirdness that Xenia doesn't implement atm, not sure.

[emoose]

Ah darn, looks like export ordinals are different on 1838 too, took me a little while to notice that call to XamEnumerate was going to our XamContentGetCreator function ;_;

Fortunately with xam_table.inc updated with the 1838 ordinals it fixes the crash that Condemned (2005-08-10) had, and actually lets us get in-game 😱

Here's xam_table.inc with the 1838 changes: https://gist.github.com/emoose/c12ae9ced0ffa94a8d287e082ff9866c 1838 goes up to 0x000007D4, then I stuffed all the extra exports we have defined that 1838 was lacking as 0x000007D5 so they wouldn't need to all be commented/removed.

Not sure if kernel might also need changes too, will try looking at it soon (E: seems not, nice), guess Xenia would need some work to support different versioned exports at once though...