I have a sound system but it's currently not used with my Super Nintendo and with my TV either. 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 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).
I ran several experiments following the Polargames and Conn 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 think 10ms-100ms would be a good range.įirst of all, many thanks for each of your replies. Unfortunately, to my knowledge no emulators with MSU1 support have a feature to set an emulated storage access delay. Most games seem to have no problem with it at all, but I recall Zelda 3 needing an asynchronous busy check. That would depend on the invidual game at hand. 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. 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. Even longer on a hypothetical CD based MSU1 design. meanwhile I'll make an educated guess based on a similar issue with another MSU1 hack (unfortunately I forgot which one it was).Īs 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).Įmulators 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.īut in "real life" opening the file may take several milliseconds.
If anyone thing about something I could test it will be more then welcome. 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).
#Snes9x bad checksum Patch
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 also thought about in-game hook that could mess the loading of the opening track but disabled them doesn't change anything. 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).įor 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. But since yesterday I have same issue once again.
#Snes9x bad checksum pro
I have recently bought a SD2SNES Pro and at first the "opening sound bug" doesn't occur at all. 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. That's weird, I thought that I was the only one that meet that particular issue.