Skip to main content

Indie game storeFree gamesFun gamesHorror games
Game developmentAssetsComics
SalesBundles
Jobs
TagsGame Engines
(+3)

Thanks! To be clear, the technical work on this port was done by Claude (Anthropic's AI); I directed it and tested on real hardware. Here's its explanation:

It's the original Data East set (MAME "robocop", World rev 4), not the bootleg, so the protection is the real HuC6280 coprocessor rather than anything bootleg-specific.

It isn't a hand disassembly either. It's closer to a static recompilation. A rewriter traces the 68000 code, both statically and with coverage from emulated playthroughs. It relocates the code and patches every hardware access to shadow RAM, and a vblank layer converts the video to the Neo Geo every frame.

The HuC6280 is handled at a high level instead of emulating the chip:

- At boot the 68000 uploads the HuC's program through the shared RAM (the HuC's own ROM is just a small loader). That uploaded 6280 code was disassembled to see what it does.

- The handshakes are faked: the loader-ready/started bytes and the 18-value sequence the 68000 checks on $4001-$4003.

- The IRQ commands (write to $47FF) are handled in 68000 code: $80 echo, $81 self-test (shared RAM filled with $AA), and 0-$7F, which runs the real job, the object collision pass.

- The collision pass is a port of the 6280 routine to 68000. It reads the HuC's data tables directly from the program image in the 68000 ROM.

- The game copies about 1,200 bytes of object records to and from the 8-bit shared RAM every frame. Those copies are patched out, and the collision routine works on the records in place in work RAM, which saves a lot of CPU.

(+1)

Ahh OK cool, I thought as much.

I do wonder if Claude read my article on the protection :)

https://hoffman.home.blog/2025/12/18/robocop-the-future-of-copy-protection/

Claude read it now. Same findings on the handshake (the fixed 18-value sequence ending in 2) and on the wasted cycles (in the port the ~1200-byte copies to and from shared RAM are patched out). The approach differs: you patch the jump table into direct calls, while the port leaves the 68000 code untouched and answers as the HuC would, including a 68000 rewrite of the 6280 collision routine, reading its data tables from the uploaded program image in ROM. It didn't consult your post while making the port, but it can't rule out having seen it during training.

(+1)

HA!  Nice :D  The funny thing is that collision protection accounts for such a huge amount of CPU cycles.  I suspect the game could run at full 60hz with it gone.

Hey did you solved the puzzle with the moving floor on SF2?