SOURCE DOCUMENT · 24 OCTOBER 2026

Team baseline investigation

# Team baselines: inventory, origins, editing and practical consequences

Research-only investigation, 2026-10-24. No disk, player data, existing program or prior research file was changed. This report refers to `original_disks/Micro League Baseball (1984)(Micro League Sports Association)(US).atr`, 92,176 bytes, SHA-256 `2f94eb9a5fa06408c46ad24cf5b8d7398de195d7354f5734dea48c03045cca75`.

## Explanation for someone who knows the game

The game does not judge a pitcher from his statistics alone. It compares his hits, walks and strikeouts per inning with a set of reference numbers stored with the **team that is batting**. Think of those references as a hidden backdrop behind the roster. Two identical hitters facing the same pitcher can receive different initial outcome chances if their teams carry different backdrops.

The two unusual backdrops belong precisely to the **1927 New York Yankees** and **1968 Detroit Tigers**. The other 23 teams use one common set. These names and years come from the disk's own directory; they are not guesses from the cities.

Under ordinary arithmetic without overflow, the 1968 Tigers backdrop is the most favorable of the three to the batting side: it gives higher hit and walk weights and a lower strikeout weight. The 1927 Yankees backdrop is the least favorable. This does not mean the historical Yankees were poor hitters; their actual player statistics are a separate input. It also does not mean the backdrop changes only that team's pitchers: **it applies while that team bats against the opposing pitcher**.

There is a further complication. The game stores many intermediate results in very small integers. A sufficiently large adjustment can wrap around instead of growing normally. One examined example has a strikeout weight jump from an unwrapped 312 back to 56. Consequently there is no reliable universal ranking of the three configurations across every possible input, and these calculations are not final batting averages or game-winning chances.

We can establish the locations, values and arithmetic effects exactly. We **cannot yet establish why the original roster authors chose these particular constants**, or what your exact GM/editor version does to them when saving a custom roster. The local folder contains the game image and keyboard-input scripts, but no GM/editor binary or disk. Replacing visible names/statistics therefore cannot be assumed either to preserve or to recalculate these hidden references. A controlled editor experiment is specified below.

## 1. The 25 teams and their exact bytes

### Addressing and identifiers

There are 25 physical team blocks, each eight 128-byte sectors (1,024 bytes). The catalog at sectors 461–464 contains pointers to them. This report's **team index** is the compact physical block number 0…24; **catalog slot** is the actual directory entry number. Catalog slot 13 is blank. Therefore physical team 13 is catalog slot 14, not slot 13. Letters below are A+catalog slot for orientation, including that gap; selection keys were not emulator-tested, and custom GM directories can assign different letters.

For physical index i:

```
first sector = 465 + 8*i
ATR block/header offset = 16 + (first_sector-1)*128
five baseline locations = header offset + 28 ... +32  (hex +$1C ... +$20)
```

ATR offsets are zero-based and include the 16-byte ATR header. The `baseline offset` column points to the first of the five bytes; the following four bytes are contiguous. Each block spans its listed sector through sector+7. The full table supplies both byte values and equivalent encoded rates, rather than confusing individual bytes with their combined hit baseline.

| Team index | Catalog slot/letter | Team | First sector | ATR header offset | Baseline offset | Five bytes hex | Five bytes decimal | H/IP | BB/IP | SO/IP | Common? |
|---:|---|---|---:|---|---|---|---|---:|---:|---:|---|
| 0 | 0 / A | AL All-Time Greats | 465 | $00E810 | $00E82C | 00 F6 5E 9D 14 | 0,246,94,157,20 | 0.96093750 | 0.36718750 | 0.61328125 | Yes |
| 1 | 1 / B | NL All-Time Greats | 473 | $00EC10 | $00EC2C | 00 F6 5E 9D 14 | 0,246,94,157,20 | 0.96093750 | 0.36718750 | 0.61328125 | Yes |
| 2 | 2 / C | Detroit All-Time Greats | 481 | $00F010 | $00F02C | 00 F6 5E 9D 14 | 0,246,94,157,20 | 0.96093750 | 0.36718750 | 0.61328125 | Yes |
| 3 | 3 / D | Philadelphia All-Time Greats | 489 | $00F410 | $00F42C | 00 F6 5E 9D 14 | 0,246,94,157,20 | 0.96093750 | 0.36718750 | 0.61328125 | Yes |
| 4 | 4 / E | 1927 New York Yankees | 497 | $00F810 | $00F82C | 01 18 94 4E 0A | 1,24,148,78,10 | 1.09375000 | 0.57812500 | 0.30468750 | **No** |
| 5 | 5 / F | 1945 Chicago Cubs | 505 | $00FC10 | $00FC2C | 00 F6 5E 9D 14 | 0,246,94,157,20 | 0.96093750 | 0.36718750 | 0.61328125 | Yes |
| 6 | 6 / G | 1955 Washington Senators | 513 | $010010 | $01002C | 00 F6 5E 9D 14 | 0,246,94,157,20 | 0.96093750 | 0.36718750 | 0.61328125 | Yes |
| 7 | 7 / H | 1955 Brooklyn Dodgers | 521 | $010410 | $01042C | 00 F6 5E 9D 14 | 0,246,94,157,20 | 0.96093750 | 0.36718750 | 0.61328125 | Yes |
| 8 | 8 / I | 1961 New York Yankees | 529 | $010810 | $01082C | 00 F6 5E 9D 14 | 0,246,94,157,20 | 0.96093750 | 0.36718750 | 0.61328125 | Yes |
| 9 | 9 / J | 1963 Los Angeles Dodgers | 537 | $010C10 | $010C2C | 00 F6 5E 9D 14 | 0,246,94,157,20 | 0.96093750 | 0.36718750 | 0.61328125 | Yes |
| 10 | 10 / K | 1968 Detroit Tigers | 545 | $011010 | $01102C | 00 D9 55 A9 13 | 0,217,85,169,19 | 0.84765625 | 0.33203125 | 0.66015625 | **No** |
| 11 | 11 / L | 1969 New York Mets | 553 | $011410 | $01142C | 00 F6 5E 9D 14 | 0,246,94,157,20 | 0.96093750 | 0.36718750 | 0.61328125 | Yes |
| 12 | 12 / M | 1973 Oakland Athletics | 561 | $011810 | $01182C | 00 F6 5E 9D 14 | 0,246,94,157,20 | 0.96093750 | 0.36718750 | 0.61328125 | Yes |
| 13 | 14 / O | 1975 Cincinnati Reds | 569 | $011C10 | $011C2C | 00 F6 5E 9D 14 | 0,246,94,157,20 | 0.96093750 | 0.36718750 | 0.61328125 | Yes |
| 14 | 15 / P | 1975 Boston Red Sox | 577 | $012010 | $01202C | 00 F6 5E 9D 14 | 0,246,94,157,20 | 0.96093750 | 0.36718750 | 0.61328125 | Yes |
| 15 | 16 / Q | 1978 New York Yankees | 585 | $012410 | $01242C | 00 F6 5E 9D 14 | 0,246,94,157,20 | 0.96093750 | 0.36718750 | 0.61328125 | Yes |
| 16 | 17 / R | 1979 Pittsburgh Pirates | 593 | $012810 | $01282C | 00 F6 5E 9D 14 | 0,246,94,157,20 | 0.96093750 | 0.36718750 | 0.61328125 | Yes |
| 17 | 18 / S | 1980 Philadelphia Phillies | 601 | $012C10 | $012C2C | 00 F6 5E 9D 14 | 0,246,94,157,20 | 0.96093750 | 0.36718750 | 0.61328125 | Yes |
| 18 | 19 / T | 1980 Kansas City Royals | 609 | $013010 | $01302C | 00 F6 5E 9D 14 | 0,246,94,157,20 | 0.96093750 | 0.36718750 | 0.61328125 | Yes |
| 19 | 20 / U | 1980 Houston Astros | 617 | $013410 | $01342C | 00 F6 5E 9D 14 | 0,246,94,157,20 | 0.96093750 | 0.36718750 | 0.61328125 | Yes |
| 20 | 21 / V | 1982 St. Louis Cardinals | 625 | $013810 | $01382C | 00 F6 5E 9D 14 | 0,246,94,157,20 | 0.96093750 | 0.36718750 | 0.61328125 | Yes |
| 21 | 22 / W | 1982 Milwaukee Brewers | 633 | $013C10 | $013C2C | 00 F6 5E 9D 14 | 0,246,94,157,20 | 0.96093750 | 0.36718750 | 0.61328125 | Yes |
| 22 | 23 / X | 1983 Baltimore Orioles | 641 | $014010 | $01402C | 00 F6 5E 9D 14 | 0,246,94,157,20 | 0.96093750 | 0.36718750 | 0.61328125 | Yes |
| 23 | 24 / Y | 1984 AL All-Stars | 649 | $014410 | $01442C | 00 F6 5E 9D 14 | 0,246,94,157,20 | 0.96093750 | 0.36718750 | 0.61328125 | Yes |
| 24 | 25 / Z | 1984 NL All-Stars | 657 | $014810 | $01482C | 00 F6 5E 9D 14 | 0,246,94,157,20 | 0.96093750 | 0.36718750 | 0.61328125 | Yes |

The rates are **encoded reference values**, not measurements newly calculated from those teams. Decode H baseline as `256*byte28 + byte29`, then divide that integer by 256. Divide bytes30/31 by 256 for BB/IP and SO/IP. Thus `01 18` is the binary integer 280, not decimal 118 and not BCD. The fifth byte feeds the unused fourth normalization factor, discussed below.

The three configurations are:

| Label used here | Five bytes (hex) | Five bytes (decimal) | Combined H/BB/SO/X integers | Encoded H/IP, BB/IP, SO/IP |
|---|---|---|---|---|
| C: common | `00 F6 5E 9D 14` | 0,246,94,157,20 | 246,94,157,20 | .9609375, .3671875, .61328125 |
| Y: 1927 Yankees | `01 18 94 4E 0A` | 1,24,148,78,10 | 280,148,78,10 | 1.09375, .578125, .3046875 |
| T: 1968 Tigers | `00 D9 55 A9 13` | 0,217,85,169,19 | 217,85,169,19 | .84765625, .33203125, .66015625 |

