Findings

The four rooms of a level are not a column: they are a plan

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 that in the game they are grouped per level and in different shapes - citing levels 1, 2, 3, 8 and 11 as examples. Every one of them proves him right. 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 another room (0xF: none) and the high one is THE POSITION of this one 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, counted tile by tile along every internal seam of all 25 levels:

reading	last row against the first row below	last column against the first column beside
the right one	77.8 %	56.6 %
axes swapped	0.4 %	0.0 %
baseline: rooms from ANOTHER level	10.8 %	7.2 %

The reading that was published matches below chance. There is a test that demands this, and that also requires the swapped reading to fail.

And it fits the two transition tables, measured over their 38 entries each: the room 0x52DB gives is always directly above, and the one 0x5327 gives always directly below. Room n+1 - the dec b at 0x529A and the two inc b at 0x52A2 - is the one to the right, wrapping to the start of the next row when the current one runs out, the way text is read.

The twenty-five arrangements, counted off those bytes:

shape	levels
a row of four	1, 10, 15
a column of four	2, 19
2x2	3, 9, 13, 17, 24, 25
two columns by three rows	4, 6, 8, 11, 14, 21
three columns by two rows	5, 7, 12, 16, 18, 20, 22, 23

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.

The cartridge defends itself: copy protection

Two instructions in the start-up write inside the cartridge itself:

• 0x4022 puts a pop hl and a ret over the djnz at 0x411C. It loads 0xC9E1 into HL and drops it in one go: in memory those two bytes are E1 C9, which read as pop hl and ret.
• 0x4050 leaves a zero at 0x4129, which is not data: it is the operand of the jp at 0x4128. In memory that turns it into jp 00000h, a dead reset.

Neither of them does anything here. The cartridge runs from ROM, and ROM takes no writes: that is why they look like dead code. They are not. A pirated cartridge is a copy loaded into RAM, and there the write does land and breaks the game. Doing nothing on the original is exactly the point.

This is no one-off idea in this cartridge: the same pair —a write over a djnz and another over the operand of a jp— turns up in nine cartridges of this series, always in the same two start-up routines, and the second one alone in one more. Manuel Pazos identified them in his disassembly of RC-727, where he named them ReadKeys_AC and VRAM_writeAC.

All 64 skull doors pair up without a single exception

Also theNestruo, in the same issue: he asked for a minimap per round with the doors joined by lines. There was no way to draw one without knowing which door goes with which, and going after that 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.

Every line on that minimap joins two doors that really pair up. There is one per round in The map.

The name of the round is its password

You can type on the title screen. 0x53C8 reads the keyboard with SNSMAT and piles what you type into 0xE4C0 — up to sixteen letters, with the index in (0xE074) — and on release it calls 0x5444, which matches those sixteen bytes against five names, from 0x546E onwards and nineteen bytes apart.

If one matches, 0x5421 uses which it was as an index into the table at 0x543A:

password	level	round
MR SLOTH	6	2
GOON DOCKS	11	3
DOUBLOON	16	4
ONE EYED WILLY	21	5
GOONIES	1	1

And here is the detail: those very bytes are also the caption painted on screen. Each of the five is a complete literal script — VRAM address, sixteen tiles and the closing 0xFF — and the comparison enters two bytes further in, skipping the address. There are not two tables: there is one.

That is why 0x53A7 shows you the password when you clear a round, under the KEYWORD caption: it is showing you the name of the round you have just left.

The names for rounds 2 to 5 have their pointers at 0x53C0, indexed by (0xE06C)-2. The fifth, ONE EYED WILLY, is the only one without a closing 0xFF, and that fits: it is the round you reach, never one that gets announced.

Sixty-four thousand tiles in 2,983 bytes

A hundred rooms of 32x20, all of them different, in under three thousand bytes: twenty-one tiles per byte. It is taken apart in The code — 8x4 blocks, the mirror bit and the shared tails — and the result is on show in The 100 rooms.

The twenty-seven ways to uncover a hidden item

