Myths, tested

Derby Owners Club stores the track condition as a single number from 0 to 3, on one going scale, and it is the same scale for every race:

That number is generated from the weather and race data, then printed by the on-screen TRACK CONDITION line. Whether the race runs on turf or dirt is stored separately, as part of the race identity; the race name itself carries TURF or DIRT. The code that sets the track condition never looks at the surface.

Four routines in the program ROM write the track condition. Every one of them sets it from weather or race data, and not one of them reads the surface:

The clincher: the game's own weather-to-going table emits the Good to Soft value directly. Its outputs across all 16 entries are exactly the set {Good, Good to Soft, Soft, Heavy}, and the Good to Soft value appears at two entries:

The input to that table is the weather and the race seed. There is no surface input anywhere in the chain. When the weather lands on those entries, the going becomes Good to Soft for the race, turf or dirt alike.

value 0 -> "GOOD"          (file 0x10EB3C)
value 1 -> "GOOD TO SOFT"  (file 0x10EB44)
value 2 -> "SOFT"          (file 0x10EB54)
value 3 -> "HEAVY"         (file 0x10EB5C)

0x0C076B3A  mov.l  0xc076be4,r3   ; r3 = &condition (0x0C21A2B4)
0x0C076B3C  mov.l  0xc076be8,r0   ; r0 = value table (0x0C170BD0)
0x0C076B3E  mov.l  @r3,r2         ; r2 = condition (0..3), read raw
0x0C076B40  mov.l  0xc076bec,r1   ; r1 = "TRACK CONDITION %s"
0x0C076B42  shll2  r2             ; r2 = condition * 4
0x0C076B46  mov.l  @(r0,r2),r2    ; r2 = table[condition]  (no surface input)
0x0C076B4A  jsr    @r3            ; sprintf

0x03E778 / 0x03EA32 : condition = (raceData[+0x28] >> 4) & 0x0F
0x03F956            : condition = byte at raceRecord[+0x72]
0x054012            : condition = weatherGoingTable[(seed >> 3) & 0x0F]

entry  0 -> Good           entry  8 -> Good
entry  1 -> Good           entry  9 -> Good
entry  2 -> Soft           entry 10 -> Good to Soft
entry  3 -> Good           entry 11 -> Good
entry  4 -> Good to Soft   entry 12 -> Good
entry  5 -> Good           entry 13 -> Good
entry  6 -> Good           entry 14 -> Heavy
entry  7 -> Soft           entry 15 -> Good
distinct outputs = { Good, Good to Soft, Soft, Heavy }

Both halves of the argument are half right, so we tested each one against the ROM. The food list holds 45 items, and beer is two of them:

Beer is a genuine food, not a gag. Each food is a 44-byte record with a name, an artwork pointer, and a block of stat values. Draft Beer and Black Draft Beer are complete, well-formed records, and the routine that looks a food up by its number is plain arithmetic with no "is this a real food" check. So the game reaches beer exactly the way it reaches a carrot.

But beer boosts nothing. The six stat-growth bytes in every food record are what a feed actually adds to the horse. We know these six bytes are the growth values because the "Large" version of any food carries the same six numbers scaled up: Korean Ginseng is 2,2,2,2,2,2 and Large Korean Ginseng is exactly 4,4,4,4,4,4. Beer's six bytes are all zero. It is the only food in the game with an all-zero payload. Feeding beer adds nothing to any stat.

Instead, beer is special-cased for a reaction. The stable code singles out beer by ID in three places (grouped with bananas as novelty items). Rather than running the normal feed-and-grow path, beer sets a small reaction state (Draft Beer and Black Draft Beer each flag a different one) and pulls from its own dedicated table of sequence pointers. In other words the developers wrote special code so beer does something on screen, just not a stat gain.

So is beer actually offered to you in this version? That is a separate system from the stat values, and it is where the trail goes cold in the ROM. Whether a food shows up in your feed choices is decided by a small runtime table the game builds when a session starts: the offer routine reads that table per food and offers the food when its value clears a threshold. We traced that table all the way back to the code that fills it, and found two things. First, there is no beer-specific "off" switch anywhere: not in beer's record, not in the lookup, not in the availability data, and not in the table's setup code. Beer is handled by the same general machinery as every other food. Second, the table is not a fixed list in the ROM; the game computes it at runtime. That means the one remaining question, does beer's entry land in the offerable range in this build, cannot be answered by reading the ROM alone. It has to be read from the game while it runs.

0x0C09AD3E  mov   #44,r0       ; record stride
0x0C09AD44  muls.w r0,r4        ; id * 44
0x0C09AD4A  add   r3,r0         ; + table base, no range check
0x0C09AD4C  rts

