The first thing you do with a cartridge is disassemble it. Here you get nonsense: the entry point is nop / dec h / add a,b / ld bc,09700h / illegal sequence. It is not that the disassembler is failing: there is no code there.
The header says so if you read all of it. INIT, STATEMENT and DEVICE all zero, and the only thing declared is TEXT=0x8010. That means "there is a BASIC program here", and the interpreter runs it from the ROM itself, without copying it to RAM. The game's only call to machine code, USR(0) in line 30000, points at address 0: pressing STOP resets the machine.
The nine holes take exactly 4,000 bytes, from 0xB000 to 0xBF9F, one behind the other. Each is a list of 16-bit values that subroutine 2500 reads with PEEK. The values run three at a time - x, height, depth - and a lone value between 30001 and 30015 is a marker: it changes the colour whatever follows is drawn in and, along the way, shifts the grouping by one. A 32000 closes the hole.
The marker's colour is not decoration: it says what the next stretch is made of, and it is used to fill in the previous one. The order is the same in all nine:
6 the outer outline; its fill is the out-of-bounds
2 the fairway 3 the green
1 the flagstick; its fill, with the seed on top, is the hole
14 the bunkers 4 the water
13 the treesEach hole's colour-1 stretch is four points: an 8-high vertical mast and a triangular pennant at the top. And it is planted exactly where that hole's DATA declares the flag to be, in all nine.
That matters because the DATA's order is not obvious. Each line carries the par, the distance, a varying number of fill seeds and the flag - and the flag is the last two values, not the first. We know because three separate counts have to agree at once, and they do:
PQ$ string in line 80 and add up to 36, the total the scoreboard writes by hand.And there is a fourth check, coming from somewhere else entirely in the cartridge: the frozen round in the variable table (see below).
Trees are three consecutive magenta stretches: two crossed diagonals and the trunk. That is, four edges from the corners of a 4x4 base up to an apex 15 high, plus the axis. A wireframe fir in five lines.
It looked like the end of the run, and it is not. It is where subroutine 4000 - the plan view - stops drawing. What comes after still belongs to the hole, and subroutine 5000 draws it: two or three stretches with coordinates up to 20,000, which are the vanishing lines out to the horizon, and on hole 3 a 2,000x400 wall at depth 1,200: the mountain in the background. They are only visible in perspective.
Line 5166 works out each marker's colour... and nobody looks at it. Line 5690 draws always in white (or dark green when the camera is in the green's close-up). The colours only matter for the plan.
There is no logical map, no grid of cells. Line 380 takes the ball's position over to the plan view in the right-hand panel and reads with POINT the colour painted there. That colour is the terrain, and out of it come the golfer's stance, the penalties and how the ball bounces.
Which is why the plan is not decoration: it is the game's data structure, and why the order of the markers matters so much.
Line 440 checks whether the terrain is colour 12 and slows the ball if it is. That condition cannot happen: no hole paints colour 12 on the plan, in any of the nine. It is dead code - most likely the rough of an earlier version, before the rough became the background colour, which is 0.
The 3,231 bytes between the program and the course data are the interpreter's variable table, frozen exactly as it was left in a real session of the game. That is the trick that boots a BASIC cartridge with no INIT routine: the ROM carries the program and its state already set up.
It can be read in full, and it tells a story: hole 2, twelve strokes in all, eleven of them spent on hole 1. And the course read pointer, ZM, holds 0xB37A - which is exactly where hole 3 begins, because with hole 2 in play its outline had already been read. HX and HZ hold hole 2's flag with the one-metre adjustment already taken off, and P holds 3, its par.
Four figures from the frozen state that agree with the reading of the course data, without using the program at all.
The last array, C1(), starts at 0xAFA1 and does not fit: it is 25 bytes short, which is precisely where the course data begins. The table is cut off, and it does not matter, because the interpreter rebuilds it all when it runs the DIM in line 20.
The program never issues a RESTORE, and the ZM pointer does not rewind either. The nine holes' DATA are read straight through, once, and the course is read straight through, once. After hole 9, line 720 is a GOTO 720: an infinite loop. Playing again means resetting the machine, and that is not an oversight at the end - there would be no way to rewind even if it jumped back to line 110.
If the ball is in sand and you pick the putter, line 280 sends the turn back to the start. But the start of the turn is line 225, which adds a stroke. Trying it costs a stroke every time, with the ball never moving.
D2(240) is reserved in the DIM in line 20 and appears in no other line of the program: 482 bytes of RAM set aside for nothing. ZL$ is assigned "0000" at the end of line 70 and nobody reads that either. And the lone RND(1) in line 90 does have a purpose: it stores its result nowhere, it is there so the generator has advanced an unpredictable number of times before the first hole's wind is drawn.