Data East’s short-lived MLC system was probably designed to provide direct competition to the NeoGeo system, but arriving in 1995 after the NeoGeo already had a strong foothold in the market it was never going to do well.
The Flyers are hilariously bad, and highly inaccurate, talking about the competition as a 15-bit 68000 with the rest of the competition specs seemingly for a fictional system and then the actual ones for the MLC not really much more grounded in reality.
Either way, it was a ‘cartridge’ based system, not multi-game like the NeoGeo, but slightly closer to CPS2 in the way it works with a lot of the logic (including the game CPU) in the cartridge along with all the ROMs (in reality the motherboard only provides the sound & video circuits etc.) Interestingly Avengers in the Galactic Storm made use of an SH2 CPU while the others instead used Data East’s encrypted 156 ARM chip, I doubt the reasons for this decision will ever be clear. The encrypted ARM obviously provided extra security, but already existed when AGS shipped so the choice to use a completely different CPU lacking any security whatsoever was an odd one, not that it mattered, I’ve never heard of any of the cartridges being bootlegged at all.
Having previously worked with the NeoGeo for titles like Street Hoop and Karnov’s Revenge the influence on the video system design here is quite obvious. The MLC forgoes the usual Data East tilemaps + basic sprites combination and favors exclusive use of a much higher capacity zooming sprite chip. While the NeoGeo retained a simple tilemap for the text overlays this system lacks that too.
I guess the idea was to keep it simple, you no longer have to worry about multiple layers and priorities and how they’ll interact with each other, you simply have a spritelist drawn in order, one thing to learn, one thing to program.
One problem with an all-sprite system is that you lose the ability to do line effects, which makes the ‘3D capable’ points in the flyer even more laughable. There are ways around this, and Data East were certainly no strange to them. Karnov’s Revenge works around the limitation by using the scanline programmable interrupt timer on the NeoGeo to trigger interrupts on specific scanlines and change the content of spriteram during the active display, picking a moment after the processing for one line is complete, the very moment before the next one gets drawn in order to do the ‘rowscroll’ effects on the floor. It’s a common technique, and Data East had made use of it many times before, even on hardware where it probably wasn’t strictly necessary.
It’s no surprise then that the MLC system is capable of similar, it does however appear that the hardware designers shot themselves in the foot with this. You see the MLC spriteram looks (at least from what we’ve been able to gather) to be buffered. That is, the content of spriteram is copied to a private buffer for use by sprite chip when rendering. With this in mind it becomes impossible to change the positional values of sprites in realtime because the changes you make will only get seen next time the RAM buffer is updated, once per frame.
To compensate for this the hardware employs what seems to be a very kludgy workaround. Next to the scanline IRQ register are a set of 3 other registers with each one having additional x-scroll, y-scroll and x-zoom values, and any sprite can be told to use these ‘global’ values. While the spritelist can’t be updated in realtime these values can be, allowing for a similar effect to be achieved although limiting the possibilities in significant ways.
That’s probably enough background information anyway. You might be wondering how this actually relates to the games running on the system, and why I’m talking about it here? Well as it turns out at least 2 of the games on the platform make use of these features. Avengers in the Galactic Storm uses them to do a similar rowscroll effect on the floors (it’s very noticeably missing on some levels) and unfortunately I haven’t been able to make any progress with that one. The other game using it, extensively, is Stadium Hero ’96, a game that has never worked in MAME.
Implementing this was tricker than it might sound. The MLC renderer in MAME had been written in a way optimized for object rendering, in other words, rendering the entire content of the sprite list once per frame, drawing the full width and height of each object (within screen limits) at that point. That’s fine as long as you’re not trying to do realtime scanline effects. If you want to do realtime scanline effects you need to instead look to see if a sprite covers the current scanline and if it does render only the appropriate span of the sprite for that scanline, a rather different approach.
MAME provides a ‘cliprect’ system, clipping rectangles that you can use to limit the area of the screen that things get drawn to. For basic cases (assuming the rendering code acknowledges the cliprects at all) this can be used for to implement such effects, by simply passing a cliprect covering a more limited area of the screen (the scanlines you want to render) to your rendering code, pixels outside that area get cut off and the desired effect can be achieved. That’s essentially what the ‘partial updates’ you see in MAME sometimes is, it’s telling you that the screen is being rendered in multiple calls (currently MAME can’t go below scanline granularity in this with using core code, so it will never be greater than the number of scanlines)
The problem is once you start to get large sprite-lists and zooming sprites the ‘pass a cliprect’ solution starts to become highly inefficient. Forcing the MLC games to do 240 partial updates caused performance to drop to around 10% speed, from significantly higher. This is essentially because the point at which pixels got clipped out using this technique was the point at which they should have been rendered. Forcing 240 partial updates was actually near enough telling the code to render the entire screen 240 times, but only actually use one scanline of it from each call. As you can imagine, that’s not exactly efficient, it means your entire renderer is 240 times slower.
The key to solving this problem is early rejection. By rejecting sprites at the earliest opportunity, and calculating which line of a sprite correlates to the current scanline then you can save a huge amount of work, you’re no longer looping over every line and every pixel of a sprite only for it to not even show up in the final display because it doesn’t exist on the current scanline, nor are you even looping over extra lines of a visible sprite, you’re jumping straight to drawing the actual visible pixels for only the sprites visible on the current line. It’s obvious, but it needs more intelligent coding than the brute force approach.
Doing this in MAME is nothing new, plenty of systems have their own custom renderers for exactly this reason, the NeoGeo being one of them, but it still requires work, it requires reworking of code designed / optimized for one scenario to be rewritten in a way optimized for another instead. Doing this for MLC had been on my todo list for a long time, knowing there were games in need of it, and so it was good to finally get it done over the last couple of days.
The fun didn’t end there tho, there are a number of other poorly understood things about MLC, first of all there was the whole issue of how the global registers get selected, and also an issue of how they got used. The first couple of attempts at getting Stadium Hero ’96 didn’t really look much better than before, there were line effects going on, but they were completely wrong. A day or two of studying the values allowed that to be fixed however.
Stadium Hero ’96 also threw up another problem. The MLC has it’s own set of clipping windows (not MAME ones!) 8 of them to be precise. These can be used to clip sprites to certain screen areas, a feature used by Skull Fang to show the boss views when the boss if off-screen. Unfortunately the MAME code only had logic to select between 4 of them, and Stadium Hero uses all 8. I found what appears to be the higher select bit, fixing the garbage covering the game screen and allowing for the windows showing your guys on the bases to render correctly most of the time. I say most of the time because there are still problems to track down, the logic used by Skull Fang is contrived, and it’s possible Stadium Hero ’96 isn’t agreeing with it.
Actually all the bits used to enable clipping windows, raster effects and raster selection are slightly odd. I don’t think the current implementation is correct at all, and it’s possible setting one bit changes how other bits behave, but test cases are so limited it’s hard to know. One thing appears to be clear, if raster effects are to ever work in Avengers in Galactic Storm then the ‘enable use’ bit we currently use can’t be right (the sprites that need to be affected don’t have it set) but furthermore there is a problem that AGS isn’t even writing valid per-scanline values from what I can see, it sets a single set of global registers (and not even the ones our current select bits would reference) once per frame. I can only guess there are multiple issues, from it not liking the reads from one of the many unknown ‘vblank??’ handlers in the driver to some further way in which the select bits and enable bits can be changed.
Stadium Hero ’96 also had (has?) a further problem, protection. In addition to the encrypted ARM the game makes use of ‘146’ protection chip, although it only writes to it on startup, and then reads it many times during the actual gameplay / attract sequence. Kale chipped in and did some work here, correcting the return value for one of the protection reads and allowing the Title Screen to show, and gameplay rules / scoring to be fixed. It appears most of the checks are quite dumb, and probably really do return fixed values given the lack of writes after startup.
So anyway, the net result of all of this is that for u2 Stadium Hero ’96 will be massively improved, I’m hesitant to call it working because there could still be lingering protection issues, and there are almost certainly bugs caused by the clipping windows at least but it at least looks a lot better now, and can actually be played.
There are other outstanding bugs with the MLC driver I haven’t managed to fix, the regression with Hoops / Hoops ’96 test mode is a very annoying one, Mametesters shows it broke a long time ago, and it remains ‘broken’ If it wasn’t for us having default eeproms you wouldn’t actually be able to run the games at all at present because it’s still impossible to enter test mode, and without being able to enter test mode you can’t actually initialize the eeprom (or change any game settings) I’d actually be curious to find out the exact change that caused this failure because it’s most likely to point us at a fix. This is definitely a platform where some good hardware tests wouldn’t go amiss tho, even basic things like the zoom precision is questionable right now (and with my new code there is a very visible gap in the Stadium Hero ’96 logo zooming)
After that wall of text, here are some screenshots of Stadium Hero ’96
(Screenshots of the much improved Stadium Hero ’96, the 6th shot shows a likely remaining clip window issue)