Hi there, Derek Andrews here, original programmer of Voltmace's Munch & Crunch and Leapfrog. I just wanted to reply to a few points raised above.
The Rev A mystery on Leapfrog: Not a biggie! I probably didn't add this to Munch & Crunch simply because it didn't occur to me at the time. I was probably just happy to have finished the job I was hired to do and lived up to Voltmace's expectations; this was all learn on the job and solve problems myself. When it came to Leapfrog they were keen to stop other companies from simply copying the ROM, hence the company name in the introduction and on the bottom row of trucks. The copyright block was just another line of security and the revision identifier would have made for a quick way of identify a rom if we ever needed to make changes or bug fixes. But as far as I recall, and this was 35 years ago, there was never any revB. I used other nasty tricks in the code to discourage re-engineering such as initialising an index register with a byte of data from within an opcode rather than using a "load immediate".
Although I don't understand how these emulators operate, I can say that getting Leapfrog to display was a challenge due to the reprogramming of all the duplicate sprites. I had no fancy emulators or debuggers. As best as I remember, the development system was a proprietary Z80 based CP/M system with a simple text editor and assembler (maybe a disassembler too as I recall looking at printouts of earlier games) and a couple of 5¼-inch floppy discs. Debugging generally involved setting special bits of code to perform a visible or audible operation, such as display a number in the score digits, or changing the screen colour to see where in the display a certain piece of code was running.
I have just recently disassembled Leapfrog and am currently documenting it and trying to understand how it operates. So far the most likely thing I have found that could be breaking the emulator is the way in which the logs are displayed. Each log is the top byte (or two) of a sprite displayed at maximum size. A simple delay counter is used to determine when to collapse the size of the logs to the smallest possible and to make them invisible. It then loads the top two bytes of the lily shape, sets their position and waits for the log objects to finish displaying before programming the size of the sprites for the lillies and the last few bytes of their shape.
It is far from a ideal and a total fudge. Because of the way that the vertical position of the duplicate sprites is set in the PVI as an offset, rather than an absolute vertical coordinate, if the emulator doesn't like having the size of the logs changed part way through displaying them, then everything below them will fall apart.