Re: [新聞] (WIP) David Haywood's Homepage
2012.10.16
The ‘Almost’ Crowd
There are a couple of drivers I’ve been working on lately which are
*almost* right, but at the same time still have a long way to go.
Starting with Black Touch ’96. BT96 is a Korean Beat ‘em Up and a
driver I started a long time ago. The video system is a bit funky,
so so was the focus of my attention. Essentially there are sprites,
and tilemaps, but the confusing thing is that the sprites aren’t
really sprites at all, infact they just appear to be 4 additional
tilemaps with positional strips, however they must be rendered as 4
distinct layers in order to get the priority correct (in terms of
list order the background sprites end up sandwiched between two of
areas containing character objects) There’s also RAM for another 4
potential layers, but it never seems to be used beyond the initial
RAM clear / initialization (and I’m guessing it doesn’t work on
real hardware)
I think this video setup, along with some shoddy programming caused
issues for the developers of the game, it seems to have a number of
bugs, including one where if you attack the enemy with your kick
attacks at the top of the playfield you can cause them to fall into,
and start walking through the background, complete with momentary
priority glitches because the rest of the code really isn’t sure
what’s going on. There are also various bogus ram writes to unmapped
areas, I’m assuming these are just bad / buggy code, maybe they
should end up going to a RAM mirror, but that isn’t clear. Amusingly
the Seibu games act in a similar way with bad protection emulation (
incorrect collision boxes and movement calculation code causing enemies
to walk off-screen) but these tasks aren’t handled by any kind of
protection in this game.
Anyway, before the last ‘u’ update I made some improvements to the
sprite system incorporating the new findings and also improved the
tile layer which is equally deceptive. Tile RAM is written as 16-bit,
but the upper 8-bits really don’t seem to matter, the upper bits of
the tile number are instead controlled via a bank register, I’ve
added support for that, fixing (I hope) the text on the story screens.
The sound is handled by a PIC ‘MCU’, which thankfully we have a dump
of because it was one of the old games which actually got decapped,
and for which the MCU serves a useful purpose. The bad news is I’m
entirely unfamiliar with the PIC series, and haven’t managed to hook
it up, I did put in a request to the rest of the devs but haven’t
heard as much as a peep back over it, so I’m guessing there are no
devs familiar with it either.
So why isn’t it working? Well the major remaining issue is that the
\timer doesn’t decrease, I wonder if the PIC is involved in this as
well as sound, but it could probably do with some tracing of the 68k
code to find out if there isn’t a more simple explanation. Obviously
the sound could do with hooking up too. You can play it, I’ve played
through a few levels (and you even get a Bikini girl between each
level like so many Korean titles..) but without the timer I can’t
really consider it to be working.
As a game, it’s terrible, the screenshots below make it look better
than it is.
http://mamedev.emulab.it/haze/pics2012/bt96_1.png
The second game I’ve been looking at, albeit indirectly is Tecmo’s
World Cup 94.
I say indirectly because I’m in the middle of doing some work to all
the Video System drivers, as I believe I mentioned in the 3-on-3 Dunk
Madness post below. I’ve identified 3 main Video System sprite systems,
2 of which are used on a wide variety of games. Like many early things
in MAME which haven’t been touched for a while every game had it’s own
implementation of the sprite chip based around what that game, and only
the game needed, needless to say most of these implementations were
incomplete.
By unifying the code I’ve not only managed to fix the problems with
3-on-3 Dunk Madness player sprites (still some tilemap priority bugs
I need to fix there however) but also Tecmo World Cup ’94 has seen
benefits from this in two ways.
First of all the players now correctly get rendered in the attract
mode, previously the code was actually ignoring half the Sprite RAM
because Grand Striker (the game the driver was originally done for)
doesn’t use it and we were masking too many bits of the index. The
code was also using the wrong sprite enable bit, which was leading
to random stray shadows and injured players getting stuck on the
screen, that’s also been fixed. Furthermore because the zooming
code for sprites has been unified with the other implementations
which are apparently more accurate, you no longer get sprites
breaking up when they zoom to full-size. There are still some
flickering sprites when you score and at the end of matches, but
that might be an original game issue.
What’s wrong here? Protection. We currently have a protection
simulation, but it’s imperfect. The game always thinks it’s the
first match, the attract sequences probably aren’t in the right
order (it displays ‘INSERT COIN’ over the high-score table erasing
some parts of the text tilemap, which looks glitchy) and I’m not
sure the ‘EVENT’ handling logic in the game works because it seems
to do nothing if you compare it with the NeoGeo Tecmo World Cup ’96
released 2 years layer.
The protection is annoying because the original hardware MCU performs
some kind of checksum on the main code, which means you can’t modify
it, however, a ROM banking trick similar to what was used on DDP2 might
get around this issue, by manually controlling the upper address pin on
a double sized ROM it might be possible to get our own code running,
and at least explore the jump addresses returned by the device during
attract / gameplay and determine if the protection glitches we have
are due to wrong jump addresses or something more (on V-Goal Soccer,
which is the same hardware, it appears to control various counters
directly instead)
There’s also the issue of the zooming tilemap. Tecmo World Cup ’94
makes light use of it, but you can still tell the implementation is
wrong (things don’t align correctly in the various zoom states).
Grand Striker and VGoal Soccer make more extensive use of it, and
with those you can really tell how bad it is, and no matter how many
times I’ve looked at it I can’t make any real sense of it, it feels
like something must be non-linear at some point in the algorithm and
even if I adapt the code to get the ‘Zoom into Stadium’part of VGoal
Soccer looking better the game is still broken. (I’d love some original
videos of V-Goal Soccer for that sequence, but it never seems to show
up) Due to these things I’ll probably demote Grand Striker to
non-working too, the pitch has never been right, and what I thought at
the time would be a quick fix from Imperfect Graphics to ‘fine’ turned
out to not be a quick fix at all, essentially meaning the game has never
worked.
http://mamedev.emulab.it/haze/pics2012/twc94_1.png
Anyway, I just wanted to highlight that work does happen in MAME even
if it doesn’t directly lead to more games being tagged as working in
the immediate future; every little bit of progress does however bring
us closer to ‘working’ and sometimes, as demonstrated here *real*
refactoring and merging of old code can sometimes help.
In other news Luca, as expected got Sparkman going which means all the
dumped SunA games now work.
______________________________________________________________________________
來源：http://mamedev.emulab.it/haze/2012/10/15/the-almost-crowd/
--
另外，dump小組取得了Puzzli 2（PGM）：
We got a Puzzli 2 PGM cart (1999). The Puzzli 2 game in mame currently
is a "super" version that came out a couple of years later (2001).
http://smitdogg.mameworld.info/pics/puzzli2.jpg
來源：http://www.mameworld.info/ubbthreads/showflat.php?Number=297569
--
ポーラステーション
http://perryt0517.wordpress.com/
--
※ 發信站: 批踢踢實業坊(ptt.cc)
◆ From: 118.168.25.126
討論串 (同標題文章)
以下文章回應了本文：
完整討論串 (本文為第 9 之 78 篇)：
Emulator 近期熱門文章
PTT遊戲區 即時熱門文章
13
28