(WIP) David Haywood's Homepage - 模擬器
By Margaret
at 2013-07-22T11:54
at 2013-07-22T11:54
Table of Contents
2013.07.20
"Reopening The History Books"
I feel it’s time again for another catch-up of what’s been going on,
including the things I’ve been working on.
A couple of days ago Charles MacDonald posted some notes on Data
East’s 146 protection chip, a chip found on a number of Data East
boards sometimes used for strong protection systems, other times
simply as an I/O interface.
The board he was studying was Super Shanghai Dragon’s Eye, one of the
few games using the chip where the original set in MAME was still
non-functional (only a bootleg version has ever worked)
After a handful of emails back and forth, and a couple of
misunderstandings concerning the formatting of the data I’d been
presented with I managed to use the information provided by Charles (as
well as a test program he’d written to check his results on the original
PCB) to get the original Super Shanghai set booting in MAME. It’s
possible there are a few graphical errors due to differences between the
original hardware and the bootleg, but it is now functional and playable.
This is the Japanese version of the game, the bootleg is an English
version.
http://mamedev.emulab.it/haze/pics2013/sshangha_original_1.png
http://mamedev.emulab.it/haze/pics2013/sshangha_original_2.png
http://mamedev.emulab.it/haze/pics2013/sshangha_original_3.png
http://mamedev.emulab.it/haze/pics2013/sshangha_original_4.png
http://mamedev.emulab.it/haze/pics2013/sshangha_original_5.png
http://mamedev.emulab.it/haze/pics2013/sshangha_original_6.png
http://mamedev.emulab.it/haze/pics2013/sshangha_original_7.png
http://mamedev.emulab.it/haze/pics2013/sshangha_original_8.png
http://mamedev.emulab.it/haze/pics2013/sshangha_original_9.png
http://mamedev.emulab.it/haze/pics2013/sshangha_original_10.png
The difference between the data Charles recovered from the protection
device and previous attempts to emulate the chip is that Charles
provided an exhaustive set of data and analysis covering every possible
value and address the chip covers, far beyond what Shanghai actually
uses. Naturally I wanted to make use of this data to improve / replace
the other per-game simulations of the chip found in MAME.
Strangely the first thing I noticed is that the behavior was the same as
the ’60′ and ’66′ chips, used by Edward Randy and Mutant Fighter
respectively. The new code actually dropped straight in as a replacement,
and the games were still happy with the results. Interestingly it
appears there was at least one minor oversight with the older Edward
Randy protection simulation with some writes being ignored because they
looked like bugs in the code, when in reality the protection device does
see them, and even responds to them.
What was more of a mystery however was the way I couldn’t relate the
information we had to a number of other games that were known to use
146, of note, Funky Jet, Nitro Ball and Fighters History. Some notes in
the code (and board tracing from Smitdogg) did confirm that Fighters
History had some extra address line swapping leading up to the chip,
but even with that applied the addresses didn’t match up. I did however
find that applying the same information to Funky Jet gave a correct
mapping, and allowed me to get rid of another old per-game simulation.
A bit of research later (and some heavy work in refactoring and
re-ordering the existing Fighters History protection simulation) and I
quickly saw that with the address bits in a consistent order between
games the missing element for Fighters History was an extra XOR applied
to the address lines at some point during the protection operation. It
isn’t clear how or why this occurs (there is no obvious configuration
byte attached to it happening) but it solved the remaining mystery of
how to hook up Fighters History, Nitro Ball, Robocop 2 and Lemmings to
the new implementation.
Fighters History was the main one of interest for me however because I
know the game has NEVER worked properly in MAME. It has been tagged as
‘Unemulated Protection’ for many years now, and the reason it is tagged
like that is because the protection tables for the last 2 bosses (Clown
and Karnov) had never been extracted, leading to the game crashing /
glitching when those characters performed certain moves (the game has a
lot of character specific protection)
After hooking up the new simulation and playing through the game is
seems those issues are now fixed thanks to the quality and completeness
of the data supplied by Charles. This pleases me because the game is an
important part of history due to being the subject of a legal battle
with Capcom who considered it nothing but a rip-off of Street Fighter
2 (Capcom lost)
http://mamedev.emulab.it/haze/pics2013/fhist_1.png
http://mamedev.emulab.it/haze/pics2013/fhist_2.png
http://mamedev.emulab.it/haze/pics2013/fhist_3.png
http://mamedev.emulab.it/haze/pics2013/fhist_4.png
http://mamedev.emulab.it/haze/pics2013/fhist_5.png
http://mamedev.emulab.it/haze/pics2013/fhist_6.png
http://mamedev.emulab.it/haze/pics2013/fhist_7.png
http://mamedev.emulab.it/haze/pics2013/fhist_8.png
Note, my current feeling is that the ’104′ chip (Rohga, Double Wings
etc.) uses different internal tables, and isn’t simply a simple
remapping of this, so those games are unlikely to benefit for now.
These Data East chips had the potential to be very nasty, so it’s good
to have them understood much better now :-)
I revisited another old issue too in the past couple of days. While
casually reading a Hardcore Gaming 101 article on Cabal I noticed it
mentioned that the Level 2 boss on Hard Times (a hack of Blood Bros)
was glitched. While this is mentioned in the source I’d never put much
time into figuring out why, so I decided it was something I should look
at. In the end it was an easy fix, that level needs a wider tilemap with
a custom page layout (it isn’t clear how wide the tilemaps are, there’s
a lot more RAM than it seems to need) I can’t fix the sound on the game
because it’s driven by an undumped (protected) PIC, but at least the
graphical issue is cleared up now.
http://mamedev.emulab.it/haze/pics2013/hardtimes_fix_1.png
http://mamedev.emulab.it/haze/pics2013/hardtimes_fix_2.png
http://mamedev.emulab.it/haze/pics2013/hardtimes_fix_3.png
http://mamedev.emulab.it/haze/pics2013/hardtimes_fix_4.png
I’ve also been very busy trying to clean up, refactor and bring together
a lot of the Konami video code as preparation for working on the Tasman
titles (with a view to maybe using any information found to further
improve the GX emulation, because they’re very similar platforms) This
is on the back of a lot of work done by Osso to modernize many of the
Taito and Konami chip implementations and is work that is many years
overdue.
Moving on to work other people have been doing another previously unknown
classic era game turned up, this one called ‘Desert Dan’ and claiming
to be by a company called ‘Video Optics’ This rare game was found by
Alberto Grego (who was previously involved with finding Planet Probe and
Grasspin)
It’s a simple vertical scroller with several different sections, a
regular desert scene, a further desert scene where movement is much
harder (looks like ice with the current palette), a cave section where
movement is more restricted due to rocks at the side, a darkened cave
section where you can’t see the internal walls, and a river full of
crocodiles. The PROM isn’t dumped yet, so the colours are wrong, the
driver currently uses the colour PROM from The Pit which is the closest
thing in terms of hardware to this. This one was added to MAME by
Mariusz Wojcieszek with some help from hap. Some (unused?) tiles seem
to contain ‘BMC’ text, although I doubt it is related to the BMC
company we know today.
http://mamedev.emulab.it/haze/pics2013/desert_dan_1.png
http://mamedev.emulab.it/haze/pics2013/desert_dan_2.png
http://mamedev.emulab.it/haze/pics2013/desert_dan_3.png
http://mamedev.emulab.it/haze/pics2013/desert_dan_4.png
http://mamedev.emulab.it/haze/pics2013/desert_dan_5.png
http://mamedev.emulab.it/haze/pics2013/desert_dan_6.png
http://mamedev.emulab.it/haze/pics2013/desert_dan_7.png
http://mamedev.emulab.it/haze/pics2013/desert_dan_8.png
http://mamedev.emulab.it/haze/pics2013/desert_dan_9.png
http://mamedev.emulab.it/haze/pics2013/desert_dan_10.png
http://mamedev.emulab.it/haze/pics2013/desert_dan_11.png
http://mamedev.emulab.it/haze/pics2013/desert_dan_12.png
.. more in progress.
______________________________________________________________________________
來源：http://mamedev.emulab.it/haze/
--
SNKP正在為新作（拳皇&侍魂）招募開發人才
http://www.snkplaymore.co.jp/employment/
--
ポーラステーション
http://perryt0517.wordpress.com/
--
"Reopening The History Books"
I feel it’s time again for another catch-up of what’s been going on,
including the things I’ve been working on.
A couple of days ago Charles MacDonald posted some notes on Data
East’s 146 protection chip, a chip found on a number of Data East
boards sometimes used for strong protection systems, other times
simply as an I/O interface.
The board he was studying was Super Shanghai Dragon’s Eye, one of the
few games using the chip where the original set in MAME was still
non-functional (only a bootleg version has ever worked)
After a handful of emails back and forth, and a couple of
misunderstandings concerning the formatting of the data I’d been
presented with I managed to use the information provided by Charles (as
well as a test program he’d written to check his results on the original
PCB) to get the original Super Shanghai set booting in MAME. It’s
possible there are a few graphical errors due to differences between the
original hardware and the bootleg, but it is now functional and playable.
This is the Japanese version of the game, the bootleg is an English
version.
http://mamedev.emulab.it/haze/pics2013/sshangha_original_1.png
The difference between the data Charles recovered from the protection
device and previous attempts to emulate the chip is that Charles
provided an exhaustive set of data and analysis covering every possible
value and address the chip covers, far beyond what Shanghai actually
uses. Naturally I wanted to make use of this data to improve / replace
the other per-game simulations of the chip found in MAME.
Strangely the first thing I noticed is that the behavior was the same as
the ’60′ and ’66′ chips, used by Edward Randy and Mutant Fighter
respectively. The new code actually dropped straight in as a replacement,
and the games were still happy with the results. Interestingly it
appears there was at least one minor oversight with the older Edward
Randy protection simulation with some writes being ignored because they
looked like bugs in the code, when in reality the protection device does
see them, and even responds to them.
What was more of a mystery however was the way I couldn’t relate the
information we had to a number of other games that were known to use
146, of note, Funky Jet, Nitro Ball and Fighters History. Some notes in
the code (and board tracing from Smitdogg) did confirm that Fighters
History had some extra address line swapping leading up to the chip,
but even with that applied the addresses didn’t match up. I did however
find that applying the same information to Funky Jet gave a correct
mapping, and allowed me to get rid of another old per-game simulation.
A bit of research later (and some heavy work in refactoring and
re-ordering the existing Fighters History protection simulation) and I
quickly saw that with the address bits in a consistent order between
games the missing element for Fighters History was an extra XOR applied
to the address lines at some point during the protection operation. It
isn’t clear how or why this occurs (there is no obvious configuration
byte attached to it happening) but it solved the remaining mystery of
how to hook up Fighters History, Nitro Ball, Robocop 2 and Lemmings to
the new implementation.
Fighters History was the main one of interest for me however because I
know the game has NEVER worked properly in MAME. It has been tagged as
‘Unemulated Protection’ for many years now, and the reason it is tagged
like that is because the protection tables for the last 2 bosses (Clown
and Karnov) had never been extracted, leading to the game crashing /
glitching when those characters performed certain moves (the game has a
lot of character specific protection)
After hooking up the new simulation and playing through the game is
seems those issues are now fixed thanks to the quality and completeness
of the data supplied by Charles. This pleases me because the game is an
important part of history due to being the subject of a legal battle
with Capcom who considered it nothing but a rip-off of Street Fighter
2 (Capcom lost)
http://mamedev.emulab.it/haze/pics2013/fhist_1.png
Note, my current feeling is that the ’104′ chip (Rohga, Double Wings
etc.) uses different internal tables, and isn’t simply a simple
remapping of this, so those games are unlikely to benefit for now.
These Data East chips had the potential to be very nasty, so it’s good
to have them understood much better now :-)
I revisited another old issue too in the past couple of days. While
casually reading a Hardcore Gaming 101 article on Cabal I noticed it
mentioned that the Level 2 boss on Hard Times (a hack of Blood Bros)
was glitched. While this is mentioned in the source I’d never put much
time into figuring out why, so I decided it was something I should look
at. In the end it was an easy fix, that level needs a wider tilemap with
a custom page layout (it isn’t clear how wide the tilemaps are, there’s
a lot more RAM than it seems to need) I can’t fix the sound on the game
because it’s driven by an undumped (protected) PIC, but at least the
graphical issue is cleared up now.
http://mamedev.emulab.it/haze/pics2013/hardtimes_fix_1.png
I’ve also been very busy trying to clean up, refactor and bring together
a lot of the Konami video code as preparation for working on the Tasman
titles (with a view to maybe using any information found to further
improve the GX emulation, because they’re very similar platforms) This
is on the back of a lot of work done by Osso to modernize many of the
Taito and Konami chip implementations and is work that is many years
overdue.
Moving on to work other people have been doing another previously unknown
classic era game turned up, this one called ‘Desert Dan’ and claiming
to be by a company called ‘Video Optics’ This rare game was found by
Alberto Grego (who was previously involved with finding Planet Probe and
Grasspin)
It’s a simple vertical scroller with several different sections, a
regular desert scene, a further desert scene where movement is much
harder (looks like ice with the current palette), a cave section where
movement is more restricted due to rocks at the side, a darkened cave
section where you can’t see the internal walls, and a river full of
crocodiles. The PROM isn’t dumped yet, so the colours are wrong, the
driver currently uses the colour PROM from The Pit which is the closest
thing in terms of hardware to this. This one was added to MAME by
Mariusz Wojcieszek with some help from hap. Some (unused?) tiles seem
to contain ‘BMC’ text, although I doubt it is related to the BMC
company we know today.
http://mamedev.emulab.it/haze/pics2013/desert_dan_1.png
.. more in progress.
______________________________________________________________________________
來源：http://mamedev.emulab.it/haze/
--
SNKP正在為新作（拳皇&侍魂）招募開發人才
http://www.snkplaymore.co.jp/employment/
--
ポーラステーション
http://perryt0517.wordpress.com/
--
Tags:
模擬器
All Comments
Related Posts
用ppsspp玩槍彈2日版
By Blanche
at 2013-07-20T23:19
at 2013-07-20T23:19
DQ10 電腦用手把
By Brianna
at 2013-07-20T21:46
at 2013-07-20T21:46
聖劍傳說３－序－光之動盪
By Madame
at 2013-07-20T13:48
at 2013-07-20T13:48
Gearboy v0.7
By Gary
at 2013-07-19T23:24
at 2013-07-19T23:24
聖劍傳說３－序－月之咆哮
By Enid
at 2013-07-19T23:08
at 2013-07-19T23:08