Page 2 of 3 FirstFirst 123 LastLast
Results 26 to 50 of 62

Thread: Status: SamSho V Special Redump

  1. #26
    Hardened Shock Trooper
    Gyrian's Avatar
    Join Date
    Mar 2016
    Location
    Fort Worth, TX

    Posts
    442
    Quote Originally Posted by Razoola View Post
    This is not a likely pcm emulation issue.
    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 by Gyrian; 01-16-2017 at 07:27 AM.

  2. #27
    Sho's Rival
    Niko's Avatar
    Join Date
    May 2014
    Location
    Kentucky

    Posts
    1,430
    Quote Originally Posted by neodev View Post
    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 by Niko; 01-16-2017 at 09:03 AM.

  3. #28
    Tech Support Moderator

    Join Date
    Aug 2000
    Location
    Dunedin, FL

    Posts
    1,650
    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.

  4. #29
    Quote Originally Posted by JMKurtz View Post
    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.

    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 by neodev; 01-16-2017 at 09:58 AM.
    NEOSD - The ONLY Neo Geo MVS & AES Flash Cart - TEAM Member


  5. #30
    Tech Support Moderator

    Join Date
    Aug 2000
    Location
    Dunedin, FL

    Posts
    1,650
    Do you have a reference for this? Maybe if this is the case, there's also a resolution known too?

    Quote Originally Posted by Razoola View Post
    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.

  6. #31
    Divine Hand of the UniBIOS
    Razoola's Avatar
    Join Date
    Nov 2002
    Location
    Finland, Earth

    Posts
    4,493
    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.
    THE UNIVERSE BIOS ( MVS / AES, and now also for CD )
    www.universebios.com. Also on facebook, please like http://www.facebook.com/UniverseBios.

  7. #32
    Mr. Big's Thug
    Evan's Avatar
    Join Date
    May 2016
    Location
    Your trash can

    Posts
    217
    Cool

  8. #33
    Divine Hand of the UniBIOS
    Razoola's Avatar
    Join Date
    Nov 2002
    Location
    Finland, Earth

    Posts
    4,493
    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.
    THE UNIVERSE BIOS ( MVS / AES, and now also for CD )
    www.universebios.com. Also on facebook, please like http://www.facebook.com/UniverseBios.

  9. #34
    Quote Originally Posted by Razoola View Post
    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.
    The expected values should be 0x43 0xC9
    NEOSD - The ONLY Neo Geo MVS & AES Flash Cart - TEAM Member


  10. #35
    Divine Hand of the UniBIOS
    Razoola's Avatar
    Join Date
    Nov 2002
    Location
    Finland, Earth

    Posts
    4,493
    Quote Originally Posted by neodev View Post
    The expected values should be 0x43 0xC9
    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).
    THE UNIVERSE BIOS ( MVS / AES, and now also for CD )
    www.universebios.com. Also on facebook, please like http://www.facebook.com/UniverseBios.

  11. #36
    Sho's Rival
    Niko's Avatar
    Join Date
    May 2014
    Location
    Kentucky

    Posts
    1,430
    Quote Originally Posted by Razoola View Post
    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).
    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.

  12. #37
    Tech Support Moderator

    Join Date
    Aug 2000
    Location
    Dunedin, FL

    Posts
    1,650
    Wired up a socket as NeoSD suggested and read the voltage on each pin and came up with the same word value as the rom dump: 0x25E0 (dump is 0xE025 because of endian notation).

  13. #38
    J. Maximum Fan Club President
    greedostick's Avatar
    Join Date
    Aug 2003
    Location
    Taterz in my Slot

    Posts
    3,830
    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!

    Neo Geo AES JP serial #1337
    Super Neo AES JP serial #1337

  14. #39
    Quote Originally Posted by JMKurtz View Post
    Wired up a socket as NeoSD suggested and read the voltage on each pin and came up with the same word value as the rom dump: 0x25E0 (dump is 0xE025 because of endian notation).
    Thanks for checking. Then something is different encryption-wise with the very first word of the V area in the pcm2 chip
    NEOSD - The ONLY Neo Geo MVS & AES Flash Cart - TEAM Member


  15. #40
    Cham Cham's Banana
    bello's Avatar
    Join Date
    Oct 2009
    Location
    sweden Norrkoping

    Posts
    161
    Great job,thanks!

  16. #41
    AH
    A
    COLUMBIAN!
    aha2940's Avatar
    Join Date
    Dec 2013
    Location
    Colombia

    Posts
    2,480
    So, all games with big 64-bit chips have dumping/decryption issues? MS3, MS4, MS5, Ganryu, KoF2k to 2k+3, Strikers +...

  17. #42
    Sho's Rival
    Niko's Avatar
    Join Date
    May 2014
    Location
    Kentucky

    Posts
    1,430
    Quote Originally Posted by aha2940 View Post
    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

  18. #43
    Divine Hand of the UniBIOS
    Razoola's Avatar
    Join Date
    Nov 2002
    Location
    Finland, Earth

    Posts
    4,493
    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.
    THE UNIVERSE BIOS ( MVS / AES, and now also for CD )
    www.universebios.com. Also on facebook, please like http://www.facebook.com/UniverseBios.

  19. #44
    Sho's Rival
    Niko's Avatar
    Join Date
    May 2014
    Location
    Kentucky

    Posts
    1,430
    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

  20. #45
    Sho's Rival
    Niko's Avatar
    Join Date
    May 2014
    Location
    Kentucky

    Posts
    1,430
    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...t_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.

  21. #46
    Divine Hand of the UniBIOS
    Razoola's Avatar
    Join Date
    Nov 2002
    Location
    Finland, Earth

    Posts
    4,493
    Neodev confirmed the issue is present in SSV and SSVS (probably other games also). For both cases the expected decrypted values could be hacked into the driver but of course that is not a proper fix.
    THE UNIVERSE BIOS ( MVS / AES, and now also for CD )
    www.universebios.com. Also on facebook, please like http://www.facebook.com/UniverseBios.

  22. #47
    Cheng's Errand Boy
    SmaMan's Avatar
    Join Date
    May 2014
    Location
    Stillwater, OK

    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?

    When I'm not gaming, I like to write. You can read my short stories and ramblings here!

  23. #48
    Sho's Rival
    Niko's Avatar
    Join Date
    May 2014
    Location
    Kentucky

    Posts
    1,430
    Quote Originally Posted by Razoola View Post
    Neodev confirmed the issue is present in SSV and SSVS (probably other games also). For both cases the expected decrypted values could be hacked into the driver but of course that is not a proper fix.
    Ohh you're right, I missed that from his comment above.

    Quote Originally Posted by SmaMan View Post
    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 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.

  24. #49
    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)
    Last edited by neodev; 02-17-2017 at 03:16 AM.
    NEOSD - The ONLY Neo Geo MVS & AES Flash Cart - TEAM Member


  25. #50
    Sho's Rival
    Niko's Avatar
    Join Date
    May 2014
    Location
    Kentucky

    Posts
    1,430
    Quote Originally Posted by neodev View Post
    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!

Thread Information

Users Browsing this Thread

There are currently 1 users browsing this thread. (0 members and 1 guests)

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •