For the NES it's impossible or close to impossible. The Super Gameboy may be possible... but you would have to take a look, if the FPGA resources are enough for a Gameboy. The Super Gameboy doesn't just contain the Super Gameboy ROM, but a complete(!) Gameboy as well (well... without an LCD and without buttons
). Still someone has to write the Gameboy in HDL.
The second challenge would be the video transfer. Since the system is 'emulated' inside the cart audio and video somehow need to get to the multi-out
. Audio isn't a problem at all since you can send it analogue via the cart slot. Video is a big problem, cause you need to send it digitally. Gameboy seems to be simple: the picture is relatively small and only has 4 colors.
Gameboy resolution: 160x144 pixel
color depth: 2 bits per pixel (4 grayscales)
amount of data per frame: (160*144)*(2/8) = 5760 Bytes
The SNES is able to stream around 6 kB data per DMA inside the vblank into the VRAM - so it's a tight fit.
But with the NES you'll reach the limits. While using some rasterisation tricks the picture can contain 64 colors simultaneously... and even more while using emphasis bits. Resolution is higher as well. Since you can only have 4, 16 or 256 colors on the SNES you'll have to use the 256 color mode.
NES resolution: 256x240 pixel
color depth: 8 bits per pixel
amount of data per frame: (256*240)*(8/8) = 61440 Bytes
As you can see: you would need 10 frames to send one NES frame - which doesn't make sense
.
Without any conservative transmission techniques (prerendered frames, pixel by pixel) and with some smart HDMA tables you may be able to outsource some of the rendering work to the SNES PPU and only have to stream tile and palette data. Maybe a compromise between the CPU via S-CPU inside the SNES and PPU emulation via SD2SNES would be possible. But that's some kind of complexity i wouldn't wanna think about right now.