This exact subject has come up before -- https://forums.nesdev.com/viewtopic.php?f=12&t=12419
-- and we went over it in great detail. That said...
Important detail easily overlooked in this
thread: video in question is discussing how to examine CPU usage through reverse-engineering an existing game
, using the feature of an emulator and its native Lua plug-in to "do magical stuff". That "magical stuff" is often not stuff you normally can do in native 65816 or in game code; it's usually "added on" functionality at the emulator level. But it really varies depending on the implementation in the emulator. This is a problem because at first glance, things like YouTube videos seem "magical and neat OMG!" yet in reality they're doing stuff that really isn't in native code running on the console itself. This gives a false impression about what the console itself is doing, unless the video author is very explicit about it (they often aren't).
So... I looked at the Lua script
. Several things:
I don't see how $2C3 matches up with $0082C3, but according to this disassembly
$0082C3 is indeed the rti
instruction at the end of NMI.
So I have to assume $75 means $8075, which is an stz $10
instruction; that direct page location ($10) has some relevance pertaining to "lag" in some way. What bugs me about this is that the little loop involving $8075 does a jsr $9322
(this is still in bank $00), yet the code at that address isn't included in the disassembly. Instead, if you dig around the disassembly, you'll find that the person who did it omitted the address and instead called $9322 GetGameMode
-- how nice that they they didn't update the label in the jsr
statement. The "guts" of the main loop are actually in a complicated routine called ExecutePtr
. So, the individual keying off of $75 / stz $10
is basically his/her "best-effort guess" at where the "main loop" ends -- and it's close enough.
In short: those "magic values" are some emulator-specific nonsense, and the person who did that video / did the script explained them in a very nebulous way. This doesn't surprise me -- common in the "SMW hacking" community and the like, as many there are folks who like to fool with this stuff but aren't really programmers (i.e. have never written code on the console). That said: I don't see why the emulator didn't just let you use the explicit ROM address, ex. $0082C3, since NMI always starts/executes in bank $00. Whatever. (Sorry, this type of stuff annoys me to no end; magic numbers
really tick me off, as it only takes the person writing the documentation a sentence or two to explain their purpose).
The Lua script also clearly is drawing rectangles and graphics, i.e. overlays, on top of the existing visuals. But achieve this in natively 65816 on the SNES itself is similar in implementation, yet very different when it comes to getting the actual
visuals. That leads me to discuss how to do it natively:
I don't think mosaic ($2105) or things like screen brightness ($2100) will be "visual" enough to notice, particularly if the amount of CPU time being used is very low. It would work for things that take a long time, but for shorter things, nope. That's why in the thread I suggest using the PPU colour add/sub registers or screen sub capability, which I'm pretty sure is what the individual in the video is using for the varying-length "green overlay" on top of the actual playfield. But give them a try and report back. The previous thread I linked should give you some ideas of what to try.
Otherwise, for how to use Lua/etc. to "tie in" to your own game's code to achieve the same thing? You're going to have to look at a code listing, or a label listing (with addresses), and know where in 65816 address space things are located. Maybe your assembler or compiler can do this for you, I don't know. You can alternately disassemble your own code and figure it out.
You'll find that getting emulators to "tie in" with your own native code isn't usually possible, e.g. you can't magically make a label in your code called "EndOfNMI" and then in some Lua script say "do something at EndOfNMI". There's no connection between the two things, hence why actual addresses are needed. To my knowledge, there's no SNES emulator that is so "integrated" with development tools (assemblers, compilers, etc.) to do this natively.