just a sidenote, in the last SNES PowerPak update it is possible to have the .srm files in the /POWERPAK/SAVE/ directory and if a .srm file has the same name as the rom file then it will be auto-chosen in the load screen , no need to manually browse for a .srm anymore
Sure, but it's still an extra, probably unnecessary screen to go through, when you could just have numbered saves and probably numbered .cht files of some kind as well (with perhaps an extra step for manual entry of cheats).
^ yeah, just sayin'... also you can load cheats from .txt or something, never tried it as I am not a fan of cheats...
anyone knows what is the correct set of DSP "bios" to use? the set working for BSNES 0.73 - 0.86 or the new BSNES 0.87+ ones? thanks in advance
I've just done an hexdump and compare of the two sets "bin vs rom" and I have to say I am a little confused on how the heck they made them different. For once it looks like the CX4.rom=CX4.bin no differences whatsoever but for all other files the bin to rom or rom to bin conversion is not a simple byteswap. It seems like you can go from one file to the other by reading 3 bytes at a time, swap 1st and 3rd (leave 2nd where it is) and write the 3 bytes to the second file, then continue onto the next 3 bytes until the end. So if your source file is a bin or rom with the following content "B1 B2 B3 B4 B5 B6 ...." you get to the rom or bin file by doing "B3 B2 B1 B6 B5 B4 ...". The file size happens to be exactly divisible by 3 for the 8KB dsps and for the 52KB sts. I have no idea which system would read 24 bits (3 bytes) at a time and do a 24 bits (3 bytes) byte swap. Very weird. Anyway I hope ikari moves to the ROM format (except cx4 as that one looks the same, go figure) so if in the future st018 can get implemented in fpga (maybe with HLE only) we don't need to mess up the firmwares as st018 is only present in the new rom format (which cannot be checked against old to see if the 3 bytes swap is there too, although its size of exactly 160KB is divisible by 3). Just got the memo my sd2snes is on its way ... can't wait to enjoy it.
Is anyone else here noticing the clock on their sd2snes running fast? Mine is now almost an hour ahead since I set it on july 2. Again, its not terribly important to me, but it may be for somebody. Also, I've noticed a few graphical glitches playing chrono trigger. I can't remember if they happen on a real cart or not. I'm gonna try to transfer my save to my real cart with my game doctor and see if it still happens.
That is a moot point, as the ST018 is probably the most powerful special chip out there, used only on a single shougi game (for fast AI, I think), and it will almost certainly never work on SD2SNES. The chip basically uses an ARMv3 CPU as its core. (Edit: Oh, I just saw your thing about high-level emulation. Still, even if that day comes several years from now, I don't think it will be that big of a deal to convert the file format.) As for the file formats, I think I saw somewhere that one format is big-endian, and the other is little-endian. That is the only difference, I think. Hrm, now that you mention it, it looks like I've gained about 30-40 seconds in the month I've had it. A lot more tolerable than an hour in two weeks though. And what kind of graphical glitches, and where?
My point was that given the only emulator that really uses them is bsnes and it moved to the new format I think SD2SNES should move to. Not exactly. If you compare an hexdump yourself you'll see it is not simple endianess unless defined over 3 bytes, which is why I thought it was weird. Big endian and little endian normally are defined at the 2 bytes or 4 bytes or 8 bytes level, never seen one at the 3 bytes level, yet that is what makes you go from a rom to a bin and viceversa for those files. Maybe those DSP are 24bits processors, dunno, with 24bits wide ISA. Nevermind .... I think I found some evidence http://www.kybernetika.cz/view_file.html?item=1139 (page209 table2) that the NEC uPD77C25 (which is the dsp1...4 according to http://byuu.org/articles/emulation/snes-coprocessors) has indeed 24bits wide intructions (the table shows an internal 2K x 24 internal program memory), so it would make sense that its ROM is also 24bits and then the endianess defined at the 24bits level .... I should have done my homework I just took for granted there were no 24bits ISA.
I can try to describe it. When you're battling a debuggest (in my case, on the conveyor in the Geno Dome), they have this rainbow laser attack that kind of sweeps across all of your players a few times and they all turn white while its happening. Random white garbage pixels kind of show up around my characters when this is happening. I can't remember for sure if this happened on the original cart, its been a while since I played it and I can't recall. I looked on youtube, but all I can seem to find is emulator footage. I'm gonna see if I can transfer my save, from the sd2snes to my original cart, using my Game Doctor as I'm nowhere near any robots in my game on the real cart. EDIT: Ok. After much effort, I managed to copy the SD2SNES .srm onto my original cart. Needed two computers to do it (my computer's floppy drive doesn't work, other computer's SD card reader doesn't work...) I can confirm this glitchiness does NOT happen on the real game cart. I'm gonna make a video comparing the two and will post it here shortly. EDIT 2: Uploading video. When it's done, it'll be here. Its certainly not a big deal, as it doesn't affect gameplay at all. Just a minor annoyance. If anyone wants to test on their SD2SNES, I can upload my .srm file. EDIT 3: As it may be useful, here is my System Information: EDIT 4: It seems my problem has fixed itself. Maybe a contact was dirty in my SFC or something. But I can't get it to happen at all anymore. In any case, the RTC issue remains.
Good to hear that it's all right now. And I feel your pain with the floppy stuff; I would just be screwed if I had to use a floppy for anything nowadays. I do have an old computer in the closet with a floppy drive, but I would have to install another hard disk in it (or perhaps use a LiveCD) just to do anything with it, and I'd probably have to blow years of dust out of the drive. Or maybe I'd pull it out and try to temporarily hook it up to my Windows 7 machine... I fortunately have a Mash Mods USB unit that I can use to transfer saves (not as elegant as, say, a Retrode, but it gets the job done).
What's really bizarre is I swapped the floppy drive that's currently in my computer with the one in this other computer because mine wasn't working and the other was. The other computer reads with my old drive fine and mine still can't read disks. Either my cable is bad, or something is damaged on my motherboard. Who knows. Good thing I don't need to use floppy disks much. Someday I'm gonna get a straight pin-to-pin parallel cable and hook the SF7 up directly for this kind of thing.
LPTs are in extinction too adimifus , don't really count on pci-lpt cards too... you should go with a USB floppy IMHO , they are dirt cheap and are fine almost everything
I know that issue in Chrono Trigger. It happens at random, seems to be a PPU timing sensitive thing. It does happen with the original cartridge as well but, like with any flash cart, not every time. Also happens in the intro where the giant frog is summoned.
Ah, interesting. Thanks for the info. Any idea why my rtc might be running fast? It's around an hour ahead of where it should be since I set it on July 2. I have an old laptop I'm planning on using for old programs and to load stuff onto the game doctor. I wouldn't even bother trying that on my main computer. LPT is too much of a pain with modern operating systems, although my motherboard does have one.
Is it possible to play with SD2SNES PAL games on a NTSC SNES without modification of the roms? Thank you
The embedded RTC of the microcontroller used isn't terribly accurate. The maker provides a software calibration register for that reason but It's not used yet. Due to variation across units calibration would have to be done by the user by setting the clock initially, then correcting it after a while so the firmware can determine a correction factor. sd2snes circumvents the region check via register $213F (which makes many games print "This game pak is not designed for your yaddayadda".) so all games should boot. Some PAL games may have adapted their timings to PAL consoles so they may show glitches when run on NTSC.
