Closed Cibomatto2002 closed 1 year ago
Minor stuff isn't it
it is Minor just pointed it out because that was the only thing that I seen that was wrong. Do I need to close this then?
Sure we appreciate the heads up i did check the MAME WIP for this game looking for a fix which mentioned this issue directly but alas there are none, and since there have been many changes to the CPS2 video code over the years pinning down which of said changes fixes the issue you mentioned it would be kinda like looking for a needle in a 100 haystacks.
But certainly feel free to leave this open for now even if it's closed it will remain on record should someone feel like looking into this again sometime down the road.
Could try ASAN to see if there's something overflowing maybe.
does asan work on android?
I don't think so.
Pitty would have been handy with the android studio debugger. Just a heads up this cores savestates are not fit for deterministic unless you update loads of files;
I'm not very diverse on these, I was under the impression libretro-super was being phased out? Core options were also wrongly set, but didn't seem to hurt. What do you think it should be?
for ra should be basic on this core. Mame current is rock solid though. This core will crash if they use use load save states when the states arent working properly. I remember i had to fix double dragon for testing the ending. Libretro super has nothing to do with the setting its the core.info files they tell ra what the core can support. Its nothing new its always been the case. changing it to deterministic is saying you have great level save states and ra will enable the functions. The harm will come when people use states that done work. I dont use any of these features anyway and people who know what they are doing can just edit the nfo file.
https://github.com/libretro/mame2003-plus-libretro/issues/1433 for reference.
What about using serialized vs basic?
You would need to look at the ra source or ask ask in discord which one disables the auto save and load options for RA. I would need to look through the source again to answer that question.
The core is in a state where games can be fixed if savestates dont work if your willing to put the work in. So if your willing to fix the states that need done you can set it to deterministic. Nothing is fullproof not even fbneo. I think they work on the assumption it works until reported otherwise the fix it as there is no savestate flags per game that its supported. You are being mislead the core info files always controlled this its nothing to do with libretro super. The core info repo is here https://github.com/libretro/libretro-core-info
I'll look into it. Im assuming these features are more so hidden when set to a lower level but possibly still accessible through the menu still if you know where to look. I'll reach out and see what they suggest for us here.
Ok here's the response I got, in light of this we can just use basic.
For a complex core that behaves differently depending upon the internal driver being used, I think I'd go for 'basic'. The user can always disable 'feature filtering based on core info' via the menu, if they want to experiment and try runahead and suchlike for specific games
yea I tend to agree with that unless someone comes along willing update drivers for this core.
back on subject, here is the cps2 changelog
Bugs:
- mmancp2u, megaman2, mpang, pzloop2, dimahoo, progear: Known issues of inputs. Source (ID 02302)
WIP:
- 0.246: Changed driver to capcom\cps2.cpp, capcom\cps2comm.cpp/h and capcom\cps2crypt.cpp/h.
- 0.244: Added machine\cps2comm.cpp/h.
- 0.224: Use ROM_LOAD_64_BYTE macro where appropriate [Vas Crabb].
- 0.222: READ/WRITE macros removal [Osso].
- 0.212: Use standard romentry.h macros [Osso].
- 0.209 : Rework 68000 interrupt handling: Implemented the cpu space as an address space. Make all vectored interrupts use the cpu space. Make it possible to direct the cpu space to another space, use it for amiga (which handles it as a normal AS_PROGRAM read). Make it possible to disable the priority muxer and get 3 lines instead, use it for CPS2 [O. Galibert].
- 0.208: Removed MACHINE_CONFIG macros [Osso].
- 0.207: Removed MCFG macros [Osso].
- 0.206: Removed TIMER MCFG macros [Osso].
- 0.205: Do cps2_set_sprite_priorities() before video update instead of at interrupt handler. Fixes sprite priority problem in mvscu, xmvsf and mshvsf on final stage (8) with Onslaught (large transformation) [hap].
- 0.201: Q-Sound: Added device_clock_changed [smf]. Saturate ROM offsets (sound\qsoundhle.cpp). Apply ADPCM sample bank (sound\qsound.cpp) [superctr]. Added improved qsound_hle core. Use ROM lookups instead of copying tables at init and use enums for most DSP ROM addresses. Replacing memset at the cost of legibility (sound\qsoundhle.cpp). Fixes awful buzz sound noise in the Super Street Fighter series [Lord Nightmare]. Removed EEPROM MCFG macros [Ryan Holtz].
- 0.198: Separated state class for CPS2 [AJR].
- 0.196: Improved DSP16 disassembler - less ambiguous, more like the manual (cpu\dsp16\dsp16dis.cpp). Cycle-accurate DSP16 core (disabled in QSound for performance reasons) [Vas Crabb]. Changed QSound (HLE) sound clock speed to 60MHz. Removed DSP16A CPU3.
- 0.192: Added MACHINE_NODEVICE_LAN flags [Osso].
- 27th October 2017: Smitdogg - Cave 1st Gen emulation accuracy project launch: With many Cave games it is especially important to get extremely accurate emulation because they were programmed with the pushed limitations of the original hardware in mind when making them, maxing them out to the point of slowdown often. In order to get MAME closer to the PCBs we can send boards to Phil Bennett and he'll add them to his work list and will be able to perfect things like video timings and pixel data. For example in ESP Ra.De. the game slows down more on the PCB than in MAME, and it sometimes has sprites disappear when there is "too much" on screen, and it actually makes a cool looking overload effect on the PCB and a timing that makes survival slightly easier, something obviously important if acuracy is your goal. Something similar happens with Progear and other games. We need a deeper testing by Phil. I sent the CPS2 setup mentioned here a while ago to Phil, it will arrive in a few days. I hooked up a mix of *several* CPS1 games. He will be able to get a large range of testing done and the emulation updates I'm sure will be awesome. If anyone has a 1st Gen Cave game PCB they will *loan* to Phil (not asking for donations with these wildly expensive PCBs), let me know, and let's get this emulation of these games perfected so when your board dies your heart doesn't. You can also donate paypal and I will offer the donations as shipping payments for any board owners who don't feel like paying shipping but will therwise loan it out. Let's get the accuracy updated.
- 0.186: Updated QSound/DL-1425 ROM and comments with corrections from recent decap [Lord Nightmare, Siliconpr0n, superctr, Quench].
- 0.180: Added achine\cps2crypt.h. Changed the DSP16A disassembler to use 'std::ostream &' internally [Nathan Woods]. Fixed a bug in DSP16 caused by incorrect use of macro [Vas Crabb].
- 0.178: Removed machine\cps2crypt.h. Use keys that can be programmed onto a CPS2 motherboard [smf, Eduardo Cruz, Andreas Naive]. Small step towards getting rid of the cps2_dead machine config [smf].
- 0.173: Changed machine\cps2crpt.cpp to machine\cps2crypt.cpp [Tafoid].
- 0.168: Fixed some strncmp in CPS2 driver [Miodrag Milanovic].
- 0.164: Added machine\cps2crypt.h.
- 0.159: Added Q-Sound amp board notes [hap].
- 0.153: Cleanup QSound. No practical changes here except that i removed support for LOG_WAVE raw sound filewriting. Updated soundstream before writing (tsk). Reg 3 is key on. Small fix to sample start and loop. Guru measured qsound music timing. Modified CPS1 video params. Added DSP pin info from Guru [hap]. Eliminate pointless planar-to-chunky conversion of gfx ROMs, just decode them as-is [Alex Jackson]. Changed VSync to 59.637405 Hz.
- 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 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: Derived CPS2 video timing based on measurements. These are educated guesses. The logic behind the derivations is shown in the source. Fixes the disappearing volume bar in the test menu for msh, mshvsf, xmvsf, xmcota and nwarr for sound and voice [Aaron Giles]. 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.
@MistyDreams where did you get the WIP from again i mind you telling me a while back but as per usual i've forgotten :) I'll look at the wip and mametesters later to see if there are any mentions of this issue and hopefully a simple fix as i dont really wanna make a major change to the video code.
As i'd feel i'd have to test every game afterwards and well there are many of them and i dont have the time nowadays this is what puts me off backporting the nice gfx improvements for Varth but that is another CPS driver and another story.
I get the mameinfo from https://mameinfo.mameworld.info/ just open the mameinfo.dat with a text editor. I just search cps2.cpp (need to use current mame drivers cpp name for whatever driver your looking for).
0.105u1: David Haywood updated CPS driver to more accurately draw tilemaps, based on evidence from a board with mixed ROMs. looks promising and 0.71u2: Shiriru fixed CPS2 raster effect is done already.
what is the issues with varth?
what is the issues with varth?
0.124u4: Fixed layer enable at the end of stage 4 in Varth.
Now this comes as part of a huge change after earlier big changes, i've never got as far as level 4 so i cannot confirm whether there is a problem with Varth in our core or it was confined to later builds before being fixed.
I remember the Coinops dev mentioning he'd backported the fix so i assume we'd need it but due to xbox scene drama he sometimes tried to send me down the wrong road codewise by claiming he'd fixed this that or the other hoping i'd try to do likewise so might be one of those type deals i'll have to play the game up till the end of level 4 to find out either way :)
Thank you !!
its not the easiest of games if cheats are available ill try play it up to level 4. I get the feeling the cpu might be enough to fix it could be wrong though. Its a pretty big update for one game.
edit played it through with the cheats (in the metadata folder) seems fine to me comparing it you a you tube video. Just the cpu speed needs upped. Must have been the newer code that needed a tweek.
its not the easiest of games if cheats are available ill try play it up to level 4. I get the feeling the cpu might be enough to fix it could be wrong though. Its a pretty big update for one game.
edit played it through with the cheats (in the metadata folder) seems fine to me comparing it you a you tube video. Just the cpu speed needs upped. Must have been the newer code that needed a tweek.
Yeah some titles will need switched as per their boardtypes i meant to do this some years back but obviously i slacked off :) Good news about Varth though.
Ok as per the latest MAME CPS1 driver im updating ours to reflect the later findings regarding the correct clock speeds for certain games i'll plod way at this over the next day or so, what's slowing me down is set name changes and or newer dumps which means i have to double check the main cpu roms to know what versions we have.
I really wanted to fix the all not working sets when I done the encryption. Its very easily done but people seem to upset on this type of progress. For reference the ones with my_cps2 init are the ones i changed.
What were the objections again i cant remember.?? maybe it was romsets as you'd be removing XOR's right.??
no objections from here didnt go there after the system16 cleanup discussions. No way to update a system and keep the 2003 base set mostly the same.
Hmm well sure 100's of romsets will need to change but we've never shied away from updating romsets to better improve the emulation before have we.?? hell users have come to expect that when it comes to this core. maybe time to start a thread on this with the pros and cons ya know.
I think this core near enough what it can do, no reason not to polish up whats already done though. The other thing I think that needs tlc is the input tags.
Just wondered if cps3 will ever be added ? Would like to play Street Fighter III if not it's ok.
I think we would need to so a soundcore for that. Its a lot of work for this core even cpu cores are a nightmare to do. Things like that would be more suited to a higher core that also has address spaces. Its a pitty we are not at 079 at lease so much more would be doable. Maybe someone else would be willing though. I can only speak for myself though.
I thought it would be to much to ask all this talk about CPS got me thinking about that game. Thanks for your time.
im updating the cps drivers to latest mame romsets need to do some testing though before committing ...
I think we would need to so a soundcore for that. Its a lot of work for this core even cpu cores are a nightmare to do. Things like that would be more suited to a higher core that also has address spaces. Its a pitty we are not at 079 at lease so much more would be doable. Maybe someone else would be willing though. I can only speak for myself though.
Well apart from the workload we have to factor in the performance using the Xbox as a benchmark which tends to be in the same ballpark as many of the devices this core is aimed at the CPS3 games preform terribly so even if we did the graft not many would see the benefits as these games would be too slow to be enjoyable.
Now there was a standalone CPS3 emulator chock full of speedups available for the Xbox and the games played lovely using it but alas there was no source code ever released for it otherwise it would likely have found it's way onto the libretro platform already solving the problem of how to play CPS3 games on lower spec hardware
I don't have a Xbox just wondering how good does Final Burn Alpha 2012 run on it? I see it has cps3
I got all the new roms cps2 in. Every single one boots only managed to got up to 1996 so far never seen any issues in game.
The comm board games arent booting they are just sticking at the terminal screen. I think is was sf2 turbo at least one of the sets had a small square in the title screen. Some games are showing the coin counter overlays but one game only does it when you press a button. The inputs will need done properly at some point. eco fighters controls just dont work period and will need done properly. Ill look at the input after checking all the sets boot fine roughly correct inputs are enough to test for now.
I don't have a Xbox just wondering how good does Final Burn Alpha 2012 run on it? I see it has cps3
Well the standard xbox only has 64mb of memory so the console cannot boot CPS3 games using FBA however some users choose to upgrade the capacity to 128mb for reasons which escape me but as a result their consoles could boot the games but folks said they played too slow as the console simply didn't have the power under the hood to run em.
Sidenote iq_132 once had those games running using FBA on a standard xbox with speedups and the games were more or less there barring when the special moves were used then they'd slow down again he planned to tweak the code to sort that when he found the time but alas he lost the source code and it wasn't to be.
There ya go all the history of CPS3 emulation on the xbox whether you wanted to know about it or not :)
Thanks interresting read.
The good news is all the original cps2 sets now boot and play bar one sf2 tag tournament that just shows the terminal screen. The testing was the biggest hurdle here. It takes a lot of time to boot and play 272 games even for a few secondsb ike i did. The ones that needed gfx fixed got em.
On most bootlegs gfx are offset but I want to look into a more generic fix down the road rather than making nearly 50 entrys in the video code for the games setup(just marked them imperfect gfx for now) . All thats left is to verify the the imputs I havent checked over then ill put a pull request in. Ive seen enough cps2 in the last few days but will finish up soon.
Aye as Roy Castle once said "dedication is what ya need" good job
I have not played the game at this time past the character select screen i'm just downloading some games to play later this week and seen this bug.