On this original game disk, the Yankees are index 4, catalog slot 4/letter E; the Tigers are index 10, catalog slot 10/letter K. The other Yankees entries (1961,1978) and the Detroit all-time team are **common**, not unusual.

## 2. What those numbers do, confirmed in the assembly

`$0C1D–$0C27` selects and copies the opposing pitcher; `$0CEC–$0D28` derives four Q8 ratios from the record's stored whole innings (offsets25–26), H (27–28), BB (29–30), SO (31–32), and raw extra numerator X (33). `$0D2A` reloads the **batting team's header**. `$0D3B/$0D3E` supply header28–29 as the hit denominator; `$0D60–$0D67` supply header30–32 for the other three normalizations. `$0C84` selects the hit/walk/strikeout factors for the six initial weights; the fourth factor is computed but not selected.

For positive valid operands, with each division rounded down separately:

```
raw_H = floor(256*H/IP_integer)
FH = floor(256*raw_H/B_H)
raw_BB = floor(256*BB/IP_integer)
FB = floor(256*raw_BB/B_BB)
raw_SO = floor(256*SO/IP_integer)
FK = floor(256*raw_SO/B_SO)
```

The existing calculator preserves signed-word/division edge behavior, packed BCD, byte-product extraction and cumulative wrap; do not replace these with one floating ratio. BB uses FB, strikeouts use FK, and all four hit weights use FH. A baseline is a **divisor**, so lowering it increases its corresponding adjustment before overflow. The fifth baseline changes FX, not these six ordinary weights; its semantic origin remains unresolved.

Header loading `$0CC3–$0CD9` copies the stored bytes. It does not calculate a pitching-staff average. The recovered builder does not inspect the team's entire pitching staff to create a new baseline. Full mathematical details and input limits are in `MATCHUP_ANALYSIS.md` and `MICROLEAGUE_ALGORITHMS.py`.

## 3. Do the baselines match the actual rosters?

### Complete stored-pitcher comparison

The table sums the ten stored pitcher records 15…24 in each block. IP means their **stored integer IP**, not reconstructed fractional innings or independently verified season totals. `Q(H,BB,SO)` here is `[floor(256*sum(H)/sum(IP)), ...]` computed independently for the three categories. This tests a specific candidate generator; it does not assume that generator is original.

| Team index / name | Stored IP,H,BB,SO totals | Pooled-staff Q8 H,BB,SO | Stored baseline H,BB,SO | Full triple matches? |
|---|---|---|---|---|
| 0 AL All-Time Greats | 2956,2455,748,1704 | 212,64,147 | 246,94,157 | No |
| 1 NL All-Time Greats | 3253,2482,586,2253 | 195,46,177 | 246,94,157 | No |
| 2 Detroit All-Time Greats | 2418,1964,726,1714 | 207,76,181 | 246,94,157 | No |
| 3 Philadelphia All-Time Greats | 2311,2048,565,1473 | 226,62,163 | 246,94,157 | No |
| 4 1927 New York Yankees | 1390,1403,409,431 | 258,75,79 | 280,148,78 | No |
| 5 1945 Chicago Cubs | 1461,1366,433,562 | 239,75,98 | 246,94,157 | No |
| 6 1955 Washington Senators | 1320,1407,613,590 | 272,118,114 | 246,94,157 | No |
| 7 1955 Brooklyn Dodgers | 1270,1197,420,707 | 241,84,142 | 246,94,157 | No |
| 8 1961 New York Yankees | 1448,1296,539,860 | 229,95,152 | 246,94,157 | No |
| 9 1963 Los Angeles Dodgers | 1408,1246,376,1057 | 226,68,192 | 246,94,157 | No |
| 10 1968 Detroit Tigers | 1451,1134,463,1087 | 200,81,191 | 217,85,169 | No |
| 11 1969 New York Mets | 1447,1183,506,993 | 209,89,175 | 246,94,157 | No |
| 12 1973 Oakland Athletics | 1448,1295,488,792 | 228,86,140 | 246,94,157 | No |
| 13 1975 Cincinnati Reds | 1411,1368,459,646 | 248,83,117 | 246,94,157 | No |
| 14 1975 Boston Red Sox | 1426,1449,482,717 | 260,86,128 | 246,94,157 | No |
| 15 1978 New York Yankees | 1324,1172,422,748 | 226,81,144 | 246,94,157 | No |
| 16 1979 Pittsburgh Pirates | 1522,1432,518,934 | 240,87,157 | 246,94,157 | No |
| 17 1980 Philadelphia Phillies | 1253,1193,441,804 | 243,90,164 | 246,94,157 | No |
| 18 1980 Kansas City Royals | 1407,1434,441,600 | 260,80,109 | 246,94,157 | No |
| 19 1980 Houston Astros | 1407,1288,437,895 | 234,79,162 | 246,94,157 | No |
| 20 1982 St. Louis Cardinals | 1360,1323,435,631 | 249,81,118 | 246,94,157 | No |
| 21 1982 Milwaukee Brewers | 1462,1479,466,771 | 258,81,135 | 246,94,157 | No |
| 22 1983 Baltimore Orioles | 1354,1347,419,732 | 254,79,138 | 246,94,157 | No |
| 23 1984 AL All-Stars | 1089,897,348,692 | 210,81,162 | 246,94,157 | No |
| 24 1984 NL All-Stars | 1000,810,326,730 | 207,83,186 | 246,94,157 | No |

**None of the 25 stored baseline triples equals all three pooled-staff Q8 values.** The discrepancy is not confined to one pitcher or one missing innings fraction. For example, the Yankees' stored walk divisor is 148 versus the roster-pooled 75; the Tigers' stored K divisor is 169 versus roster-pooled 191.

An unweighted mean of the ten individual pitcher rates also fails to reproduce the complete three-value baseline for every team examined. Common all-time AL gives `[214,67,146]` by that calculation, versus stored `[246,94,157]`. The equivalent NL calculation gives `[195,46,177]`, still with the same common header. The 1927 Yankees and 1968 Tigers unweighted results are recorded below for reproducibility:

| Team | Unweighted mean-ratio Q8 H,BB,SO | Stored triple |
|---|---|---|
| AL All-Time Greats | 214,67,146 | 246,94,157 |
| NL All-Time Greats | 195,46,177 | 246,94,157 |
| 1927 New York Yankees | 270,82,77 | 280,148,78 |
| 1968 Detroit Tigers | 198,92,183 | 217,85,169 |

As a further limited check, pooling the 15 ordinary batter records and treating `(AB-H)/3` as a **hypothetical** innings proxy gives triples `[355,142,115]` for 1927 and `[246,101,160]` for 1968, neither matching. This tests one alternative theory, not the true compiler: roster batting totals omit pitcher batting/other outs and need not represent an entire season. It does not exclude a different documented historical reference-population calculation.

### Origin hypotheses and what the evidence permits

| Proposed origin | Evidence for / against | Conclusion |
|---|---|---|
| Current roster's pooled pitching totals | All 25 triples disagree; unweighted means also fail | Not the simple direct generator tested here |
| League-wide historical averages | Shared constants and special historic teams are compatible with external reference rates | Possible; no reference population/year/rounding recipe recovered |
| Each team's own historical-season average | Different stored staffs and many different years still share identical constants | Not demonstrated; cannot infer it from the team label |
| A broad era correction | Two special teams are dated 1927 and 1968, while most use a standard pattern | Plausible interpretation, not a recovered era lookup table |
| Predefined author/editor constants | 23 exact five-byte matches are strong evidence of a common supplied configuration | Common supplied pattern confirmed; who generated it and which editor operations reset it remain unknown |
| An error, old edit or variant roster history | No authenticated unmodified master or compiler was compared | Not excluded; this image's filename/year is not complete provenance |

The fact that 1968 has a lower H/IP reference than 1927 is compatible with an era interpretation, but numerical plausibility does not establish a source. In particular, the unusual Yankees BB/IP reference must not be declared a measured 1927 league average without matching independently documented totals and rounding. We have not produced such a match. No exact league/year attribution is claimed.

The original publisher's GM manual documents creating and renaming teams, copying rosters, editing player statistics and saving revisions. It describes defaults for some visible player attributes but does not identify these five bytes, a normalization formula or a user control for them. This is documentary evidence about advertised controls, not a byte-level guarantee of preservation. The accessible scan is [MicroLeague Baseball / GM instruction manual](http[local research path]

## 4. Custom roster editing: available and missing evidence

### What is actually in this folder

A recursive file inventory finds one `.atr` and no `.xfd`, `.xex`, `.com`, `.bas` or `.exe` editor/disk program. The two partial-download files are audio downloads in `sounds`, not an editor image. There is no separate GM/Owners disk, original roster compiler or exported six-team custom ATR available here to inspect. `MLFE.py` is a small curses display experiment, not a MicroLeague disk editor. `rosters.txt` and historical automation scripts are application data/supporting evidence, not a saved byte dump of the custom team's header.

The lineup/substitution overlay inside the game image is **not the GM statistics editor**. Sector198 loads at `$8700`; its reviewed commit `$88CC–$88E4` copies header offsets41…60, leaving baseline offsets28…32 outside that write range. It changes lineups and pitcher IDs; it does not prove how a separate GM program handles player-stat edits, copy/create, rename/year changes or final disk save.

### Python roster-input scripts

| Source location | Evidence | What it cannot establish |
|---|---|---|
| `microleague input roster.py:183–191` | Focus window, send E, select a team by directory letter, send E for editing | Underlying GM binary/version and hidden save behavior |
| Same file:193–267 | Types batter names, conventional statistics, positions/ratings/speed through four screens | Whether exiting a screen recalculates hidden team bytes |
| Same file:271–324 | Types pitcher ERA, rounded IP, H, BB, SO, S/R and ratings through three screens | Baseline preservation or recalculation |
| Same file:23–26 | Historical IP rounding helper, not an Atari algorithm | Baseline generation |
| Same file:326–327 | `exit()` occurs before the following Y-save keystroke | Final save not established from the saved script alone |
| `microleague input roster 2023.py:372–513` | Analogous intended screen-input workflow | Byte-level editor behavior |
| Same file:515–516 | Active top-level exit before final Y; AST parsing confirms lines204/261 are inside disabled string blocks, not active exits | Preserved source is not an execution log proving final save; do not infer earlier termination from text search alone |

Neither input script reads team-header baseline bytes, calculates normalization baselines, supplies league reference rates, writes those raw bytes, or verifies them after saving. Player-stat aggregation in the scripts is not a baseline formula merely because it includes H/BB/SO/IP. The scripts target custom directory letters (for example D/I); their letters cannot establish inheritance from this ATR because GM directory order can differ.

### Answers to the four editing possibilities

| Question | Established answer |
|---|---|
| Does editing preserve existing baseline bytes? | Unknown for the separate GM editor. Copy-and-edit retaining them is a plausible risk, not proved. The in-game lineup commit preserves them locally. |
| Does editing recalculate them from the edited players? | No recalculation code exists in the examined Python scripts or recovered matchup builder. Separate editor behavior remains unknown. |
| Does it replace them with defaults? | Possible on create/copy/save/rename; no relevant editor binary to trace. Defaulting some visible fields does not prove defaulting these bytes. |
| Can they be edited directly in the standard UI? | No explicit normalization control documented in the examined manual, and no such input in these scripts. Not a proof that every version lacks an undocumented control. |

Changing a team name/year could be a different editor code path from changing a player's H, so those operations must be tested separately. Do not assume roster lineage is preserved merely because visible players are replaced, or assume it is erased merely because a new name is entered.

### Targeted editor experiment (not performed)

When the correct GM disk/version and the six-team league image become available, use disposable copies in Altirra; leave the evidence originals write-protected. Before each operation, record the chosen team's entire block and five header bytes. Re-find the team after save by directory pointer/name, because an editor can move its block.

1. **Copy only:** copy original common, Yankees and Tigers rosters to a disposable GM disk. Compare the five bytes immediately after load and after save/reload. This tests copy/default behavior independently of stat edits.
2. **Name only / year only:** change only team name, then separately only year. Watch offsets28…32 for writes. Test whether a year-dependent lookup/default occurs on rename or metadata save.
3. **One batter edit:** change one H while holding all other bytes constant; exit screen, verify/save, reload. Compare before/after and record the PC/overlay of any baseline write.
4. **One pitcher edit:** separately change IP, H, BB, SO; then replace the entire staff. Large controlled changes make a recalculation hypothesis easy to detect. Check each exit/save stage, not just the eventual game result.
5. **New from blank:** create a complete team and inspect defaults before player entry, after entry, after verification and after final save. Compare with copied-template behavior.
6. **Trade / imported player / full roster replacement:** distinguish moving one record from rebuilding a header. Test six-team replacement using the historical workflow only after the smaller cases explain each stage.
7. **Controls:** exit without saving, save unchanged, then load in the game and break `$0D2A/$0D41/$0D67`. Verify the on-disk bytes actually become the divisors used while that team bats.

Write watches should use the **actual editor header pointer**, not assume headers always live at `$6900/$6D00` in the GM program. Log all writes to its `header+28…32`, the source values and writing instructions. A before/after equality alone shows preservation for that operation; it does not prove no temporary rewrite occurred.

## 5. Quantified consequences using the existing calculator

### Fixed assumptions and profiles

All comparisons below call the unchanged `MATCHUP_CALCULATOR.py`. The same batter and pitcher are used across C/Y/T; only the five header bytes change. Offense0, normal defense, default tail thresholds243/247/253 and raw extra numerator0 are fixed. IP below is explicitly the **stored whole IP**; the PCA case uses the previous example's floor/nearest scenario174, not a newly claimed original fractional-IP conversion. Counts are exact over the 256 initial-byte values. Percentages assume a uniform sampled byte, not a validated live POKEY distribution.

| Profile | Batter AB,H,BB,SO,2B,3B,HR | Pitcher stored IP,H,BB,SO | Status |
|---|---|---|---|
| A Carew/Feller | 616,239,69,55,38,16,14 | 250,239,95,111 | Saved original-game fixture |
| B supplied PCA | 626,175,83,187,31,8,45 | 174,154,37,174 | User-supplied example, IP scenario explicit |
| C contact | 600,180,40,60,30,5,10 | 200,180,50,150 | Synthetic representative profile |
| D high-K power | 550,145,100,200,25,2,40 | 180,130,45,220 | Synthetic; exposes individual-weight wrap |
| E weak/high-K | 450,90,20,130,15,2,5 | 200,150,40,200 | Synthetic; exposes cumulative wrap |
| F high-rate stress | Same batter as B | 200,300,100,220 | Synthetic stress test, not an actual player/typical forecast |

### Six requested initial families

Each cell gives **integer count out of256, followed by percentage**. An initial single-family selection is not a guaranteed final single, and this table must not be called a completed-PA batting line.

| Profile | Baseline | Walk family | K family | Single family | Double family | Triple family | HR family |
|---|---|---:|---:|---:|---:|---:|---:|
| A | C | 25 / 9.765625% | 14 / 5.468750% | 62 / 24.218750% | 13 / 5.078125% | 4 / 1.562500% | 4 / 1.562500% |
| A | Y | 16 / 6.250000% | 28 / 10.937500% | 54 / 21.093750% | 12 / 4.687500% | 4 / 1.562500% | 4 / 1.562500% |
| A | T | 28 / 10.937500% | 13 / 5.078125% | 70 / 27.343750% | 15 / 5.859375% | 5 / 1.953125% | 5 / 1.953125% |
| B | C | 16 / 6.250000% | 109 / 42.578125% | 29 / 11.328125% | 10 / 3.906250% | 1 / 0.390625% | 14 / 5.468750% |
| B | Y | 10 / 3.906250% | 219 / 85.546875% | 25 / 9.765625% | 0 / 0.000000% | 0 / 0.000000% | 0 / 0.000000% |
| B | T | 18 / 7.031250% | 101 / 39.453125% | 33 / 12.890625% | 11 / 4.296875% | 2 / 0.781250% | 16 / 6.250000% |
| C | C | 10 / 3.906250% | 29 / 11.328125% | 50 / 19.531250% | 11 / 4.296875% | 1 / 0.390625% | 3 / 1.171875% |
| C | Y | 6 / 2.343750% | 59 / 23.046875% | 44 / 17.187500% | 9 / 3.515625% | 1 / 0.390625% | 3 / 1.171875% |
| C | T | 12 / 4.687500% | 27 / 10.546875% | 57 / 22.265625% | 12 / 4.687500% | 2 / 0.781250% | 4 / 1.562500% |
| D | C | 26 / 10.156250% | 154 / 60.156250% | 22 / 8.593750% | 6 / 2.343750% | 0 / 0.000000% | 11 / 4.296875% |
| D | Y | 16 / 6.250000% | 56 / 21.875000% | 19 / 7.421875% | 5 / 1.953125% | 0 / 0.000000% | 9 / 3.515625% |
| D | T | 29 / 11.328125% | 143 / 55.859375% | 25 / 9.765625% | 7 / 2.734375% | 0 / 0.000000% | 12 / 4.687500% |
| E | C | 5 / 1.953125% | 114 / 44.531250% | 28 / 10.937500% | 6 / 2.343750% | 0 / 0.000000% | 1 / 0.390625% |
| E | Y | 3 / 1.171875% | 229 / 89.453125% | 0 / 0.000000% | 0 / 0.000000% | 0 / 0.000000% | 0 / 0.000000% |
| E | T | 5 / 1.953125% | 105 / 41.015625% | 32 / 12.500000% | 7 / 2.734375% | 0 / 0.000000% | 1 / 0.390625% |
| F | C | 39 / 15.234375% | 119 / 46.484375% | 49 / 19.140625% | 17 / 6.640625% | 3 / 1.171875% | 24 / 9.375000% |
| F | Y | 25 / 9.765625% | 0 / 0.000000% | 28 / 10.937500% | 15 / 5.859375% | 2 / 0.781250% | 21 / 8.203125% |
| F | T | 43 / 16.796875% | 111 / 43.359375% | 56 / 21.875000% | 19 / 7.421875% | 3 / 1.171875% | 0 / 0.000000% |

Exact changes relative to the common configuration, in byte counts (multiply each by .390625 for percentage-point change):

| Profile | Baseline vs C | Delta counts [BB,K,1B,2B,3B,HR] |
|---|---|---|
| A | Y | -9,+14,-8,-1,+0,+0 |
| A | T | +3,-1,+8,+2,+1,+1 |
| B | Y | -6,+110,-4,-10,-1,-14 |
| B | T | +2,-8,+4,+1,+1,+2 |
| C | Y | -4,+30,-6,-2,+0,+0 |
| C | T | +2,-2,+7,+1,+1,+1 |
| D | Y | -10,-98,-3,-1,+0,-2 |
| D | T | +3,-11,+3,+1,+0,+1 |
| E | Y | -2,+115,-28,-6,+0,-1 |
| E | T | +0,-9,+4,+1,+0,+0 |
| F | Y | -14,-119,-21,-2,-1,-3 |
| F | T | +4,-8,+7,+2,+0,-24 |

### Arithmetic hazards demonstrated

* **B/Y cumulative wrap:** adjusted weights are `[10,219,25,8,1,12]`; cutpoints become `[10,229,254,6,7,19,243,247,253]`. The early single threshold already covers R<254, so later double/triple/HR families receive no new byte values. This is not “the hitter lost his power statistics”; it is threshold overflow.
* **D/Y individual-product wrap:** starting SO weight78, FK=1024. Unrestricted product scaling gives312; the original retains a byte, `312 mod256=56`. Common SO count154 therefore becomes only56 under Y, despite Y's much larger K factor. The cumulative thresholds remain monotone here. **The calculator's current cumulative-warning field alone does not flag every individual-weight wrap**; this report explicitly inspects unmasked product results without changing that program.
* **E/Y cumulative wrap:** SO occupies229 byte values, then adding the single weight wraps the third cutpoint to1. No hit family can exceed the already reached threshold232, so all four initial hit-family counts are zero. Mixed-out, interruption/error and groundball still receive remaining uncovered values.
* **F/C tail overlap without a cumulative addition wrap:** the sixth threshold is251, above fixed tail243/247. Mixed-out and HBP/interruption receive no values and the error-family count falls to2. “No cumulative wrap” alone is not enough for ordinary category-difference reasoning.
* **F/T cumulative wrap:** the sixth threshold wraps to4, eliminating the initial HR family despite a positive HR weight. The total initial hit-family count becomes78 versus93 for C, reversing the ordinary hit-family advantage of T in this stress case.

Initial hit-family totals in the last bullet are not final hit rates. Error, out and continuation family masses can also change when early thresholds overlap the tail; their usual default counts must not be forced back into the results.

### Which backdrop helps the batting team?

For fixed positive pitcher raw ratios, before wrapping, H and BB factor order is `T >= C >= Y`, whereas K factor order is `T <= C <= Y`, allowing equality from quantization. If all individual weights fit, cumulative cutpoints remain monotone, and the sixth threshold stays below the tail, **T weakly favors the offense in the six requested initial categories**: at least as many walks and each hit family, and no more strikeouts. C is intermediate; Y is least favorable on those measures.

That is a mathematical ordering of these local categories, not a universal theorem about runs or win probability. It can fail as a global outcome ranking when integer products/cumulative thresholds wrap, as profiles D/F demonstrate. Later fielding, runner state, double plays and interruptions also prevent a universal final-PA or winning-value claim. There is no single safe percentage to describe a template's “advantage” across all players.

## 6. Could a custom six-team league use one common backdrop?

### What would be standardized

A common five-byte header value for every custom team would remove this **particular team-header difference**. At fixed player records/action/tails, every team would then apply the same normalization math while batting. Player skills would still differ; this is not equalizing player statistics.

Using C=`00 F6 5E 9D 14` preserves the setting already present on23/25 teams. That makes it a useful **Classic-common candidate**, not proof it is ideal for a modern league or incapable of overflow. Choosing another shared configuration would be a deliberate league rule and should be evaluated on actual custom rosters first.

### Exact locations on this ATR — identification only, no patch performed

For every physical team block, the five locations are `block_offset+$1C…+$20`, as listed in section1. On the original image, only two blocks differ from C:

| Team | Baseline byte positions | Existing bytes | Candidate common bytes |
|---|---|---|---|
| 1927 Yankees, sector497 | ATR `$00F82C…$00F830` | `01 18 94 4E 0A` | `00 F6 5E 9D 14` |
| 1968 Tigers, sector545 | ATR `$01102C…$011030` | `00 D9 55 A9 13` | `00 F6 5E 9D 14` |

These are two five-byte fields, but **nine individual bytes differ**: all five Yankees bytes and four Tigers bytes (its leading00 already matches). Standardizing the whole original25-team image would require no changes to the other23 fields. A six-team GM image may have different sector allocation, templates and directory pointers; these original offsets must not be reused blindly.

### Does that require patching the original game?

No original game-code patch is inherently needed: these are loaded **roster data**, not instructions. Possible future routes are an editor that explicitly writes/initializes these fields, a verified common-template workflow, or a separate roster-data conversion tool operating on a derivative team/GM disk. The editor's support is currently unknown. A runtime memory adjustment would not prove persistence in the saved roster.

Directly editing this original ATR would alter historical evidence and is **not proposed or performed here**. Even if the final approach edits a derivative ATR's data, it need not change engine instructions. It would still need correct image/catalog mapping and save/load validation. We have not certified arbitrary free space, checksum behavior or persistence rules of an unavailable GM disk.

Copying a common-baseline template and replacing its roster is a **conditional option only**: it becomes defensible after the preservation experiment shows the editor leaves those bytes intact. At present that workflow might preserve them, recalculate them, or reset them. Existing Python typing scripts are not sufficient to choose among those possibilities.

### Other behavior that may change

* Initial walk, K and hit weights change as above. Subsequent events, scores and computer-management triggers can change **indirectly** because different initial families occur. Header normalization is not merely cosmetic.
* In the usual nonwrapping region, changed six-weight sums change mixed-out mass while the last tail bands retain their local sizes. With wrapping/tail overlap, even that simplification fails.
* Corners/infield singles coefficients51/102 stay the same, but they multiply a changed singles weight; later positioning effects remain. Standardizing baselines does not standardize away defensive strategy.
* Recovered surprise/sacrifice bunt gates bypass `$0C00` and use speed/command/defense, so no direct baseline coefficient enters those gates. A league with different swing-away normalization can still change bunt-versus-swing strategy value.
* The fifth byte changes FX; no use of FX by the ordinary six-weight selector was found. No numeric change to player speed, fielding, handedness, pitcher ID or fatigue counters is implied by changing only these five bytes. A complete global indirect-reference proof is not claimed.
* Header defaults used for pitcher batting are at offsets33…40, adjacent but outside these five bytes. A future conversion must preserve those and all names/lineup/catalog data. Merely having a shared backdrop does not make modern seasons safe from high-K byte overflow.

## 7. Research status and next decision

**Confirmed:** all25 identities/locations; special configurations belong to1927 Yankees and1968 Tigers; the three raw patterns; batting-side use; no simple pooled/unweighted staff match; exact conditional initial-family comparisons; concrete overflow counterexamples; scripts do not explicitly manage baseline bytes.

**Supported hypothesis:** a common supplied/reference configuration with exceptional historical-roster settings. This does not establish the author, reference population, intended era calibration or unmodified-master provenance.

**Unknown:** the original baseline generator; whether the GM editor preserves/recalculates/defaults on create, copy, player edit, name/year edit and save; whether an undocumented direct-edit interface exists; the baseline bytes actually inherited by the historical six-team leagues.

The next informative step is the targeted GM copy/edit/save comparison, preferably starting from an actual historical custom-league image. Until then, no baseline should be changed simply because a team name suggests a particular era, and no six-team league should be declared unequal solely from its visible team names.

## 8. Reproducibility and validation

Tables were computed by reading the preserved ATR and invoking the existing calculator; no original application or Atari instruction was executed. Catalog pointers were checked against physical block locations rather than assuming slot numbers stay contiguous across the blank slot. Every table pattern was compared with its actual stored header bytes.

The arithmetic comparisons are static byte-domain calculations. They are not emulator observations, game simulations, or estimates derived from historical win-expectancy changes. No external historical league totals were silently substituted for missing baseline provenance. External material is limited to the publisher's documented GM workflow and its limits, linked above.

Validation: all 25 catalog pointers, block locations, raw baseline patterns and pitching-staff totals/means were checked; all 18 profile/configuration initial-count vectors sum to 256, and the reported wrap counterexamples were asserted explicitly. All 12 existing matchup-calculator tests pass. SHA-256 fingerprints of 68 existing source/report/index/data files, including the ATR, remain identical; names/sizes/modification-time fingerprints of all 1,430 pre-existing files also match. The only addition is BASELINE_INVESTIGATION.md. The research index and all prior reports/modules/tests were deliberately left unchanged.

### Appendix: exact thresholds, factors and all ten counts

These supply the remaining outcome families and make the percentage tables independently checkable. Class order is `[BB,SO,single,double,triple,HR,mixed_out,HBP_or_interruption,error,groundball]`. Factors are `[FH,FB,FK,FX]`. As elsewhere, these are **initial families**, not complete plate appearances.

| Profile/setting | Factors FH,FB,FK,FX | Adjusted six weights | Nine cutpoints | Ten initial counts |
|---|---|---|---|---|
| A/C | 253,264,184,0 | 25,14,62,13,4,4 | 25,39,101,114,118,122,243,247,253 | 25,14,62,13,4,4,121,4,6,3 |
| A/Y | 223,167,370,0 | 16,28,54,12,4,4 | 16,44,98,110,114,118,243,247,253 | 16,28,54,12,4,4,125,4,6,3 |
| A/T | 287,292,171,0 | 28,13,70,15,5,5 | 28,41,111,126,131,136,243,247,253 | 28,13,70,15,5,5,107,4,6,3 |
| B/C | 235,147,417,0 | 16,109,29,10,1,14 | 16,125,154,164,165,179,243,247,253 | 16,109,29,10,1,14,64,4,6,3 |
| B/Y | 206,93,840,0 | 10,219,25,8,1,12 | 10,229,254,6,7,19,243,247,253 | 10,219,25,0,0,0,0,0,0,2 |
| B/T | 266,162,387,0 | 18,101,33,11,2,16 | 18,119,152,163,165,181,243,247,253 | 18,101,33,11,2,16,62,4,6,3 |
| C/C | 239,174,313,0 | 10,29,50,11,1,3 | 10,39,89,100,101,104,243,247,253 | 10,29,50,11,1,3,139,4,6,3 |
| C/Y | 210,110,630,0 | 6,59,44,9,1,3 | 6,65,109,118,119,122,243,247,253 | 6,59,44,9,1,3,121,4,6,3 |
| C/T | 271,192,290,0 | 12,27,57,12,2,4 | 12,39,96,108,110,114,243,247,253 | 12,27,57,12,2,4,129,4,6,3 |
| D/C | 191,174,508,0 | 26,154,22,6,0,11 | 26,180,202,208,208,219,243,247,253 | 26,154,22,6,0,11,24,4,6,3 |
| D/Y | 168,110,1024,0 | 16,56,19,5,0,9 | 16,72,91,96,96,105,243,247,253 | 16,56,19,5,0,9,138,4,6,3 |
| D/T | 217,192,472,0 | 29,143,25,7,0,12 | 29,172,197,204,204,216,243,247,253 | 29,143,25,7,0,12,27,4,6,3 |
| E/C | 199,138,417,0 | 5,114,28,6,0,1 | 5,119,147,153,153,154,243,247,253 | 5,114,28,6,0,1,89,4,6,3 |
| E/Y | 175,88,840,0 | 3,229,25,5,0,1 | 3,232,1,6,6,7,243,247,253 | 3,229,0,0,0,0,11,4,6,3 |
| E/T | 226,153,387,0 | 5,105,32,7,0,1 | 5,110,142,149,149,150,243,247,253 | 5,105,32,7,0,1,93,4,6,3 |
| F/C | 399,348,458,0 | 39,119,49,17,3,24 | 39,158,207,224,227,251,243,247,253 | 39,119,49,17,3,24,0,0,2,3 |
| F/Y | 351,221,922,0 | 25,241,43,15,2,21 | 25,10,53,68,70,91,243,247,253 | 25,0,28,15,2,21,152,4,6,3 |
| F/T | 453,385,425,0 | 43,111,56,19,3,28 | 43,154,210,229,232,4,243,247,253 | 43,111,56,19,3,0,11,4,6,3 |