If you’ve ever tried running the Sega ST-V game ‘Decathlete’ in MAME, you’ll have probably noticed it doesn’t look pretty.

Infact, aside from a few advertising banners in the 400 Meter race every single graphical element appears to be corrupt, meaning you can only really make out the shapes of the models and nothing more. Performance, you may have noticed is also really bad, significantly worse than almost all the other Sega ST-V titles, and surprising considering it’s “only” Saturn based hardware.

So why does Decathlete look so bad compared to all the other ST-V titles in every single MAME version up to and including 0.200? Simple, it had additional protection of a type that had not yet been figured out.

The ST-V cartridge for Decathlete contains a chip marked 315-5838, this chip provides encryption and compression related functions for the game, and figuring it out has been on my ToDo list for a long time, but the lack of decompressed and unencrypted data to study was a problem. To compound the problem the game data did not fully align with that found in the home port to the Sega Saturn either, so that wasn’t especially helpful as a source of unencrypted data to study.

Since Peter Wilhelmsen and Morten Shearman Kirkegaard have been working with me and producing hardware solutions to get data out of systems this seemed like a decent target for them to help with as a solution to easily transfer the decompressed and decrypted data from the game to a PC would provide significantly more data to study. I helped by providing information about the way the device works in terms of the SH2 program using it, where the encrypted data was, and my own observations on the tables uploaded (one of them clearly being a dictionary etc.) while Peter and Morten went to work producing a piece of hardware that slots in where the main program ROM would go on an ST-V cartridge, allowing us to sniff bus accesses to the ROM space as a way of transferring any data the SH2s can see back to the PC; the same technique that was used to transfer data back from the PGM2 unit and one we hope to use with some other systems like Casio Loopy in the future. This is much easier and more efficient than trying to display the data onscreen or anything like that.

With these tools and a list of source data provided they were able to extract all the decrypted and decompressed data from the game. I verified the extracted data by hacking up the protection device emulation to allowing MAME to read data directly from the files provided by Peter and Morten, and could confirm that for the files I hooked up the graphics appeared correctly in the game.

This was not the end of things however as supporting the data in decrypted form would not be true emulation, the real algorithm was needed and because this chip provided compression functions as well as the encryption there was an extra hurdle in the way (pun intended)

Anyway, Morten actually ended up making quite short work of this, using the tables uploaded by the game at runtime to figure out the nature of the compression, and writing a program that could recompress the extracted (fully decompressed / decrypted) data giving compressed (but not encrypted) blocks of data that were the same size as the compressed (but encrypted) blocks of data in the original game rom.

Since we now had the compressed, but unencrypted form of the compressed, encrypted data found in the ROM the encryption scheme could be studied too. We were hoping that it would be a simple 16-bit XOR that changed per-game, but instead, while still operating on 16-bits, it turned out to be more complex. Morten & Peter did figure out something that worked, and could correctly decrypt the data, but it wasn’t the cleanest of algorithms. Samuel Neves stepped in at this point and helped try to simplify the algorithm as much as possible, but even after that it was still a lot more complex than a simple XOR. This is actually quite frustrating, because while none are as high-profile as Decathlete there are a number of other games using the same chip that clearly have different encryption keys and we’ll likely need study those too rather than being able to work it out from the data.

Anyway, I was provided with sample code by Peter and Morten which worked outside of MAME, and so I took on the task of adapting said code for use in MAME, ensuring it worked in a ‘stream in, stream out’ ‘bytes on request’ mode as required for it to work in the way the SH2s talking to it expect it to work. By hooking it up in MAME the graphics are now correctly decrypted when running the game.

As you can see the emulation isn’t perfect yet, but none of those problems are protection related anymore, merely video emulation glitches. A lot of things are transparent that shouldn’t be transparent, and for reasons not investigated performance of this is actually worse than some of the Naomi titles, despite being on Saturn hardware, it runs at about 30% ingame without frameskip. It’s probably a worst-case scenario for a fair bit of the MAME Saturn emulation code, which will need revisiting at some point. Due to these issues I’ve actually left it as ‘NOT WORKING’ for now, despite being playable, but I don’t want people to get a bad first impression of the improvements. This might change if other people feel it should be marked as working.

I mentioned other games using the chip, and those are

Name Club v1 and v2 (chip has a 317-0229 sticker):
These use it for compressing and encrypting the higher resolution image data that gets sent to the printer (so you can’t actually see any onscreen problems as a result of the missing emulation, but if we were to hook up printer emulation it would print out garbage)

Print Club Winnie The Pooh Vol 2 / 3 (chip has a 317-0230 sticker):
Uses it to decrypt a block of startup code, so the machine doesn’t boot right now. Use beyond that unconfirmed, might just be that one block of data.

Print Club Love Love Vol 1 / 2 (chip has a 317-0231 sticker):
Same use as other PC Winnie The Pooh

Dead or Alive (on Model 2A)
Game uses it to decrypt a single string, which it then does a byte-for-byte comparison against the expected result. This has been hacked around for long before people even knew it had this complex decryption / compression chip, an absolute waste of silicon.

The other cases are potentially going to be annoying as they’ll require work to give us enough data to figure out the encryption part. Dead of Alive for example, we have the exact output string, and the compressed / encrypted data, and can even recompress the string, but there’s not enough data there to actually draw any conclusions about the encryption part.

Could there be more, maybe, there are a lot of random redemption games and a ton of undiscovered Print Club cartridges still out there.

Here’s a video of Decathlete running, note this was recorded with -aviwrite, so appears to be full speed even when the emulation was running much slower.

Content not available.
Please allow cookies by clicking Accept on the banner

Other slightly interesting notes about Decathlete, depending on the BIOS region it uses different compressed data for some elements. The US region is obvious, the Winners Don’t Use Drugs logo isn’t needed for other regions, so doesn’t get decompressed. What is less obvious is why it uses slightly different font data, I haven’t studied it much, but the difference in size isn’t enough to cover Japanese characters or the like. This actually confused me at first because Peter and Morten were working with an STV unit that had a European bios, and all my notes were based off running it in Japanese.

There have been a few things going on recently, but not had much time to post about them.

The most interesting thing is probably the discovery of an actual original title for the floppy disk based Magnet System arcade hardware rather than the unlicensed conversions of existing games that we’d seen previously.

The game in question is a vertical shmup called War Mission

Content not available.
Please allow cookies by clicking Accept on the banner

We’re quite lucky with this one as the disk was showing signs of failure, however the game only uses the first 24 or so tracks on the disk and only loads once on startup, unlike the other Magnet games which have pauses for loading between each scene. Later tracks, which do contain data, but presumably leftovers from whatever was on the disk before or another game, did not read consistently even when the original drive was used, but for the area used by the game the same reads were reproduced every time so those should be good at least.

It’s not a great game, hitbox is far too big meaning collisions usually feel unfair, and there’s very little content often just the same enemies reused with palette swaps (the video covers it all)

There are also some design issues like the 3 star powerup actually making the game more difficult as you can only have one set of bullets onscreen at once meaning you’re often left unable to take out enemies at close range if you’ve already fired off your shots. There are also plenty of places where enemy bullets spawn from nothing, which again just seems to be a design issue rather than an issue with the emulation or disk image, probably to keep you on your toes.

Unfortunately as with all the Magnet system games there is no way to reset the high score table to defaults, so the scores on the disk are the ones from people playing the game back in the day, and we have no idea what the factory defaults would have been, as a result the score table we have seems to be pretty much maxed out by a handful of players who must have played the game extensively back in the day. The chances of finding an untouched factory disk of these things is practically zero (it’s a miracle even this one showed up) so we’re probably just going to have to live with that.

Also, don’t bother trying to contact me at MameWorld, my account has been banned by Smitdogg, head of The Dumping Union because he took personal offense at me passing along some criticism over the quality of another dump (Tom Tom Magic, a Korean pinball game which had not been dumped correctly) Personally I find this behavior worrying and advise people take caution when donating to The Dumping Union as it seems they now think they’re above criticism and are quite happy to shoot the messenger as it were, My contact was only concerned with the quality of their output, including documentation provided, especially when dealing with such a rare PCB.