id 36 KOREAN GINSENG        1C..21 = 02 02 02 02 02 02
id 37 LARGE KOREAN GINSENG  1C..21 = 04 04 04 04 04 04   ; exact double
id  0 CARROT                1C..21 = 02 00 00 00 00 00
id 43 DRAFT BEER            1C..21 = 00 00 00 00 00 00   ; all zero
id 44 BLACK DRAFT BEER      1C..21 = 00 00 00 00 00 00   ; all zero

0x0C0A4110  draw path  : beer uses hardcoded display offsets
                         (0x764 / 0x790) into a separate buffer,
                         not the normal table + id*44 indexing
0x0C0A5B44  feed path  : bananas (41/42) + beer (43/44) share a
                         branch; beer writes a reaction state at
                         0x0C21A4F4 (draft=1, black draft=2)
0x0C0A5FA0  feed path  : beer indexes its own pointer tables at
                         0x0C187E60 / 0x0C187E8C (its reaction
                         sequence), bypassing normal handling

0x0C04806C  offer builder : for food 0..44, read the runtime
                          array at 0x0C21D738 + food*4, look it up
                          in the availability table, and offer the
                          food when the result is < 3
0x0C09AD50  lookup        : reads AVAIL[value*16 + mode_column]
0x0C1467FC  AVAIL table   : 16 bytes per row; beer's rows are
                          normal and offerable, not gated

0x0C03563C  init fill loop : writes 0x0C21D738[index] for the
                           first 40 foods; each entry is the
                           return of a runtime divide routine
                           (0x0C0C211C), not a value copied from
                           a fixed table in the ROM
beer entries  : DRAFT BEER       -> 0x0C21D7E4  (0x0C21D738 + 43*4)
                BLACK DRAFT BEER  -> 0x0C21D7E8  (0x0C21D738 + 44*4)

This claim has two halves, and they do not fail the same way. One of them is very nearly right. The other is wrong, and the real Rev D difference turns out to be something else entirely.

Half one: is Competing worth investing in?

We built four horses that were identical in every respect the game tracks: same sire and dam, same race record, same earnings, same three internal stats, same running style, and the same total externals. The only difference was which external carried the high value. Each horse loaded one stat to 63 and left the other three at 32.

Before the gates opened, the game ranked them. This ranking is computed from the horse's stats, so it is the game telling you what it thinks each stat is worth:

Same points, same cost, and the Competing horse is rated last. Then they raced, over 2000m on turf:

Three of the four ran the identical time. The Competing horse was the only one that could not keep up, and it was beaten by a computer horse in the process. The game's own ranking and the actual race agree with each other, and both put Competing last.

To be precise about what "doesn't matter" can and cannot mean: the stat is not dead. We disassembled both program ROMs, and Competing is read and processed on exactly the same footing as the other externals: copied three ways into each race entity, run through its own conversion routine, and consulted by the game's own horse-evaluation ladder. Nothing skips it or zeroes it. But among the five externals that get a conversion constant, Competing's is the smallest, a twentieth of the one Tenacious gets. We have not yet proven how those converted values feed race speed, so treat that as a hint rather than a measurement. The measurements are the tables above.

Full honesty on sample size: we also ran head-to-head rounds between horses differing only in Competing (1 vs 21 vs 42 vs 63), and those were mixed. One round produced a perfect finishing gradient in Competing order, another leaned the other way. The four-way ranking round above is the cleanest single result so far, and more rounds are queued. What no result has shown is Competing outperforming an equal investment in any other external.

There is a second, quieter cost. Derby Owners Club damps your training gains as your six externals add up. The higher your total, the less each session gives you, while a failed training still takes the full amount away. In our tests, horses with a total around 227 to 245 gained from rest and training, while horses at 263 to 281 gained nothing visible and still lost 3 points on a failure. So points poured into a weak stat are not merely wasted. They also throttle everything you try to add afterwards.

Half two: is this what changed in Rev D?

No. Competing is handled identically in both revisions. The routine that converts it is the same nine instructions, using the same constant, in Rev C and Rev D alike. Nothing about this stat was touched.

What actually changed in Rev D is a ceiling on internal growth. Once a horse's three internal stats add up to more than 160, the ordinary per-race growth switches off. Decay from neglect still runs, so a Rev D horse settles just above 160 and hovers there: a ceiling it drifts back to, not a cliff it falls off. Rev D also lowered the per-stat ceiling from 60 to 55. Rev C already slowed growth at higher totals, so this was a re-tune that added a lower, harder rung rather than a brand new idea, and Rev D even loosened one veteran career band (35 races where Rev C used 30). Externals keep improving as normal throughout, which is why the change is easy to misread: your horse is still developing, just never where you are looking.

We tested this with two horses that were identical apart from their internals, on the same cabinet, on the same evening:

One number changed between them, and the outcome flipped. The same horse on Rev C had gained on every single race.