What's new
I might be willing, but this is the issue...
Before I hand over known working hardware, I want a few day hands on time with the conversion ROMs.

IF it's 100% free of bugs/errors and played perfectly, then and only then would I send the real Punisher board.
Only way I would do it is if all the kinks were worked out. It's not worth it if it isn't exact IMHO.
So yea, its NOT perfect... And I can't have hands on time with it, only videos.
This is a deal breaker in two areas already.

Like everyone has been saying tho, yea I'm in!!!
That's "in" to donate (50$) to a collection to raise the money (seems like we are off to a good start) to get this done.
I won't however be trading him mine. ;)
 
So yea, its NOT perfect... And I can't have hands on time with it, only videos.
This is a deal breaker in two areas already.

Like everyone has been saying tho, yea I'm in!!!
That's "in" to donate (50$) to a collection to raise the money (seems like we are off to a good start) to get this done.
I won't however be trading him mine.
That sucks!

Well I am still in to donate, I will push in $350 maybe a little more toward getting this done. Would love to see a proper punisher conversion on the CPS2 multi, maybe a Cadi & Dinos conversion also?!
 
I was the one doing SF2 Hyper Fighting(A regular CPS1 game). Last thing I did was wake up the Cps-2 Z80 which is different than the one using kabuki.

Here is what I remember
First problem you should do, is Graphic roms need to be interlaced first half with the second half each r which I put on that thread.
Then come the inputs, includes the dipswitches and controller editing. Test switch on HF caused the game to skip every other frame so hard coding the switches fixed that.

Also here is a little helpful info CPS1 and CPS2 handles the Kick Harness very differently so if your game needs it.
https://github.com/jedpossum/HFCPS2/blob/master/P2HK.asm

Also, some CPS1 games treat 0xFFFFF0 ~ 0xFFFFFC as regular memory when dead cps2 boards read that for sprite offset so you have to some hard work to fix this.
 
One of the things that deeply discouraged me on this stuff is the fact that each game has different graphics ROM mapping, where physical address on rom bus vs logical offsets the game write to the PPU hardware to fetch the tiles. That varies from game to game.


I was able to make Punisher graphics ROMs work properly but that game doesn't really use a very complex graphics mapping. Daimakaimura on the other side had me very confused... lol
 
Nice to see there is still some (albeit end) user interrest in this. I gave up on this a while back as i have too little free time to look into this. I started out when i was unemployed, but now i'm back at work and when i get home, i rarely can bring myself to doing things like this.

From Leo's punisher work, at first i thought there would be some "minor" things left to do in Punisher, like sprite priority fixes, but i found out soon, the game also seems protected to a certain degree. You can play stage 1, but after a certain point, enemies will suffer from insta-death and you can just walk all the way to the end of the game. Even the bosses die. :(
 
For that port sound can be a huge question mark does a person/team hack up a qsound program rom and sample roms or figure a way to hack on kabuki to the board. At least for all the cps1 sf2 versions Super Turbo and had all the music for those games including the intro music as ST used it for character select screen.
 
Well, on CPS2 the CPU is part of the B board then it would be tricky to make it work. The B board for it would be quite complex and we still would not be able to use the CPS-A and CPS-B chips like CPS1 chips due to how they are wired up on the CPS2 A-BOARD. Tough, no? :)
 
The 68000 is inside the SPA chip (DL-1525, which happens to be a custom part made by Motorola for Capcom)in the B BOARD. Stuff on CPS SHOCK is a mega pile of bullshit. :)

There are decaps of the chip done already for Arcade Hacker's key rewrite project so I'm not talking this out of my ass.


The CPU has to be together with the battery for obvious reasons (security). The keys do not travel from B board to A board. If it was done that way it would be too easy (like it was easy to figure out the protection of the original XBOX by snooping on the south bridge bus).
 
Last edited:
Ok then, why not use a standard M68000 Processor on a new/custom emu. "B" board?


The 68000 is inside the SPA chip (DL-1525, which happens to be a custom part made by Motorola for Capcom)in the B BOARD. Stuff on CPS SHOCK is a mega pile of bullshit. :)

There are decaps of the chip done already for Arcade Hacker's key rewrite project so I'm not talking this out of my ass.


The CPU has to be together with the battery for obvious reasons (security). The keys do not travel from B board to A board. If it was done that way it would be too easy (like it was easy to figure out the protection of the original XBOX by snooping on the south bridge bus).
 
I said it would be very complex to design a new board (we would not use the custom chip on such a design, I suppose). The custom chip in the existing board does run non encrypted code if there's no key programmed so making a new board is actually stupid. :)
 
Capcom has a bit of battery backup-ram integrated into their custom 68K design to hold the start up key(s).

So, couldn't a bit of backup ram be added to the new B board. And and a programmable chip w/ code to clear the ram and re-write to it also be added? And perhaps that chip could also re-flash the program, sound, and graphics chips at in the same process.

I said it would be very complex to design a new board (we would not use the custom chip on such a design, I suppose). The custom chip in the existing board does run non encrypted code if there's no key programmed so making a new board is actually stupid. :)
Or, instead of re/flashing each game: have a all the games pre-loaded, and just run a program that flags which game directories are active. But, this may be a dumb idea.
 
Last edited:
It's not battery backed up RAM. If you go by the bullshit on CPS2 SHOCK they claim the two 6264 RAM chips on the B board are related to security. The RAMs are actually for the SPRITES name table. (table with position, palette color and tiles to form the sprites on screen)

The RAM which holds the security keys is only 160 bits. Not enough (and not accessible for data storage). Considering that the key was supposed to last a long time Capcom would prefer to keep things simple and let the battery hold only the security memory data.


About pre-loading games, the system was designed to have a game loaded to it by means of MASK ROMs. And only one while at it (that's why the security is in place, to prevent people from swapping the games around).

Anyway, the solution we have right now is pretty decent. What we need is sit around a campfire and talk about software based solutions for CPS 1.5 games because we don't need any new hardware, just understand how the games work and change them properly with that knowledge. The reason why I only went half way through converting the Punisher is that I lacked the knowledge of how the game worked and I didn't have the patience to disassemble it and see what was going on.
 
If the keys were backed on ram people would of had them way sooner. Since you could just check that ram but instead Nicola and Andreas had to use gigabyte sized key dumps to figure out how the encryption worked.
 
Then it looks like someone should politely email the mame dev. team and tell them to remove the shit on their site. :)
 
Back
Top