All that said, I’ll be away for the next week because I’m going to be in a field for Download Festival and staying with some friends.

Not much to report at the moment.

The XaviX work has stalled somewhat while I try to look through many lines of disassembly to see what I’m missing, there are a few things I haven’t shown / uploaded any videos of, but I’d rather wait until I make a breakthrough on those.

Instead I’ve spend today looking a bit more at the ‘Elan’ hardware on which several other Radica games run, and improved the sprite base register in the later type used by Golden Tee Home, connectv Football and several others (that are yet to be dumped)

connectv Football was a surprising find, because Radica typically used the connectv brand for European products and Play TV brand for US products, however there was already a Play TV Football, based on XaviX hardware so logically connectv Football would be the same game but for the European market. In this case however it was not, it’s a unique game that appears to have only been released in the UK / Europe. I guess what makes it especially strange is that it uses the same font for the ‘Football’ text, despite being an entirely different game, see this screenshot from an earlier update.

The connectv Football ROM does contain a ‘connectv Real Soccer’ logo too, but it appears to be unused, maybe had this one been released in the US that would have been the name, but with the Play TV branding obviously. Instead the actual Play TV Soccer game is yet another game, this time an import of the Epoch Excite Soccer from Japan on Xavix hardware (not yet dumped)

Controls haven’t been hooked up yet, but it’s just a collection of 3 mini games that you played with an shiny shinpad that worked with sensors in the base unit, reporting an X/Y position relative to the base, so might not be too difficult to map to a mouse. Sprite colour register is not yet fully understood.

I’d like to get this one finished because it’s actually one that I purchased myself and sent to Sean for deglobbing and dumping.

Another I purchased and sent was the other UK / European exclusive, connectv Cricket, this one however runs in vii.cpp (SunPlus) hardware like Skateboarder, and appears to expose some bugs in the DMA handling (or CPU core) of the driver, as well as needing proper I2C EEPROM emulation, and whatever IR communication hookup it needs to communicate with the bat, meaning that right now it’s a long way from being playable.

I also sent some LCD games, but they turned out to be an MCU type we have no current way of dumping and with no visible bits under a microscope, so at least one of those will probably go down as a casualty of the discovery process.

In other news Morten Shearman Kirkegaard figured out the correct compression algorithm for Gunpey by studying the compressed / decompressed data, allowing the fake decompressed data rom we extracted to be removed and replaced with real emulation of the decompression. That progress missed the latest release but will be in the next one.

Caps0ff decapped a number of MCUs including F1 Dream, which I hooked up, fixing operation of the original game in MAME (previously you had to run bootleg versions) The game however does still feel rather unfinished, crashing if you successfully complete all the tracks, but it that doesn’t appear to be protection related and I have a strong feeling the original game would crash / reset in that position too (and Capcom never programmed a proper end sequence)

Master Boy is a Spanish quiz game made by Gaelco.

Many years ago Charles MacDonald painstakingly extracted the internal ROM of the HD647180X0CP6 MCU used by Master Boy by exploiting a bug in the game’s string handling to output the internal ROM data, then handfix some bits that couldn’t be accurately dumped that way. This was done before decap techniques were available, so was something of a miracle that any method could be found to dump the rom. I then emulated it with the help of some notes he had made.

What we ended up with was the following game running in MAME

Actually, the above isn’t quite what we ended up with, because prior to last month we were running a set with the copyright message in the startup box hacked out and nobody had noticed, but that’s an aside.

There were however two things that didn’t quite add up here. We had sources that suggested Master Boy was a 1987 game, or possibly even a 1986 game. We also had sources that said there was a ‘Master Boy 2’ from 1991. The PCBs for the emulated Master Boy were marked as revision A, so it was speculated that maybe there was just an earlier set from 1987 we hadn’t found yet, but we’d seen no solid evidence for a ‘Master Boy 2’ at all.

Fast forward to a month or so ago and the guys at ARPA and Recreativas.org uncovered a very different Master Boy PCB

