3D Sonic the Hedgehog for the 3DS doesn't use ROM patches to apply changes... Instead, what it does, is that it checks for certain conditions, and when appropriate, it will override the emulator, run its own code, then give back control to the emulator. No ROM modifications are made. For example, it will check if Sonic is spindashing, and when the 68000 gets to LoadSonicDynPLC, it will stop the 68000, transfer the appropriate spindash art (depending on which frame it is), then set the 68000's PC to the end of LoadSonicDynPLC, and then let the 68000 run again. (You can see that here) There are many more routines in the ARM code like this. All the extra VDP stuff used to do the 3D effects are done with this method as well. But hey, this is one step closer to figuring out the extra VDP features. You would just need to look in the ARM code in ExeFS (base address is 0x100000). Luckily, finding references to 68000 memory is rather easy, as it's all basically how it would look on the MD (i.e. you will be able to see things like 0xFFFE10 and 0xFFC800 referenced in the ARM code and it would be referencing to MD's RAM). The extra VDP stuff is mapped after the standard VDP addresses, so in the $C00000-$DFFFFF area.
Post from TheStoneBanana on SSRG (I have his permission to post what he posts there here) It should be noted that this was tested with Sonic 2, but not Sonic 1.
Well, similar to the corrupted save state hex editor for Super Mario World for SNES, could a Sonic 1 hack be made to poke and prod the memory addresses associated with Sonic 1's 3D rendered elements? That hack could then be run within the emulator I suppose...
I just realized I completely forgot to post this here. A while back near the end of June, TheStoneBanana gathered a pretty complete memory map for the Gigadrive's extended VDP: