Gang Beasts (CUSA04865)

[ntamas94]

Existing thread

• I searched this category for the title ID and no thread exists for this title on any platform.

Title

Gang Beasts (CUSA04865)

Content version tested

01.00 (base game, no patch)

AnyPS5 commit

main a4440ed with #6684 and #7660 merged on top, plus the guest TLS relocation fix from #6977 (3b158c1, adapted to the current GuestImageReader.cpp). #6618 is not included: it conflicts with current main.

System tested

Windows 11 Pro 10.0.26200, WinLibs GCC 15.2.0 r7. Relinker-only build; the converted executable was not run.

Furthest point

Does not convert

What is shown

Conversion only. Unity title on the Mono scripting backend: Media/Modules/ holds mono-ps4.prx and MonoAssembliesPS4.prx, and Media/Plugins/ holds 5 Unity plugins.

• eboot.bin (2120 NID references), all 11 modules in sce_module/ (including libc.prx and libSceFios2.prx) and the 5 plugins in Media/Plugins/ convert.
• libSceFios2.prx needs the TLS relocation fix from feat: run PS4 games on the AGC driver — Limbo (CUSA01664) in game (integration branch) #6977. Without it, conversion stops with Invalid guest TLS relocation.
• mono-ps4.prx converts.
• MonoAssembliesPS4.prx stops conversion (see Current blocker).

Current blocker

FAIL: Forbidden syscall instruction at code offset 0x129f1c (offset 0x129f1c)
Input: ...\eboot.bin

The offset is in Media/Modules/MonoAssembliesPS4.prx, the Mono AOT image. Its executable segment runs from 0x0 to 0x2ddf930, but .eh_frame_hdr lists only 3 FDEs, all at the end of that segment: 0x2ddf300..0x2ddf7a5, 0x2ddf7b0..0x2ddf7db and 0x2ddf7e0..0x2ddf7ed. The AOT-compiled methods have no DWARF unwind entries. Unwind ranges therefore cannot bound the code, and the data inside the executable segment is scanned as instructions. The bytes around 0x129f1c (09052a00f8040000000028010f05c400) look like table data. The executable segment contains 436 0F 05 byte pairs in total.

Needed: a way to bound the code of a Mono AOT module, or to tell its data from its code. Open pull requests still needed: #6684, #7660 and the TLS fix in #6977. #6977 is also needed to run the title.

How it was run

From the dump folder (Itemzflow dump; eboot.bin and all modules were already decrypted ELF files):

relinker --windows --windows-gui --registry --module-dir Media/Modules --module-dir Media/Plugins eboot.bin <out>/gangbeasts.exe

Without --module-dir Media/Modules, conversion completes: the executable and 16 modules are written.

AI-assisted: yes (Claude Code)

[ntamas94]

Where MonoAssembliesPS4.prx stops, and a rule that gets it through conversion

MonoAssembliesPS4.prx holds 78 Mono AOT images, all in the old format (mono_aot_version "67"). Each image comes with a static globals table in the data segment. The table is a NUL-terminated array of 16-byte entries: a RELATIVE-relocated pointer to a name string, followed by a RELATIVE-relocated pointer to the named object.

The names include methods, methods_end, code_offsets, method_info_offsets, extra_method_table, extra_method_info_offsets, class_name_table, got_info_offsets, ex_info_offsets, unwind_info, class_info_offsets, plt, plt_end, mono_image_table, mono_aot_file_info, blob, mono_assembly_guid, mono_aot_version, mono_runtime_version and mono_aot_assembly_name, plus the unbox trampolines ut_*. mscorlib also lists the full-AOT trampolines: X and X_p pairs (generic_trampoline_N, rgctx_fetch_trampoline_N, throw_exception, ...) and specific_trampolines, static_rgctx_trampolines and imt_thunks.

Each image places all of its data, not only its code, in the executable segment. For Assembly-CSharp-firstpass:

Range	Content
0xf0..0x10e8a8	methods..methods_end: code
0x10e8a8..0x12ea70	code_offsets .. class_info_offsets: tables
0x12ea70..0x135d66	plt..plt_end: 10-byte entries, jmp *rel32(%rip) followed by a 4-byte info offset
0x135d68..	mono_image_table, the GUID, version and name strings, then the table's name strings

Only the module's C functions (0x2ddf300..0x2ddf7ed, at the end of the segment) have FDEs, so the whole segment is scanned as code. Three stops follow from that:

1. Forbidden syscall instruction at code offset 0x129f1c: inside class_name_table.
2. With the tables masked, 0xcaba66: the 4-byte info word of a PLT entry (0f 07) decoded as sysret.
3. With the PLT info words also masked, Code analysis: overlapping instruction boundaries (offset 0x2ddf1c2): the name strings of the last image.