The longest table in the cartridge is the one at 0x6DBD: twenty-seven entries. Each is a 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 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 frame by frame 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: each condition is used exactly once. 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. That is 0x6E14.

Items are shields with charges

The list at 0x7D9B is eight bytes, one per hazard, and it says which inventory item stops each one — or 0xFF if none does. Carrying it, the hit does not take energy: it spends one charge of (0xE150+item), and when they run out 0x8B37 drops the item from the inventory.

The seven hazards and their bit, which 0x7A9E leaves in (ix+00Ah) — also where the player's colour comes from:

hazard	bit
water jet	0x01
stalactite	0x02
drip	0x04
flame	0x08
rising column	0x10
pipe leak	0x20
boulder	0x40

The energy bar is sixteen bits — (0xE063) the fraction and (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.

The demo is a recorded game

0x51D5 simulates nobody: it plays back a tape. 0x472D starts by reading the joystick and keyboard with 0x4742, but 0x5206 jumps in at 0x4730, which is the very next byte, with a already loaded from a table. So the input routine runs from halfway through and hands back whatever it was fed.

Two parallel tables, both indexed by (0xE00B): at 0x520E, 34 joystick states and the closing 0xFF; at 0x5231, how many frames each lasts. When (0xE00C) reaches the duration, on to the next. The 0xFF closes the recording and clears (0xE066).

This is what makes it possible to check VRAM by booting the cartridge from cold: the intro, the title and the demo come up on their own, always the same, with no savestates and no breakpoints.

The chaser counts tiles to pick a rope

When the chaser wants to change height, 0x756D and 0x7577 walk its row tile by tile in both directions, counting how many there are until they hit 0x41 — the foot of a rope — or 0x53 — the head — and it heads for the shorter count.

And bit 0 of (ix+00Fh) decides which side is tried first, 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. 0x66E4 says so: the player climbs 0x41 pressing up and goes down 0x53 pressing down.

The water keeps a notebook of what it covers

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.

The current, on the other hand, moves nothing. 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.

Each record in those batches is four bytes of pattern and two of jump to the next tile. The third jump is read and then not used: that is why each batch takes sixteen bytes and not eighteen.

Half the artwork is manufactured at boot

Of the 42 16x16 sprite patterns the cartridge carries (0x927F), 22 are not drawn: 0x4CDF manufactures them 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 have to swap its two columns, because a 16x16 pattern is two columns of sixteen bytes laid one behind the other. The cartridge does it by entering with the destination pointing at the second half (0x1D50, not 0x1D40) and with the inc e / sub 020h dance on the low byte of the address, at 0x46E6.

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 table at 0x6996 confirms it too: the mirrored drawing is painted twelve pixels to the left and the normal one four.

The geometry is upside down, and so is the RLE

The eight bytes at 0x4720 put colour low and patterns high, which is the opposite of what nearly everyone does. It is in The cartridge.

And the decompressor at 0x46A6 runs backwards from what it looks like too: bit 7 set means literal and clear means run. It is decided by where the djnz jumps back to.

The title screen and the ending are the same screen

0x558D builds a single scene, with nine characters walking, and both come out of it: it only differs on (0xE06C)==6, that is after you finish the game. The THE GOONIES lettering is painted on top of that scenery and is not erased when you enter it, because between scenes the cartridge only clears the name table.

A sprite is switched off with a 0xC0 in the row

At 0x6576, a sprite is removed by putting 0xC0 in its row byte, which is the VDP convention. Not in the pattern byte — and 0xC0 is a perfectly valid pattern number too. Checking the wrong byte eats good sprites: the player's seventh pose came out with no body.

The caption says 1986

No outside catalogue entry needed: the title-screen caption, drawn from the ROM, reads © KONAMI 1986, with the 1985 Warner Bros. trademark notice below it. The film is from 1985; the cartridge, from 1986.

The house's hidden mark

It is covered in The cartridge. The finding is Manuel Pazos's, and this cartridge pins down a character that was still unconfirmed.