2

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.

Improve this question
6
  • Since teh technology (speed/data rate about the same as for the NES, the anwers will be exactly the same. Unless you come up with a more concrete concepts than a vague 'pysicaly emulating' that is. The cited Gameboy cardridge 'emulator' is not a gereral purpose emulator of every possible cardridge but rather a quite limited one for ROM only. That's a total different (and comparable simple) task.
    – Raffzahn
    Jun 28, 2018 at 20:43
  • 1
    MCU's GPIO speed is limited (toggle speed up to 5MHz if you're lucky for single port access. Handling 72 pins is much worse) so unless using some integrated interface there is high possibility it will be too slow to emulate memory/bus/etc. That is why FPGA is better choice as there you can have much much higher speeds. If you use SRAM covering the whole memory space and use MCU to access it from PC or whatever that should work ... with combinaton of some LATCH you can even make it remapable. However I am not familiar with the platform and could be missing some cartridge relates stuff...
    – Spektre
    Jun 29, 2018 at 6:44
  • 1
    Suggest this question would probably be better suited to electronics.stackexchange.com -- the important part of the question is about electronic interfacing using modern equipment, not the retrocomputing aspects.
    – Jules
    Jun 29, 2018 at 10:18
  • @Raffzahn - disagree with the suggestion this is a duplicate. The NES cartridge interface is much wider than the Gameboy, and exceeds the number of IO pins in most microcontrollers, so that makes the job there much harder. Gameboy (32 pins) is just about doable. NES (72 pins) would be essentially impossible with the hardware discussed.
    – Jules
    Jun 29, 2018 at 10:24
  • 1
    @Jules It still features the same problem that no standard microcontroller is fast enough to deliver all possible reactions in time. This question asks (again) for a way to wide functionality, that can not be delivered by using a standard microcontroller. It would need a considerable restriction to like pure ROM emulation to make it feasible - which again hasn't happened. - Then again, I support your sugggestion of a move to electronics as well, as it's realy more about the capabilities of modern microcontrollers than about any feature of the classic system.
    – Raffzahn
    Jun 29, 2018 at 10:32

1 Answer 1

Reset to default
5

In principle, there's certainly no reason it isn't possible. The BCM2385 on the Raspberry Pi model 1 has 45 GPIO pins (you'll need 32 to interface with the Gameboy cartridge bus) that are (apparently) designed to operate at 125MHz (although the partial datasheet cautions that they may not run that fast when driving high capacitance outputs ... but you'll probably buffer the output with something like a 74HCT244 or similar which should resolve any such issues), which is slightly better than the 100MHz GPIOs on the STM32F4.

The real issue is that the Raspberry Pi (at least model 1 versions) are based on a microcontroller chip that is at least partially undocumented. You'll need to run without a traditional operating system (because the latency introduced by a traditional OS would make it impossible to meet the timing constraints you'll have), but certain parts of the system, including the boot process, rely on functions that are considered proprietary by Broadcom and have (AFAIK) never been publicly disclosed. This could cause issues during development.

You may find it easier to work with a different board, e.g. something like a CubieBoard, Orange Pi, or similar. These are similar in capability to the RPi, but typically use processors that are fully documented, which would make development a bit easier.

An FPGA would make the process much easier, though, as they're able to handle timing constraints like this much more easily than microcontrollers. FPGA boards with multiple megabytes of SDRAM can be acquired for $20 or less, and can also be easily interfaced with devices like MMC/SD cards or even hard disks very easily.

Improve this answer
1
  • Isn't that, in a nutshell, about the same that has been said for the NES question?
    – Raffzahn
    Jun 29, 2018 at 10:33