0.36b3 [Paul Leaman]
TODO :
- Rasters are not correctly emulated in places where more than one split happens per frame. A known place where this problem happens is during Shuma-Gorath's Chaos Dimension super move in both MSH and MSHVSF. The screen should split into around 6 or more strips and then scroll the gfx inside those strips up and down alternatly (as one stip moves gfx up the next strip moves the gfx down).
- The network adapter used in Super Street Fighter II: The Tournament Battle is not currently emulated though the ports it uses are setup in the memory map.
- Giga Wing's attract mode seems to loose sync with music. The problem seems to happen due to gfx drawing slowing to much when screen colors fade out. This problem could be due to the 68k being clocked at 11.8mhz when the hardware has a 16mhz crystal on it. Various timing loops show 11.8 being the average speed of the cpu and this does run true when comparing emulation and real hardware when timing is not based on VSync (ssf2 and ssf2t for example). It is possible that what is slowing the cpu is read/write wait states when accessing RAM areas. This would mean that in places where lots of opcodes are being used in connetion with data registers only the code would end up running to slow.
- Giga Wing's sprites are 1 frame out when compared to background scrolling. See the explanation above for the most likley cause of this problem.
- Progear slows down more than it should when compared to real hardware. See the explanation above for the most likely cause of this problem.
- Any new region sets will need full encryption tables dumped to extract the proper keys or they will need to be brute forced. XORs are no longer supported nor wanted.
- All games: All inputs have been mapped according to the "test mode" (even if some buttons don't physically exist on the machine). Joysticks and buttons can be fully tested. COINn sometimes don't show anything but are OK ingame. Unless I notify something below for some games, there is no extra button !
- mmancp2u: BUTTON3 doesn't physically exist on the machine and has no effect ingame.
- megaman2: BUTTON3 doesn't physically exist on the machine and has no effect ingame.
- mpang: BUTTON2 doesn't physically exist on the machine and can't be seen in the "test mode". However, if you map it where it should be, it has the same effect as BUTTON1.
- pzloop2: Whatever your settings are, the paddle can't be tested in the "test mode"! I can't tell at the moment if it's an emulation or an ingame bug :(
- dimahoo: BUTTON3 doesn't physically exist on the machine. However, it acts like a rapid fire (keep button pressed).
- progear: BUTTON3 acts like a rapid fire (keep button pressed). It has to be enabled in the game settings as it is OFF by default.
NOTES :
- Driver: Thanks to Raz, Crashtest and the CPS2 decryption team for their initial work on extracting decrypted code. Thanks to Andreas Naive and Nicola Salmoria for understanding the encryption mechanism.
BUGS :
- msh, xmvsf, xmcota: [possible] In the test menu for msh, mshvsf, xmvsf, xmcota, nwarr for sound and voice, the bar for volume disappers. (ID 01488)
- msh, mshvsf: Rasters are not correctly emulated in places where more than one split happens per frame. Source (ID 02297)
- mmancp2u, megaman2, mpang, pzloop2, dimahoo, progear: Known issues of inputs. Source (ID 02302)
WIP :
- 0.135u4: Fabio Priuli added driver data struct and save states to CPS2 driver.
- 0.131u1: MooglyGuy merged memory maps in the CPS2 driver.
- 0.128u4: Documented the CPS2 Phoenix sets, and what happens to a dead CPS2 board [MAMEPlus]. The Phoenix sets were created by Razoola as a method of allowing the games to run on CPS2 boards where the battery had died. When this happens the boards run non-encrypted code, but the memory mapping is changed. As the original games have encrypted code mixed with decrypted data the program roms must be carefully modified in order to correctly contain only decrypted code and data, as well as modification to compensate for the memory map changes that occur on the dead boards. Due nature of this process there were sometimes errors introduced into the 'Phoenix' sets. Unfortunately the 'Phoenix' sets also ended up forming the basis of a mass cps2 bootlegging operation whereby cheap CPS2 B boards were purchased, the encryption keys killed, and the boards converted to more desirable games. These started off as single game bootlegs of in-demand titles, but soon started also forming the basis of xx-in-1 bootlegs running on heavily customized B-boards. These are not legitimate Capcom products despite appearing to be so. These bootlegs are often sold as 'Phoenix Edition' after Razoola's name, 'xx-in-1', or simply 'Suicide-Free' to further artificially inflate the price. Buyer Beware! All sets are marked as bootleg because they're unauthorized modifications of the original Capcom rom data, and were used for bootleg conversions. This may not be a complete list of sets, it was taken from MamePlus. Other sets, and further customized bootlegs boards are known to exist. There is a bootleg of Megaman 2 called 'Gigaman 2' which has SMT roms, and replaces the Qsound hardware with an OKI6295 / AD-65 chip. No known complete dump exists.
- 0.128u3: CPS2 ROM updates to match PCB labels [Razoola].
- 0.127u1: Aaron Giles derived CPS2 video timing based on measurements. These are educated guesses. The logic behind the derivations is shown in the source. Changed VSync to 59.629403 Hz.
- 0.127: Robiza fixed graphics in CPS2 games.
- 0.126u3: Firewave fixed 'Abort' in all CPS2 parent sets.
- 0.124u3: Nicola Salmoria merged CPS1, CPS2 memory maps and some tweaks from schematics, though to get perfect memory maps dumps of the A-board PALs would be needed.
- 0.124u1: Changed palettesize to 3072 colors.
- 0.123u1: Changed the GAME definitions in the cps2 driver to reflect how many players and how many buttons there are for each game. Rewrote the INPUT_PORTS definitions to use PORT_INCLUDE, PORT_MODIFY and PORT_CUSTOM macros. Added a few notes about the inputs when I thought they were needed to avoid wrong bug reports. Started to clean the driver [Stephane Humbert].
- 0.122u8: Changed 68000 CPU1 clock speed to 16MHz.
- 9th September 2007: David Haywood - CPS2 Generation: For a long time two CPS2 sets, the CPS2 versions of MegaMan and RockMan, have been left without a decryption key and thus been non-functional. The CPS1 versions have been supported for many years, but finding the keys for the CPS2 versions was proving to be very difficult as the CPS2 and CPS1 sets were not identical underneath the encryption due to hardware differences between the platforms. It had been assumed that the two versions were simply too different, to the point of giving up with the usual line of key finding attacks Nicola has used to find the keys for the other sets. However, after studying the sets myself I realised that a large amount of the code probably WAS the same, just offset in the rom. Many code functions were surrounded by similar data, and were of the same size in both versions. By assuming that these functions were the same, and realigning the code we ended up with a much closer match between the CPS1 and CPS2 sets, allowing the standard attack Nicola devised to work. As a result, keys have now been found for the CPS2 versions of the game. This means every currently supported CPS2 set has been decrypted. The Megaman CPS2 set is actually a limited release 'SAMPLE' version, as the game was (to my knowledge) never fully released in the US. The main differences in the CPS2 versions are the use of Qsound hardware for the sound, and an Eeprom to save game settings (as opposed to dipswitches). As a bonus (thanks to Chris Hardy) 2 new Euro parent sets are now supported and decrypted too: Dimahoo (Euro) and Street Fighter Alpha 3 (Euro).
- 0.116u1: Nicola Salmoria updated CPS2 decryption bit order to match what is likely the original order.
- 0.114u2: Couriersud fixed crash if you attempt to view graphics page 4.
- 0.114: Aaron Giles fixed a MAME crash if you do a hardware reset.
- 0.113u2: Changed VSync to 59.633333 Hz.
- 0.112u2: Many more CPS2 keys added. Removed all XORs and support for them from MAME [Nicola Salmoria, Andreas Naive].
- 0.111u5: Nicola Salmoria removed XORs from almost all CPS2 games in place of proper emulation of the encryption.
- 23rd January 2007: Guru - Here's a few pics of the very first custom chip that I sent to a professional Japanese IC decapping company that we (Mamedev) are using to help us with some MAME-related things. Hopefully if this is successful, more will follow and also hopefully talented hardware devs like JROK will be able to make replacements for it to repair real PCBs. You may also be wondering why we're doing this instead of using some other people who frequent the 'boards' who have offered to do this kind of thing for free? The answer is fairly simple.... apart from the amount of time it takes to get this done, the level of communication is somewhat 'sporadic' and so far offers to supply other chips to them have been ignored. We requested pics of some CPS2 ICs that were said to have been decapped and so far nothing has surfaced (over a month has passed since then). Doing it this way gives us more control over what we achieve and ensures the work is done in a timely manner. Apart from that, the plan to get this IC decapped has been in the works for several months, so we might as well use the professional IC decapping company whenever possible because the amount of ICs we need to decap is possibly too much work for someone to do in their spare time for free.
- 0.111u3: Andreas Naive and Nicola Salmoria replaced CPS2 CHDs with preliminary decryption function.
- 8th January 2007: Razoola - Nicola Salmoria of MAME Dev seems to have worked out the rest of the CPS2 algo (though there is still some s-boxes to complete), to quote his blog... * Take the 16-bit address and a 96-bit key and run them through the first Feistel network, to produce a 16-bit subkey. * Take the 16-bit ciphertext, 16-bit subkey, and another 96-bit key and run them through the second Feistel network, to produce the 16-bit plaintext. Our congratulations go out to him, again to Andreas Naive and also Charles MacDonald who all played a role to get to this point today. Looking back at the way things have gone from the first XOR release some six years ago (after the discovery of the main weakness in the system), we know some people were quite unhappy at our unwillingness to have this algo known for emulation (Statement of 7th Janurary 2001). It was always our intention to hold back information to help achieve this until the system was commercially dead (our view was 3 years after the last game released). It is very satisfying to know we achieved this as believe it or not Janurary 2007 is just past that three year mark (Hyper Street Fighter II was released in December 22nd 2003). I will update the encryption page with the details once Nicola has fully documented the Algo within MAME.
- 0.110u4: CPS2 updates [David Haywood]: Added table for Jyangokushi (from Guru). Note that GFX/Sound roms aren't dumped on this one. Removed old 'handcrafted' XORs for games which we have CHDs for and replaced them with XORs generated from MAME using the CHD. This means anyone with the CHD can easily generate the XORs (using the code I've left in there) if they need to be able to run the games with a shorter startup time. Disabled the loading of the XORs by default for all sets with a CHD. Now only the CHD is loaded, unless the #define is changed at the top in which case only the XORs generated from the CHD are loaded.
- 0.110u3: David Haywood added raw decryption table to choko. Enabled the use of the large CHD-based tables by default.
- 0.110u2: David Haywood added support for using CHDs to decrypt CPS2 games. This code is disabled for the moment, but will be enabled in the future. Only a handful of games have complete tables so far. These tables are huge (~4GB) and uncompressable until the encryption algorithm is understood.
- 19th September 2006: Charles MacDonald - With the success of the Choko dump from a while ago, I'm working to get the CPS-2 dumping tools and instructions updated. Changes were made from the last version, mostly bugfixes and speed-ups to decrease the amount of time it takes to dump a full table set. There's also a minor modification that needs to be done to the PCB, to ensure stability, though now that it's known which features are absolutely needed, I might redesign it. Admittedly not many people have been interested in getting more of the games dumped, probably because all the popular ones we wasted tons of quarters on are already emulated!
- 0.105u3: Aaron Giles uncommented/added missing undumped ROMs/XORs in the CPS2 games.
- 0.105u1: David Haywood updated CPS driver to more accurately draw tilemaps, based on evidence from a board with mixed ROMs.
- 14th February 2006: Guru - A CPS2 USB adapter arrived, thanks to Charles MacDonald. The adapter plugs into the 64-pin CN7 on the B board. The chips on the bench are the original ROMs and PALs. ROM3 is changed and ROM10 is added. Plus 1 PAL on the A board is changed and 2 PALs on the B board are changed. Unfortunately, none of the PALs were socketed and this particular B board didn't have a CN7 connector! So I had to desolder a CN7 connector from another dead CPS2 board and solder it to this board and desolder and socket the 3 PALs as well! Luckily she still works! It's not that exciting to look at though.
- 15th January 2006: Razoola - Nicola Salmoria has reported on his blog some progress in understanding the CPS2 algo. He has managed to shrink the current 8gig table of SFZ down to 4gig. This is the first breakthrough in understanding the encryption used. For more information visit his blog.
- 11th January 2006: Charles MacDonald - I've tried to package and clean up all the CPS-2 related development stuff I have that was used for table dumping. This can be used for writing CPS-2 software, running tests on the system, and dumping table data so we can hopefully figure out the encryption at some point. I will definitely include more sample programs, documentation, and hardware information in future updates to the package, but I wanted to get this off my to-do list.
- 5th January 2006: Razoola - While playing around coding on a dead CPS-2 board I have today I found that the encryption algo is still fully in place even after the CPS-2 board has suicided. That said, on examining values the number do not match those of the expected game. This almost certainly confirms that their is only _one_ algo over all CPS-2 games with the only difference being key data (like Kabuki on CPS-1). I passed some test code onto Charles MacDonald so that he can check the values he gets there (on his dead SFA3 board). Those should match what I see here and to be honest it looks just a formality. When you consider the watchdog on a suicide board is 0xFFFF,0xFFFF,0xFFFF (example opcode, CMPI.L #$FFFFFFFF,$FFFF0000) everything starts to make sence. There was a big debate over this going back to when we first broke past the protection. The worry voiced by some DEVs was that all boards would be needed again to get the algo for each game. This new discovery certainly confirms that once the algo is known for one game all the others can be brute forced using the XOR tables. As for figuring out the algo itsself whats needed now is a complete dump of tables (8gig) of the algo executing in this default state. Using this the algo should be easier to understand because any key data used for math should be 0xFFFF. I have quickly dumped a complete table for a couple of addresses and while it still looks a mess there are certinally more patterns compared to a normal game. Update: I've got word back from Charles and after some work (over irc) he has managed to get the same data I was seeing. This basically confirms what I mentioned above. There were some initial problems with his transfer system (which is far superior to mine) giving different results. It turned out that at some point during the process the protected RAM was being reprogrammed!!! The exact way this is happening is not yet known but it opens up some large posibilities if the cause can be found and understood. This situation did not happen when he was dumping games that were non suicide. It currently looks like there is no way to get a full 8gig table because the protected region in a suicide state seems to be only 0x10000 bytes where a complete table covers 0x20000 bytes. Hopefully we can get around this.
- 4th January 2006: Razoola - I have written a small tool that can be programmed onto EPROM and used to test if a CPS2 board has suicided.
- 19th November 2005: Charles MacDonald - Thanks to a generous donation from Razoola and the CPS2Shock team, I've been given B-boards for the following games: sfzj, csclubj and sfz3. I have dumped complete table sets from the first two and am doing tests on the latter. It has no battery, so I can see how the hardware works when the battery-backed SRAM is erased. With a much larger data set (32 GB) spanning four games, hopefully some patterns will be discovered. I'm still interested in dumping a regional variant for one of the currently dumped games to see what kinds of similarities might exist between the two. Most likely I will revise and release the tools and specifications for my CPS-2 development setup in the future. Then other people could dump table sets from their games and contribute to this project. There are so many CPS-2 games out there that I couldn't possibly do it all myself, nor would I want to.
- 12th October 2005: Charles MacDonald - Getting a bunch of PCBs to work with in the next few weeks: three CPS-2 'B' boards (more on those next update) and a Quartet 2 board. I'll continue my CPS-2 research once the other games arrive. One of them has no battery so I can skip the annoying encryption and run tests directly, which will be a huge convenience. I think right now all the useful data that can be extracted from xmcota and pzloop2j has been obtained.
- 30th September 2005: Charles MacDonald - I've been doing some research on the CPS-2 hardware in the last few months, starting as soon as the System 32 work was put on hold. I'll give a basic overview of the encryption, however I should point out I'm just elaborating on the findings that Razoola originally made, which are at CPS-2 Shock. As you can imagine the results of his prior experiments have been absolutely essential to this project. The CPS-2 hardware uses a custom 68000 CPU running at 16MHz, though the effective speed is lower due to video DMA. Out of the 16MB address range, the lower 4MB is allocated for ROMs storing program code and data. The first 1MB of this area is where decryption is enabled, though the exact boundary under the 4MB point may change from game to game. In addition to the address range check, there is a timer that expires after a certain amount of time has passed. When this happens, decryption is turned off and the 68K will execute code exactly as it is read from memory. A sequence of one or more specific instructions, changing on a per-game basis, will reset the timer and enable encryption again. The timer can be restarted after any duration from when it has expired. The decryption logic uses bits A16 through A1 of the 68K address bus, meaning the encryption wraps every 128K. For each encrypted word at a given address there is exactly one unique output; in contrast to the FD1094 there are no disabled opcodes or 'blanked' data that resolve to the same decrypted value. Data read from the supervisor or user code space is decrypted (e.g. opcodes and operands) and data from the supervisor or user data space is not. The size of a complete set of decrypted data for one game quite large, totalling 8GB - it takes forever to dump. There are no duplicate tables within a game's table set or between sets for different games, though I've only examined tables dumped from the two 'B' boards I have. I've discussed analysis of the table data with a few other people and so far the encryption seems to be pretty tough to solve. As a result, I think progress will depend on additional help. If you have skill in this type of thing (strong mathematics background and familiarity with encryption) and would like to lend a hand, then please get in contact with me. Working with the CPS-2 hardware has been challenging due to the large amount of custom parts involved. I designed a communications board with a USB adapter, DTACK generator, and interface to the CPS-2 video and peripheral bus to run software on it, as well as several adapters to replace the 16V8 GALs with more capable 22V10 GALs that have their own shared I/O bus. Small update for some common questions: The two games I've dumped are xmcota and pzloop2j, which are both already emulated in MAME. The ETA for a complete table dump (65,536 files) is 9 hours, and it's fully automated. Sometimes the system locks up randomly and has to be reset which slows things down, this occured quite a lot for pzloop2j and not at all for xmcota. They have different types of B boards, perhaps that has something to do with it. Many people are suggesting to look at Street Fighter Zero and it's variants, as well as Rockman which had a less common CPS-2 release but is very similar to the CPS-1 version. The only thing that would be really useful is to find two games that are encrypted with the same or similar keys, so unless Rockman has an identical key as another game it's not that useful. I would be interested in getting data out of another variant of xmcota.
- 0.94u2: Aaron Giles fixed CPS2 QSound routing.
- 27th October 2004: Razoola - There seems to be someone making quick hacks of XOR files we have released in the past to get games running which don't currently have XORs. While this sounds a good thing it's actually no different than using the region switch option in kawaks for example. The big problem is that these new XOR's contain incorrect information in relation to what the real encryption would return for many addresses when compared to real hardware. It also makes it less likely for these games to be donated in the future so good XOR's can be created as people will think they already have good XOR's. The reality is these new hacked XOR's are prone to all the bugs that come with using region switching in CPS2 games. It's for these reasons that I want it known I have nothing to do with these hacks and I would advise against them being used officially in any emulator as they cannot guarantee an accurate game.
- 0.71u2: Shiriru fixed CPS2 raster effect.
- 19th January 2003: Shiriru's updates to the CPS-2 driver fixing raster effects.
- 8th December 2002: Barry Rodewald submitted a bug fix for resetting the Z80 in the CPS-2 driver, and smf improved the fix.
- 19th November 2002: Shiriru's updates containing fixed sprite masking in the CPS-2 driver and fixed sprite delay in Battle Bakraid were also forwarded.
- 13th September 2002: Barry Rodewald submitted a fix for the CPS-2 driver to reset the Z80 properly after exiting service mode.
- 6th September 2002: Barry Rodewald submitted an improvement to the CPS-2 driver raster effects' emulation, improving many cases, however it still causes flicker from time to time.
- 11th August 2002: Two of Shiriru's old updates were forwarded, which fix background colors and BG/sprite sync in the Cave driver and sprite masking in the CPS-2 driver.
- 12th May 2002: Barry Rodewald submitted an update to the CPS-2 driver supporting raster effects, but it unfortunately causes the background / sprite sync to be broken.
- 25th August 2001: Aaron Giles fixed a decryption problem which caused CPS-2 not to work.
- 0.54: Major changes to the CPU interface. As a result of this, some games are temporarily broken, most notably CPS2 [Aaron Giles].
- 0.37b16: Removed vidhrdw\cps2.c. Shiriru fixed sprite priorities in CPS2 games. Fixed user1 roms addresses.
- 16th June 2001: Shiriru fixed sprite priority and added sprite transparency in the CPS-2 games.
- 1st June 2001: Nicola Salmoria fixed CPS-2 games from crashing when resetting them.
- 0.37b14: Changed 68000 CPU1 clock speed to 11.8MHz and VSync to 59.633331 Hz.
- 0.37b13: Changed 68000 CPU1 clock speed to 12MHz.
- 16th February 2001: Nicola Salmoria fixed the input ports for third and fourth player in the CPS-2 games.
- 10th January 2001: Paul Leaman added the necessary modifications to the CPS-1 driver to allow CPS-2 emulation, and he added support for Street Fighter Zero.
- 0.36b3: Added cps2.c driver and vidhrdw\cps2.c.
|
