DKC2 sd2snes bugs (no opening title sound)

Don't know if it matters because Lufia 2 says the same thing but when snes9x runs the rom it says bad check sum at the beginning in yellow text.  It does play with the enhanced audio though.

@Highblade7777 Bad checksum occurs when ever a ROM is patched. Some hackers, myself included, forget or don't bother to rebuild the checksum. This error can also occur when a ROM size is increased (say from 1MB to 2MB ROM). If this annoys, then the checksum would just need to be rebuilt (using some tools from RomHacking.net, don't recall the name, used only a few times when resizing ROMs). It won't hurt anything, as far as I know.

Also, out of curiosity, are your original non-patched ROMs non-header? Most of our Zeldix patches require non-header ROMs.

UPDATE: It was Checksum Recalculator (now I remember, lol). Here is the link:
https://www.romhacking.net/utilities/499/. This tool will recalculate and update the checksum for the modified ROM. This will remove the bad checksum error after you patch a ROM with a trusted IPS file.

Absolutely no header, sfc rather than smc in fact. In my experience if you mess that up the rom won't even boot up.

@Highblade7777 Just asking due to your "bad checksum" curiosity, as this could produce bad checksum as well. So most likely Lufia2 MSU-1 had significant changes compare to the non-patched version. It is optional to recalculate the checksums anyway. As far as I know, snes9x or sd2snes will still run the game regardless (given the IPS patch is good and the intended ROM was used).

so how is the SDD-1 firmware treating you? Is it a beta release after 1.9 like SA-1 was for a while?

@Highblade7777 I was using 1.8.0 with SDD-1 to test my Street Fighter Alpha/Zero 2 MSU-1 patch back in December and never bothered to upgrade to 1.9.0 when it released. Now, I just upgraded to 1.9.0 to help you out with DKC2 issue.

Honestly, I think now that my sd2snes is updated to 1.9.0 without SDD-1, I will just wait for an official release. It is only two games I can live without.

@Highblade, I am sorry for cutting in on your post between Pepillopev and you, I just wanted to post this link from the sd2snes website on doing a diagnostic test on your sd2snes cart. I do not know if that will fix the issue, but I do not think it would hurt to try it. Here is the link https://sd2snes.de/blog/cool-stuff/sd2snes-diagnostics

Again sorry for cutting in. Just wanted to help. Have a great day

That's weird, I thought that I was the only one that meet that particular issue.
Previously on my SD2SNES I had the exact same issue, but because of I also got several strange other bugs I didn't really pay attention.

I have recently bought a SD2SNES Pro and at first the "opening sound bug" doesn't occur at all. But since yesterday I have same issue once again.
That's why I now don't think it's SD2SNES hardware relative (I previously run the SD2SNES Diagnostics on my initial PCB without any problem).

For a moment I thought that it could be a problem with my 8BitDo Controllers but I tried with an original controller and experiment the same issue. I also thought about in-game hook that could mess the loading of the opening track but disabled them doesn't change anything.
I also now own a PAL Switchless unit with SuperCIC, uIGR 2.3 and D4 patch to eliminate any hardware region problem but it doesn't change anything either.
I'm sure that the patching operation of the DKC2 ROM was done correctly (because it runs normally at first), and no problem also with the "too long naming" in my file structure (I have tested it on the root of the SD card and my files names are never longer that eight characters to maximize compatibility).

If anyone thing about something I could test it will be more then welcome.

@alex_tenjo. Hello :-). Have you tried your new sd2snes pro on a third party system like the super NT, or did you play on the og snes? If you only have the OG snes, I would suggest if you have not already to clean the pins in your system. I know that might sound odd, but I have ran into some what of the same thing with my NES. If the pins on the connector are dirty or the brass contacts are dirty, that usually fixes the nose issues. Also do you have any sound system set up at all? Like a soundbar or a home movie theater set up. If so, I would suggest you unhooking it from your tv and then give it a shot. Sometimes for whatever reason sound systems do not like the old school systems and it can cause issues. I hope this helps you out. :-)

@alex_tenjo: there are several issues:
- we unfortunately cannot debug sd2snes issues (only geiger snes9x/bsnes) since there simply is no debugger
- None of us here coded the hack (dunno where Mattrizzle is) and each author has his unique coding style which might be hard to retrace to others (here this is the case)

