I wholly understand your sense of perfectionism. I'm hopeful that Sour's emulator will be a worthy alternative for people who are tired of putting up with me, and give me some more room to experiment with my emulator.That nonsensical pedantry and research has given us a wealth information and made the SNES emulation and development scenes go forward (which can't be said about for example Nintendo 64 emulation until much more recently). I'll do my best going forward to act professionally. I know how annoying I've been about all of this, and you all have my apologies for that. I can't really separate the two, nor is this a condition that can be cured. I get huge levels of anxiety when things aren't "perfect" in my mind. The same ASD that led to me spending 15 years perfecting an emulator for a retro video game system is what also drives my obsession with supporting absolutely everything I possibly can. * CPU soft reset acts just like a regular interrupt: it pushes the PC address and P register onto the stack, but there was a gotcha because the CPU switches to emulation mode on reset which causes stack wrapping around $01xx.īut there's definitely more I'm forgetting in there. * it takes either 186 or 188 cycles to complete a CPU reset before code starts executing (it varies) * VIRQs and HVIRQs fire one scanline later than expected on the very first frame after reset (likely the CPU counter is misaligned) * if you write to VRAM on the *very* last possible cycle before frame rendering starts, it writes the CPU open bus value to VRAM instead of the value you wrote to it It took forever to test every possible thing it could be on my old SNES copier.) ** (^ I spent weeks tracking that down because latching IRQ / NMI PPU counters kept being off slightly from real hardware. If the bus read is from a slow ROM region, this will cost another 2hz of time to pass. * when OAM interlace is on, and sprite size is 0, OAM sizes 6 and 7 are halved to, eg nop, inc, etc: then the I/O cycle is transformed into a bus read cycle from the current PC address instead. ** (^ likely to fix the CPUr1 crash when performing DMA and HDMA at the same time) * the DRAM refresh point plus the HDMA frame initialization point is different between CPUr1 and CPUr2 A lot of my findings I never wrote about. You probably will want to dig through the bsnes source code though. I feel you on test ROMs and documentation. If you don't want to provide an address to send it to (I wouldn't blame you), I can Paypal you some funding for one. If you'd like the means to test your code on real hardware, I can send you my sd2snes. * Taz-Mania Īnd also lack the equipment needed to run them * Bishoujo Janshi Suchie-Pai and Marvelous (SA-1) * Koushien 2 (if you ever replace blargg's DSP with your own, test this one) Here's my evil games list, in case you wanted to test them, creaothceann: Thanks for testing so much, by the way, really helpful to get bug reports like these.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |