Not one capture here. Every picture is drawn from the bytes of the ROM, by running in Python the same decompressor, figure engine and label interpreter the Z80 runs, and then checked byte for byte against openMSX's VRAM: all five screens come out with zero differences in colour, patterns and sprite patterns. The listing and the numbers are reproducible with make, and reassembling gives back the ROM byte for byte.
Found by theNestruo, in issue #1: this page used to publish the hundred rooms one by one, with no plan, and he was the one who said they are grouped per level in different shapes. What follows is only the job of finding in the bytes what he already knew.
empieza_el_nivel (0x4F82) takes one byte per level from 0x9D67 and leaves it in (0xE06A). That byte picks one of nineteen rows at 0x52DB, four bytes, one per room.
In each byte the low nibble is the room you pass into leaving through the left (0xF: none), and the (0xF: none) and the high one is THE POSITION of that room in the plan: the top two bits are THE ROW and the next two THE COLUMN.
This went out the other way round on 2026-09-09, and theNestruo caught it. What settles it is not an argument but the scenery itself: laid out right, the tiles match across each seam on 77.8 % of the vertical ones and 56.6 % of the horizontal; with the axes swapped, 0.4 % and 0.0 %, which is BELOW the 10.8 % and 7.2 % of comparing rooms from different levels. And it fits the two transition tables: the room 0x52DB gives is always directly ABOVE and 0x5327's always directly BELOW, over their 38 entries each.
Out come the arrangements: five levels in a column, two in a row, six as 2x2 and fourteen odd-shaped. And it fits everything else: 0x5327 gives the room to the right, and the ones above and below are the current one minus and plus one -the dec b at 0x529A and the two inc b at 0x52A2-.
The proof that the arrangement is right is in the picture: put together like this, platforms and ladders carry on from one room into the next, and the water at the bottom runs through. All twenty-five maps in The map are redrawn with it.
Also theNestruo, in the same issue: he asked for a minimap per round with the doors joined up, and going after which door goes with which is what turned this up.
Each skull door is three bytes, and out of the third 0x8DA8 takes two things: the low six bits are the level it leads to and the top two the ENTRANCE, which is the number of the door you come out of over there.
That turns the doors into checkable pairs: if door j of level A says (B, k), then door k of level B has to say (A, j). All 64 in the cartridge do, without one exception, and on top of that none leaves its round: the 25 levels are five closed groups of five.
You can type on the title screen. Letters pile up at 0xE4C0 and 0x5444 matches them against five sixteen-byte names, laid out nineteen bytes apart from 0x546E: MR SLOTH takes you to round 2, GOON DOCKS to 3, DOUBLOON to 4, ONE EYED WILLY to 5 and GOONIES to 1.
And those very same bytes are also the script that paints the round's name when it starts. There are not two tables: there is one. On finishing a round, 0x53A7 shows you, under the KEYWORD caption, the name you have just left behind - which is exactly what you type to come back.
The fifth is the only one without a closing 0xFF, and that fits: ONE EYED WILLY is the round you reach, never one that gets announced.
The twenty-five levels are four rooms each, and every room is 32x20 tiles: 64,000 tiles altogether. All of it fits in 2,983 bytes - about twenty-one tiles per byte.
Three layers do it. A level is eighty bytes, four columns by twenty rows, and each byte points at an 8x4 tile block in the table at 0x5B65, which holds a hundred and eight. Bit 7 of the byte asks for the block mirrored, and that is used 615 times out of 2,000. And the hundred and eight blocks share tails: counting every byte once they take 717 rather than 841, because some start inside others.
All hundred and eight are used. Not one is spare.
The longest table in the cartridge is the one at 0x6DBD: twenty-seven entries, one per condition that uncovers one of the hidden items. Hit the same spot twice in a row; kick once to each side; stand still for 0x60 frames; keep both bars above 0x28; kick the rolling boulder, or the flame...
Nearly all of them lean on (0xE126) and (0xE127), which hold the player's last two hits, kept up to date by 0x8005.
And none is spare: walking the lists of all twenty-five levels turns up twenty-seven hidden items with twenty-seven distinct indices, 0 to 26. Twenty-three levels carry one and two carry two, levels 5 and 16.
All twenty-seven, mind you, look exactly alike: a single tile, 0x91, blinking.
The list at 0x7D9B is eight bytes, one per hazard - water jet, stalactite, drip, flame, rising column, pipe leak and boulder - and it says which inventory item stops each one. Carrying it, the hit does not take energy: it spends one charge of (0xE150+item), and when they run out the item vanishes from the inventory.
The energy bar is sixteen bits - (0xE063) the fraction, (0xE064) what you see - and it is drawn to one eighth of a tile.
There are twenty-three items, and the table at 0x5576 says which level each is in: twenty-three distinct values between 0 and 24, and 5 and 14 are exactly the ones missing. Levels 6 and 15 are the only two with no item.
When the chaser wants to change height, 0x756D walks its row tile by tile in both directions, counting how many there are until it hits 0x41 - the foot of a rope - or 0x53 - the head - and it heads for the shorter count.
There is a nice detail: bit 0 of (ix+00Fh) decides which side is tried first, and it is consumed by rotating it on each query. That is why two identical chasers on the same row do not both make for the same rope.
The green ropes are the same for everyone: the player climbs 0x41 pressing up and goes down 0x53 pressing down (0x66E4), and the creatures use those two.
0x5206 jumps into 0x4730, the byte after the call that really reads the joystick, with the accumulator already loaded from a table. So the input routine runs from halfway through, and what it hands back nobody pressed.
It is 34 joystick states at 0x520E - plus the closing 0xFF - and their 34 durations at 0x5231. The demo always does exactly the same thing, and that is what makes it possible to check VRAM from a cold boot, with no savestates and no breakpoints.
The water jet runs down the room standing on tiles. So it can retract without leaving holes, whenever it meets an occupied tile it writes down at 0xE1D0 the row and the three tiles that were there, and puts them back on the way out. The map is never touched: the map is read-only and only the screen changes.
The current, on the other hand, moves nothing at all: 0x854E rewrites three patterns - tiles 0x6D, 0xCF and 0xF1 - across all three banks, swapping two sixteen-byte batches with bit 2 of the frame counter. The water appears to flow and not one tile on screen has changed.
Of the 42 16x16 sprite patterns the cartridge carries, 22 are not drawn: they are made by mirroring the others. Same with tiles: 34 are made by reversing the eight bits of another 34.
Mirroring a 16x16 sprite is not just flipping bits - you must swap its two columns. The cartridge does it with an inc e and a sub 020h on the low byte of the address (0x46E6), entering with the destination already pointing at the second half. Getting that wrong gives you figures split down the middle, and the VRAM check says so plainly: with the fix, 0 bytes different out of the 2,048 of sprite patterns.
The eight bytes at 0x4720 are the VDP registers, and they lay the tables out the wrong way round: colour low and patterns high. Colour at 0x0000..0x17FF, sprite patterns at 0x1800, patterns at 0x2000..0x37FF and names at 0x3800. An ld hl,00008h in this cartridge does not point at patterns: it points at colour.
And the decompressor runs backwards from what it looks like too. At 0x46A6, bit 7 SET means literal and clear means run: it is decided by where the djnz jumps back to, the ld a,(de) - so it re-reads - or the out - so it repeats.
At the end of the cartridge, behind the padding, sits the title in katakana written backwards along with the catalogue number: グーニーズ and the 34 of RC-734. The finding is not ours: Manuel Pazos uncovered it in 2021, and it is thanks to him that anyone knows to look there. This cartridge also pins down a character that was still unconfirmed: 0xBA only works out as the long-vowel mark.
And something the cartridge itself says, rather than an outside catalogue entry: the title-screen caption, drawn from the ROM, reads © KONAMI 1986, with the 1985 Warner Bros. trademark notice below it. The game is from 1986.
Under each picture is where it comes from and what is on it.
0x6F68 gives ONE tile per item and the game takes that one and the next three to build a 2x2 on the bottom row. Levels 6 and 15 do not show up in the list: they are the two with no item.