There is not one illustration here. The wordmark, the scoreboard and all eighteen holes are drawn from the bytes of the ROM, by running in Python the same decompressors and the same script interpreter the Z80 runs, and checked against the emulator's VRAM: 13,655 of 13,664 bytes identical — the nine that differ are the scoreboard digits, which the game writes as it plays — and all 480 cells of every hole exact across six in-game dumps. The one screen capture on this page is the CALL GOLF one, because what it shows is precisely the cartridge running. The listing and the numbers come from the binary and are reproducible with make.
The eighteen screens are not eighteen separate backdrops: they are windows onto one course of 20 × 415 cells. Hole 1 is the southern end, hole 18 the northern one, and two consecutive holes share one row: the top row of hole n is the bottom row of hole n+1. That is why the lake hole 1 ends in sits at the foot of hole 2, and the sea crowning hole 2 is the one washing hole 3.
theNestruo spotted this. Here it is measured: the shared row matches on 70.9 % of its twenty cells, against 41.6 % for any two adjacent rows within a single hole — the baseline it has to beat — and 21.0 % for two rows that do not touch. All seventeen joins beat it, one by one. And the overlap is exactly one row: trying one through six, one wins in all seventeen pairs.
Stacked the other way round — hole 2 below hole 1, which is how this site had it first — gives 35.9 %: below the baseline. What was wrong was the measurement, not the map.
There is not a single coordinate in a hole's script: the continuity is drawn, not computed. And the game itself gives the direction, because all eighteen tees sit in the top rows and all eighteen flags in the bottom ones: every hole is played north to south, and the course is walked south to north.
A whole hole takes some three hundred bytes, and the trick is in the first three. The cartridge copies them to 0xE451 and there they stay: they are the hole's palette. Then, in the script, a 0x3n, 0x4n or 0x5n byte repeats the first, second or third of those materials n+1 times.
What links the two is a subtraction of three. The palette index is the opcode's high nibble, and the table starts at 0xE44E — three bytes before the header — exactly so that 3, 4 and 5 land on it. So there is no palette table: there is an offset that makes the hole's header be the palette.
The MSX's SCREEN 2 is three independent thirds, and for all three to hold the same thing you have to write it three times. 0x9505 makes the six calls — three of patterns and three of colour — but 0x9834 sets DE=0xB324 again on every one, so all three decompress the same source.
That is 2 KB of cartridge for 6 KB of table, and the same for the colour. The game's entire pattern table fits in 1,613 compressed bytes.
0x9505 is an or 0AFh, that is, the two bytes F6 AF: call there and the Z flag goes clear, and the six calls behind it load the long tables. But 0x8829 calls 0x9506, the second byte of that same instruction, and 0xAF on its own is xor a: entering there runs the operand, zeroes A and sets Z, and then the six load two short tables that only touch tiles 0x10 to 0x1D of each third.
Those fourteen tiles are the letters of HOLE IN ONE. The rest of the screen — the striped background, the credits — is built with the same 20×24 grid the course uses.
Both decompressors stop when the VRAM pointer reaches its limit, not when the source runs out. And the wordmark's two tables fall short: they give 104 of the 112 bytes that have to be written.
So they keep reading. The last eight bytes of tile 0x1D come from the header of the colour table that follows, and the colour table's own come from the start of the code at 0xBE0D. All sixteen bytes sit like that in the emulator's VRAM. It is free because nothing names tile 0x1D: the wordmark's two halves only reach 0x1C.
There is no table with the holes' details. The par is told by the very tile that draws the tee: 0xD9 is a par 3, 0xDD a par 4 and 0xE3 a par 5, and on the way past the interpreter notes where it is so it can place the ball. The length is three ASCII digits stuck right behind the 0x21 that closes the map, and the scoreboard writes them out as they are with an 'm' beside them.
Added up, the eighteen give a course of par 72 and 6,430 metres, with four par 3s, ten par 4s and four par 5s. A championship layout, and not one byte spent saying so.
0x9571 writes ten cells per row and skips twenty-two to land on the next, twenty-four times over: that leaves the TOP, SHOTS, HOLE, PAR, POWER, CURVE and CLUB panel filling columns 1 to 10 of the screen.
The course comes in right behind it. 0x9A66 dumps the hole's 480 cells as twenty columns by twenty-four rows from 0x180B, which is column 11. The two halves never collide because neither is drawn centred: each one knows its own width.
Under each picture is where it comes from and what is on it.
CALL GOLF. Drawn with the same interpreter and the same tiles as the cartridge's, because it is the same formattools/campo.py in the cartridge's own format: a sand fairway, a lake that swaps sides, and a bar of water at the top as many cells long as the hole number. They are drawn with the same interpreter that draws the ROM's — if the format were misunderstood, this would come out as noiseCALL GOLF typed at the BASIC prompt: the attract mode draws the generated hole 2 — 480 of 480 cells — and the scoreboard reads its PAR 4 and 302 m, which are not the ROM's 168 m par 3. Captured from openMSX by tools/omsx_call_golf.tcl