Feedback What are the barriers to producing a GB/C Hypervisor on GBA?

[inversalAutoDoc]

Well, the thread title asks the question, but I figure I'd explain why I think it could be possible before someone who knows what they're talking about comes in and sets me straight.

Basically, the GBA already has the hardware in it to function as a GB/C, right? It doesn't run gameboy games by emulation. I use both Nintendon't and GBARunner2 on the Wii and NDS/3DS (respectively) to run Gamecube and GBA games (also respectively) using the hardware that's already there.

We also know that some parts of the GB hardware are directly accessible from within GBA games - most notably, imo, is the hardware synth used to produce the gameboy's characteristic sound. GBA games can leverage those sound channels as well. (AFAIK these parts had to be carried along with the rest of the GBA hardware even when they dropped GB support because some games made use of it)

So, what is preventing a program from booting in GBA mode, then acting as a bootstrap for a game in GB/C mode? Is it something in the firmware that can't easily/realistically be circumvented? Or is the problem simply much more complex than I understand? [Actually, if we want to talk hypotheticals, wouldn't it have been neat if some GBA games had a built-in GB executable minigame in a similar manner to Luigi Bros. in NSLU?]

(Also I realize that I may have given this a misnomer, as instead of running in a limited mode on the GBA's main processor it would be outsourced to the dedicated hardware for GB/C games inside the console, but like, unless that's the direct source of my misunderstanding here I think it gets the point across well enough)

 

[Kwyjor]

So, what is preventing a program from booting in GBA mode, then acting as a bootstrap for a game in GB/C mode?

I think I dimly recall that someone might have managed to do something vaguely like that already? Needless to say, it was a rather useless little trick with no practical application.

Also I realize that I may have given this a misnomer

Indeed, "hypervisor" is usually used around here to refer to things like GC games on Wii or GBARunner2, wherein the code is running natively on the CPU.

 

[Vague Rant]

My understanding is that the legacy Game Boy CPU is not accessible in GBA mode, so you can't run Game Boy code natively while the system is in GBA mode. Only one of the CPUs is in control of the hardware on any given boot. So that rules out running GB games on their own CPU from GBA mode.

The Game Boy "Z80"(-alike) and Game Boy Advance ARM7 CPUs are architecturally unrelated, so you also can't run them "natively" on that (like what Nintendont or GBARunner2 do via hypervisor) without resorting to emulation, as has already been done in Goomba/Goomba Color.

So as far as I know, this just isn't possible due to the hardware design of the GBA.

 

[Kwyjor]

Here we are:
https://github.com/Lorenzooone/gba-dump-gb

Routine to switch a GBA into GBC mode by software and to then dump cartridges' contents through the link cable!

Not sure if it was finished, though. It also links to https://www.dwedit.org/dwedit_board/viewtopic.php?id=339 and the more informative https://github.com/AntonioND/gba-switch-to-gbc .

 

[metroid maniac]

As others have pointed out, the GBC CPU is simply inaccessible in GBA mode.
But more generally, a hypervisor is only practical if there's a means to interrupt code running natively and emulate the differences from the host platform where a difference occurs, which depends on how the systems are designed.
GBARunner2 can run at a playable speed because DS mode is largely compatible with GBA software running natively, but the NDS's MPU can be used to intervene and emulate most aspects which differ from GBA mode. The MPU wasn't designed to do this, so it's only just viable. Ideally you'd want a platform with deliberate support for virtualization.
Even if the GBC CPU were accessible, it'd be very unlikely that the GBA would have anything like that.

 

[patters]

I seem to recall that the reasons the Gameboy micro and Nintendo DS removed Gameboy/Gameboy Color back compatibility, and that the DSi removed GBA compatibility wasn't just to irritate customers - but more like that certain components were stripped out when designing the new SoCs and PCBs to cost-reduce them. The 5V power requirement of GB/GBC carts was presumably a big reason they had to go.

 

[tbgtbg]

So, what is preventing a program from booting in GBA mode, then acting as a bootstrap for a game in GB/C mode? Is it something in the firmware that can't easily/realistically be circumvented?

There's a switch in the cart slot that tells the system whether to start as a GBA or as a GBC. The carts have slight shape differences so only the carts that need the switch pressed press it. That's why GBA flashcarts can't play GB/GBC games directly, only via emulation.

 

[DanTheManMS]

Yeah, the voltage difference is a pretty big issue, hard to bypass that. The GBC crasher program from Dwedit's forum (which Kwyjor already linked) didn't end up going anywhere useful.

As far as audio goes, Goomba and Goomba Color already do this. They don't bother emulating the audio and sound effects at all -- they pass the relevant commands straight to the GB/GBC audio hardware semi-blindly, freeing up precious clock cycles.

Actually a lot of emulators on the GBA do this. I know PocketNES does for example, since the GB/GBC hardware can reproduce almost everything the NES could generate.