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

2013.03.14

"LaLa is Missing"

Sometimes drivers sit untouched for a while, not because they’re
especially difficult to make progress on, but simply because they’ve
ended up at the back of the queue while other potentially more
interesting targets are looked at. PoPo Bear is one of those drivers.

BMC aren’t known for their regular arcade games, everything else we’ve
been with the BMC brand on it has been a poorly disguised gambling /
redemption game and the compact PCB design of PoPo Bear along with the
4 banks of dipswitches (above 2 is unusual for anything other than
Gambling games) I actually expected it to be another gambling game,
and issued a warning that if we were to buy one of two PCBs available
at the time it should probably be the other one because it looked more
interesting. In the end both were purchased, because even if it had
turned out to be a gambling game the current policy means it would end
up supported anyway and the prices were reasonable.

The original Dumping Union MAME World post from when it was purchased
can be found here and the following PCB picture was supplied as part
of that.

http://mamedev.emulab.it/haze/pics2013/popobear_small.jpg
(The compact PoPo Bear PCB could easily have been a gambling game like
most BMC titles)

Upon initial inspection of the ROMs they did indeed contain strings like
‘Hopper’ and ‘Payout’ which seemed to confirm that it was, like
everything else, a gambling game, even if it didn’t look it from the
screenshots we’d seen (but screenshots can always be deceptive, see
games like Lucky Boom) Kale did some work on the driver back then and
got it running the game, but the video implementation was left
significantly incomplete (wrong res, bad sprites, bad scroll, bad
enables etc.) and the game remained only borderline playable due to the
glitches.

The interesting thing at this point was that it actually appeared I was
wrong, all the aforementioned strings in the ROM simply appear to be
leftovers from the codebase of another game probably developed to run
on the same platform, this game was clearly a hybrid of the classic
‘Snake’ game lots of people grew up with on their phones (and we should
really get around to emulating!) with elements of Bomberman thrown in
for good measure, an actual proper game with no signs of any kind of
Payout system or rigged gameplay.

Anyway, I decided to pick the driver up again the other day, clean it
up, and fix up as many of the video bugs as I could.

I believe BMC to be either Chinese, or possibly Taiwanese like IGS, and
(original) games and hardware from that region tend to lend themselves
to some curious hardware designs in terms. This hardware is no exception
to that, and while the CPU is a bog standard 68000 the video hardware
has some oddities.

First on the list is the tilemap handling. The majority of arcade games
have the video hardware access the graphic ROMs directly. On this board
they’re memory mapped, don’t decode as tiles and the CPU has to copy
them into memory before use. Not too unusual, but then you have a further
peculiarity with the system. Despite there being a clear tilemap layout
in RAM addressing tiles by number the data doesn’t actually get copied
across as tiles, but instead as a linear 512 pixel wide bitmap. The
hardware transparently converts the addressing into tiles for drawing,
but the CPU can draw directly to the screen directly more easily than
if it had to pack everything into tiles. The game doesn’t really take
advantage of that, but it’s something you don’t see on every piece of
arcade hardware, and is probably used to more of it’s full potential
by some other undiscovered game on the platform.

I spent a fair bit of the time cleaning up and understanding this as
part of the work I did on the driver, to hopefully make it clearer that
the hardware really does use tiles for the tilemaps, even if the way
they get stored is odd.

The tilemap chip supports 4 scrolling layers, of 128×64 8×8 tiles, and
can turn on row-select and line-scroll effects for at least 2 of them.
It uses 8bpp tiles from a single palette of 256 colours outputting a
resolution of 486 ×240, not bad for a generic looking PCB.

The sprites similarly require their data to be copied into RAM first, a
different area of RAM to the tile graphics. Otherwise they’re more
conventional, not tile based, but must be multiples of 8 in size. The
width and height are tied together, so sprites can be 8×8, 16×16, 32×
32 or 64×64 pixels in size. They have their own set of 256 colours,
although the palette addressing is messy, the sprite pixel data is
8-bit, which would give you access to all the colours anyway, but there
seem to be at least another 4 bits to further convolute the addressing.
That isn’t fully understood because the game makes minimal use of it.
The priority system is a sprite to sprite one, with 16 levels of
priority, again unusual, for the majority of systems the sprite to
sprite priority is determined by the list order, with only the sprite to
tilemap priority being determined by the sprite priority bits. It’s
unclear if there is any level of sprite to tilemap control or if
priorities are fixed.

Anyway I fixed most of that as well, the primarly problem was with the
sizes, and the observation that all things should be equal width/height
soon made things look a lot better.

With those fixes the game is now playable, truth be told Kale had already
done most of the work needed back when he looked at it initially and it
just needed some fresh eyes to clean things up and better understand a
couple of aspects of it.

There are still some things not quite right, I think the hardware has
some kind of timers and readback of the timer registers because right
now a number of elements in the intro animate at turbo speeds, and the
music playback is also quite broken. I’m hoping that now I’ve fixed
the graphical side of thing Kale will revisit those, but in what time
frame remains to be seen.

The game sports a year 2000 copyright, I guess when you take that into
consideration it is incredibly dated looking for the time period
involved, but it’s what you come to expect from some of the games
developed by relatively unknown parties outside of the Japan. It also
coincides with when IGS were doing well making me think this attempt to
jump into the games market might have been inspired by that.

Anyway, here are some screenshots from the current emulation of the game,
with the various fixes I’ve made applied over Kale’s initial work from
last year

http://mamedev.emulab.it/haze/pics2013/popo_new_1.png
http://mamedev.emulab.it/haze/pics2013/popo_new_2.png
http://mamedev.emulab.it/haze/pics2013/popo_new_3.png
http://mamedev.emulab.it/haze/pics2013/popo_new_4.png
http://mamedev.emulab.it/haze/pics2013/popo_new_5.png
http://mamedev.emulab.it/haze/pics2013/popo_new_6.png
http://mamedev.emulab.it/haze/pics2013/popo_new_7.png
http://mamedev.emulab.it/haze/pics2013/popo_new_8.png
http://mamedev.emulab.it/haze/pics2013/popo_new_9.png
http://mamedev.emulab.it/haze/pics2013/popo_new_10.png
http://mamedev.emulab.it/haze/pics2013/popo_new_11.png
http://mamedev.emulab.it/haze/pics2013/popo_new_12.png
http://mamedev.emulab.it/haze/pics2013/popo_new_13.png
http://mamedev.emulab.it/haze/pics2013/popo_new_14.png
http://mamedev.emulab.it/haze/pics2013/popo_new_15.png
http://mamedev.emulab.it/haze/pics2013/popo_new_16.png
http://mamedev.emulab.it/haze/pics2013/popo_new_17.png
http://mamedev.emulab.it/haze/pics2013/popo_new_18.png
http://mamedev.emulab.it/haze/pics2013/popo_new_19.png
http://mamedev.emulab.it/haze/pics2013/popo_new_20.png
(Current Emulation shots from PoPo Bear)
______________________________________________________________________________

來源：http://mamedev.emulab.it/haze/

--

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

--