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.
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)
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.
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.
.. more in progress
News Source: Here
This comment has been removed by the author.
ReplyDelete