Status: SamSho V Special Redump

Niko

Whip's Subordinate
Joined
May 15, 2014
Posts
1,773
Making this thread to keep everyone updated on the status of having Samurai Shodown V Special redumped and added to MAME.

Backstory:
As some of you know from the NeoSD thread, It was pointed out that a particular sound glitch within the game was due to a bad dump of the V roms.

Below is a video demonstrating the sound glitch, listen for the POP after the announcers pronounces "Basara".

#Youtube tags appear to be currently broken
https://www.youtube.com/watch?v=dnnRlDGbJQ8

Pretty minor issue right? Actually its quite annoying. The original dump was submitted to MAME back in 2006. So it took 10years for someone to notice or care enough to bring it forward. Makes you wonder what other sound glitches might be present that havent been found yet.

Due to the current price of this game and the huge 64Megabit V-Roms. Redumping this myself was not an option and the only person I knew who was capable of doing something like this was all the way in Canada. So on a whim I reached out to one of the Neo gurus who happened to only be a few states away. Luckily he agreed to do it for me.

To the F$^KIN point:

So as of Yesturday, I've sent my cart off to NeoGeo OG JMKurtz to have the V roms redumped.

Shipping should only take a few days, but JMKurtz has already mentioned he would need to build and test an adapter in order to correctly dump these roms.

Once the roms are dumped and verified they will be submitted to MAME and available to the general public. So stay tuned :)
 

GutsDozer

Robot Master., Master Tasuke, Eat Your, Heart Out
10 Year Member
Secret Santa Veteran
Joined
Mar 5, 2013
Posts
5,391
Great job bud thanks for your work!
 

massimiliano

ネオジオ,
20 Year Member
Joined
Feb 27, 2004
Posts
3,224
Kudos, and thanks for your effort...way to go!
 

WNivek

Overtop Pathfinder
Joined
Apr 5, 2016
Posts
104
I am a fan of software preservation, so this effort pleases me. Good on ya, dude.
 

Neodogg

Dogg-Father,
20 Year Member
Joined
Nov 27, 2002
Posts
5,588
You magnificent bastard!

PM'ing Jeff now with you new return address!
 

wingzrow

Galford's Armourer
Joined
Jan 20, 2006
Posts
466
So Metal Slux X finally gets properly decrypted due to The NEO SD card, AND we're fixing the dump issues with Sam Sho 5 Special? God damn, the neo sd card is the gift that keeps on giving. What are the odds that there are other roms that haven't been properly dumped & we just didn't realize it until now?
 

Niko

Whip's Subordinate
Joined
May 15, 2014
Posts
1,773
So Metal Slux X finally gets properly decrypted due to The NEO SD card, AND we're fixing the dump issues with Sam Sho 5 Special? God damn, the neo sd card is the gift that keeps on giving. What are the odds that there are other roms that haven't been properly dumped & we just didn't realize it until now?

Its very possible, this sort of thing does happen. I'd say its more likely with the larger games as most readers cant natively address all the memory in the larger mask roms. I'd say now that we have a flash cart, people are paying closer attention to oddities. I know its already been suspected a few times since the NeoSD came out, once in paticular with Pulstar.
 

pegboy

Armored Scrum Object
Joined
Sep 27, 2013
Posts
268
This is awesome. It's great to see people striving to fix emulation issues and get 100% clean dumps of these games. Even after all these years there is still a lot of work to do.
 

aku

Loyal Neo-Disciple
Joined
Dec 31, 2015
Posts
834
i have the ssvs cart but dkarDaGobert didnt reply to my PM in mid december...

great to see it happening....
 

NeoCverA

RevQuixo. Who He?,
20 Year Member
Joined
Aug 7, 2002
Posts
6,691
A rare thing around these parts. Thanks for the contribution.
 

neofonta

Zero's Secretary
Joined
Mar 13, 2008
Posts
148
Great news here
Thanks @Niko49 for contributing to the roms scene, you're so welcome!
 

Niko

Whip's Subordinate
Joined
May 15, 2014
Posts
1,773
Just wanted to update everyone on the status of this.

JMKurtz received the cart Yesterday and was able to get the roms dumped. However, the rom dumps are the exact same as they current roms already in MAME.

So basically what this means is that the original dump from 2006 was good, but the decryption of the roms and or the emulation of the PCM2 chip are not correct. I'm going to reach out to the NeoSD team and hopefully they will be able to investigate further.

On a positive note, we are one step closer to solving this issue!
 

wingzrow

Galford's Armourer
Joined
Jan 20, 2006
Posts
466
Just wanted to update everyone on the status of this.

JMKurtz received the cart Yesterday and was able to get the roms dumped. However, the rom dumps are the exact same as they current roms already in MAME.

So basically what this means is that the original dump from 2006 was good, but the decryption of the roms and or the emulation of the PCM2 chip are not correct. I'm going to reach out to the NeoSD team and hopefully they will be able to investigate further.

On a positive note, we are one step closer to solving this issue!

Well at least that narrows down the issue.Thanks for the hard work.
 

Gyrian

Hardened Shock Trooper
Joined
Mar 24, 2016
Posts
443
Thanks for getting this done, Niko & JM.
An unexpected twist, but now that this is understood we might still be around the corner for a fix. It would be surprising if this ended up amounting to a decryption error. I'm putting my chips on PCM emulation bug.
 

Razoola

Divine Hand of the UniBIOS,
Staff member
20 Year Member
Joined
Nov 12, 2002
Posts
4,662
This is not a likely pcm emulation issue. I pointed out in the main neosd thread some time ago that one can compare against ssv (given the first part of the samples in both games is identical). From that you can see there are 4 bytes dufferent from the part that can be compared (once decrypted). I did post them in the neosd thread as patches to the neo file but here they are again if patching direct decrypted data only.

0x06bc0 was 0xab, should be 0x08
0x0ed41 was 0x08, should be 0x89
0x16bc0 was 0x6e, should be 0x82
0x1ed41 was 0xda, should be 0x8f

Now this could be a decryption issue, and a couple of these patches above may be due to issues in the ssv dump. However applying these patches fixes the pop with Basara in ssvsp.

I do remember at some point in the past with dumps on NeoGeo there were issues with getting correct values for the first 2 bytes in large ROMs so I wonder if this issue is there.
 
Last edited:

neodev

Neosd Tech
Joined
Nov 28, 2016
Posts
256
This is not a likely pcm emulation issue. I pointed out in the main neosd thread some time ago that one can compare against ssv (given the first part of the samples in both games is identical). From that you can see there are 4 bytes dufferent from the part that can be compared (once decrypted). I did post them in the neosd thread as patches to the neo file but here they are again if patching direct decrypted data only.

0x06bc0 was 0xab, should be 0x08
0x0ed41 was 0x08, should be 0x89
0x16bc0 was 0x6e, should be 0x82
0x1ed41 was 0xda, should be 0x8f

Now this could be a decryption issue, and a couple of these patches above may be due to issues in the ssv dump. However applying these patches fixes the pop with Basara in ssvsp.

I do remember at some point in the past with dumps on NeoGeo there were issues with getting correct values for the first 2 bytes in large ROMs so I wonder if this issue is there.


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)
 

Razoola

Divine Hand of the UniBIOS,
Staff member
20 Year Member
Joined
Nov 12, 2002
Posts
4,662
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)

This is what I suspected also, Im glad you confirmed it... I remember these large ROMs are hard to dump and I dont remember the process to read and get the first two bytes correctly. I guess this applies to both V ROMs also, there will be more incorrect bytes somewhere.
 
Top