![]() ![]() The Shift key(s) seem to confuse the GUI a lot. I'll try and see if there's a solution for it. I had assumed the whole disappearing from Alt-Tab when a tool window is opened to be a Windows issue (but maybe its a WinForms issue?), I've always found this to be pretty annoying myself, though. I can't remember the exact details anymore, but I know I did actually try to fix this at some point in the past. Sour wrote:Shift not being differentiated is a bit of a limitation to the way keys are processed in both Mesen & this one. That being said, please don't feel like you *have* to add these! At the very least maybe this list will someday be useful for someone else trying to debug their emulator :p The majority of these I found and fixed by debugging games that didn't work properly, so having test roms to validate these would have saved me a lot of time (and having them for regression testing would still be nice, too). The ADC/SBC tests don't catch everything, either, but since blargg made some tests for those particular instructions, it's not a big problem. Validate some of the DMA restrictions (e.g trying to DMA from work ram to work ram, etc.)I think those are the main ones that aren't PPU-related at all. Check that the "decrement" flag is ignored by HDMA Check that the "fixed transfer" flag is ignored by HDMA I think BRK/COP aren't tested at all? Could be wrong - I had forgotten about the signature byte and so RTI wasn't returning to the correct address. ![]() ![]() TSC/TDC/TCD always transfer 16 bits, regardless of the 8-bit memory flag Check that MVP/MVN can be interrupted by an interrupt (this one might be a bit outside the scope of CPU-only tests, though) Check the wrap behavior for X/Y when 8-bit indexes are enabled Check that the value of DBR is altered by the instruction Check that the destination/source bank are correct (I had inverted them by mistake) Shift operations when 8-bit memory flag is enabled shouldn't affect the MSB of the A register Or at least, they're most interesting to work on when compared to implementing the 150th slight variation of an MMC3 clone :|Ĭode: Select all -The CPUPHL test seems to rely on open bus behavior for $4210 reads, which is a good test in a sense, but also confusing when trying to debug it SGB is probably not something I will end up supporting (or at least, not anytime soon), Sufami Turbo I hadn't even ever heard of yet!īut still, I think ~30 somewhat complex boards (e.g coprocessors, etc.) is probably more manageable than the NES' 300+ comparatively simple boards. I might stick to heuristics for now (especially if they work for the vast majority of games), but might try incorporating the database eventually just for the sake of having accurate mappings for known boards. The database info will definitely be useful whenever I need to confirm if the default mappings might be an issue or not. It's been working pretty well (far better than what I had done initially), but I haven't gotten to implementing Ex-HiRom and the like at all yet. I was actually already using a slightly modified older version of your heuristics that you had posted on the zsnes boards like a decade ago, actually. Byuu wrote:The CPU NMI and IRQ timing is based off of the Vblank and Hblank pin outputs from the PPU, and it keeps its own internal counters, which means that IRQ timings are not affected by long dots.This (and well, your whole post really) is actually very important information, thanks! ![]()
0 Comments
Leave a Reply. |
Details
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |