(WIP) David Haywood's Homepage - 模擬器

2013.03.18

"Mostly Lacking Cool"

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

http://mamedev.emulab.it/haze/pics2013/sh96_1x.png
http://mamedev.emulab.it/haze/pics2013/sh96_2x.png
http://mamedev.emulab.it/haze/pics2013/sh96_3.png
http://mamedev.emulab.it/haze/pics2013/sh96_6.png
http://mamedev.emulab.it/haze/pics2013/sh96_7.png
http://mamedev.emulab.it/haze/pics2013/sh96_8.png
(Screenshots of the much improved Stadium Hero ’96, the 6th shot shows
a likely remaining clip window issue)
______________________________________________________________________________

來源：http://mamedev.emulab.it/haze/2013/03/18/mostly-lacking-cool/

--

ポーラステーション
http://perryt0517.wordpress.com/

--