In the emulator

It has to be anchored in page 2

openMSX does not guess this cartridge right on its own: it puts it at 0x4000 and the game never starts, because its header declares TEXT at 0x8010 and there is nothing there. You have to tell it. With an extension of your own:

<?xml version="1.0" ?>
<!DOCTYPE msxconfig SYSTEM 'msxconfig2.dtd'>
<msxconfig>
  <info>
    <name>3D Golf Simulation</name>
    <manufacturer>T&amp;E Soft</manufacturer>
    <code/><release_year>1983</release_year>
    <description>A 16 kB cartridge anchored in page 2.</description>
    <type>cartridge</type>
  </info>
  <devices>
    <primary slot="any"><secondary slot="any">
      <ROM id="3D Golf Simulation ROM">
        <mem base="0x8000" size="0x4000"/>
        <rom><filename>.../3dgolf.rom</filename></rom>
        <mappertype>Mirrored</mappertype>
      </ROM>
    </secondary></primary>
  </devices>
</msxconfig>

Save it under share/extensions/ in openMSX's user directory and start with -ext <name>. slotmap confirms the ROM sits at 0x8000.

And it wants a Japanese MSX

The game writes the golfer's stances and the panel's labels with high bytes, which on a Japanese MSX are the graphics and katakana and on a European one are other symbols. On a European machine the course comes out the same - it is pure geometry - but those labels come out wrong. It is not a fault in the cartridge.

And patience

Drawing hole 1 takes the interpreter more than five minutes of emulated time: subroutine 2500 reads the outline value by value with PEEK, HEX$ and VAL, and the plan's fills are not quick either. tools/omsx_campo.tcl turns the speed limiter off and waits until second 380 before dumping.

What was checked against VRAM

tools/campo.py draws the course by running the program's own subroutines in Python, on an emulation of SCREEN 2 with its colour attributes. make vram compares the result with the emulator's dump:

region	pixels matching	VRAM bytes matching
plan view	15,737 of 15,744 (99.96 %)	4,217 of 4,224 (99.83 %)
3D view	18,011 of 18,432 (97.72 %)	4,439 of 4,608 (96.33 %)

The plan is the one that counts, because it is the one the game reads with POINT to know what the terrain is. The seven pixels that differ are on the edge of two bunkers.

In the 3D view, the ones that differ are edge pixels of the same lines, off by one. Six variants of the line-drawing were tried and none closes the gap entirely; it is in Open questions.

What VRAM taught us about SCREEN 2

Emulating the display was not optional - the game reads from it - and the obvious model came out wrong. What real VRAM says:

• A LINE ... BF is not a heap of points: it fills by whole bytes, and wherever the row of eight pixels ends up fully covered it leaves the pattern at zero and the colour in the low nibble. The view's ground reads pattern 00 and colour 0C; the sky, 00 and 05.
• When a point is painted in a colour that is neither of the row's two, the result depends on how the row was. If it was all background, the new colour goes in as ink - which is why the view's white lines come out thin over the green, 0C becoming FC, instead of dragging the whole cell with them. If it was all ink, it goes in as background: that is how the white frame slips into the plan's border, 60 becoming 6F with the pattern going FF to 7F.
• SCREEN 2 + CLS leaves the colour table at 0x00, not 0xF0.

With the naive model the plan matched at 38 %. With this one, at 99.96 %.