This was clearly not the same hardware as the emulated Master Boy, it’s a much simpler PCB using a Z80 instead of HD647180, an AY8910 for sound, and very little else; it’s a very simple PCB. The PCB was said to be for the 1987 version of Master Boy.

I quickly went about emulating the game, giving me the following.

So that concluded the 1987 version of Master Boy did exist, and was an entirely different piece of code. This newly emulated game is the real ‘first game ever made by Gaelco’ after they split from Tecfri in 1986. It is possible there is still an earlier revision than this as some sources still indicate 1986, but if that earlier revision exists it’s likely to be on this same PCB.

This also very likely means the elusive ‘Master Boy 2’ is in fact just the version we already had emulated, it’s clearly a sequel to this 1987 game, but for whatever reason Gaelco opted to not put ‘2’ on the title screen. Anybody who had played both back in the day would have remembered the 1991 as a sequel, which is where the ‘2’ likely came from.

In semi-related news I’m 99% sure we need to extract the internal ROM from a genuine Italian version of the 1991 game too, the string references on the bootup screen are incorrect using the ROM we have, they seem to be off-by-1, so the startup text here should show ‘Play Mark’ for example, not ‘Mark’ Of course this will require finding a genuine Italian PCB (not one that has simply had the Italian ROMs put on it) and finding a way to dump the internal ROM. With modern decap techniques I imagine there are more options for doing that now than having to resort to the techniques Charles used back in the day tho

Here is a video of the 1987 Master Boy running in MAME

Content not available.
Please allow cookies by clicking Accept on the banner

and here is the original PCB from which it was dumped running

Content not available.
Please allow cookies by clicking Accept on the banner

Team CAPS0ff recently devised a way to dump the internal EPROM from the Taito ‘c-chip’ protection modules

The TC0030CMD aka ‘c-chip’ is a custom Taito module which integrates a UPD78C11, RAM, ROM and a custom ASIC into a single package and was used to protect a number of Taito games in the late 80s / early 90s. It was, to my knowledge, the only time Taito used a custom package like this rather than simply using an off-the-shelf MCU directly.
actually
CAPS0ff had previously managed to dump the UPD78C11 part of the c-chip (which is a common kernel shared by all the c-chips) using optical techniques, basically decapping the chip, imaging the ROM area (which could be done because the internal ROM of the UPD78C11 is a MASK rom) and entering the data manually. That was done some months ago, and to the best of our knowledge was correctly dumped as the internal checksum it does at least matches without any special fudging being needed.

Dumping of the EPROM part required more thought, it couldn’t be done with the same technique as it isn’t a MASK rom so in the end a new way was found, hooking up the ROM die directly and dumping it after some very fine / delicate work. You can read all about that on the Team CAPS0ff blog.

The c-chip does several things for the games on which it is used. Firstly it manages the player inputs and some of the other system inputs, reading them and putting them in a shared RAM area for the 68k-side game code to read. One slightly odd quirk is that one of the digital ports is read through the ADC (Analog to Digital) port of the UPD78C11 which is an incredibly inefficient way of doing things. In most cases this port is used for the Player 2 cocktail mode controls.

The most important function of the c-chip, as with any good protection scheme is providing per-game protection functions that are tightly integrated with the actual game logic. Taito made use of this to varying extents across the games using it.

Bonze Adventure

Bonze Adventure has had issues in MAME for the entire time it has been emulated, with all of these coming due to various inaccuracies in the c-chip simulation. One of the main things the c-chip handles comes in the form of the restart positions when the player dies. The game code passes in the current co-ordinates and expects to get back the correct restart position for those co-ordinates. Failure to return the correct values results in the game crashing.

While the return values used by the simulation in MAME had been extracted from a running PCB there was still something clearly wrong with the simulation, like some coordinates had been missed, or there were flaws in the algorithm. Maybe this isn’t too surprising as the game is full of secret locations, and the actual restart positions are sometimes slightly illogical (sometimes skipping ahead, rather than backwards – depending more on which restart position you’re closest too, rather than which one you’ve passed)

