nesdev.org

Yesterday I got my new GameDoctor SF7 and tried to run StartOcean from the cartridge slot; all what I got was messed graphics, just like it looks on an emulator without the graphic packs. So, it seems that S-DD1 chip is not working on the cartridge side.

Does anybody know why?

The CIC integrated into the S-DD1 chip probably detects the copier and thus refuses to enable its hardware decompression function. Try using the cart directly on a SNES (e. g. with a newer adaptor like Super Key or Fire Adaptor in case you have a PAL unit, or on a US SNES or Super Famicom), and I'm pretty sure it'll work just fine.

More likely the GD isn't passing the entire entire address space to/from the cart.

Or delays are introduced that screw it up. The Cx4 chip in Mega Man X2 and X3 has issues running through the GDSF7 too.

It sounds like you are trying to run Star Ocean/S-DD1 on a PAL SNES with the lockout chip disabled? If so I read its one of the known 'problem' games (Like Super Mario RPG/SA-1) which can only be played on a console with a working matching lockout chip, in this case either a US SNES or JPN Super Famicom.

If you are trying to play it on a PAL SNES one option is to mod the console with ikari_01's clone lockout chip, see this thread for details:-
http://nesdev.com/bbs/viewtopic.php?t=5 ... c&start=60
(The first post on that page even mentions the problem with S-DD1 games)

Alternatively, if you can re-enable the PAL lockout chip in the SNES console you could mod the actual game, as mentioned in a post I made over at the gamesx forums:-
http://nfggames.com/forum2/index.php?to ... 8#msg24458
Pin 82 on the S-DD1 allows you to switch the lockout chip between NTSC and PAL modes.

I hope that helps

Thanks you all for your answers.

I tried to play the game on a Super Famicom yesterday, and on a modded PAL SNES today, both giving the same results.

I don't think the malfunctioning is caused by the S-DD1's CIC. I guess that it is working just like any other CIC (in "key" mode), so if SNES CPU is not reset, it means that lock-CIC receives the valid binary sequence from S-DD1, so it should be receiving the valid one too.

Maybe the cause is what kyuusaku said but... can somebody confirm it?

Did you put the game directly into a Super Famicom (Japanese) Console and get the same problem? If the game doesn't work when directly inserted into an original Japanese console that suggests other issues.

If it doesn't work when played through the GDSF7, there probably isn't any remedy other than not to try to do that.

MottZilla wrote:Did you put the game directly into a Super Famicom (Japanese) Console and get the same problem? If the game doesn't work when directly inserted into an original Japanese console that suggests other issues.

If it doesn't work when played through the GDSF7, there probably isn't any remedy other than not to try to do that.

Yes, of course I did! I was playing SO on my Super Famicom for long, and supposed I could do the same through GDSF7. I was corious to know why. Not is that I really want to play it on GDSF7, just ccuriosity.

Well I don't know if anyone has researched the issue, but it's fairly safe to say somewhere between the cartridge and the console in the GDSF7 signals are not being passed or are not getting through or are not coming through as well. With Mega Man X2/X3, the Cx4 chip works through the GDSF7, but is glitchy in its behavior. For Mega Man X2 (or X3, one of them) you can't get into the game or atleast I couldn't. But the other game went in game and played with some errors but the Cx4 did function for certain tasks like putting the sprites on screen like Mega Man X.

magno wrote: I don't think the malfunctioning is caused by the S-DD1's CIC. I guess that it is working just like any other CIC (in "key" mode), so if SNES CPU is not reset, it means that lock-CIC receives the valid binary sequence from S-DD1, so it should be receiving the valid one too.

So, Star Ocean doesnt look like this?:-

Thats how it looks when the games CIC disables the S-DD1 processor.

The picture is from ikari_01's post in the thread I linked to previously:-
http://nesdev.com/bbs/viewtopic.php?t=5 ... ght=#60014

This doesn't answer your question, but if you want to play it on your GD7:

Some time ago, neviksti made patches that decompress the GFX and expand the game to a 96mbit ROM, basically creating a version that doesn't require the SDD-1 chip. So you can run it on the GD7, but not from the cart.

Google found the patches available here http://www.racketboy.com/forum/viewtopi ... a&start=30 look a few posts down on that page.

Link83 wrote:

magno wrote: I don't think the malfunctioning is caused by the S-DD1's CIC. I guess that it is working just like any other CIC (in "key" mode), so if SNES CPU is not reset, it means that lock-CIC receives the valid binary sequence from S-DD1, so it should be receiving the valid one too.

So, Star Ocean doesnt look like this?:-

Thats how it looks when the games CIC disables the S-DD1 processor.

The picture is from ikari_01's post in the thread I linked to previously:-
http://nesdev.com/bbs/viewtopic.php?t=5 ... ght=#60014

Yes, that's how it looks like. Just like when you run the ROM on an emulator which doesn't support S-DD1 nor graphic packs.

Maybe you are right and somehow CIC detects it is not running directly on a SFC and disables the decompression.

BootGod wrote:This doesn't answer your question, but if you want to play it on your GD7:

Some time ago, neviksti made patches that decompress the GFX and expand the game to a 96mbit ROM, basically creating a version that doesn't require the SDD-1 chip. So you can run it on the GD7, but not from the cart.

Thanks for the link. I was looking for some information about how to split ROMs larger than 32 Megs in GD3 format, since my copier has 64 Megs RAM and want to play Tales of Phantasia on it.

Splitting ROMs for GDSF7 is as simple as taking the large GD3 format file and cutting it into either 8 megabit pieces (with the first piece also having the 512 byte header) until you run out of ROM to turn into pieces. You can also make them into 12 megabit pieces if you are using 1.6mb format disks. You may also be able to make 10 megabit or other piece sizes but I never tested it.

MottZilla wrote:Splitting ROMs for GDSF7 is as simple as taking the large GD3 format file and cutting it into either 8 megabit pieces (with the first piece also having the 512 byte header) until you run out of ROM to turn into pieces. You can also make them into 12 megabit pieces if you are using 1.6mb format disks. You may also be able to make 10 megabit or other piece sizes but I never tested it.

I'm using uCON64 v2.0 to split the ROMs (and to convert them to GD3 format), but when trying to convert ROMs greater than 32 megs, it prints an error message: it says it can't convert roms greater than 32 megs....

Oh I didn't realize you had not been able to convert it. Honestly I don't know what program will do so, but it can be done. Basically if you take the SMC non-interleaved ROM you just need to go and interleave it. Then you just need a GD3 header, which you might be able to figure out a working one for ToP by looking at the 96mbit Star Ocean hack for GD3 format.

Or a program may already exist.