leonardoliveira & Idc's clean decrypted roms
- yosai
- Windy City
- Posts: 4057
- Joined: August 17th, 2008, 5:00 pm
- Location: London
- eBay: yosai
Re: CPS2 Development PCB - SFZ
& all in one.
- KmanSweden
- KmanSweden
- Posts: 1242
- Joined: October 13th, 2010, 10:37 am
- Location: Stockholm, Sweden
- eBay: KmanSweden
- Initials: PKK
- Contact:
- WilalvesBR
- Posts: 36
- Joined: December 14th, 2011, 1:42 pm
- Location: Brazil
- eBay: Wilalvesbr
- Initials: WIL
Re: CPS2 Development PCB - SFZ
Best game in the series!leonardoliveira wrote: Another weekend, another game:
Brazil version:
Counting the days for the next weekend!!
- idc
- Ralf Little impersonator
- Posts: 1311
- Joined: October 16th, 2008, 9:17 pm
- Location: Tamworth, Staffordshire
- eBay: iancourt
- Initials: IAN
- Contact:
- leonardoliveira
- Please Continue...
- Posts: 692
- Joined: August 30th, 2012, 5:53 am
- Location: Brazil
- Initials: leo
Re: CPS2 Development PCB - SFZ
This one is special for me...
It's the first CPS2 game I've ever seen. Back in 1994, when it was new.
<CURSES>
SHOW VERSION flag enables "FREE PLAY" at the SYSTEM CONFIGURATION:
STOP VERSION flag enables CAPCOM's debugger:
(I caused that crash through messing the stack to cause it to show up)
It's the first CPS2 game I've ever seen. Back in 1994, when it was new.
<CURSES>
SHOW VERSION flag enables "FREE PLAY" at the SYSTEM CONFIGURATION:
STOP VERSION flag enables CAPCOM's debugger:
(I caused that crash through messing the stack to cause it to show up)
Last edited by leonardoliveira on August 11th, 2013, 2:01 am, edited 1 time in total.
- MrSandman
- Posts: 347
- Joined: October 9th, 2010, 9:00 pm
- Location: Germany
- eBay: Not yet, not trading yet
- Initials: NOR
Re: CPS2 Development PCB - SFZ
Do you intend to clean every CPS2 game, including all region versions, or do you only clean certain games?
What is your priority in selecting the games? Popularity of the game, severity of problems with the phoenixed set, easeiness to reprogramm?
It seems a lot an tedious work, so you'd have to sacrifice a lot of weekends if you'd wanted to reprogramm every game and region, right?
What is your priority in selecting the games? Popularity of the game, severity of problems with the phoenixed set, easeiness to reprogramm?
It seems a lot an tedious work, so you'd have to sacrifice a lot of weekends if you'd wanted to reprogramm every game and region, right?
"Hans, I've just noticed something."
- leonardoliveira
- Please Continue...
- Posts: 692
- Joined: August 30th, 2012, 5:53 am
- Location: Brazil
- Initials: leo
Re: CPS2 Development PCB - SFZ
I'm doing the games as I feel the need to or as people request (I've done Mitchell stuff because idc asked but turns out I liked Choko a lot after doing it). Some of these roms were hacked for some commissioned work (on real face to face dealings, not through internet) as I service boards for local operators here.MrSandman wrote:Do you intend to clean every CPS2 game, including all region versions, or do you only clean certain games?
What is your priority in selecting the games? Popularity of the game, severity of problems with the phoenixed set, easeiness to reprogramm?
It seems a lot an tedious work, so you'd have to sacrifice a lot of weekends if you'd wanted to reprogramm every game and region, right?
For example, the SFZ2A rom I did for a person to recover his game which was the Brazil 960813 revision. If you burn Razoola rom which is of a newer revision (he picked the most recent revisions on all of his releases) you end needing to erase all eproms. With my hack, you get to keep the Capcom sticker on all the chips but 03 and 04 which need to be changed.
Even when your game is the same revision as the Raz rom, sometimes you need to erase an extra chip as it has the phoenix menu in it. An example is Pocket Fighter, which has the phoenix code at the last eprom. That game only has the first chip encrypted.
I've done Vhuntjr1 and vampjr1 because I like the games.
SFA3 Brazil I've done because someone wanted a board resurrected and I thought I could pull out that stunt. It worked great in the end... lol
There's some games I've done that are not on the list here, but idc will host them publcly. I'll eventually look all the games.
I'm open to suggestions. As you mention, there's phoenix games that do not work right. Care of listing them here ?
- WilalvesBR
- Posts: 36
- Joined: December 14th, 2011, 1:42 pm
- Location: Brazil
- eBay: Wilalvesbr
- Initials: WIL
Re: CPS2 Development PCB - SFZ
Hey Leo, how about doing the same fix on the euro version of the game (Darkstalkers: The Night Warriors Euro 940705)?leonardoliveira wrote: I've done Vhuntjr1 and vampjr1 because I like the games.
The euro version has language options (portuguese included)!
It would be great because the brazilian version has not been dumped/found yet even it being one of the most popular games back in the days.
- pubjoe
- Fosters Political Ambitions
- Posts: 9836
- Joined: August 19th, 2008, 8:58 am
- Location:
Re: CPS2 Development PCB - SFZ
Hi Leonardoliveira,
Amazing work here.
I hope you don't mind me asking but have you received any negative feedback for these 'clean' roms? I remember when razoola began providing phoenix roms there was talk of the "phoenix edition" graphic being an important addition so as to differentiate modified boards from unmodified boards - or at least, to the casual user (like me).
...Not that this is of any importance to me, I'm just playing devil's advocate. I don't know if it's even worth much consideration seeing as preventing extinction of CPS2 is by far the greater cause. I just know that that simple phoenix graphic sparked a bit of debate back in the day.
Amazing work here.
I hope you don't mind me asking but have you received any negative feedback for these 'clean' roms? I remember when razoola began providing phoenix roms there was talk of the "phoenix edition" graphic being an important addition so as to differentiate modified boards from unmodified boards - or at least, to the casual user (like me).
...Not that this is of any importance to me, I'm just playing devil's advocate. I don't know if it's even worth much consideration seeing as preventing extinction of CPS2 is by far the greater cause. I just know that that simple phoenix graphic sparked a bit of debate back in the day.
- leonardoliveira
- Please Continue...
- Posts: 692
- Joined: August 30th, 2012, 5:53 am
- Location: Brazil
- Initials: leo
Re: CPS2 Development PCB - SFZ
That's why Capcom put pins and stickers on their products. To differentiate a botleg from a original product. I hacked these games trying to make legitimate boards work so I want them to work as they did when they were still encrypted.pubjoe wrote:Hi Leonardoliveira,
Amazing work here.
I hope you don't mind me asking but have you received any negative feedback for these 'clean' roms? I remember when razoola began providing phoenix roms there was talk of the "phoenix edition" graphic being an important addition so as to differentiate modified boards from unmodified boards - or at least, to the casual user (like me).
...Not that this is of any importance to me, I'm just playing devil's advocate. I don't know if it's even worth much consideration seeing as preventing extinction of CPS2 is by far the greater cause. I just know that that simple phoenix graphic sparked a bit of debate back in the day.
I have not received any negative feedback yet as since 2010 when I started working with this stuff I was only able to do three games. After a discovery I made (I learned how to use the disassembler correctly with the CPS2 compiled game programs) I was able to put out like 12 games in a period of a month. So this might be too new for any feedback to be created.
Also, there's another difference on my work. I acknowledge these games do not belong to me, they belong to Capcom so I don't feel like it's right to paste some macro of code in it then sell it even if the price is just for "the service" of reviving the game. So I make the hacks, put it on the public domain and good luck everyone. You see, I don't want any stress from this.
If people make bootlegs of the games, it's up for the buyer (and honestly it's very easy to tell a bootleg apart from a legitimate game, even if it is repaired with my ROMs) by opening the B board top cover and checking the kind of chips that are installed. A bootleg will have 100% EPROMs on the board while a legit game will have MASKROMs on everything but the ROMs with CODE for sound and main CPU.
Very few exceptions do exist but these will have CAPCOM stickers on their EPROMs as well. So bootlegging does not concern nor worries me at all. I just want people to be happy. I made some of these games decrypted for learning, for joy and for personal pleasure. I hope it makes other people happy, too. Now that the boards are dying and several zones are no longer supported I suppose efforts like mine or Razoola's are the only real way to preserve the real hardware in working conditions.
- pubjoe
- Fosters Political Ambitions
- Posts: 9836
- Joined: August 19th, 2008, 8:58 am
- Location:
Re: CPS2 Development PCB - SFZ
Brilliant reply.
- KmanSweden
- KmanSweden
- Posts: 1242
- Joined: October 13th, 2010, 10:37 am
- Location: Stockholm, Sweden
- eBay: KmanSweden
- Initials: PKK
- Contact:
Re: CPS2 Development PCB - SFZ
I had a look over at assembler and noticed you've done Puzz Loop2. Care to share a URL?leonardoliveira wrote: There's some games I've done that are not on the list here, but idc will host them publcly.
It didn't say what revision but I'm guessing there's only one?
Up the Irons!
- MrSandman
- Posts: 347
- Joined: October 9th, 2010, 9:00 pm
- Location: Germany
- eBay: Not yet, not trading yet
- Initials: NOR
Re: CPS2 Development PCB - SFZ
Hi leonardoliveira,
could you please explain what you mean by "Mitchell and Choko stuff"?
As for listing problematic Phoenix ROMs, I've not had any experience any so far - I only know of problems from reading threads here and there (IIRC SFZ3 and SSF2X some winning quote text mess-ups in English settings).
Would testing the ROMs in MAME suffice (wouldn't know how and where to start)?
When debugging the games, do you also look at the code, i.e. how the AI was programmed or how much of the same code is being reused for different games (say how much code is borrowed between the different fighting games or puzzle games etc).
could you please explain what you mean by "Mitchell and Choko stuff"?
As for listing problematic Phoenix ROMs, I've not had any experience any so far - I only know of problems from reading threads here and there (IIRC SFZ3 and SSF2X some winning quote text mess-ups in English settings).
Would testing the ROMs in MAME suffice (wouldn't know how and where to start)?
When debugging the games, do you also look at the code, i.e. how the AI was programmed or how much of the same code is being reused for different games (say how much code is borrowed between the different fighting games or puzzle games etc).
"Hans, I've just noticed something."
- idc
- Ralf Little impersonator
- Posts: 1311
- Joined: October 16th, 2008, 9:17 pm
- Location: Tamworth, Staffordshire
- eBay: iancourt
- Initials: IAN
- Contact:
Re: CPS2 Development PCB - SFZ
Downloads will be made available shortly, we just have some final testing on hardware to do (testing on MAME alone is not enough - CPS2 hardware is actually far less tolerant to bugs than MAME).KmanSweden wrote:I had a look over at assembler and noticed you've done Puzz Loop2. Care to share a URL?
It didn't say what revision but I'm guessing there's only one?
There are two revisions of Puzz Loop 2. Leo has done only the older, more common revision at present. The newer version was dumped and submitted to MAME by me a few months ago...
- KmanSweden
- KmanSweden
- Posts: 1242
- Joined: October 13th, 2010, 10:37 am
- Location: Stockholm, Sweden
- eBay: KmanSweden
- Initials: PKK
- Contact:
Re: CPS2 Development PCB - SFZ
Cool.idc wrote:Downloads will be made available shortly, we just have some final testing on hardware to do (testing on MAME alone is not enough - CPS2 hardware is actually far less tolerant to bugs than MAME).KmanSweden wrote:I had a look over at assembler and noticed you've done Puzz Loop2. Care to share a URL?
It didn't say what revision but I'm guessing there's only one?
There are two revisions of Puzz Loop 2. Leo has done only the older, more common revision at present. The newer version was dumped and submitted to MAME by me a few months ago...
I'll check what rev I need then..
Up the Irons!
- leonardoliveira
- Please Continue...
- Posts: 692
- Joined: August 30th, 2012, 5:53 am
- Location: Brazil
- Initials: leo
Re: CPS2 Development PCB - SFZ
WARNING
THIS POST MIGHT CONTAIN A WALL OF TEXT.
There's two ways of decrypting the games. One is XOR CLASH two revisions of the game with exact same program code and the other is completely disassemble the game on an interactive disassembler. The two ways are prone to errors but the automated way (XOR CLASH) leaves you with a extra trouble of finding where the mistakes are. I found a solution for that issue, which almost perfected the method. Issues with disassembling the game could happen from overlooks, mis disassemblies or plain traps set up by CAPCOM within the code. Anyway, I had Rockman working correctly after I finished disassembling it. I had very minor glitches in Quiz Nanairo Dreams, which came to be from overlooking instuctions somewhere.
Vampire the Night warriors was done through disassembly method.
I had three crashes in it:
- At Gallon stage the props that break at the background would cause address errors. -> This one was a set of data that was supposed to be treated as not encrypted data was left by me in the state it is after run through the encryption.
- One move from ZabelZarock would cause a illegal instruction exception. -> Sometimes the borderline of where data and instructions are laid up on the ROM are quite cloudy.
They like to use small jump table patterns within the code branches to change what the game will do. The data with the relative offsets for the jumptables are aways envrypted at it's read relative to the program counter. Stuff that is read from fixed addresses using the address registers for indexing are read in the exact way they are stored in the EPROM chip. Also since the CRC check code reads the whole rom using either a program counter relative instruction or a normal instruction, the act of decrypting the ROM causes the CRC to change. So it will aways fail the CRC check after decrypted ...
So an overlook on knowing what region is code or data may cause either illegal instruction exception (as it jumps somewhere it was supposed to have a instruction but there's a chunk of corrupted data) or a wrong pointer causes it to jump to a wrong place or try to read a word or long word at an odd address causing a address error. Anyway if it's just reading data, the address is even but it's a wrong address, you have other odd kinds of glitches (perhaps this is what happens with the Super Street Fighter 2 ROM that supposedly has text glitches or show characters check boxes during game play...) which are pretty tough to trace/debug.
- An odd behavior on the game over screen with Vampire the Night Warriors (read above about data words being read from wrong addresses... An pointer was being fetched from a wrong address because the routine that reads the data would do so using a pointer fetched by another routine that ran before it... ) the game would not show "GAME OVER" after the continue counter expired.
Problems with data that trigger no exceptions or errors are particularly nasty to find, but to figure out where exactly it is at I use NEBULA or any other emulator which still use XORs to make certain regions of the ROM be what they were like when they were still envrypted. I test the game and see where I replace the data with the original encrypted data fixes the issue. When I find the exact offending offset I disassemble it and study how it works in detail.
That brings me another problem: Know if there is any glitches to check ...
And that's where testing helps a ton. Having lots of smart, interested people test these games would help big time.
That's exactly what idc was talking about when he said "we just have some final testing on hardware to do (testing on MAME alone is not enough - CPS2 hardware is actually far less tolerant to bugs than MAME)"...
We tried to run Ultimate Ecology and while it worked on MAME just fine, it would crash on his board. I burnt the game on EPROMs to test and found the exact same fault (It would freeze after displaying the region of use warning). Turns out it was still writting to the CPS2 sprite control register when it was clearing the ram before start the main game loop.
It was a 5 minutes fix. There's a huge loop routine that cleans 16 bytes per loop. Patched the main counter to make it loop a couple times less and game was booting perfectly. Played it several times and no glitches to be seen.
Still, MAME is the core tool on this process.
Unfortunately you have no labels on a assembly listing done through reverse engineering and to get that much information from a game engine you would easily pour down a year of your life in such a project. So, no I only look deeply at code that is causing trouble and only when I have a good idea where the problem is at (see the text above about using NEBULA as debugging tool).
Also I aways enable CAPCOM's debugger on any ROMs I deal with. Mitchell games have no debugger (well Puzzloop 2 does but I didn't bother using it, the game worked outright. Simple code on Mitchell's stuff was easy enough)..
THIS POST MIGHT CONTAIN A WALL OF TEXT.
It's more like "Mitchell stuf"... idc asked me to decrypt Mighty Pang, which I did. It was one of the first games I completely disassembled for obtaining the map of what is encrypted and not encrypted within the ROM. Because of that, I decrypted Janpai Puzzle Choko out of a spite, followed by Puzzloop 2. That's what I meant by "Mitchell stuff".MrSandman wrote:Hi leonardoliveira,
could you please explain what you mean by "Mitchell and Choko stuff"?
I remember that Raz rom for Pocket Fighter/Super Gem Fighter have some odd quirk with the AI. Turned out it was just one single wrongly decoded word somewhere in the middle of the data.MrSandman wrote: As for listing problematic Phoenix ROMs, I've not had any experience any so far - I only know of problems from reading threads here and there (IIRC SFZ3 and SSF2X some winning quote text mess-ups in English settings).
There's two ways of decrypting the games. One is XOR CLASH two revisions of the game with exact same program code and the other is completely disassemble the game on an interactive disassembler. The two ways are prone to errors but the automated way (XOR CLASH) leaves you with a extra trouble of finding where the mistakes are. I found a solution for that issue, which almost perfected the method. Issues with disassembling the game could happen from overlooks, mis disassemblies or plain traps set up by CAPCOM within the code. Anyway, I had Rockman working correctly after I finished disassembling it. I had very minor glitches in Quiz Nanairo Dreams, which came to be from overlooking instuctions somewhere.
Vampire the Night warriors was done through disassembly method.
I had three crashes in it:
- At Gallon stage the props that break at the background would cause address errors. -> This one was a set of data that was supposed to be treated as not encrypted data was left by me in the state it is after run through the encryption.
- One move from ZabelZarock would cause a illegal instruction exception. -> Sometimes the borderline of where data and instructions are laid up on the ROM are quite cloudy.
They like to use small jump table patterns within the code branches to change what the game will do. The data with the relative offsets for the jumptables are aways envrypted at it's read relative to the program counter. Stuff that is read from fixed addresses using the address registers for indexing are read in the exact way they are stored in the EPROM chip. Also since the CRC check code reads the whole rom using either a program counter relative instruction or a normal instruction, the act of decrypting the ROM causes the CRC to change. So it will aways fail the CRC check after decrypted ...
So an overlook on knowing what region is code or data may cause either illegal instruction exception (as it jumps somewhere it was supposed to have a instruction but there's a chunk of corrupted data) or a wrong pointer causes it to jump to a wrong place or try to read a word or long word at an odd address causing a address error. Anyway if it's just reading data, the address is even but it's a wrong address, you have other odd kinds of glitches (perhaps this is what happens with the Super Street Fighter 2 ROM that supposedly has text glitches or show characters check boxes during game play...) which are pretty tough to trace/debug.
- An odd behavior on the game over screen with Vampire the Night Warriors (read above about data words being read from wrong addresses... An pointer was being fetched from a wrong address because the routine that reads the data would do so using a pointer fetched by another routine that ran before it... ) the game would not show "GAME OVER" after the continue counter expired.
Problems with data that trigger no exceptions or errors are particularly nasty to find, but to figure out where exactly it is at I use NEBULA or any other emulator which still use XORs to make certain regions of the ROM be what they were like when they were still envrypted. I test the game and see where I replace the data with the original encrypted data fixes the issue. When I find the exact offending offset I disassemble it and study how it works in detail.
That brings me another problem: Know if there is any glitches to check ...
And that's where testing helps a ton. Having lots of smart, interested people test these games would help big time.
No, because some behaviors of MAME do not match the real board. For example writes from the RAM TEST code or from the RAM CLEAR that is done after the RAM TEST to the CPS2 sprite layer control register (0x400000 region on normal battery clad boards, 0xFFFFF0 at dead boards) cause an exception which freezes the real board. That does not happen on MAME. I suspect that's intentional and was meant to confuse anyone who eventually managed to decrypt a game as a last effort to make the hacker give up from hacking (lol).MrSandman wrote: Would testing the ROMs in MAME suffice (wouldn't know how and where to start)?
That's exactly what idc was talking about when he said "we just have some final testing on hardware to do (testing on MAME alone is not enough - CPS2 hardware is actually far less tolerant to bugs than MAME)"...
We tried to run Ultimate Ecology and while it worked on MAME just fine, it would crash on his board. I burnt the game on EPROMs to test and found the exact same fault (It would freeze after displaying the region of use warning). Turns out it was still writting to the CPS2 sprite control register when it was clearing the ram before start the main game loop.
It was a 5 minutes fix. There's a huge loop routine that cleans 16 bytes per loop. Patched the main counter to make it loop a couple times less and game was booting perfectly. Played it several times and no glitches to be seen.
Still, MAME is the core tool on this process.
The CPS2 games seem to be coded in either C# or CPP so the code look like a big construction of .... LEGOS !MrSandman wrote: When debugging the games, do you also look at the code, i.e. how the AI was programmed or how much of the same code is being reused for different games (say how much code is borrowed between the different fighting games or puzzle games etc).
Unfortunately you have no labels on a assembly listing done through reverse engineering and to get that much information from a game engine you would easily pour down a year of your life in such a project. So, no I only look deeply at code that is causing trouble and only when I have a good idea where the problem is at (see the text above about using NEBULA as debugging tool).
Also I aways enable CAPCOM's debugger on any ROMs I deal with. Mitchell games have no debugger (well Puzzloop 2 does but I didn't bother using it, the game worked outright. Simple code on Mitchell's stuff was easy enough)..
- IDCHAPPY
- c***3
- Posts: 2611
- Joined: May 3rd, 2010, 7:25 pm
- Location: Edinburgh
- eBay: Arcadedreams2013
- Initials: IDC
- Contact:
Re: CPS2 Development PCB - SFZ
Still great work Leo
Give me a like on Facebook at:
https://www.facebook.com/pages/Arcadedr ... ef=tn_tnmn
https://www.facebook.com/pages/Arcadedr ... ef=tn_tnmn
- idc
- Ralf Little impersonator
- Posts: 1311
- Joined: October 16th, 2008, 9:17 pm
- Location: Tamworth, Staffordshire
- eBay: iancourt
- Initials: IAN
- Contact:
- MrSandman
- Posts: 347
- Joined: October 9th, 2010, 9:00 pm
- Location: Germany
- eBay: Not yet, not trading yet
- Initials: NOR
Re: CPS2 Development PCB - SFZ
Thank you for your detailed explanation.leonardoliveira wrote:...
I have no experience with the M68xxx or the CPS2 hardware, but I do get an understanding now what the difficulties are.
As testing in MAME is not enough, you'd need someone who owns a dead, original board, as testing say a Mighty Pang on a Street Fighter Zero board might not be possible (I've read that somewhere regarding conversions - in order to run game A on a board for game B, some modifications are necessary - PALs or something like that)?
"Hans, I've just noticed something."
- KmanSweden
- KmanSweden
- Posts: 1242
- Joined: October 13th, 2010, 10:37 am
- Location: Stockholm, Sweden
- eBay: KmanSweden
- Initials: PKK
- Contact: