What is not settled, said as what it is.
DEFINT D and the 3D viewLine 3 ends in DEFINT D, verified in the bytes (AC 44). That makes every variable starting with D an integer, DN() included - and DN() is where subroutine 5000 keeps the rotated outline. The rotation in lines 5140 and 5145 ought, therefore, to be rounded to whole numbers.
Drawing the view both ways and comparing against the emulator's VRAM gives the opposite of what you would expect: without rounding, 18,011 of 18,432 pixels match; with rounding, only 17,756. Something is missing from the chain. It is written down as a question, not a conclusion.
The cartridge's own frozen variable table confirms DEFINT D is in force - DX, DY, DZ, DD, DA, DB and D4-D7 are all stored as two-byte integers, and DI() as an integer array - so the doubt is not whether the directive works: it is why the drawing comes out better without applying it.
Of the 18,432 pixels in hole 1's view, 421 do not match the emulator. All of them are edge pixels of the same lines, off by one: the lines are where they should be, but the staircasing differs. Six variants of the trace were tried - initial error at 0, at half, at half plus one, at maximum, at one, and with the endpoints swapped - and they all land between 97.4 % and 97.8 %. Emulating the interpreter's six-digit precision does not fix it either.
It reads through and fits: 98 plain variables and nine arrays, in the program's order, with the last one cut off 25 bytes from finishing because the course data starts at 0xB000. What has not been done is checking value by value that all 98 hold what they should at that point in the round: the ones that pin down the course reading were checked (H, ZM, HX, HZ, P), and the rest were taken as good because the pattern fits.
From 0xBFA0 to 0xBFFF sit 96 bytes nobody reads: the ninth hole ends at 0xBF9F and that is where everything the program consults stops. They are not zeros - there is content - but no line reaches that far. Most likely they are whatever was in memory when the ROM was burned, like the variable table, but that is not verified.
All nine are decoded and drawn, and the three cross-checks agree on all nine. But only hole 1 has been compared against the emulator's VRAM, because to see hole 2 you have to hole out on 1, and there is no convenient way to automate that: the program has no shortcut for changing hole and the round cannot be rewound.
The other eight come out of the same engine and the same data, and their reading is backed up as well by the cartridge's frozen round, which points at hole 3. But compared byte for byte against the machine, one.