JAMMArcade.net – Page 233

Decrypting my own CPS2 ROM’s

General Comments Off

Apr 012012

Ive been messing around, on and off, with decrypting these a while now. Basically I wanted the ROM’s as standard as I could get. No mini menu and no other hidden changes. I also wanted to keep the board region the same and there are some blanks in the Phoenix sets created by Razoola.

Using MAME to save the DASM from a non decrypted set I then made a program to convert that DASM back into binary format.
Once I had this I then added some extra functionality to my program to compare 2 different regions of the same ROM set. Where the data matched on both ROM’s is the unencrypted data and when this happened I replaced the data in my first binary file with the unencrypted data from this comparison.

At this point I know have an unencrypted, unmolested ROM (almost).
There are a couple of points in the original ROM’s which match but are in fact encrypted. I will cover these later on.

As per instructions from Razoola himself at the CPS2Shock website. The ROM must now be patched so all read/writes to the region 0x400000 – 0x40000a are changed to 0xFFFFF0 – 0xFFFFFA. The self test routines must also be patched not to clear this region. Both are pretty easy to do using the MAME debugger to find the areas.

My first conversion was for the Japan version of 1944. When I got to this point and tested in an emulator, I received this message

If 1944 this area is different depending on the region so my simple program treated it as encrypted data resulting in it reading the region code from an incorrect address.
This area is located at address $C2. if the word is set to #$0000 this is the Japan region code. I think #$0002 is for USA but not sure what others are.
I don’t think this region setting affects game play but it does change the language used, especially in the test menus.
As I wanted to keep this as standard as possible I chose to keep the menu in Japanese.

One other thing is that the ROM tests in the test menu will fail. This is caused by invalidating the checksum when patching the ROM. I have also changed the checksum number accordingly to comply with the actual checksum calculated and now the tests pass. The checksum data is held at address $D0. The two address following this in 1944 are also checksum values for the other 2 ROM’s.

There were a couple more instances of my data being wrong and causing crashes but they were soon found by comparing against the genuine game.
Ive tested my ROM on the real hardware and it works just fine from start to finish

WWF Wrestlefest memory test program

Downloads 1 Response »

Mar 282012

I made up a small memory test program for WWF Wrestlefest.
It only tests the 2 background RAM’s at present. My original program tested the foreground and sprite RAM too but the FG test kept failing. After a lot of EPROM erasing I figure it isn’t possible to read the RAM back, only write to it. There may be a way as there are a couple of undocumented writes to areas in the address space.
I got bored after a while and because of this sprite RAM isn’t tested. One day I might finish it, its probably only a few minutes worth of work.

Regarding the undocumented addresses:
The first at $140016 seems to be the watchdog reset and is called by the command clr.w $140016.
The second at $140008 has something to do with the screen output. I found if this wasn’t cleared then some portions of the screen didn’t refresh. This only applied to the FG0 RAM but may also apply to the sprite RAM too.
Neither of these are used or mentioned in the MAME driver and the driver for this game seems to be quite inaccurate compared to the real board.

Ive uploaded the test program and can be used by replacing the EPROMs at location 18 and 19 with 27C020’s or 27C010’s
WWF MemTest Download

WWF Wrestlefest repair log #1

Mar 242012

Been after a genuine board of this for a bit now and this one came along. I thought it might be in full working order but once again eBay lets me down.
This one had jailbars through all the main sprites.

More often than not this is a bad ROM and this was ended up being just that.

In the corner of this board there is a bank of 8 MASKROMs that contain the graphics. Unfortunately none of these are in sockets and as I couldn’t really see anything hugely wrong on the scope.
This game doesn’t have a test mode nor does it carry out any RAM/ROM tests on start up so I wrote a little self test program myself in assembly that tested the sprite RAM at location 0x0c2000 – 0x0c3fff in the address map and simply would display a “P” for a pass or “F” for a fail.

This passed no problem so my hope is for one of the ROM’s to be dodgy as opposed to one of those custom chips.
I set about desoldering them one at a time and checking along the way. After the fourth one I found my problem with a bad ROM dump.

My dump is on the right and the MAME set dump is on the left. As you can see, bit 0 is stuck on.
I fitted a socket and reinstalled the ROM but with data line D0 lifted and checked it out with the scope.

On a closer inspection it shows that the logic level isnt dropping below 2v.
The MASKROMs are pin compatible with 27C080 EPROMs of which I have none. I have ordered some so will hopefully receive it early next week

EDIT: EPROM came today, the game is now fully working

Another CPS1 PAL added

PAL Updates Comments Off

Mar 202012

Balázs emailed me a dump of his KD29B chip from King of Dragons.
His chip was a GAL replacement but he has tested this dump and confirmed it works.
Thanks to him for sending this.

Looking for the Strider (Japan resale) PAL if anyone has it

Missing CPS1 PAL dumps

PAL Updates Comments Off

Mar 182012

Don’t know how I missed these 2 as Ive had the chips for ages.
They are S224B from Final Fight and DAM63B from Daimakaimura.

I know these are already in the MAME sets but I may as well add them myself for completeness.

Older Entries Newer Entries