There is not one illustration here. The screens are captures of the cartridge running in openMSX, taken by a script that only changes the event number the game itself uses as an index; the logo and the font sheet are drawn from the bytes of the ROM, by running in Python the same script interpreter the Z80 runs. The listing and the numbers come from the binary and are reproducible with make.
The first event's label has one R too many. It is not the capture, nor the emulator, nor the crop: it is written into the data. The label at 0x64B1 carries, behind its header byte, the glyph string
0A 01 01 00 0A 12 1E 1B 0E 16 0F 1B 1C 0A
and in the cartridge's font (0x6197) those indices read 110 HURDLERS . The capture only shows the result.
The four events are new, but only two of the motors are. The one for the 110 hurdles and the 1500 metres is the same that ran the previous cartridge's races. And the high jump one (0x6A2C) is the one that span the hammer over there: wind up, mark the angle with the button and let go.
What changes is what gets drawn, not the mechanism. What this cartridge really adds is 2,227 bytes, and its four largest runs are: places: the hurdle jump, the javelin motor, the high jump one and the drawing of the hurdle.
It is a comparison of columns at one specific instant. While the athlete jumps —pose 13, ten frames counted at 0x5A34— 0x5A5B compares his column with the column of the hurdle that is his. If when the jump ends they are less than eight columns apart, bit 4 of 0xE028 or 0xE029 gets set.
That bit is the fall: 0x5AA5 gives him pose 14, wipes his four speed bytes and gives him 0x14 frames of getting back up. Outside that instant, the hurdle and the athlete never touch.
A normal actor assembles its figure in the scratch area at 0xE230 and uploads it in one go. The hurdle does not fit in one row, so 0x7AB3 assembles the top half at 0xE230 and the bottom half at 0xE270, and uploads them separately, each to its own row of the name table.
It is the only actor in the cartridge that does this.
0x517B holds 00 12 93 / 00 96 72 / 00 02 36 / 00 03 31, which INIT copies to 0xE040. All four are real world records, but three had already been beaten by the time the cartridge reached the shops: Petranoff threw the javelin 99.72 in May 1983, Zhu Jianhua cleared 2.37 on 11 June, and Ovett took the 1500 down to 3:30.77 in September.
The one that holds is the oldest of them all, Nehemiah's 12.93 from 1981. The dates do not come from the cartridge: they are a cross-check against the published progressions. What comes from the cartridge is the figure.
The 51 glyphs at 0x6197 are in order: 0..9, the space, and then the alphabet from A to Y skipping Q, X and Z. With A at index 0x0B, P falls at 0x1A and the next one is already R.
And yet the Q exists: it sits at the end, at index 0x2C, outside the alphabet. The reason is the one word in the game that needs it, the scoreboard's QUALIFY, which at 0x611E is the string 2C 1E 0B 16 13 10 21.
This is the kind of thing you only see by drawing it: read as a block, the 51 glyphs are 408 bytes that all look alike. The sheet is further down.
86.9 % of this cartridge's comments are identical to one in the sibling: they came over with the shared code, and that puts them at the right address without changing what they say.
Two guards watch for it and both have caught something. repasa_el_porte.py checks that every cited address exists here: it found nine that did not. And cifras_portadas.py checks that, when the comment is identical, the instruction it annotates is too: it found the two comments at 0x4389, which said “32 sprites” when here the ld bc,01afeh loads 26.
At 0x4E64, right next to the eight VDP registers, there are three groups of four bytes shaped like rows of the sprite attribute table: 00 70 38 70 / 00 A0 38 70 / 00 F0 38 F0. No pointer in the ROM lands there and nobody reads them.
They are also in the previous cartridge, byte for byte identical and just as dead as here. Both inherited the same corpse.
Comparing the code with all sixteen-bit operands zeroed —so that a routine reassembled somewhere else still shows up— this cartridge shares 6,298 bytes, 63.8 %, with its sibling. With any other Konami MSX cartridge in this series it does not reach 2 %, and the longest common runs go from 21 to 42 bytes, against the 681 consecutive ones it shares with the sibling.
So the two Hyper Olympics are neither one framework nor the other. They are a third, and so far it has just two members. The full figures are in Findings.
Many cartridges from the house hide their RC-7xx catalogue number and the game's title in katakana at the end of the ROM, behind the filler; it was Manuel Pazos (@ManuelPazosMSX) who found that out.
Not here: the last two bytes are 0xFF and in front of them there is sound player code. It was checked with tools/marca_konami.py, which in the same run does find it in another cartridge from the house. The RC-711 comes from the catalogue, not from the binary.
Under each picture is where it comes from and what is on it.
pantalla_del_menu script and the four menu lines. Whichever you pick leaves a number from 1 to 4 in 0xE01B, and from that come the number of players and the controller
tools/graficos.py. You can see at a glance what the listing claims: there is no X and no Z, and the Q sits at the end, outside the alphabet. They are byte for byte the same 408 bytes as in the previous cartridge