Marvel Vs. Capcom: Clash of Super Heroes (Japan 980123) (Single PCB)


Immagine gioco: Marvel Vs. Capcom: Clash of Super Heroes (Japan 980123) (Single PCB)
   
Immagini disponibili::




 Descrizione 
Nome romset mvscjsing.zip
Anno di produzione: 1998
Produttore: Capcom
Questo gioco il clone di: Marvel Vs. Capcom: Clash of Super Heroes (Euro 980123)

Genere del gioco: Picchiaduro
Categoria: Picchiaduro / Scontro

 Emulazione 
Questo gioco funziona correttamente in MAME Questo gioco funziona correttamente in MAME
In MAME dalla versione: .147u3
Salvataggio state: Supportato
Stato dell'emulazione: Buono
Emulazione colore: Buono
Emulazione sonoro: Buono
Emulazione grafica: Buono
Dimensione palette: 3072
Il driver di questo gioco in MAME : cps2.c - Leggi il codice

  Dati tecnici 
Questo gioco usa un solo schermo:
  Tipo di grafica: Raster
  Orientamento schermo: Orizzontale
  Risoluzione del gioco 384 x 224 @ 59.629403
Numero di giocatori: 2
Controllato con:
  Joystick
Numero di pulsanti: 6

 Dati Scheda 
Il ROMset si compone di 9 ROM (2 del set parent, 7 del set clone)
Riferito alla versione MAME: 0.152

NomeDimensioniCRC32SHA1FunzionamentoNel romset
mvc_ja.simm120971526a2ef7c2 625530b92217375014db4694196e6ab2a4684db6 good mvscjsing
mvc_ja.simm32097152699d09ad 67f6587808f55f10f58e067512f8db3f67dda770 good mvscjsing
mvc64-13m.1383886088428ce69 65b1cdb40e5bd0c9afc21d267d02d118f8c9a44a good mvscjsing
mvc64-15m.1583886082e0028f4 be21622c5e3ba9a0a799d943fc6cc2bf7ec9582f good mvscjsing
mvc64-17m.178388608308ca826 2ef1fb4999e7e25e7f605c788f61a85da6715475 good mvscjsing
mvc64-19m.19838860810699fe1 4bb65999c2a73c46cd0c7b6ea26ffb0d8ab24602 good mvscjsing
mvc.0113107241629e95 36925c05b5fdcbe43283a882d021e5360c947061 good mvsc
mvc.02131072963abf6b 6b784870e338701cefabbbe4669984b5c4e8a9a5 good mvsc
mvc64-11m.1183886085d8819e0 afe2ec7fa4786e6d9a9a0ffa5787862ad69b0010 good mvscjsing


:  Gioco Parent
:  Gioco Clone
:  BIOS

Le dimensioni del file mvscjsing.zip sono 21.56 Mbytes (compresso)

 Informazioni 
HISTORY
Attenzione: I dati di history.dat potrebbero essere diversi da quelli riportati nel resto della scheda (tratti da MAME), in quanto provenienti da fonti diverse.

 MAMEINFO.DAT 
Informazioni su mvsc

0.127u4 [Bonky_0013]

0.102u3 [?]

0.58 [Razoola, J. Murphy, walk, Dr. MAD]


Artwork available


Bugs:

- Clone mvscu: Sprite priority problem on Final Stage (8) with Onslaught (large transformation). Yonah (ID 04954)


WIP:

- 0.148: Documented an alternative SIMM card configuration for clone (Japan 980123) (Single PCB) [Smitdogg, The Dumping Union].

- 0.147u3: ranger_lennier, Yohji, Tormod, Smitdogg and The Dumping Union added clone 'Marvel Vs. Capcom: Clash of Super Heroes (Japan 980123) (Single PCB)'.

- 16th November 2012: Smitdogg - We got the CPS2 single board version of Marvel Vs. Capcom. The differences I've seen so far are the mask roms are different sizes and the volume is controlled with a knob instead of digital steps. The section in service mode where it normally shows you the volume level is totally missing in this version.

- 0.142u5: Alex Jackson fixed reset at staff roll only in Marvel Vs. Capcom. Added new maincpu rom ($80000). NOTE: The originally dumped ROM4 (mvce.04a) contains garbage instructions that cause the game to crash during the ending staff roll. The ROM has been repaired so that the code matches the other sets after decryption.

- 0.138u3: Razoola added clone Marvel Vs. Capcom: Clash of Super Heroes (USA 971222).

- 0.128u4: MAMEPlus added clone Marvel Vs. Capcom: Clash of Super Heroes (USA 980123 Phoenix Edition) (bootleg).

- 0.127u4: Bonky_0013 added 'Marvel Vs. Capcom: Clash of Super Heroes (Euro 980123)'. Renamed (mvsc) to (mvscr1).

- 13th January 2008: Mr. Do - I finished off the rest of the instruction cards made available by Strider of Cybercade: Marvel vs. Capcom.

- 0.102u3: Added 'Marvel Vs. Capcom: Clash of Super Heroes (Euro 980112)'. Renamed (mvsc) to (mvscu).

- 0.86u3: Added clone Marvel Vs. Capcom: Clash of Super Heroes (Asia 980123). Renamed (mvsca) to (mvscar1).

- 0.84: Razoola added clone Marvel Vs. Capcom: Clash of Super Heroes (Brazil 980123).

- 0.58: Added Marvel Vs. Capcom: Clash of Super Heroes (US 980123) and clones (Japan 980123), (Japan 980112), (Asia 980112) and (Hispanic 980123).

- 0.56: Added Marvel Vs. Capcom: Clash of Super Heroes (Asia 980112) (Testdriver).

