This question already has an answer here:
This is an extension to the question NES cartridge rom emulation with arduino or pi?, which asked whether it would be possible to physically emulate a NES cartridge using an Arduino/Raspberry Pi (RPi). By this I mean mapping part of the RPi's SDRAM to hold game ROM and RAM, interfacing to the Gameboy's 32 cart pins via the GPIO header, so that the Gameboy believes a normal cartridge is connected. It would also need MBC functionality to be able to emulate generic games. Unlike that previous question, I would like to know if there are any specific hardware limitations to trying this for a Gameboy (not NES) using a RPi (not a generic MCU). I'm assuming no OS is needed on the RPi, just some interfacing software which maps the memory addresses properly. There could also be some Gameboy software that is initially loaded to the Gameboy which allows you to select from a choice of stored game roms.
There is an excellent set of blog posts here: https://dhole.github.io/post/gameboy_cartridge_emu_1/ in which someone has done exactly this idea but using the STM32F4 MCU rather than an RPi. Assuming no OS overhead on the RPi, is there any reason why such a setup wouldn't work using an RPi instead? Naively my thinking is that even the RPi Model 1 B is clocked at 700 MHz (with the 3B at 1.2GHz), whereas the STM32F4 is 168 MHz, so just based on CPU cycle speed there shouldn't be an issue. My understanding of how that matches up with bus speeds etc. is limited though.
The motivation for doing such a thing, apart from the fun of trying, is that you could store multiple game roms, and perhaps design some Gameboy software that lets you choose a selection. As Gameboy games take ~64--1000 KB space, even the RPi Model 1B with 512 MB memory could hold a large number of games.