Aaron Giles maintains a blog regarding various MAME fiddlings he does, and his newest post contains a tidbit on UMK3... and possibility of (eventually) fixing the palette bug...
--flux
Here's the direct link for those interested: http://aarongiles.com/?p=209"Finally, I took a look at the Mortal Kombat 3 bug where the palette on the character selection screen or the intro screen is all wrong. This turns out to be a cycle counting issue. The code that builds up these screens sets up a queue of palette entries to change. Each character that is displayed has its own palette, so if there are a lot of characters, there are a lot of palette changes to queue. But palettes are only changed in the VBLANK routine, so it’s possible for the queue to get too full, depending on how quickly the game accumulates entries in the queue. When it hits its limit, it fortunately doesn’t corrupt memory (good), but instead throws everything out of the queue (bad), leaving you with a bunch of missed palette changes.
This queueing behavior is why the problem gets worse if you have unlocked a bunch of characters, because more characters are displayed on the screen, and thus more palettes get queued.
The reason this worked on a real machine is probably due to the TMS34010’s cache. We don’t emulate the cache behavior in MAME; rather, we act like all instructions are in the cache, and count the minimum number of cycles for each instruction. This is generally the right approach, but in this case it works against us because we allow the code that sets up the palette queues to run too fast, overflowing the queues before the VBLANK comes in and clears everything out.
So for now, we’ll just have to live with it. The 34010 cache is described in gory detail in the manual, so it is possible to simulate it eventually. But for now, a little color glitch isn’t going to hurt anything. "
--flux