![]() Oh, thats not the only good news either as far as translation progress goes. what with the lack of needing to hit Esc all the time as mentioned above. Tbh, i've actually gotten more used to using snes9x vs zsnes, its just easier really. only problem is, due to the translation patch making the rom have a bad checksum, snes9x won't run the game at all and gives the message "bad checksum" when i try to. That's weird, I thought that I was the only one that meet that particular issue.Anyone know how to do this (easily if at all possible)?Ī full retranslation of FFIV for snes came out recently ( ) and i was wanting to play it on snes9x as its a bit more convenient than having to hit the Esc key all the time when i need to change anything in the emulators menus like with zsnes. 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).į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. 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. 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. 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. ![]() I can edit and save in Lunar Magic but can't actually load the game to see if those changes are being. It seems to alternate between saying bad checksum and checksum ok but regardless the game won't load. ![]() 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. The message shown on screen is: 'SUPER MARIOWORLD' checksum ok LoR 0m, 16Mbits, ROM+RAM+BAT, NTSC, SRAM:16Kbits, ID:, CRC32:19E2B1F8. 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.įirst of all, many thanks for each of your replies. 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 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. Check the hack page and you'll see the creator will usually specify a rom type (headered or unheadered) Typically for hacks I use the Japanese unheadered rom and rarely have problems. I have a sound system but it's currently not used with my Super Nintendo and with my TV either. You've got a mismatch between the rom the hack was built with and the rom you're patching the hack to.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |