Quoted from Rarehero:ColorDMD colorizes on the fly because it has to...it's intercepting the DMD data. I imagine if MMr is colorized, the monochrome frames will be colored within the software...there would be no more monochrome or a need to color on the fly...it would just be outputting the images as they reside in the code at that point.
You can't do it that way, because the game is running emulated code. The hypervisor can only look at the data in the virtual display ram and colorize from there - you can't add color to the original ROM code. They cannot screen-capture every possible frame that would ever be displayed and try to map to redrawn color frames, because far too much of the display is dynamic and cannot simply be mapped.
EDIT - replied to rare before seeing the ensuing discussion. I don't want to say it's impossible, but it's definitely more complicated than many people think. I remember even the colorDMD guys saying MM was harder than the games they did prior due to a new almost sprite-based system for some animations. There are dynamic frames generated where the colorize routine may have to determine whether a particular pixel is part of the score or part of the background or part of an animated object moving on the screen. Now run that routine for every one of 128x32 pixels, then 15 times a second, and pile that on top of the hypervisor functionality...
The game runs on the beagleboard. That board already has to emulate the original CPU and translate the input/output to the new hardware system. The existing frames are tearing, which could be an indication the CPU is occasionally lagging when emulating the existing display. Asking it to perform the colorization process as well ... will it be able to? Remember, colorDMD has its own biult-in processor handling everything, separately of the MM CPU.