gbadev.org forum archive

This is a read-only mirror of the content originally found on forum.gbadev.org (now offline), salvaged from Wayback machine copies. A new forum can be found here.

Hardware > How does a GBA acheive backward compat with the old GB?

#4885 - Weevil - Mon Apr 14, 2003 4:24 am

Hi,

I'm just generally interested here. I'm working on developing some code for the GBA and i got sidetracked into wondering how on earth it pretends to be an original Gameboy for backward compatibility with old gameboy/gameboy color games.

My research goes as far as "there's a little switch in the cart slot that old GB cartridges activate" this switch apparently sets the voltage used to drive the cart to 5v instead of 3v. I'm not bothered about that, i'm more interested in how the ARM7tdmi processor inside the GBA emulates the old Z80-style processor that was in the original GB, or if it even tries to.

I imagine the old processor that Nintendo developed for the GB (i think they developed it anyway) must be worth practically nothing these days and it wouldn't be too expensive to just include it in the GBA along with the new ARM cpu, but that seems like an incredible kludge to me and i'd have thought nintendo would have come up with a more elegant solution. If the GBA does contain TWO cpus that would interest me, especially if there was some way to hack them so they work in tandem (which i seriously doubt).

Anyone got any detailed info or links on how the GBA backward compatibility works?

Thanks in advance,
Weevil

#4887 - Weevil - Mon Apr 14, 2003 4:59 am

Well after a little more digging i've found evidence that suggests the GBA does indeed contain either some sort of hybrid all-in-one CPU (that can switch modes between being an ARM7tdmi or a Z80/8080-clone as used in the CGB/DMG) or both an ARM cpu and a CGB/DMG cpu as seperate entities. The latter is probably more likely and cheaper for Nintendo since they wouldn't need to produce some sort of special hybrid cpu.

The document at http://www.work.de/nocash/gbatek.htm says you can only use one CPU mode at a time. This is a shame because if there really are two chips on the board, the GBA could have been designed to use the Z80/8080 CPU as an 8mhz co-processor when in ARM mode.

What i'm really looking for here is some deep info on how backward compat is implemented in the GBA. Ultimately i'd like a detailed block diagram of the chipset but that's very unlikely to appear. What this is all in aid of is finding some way of switching CPU modes in runtime through extreme cleverness and bad practices in order to acheive some sort of dual-processor operation. If the CGB/DMG cpu is actually a seperate chip on the board that is clocked while the ARM chip is active this might be possible. And damn it i'm stupid enough to try.

Weevil

#4888 - Daikath - Mon Apr 14, 2003 5:03 am

Weevil wrote:
If the CGB/DMG cpu is actually a seperate chip on the board that is clocked while the ARM chip is active this might be possible. And damn it i'm stupid enough to try.


You sure you want to do that Hannibal?

Dont worry BA

I just love it when a plan comes together.
_________________
?There are no stupid questions but there are a LOT of inquisitive idiots.?

#4895 - tepples - Mon Apr 14, 2003 6:44 am

Weevil wrote:
The document at http://www.work.de/nocash/gbatek.htm says you can only use one CPU mode at a time. This is a shame because if there really are two chips on the board, the GBA could have been designed to use the Z80/8080 CPU as an 8mhz co-processor when in ARM mode.

And then possibly suffer from the same sorts of synchronization and core-to-core bandwidth issues that hindered software development on and accurate emulation of the Super NES and Sega Genesis systems. How would you have designed communication between the cores? And what sorts of tasks would you have the Sharp80 core actually do in practice?

Quote:
If the CGB/DMG cpu is actually a seperate chip on the board that is clocked while the ARM chip is active this might be possible.

I'm pretty sure it's not clocked. There are two cores (ARM7TDMI and Sharp80) on one die. Not clocking the core that's not active would save a load of current.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

#4905 - Weevil - Mon Apr 14, 2003 5:03 pm

Quote:
How would you have designed communication between the cores?


One assumes both cores share the same memory chips and bus lines, but the CBG/DMG would obviously only use a small portion of the address bus. It might be possible to share memory between cores. I don't know how. But then, since you're right about current and clocks it's unlikely that the CGB/DMG core is clocked while the ARM core is clocked.

Quote:
And what sorts of tasks would you have the Sharp80 core actually do in practice

Anything like intensive math work such as building sine tables, sorting data, etc.

Quote:
There are two cores (ARM7TDMI and Sharp80) on one die. Not clocking the core that's not active would save a load of current.


If they're on the same die though, it's possible they might both be clocked together with a clock divider to cut the 16mhz clock for the ARM down to 8mhz for the CGB. That would simplify the design of the chip though admitedly it takes only one transistor to cut off the clock to the CGB.

Maybe i should just forget this crazy idea.

#5439 - Rattus - Sun Apr 27, 2003 8:03 pm

AFAIK, the processor to use it determined by the size of the cartridge you slot into the GBA- the original GB carts are bigger and depress some kind of hardware switch to activate the old processor... I don't know if it's even possible to switch between processors without causing a hardware reset, but if it was, and retain something in memory, I wonder what you could do with using the cart_inserted bios function to remove your GBA cart, and resume execution of some kind when you insert a GB cart?