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 scenery with the cartridge's own machines rewritten in Python, and the characters with the game frame written from its 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.
INIT (0x407B) hooks H.KEYI with a jp 0x402C, clears the one kilobyte of RAM and then sits forever on the jr $ at 0x40A9. Everything else happens in the hook, once per frame: sound, controls and the current scene. The lock at 0xE005 counts overlapping interrupts and serves the one that came in meanwhile without going back through the stack.
The characters and obstacles are not placed by the scenery set-up: the game places them frame by frame. tools/pista.py rewrites that frame from the cartridge's tables -moving objects 0x549B, poses 0x5116, start-ups 0x6161- and against 43 openMSX dumps it gives 0 bytes different.
(0xE052) says which act it is, 0 to 4, and the cartridge dispatches on it through four tables stuck right behind their calls: set-up (0x5FEF), start (0x60B6), frame (0x4C93) and the moving objects table (0x549B). Three of them were labelled off by one in the listing; the RAM measured at the start of each act gave it away.
0x458F reads through DE and writes through HL, the other way round from what it looks like. That is why 0x7477 copies 0x2AC0 over 0x2BB0, overlapping, and the horse act's scenery repeats by itself.
The ld hl,(0xE002) brings the flags in L and the frame counter in H. The bit 5,h is not the number of players: it flips the mask between drawing and erasing every 32 frames.
The VDP does not draw the fifth sprite crossing a line. On the trapeze six of them cross lines 48 to 52, and two are dropped. With that limit the drawing matches the emulator's picture in 49,152 dots out of 49,152.
Under each picture is where it comes from and what is on it.