Either way, this left MAME users with a choice of using an older version of MAME with guessed / inaccurate restart positions that didn’t outright crash, but could be glitched quite easily, or a newer version, with verified coordinates that for other reasons didn’t work (or hacked up builds that partially restored the old behavior) None of the emulated solutions were actually correct, even the PS2 Taito Legends port was incorrect because that was based off the same knowledge MAME had at the time.

Using the correct dump of the original c-chip all these problems go away, and the game now has correct restart points, and won’t crash if you die in the secret locations etc.

Content not available.
Please allow cookies by clicking Accept on the banner

Rainbow Islands

Due to historical significance of the game as part of the Bubble Bobble series, this was possibly one of the most important c-chips so having it dumped is a huge milestone even if end users might not notice a huge difference here.

Rainbow Islands is one of the most extensively protected c-chip games but also one where the simulation was already very good thanks to tireless work by a couple of people who were big fans of the game. Having extensively studied the behavior of the chip over the years, and extracted the various data tables from it already it’s fair to say the game was already very well emulated.

Very well emulated isn’t the same thing as correctly emulated however. Even with the extensive studies of the c-chip responses that had been done there was still some guesswork, of note in the generation of the y coordinates at goal-in where the random number generation was not understood and a simple table of observed values substituted for the real algorithm.

By running the real c-chip code the need to understand this goes away (although it would now be possible to analyze the c-chip program and work out what the real algorithm was) The beauty of hooking up the real protection MCUs in cases like this is that things ‘just work’ because you’re simply running the correct code, not having to simulate anything. This also allows for extensive cleanups of the MAME code as simulations of complex ‘black-box’ style protection devices inevitably end up being large and unwieldy as a well programmed MCU can do a lot of work for the game. Being able to simply delete those simulations and know the original code is being emulated instead is a big boost for the project, and for preservation in general.

Content not available.
Please allow cookies by clicking Accept on the banner

Rainbow Islands is an interesting case because it did spawn a bootleg, Jumping, on which some of the earlier protection simulations in MAME (and RAINE) were based prior to the more extensive studies that I previously mentioned. While the bootleggers had managed to work around the protection, they hadn’t got it right as beyond surface level there were many, many problems with the hacks the bootleggers had used to work around the protection in Jumping making it a much less desirable product. Despite this bootleg existing, it shows what a good job Taito did of the protection.

Rainbow Islands Extra

This semi-sequel of Rainbow Islands uses a different c-chip to Rainbow Islands. This c-chip isn’t actually dumped yet (and needs to be) but in the meantime I’ve applied the differences in the simulation code to the Rainbow Islands MCU so that it still runs using a fake c-chip ROM. Maybe the real one actually holds more secrets, maybe the real one has the actual MCU code tidied up a bit (as it looked to me like there were some unused tables in the Rainbow Islands MCU) In the meantime there’s not much to say about this, it’s the same basic protection Rainbow Islands but with different data due to the rearranged levels.

Personally I’ve never really seen the point of Rainbow Islands Extra, it feels more like a cheap hack, none of the remixed levels really make any sense and it loses most of the charm of the original by starting you off on a very dull looking level.

Superman

This one was dumped by CAPS0ff, allowing the real behavior to be studied, and differences between the simulation and proper emulation to be observed.

While Superman is not the best protected of the C-Chip games, and doesn’t tie any critical game logic to c-chip responses it does make the c-chip responsible for passing a chunk of 68k code back to the main CPU, this code is used to manage the sound command buffers in the game.

The previous simulation of the c-chip returned this code for the 68k CPU, it was accompanied in the MAME source by the comment “This code for sound communication is a hack, it will not be identical to the code derived from the real c-chip”

