I got to the last boss (second form), but I'm not good enough to beat him. I tested it with ME, Mednafen, and the real system (SGX) and it ran fine. Ootake and Yame have so issues with timing that causes scrolling glitches. Surprisingly, it didn't take long to get it up and running (I think 2 days). It uses about 80% of megaman's backend code. Anyway, give it a try
I wanted to mention that Kid Icarus, as well as Metroid both use WRAM mapped at $6000. This is probably due to the games being for Famicom Disk System originally. So it's rather amusing that both of these games could have had save support if Mr Potatomoto used SRAM and a Battery. Instead I guess it's just a regular RAM chip. But anyway since you have the PCE Registers mapped at $6000 to $7FFF that is a problem, though I'm guessing you put them there so they wouldn't be at $4000 to $5FFF since the Mr Potatomoto code could end up writing there?
But anyway, for Kid Icarus or Metroid you'd have to change all usage of the 8K of extra WRAM to some of the PCE's WRAM after the first 0x800 bytes which the NES sees as the built in WRAM. The problem is that both these games would need to not use the whole 8K or else you wouldn't have enough. Though I don't know how it works with HuCard's containing SRAM. You must since you were talking about Zelda 2.
Yeah, if the game requires most of the additional 8k of SRAM for usage (say compared to Dragon Warrior), it would have to be moved to PCE CD project. For CD projects I can remove bank $FF and use self modifying ST0/ST1/ST2 opcodes to access the VDC ports. That would remove the problem of trying to relocate any of the game's SRAM write/read code to PCE's work ram.
Hmm. There is another option if you/we/anyone were to keep Kid Icarus, Metroid, Zelda, Zelda 2, and other SRAM games as a hucard projects. Populous ROM for PCE has an extra 32k of ram. It would the same method as above (self modifying 'stow to vram' opcodes).
I've already moved Castlevania to a PCE CD project (it plays CD tracks in place of songs currently).