Rule tested (on a scan-only copy whose data bytes were replaced with 0x90; the output of that run cannot be executed):

• An image's block runs from methods to the end of the last string its globals table points to.
• Inside a block, code is methods..methods_end, the 6-byte jmp of each PLT entry, X..X_p for every name that has an _p partner, and specific_trampolines, static_rgctx_trampolines and imt_thunks up to the next listed address. Everything else is data.

The 78 blocks cover 0xf0..0x2ddf2f8 with no gap larger than 16 bytes and no overlap. All 79,477 PLT entries in them have the 10-byte form. 0x0..0xf0 is the module's C init function, which has no FDE either, so the rule only marks positively identified data. With every data range masked, conversion of the whole title completes: the executable and all 18 modules, including MonoAssembliesPS4.prx.

What a relinker change would need: recognise the globals tables (a table that names mono_aot_file_info but lacks methods, methods_end, plt or plt_end, or has a PLT entry not of the 10-byte form, should throw), then pass the data ranges to the syscall scan and the code analysis in the same way as the relative jump tables. That way the data is masked only in the scan copies, never in the output.

A smaller point: the syscall stop names the executable (Input: ...\eboot.bin) even though the offset belongs to MonoAssembliesPS4.prx. The code-analysis stop names the module correctly.

AI-assisted: yes (Claude Code)

[thuanquang]

@ntamas94 on your smaller point, the syscall stop naming eboot.bin instead of the module: #8262 makes it name the module the instruction is in.

[ntamas94]

First run: the title starts, opens its window and stops in GPU set-up

Setup, all local:

• Libraries: feat: run PS4 games on the AGC driver — Limbo (CUSA01664) in game (integration branch) #6977 at 93eeee0.
• Relinker: main a4440ed with fix(relinker): run a guest DT_INIT of 0 as the module initializer #6684, fix(relinker): resume scans after undecodable bytes between PS4 unwind functions #7660, the TLS relocation fix from feat: run PS4 games on the AGC driver — Limbo (CUSA01664) in game (integration branch) #6977 and the Mono AOT change from the earlier comment. feat: run PS4 games on the AGC driver — Limbo (CUSA01664) in game (integration branch) #6977's own relinker stops on eboot.bin with Unsupported 0F 79 opcode without SSE4A prefix (offset 0x2616cf). fix(relinker): resume scans after undecodable bytes between PS4 unwind functions #7660 fixes that, but it does not apply cleanly on feat: run PS4 games on the AGC driver — Limbo (CUSA01664) in game (integration branch) #6977.
• System: Windows 11 Pro 26200, i9-9900K, RTX 2080.

Loader

1. libSceNpProfileDialog.prx has no file. The NpToolkit2 modules import 5 functions from it: sceNpProfileDialogInitialize, Terminate, OpenA, UpdateStatus and GetResult.
2. With that library present, 233 imports stay unresolved:

Library	Imports
libSceGnmDriver	75
libSceHmd	21
libSceNpTus	20
libSceVrTracker	13
libSceNpScoreRanking	12
libSceNpMatching2	11
libSceNpManager	10
libSceSaveData	8
libSceCamera	8
libSceMove	7
libSceNpWebApi	7
libSceSocialScreen	5
libkernel, libSceNpSignaling	4 each
libSceNetCtl, libSceRemoteplay, libSceVideoOut, libSceNpTrophy	3 each
libSceNpAuth, libSceSaveDataDialog, libSceSystemService, libSceInvitationDialog, libSceUserService, libSceGameCustomDataDialog	2 each
libSceHttp, libSceNpUtility, libSceAjm, libSceDiscMap	1 each

The Hmd, VrTracker, Camera, Move and SocialScreen imports come from the title's own sce_module/ tracker modules (libSceFaceTracker, libSceHeadTracker, libSceHandTracker).

Run, with throwing stubs for those 233 imports (local only, not for a PR)