F01B20: 48E7 8080 movem.l D0/A0, -(A7)
F01B24: 206D 1C40 movea.l ($1c40,A5), A0
F01B28: 302F 000C move.w ($c,A7), D0
F01B2C: 1080 move.b D0, (A0)
F01B2E: 5288 addq.l #1, A0
F01B30: 203C 00F0 1C40 move.l #$f01c40, D0
F01B36: B1C0 cmpa.l D0, A0
F01B38: 6604 bne $f01b3e
F01B3A: 41ED 1C20 lea ($1c20,A5), A0
F01B3E: 2B48 1C40 move.l A0, ($1c40,A5)
F01B42: 4CDF 0101 movem.l (A7)+, D0/A0
F01B46: 4E75 rts

With the real c-chip emulated we can see that the above statement if indeed true, because the actual 68k routine supplied by the original c-chip looks like this.

F01B20: 4E56 0000 link A6, #$0
F01B24: 48E7 0100 movem.l D7, -(A7)
F01B28: 3E2E 0008 move.w ($8,A6), D7
F01B2C: 0C07 00FF cmpi.b #-$1, D7
F01B30: 6742 beq $f01b74
F01B32: 0C6D 0003 1CCA cmpi.w #$3, ($1cca,A5)
F01B38: 660E bne $f01b48
F01B3A: 082D 0003 1C4B btst #$3, ($1c4b,A5)
F01B40: 6606 bne $f01b48
F01B42: 0C07 0019 cmpi.b #$19, D7
F01B46: 662C bne $f01b74
F01B48: 48E7 0080 movem.l A0, -(A7)
F01B4C: 206D 1C40 movea.l ($1c40,A5), A0
F01B50: 10C7 move.b D7, (A0)+
F01B52: 2E3C 00F0 1C40 move.l #$f01c40, D7
F01B58: B1C7 cmpa.l D7, A0
F01B5A: 6606 bne $f01b62
F01B5C: 41ED 1C20 lea ($1c20,A5), A0
F01B60: 600A bra $f01b6c
F01B62: 2E2D 1C44 move.l ($1c44,A5), D7
F01B66: B1C7 cmpa.l D7, A0
F01B68: 6602 bne $f01b6c
F01B6A: 5388 subq.l #1, A0
F01B6C: 2B48 1C40 move.l A0, ($1c40,A5)
F01B70: 4CDF 0100 movem.l (A7)+, A0
F01B74: 4CDF 0080 movem.l (A7)+, D7
F01B78: 4E5E unlk A6
F01B7A: 4E75 rts

Superman also has a second block of 68k code supplied by the C-Chip, but from what I can tell there are no jumps to it from the main code, so it is probably a leftover from development.

F01B80: 4E56 0000 link A6, #$0
F01B84: 3F3C 0007 move.w #$7, -(A7)
F01B88: 4EBA FF32 jsr (-$ce,PC) ; ($f01abc)
F01B8C: DFFC 0000 0002 adda.l #$2, A7
F01B92: 48E7 80C0 movem.l D0/A0-A1, -(A7)
F01B96: 41F9 0090 0001 lea $900001.l, A0
F01B9C: 302E 0008 move.w ($8,A6), D0
F01BA0: 1140 0000 move.b D0, ($0,A0)
F01BA4: 4228 0002 clr.b ($2,A0)
F01BA8: 302E 000A move.w ($a,A6), D0
F01BAC: 1140 0004 move.b D0, ($4,A0)
F01BB0: 4E45 trap #$5
F01BB2: 3F3C 0007 move.w #$7, -(A7)
F01BB6: 4EBA FF04 jsr (-$fc,PC) ; ($f01abc)
F01BBA: DFFC 0000 0002 adda.l #$2, A7
F01BC0: 4A28 0002 tst.b ($2,A0)
F01BC4: 67EA beq $f01bb0
F01BC6: 3F2E 0008 move.w ($8,A6), -(A7)
F01BCA: 4EBA FEF0 jsr (-$110,PC) ; ($f01abc)
F01BCE: DFFC 0000 0002 adda.l #$2, A7
F01BD4: 1E28 0000 move.b ($0,A0), D7
F01BD8: E14F lsl.w #8, D7
F01BDA: 1E28 0002 move.b ($2,A0), D7
F01BDE: 41E8 0004 lea ($4,A0), A0
F01BE2: 226E 000C movea.l ($c,A6), A1
F01BE6: 1010 move.b (A0), D0
F01BE8: 12C0 move.b D0, (A1)+
F01BEA: D0FC 0002 adda.w #$2, A0
F01BEE: 51CF FFF6 dbra D7, $f01be6
F01BF2: 4CDF 0301 movem.l (A7)+, D0/A0-A1
F01BF6: 4E75 rts

As you can see, the real sound communication code is somewhat more complex than the fake code that was being used. Of note, it actually checks the status of the Demo Sound dipswitch (stored in RAM) and doesn’t pass on sound commands in attract mode if Demo Sounds are disabled, the fake code completely ignored that. The check of ‘F01B3A: 082D 0003 1C4B btst #$3, ($1c4b,A5)‘ is where the real code is checking the dipswitch value in RAM while ‘cmpi.w #$3, ($1cca,A5)‘ is checking if the game is in gameplay or attract mode (4 is gameplay, 3 is attract mode) There are also other subtle differences in the way the sound commands are handled. Maybe having the Demo Sound dipswitch behave the same as real hardware isn’t the biggest piece of news but it’s one of those small accuracy things that is good to know is now correct. I haven’t tried to work out the point of the apparently unused code, or when it would be called.

Like all the other games the c-chip is also directly responsible for handling inputs and putting them in shared RAM. The previous simulation just shoved them directly into RAM.

Content not available.
Please allow cookies by clicking Accept on the banner

Volfied

This is another one that has been dumped by CAPS0ff and is now fully emulated. The Volfied protection sits somewhere in the middle of the others, supplying palette data for enemies, and managing a few counters (eg for ensuring an enemy attacks you when your shield runs out) It isn’t an especially interesting protection, but some of the behavior it has wasn’t 100% obvious or trusted prior to having the proper c-chip dump.

The Volfied emulation still seems to have some other timing issues even with the c-chip emulated, because the 2nd attract mode how to play sequence does not appear to complete correctly, there are unused messages telling the player that the enemy gets smaller as you box it in which aren’t triggered because the player dies too early. The actual behavior needs verifying on the PCB and I suspect is related to some video flags, not the c-chip. Having the real c-chip dump and emulation at least allows us to 100% rule out that being some kind of subtle c-chip related behavior.

Content not available.
Please allow cookies by clicking Accept on the banner

Operation Wolf

The Operation Wolf c-chip is not yet dumped. Bryan McPhail has sent one for processing, and considering the amount of research he has done over the years to improve the simulation of it I’m sure he’ll be very interested in seeing what the real code has to offer. Operation Wolf appears to be the first, and most heavily protected of the c-chip games with many small details of the game logic being tied to protection functions. It took many, many years for the simulation to be any good at all, I definitely suggest reading Bryan’s blog for more information about that. Once this one is dumped all that simulation code can be cleaned up. Chances are Bryan will be the one to hook this up when it gets dumped because given the amount of work he’s put in over the years, and also it being his chip being sent for processing, it just kinda makes sense if he is the first one to look at it.

I guess the interesting sub-note for Operation Wolf so far is that the UPD78C11 part of the dump we have actually came from an Operation Wolf c-chip, and we do have a partial dump of the EPROM from another Operation Wolf c-chip (missing half the code / data) but both of those were casualties in the process of figuring out how to dump these properly.

Operation Wolf is also historically significant because it was bootlegged back in the day, however the bootleggers chose to use a Z80 to simulate the behavior of the c-chip. This resulted in a lot of incorrect assumptions that the original c-chips were Z80s and the bootleggers had managed to extract the code. Truth be told the bootleggers had simply tried their best to analyze the protection behavior and recreate it, much as the emulation developers had. The Z80 code, one studied actually turned out to be full of bugs and incorrect behaviors. Rumours did however still persist that the c-chip was a Z80 due to this until the very day it was actually decapped and proven not to be.

Mega Blast

