The whole binary is explained and everything it draws is checked against the emulator. What is left are loose ends of detail.
0xBB6F and 0xBCA9 decompress 408 bytes each into VRAM 0x1168-0x1300 and 0x3168-0x3300, that is, patterns and their colour for tiles 0x2D to 0x5F of the third third. 0x9A92 loads them, along with the hole and par markers.
The format is clear and fits its neighbours without a gap, but none of the dumps taken reaches that screen, so its content is not checked against VRAM the way the rest is. Getting there in the emulator and dumping would settle it.
The greens use tiles 0x10 to 0x1F, which the title's wordmark overwrites, and 0x9ABD reloads the third third from the long tables. The exact path by which the other two thirds get reloaded before putting is still to be tied down.
0x9BCF holds the offsets and the small graphic pieces of the POWER, CURVE and CLUB meter. The first seven bytes are the offsets for indices 0 to 6 used by the script at 0x9B6E; the rest are more offsets and fragments, not broken down block by block.
Three eight-byte records, indexed from 0x8491 with ((0xE01C)-3)*8 + (0xE45B). Only fields +0 and +4 of each record are confirmed.
The eight PSG tracks are followed byte by byte with the same interpreter the code uses, and that is where the highest note they play - number 36, exactly where the period table ends - comes from. That simulation is not checked against the emulator, unlike the screens. It counts as very likely, not as confirmed by a second source.