- 23rd January 2002: Razoola - Released XORs 77-80 for Marvel Vs. Capcom (USA 980123), (Japan 980112), (Japan 980123) and (Asia 980112) donated by J. Murphy, walk and Dr. MAD.

- 0.37b15: Added clone Marvel Vs. Capcom: Clash of Super Heroes (Japan 980112) (Testdriver).

- 0.37b13: Added clone Marvel Vs. Capcom: Clash of Super Heroes (Hispanic 980123) (Testdriver).

- 0.37b7: Added clone 'Marvel Super Heroes vs. Capcom: Clash of Super Heroes (Japan 980123)' (Testdriver).


LEVELS: 8


Other Emulators:

* Calice

* FB Alpha

* Kawaks

* Nebula

* Raine

Informazioni su cps2.c (Driver MAME)


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.

- Some Hispanic/Brazil region sets have settings adjustable for a card dispenser. Many times, this is defaulted to ON. Since MAME at this time does not emulate this unique dispenser, you will get a "NO CARD" message flashing on the screen for these sets unless you enter Service Mode and adjust CONFIGURATION > SYSTEM > C. DISPENSER to OFF. An example of a game which does this is Street Fighter 3 Alpha.


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. Misc (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.148u5: Added QSound internal DSP ROM to the device [Andrew Gardner]. Added DSP16 (4Mhz) CPU3.

- 0.148u1: CPS2 modernisation [Robbbert].

- 0.148: Modernize the QSound sound device. Added DSP16 registers and implemented the goto opcode. Added DSP16 16-bit immediate load opcode. Fixed reset behavior. Code reorganization [Andrew Gardner]: The one that started it all. It works now. No idea what I was doing wrong before, but I'm not doing it anymore. It appears as though a clean build might be necessary for this one to take. I've tested more CPS2 games than I care to mention, a bunch of zn games, and a cps1 game and they all are happy, so we should be good. Now for the fun stuff...

- 0.147u4: Added digital volume control [Barry Harris]. I have attached a patch which allows CPS-2 games to use their digital volume (up & down) buttons. The buttons are mapped to the usual MAME volume up & down buttons, and the test screen sound sliders work, as does the expected change in actual sound volume. I have also added support for disabling the volume slider in the test menu, as used by the single board games (eg, mvscjsing). These games didn't have the digital controls (they replaced them with a volume knob), and the test screen shouldn't display the slider (confirmed by Smitdogg).

- 0.144u2: Angelo Salese removed deprecat.h usage from CPS2 driver. Fixed graphical glitches in various CPS2 games test menu.

- 0.141u2: A new WE DSP16A CPU disassembler [Andrew Gardner].

- 24th January 2011: Dr. Decapitator - The Capcom DSP16A (#17 on the status page) has been decapped.

- 6th May 2010: Smitdogg - The rare Capcom boards just arrived. They are: Street Fighter EX2 (980312 Hispanic), Gigawing (990222 Hispanic), Street Fighter Alpha 3 (980629 Hispanic), X-Men: Children of the Atom (950105 Hispanic), D&D: Tower of Doom (940113 Hispanic) (test location version) and Eco Fighters (931203 Hispanic) (test location version).

- 25th April 2010: Smitdogg - We have gotten all of the rare Capcom boards I mentioned before for less than I thought we would have to pay for them. I am considering stockpiling donations for a few weeks to try to get one of the super rare games available which cost between $950 and $10,000 each.

- 20th April 2010: Smitdogg - A bunch of hard to find versions of old Capcom games are temporarily available but we need to raise some money. I'm putting what's left in the donations toward them but it won't be enough to get them all so if you can donate, please click here. Thanks!

- 13th March 2010: Smitdogg - Bill D. dumped some CPS2 PALs.

- 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: Roberto Zandona fixed corrupt graphics in CPS2 games. Changed region gfx1 to gfx.

- 0.126u3: Firewave fixed all parent CPS2 games abort.

- 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].

- 12th February 2008: Mr. Do - The rest of the instruction cards from CPS2Shock are in now, for your Capcom playing pleasure. The only thing I'm unsure of is if the proportions of the cards. If you notice, they are all the same size, as if they were all resized to be the same. And if you compare a couple of the scans I got from Tormod to the same game from there, they don't match. So, if you have any CPS2 cards lying around, feel free to send a scan my way (or you can loan me the card for scanning, and I'll pay for return shipping). Oh, and that goes for any artwork.

- 0.122u8: Changed 68000 CPU1 clock speed to 16MHz.

- 13th January 2008: Mr. Do - I'm FINALLY getting to the rest of the instruction cards Tormod sent me about a year ago =P. First off, the rest of his CPS2 stuff: Battle Circuit, JPN version of Marvel SH vs. SF, SF Zero 2. To round out the above CPS2 games, the instruction cards for Marvel vs. Capcom (JPN), SFZero 2 Alpha, and SF Zero 3 from CPS2Shock were added. Next update, we should see the rest of the instruction cards from CPS2Shock.

- 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 MAME crashed if you do a hardware reset in CPS-2.

- 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: Added machine\cps2crpt.c. 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.

- 0.65: Fixes to CPS2 raster effects [Shiriru].

- 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.

- 0.62: Improved raster effects in CPS2 games [Barry Rodewald].

- 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.

- 0.61: Preliminary support for raster effects in CPS2 games [Barry Rodewald].

- 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.

- 0.55: Fixed MAMETesters bug cps2c054ora.

- 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.



 Strumenti 
Versione per la stampa
Link diretto alla scheda del gioco

Link HTML per pagine WEB, solo testo
Link HTML per pagine WEB, con immagine
Link BBcode per forum, solo testo
Link BBcode per forum, solo testo