There is not one screenshot here. The pictures are drawn by repeating what the cartridge does: the same bytes go up to video memory at the same addresses, and the river and road rows are built with its own lane engine. Everything else —the listing and the numbers— comes from the binary and is reproducible with make.
They are not similar: they are the same code. The 163 bytes at 0x4111–0x41B3 in this cartridge and those at 0x4160–0x4202 in Time Pilot (RC-703) match byte for byte except for three, and two of those three are the low byte of a relocated pointer: 0x41A1 here and 0x41F0 there, exactly the 0x4F offset between the two copies.
The third is the only one that says something different: PSG register 7, the mixer. It is 0xA8 here and 0x98 there, which means the noise is on channel B in Frogger and on channel C in Time Pilot. In both cartridges the player sits right before INIT.
When the game is left alone, no random generator moves the frog: a list is read. It lives at 0x584F and it is fifteen bytes, one per move, in the same format as the controls:
00 08 01 01 01 01 01 08 01 01 01 01 08 00 01
That is: wait, right, five times up, right, four up, right, wait and one more up. The pointer goes back to the start whenever a stage is built, and since only its low byte is incremented, the list cannot cross a page.
The stage is picked with (stage-1) mod 5 over a five-word table… but the second and third entries point to the same place, 0x5CCD. Stages 2 and 3 use exactly the same river and road layout.
The only thing that separates them are two touch-ups 0x5493 makes on the third slot: the first object in the top row becomes a crocodile, and the second object of row 15 gets the «last» bit set, which leaves that row with two objects instead of three.
Diving is not a property of being a turtle: it is a bit. The fourth byte of the record holds a counter, and it only animates if bit 7 is set. When the stage is built, 0x5489 sets it at exactly two addresses: 0xE0C3 and 0xE0EB, that is the first group of row 5 and the second of row 9.
And they do not start alike: one begins at 0x80 and the other at 0x8A, so that they never dive together. From stage 6 on, 0x54D6 adds a third one (0xE0E7, counter at 0x8F).
There are four comparisons against the stage number in the whole cartridge, and no more: on 2 eight river objects go up two types (0x54A8), on 3 the frog you have to rescue shows up (0x506A), on 6 two lanes move one step per turn and the third diving turtle is added (0x54C9), and on 11 row 7 is left with a single object (0x54DB).
From there on the only thing that changes is which of the four layouts comes up, and that cycles every five stages. Stage 11, stage 47 and stage 99 play exactly the same.
And there is no ending: on stage 100 the counter goes back to 1 (0x53F5) and the scoreboard number, which is BCD, goes back to 01. No banner, no music, no screen.
The five homes sit at columns 4, 8, 12, 16 and 20, and each has its own bit in 0xE080. When the frog enters one, 0x528F checks that bit; if it was already set, there is no warning and no bounce: jp 0x5305, which is the death routine.
The MSX1 can only show four sprites on a line, so Frogger keeps them for the frog and the crocodile. Everything else is characters.
To move them smoothly, 0x473C stores four versions of every drawing in video memory, shifted 0, 2, 4 and 6 pixels: it rolls the whole pattern set two bits and lets the bits that fall off enter the character next door. Each object's position is kept in quarters of a character, and its low two bits pick the version.
SCREEN 2 splits patterns and colours into three 2 KB thirds, and the game wants them identical. Instead of three copies, 0x471A does one of 4095 bytes with the destination 2 KB ahead of the source: past the first third it is already reading what it has just written, so the second propagates into the third on its own.
In SCREEN 2 colour goes per pattern line, not per cell: two cells holding the same character cannot have different colours. So INIT uploads the letter set twice, at characters 0x98 and 0xD8 (0x4235 and 0x4240 repeat bytes the previous block had already sent).
The colour table loaded right after gives cyan to the first and white to the second: that is why the title menu comes out cyan and the in-game scoreboard white.
At 0x57F7 there are six bytes of perfectly formed code: the one-byte-index version of the table lookup at 0x57FF, returning in B the Ath byte of a table embedded behind the call and jumping past the 0xFF that closes it.
It works. But no instruction in the cartridge calls it: all four calls go to the two-byte version.
Each of these pictures is the cartridge replayed outside it: the characters go up the way the ROM sends them, with their colours, and the rows are built with the same lane engine. Under each caption is the address it comes from.
