Digimon Digital Card Battle Hits 100% Decompilation: Inside the PS1 Cult Classic's Flawless C Reverse-Engineering

Developer juandav achieves a 100.00% byte-identical C decompilation of Digimon Digital Card Battle (PS1). Explore the 1,370 matched functions, the 7-segment P.DRV overlay architecture, and what this means for native PC ports.

Digimon Digital Card Battle Hits 100% Decompilation: Inside the PS1 Cult Classic's Flawless C Reverse-Engineering

In the golden twilight of the original PlayStation, Bandai quietly dropped one of the most mechanically addictive digital collectible card games ever minted: Digimon Digital Card Battle. Today, developer juandav has accomplished what once seemed impossible for a complex multi-overlay PS1 title: achieving 100.00% byte-identical C decompilation across every single function, segment, and rodata block.

Every line of MIPS R3000A assembly across the main executable and all seven overlay segments in P.DRV has been painstakingly reconstructed into human-readable, re-compilable C. Zero assembly stubs remain. No INCLUDE_ASM macros. No orphaned bytes. Just pure, clean source code.


The Anatomy of a 100% Match

Unlike standard linear PS1 binaries that execute from a single monolithic .EXE, Digimon Digital Card Battle (specifically the North American release, SLUS_013.28) employs an overlay architecture to maximize the PlayStation's modest 2MB of main RAM (RAM memory ceiling: 0x801FFFFF). The game splits its logic between a resident boot executable and seven modular dynamic overlays stored inside the disk archive P.DRV.

📊
Decompilation Scorecard:
• Total Functions: 1,370 / 1,370 (100.00% Matched)
• Total Code Size: 695.89 kB matched
• Total Data & Rodata: 1.58 MB matched
• ASM Stubs Remaining: 0
• Toolchain: GCC 2.95.2 (-O1 -G0) + ASPSX 2.86 via maspsx & PsyQ 4.7

Here is how the 1,370 functions break down across the system's memory segments:

Module / Segment Functions Primary Responsibility Status
SLUS_013.28 (Main Executable) 506 Kernel init, VBLANK handler, CD-ROM streaming, core card battle engine & memory manager 100.00% ✅
OPENSEG 49 Opening FMV playback, attract mode, title screen, and save card slot checks 100.00% ✅
SAISEG 49 Audio subsystem init, SPU voice streaming, sound effects, system config 100.00% ✅
SUBSEG 161 Card album / binder viewing, deck construction, card fusion shop (Fusion Shop / Digimon Center) 100.00% ✅
EVOSEG 276 Armor Digivolution sequences, 3D battle arena rendering, special attack FX, particle systems 100.00% ✅
KAWSEG 157 Overworld map traversal, battle arenas (Flame City, Igloo City, Junk City), NPC dialogue trees 100.00% ✅
SUGSEG 81 Minigame logic, board-game style map events, slot mini-games, card lottery rewards 100.00% ✅
ENDSEG 91 Staff credits roll, post-game epilogue routines, bonus battle unlock handlers 100.00% ✅

The Technical Hurdle: Taming PsyQ 4.7 & maspsx

Matching early 2000s Japanese PS1 games requires an archaeological approach to compiler toolchains. Bandai's developers originally built Digimon Digital Card Battle using Sony's official PsyQ 4.7 SDK, compiled under Cygnus GNU C (GCC 2.95.2) with flags -O1 -G0.

One of the project's biggest triumphs was recreating the exact assembly scheduling of the MIPS R3000A CPU. On the PS1, the compiler's pipeline optimizations frequently swapped instructions into the branch delay slot or rearranged register allocations based on subtle variable scoping in C. By leveraging maspsx—a modern Python-based preprocessing layer that cleans modern GCC assembly output before feeding it into the vintage aspsx.exe assembler—juandav managed to produce byte-identical machine code down to every single branch delay slot and load delay pipeline stall.

// Example: Reconstructed segment loader and overlay relocation
void LoadGameOverlay(OverlayId segId) {
    SectorAddress addr = g_OverlayTable[segId].cd_lba;
    u32 byteSize = g_OverlayTable[segId].size;
    void* destRam = (void*)0x801DDF38; // Shared dynamic overlay memory bank

    CdReadSync(0, 0);
    CdIntToPos(addr, &g_CdPos);
    CdSearchFile(&g_CdFile, g_OverlayNames[segId]);
    CdReadFile(g_OverlayNames[segId], (u_long*)destRam, byteSize);
    CdReadSync(0, 0);

    // Flush PS1 Instruction & Data Caches before overlay entry
    EnterCriticalSection();
    FlushCache();
    ExitCriticalSection();
}

Why a 100% Decompilation Changes the Game

Achieving a 100% match is not merely an archival triumph—it is the foundation for an entirely new era of community-driven enhancements:

1. True Native PC Recompilation

Just as projects like Zelda 64: Ship of Harkinian, Jak & Daxter: OpenGOAL, and the recent Wind Waker Recomp proved, a clean C codebase means the game can be decoupled from PS1 hardware constraints. With a hardware abstraction layer (HAL) swapping PsyQ's libgpu, libgte, and libspu calls for modern SDL2, DirectX 12, or Vulkan renderers, Digimon Digital Card Battle can run natively on Windows, Linux, macOS, and Steam Deck at widescreen 4K and 120 FPS.

2. The End of PS1 Card Battler Quirks & Bugs

In the original PS1 release, several card interaction timings, status condition calculations (like Poison and Jamming), and AI decision algorithms had obscure glitches or unfair RNG skew. Having full source code allows community modders to audit the card battle math, fix 25-year-old game-freezing bugs, and rebuild the CPU opponent AI to actually execute optimal combos.

3. Modern Romhacking & Custom Card Expansions

Previously, ROM hackers had to reverse-engineer compressed binary tables in hex editors to add new cards. With juandav's clean source tree, adding new Digimon cards, balance patches, custom evolution lines (Mega-level cards, Jogress fusions, Digimon Tamers / Frontier expansions), and online peer-to-peer multiplayer card duels becomes completely feasible.


Multi-Region Support & What's Next

While the North American release (SLUS_013.28) is already standing at a flawless 100.00%, the repository is designed for multi-region preservation. Target configurations are already in place for both the Japanese original (Digimon World: Digital Card Arena, SLPS_025.06) and the European localized version (SLES_039.00), allowing reverse engineers to inspect localization diffs and region-exclusive tuning directly in C.

You can track the project, inspect the full codebase, and build the matching binary yourself on GitHub and decomp.dev: