2015.12.14
年末疯狂更新w
"No longer utter Pollux"
The Dooyong developed shooters are some of the more original Korean efforts
of the 1990s, while other companies were simply bootlegging hardware ideas
and code and hacking them into new looking games, Dooyong actually created
their own games and used their own hardware designs.
The quality in general was fairly average, but they’re not terrible to play.
The emulation of them still had some bugs too, each game uses a slightly
different mapping (same basic ideas, but all the ports moved around, slight
changes etc.) which means sometimes bad assumptions get made, or things get
missed. One game in the driver that had always had issues was Pollux with
visible problems even on the title screen, and a number of MameTesters bugs
relating to it.
We knew from earlier work on Flying Tiger that the hardware had some palette
banking, it just hadn’t been hooked up on Pollux.
I spent a bit of time hooking it up, but was initially a little confused, we
knew that Pollux was missing a palette cycle effect on the title, but none of
the colours in any of the palette banks were cycling. That actually turned
out to be a simple case of a missing vblank flag. The 2nd palette bank
uploaded by the game is for the most part a darker copy of the first,
although it was quickly obvious that the title screen was meant to be using
that darker copy and not the one that it was using before, the darker copy is
where the palette colours were cycling, and also where the correct colours
were for several other title screen elements rather than entirely just darker
versions like the rest of the time the game is running.
Now, when the palette ‘banking’ was hooked up to Flying Tiger we didn’t
actually treat it as banking, we treated it as some ‘ram write protecetion’
meaning the bank bit was being used more like a RAM write protect flag than
actual palette banking. This struck me as wrong, and a little more studying
of a reference video for Pollux gave further weight to my theory that the
hardware really did want to do real palette banking instead.
What I’d noticed is that in Pollux, when a bomb was released, the screen was
meant to show periodic brighter pulses for the duration of the bomb. What I
found out is that we’d actually been rendering the whole of Pollux with the
wrong palette, the brighter version, since it was first emulated. That
brighter palette was actually only meant to be used when you used a bomb,
that was the entire point in there being two palette banks, a simple and
quick way to turn the whole screen brighter / darker without having to write
a new palette during gameplay. This simple bankswitch on the palette actually
fits well with Dooyong’s general design of this hardware – leaving the CPU
as free as possible to just run the game logic, not be updating palette data
and tilemap data)
I implemented this, it turned out the selected palette bank for writing is
also always the visible one. As a result the game looks much darker now,
which greatly improves the contrast between backgrounds and sprites.
There was a MameTesters bug concerning the character portraits in the ending,
after fixing the above issues I checked and that was fixed too, not too
surprising.
Bad palettes
http://mamedev.emulab.it/haze/pics2015/pollux_bad.png
Good palettes
http://mamedev.emulab.it/haze/pics2015/pollux_good.png
Here’s a video from MAME with the fixes, it’s got cheats enabled, but
allows you to see all scenes in the game for reference.
https://www.youtube.com/watch?feature=player_embedded&v=wpjMsEAO-Vg
The Flying Tiger code was also updated with this new knowledge, although I don
’t know if anything has changed in it as a result. It’s possible some of
the other games in the driver should have this hooked up too, I plan on
checking that soon.
"The Value Of Videos"
One of the most important things we can do as a society is make videos of
things, take photos of things, and share them for the world to see, you never
quite know when what you’ve done might come in handy, or prove to be the
only remaining reference that something once existed, it continues to amaze
me how even things that were at one point popular are now difficult to find
any visible trace of now.
This is true of arcade games as much as anything else, and I Know when
looking at the fruit machine and other non-video games the situation is even
worse, sometimes not a single photo of a machine anywhere.
While looking at Mega System 1 it was noted in the source that the game P47
sets some other bits during the Jaleco logo, effect unknown. Luckily, in this
instance there was a video on YouTube of P47 booting up. It’s a terrible
quality video, but it still gave us an idea of what was missing.
https://www.youtube.com/watch?v=iyyE5OecGHI&feature=player_embedded
some kind of trail effect…
I poked around with the code a bit, and have attempted to implement this in
MAME.
https://www.youtube.com/watch?v=nKsfHSvP42c&feature=player_embedded
I don’t know if this is actually correct, at the point where they want the
trails to vanish they adjust a parameter, the original video isn’t really
clear enough to show how the trails are removed, so I’ve had to guess. If
anybody has a P47 PCB and can record a better quality video it would be
appreciated, the one on YouTube was more useful than the original poster
probably ever thought it would be, but not really good enough to say my
emulation is correct :-)
"Mirror Mirror"
Another long-standing problem with the Mega System 1 driver is the lack of
character movement in the attract modes of 64th Street and Chimera Beast. A
similar problem was fixed in Cybattler a long time ago by handling a mirror
address for main RAM, easily noticed due to unmapped reads/writes, but the
other two games weren’t making any unmapped reads or writes.
Today I decided to try a little experiment. I knew from the ‘nmk16.cpp’
hardware that sometimes the 68k is hooked up to RAM in a way that means the
byte write behavior is a little unusual. The standard way of handling byte
writes is to make sure only the byte of the word that is being written to
changes, leaving the other half of the word alone. Due to the way the 68k
works it’s also possible for that hookup to be slightly different, so that a
byte write alters the content of both bytes in the destination word,
mirroring the written byte in the other half.
Most games break if you implement things the latter way, they assume they can
write bytes without them corrupting the adjacent byte. I quickly changed
Megasystem 1 to use that method to see what happened, the result, a working
attract mode. I do wonder if this is part of a bigger picture, NMK and Jaleco
often worked together, there are Jaleco games in ‘nmk16.cpp’ and NMK
developed several of the titles for Jaleco’s Megasystem hardware too, it’s
possible some hardware ideas / designs were also being shared.
While only Chimera Beast and 64th Street show obvious improvements from this,
and both of those are ‘Megasystem 1 Type C’ hardware, I’ve hooked it up to
all hardware types (except D, but that’s very different and did cause the
game to crash) I’ve not noticed any real differences this way, most games don
’t make many byte writes, some avoid them entirely. St. Dragon makes an
unusually high number so it might be worth checking / verifying that nothing
has broken there with these changes, it is afterall possible that only one of
the board types has this design.
Here are some revised attract mode videos from the games. The 64th Street one
also shows the environment damage that was previously missing (Kale fixed it
last week) and the Chimera Beast one, to my surprise, shows the Mosaic
effect, it’s used ingame when you get grow.
https://www.youtube.com/watch?feature=player_embedded&v=kIOSoTHtBIc
https://www.youtube.com/watch?v=qhBjrqNTDm8&feature=player_embedded
"Somewhere Only Slightly Less Dangerous Than The Hands Of A Hoarder"
Following on from the post about the rare PV1000 game being dumped we have
saw another rare Japanese console / computer game dumped. This time it’s one
for the Tomy Pyuuta system, an early ’16-bit’ machine.
The Pyuuta games while not graphically spectacular or ambitious do seem to
offer some fast paced arcade-like gameplay, and this one is no exception.
The game in question is “Bermuda Triangle”
Despite the initial appearance (what looks to be a massively oversized ship
at the bottom of the screen) it has no connection with the much later arcade
title released by SNK. This is a fast and challenging wave based shoot /
dodge game.
This one was also rather costly, with most of it being paid for by MooglyGuy
this time around.
https://www.youtube.com/watch?v=XkkWiSVlsj0&feature=player_embedded
"Makeup On A Broken Man"
The Jaleco Megaystem 1 driver is broken to an almost shambolic level, nothing
really works as it should. This is mainly down to interrupt handling, timing,
sometimes subtle protections, and generally things not being understood well.
It did used to run ‘better’ but even back then it was held together with
hacks.
If you’re expecting this post to be about Ninja Kazan (Iga Ninjyutsuden)
being fixed, or the random sprite lag being fixed, or Takeda Shingen /
Shingen Samurai-Fighter crashes being fixed then stop reading now, they’re
not, I have no clue how to fix them without resorting to the hacks of old,
and I’d really rather not do that.
Kale did add a video RAM mirror allowing the background destruction to
function correctly in 64th Street (characters still don’t move during
attract tho) and so I decided that while fixing the bigger issues with the
driver simply wasn’t going to happen it was probably worth making some other
improvements for the time when that does happen.
It has been known since system11 acquired a PCB and made a video that there
was a graphical effect missing in Takeda Shingen, A Mametesters report was
created with 2 handy videos demonstrating the effect in Takeda Shingen and
the P-47 test mode.
This was a while back, and in the meantime the Final Burn Alpha devs emulated
the effect due to having more active devs on the MS1 driver than we have.
Since nobody else had done it yet, and it was easy enough, I ported the FBA
code that dink and iq_132 had written back into MAME; since the FBA code was
based on the MAME code in the first place this wasn’t too difficult.
The result can be seen in the vidoes below. Note, I’ve used the English
language set ‘Shingen Samurai-Fighter’ instead of the Japanese language set
system11 used for his video. Also note, the game really is broken beyond
being playable in MAME right now and crashes out at the start of level 2 even
in this test video. The effect can be seen after I pick up the power-up which
turns my sword into a flashing one, and then kill some enemies, with the
effect emulated they ‘pixelate’.
https://www.youtube.com/watch?v=8KoigziHzTo&feature=player_embedded
The P-47 test mode video demonstrates more clearly the settings for Mosaic
that are available. (same settings as Mametesters reference video have been
used, you can see the effect creates the same pixels in MAME)
https://www.youtube.com/watch?v=XsLulHtj_i0&feature=player_embedded
The effect is also used on the Jaleco logo in P47, after the spinning
squares, looks a bit ugly, but should be correct. There’s actually another
missing effect on the Jaleco logo here, the initial graphics should draw
sprite trails, we’re going to have to look into that one too, could once
again be the only place it gets used(!)
https://www.youtube.com/watch?v=nrmGrWeMASA&feature=player_embedded
Obviously these will be more interesting to you once the driver works
properly again (which like I say, I have no ETA on) but until then you might
appreciate seeing them anyway.
另外....
We got Zombie Revenge (Rev. A).
scans:
https://mega.nz/#!xgEHmBpJ!YLpadcW023G_z7FnVq6uSlb2xOsR-oHJ-ENKQtIIr94
http://www.mameworld.info/ubbthreads/userfiles/348047-zombies.png
来源 http://mamedev.emulab.it/haze/
http://www.mameworld.info/ubbthreads/showthreaded.php?Number=348047