Densha de Go! Plug & Play: Complete Architecture of the Original Game

What this report is

In 2018, Taito shipped Densha de Go! Plug & Play, a palm-sized HDMI “TV game” containing a complete remake of the classic 1996 train-driving arcade game. Unlike the arcade boards and consoles of the series' history, this unit is a small embedded Linux computer: an Allwinner R16 quad-core Cortex-A7 SoC with a Mali-450 GPU, booting Linux 3.4 and running a single 8 MB ARM executable named dgf.

This report dissects that executable. Every claim below was produced by one of three methods, and each section says which:

• Static decompilation. The binary was analyzed in Ghidra and Binary Ninja; their pseudo-C outputs (shown throughout) were cross-checked against each other. The binary ships with 57,000 symbols from its original build, which anchors nearly every function to its real name.
• Live execution. The unmodified game was run on desktop Linux through a thin hardware-emulation shim (EGL/X11, evdev, CedarX video), and driven with a keyboard mapped at the original controller's evdev boundary. All game screenshots in this report come from those live runs.
• Data autopsy. The 1.6 GB Data/ asset tree was parsed: archives, textures, schedules, and save files were decoded byte-by-byte and the decoders verified against the loaders found in the binary.

Who this is for

Three audiences, three levels of depth, all in the same sections:

The report map

The game decomposes into clean layers, and so does this report. Read in order, or jump:

One frame of the game, end to end

Before the chapter-by-chapter breakdown, here is the shape of the whole machine. At 60 Hz, the game:

1. Copies the game condition bit-field that gates every subsystem this frame;
2. Runs the current map mode (departure choreography, driving, arrival, results), each a small state machine;
3. Translates controller state into notch/brake positions through a safety-gated input chain;
4. Integrates one physics step: traction minus four resistance models, brake precedence, jerk penalty;
5. Runs the ATS/ATC signal logic against the track layout ahead;
6. Judges the player against profile tables for speeding, late arrival, stop position and driving manner;
7. Records the frame as a draw-packet stream, which the render thread interprets into GLES 2.0 calls.

Each of those seven bullets is a chapter of this report. The diagram below shows how the executables' layers stack: