Gyrian
Hardened Shock Trooper
- Joined
- Mar 24, 2016
- Posts
- 443
Haha, and there go all my chips in a flash.
I am enjoying the momentum on this one; the end of this old mystery draws near.
Last edited:
Status: SamSho V Special Redump
- Thread starter Niko
- Start date
Hardened Shock Trooper
Haha, and there go all my chips in a flash.
I am enjoying the momentum on this one; the end of this old mystery draws near.
Niko
Whip's Subordinate
- Joined
- May 15, 2014
- Posts
- 1,773
I've just made a quick test with neobuilder to check which encrypted addresses these bytes belong to and this is interesting:
0x006bc0 value is taken from encrypted offset 0
0x016bc0 value is taken from encrypted offset 1
the other two look less interesting, they are:
0x00ed41 value is taken from encrypted offset 0x18180
0x01ed41 value is taken from encrypted offset 0x18181
BUT, now things get more interesting. by checking the decryption in ssv (not sp),
0x00ed41 value is taken from encrypted offset 0x0
0x01ed41 value is taken from encrypted offset 0x1
so, in summary, both SSVS and SSV dumps are wrong, the first 2 bytes of the V rom are wrong in both, unless they are patched by the decryption ASIC in some way, or offsets 0 and 1 have some other special xor value.
just to note which are the correct values:
in order to make the value at 0x60bc0 be 0x08, the encrypted value present at 0x00000 should be 0x43 (it is 0xE0)
in order to make the value at 0x160bc0 be 0x82, the encrypted value present at 0x00001 should be 0xC9 (it is 0x25)
Thanks for your input.
In order for JMKurtz to dump the V Roms, he had to build an adapter and first wanted to test against a mask rom of the same size. So I also sent him a KOF2k2 ( which also uses a 64Mb V Rom), to dump first and compare to whats in MAME. Basically our control set.
So we either have a bunch of bad Neo dumps in MAME, or there is something else going on. Like you mentioned with the special xor value for the first 2 bytes.
Last edited:
These 64MBit roms are 16 bit, not 8 bit like previous (32MBit) roms used, so it was quite easy to dump these roms as a 27C322. I only needed to control the A21 (Pin 11) manually to read half the rom at a time. So, there was no need to make an adapter this time around.
I first read the V1 of KoF2K and it matched perfectly to the existing KoF2K V1. Is that one that's known to have similar issues?
Reading these 64MBit was pretty straight forward and there's not going to be any different way to read the roms with a device programmer. I read and verified each read to make sure the roms read identical several times. I'm using a Xeltek SuperPro 5000 unit, so it's not like it's a cheap HK reader.
If it's reading the first couple of bytes incorrectly then it's likely any standard programmer like this would exhibit the same problem as others since I would assume they are all using the same algorithm for reading the roms and none of them would directly support a specialized algorithm for a 42 pin 64MBit MASK ROM.
I first read the V1 of KoF2K and it matched perfectly to the existing KoF2K V1. Is that one that's known to have similar issues?
Reading these 64MBit was pretty straight forward and there's not going to be any different way to read the roms with a device programmer. I read and verified each read to make sure the roms read identical several times. I'm using a Xeltek SuperPro 5000 unit, so it's not like it's a cheap HK reader.
If it's reading the first couple of bytes incorrectly then it's likely any standard programmer like this would exhibit the same problem as others since I would assume they are all using the same algorithm for reading the roms and none of them would directly support a specialized algorithm for a 42 pin 64MBit MASK ROM.
neodev
Neosd Tech
- Joined
- Nov 28, 2016
- Posts
- 256
Being the very first byte(word) in the rom, and assumming it's compatible with an standard 27c322, it should be easy to read without a programmer. It could be read with a 42 pin socket and a logic probe to rule out programmer algorithm mistakes.
Just tie all address lines + CE + OE in the socket to GND, apply 5V power and probe each data pin with a logic probe.
Last edited:
Do you have a reference for this? Maybe if this is the case, there's also a resolution known too?
- Joined
- Nov 12, 2002
- Posts
- 4,662
I do remember this being a long standing issue from years back. Back in the day there were a few ROMs redumped and only the first two bytes (or word) were different. How the redumps were done I'm not sure but I would guess there are still quite a few dumps in MAME which may have this issue. A guy in Mexico could dump them correctly I remember but I do not know the method he used, what neodev suggests would be worth a shot I think.
- Joined
- Nov 12, 2002
- Posts
- 4,662
The one good thing in our favor here is using SSV the expected SSVSP encrypted values can be calculated before dumping (and visa versa). I would suggest calculating the expected values for SSVSP and then making a device that obtains that value via dumping... Then documenting the process for MAME.
neodev
Neosd Tech
- Joined
- Nov 28, 2016
- Posts
- 256
The expected values should be 0x43 0xC9
- Joined
- Nov 12, 2002
- Posts
- 4,662
Great, so once those values are dumped via whatever method. The same method can be used on the SSVSP V2 and the kof2k2 V ROMs (if Jeff has both).
Niko
Whip's Subordinate
- Joined
- May 15, 2014
- Posts
- 1,773
I did send him both carts.
What other carts might this be a problem with? Any cart with a 64Mb mask rom? I fear there are many more dumps out there that have the same problem.
- Joined
- Aug 11, 2003
- Posts
- 4,475
This is great. With Kurtz handling this I think we can all be confident that it will be done correctly.
Thanks to both of you!
Thanks to both of you!
neodev
Neosd Tech
- Joined
- Nov 28, 2016
- Posts
- 256
Thanks for checking. Then something is different encryption-wise with the very first word of the V area in the pcm2 chip
Niko
Whip's Subordinate
- Joined
- May 15, 2014
- Posts
- 1,773
So, all games with big 64-bit chips have dumping/decryption issues? MS3, MS4, MS5, Ganryu, KoF2k to 2k+3, Strikers +...
My guess, is its anything using the PCM2
- Joined
- Nov 12, 2002
- Posts
- 4,662
Im not 100% sure this is a issue related to the encryption. Of course I could be wrong but Its just the previous situation back in the early 2000's is the same. Could it be related to timing when reading the first word of these ROMs? Perhaps the correct value is only present for a short time.
Niko
Whip's Subordinate
- Joined
- May 15, 2014
- Posts
- 1,773
Someone else pointed this out to me, but could this have something to do with it? Its connected to the V roms in SSV but was added to the PROGBK2S with SSVS
https://wiki.neogeodev.org/index.php?title=NEO-HYCS
https://wiki.neogeodev.org/index.php?title=NEO-HYCS
Niko
Whip's Subordinate
- Joined
- May 15, 2014
- Posts
- 1,773
Just an update, Jeff has run out of free time to continue to work on this right now. His most recent idea was to build a 64Mbit eprom to test the dump on real hardware. Unfortunately this is not an easy task.
On a sidenote, I've been talking with some friends from the Dumping Union who took a look at the PCM2 decryption processes in MAME and agreed that some of the logic looks incomplete/inaccurate. Mainly in this function here: https://github.com/mamedev/mame/blob/master/src/devices/bus/neogeo/prot_pcm2.cpp#L59
Its also been noted that the date codes on the PCM2 ICs between SSV and SSVS are different, which could indicate something in the logic changed between these two games. Since SSVS was the last game produced, it could be a special case.
On a sidenote, I've been talking with some friends from the Dumping Union who took a look at the PCM2 decryption processes in MAME and agreed that some of the logic looks incomplete/inaccurate. Mainly in this function here: https://github.com/mamedev/mame/blob/master/src/devices/bus/neogeo/prot_pcm2.cpp#L59
Its also been noted that the date codes on the PCM2 ICs between SSV and SSVS are different, which could indicate something in the logic changed between these two games. Since SSVS was the last game produced, it could be a special case.
SmaMan
Cheng's Errand Boy
- Joined
- May 17, 2014
- Posts
- 119
Viva la preservación!
I just had a thought... what about the official emulated copies of these games, on Metal Slug Anthology, the Wii VC and things like that. Do they have these same dump issues? (I know there was never a port of SSVS.) I don't quite understand everything that's going on, but would it be worth looking into those roms for (through WiiScrubber or InjectuWAD or whatever the good program is for that these days) for differences to what's been dumped into the MAME romset?
I just had a thought... what about the official emulated copies of these games, on Metal Slug Anthology, the Wii VC and things like that. Do they have these same dump issues? (I know there was never a port of SSVS.) I don't quite understand everything that's going on, but would it be worth looking into those roms for (through WiiScrubber or InjectuWAD or whatever the good program is for that these days) for differences to what's been dumped into the MAME romset?
Niko
Whip's Subordinate
- Joined
- May 15, 2014
- Posts
- 1,773
Ohh you're right, I missed that from his comment above.
I dont think SSV or SSVS is on WiiVC, There is a PS2 port of SSV but files are usually concatenated and packed in a proprietary manner and even then, there is chance the roms are already decrypted which I dont think would help since we already know what the values should be. In the long run it would probably be easier for one of the tech guru's to put together a 64Mbit V rom to test the dump.
neodev
Neosd Tech
- Joined
- Nov 28, 2016
- Posts
- 256
I missed these latest responses on this thread.
Well, I'm probably getting a kof2002 cart, that I think uses the same pcm2 variation that ss5/ss5sp with the extra scrambling. Getting a SS5 or SS5SP is hard, as they are very expensive.
What I plan is probing the address and data bus of the V1 rom (I only have a 16 bit logic analyzer, so I can only partially probe it) and then making the game (via a custom m1 rom or using another game CHA board) play that sample, and sniff the addresses and values it reads, and then probe the V1 address bus and the cart data bus, to check that the encrypted and decrypted values match with the ones currently in the dump and after decryption. If the encrypted value matches, but the decrypted one doesn't, then it's definitely something happening in the PCM2 that is different for offset 0. It might be that address 0 is swapped to a different address in the V1 rom space, but the address probing should show that (if that's the case, I'll move all the probes to the address bus and extract it in several tries).
This might take a while, as I don't have the cart yet, and I need to find time to do that too
Also about the HYCS circuit, it seems to keep the MSB address of the rom LOW as long as the included voltage supervisor signals the voltage is too low, or the IN_RST pin is low. I don't know what's exactly for, but I can only guess that it must be forcing that to 0 during startup because the PCM2 might be reading the decryption data from the V1 rom itself, and it's stored in a place with the MSB set to 0, and they have some kind of bug that makes the address MSB float (or input, as the bus is muxed with in and out signals) and they need to force it to 0. I will also sniff the V1 accesses during startup to check which addresses it reads before playing any sample (not easy, as the YM always generates addresses even if it's not playing data, it just generates the last address over and over, without increment)
Well, I'm probably getting a kof2002 cart, that I think uses the same pcm2 variation that ss5/ss5sp with the extra scrambling. Getting a SS5 or SS5SP is hard, as they are very expensive.
What I plan is probing the address and data bus of the V1 rom (I only have a 16 bit logic analyzer, so I can only partially probe it) and then making the game (via a custom m1 rom or using another game CHA board) play that sample, and sniff the addresses and values it reads, and then probe the V1 address bus and the cart data bus, to check that the encrypted and decrypted values match with the ones currently in the dump and after decryption. If the encrypted value matches, but the decrypted one doesn't, then it's definitely something happening in the PCM2 that is different for offset 0. It might be that address 0 is swapped to a different address in the V1 rom space, but the address probing should show that (if that's the case, I'll move all the probes to the address bus and extract it in several tries).
This might take a while, as I don't have the cart yet, and I need to find time to do that too
Also about the HYCS circuit, it seems to keep the MSB address of the rom LOW as long as the included voltage supervisor signals the voltage is too low, or the IN_RST pin is low. I don't know what's exactly for, but I can only guess that it must be forcing that to 0 during startup because the PCM2 might be reading the decryption data from the V1 rom itself, and it's stored in a place with the MSB set to 0, and they have some kind of bug that makes the address MSB float (or input, as the bus is muxed with in and out signals) and they need to force it to 0. I will also sniff the V1 accesses during startup to check which addresses it reads before playing any sample (not easy, as the YM always generates addresses even if it's not playing data, it just generates the last address over and over, without increment)
Last edited:
Niko
Whip's Subordinate
- Joined
- May 15, 2014
- Posts
- 1,773
I missed these latest responses on this thread.
Well, I'm probably getting a kof2002 cart, that I think uses the same pcm2 variation that ss5/ss5sp with the extra scrambling. Getting a SS5 or SS5SP is hard, as they are very expensive.
What I plan is probing the address and data bus of the V1 rom (I only have a 16 bit logic analyzer, so I can only partially probe it) and then making the game (via a custom m1 rom or using another game CHA board) play that sample, and sniff the addresses and values it reads, and then probe the V1 address bus and the cart data bus, to check that the encrypted and decrypted values match with the ones currently in the dump and after decryption. If the encrypted value matches, but the decrypted one doesn't, then it's definitely something happening in the PCM2 that is different for offset 0. It might be that address 0 is swapped to a different address in the V1 rom space, but the address probing should show that (if that's the case, I'll move all the probes to the address bus and extract it in several tries).
This might take a while, as I don't have the cart yet, and I need to find time to do that too
Also about the HYCS circuit, it seems to keep the MSB address of the rom LOW as long as the included voltage supervisor signals the voltage is too low, or the IN_RST pin is low. I don't know what's exactly for, but I can only guess that it must be forcing that to 0 during startup because the PCM2 might be reading the decryption data from the V1 rom itself, and it's stored in a place with the MSB set to 0, and they have some kind of bug that makes the address MSB float (or input, as the bus is muxed with in and out signals) and they need to force it to 0. I will also sniff the V1 accesses during startup to check which addresses it reads before playing any sample (not easy, as the YM always generates addresses even if it's not playing data, it just generates the last address over and over, without increment)
Thanks for the update neodev! I know you guys have been very busy lately. Let me know if you need anything and I'll see if I or someone I know can help out!