Yes, NewRIsingSun wrote this tool.
Ah, makes sense.Sour wrote: ↑Wed Jan 15, 2020 7:55 pmYea, I'm aware of this one - it's a dumb technical limitation (the "Code" menu is actually a copy of the disassembly's right-click menu, in which the option is selected properly) that I haven't found a neat solution to and don't think the issue is important enough to write some more code just to fix this specifically (vs finding a more general solution.)
It just forces me to restart the game sometimes while debugging. Now that you’ve explained it, maybe it will be less of a “problem”. (It’s not a big problem... your numerous debugger options usually help return to the debugging point to be quick and painless.)Sour wrote:It's just due to the way this is coded, it forces the game to finish the current frame before it reloads the CDL and regenerates the disassembly cache. It's fixable, though, but is this really an issue? I don't imagine many people frequently manually load external CDL files..
It may be only me; I don’t use fasm so I manually load external CDL files; after learning how you created CDL files to work, it’s really fun and beneficial, for me, to manually edit them.
If you're generating the .cdl file as part of your build process, you should just be able to write the .cdl file next to the .nes file & enable the "auto-load .cdl files" option in the workspace options of the debugger to avoid having to load the .cdl file manually after having started debugging.
Thank you Sour! Often, my computer is sleeping when I’m not using it... and so Mesen debug remains open as I use it for many days at a time. Gtg.Sour wrote: ↑Mon Jan 27, 2020 8:44 pmIf you're generating the .cdl file as part of your build process, you should just be able to write the .cdl file next to the .nes file & enable the "auto-load .cdl files" option in the workspace options of the debugger to avoid having to load the .cdl file manually after having started debugging.
Also, in the log window it displays CRC32 of PRG alone but not of CHR alone instead it's combined PRG+CHR.
Can you add single CHR CRC32 as well?
Maybe add board type as well, if possible.
Code: Select all
Note: Version 0.9.9.0 is being used now.
Thanks, this should be fixed in the latest dev build now.
I'll add it to the list of requests.
As for a separate CHR CRC, I don't really see too much value - I've actually recently discovered that a good chunk of the time used to load/reload a rom in Mesen is caused by the fact it's calculating a ton of different CRC types (MD5, SHA1, etc.) to support a variety of stuff. I've recently replaced the CRC32 implementation by a much faster one to reduce the impact, but I'd still rather not add *more* CRC calculations to the load process (if anything I'm more likely to remove some and only calculate them when absolutely needed)
What if you only calculate the CRC if someone opens the log window to have it display? This shouldn't interfer with ROM loading too much, I think.
Otherwise I'd just remove the CRC check completely since the NES didn't have any checksum anyway. At least not that I know.
I'm trying to understand proper nmi timing. Let's take for instance: SMB (or just about any game) - if you look in the event viewer, the nmi happens on line 241 between cycle 26 and 33. What's the logic behind the thing that causes the nmi to be delayed like that. I know older emulators would run X-amount of cycles before the vbl on line 241 to make some games happy (marble madness, b-wings, bad dudes, etc). I want to know what the hw-accurate way to know which cycle to run the nmi on. from what I can tell, Mesen is running the nmi @ cycle 0 on 241 (in ppu.cpp), which is even more confusing because PPUCTRL is 0x80 @ 241 cycle 0 I hope you or someone can shed some light on the logic behind this one.
The NMI/IRQ dots in the event viewer correspond to the first cycle of the first instruction of the NMI/IRQ handler, not the timing at which the IRQ or NMI flag was set nor the time at which the CPU registered the NMI/IRQ.
In practice, this means the dot is 21 pixels late (because the NMI/IRQ handle takes 7 cpu cycles, iirc). Add to that the jitter caused by the current instruction needing to finish before you can jump to the IRQ/NMI handlers and 26 to 33 dots sounds about right in most scenarios.
The timing variation from frame to frame comes from the fact that once the PPU requests an NMI, the CPU has to finish executing the current instruction before it can carry out the interrupt, so the exact timing will depend on how many cycles are left to execute of the current instruction. The extra 21 PPU cycles are there because it takes time for the CPU to push the current PC and status flags to the stack and jump to the address indicated in the NMI vector. This takes 7 CPU cycles, or 21 PPU cycles (in NTSC).
You’re welcome. Thank you so much Sour; using 0.9.9.13 now, it’s much smaller than 0.9.9.0 ; am now able to follow selection with pressing del on keyboard and that entire Watch line disappears! Wonderful!