Try following
- countercheck the patched rom on your pc with various emulators so you can be sure it is indeed a sd2snes related problem (and you didn't patch a wrong rom version or whatever).
Best is you try higan as well as this is the most real hardware related emulator available.
- if this all works, ask Ikari... none of us here is able to help you then.

I'll try and reproduce it... meanwhile I'll make an educated guess based on a similar issue with another MSU1 hack (unfortunately I forgot which one it was).
As the error seems to be dependent on the file system structure and individual SD Card used, it might be caused by the inevitable delays introduced by locating and accessing the file on card (and subsequently, the ROM hack not handling such delays gracefully).

Emulators usually have this as a zero-delay operation (SNES application requests audio track -> emulator synchronously opens file -> SNES emulation is resumed) so the busy flag will already be cleared before the next CPU cycle.

But in "real life" opening the file may take several milliseconds. Even longer on a hypothetical CD based MSU1 design.
If the MSU1 hack uses a synchronous busy loop inside the NMI this usually causes screen flickering but it could also have all sorts of other effects if the loop is overthrown by an IRQ or other NMI.
Likewise if a synchronous busy loop is located in the game's main loop it might be overthrown by an otherwise unexpected NMI or IRQ altering the game state or hardware state prematurely. That would depend on the invidual game at hand.

Most games seem to have no problem with it at all, but I recall Zelda 3 needing an asynchronous busy check.

Unfortunately, to my knowledge no emulators with MSU1 support have a feature to set an emulated storage access delay. I think 10ms-100ms would be a good range.

First of all, many thanks for each of your replies.
I ran several experiments following the Polargames and Conn advices.

@Polargames: Unfortunately I don't own any third party system, but I own five Pal Super Nintendo (for most of them are early models), and six Super Famicom (SHVC models for most of them with all the known CPU/PPU1/PPU2 combinations). I have test to reproduce the issue with at least the Pal units to remove the "possible console problem" and I can say that I got the "no logo sound" on each units (I haven't test with Super Famicom, but I can do it if you think it could be relevant).
Regarding the pins of my main Super Nintendo, I can say they are clean, but to be sure to eliminate that possibility, I have re clean all the pins (the removable slot on both sides and the pins attached to the PCB) with isopropanol.
I have a sound system but it's currently not used with my Super Nintendo and with my TV either. The sound goes straight form the console to the monitor and the speakers that produce the sound are the built-in TV's.

@Polargames: According to your first advice I have test the patched ROM on an emulator and I can confirm that everything runs perfectly (to let you know, the CRC of my patched ROM is: DFEDCC0E, it could be different on yours, but it's because I use IpsAndSum to correct the checksum).

Now, after trying various things, I can first tell you that the "no logo sound" bug (even if I now don't consider it as a proper bug) doesn't occur any more.

One one hand I'm convinced that the problem was not a "software" problem because the "faulty" ROM first works perfectly, and later without any noticeable change stop playing the MSU1 logo track. I can also say that putting that problem apart, everything works flawlessly with the patch ROM before and after the issue.
On the other hand I don't thing (even if it's not as clear as the "software" part) the SD2SNES PCBs are involved in the problem, because with two different units (an original Rev. H and a Pro model Rev. B), at first runs perfectly on both, and then suddenly stop working after time. The fact that the problem happened not immediately on the two different units, leads me to think that my initial SD2SNES wasn't a faulty board because the same thing occur on a SD2SNES Pro after several days of use.

What I think nonetheless is that particular ROM calls the logo MSU1 track very early after the initialisation of the cartridge. And it makes me start to think that a too long access time (as Ikari confirm extremely well) might be the cause of the problem.

That's why I started yesterday to use the SD2SNES built-in access time benchmark to check my SD cards performance. The results were extremely bad, after one week of use, the benchmark report more than 5ms max on my SD2SNES Pro which is far from being optimal for MSU1 (I also test it the day I received my SD2SNES Pro and I don't precisely remember the results but it were close to 1ms). That's the reason why I have decided to backup my SD card and reformat it with 32kb clusters setting (even if I think cluster size impact on an SD card performance should be minimal). Doing so reduce/restore max access time to 1.5ms. The results were better but not below the recommanded "less than 1ms".

Anyway, since I have done it the disappearance of the logo sound never occur again even after a lot of attempts.

I can confirm that the max access time on my initial SD2SNES, get worst time after time. I am sure of that because I took various screenshots of the SD2SNES benchmark screen since last year (to gather data about my Super Famicom CPU/PPU versions), and if you look to the attached screens, you will see a degradation of the performance.

I have done the same backup and format operations to the SD card of the original SD2SNES just before I offer it to a friend yesterday and it restored a much better max access time (and the logo opening sound on the same time). The technical information gave by Ikari and my tests drive me to the conclusion that it could be nothing but an access time problem.

I will try to get a better SD card than the stock one I received with my SD2SNES Pro unit.

Finally, (and if the conclusion is not wrong), I also think that the Super Mario All Star flashing opening screen I noticed (which happened randomly), could be also explained by a too long access time.

Once again thanks for the help you've provided, and please let me know if you think about anything else, I would be more that happy to do more tests.

The recommended access time applies solely to concurrent audio+data streaming (e.g. for FMV playback).

Access times for locating and opening a file inside a directory tree on card, and building a link table for its cluster chain, will take much longer than the measured access time of the benchmark because it entails a number of random read accesses. That is what the MSU1 busy flag is for, after all.

MSU1 applications must accept arbitrary busy periods (or at least some hundreds of ms) when requesting a new audio track or a new data offset so the MSU1 hardware can prepare the new data. It is not the SD Card's or user's responsibility if the patch fails on that occasion. But of course trying to minimize access times can serve as a workaround.

Ikari, now that you finally are here again can you give an answer to the question whether the save while playing with msu is fixed in sd2nses pro

SD2SNES Note: Problems with saving is a known issue with MSU-1 enhanced games on the SD2SNES.The game saves only with this technique your progress: In order to save permanently, you'll need to "Save and Quit", and then either press L+R+Select+X or press and hold the reset button on your console long enough so that it resets to the SD2SNES main menu.

Is this also necessary in the pro version and/or is there a chance this gets fixed with the larger fpga in future?

@alex_tenjo, I am happy that your no logo sound went away. Your systems have covered all the bases for sure, you can try it on your Super Famicom, but I do not know if the 60Hz on that would make any difference, except fps of course. Also great job of cleaning your pins, great to here they are in the best shape as can be, and that you have your system connected right to your tv. That takes a lot of factors out. :-) I am happy that the rom worked on your emulator, and the checksum being different from mine thats a ok with me :-), I do not fix mine at all. But thank you for the information on the CRC. Now about the SD card, that might be your problem because sometimes the very cheap ones that are shipped are bad, So your on the right track on getting a better one. If I could make a suggestion on brand of sd card I would say Sandisk would be the better pick, but that is up to you and what your budget is also. Also it could be the software on the sd2snes could of had a hiccup at that said point. 9 times out of 10 software works fine, but every now and then it can go weird. So that might of been the issue. I really think its your sdcard card that came with it. When you get your new one could your run the same test you did on the read time for said sd card. I would like to look at it if thats ok with you. :-) Great Job all a round, happy that everything worked. :-D P.S Thank you for the Thanks to Conn and myself. Were happy to help out :-)

@ikari_01
Thanks for your detailed explanation; I didn't know about the busy flag that's obsoleted what I thought. In the end, the true problem behind that (supposedly) bug is unknown still. However, as you wrote trying to minimize access times isn’t a bad idea, and indirectly solved the problem.
One additional thing: Can I please send you a pm for another technical question? (There's no rush at all for that).

@Polargames
Thanks for your comments; I will try it on Super Famicom if the problem occur again. I also think that it wouldn’t make a difference, I just say that because several problems arise on my PAL system and not on my Super Famicom. Nevertheless, I now use a Switchless PAL console and the SuperCIC should eliminate any compatibility issue.
I will follow your advice and get a better micro SD Card. The stock one I received is a Kingston Class 10 UHS-I, I will look for an UHS-III to eliminate any potential problem (even if this rating stand for write performance and not latency, UHS-III should be better anyway). I will let you know once I get a new micro SD and run tests.

Thank each of you three again for your time spent on that strange case.

@alex_tenjo, You are more then welcome and I wish you good luck on your super famicom also. :-)

Sounds good, Kingston used to be a good brand for sd cards and flash drives, but now they are so-so, and I cannot wait to hear the results of your new sd card. :-D

@Polargames
I have ordered a sort of high end SanDisk micro SD Card. I should received it next week, I will let you know :-).

alex_tenjo wrote:@Polargames
I have ordered a sort of high end SanDisk micro SD Card. I should received it next week, I will let you know :-).

AWESOME!!!!! I can not wait for your tests, and thank you also for letting me know

@Polargames
Ordered high end SanDisk micro SD Card has been received on Saturday (~0.620ms average access time according to the SD2SNES built-in benchmark). After spending some time testing, I can say that I haven't met an issue so far (except for the Japanese version of Final Fight Guy, but I will post details in the game section). I never get the DKC2 opening sound "bug" again.
Thanks again for the time you took to help/reply me.

@alex_tenjo Awesome, and great speed on it also. I am happy that you did not get the bug at all. Your very welcome and feel free to post anymore issues you have ran into. :-)