While reading the Dolphin Emulator website, I learned that this section of the forums existed. I hack Pikmin 1 & Pikmin 2 as a hobby. Recently, our community has had an explosion of people learning about assembly editing, myself included. From my time using Dolphin's debugging tools, I have some suggestions for new features and improvements that will positively effect virtually all GC/Wii modding communities!
There are three ideas that I have thought of so far.
Anti-Breakpoints
This is a basic tool that would speed up my workflow tremendously. It goes like this:
If a
Memory/Register Breakpoint is tripped, Dolphin then checks to see if the processor instruction responsible has an
Anti-Breakpoint. If it does, emulation will continue as normal.
If a
Processor Breakpoint is tripped that interacts with memory/registers, Dolphin then checks to see if the memory range/registers has an
Anti-Breakpoint. If it does, emulation will continue as normal.
For the former example, this would be incredibly useful when a particular memory address (usually static data) is accessed multiple times in an irrelevant loop. Sure, there are messy configurations one could create to push past the annoying loop, but that's no good. For one, Dolphin's breakpoints are already hard to keep track of and a messy configuration would compound that. For two, repeat experiments are difficult depending on how you do the configuration. Having this basic yet powerful tool would save so much time.
For the latter example, I actually am not sure how useful it would be, but I'm sure having Anti-Breakpoints work both ways will be better in the long-run. I don't know everything, after all.
Emulated Memory Override
While exploring the internet, I learned about a leaked build of Metroid Prime 3 exists for the GameCube, and that the only reasonable way to run it is via a modified build of Dolphin Emulator that allocates more emulated RAM to simulate a NPDP-GDEV unit. The commit that added this feature to the master branch to be optionally changed upon compiling is
here.
This feature has always piqued my interest, but now that I am into game modding, even more so. You see, Pikmin 2 is pretty starved for free memory, which leads to custom course models being a pain to make. However, when running in a build of Dolphin with more emulated RAM, Pikmin 2's MEM heap / CPU bar actually recognizes the extended memory range!
![[Image: lAvkDmc.png]]()
If our community could solve how to expand the OSArena(?) to create a larger heap, we could make new content that would be impossible on the original hardware! (Think like how Project 64 can have its memory expanded and how the SM64 community uses that very often.) This would also make using Dolphin Emulator to test game prototypes like the Metroid Prime 3 one much easier to do on recent revisions.
So here's how I visualize it; a slider just like the Emulated CPU Override one in pretty much the same menu. On it are clearly marked intervals for retail GameCube, retail Wii, NPDP-GDEV, etc. (I am unfamiliar with Wii dev units; did they have even more RAM?). I suppose emulating less RAM ought to be possible as well, but I cannot see many reasons why one would want that. Essentially, take what is normally a feature exclusive to dirty builds of Dolphin Emulator (not friendly for sharing game mods), and make it easily configurable for anyone on the latest revision of Dolphin (which, btw, is so loaded with awesome tools for hacking. I want to take a moment to thank you guys.) How neat would that be?
This slider would obviously only be configurable while no emulation instance is running. Hopefully this is an easy feature to implement?
Better Annotation in Code Dumps
My final request is a smaller one (I think). I find it odd that Dolphin's live disassembly in the code window can tell you exactly what function a branch instruction jumps to, yet code maps that can be generated under Symbols > Save Code only mentions the memory offset.
![[Image: DoH5zVZ.png]]()
Can the code maps have the feature implemented to them that the live disassembly already has? Perhaps omit the function name for in-function jumps, as that would be a bit redundant.
I apologize for the high volume of requests I have made. I would love to help implement them myself, but as good as I am at hacking Pikmin games, I am still hopeless when it comes to C++. I can only hope that these additions are as easy to implement in practice as I think they should be.
![[Image: 9EPMkz5.jpg]](http://i.imgur.com/9EPMkz5.jpg)
I was working on the chapters as I progressed
![[Image: BKpfHr8h.png]](http://i.imgur.com/BKpfHr8h.png)
![[Image: Sutxhxbh.png]](http://i.imgur.com/Sutxhxbh.png)
![[Image: ZTM9fmkh.png]](http://i.imgur.com/ZTM9fmkh.png)
![[Image: BBKGb2Gh.jpg]](http://i.imgur.com/BBKGb2Gh.jpg)
![[Image: GZzD5xqh.png]](http://i.imgur.com/GZzD5xqh.png)
![[Image: 3P3JtwXh.png]](http://i.imgur.com/3P3JtwXh.png)
![[Image: FBsDcTkh.png]](http://i.imgur.com/FBsDcTkh.png)
![[Image: Nz05uvyh.png]](http://i.imgur.com/Nz05uvyh.png)
![[Image: K9LaKFGh.png]](http://i.imgur.com/K9LaKFGh.png)
![[Image: UuVpTuoh.png]](http://i.imgur.com/UuVpTuoh.png)
![[Image: E0ToQ6Xh.png]](http://i.imgur.com/E0ToQ6Xh.png)
![[Image: dabJzyVh.png]](http://i.imgur.com/dabJzyVh.png)
![[Image: L6ybncFh.png]](http://i.imgur.com/L6ybncFh.png)
![[Image: LN7mIjeh.png]](http://i.imgur.com/LN7mIjeh.png)
![[Image: NGRSUtCh.png]](http://i.imgur.com/NGRSUtCh.png)
![[Image: lx1GqARh.jpg]](http://i.imgur.com/lx1GqARh.jpg)
![[Image: J5UoZjHh.png]](http://i.imgur.com/J5UoZjHh.png)
![[Image: 0WO4Tyxh.jpg]](http://i.imgur.com/0WO4Tyxh.jpg)
![[Image: kRi3Cnth.png]](http://i.imgur.com/kRi3Cnth.png)
![[Image: q3yko8dh.png]](http://i.imgur.com/q3yko8dh.png)
![[Image: miniupdatae-libusbheadermini.png]](http://dolphin-emu.org/m/user/blog/minis/libusbhotfix/miniupdatae-libusbheadermini.png)
![[Image: lAvkDmc.png]](http://i.imgur.com/lAvkDmc.png)
![[Image: DoH5zVZ.png]](http://i.imgur.com/DoH5zVZ.png)