# A table the game builds at start-up comes out wrong under the emulator

## Symptoms

POD's `FUN_004cfde4` builds a square-root table (√j × 65536, truncated). Run under Unicorn,
10,289 of its 24,576 entries came out one above the truncated root, with no pattern by the
fraction (between 0.5 and 1 some rounded up and some did not).

## Cause

Unicorn starts the x87 with the control word 0. Its precision control (bits 8 and 9) is then
00: every result rounds to 24 bits, single precision. A program on Windows starts with 0x037f
(64-bit precision, round to nearest) because the C library's start-up runs `fninit`; in POD
that is Watcom's at 0x4d74e0. A function called directly under the emulator skips the
start-up, so its `fsqrt` and `fmul` rounded to 24 bits (*measured*: the control word read in a
code hook was 0, and the table matched `trunc(sqrt(j) × 65536)` once the word was set).

## What to do

Start every emulated call through a stub that runs `fninit` and loads the control word the
game runs with (`fninit; fldcw [cw]; call target; hlt`). That is not always the start-up's:
POD's start-up leaves 0x037f, but in the race the game runs with 0x027f (53-bit precision),
read from a step log recorded inside the game. Under 0x037f, one target point in about 18,000
game steps came out one unit off. Read the control word in the running game when you can. `measure/race_rules.py`'s
`run` and `measure/controllers.py`'s `run` use such a stub (the latter with 0x027f). Run a start-up routine that fills tables
(here `FUN_004cfde4`) the same way, then keep the filled image for the later calls. When an
emulated float result looks slightly off, read `FPCW` in a hook before blaming the code.

GameFrame's `pe32_emu` now starts the x87 at 0x037f, as Windows starts a program, and
`reset()` puts it back. Pass `fpu_cw=0x027f` (or the word you read) when the game runs with
another one.