How Dragon Ball Z: Gekitou Tenkaichi Budoukai (Datach Joint ROM System, 1992, Bandai) generates characters from barcodes
日本語 ｜ English ｜ Français ｜ Español ｜ Italiano ｜ 한국어
The Datach was a barcode reader that clipped onto a Famicom. You swiped the barcode off a bag of chips, and a Dragon Ball Z character came out and fought. What I remember from being a kid with one is that no matter what I scanned, I got weak characters. Frieza and Cell simply never turned up. That irritation is thirty years old and it is what eventually produced this site: it turns out I was not unlucky, the odds were roughly one in eight thousand.
For anyone arriving from the emulation side: the cartridge is Dragon Ball Z: Gekitou Tenkaichi Budoukai, released in December 1992 as the first title for the Datach Joint ROM System. English-language emulator documentation generally catalogues Datach titles under iNES mapper 157, within Bandai's FCG family (mapper 16). Emulating the cartridge and emulating the barcode reader are separate problems; this site is about neither. It is about what the numbers on the barcode actually mean once they reach the game.
Specifically: how the 13 digits (or 8 digits) of a retail barcode decide the character, HP, BP, DP and special move level. The answer was recovered from two directions at once, by inferring structure from a large body of observed scans, and by examining how the game itself computes the result. Both agree. For retail JAN/EAN codes, the algorithm itself has been recovered.
Retail JAN/EAN codes are not the only thing the Datach reads. A second, Bandai-proprietary card format exists and works by entirely different rules. Pages 1 to 3 and the strongest-barcode page are about retail JAN/EAN codes; the proprietary format is covered on 4. Bandai's barcode.
Checked against the barcodes other people recorded over the years, all five fields match on 502 of 508 thirteen-digit codes and 14 of 18 eight-digit codes. The ten that disagree are each off in exactly one of the five fields, by a small amount. The four eight-digit cases were re-checked individually in the game itself on 15 August 2026, and all four turned out to be slips in the original record. One is a stat written down wrong; in the other three the barcode digits themselves are off by one digit, and correcting them makes all five fields match. The six thirteen-digit cases look like the same kind of transcription slip, though those have not been re-run. No counterexample to the algorithm has turned up so far. If you find a case that disagrees, please say so.
| Page | Contents |
|---|---|
| 1. How the barcode is read | Which digits are used and which are ignored, the 40-bit scatter table, how EAN-8 is handled |
| 2. Choosing the character | The weighted draw, the item slot, promotion to Super Saiyan and final forms, the special code |
| 3. Computing the stats | The formula and lookup tables for HP/BP/DP, and the special move level |
| 4. Bandai's barcode | Bandai’s proprietary card format, the display saturation, and what "Perfect Cell at 99990" really was |
| Strongest barcode | The theoretical maximum with a retail JAN/EAN, the strongest code per character, and the best found in recorded scans |
| Barcode tool | Type in a barcode and get the predicted result. Includes a table of recorded barcodes for every character |
| Notes | The special code built into the game, why Frieza's third form never showed up, which shelf to shop from, what the mismatched records turned out to be, and what is still unknown |
| 2026-08-09 | Site published: analysis 1–3, strongest barcode, barcode tool, notes |
| 2026-08-14 | Analysis 4 published: Bandai’s proprietary card format and how "Perfect Cell at 99990" works. Every page now states that its scope is retail JAN/EAN |
| 2026-08-15 | Two of the open questions closed: the four near misses on EAN-8 are slips in the original record, and the two names on a Lv.4 Goku are explained. Check-digit handling clarified |
Completely fixed. There is no random number anywhere in the process. The same barcode always produces the same character with the same stats, on any cartridge.
Nothing about the algorithm is Japan-specific. Only digits 3 through 12 feed the calculation; the first two digits (the country prefix) and the check digit have no effect. A US UPC-A code is an EAN-13 with a leading zero, so it runs through exactly the same path and produces a perfectly ordinary result. Two caveats. The check digit is ignored by the calculation but still verified by the reader, so the code has to be a valid barcode to get that far. And this is a statement about the algorithm; whether the physical reader copes with a given printed label is a separate question that has not been tested here.
4936338232324, which yields Super Saiyan Goku at HP 99500 / BP 48250 / DP 33250 with a
Lv.4 special move, for a total of 181000. That is the proven maximum under a Lv.4 constraint.
It is a constructed number, not a real product. The full derivation and a per-character table are
on the strongest barcode page.
Frieza's first form holds one ticket out of sixty in the character draw, and the transformed forms are not drawn at all: they require the stats to land inside a narrow band. Third form works out to roughly 1 in 8,000, and Cell's third form to about 1 in 17,000. Details in the notes.
Yes. The barcode tool on this site runs the recovered algorithm in your browser and predicts the result for any EAN-13 or EAN-8 code. Nothing is sent anywhere. It deliberately does not work in reverse: there is no function that generates or prints a barcode for a character you want.
The generation rules have been. One thing in the display layer has not: the names of a few unobserved items. The two questions that used to sit here alongside it — why a Lv.4 Goku showed two different move names, and why four recorded 8-digit scans disagreed by one field — were both answered in August 2026 by re-checking the cases in the game itself, and both turned out to be slips in the original records. The notes page has the detail.
This site stands on work other people published first. Four debts in particular.
The observed data. The barcode-to-result tables used to check the algorithm come from @tareichi001 and from the records collected on Famicom all (atwiki). Without those 500-plus records there would have been no way to test whether the algorithm was right at all. The observation that the special move level depends on the 6th and 8th digits, in particular, was where this analysis started.
Character and item names. The names in the tables on this site are matched against the character table, item table and special move tiers published on nnnes1, a Famicom cheat-code wiki. The program only returns an ID number, so without that table nothing could be named.
The original manual. The list of item card effects comes from the game's original instruction manual, reproduced on Game no Setsumeisho (Kari). The program only reveals what each routine does; it says nothing about which item carries which name. Only by matching that list against the code did name, effect and internal number line up — and it was that list that revealed one of the readings here had been off by a single entry. Whoever keeps these paper materials online has this site's gratitude.
Prior work. Someone had already constructed barcodes that produce Frieza's and Cell's transformed forms, back in 2013 (Niconico sm21301478, by xyaa). As far as can be confirmed, this site is the first public description of the conversion rules themselves, but people were making codes long before that.