main reaches the ELF entry, the Mono runtime starts ([MONO_DLL] start, opens /app0//.mono/config), Vulkan comes up and the window opens at 1920x1080. The stops, in order:

#	Stop	Local answer for the next run
1	sceKernelIsNeoMode	0, measured (below)
2	libSceDiscMap fJgP+wqifno	0x81100004 (no bitmap info), like the other DiscMap queries; not measured
3	pthread_cleanup_push / pthread_cleanup_pop	the existing __pthread_cleanup_push_imp / pop_imp with a heap handler, as FreeBSD libthr does
4	sceMoveInit	measured (below)
5	sceVideoOutGetDeviceCapabilityInfo_	measured (below)
6	sceVideoOutModeSetAny_	0; not measured
7	sceVideoOutConfigureOutputMode_	0; not measured
8	sceGnmGetTheTessellationFactorRingBufferBaseAddress (#6977 stub)	stopped here

Measured on a PS4 (firmware 10.71, base model) with a probe module loaded into a running homebrew app. The system libraries were loaded from /<sandbox word>/common/lib/.

• sceKernelIsNeoMode returns 0.
• sceMoveInit returns 0; a second call returns 0x80EE0002. sceMoveTerm returns 0.
• sceMoveOpen(user, 0, index) returns a handle with no Move controller connected (0x03140800 for index 0, 0x03150801 for index 1). With user -1 it returns 0x80EE0006, and with type 1 it returns 0x80EE0007.
• sceVideoOutGetDeviceCapabilityInfo_ takes three arguments, (handle, info, size). With size 8 it returns 0 and writes the 64-bit value 1. With size 0, 4, 16, 24, 32, 40, 48 or 64 it returns 0x80290001 and leaves the buffer unchanged. With an invalid handle it returns 0x8029000B.

Furthest point is now Stops before the first frame, with local stubs. Next is the PS4 GPU set-up in #6977.

AI-assisted: yes (Claude Code)

[ntamas94]

Progress: Gang Beasts (CUSA04865) reaches its main menu on top of #6977

Setup: eboot converted with the main relinker plus the Mono AOT data-range fix (local branch, PR pending), run with the #6977 libraries plus local changes. Everything below is on a local branch; what looks generic is listed as a PR candidate.

Stops passed since the last update, in order

1. RELEASE_MEM DATA_SEL 4 (fix(agc): name the RELEASE_MEM system counter instead of GDS data #7911): the Gnm SDK names it the GPU core clock counter and the PS4 emulators (shadPS4, fpPS4) run it at 800 MHz (911 MHz in Neo mode); this title divides its frame stamps by sceKernelIsNeoMode() ? 911000000 : 800000000, inlined from the SDK. Locally the AGC writes the host steady clock as an 800 MHz count, eight times the DATA_SEL 3 rate on the same epoch. The PS5 meaning of DATA_SEL 4 is still unmeasured (not the 100 MHz counter of DATA_SEL 3, by the AMD naming).
2. Gnm builders missing on the feat: run PS4 games on the AGC driver — Limbo (CUSA01664) in game (integration branch) #6977 branch, written after shadPS4: sceGnmSetVgtControl/ResetVgtControl (context 0x2aa), DrawIndex, DrawIndexAuto, DrawIndexOffset, DrawIndirect, DrawIndexIndirect, DispatchDirect, DispatchIndirect, ComputeWaitOnAddress, SetPsShader350, UpdateVsShader/UpdatePsShader350/UpdateGsShader (the 0xc01e NOP register updates, lowered to SET_CONTEXT_REG), SetCsShaderWithModifier.
3. A PS4 display buffer without a resident image was read with the PS5 render-target layout ("null or misaligned address"); it now goes through the GCN display layout on the CPU path.
4. GCN texture descriptors: this title keeps a flag in word1[7:0] (0x40), which the PS4 GPU ignores because its address space is 40 bits; GcnImageWords now drops that byte (PR candidate for feat: run PS4 games on the AGC driver — Limbo (CUSA01664) in game (integration branch) #6977).
5. GCN v_cmpx (VOPC and VOP3): translated as RDNA v_cmpx followed by s_mov_b64 vcc|sdst, exec (PR candidate for feat: run PS4 games on the AGC driver — Limbo (CUSA01664) in game (integration branch) #6977).
6. GCN image instructions on 3D/cube descriptors: GCN has no DIM field, the T# type decides the address count, so the driver now recompiles a shader with the dimension of the descriptor it binds (separate local branch, PR candidate for feat: run PS4 games on the AGC driver — Limbo (CUSA01664) in game (integration branch) #6977).
7. PS4 tile mode 19 (Thick_1dThick): 8x8x4 micro tiles with addrlib's ADDR_THICK element order per element size, level-major slabs of four slices, detiled on the existing thick path (checked against addrlib, Mesa, GPCS4, shadPS4 and fpPS4; PR candidate).
8. Primitive type 19 (QUADLIST): a four-control-point variant of the rect-list tessellation shaders (control points reordered 0,1,3,2, culling off as for rect lists; PR candidate).
9. Smaller: wireframe PA_SU_SC_MODE_CNTL (0x12c, the loading bar frame) rendered filled; a draw without a pixel program ignores its color masks; 256-byte base alignment for GCN color targets; PS4 libSceMove as measured on a PS4 (FW 10.71, no controller); PS4 SaveData/NP calls on the existing cores; blocking socket receives wait in short alertable rounds so sceKernelRaiseException thread delivery does not hang.

State

• The Double Fine splash, the loading screen with its bar and the main menu ("Press a Button") render at 59.94 FPS.
• Open: lightmapped surfaces render white. The 512x512 lightmaps are 5_9_9_9 FLOAT (RGB9E5) textures written by the CPU (Enlighten runs on a worker thread), and their memory content is not valid RGB9E5 (exponents 28-31, many saturated texels); read as RGBA8 the brightness is about right but the colour is mottled. Under investigation.
• Open: after the menu a vertex fetch shader binds a fifth vertex-buffer V# that holds T#-like words ("buffer descriptor uses an unsupported type").

Measurements on the PS4 (FW 10.71) used above: sceKernelIsNeoMode = 0, sceGnm* tessellation and workload queries, DrawInitDefaultHardwareState350, sceVideoOutGetDeviceCapabilityInfo_ (size 8 only), Move calls without a controller. A homebrew GPU submission to measure the counters directly crashes the app (CE-36329-3), so the 800 MHz rate rests on the SDK text and the title's own divisor, not on a console measurement.

[ntamas94]

Progress: Gang Beasts plays a full round on top of #6977

Everything below runs on a local branch on top of #6977. The last update ended at the main menu.

1. The GPU trailing the title

After the menu, about half the runs stopped on unsupported PM4 packet type in the draw command buffer, always at the same dword. The title alternates two 57 KB draw command buffers. In each one it embeds a record with allocateFromCommandBuffer (8 bytes), binds a 16-byte V# over it at COMPUTE_USER_DATA_8, and a compute dispatch stores 1 at record offset 8, which is the header of the next packet. A watch on that dword, with timestamps on submits and dispatches, showed the order: the CPU rebuilds a buffer about 1 ms after submitting its previous use, and the dispatch's store lands 5 to 7 ms after that submit, on top of the rebuilt header.

Past the menu the same lag showed up as draws with foreign descriptors: an S# slot holding T# words, a V# slot holding an S#, a sampler that reads as unnormalized with clamp mode 7.

With each Gnm submission waiting for the work already queued, none of this happens, in runs of up to ten minutes through the menus, character select, loading and a full match, at the same menu frame rate. The title paces itself on flip events and on labels it embeds in its command buffers, and that pacing assumes the GPU stays close behind the command processor, as it does on the console.

Get-fix#3 offers three commits for #6977's branch: the submission wait as an opt-in knob (APS5_GNM_SUBMIT_WAIT_IDLE=1, off by default because a submission that waits on a label written after a later submit would never finish), stepping over type-0 and type-2 packets as the command processor does, and rendering into one array slice of a GCN color target.

2. A label can become visible before a copied buffer's write-back (AGC, not PS4-specific)

While reading the driver for (1): a written buffer that the device holds as a CPU copy gets its results back to guest memory when its batch is reaped, but a label recorded after the dispatch is stored on the GPU first. A title that polls the label and rewrites the region loses its bytes to the late write-back. #8180 drains such a label so the write-back runs first; a new execution test fails without it. This was not the cause of (1), since no CPU store path wrote the clobbered dword in the traced runs, but it is a real ordering hole.

3. The level load that never finished

With (1) handled, the match still did not start: every thread idle, the loading icon spinning. The title calls sceNetSetsockopt on a UDP socket it created with socket(), and this branch's network library returned EBADF because it only knew its own sockets. main handles that since #6142, so a rebase of #6977 brings it; locally the network library adopts the kernel socket on first use.

4. Into the match

Two more gaps on the way, both covered elsewhere: GCN MTBUF (tbuffer_load_format_*) is in Get-fix#1, as DealPotato also described for Second Son in the #6977 thread, and the color slice view is in Get-fix#3.

State

• A full round plays: menu, character select, a level (Wheel) with correct lighting and physics, the end of the match and the return to character select. With the submission wait it runs at about 20 FPS in the level, 40 in character select and up to 60 in the menus. Most of a level frame goes to recording draws on the driver's queue worker (about 375 draws per frame at about 80 µs each), not to the GPU (about 26 ms busy per 50 ms frame). Scripted presses go through APS5_PAD_INPUT_FILE.
• Open: Mono logs an assertion from its thread-pool wake-up pipe (threadpool.c:908, pipe[0] != INVALID_SOCKET) that the socket traces do not explain yet; the title plays regardless. Audio plays (FMOD through the SDL audio output).

[ntamas94]

Update 2026-10-22: the title on the upstream PR stack over main

Build: main 7e2ba73 + #9430, #9431, #9432 (Get-fix's rebased heads) + #9671, #9672, #9673, #9674, #9675, #9676, relinked with --windows --registry --module-dir Media/Modules --module-dir Media/Plugins. Run with APS5_GNM_SUBMIT_WAIT_IDLE=1 on an RTX 2080 (driver 617.14), Windows 11 10.0.26200.

Furthest point: title screen, Local, costume select, match setup, a stage in play; three runs of 330 s each on the same build, each stopped by the run's timeout, no crash, 13,771 / 12,533 presents with #6948 (two different stages, 29-56 FPS) and 10,687 without it (level8, lighting white). Lighting correct with #6948. Zero not implemented, AGC graphics: or unsupported PM4 packet type throws in the three runs.

That needed, beyond the six pull requests, in the order the title stopped on the bare stack:

1. AGC graphics: storage texture has no committed guest pages at the first level load: the PS4 T# base address was read as 40 bits (word 1 bits 6-7 are MTYPE_L2). Fixed by fix(libSceAgcDriver): read a PS4 texture base address as 38 bits from fix(agc): PS4 display, textures and GCN instructions for CUSA03312 Get-fix/AnyPS5#1 (a2bd6f6); not in feat(libSceAgcDriver): draw PS4 (GCN) command buffers #9431 nor main.
2. AGC graphics: a point or line polygon mode on a rect list is unsupported (register 0x205 = 0x0000012c): the title draws rect lists with POLY_MODE dual / lines, and e61d31d (2026-10-19) throws for that. Run with a local stand-in that draws them filled; the PS4's behaviour for a rect list in line mode is not measured.
3. GCN image instruction on a descriptor of type 10 needs a different address count than its inferred dimension: fixed by feat(shader): take a GCN image's dimension from its T# from fix(agc): PS4 display, textures and GCN instructions for CUSA03312 Get-fix/AnyPS5#1 (f9b38d1).
4. GCN MTBUF opcode 3 ... is not implemented at the first menu transition: fixed by feat(shader): translate GCN MTBUF typed buffer instructions and the V_RSQ_CLAMP_F32, SOPK and SMRD literal commits from fix(agc): PS4 display, textures and GCN instructions for CUSA03312 Get-fix/AnyPS5#1 (6350d27 and siblings).
5. Lighting washed out white (the Enlighten lightmap compute readback): fix(agc): store linear compute writes behind their dispatch #6948 (open, mergeable). With it the stage lights correctly.

The exact build is the gb-stack-run branch (ntamas94/AnyPS5@859048f14d): the stack, the Get-fix#1 and #6948 commits above, and the local stand-ins marked "not for upstream".

Also still local: sceNetCtlRegisterCallbackForNpToolkit registering like the other NetCtl callbacks, the RELEASE_MEM DATA_SEL 4 clock count, and the earlier bring-up stand-ins listed above.

Open pull requests the title needs: #9430, #9431, #9432, #9671, #9672, #9673, #9674, #9675, #9676, #6948, and Get-fix#1 (at least its 38-bit base address, GCN image dimension and MTBUF commits) once it is opened upstream.

AI-assisted: yes (Claude Code)

🤖 Generated with Claude Code

[ntamas94]

Follow-up to the update above: the Get-fix#1 commits it names are now open upstream as @savvaniss's pull requests, so the list of what the title still needs reads:

• fix(agc): decode PS4 texture bases, linear-aligned targets and thin-tiled 3D textures #9891 (on feat(libSceAgcDriver): draw PS4 (GCN) command buffers #9431): the 38-bit T# base address (blocker 1), plus a non-resident GCN display buffer presented through the GCN decode, which relies on fix(libSceAgcDriver): decode PS4 tiled scanouts in their own layout on the CPU path #9673 for the decode itself.
• feat(shader): decode more GCN instructions and take a GCN image's dimension from its T# #9889 (on feat(shader): decode PS4 (GCN) shaders by re-encoding them to RDNA #9430): the GCN image dimension taken from the T# (blocker 3), MTBUF, V_RSQ_CLAMP_F32, SOPK and SMRD literal offsets (blocker 4).
• fix(agc): store linear compute writes behind their dispatch #6948 for the lighting (blocker 5), and the local stand-in for the rect-list polygon-mode throw of e61d31d (blocker 2).

Open pull requests the title needs: #9430, #9431, #9432, #9671-#9676, #9889, #9891 and #6948.

AI-assisted: yes (Claude Code)

🤖 Generated with Claude Code