The Mega Blast c-chip is also not dumped yet, although it might well be blank or recycled from another game. It would be fair to say that the C-Chip on Mega Blast exists for decoration, it isn’t used beyond the startup check. Once the command to jump out of the MASK rom area of the UPD78C11 and into the EPROM has been sent no further commands are sent to the C-chip, and no accesses are done to the shared region, the game doesn’t even read the inputs through the c-chip. As long as the c-chip RAM works, and it returns the correct value for having passed the UPD78C11 MASK rom checksum the game will run. It’s literally used for nothing. CAPS0ff do currently have a Mega Blast chip, and will eventually dump it, at which point we’ll see if it is indeed blank, from another game, or maybe even contains protection code that Taito never got around to hooking up, or that might have been used on an earlier / unreleased version of the game but ultimately ended up being disabled because there were problems with it. It’s definitely the least interesting of the c-chip games on the surface (because it doesn’t even make use of it) but if it holds some secrets / tells a forgotten story of development it does still have the potential to be one of the more interesting ones for the arcade archaeologist.

Other Secrets

Even with all this done there are a few things we don’t fully understand about the c-chip, but as far as the protection functions go they’re not important. One thing of note is that the internal UPD78C11 code actually includes an additional mode of operation not triggered by any of the games. This mode includes various diagnosis features that we were hoping could be used to dump the EPROMs without having to resort to the physical attack CAPS0ff needed in the end. Unfortunately upon sending the correct command to enter this mode we found the 68k was locked out of all responses from the c-chip. This is presumably due to a port write to ‘PORT F’ that only happens when triggering that mode. There might be some way to get the 68k to see the responses again, but we couldn’t find it, the chip simply stopped responding at that point. None of the games use that port, so it was clearly something intended for development / debugging of the original c-chips only, I guess it’s possible the code is non-functional on the retail modules. If somebody else did want to independently research the c-chips beyond the work done here there’s definitely a lot more to work with now than there was prior to the work done by CAPS0ff, and I imagine at some point it will become necessary to start building replacement c-chips as they do seem to be a source of failure with these boards.

I’m overdue a few updates here, because a couple of important things have happened and I haven’t managed to find time to write about them yet. I’m going to start with emulation improvements on an arcade puzzle game from the year 2000.

Gunpey, a game that was apparently named as a tribute to the late Gunpei Yokoi (creator of the original Nintendo Game & Watch series) is an arcade port of the Wonderswan title of the same name, it was also ported to the Playstation.

Last time I looked at this driver was back in March of 2013 where despite making some good progress, I got stuck completely with the sprite compression.

Fast forward 5 years to March 2018 and I have some new progress to show. Peter and Morten, who have been working on numerous projects with me, hooked up some hardware to the Gunpey PCB that allowed them to log video ram read / writes. By using this hardware they were able to save the decompressed data for every compressed sprite, giving us plenty of plaintext material to use and hopefully make it easier to figure out the actual compression scheme.

As a step in this process the extracted data has been hooked up to MAME while the actual scheme is figured out. This gives correct sprites in all the cases where you could previously only see garbage due to the data compression. Obviously the work isn’t yet finished, but by using this data the game can be considered playable. Once the compression is figured out the end result should be the same, just with cleaner underlying code.

I also took the opportunity to add support for zoomed sprites, used when you launch an attack on the enemy. Here are some screenshots of the improved driver.

Working with the hardware also told us a few other things, like that the framebuffer is actually in the same RAM that the sprites get decompressed into, not a separate memory area, so there must be a way the game sets up the pointer so it knows where to write the framebuffer data. It was also confirmed that the framebuffer is double buffered. These features need hooking up.

One thing that isn’t yet clear is if the Arcade version really is meant to effectively run at 30 frames per second, only updating the screen every other frame. The Playstation release runs at 60 so appears to animate a lot more smoothly. There are registers to select the source of the drawing, but at the moment they really do only change every other frame, so this might require some further investigation. Unfortunately while there are a lot of original hardware YouTube videos none of them are HD 60fps videos recorded on a 60fps camera that could show me if the game is / isn’t meant to update every frame.

Anyway, here is a video I’ve recorded showing the progress so far, obviously this is a big improvement over how it has been in previous MAME releases.

Content not available.
Please allow cookies by clicking Accept on the banner