Metroid Other M Remake (April Fool's)

DoctorM64 is making an NES remake of Metroid Other M! Pretty sweet!

http://metroidmremake.blogspot.ca/2013/03/just-one-cart.html

Are the physics going to be right? That's always the issue with these remakes, jumping physics not being just right. I've never heard of M so I don't know what it's like.

EDIT: Oh, it's a 3D game.

Are you sure this is serious? I mean, "small 4 minute boot-up decrunching sequence"? VHS with cutscenes you can play when prompted to? Oh, April fools... I miss the days when that didn't affect NESDEV.

Am I the only one that noticed that those are levels from Batman with different palettes?

Yeah, when I read that in the article, I knew it can't be real.
But...may I ask something?
He says:

Is that even possible? I have no technical knowledge, but I think that when you pull the cartridge out of NES, then whole RAM gets messed up or (and) CPU gets confused since there's no more code to execute.
At the other hand, maybe you can use SRAM routine to "wait until next cartridge is popped in"?

Cartridge swapping is actually possible on the Famicom, or NES with the lockout disabled. Just turn off NMI/interrupts, place a loop of code in RAM, and jump to it. At this point it's generally doable to swap carts, after which you could jump out of your loop back into the cartridge code.

It's not totally reliable (I get crashes sometimes while attempting it), but it does work more often than not for me. I've been using it to execute audio code on expansion audio carts without having to replace the mask ROMs.

Just inserting a cart into my NES and powering on isn't a 100% reliable operation, so swapping is extra iffy. I dunno if there's a good way to prevent a crash on a bad connection after the swap. Maybe if you did a checksum of some sort before jumping out of the RAM loop?

Also I have no idea if doing this could potentially damage my cartridges and/or NES.

Cartridge swapping, especially on the front-loading NES, is hindered by the ease with which adjacent pins can be momentarily shorted. This can interfere with executing code from internal RAM, which is why (I am told) TapeDump uses OAM DMA in a tight wait loop to minimize the amount of time the data bus contents need to be valid.

Yep, in fact this applies to pretty much any device that is has current going through - there's a state where it's in transition where both ends can potentially end up damaged. Likelihood of damage actually happening is pretty low, but yes, there's a risk.

I do hotswapping on my NES often. OAM DMA is very useful to minimize crashes. Also useful to have the code keep re-initiating a short sound so that if it hangs, the sound will stop and you'll know immediately that it crashed (and might be able to notice what you did that caused it so you can try swapping differently next time). After the repeated OAM DMA code ends (say 8 seconds of it), it's simplest to jump into a bootloader in RAM so you can send test code over the controller port (which of course runs a bootloader once it's done its thing, so it's ready for the next "command" program).