What the cartridge draws
Under each picture is where it comes from and what is on it.
Not one capture here. Every picture is drawn from the bytes of the ROM: the screens and the bakery with the cartridge's own set-up chain rewritten in Python, and the baker and the raccoons with their pose and step tables, checked against openMSX down to zero bytes. The listing and the numbers are reproducible with make, and reassembling gives back the ROM byte for byte.
The listing called carts what the baker shoots and what costs the baker a life. Drawn from the ROM they are the raccoons: two sprites in a row, the second sixteen pixels to the right, in grey, yellow and red (0x51B2).
There is one bakery, the 92 columns at 0x7604, but the stage set-up picks its graphics blocks with (0xE051): green machines on stages 1, 2, 4, 6... and blue ones on 3, 5, 7... Checked against openMSX down to 0 bytes.
The 64 sprite patterns are loaded by 0x70D6: three compressed blocks and, on top, their mirror images -each byte with its bits reversed and the two halves swapped-, so every figure faces both ways without being stored twice.
While in the menu, the controller reading does not come from the controller: it comes from 80 bytes recorded at 0x6001, which the cartridge serves as if someone were pressing.
The clock at 0x4614 counts seconds in BCD up to 60 and adds a minute; on minute eight it raises the end-of-stage flag. Neither of its two batch siblings has it.
0x60B0 fills the 768 cells with indices 0, 1, 2... to see every pattern at once and stays on a jr $. Nothing calls it: it is the developer's tool, left behind in the ROM.
Under each picture is where it comes from and what is on it.