Default Key Bindings
Key bindings are defined at line 362 of my script:
- Left bracket/right bracket: Wider/narrower RAM display
- Numpad +/-: Taller/shorter RAM display
- PgDn/PgUp: Next/previous "block" of RAM
- H: Cycle through palette types (prime --> random --> monochrome --> prime)
- J: Cycle through RAM value modes (unsigned --> signed --> hex --> unsigned)
- K: Toggle display cursor
- M/N: Use next/previous palette ("prime" mode only, basically uses the next/previous prime number)
- Keypad 1-9: Display RAM at the corresponding position on the screen
I've had a lot of fun just using the script to "explore" the RAM. Just play the game and see if you notice anything interesting going on. But if you want to use it more systematically, start by considering just what you're looking for. In the case of Mario jumping, I can look at the RAM for pixels that change only when Mario jumps. Switching to monochrome helps because I can then look for pixels that dim or brighten as Mario follows his trajectory. The prime and random palettes are best for detecting any amount of change while monochrome is great for finding RAM values that change continuously.
A quick note on palettes: "Prime" is based on producing a hash of the form p^b mod 256, where p is a prime number and b is the value of the byte in question. This means we can move backward and forward through different palettes of this type. Find one you like and make it your default value! On the other hand, "random" is exactly that-- random (except for value 0, which is always black). If you find a random palette you like, don't cycle through to monochrome or you'll never see that palette again.
Possible Improvements and Open Questions
I'm content with where this script is in its development, but there are a few improvements I could make.
I considered adding a "blackout" feature that allows users to exclude RAM addresses that they already know they aren't interested in. This would be useful because gui.drawPixel is computationally expensive (when you run it 4,000 times per second) and the program would run faster if we didn't bother rendering those pixels.
I only allow the width and height of our box to change by multiples of two. I don't care to program in other increments, but it wouldn't be all that difficult either. As such, if anyone
wants that feature, I'll throw it in.
Want to investigate words or larger domains? Or individual bits? Too bad! I'm not sure how I would implement those features at this time and I dread having to program in support for big and little endian. Of course, if there's overwhelming demand for it, I'll see what I can do.
Finally, open questions I need help with. As of right now, the script is tailored to NES and Game Boy games. What I need to make my script more robust are a) valid address ranges for other systems and b) screen dimensions for other systems. If you can pass that information on to me, I'll transfer it straight into my script immediately.
And of course, if you have any other thoughts or want me to add any features, let me know!
Minor change to my script to fix an off-by-one error that prevented paging forward when on the penultimate page.