Help Understanding CPU Memory

[YoshiMoshi]

I'm trying to understand the GBA architecture.

CPU Architecture
First I've seen online that the CPU is a ARM7TDMI.
I've looked through the datasheet, the ARM7TDMI allows for a coprocessor.
The GBA is backwards compatible with GB and GBC games which uses a different CPU
Looking at the GBA itself, there appears to be only one CPU.
Is the GB and GBC processor in the same IC as the ARM7TDMI core for the GBA?
Has anyone taken apart the IC, and see two separate dies in one package? Or is it all one die?

CPU Memory
It looks like the GBA ROMs are temporarily stored in the CPU memory? So is a temporary copy of the ROM made in the CPU?
I don't understand why the CPU doesn't just read the address it needs from the game pak ROM?
Where the ROM is stored in the CPU memory does not align with address on the game pak ROM. Meaning Address 0 on the Game Pak ROM is not address 0 on the CPU, it stores the ROM in different address locations on the CPU. So I'm confused as to how on the hardware side of things, it calls address 0 of the game pack ROM, but then stores it in a different address location of the CPU.

Thanks for nay help.

 

[SAIYAN48]

@Jayro This might be up your alley.

 

[Jayro]

First of all, here's this:
http://marc.rawer.de/Gameboy/Docs/GBCPUman.pdf

Hope these give you some insight.

 

[FAST6191]

I'm trying to understand the GBA architecture.

CPU Architecture
First I've seen online that the CPU is a ARM7TDMI.
I've looked through the datasheet, the ARM7TDMI allows for a coprocessor.
The GBA is backwards compatible with GB and GBC games which uses a different CPU
Looking at the GBA itself, there appears to be only one CPU.
Is the GB and GBC processor in the same IC as the ARM7TDMI core for the GBA?
Has anyone taken apart the IC, and see two separate dies in one package? Or is it all one die?

CPU Memory
It looks like the GBA ROMs are temporarily stored in the CPU memory? So is a temporary copy of the ROM made in the CPU?
I don't understand why the CPU doesn't just read the address it needs from the game pak ROM?
Where the ROM is stored in the CPU memory does not align with address on the game pak ROM. Meaning Address 0 on the Game Pak ROM is not address 0 on the CPU, it stores the ROM in different address locations on the CPU. So I'm confused as to how on the hardware side of things, it calls address 0 of the game pack ROM, but then stores it in a different address location of the CPU.

Thanks for nay help.

Above appears to have handled the z80 alike GB/GBC disconnect thing (it is not available like you might have had a z80 coprocessor on a megadrive). Have not seen what goes for a decapped chip though -- I was happy enough to get sanded boards https://circuit-board.de/forum/index.php/Thread/13913-STRIP-CLUB-PCB-Scans/?pageNo=1 .

If you are thinking in the sense that on CD based things where binaries are dumped into memory, or some modern dumper-emulator things where the ROM is dumped (which troubled flash carts and https://mgba.io/2015/10/20/dumping-the-undumped/ and some other aspects of https://gbatemp.net/threads/buying-a-gba-flash-cart-in-2013.341203/page-18#post-4756995 ) into dumper-emulator RAM (which is cheap now vs back then -- the GBA has a few hundred kilobytes of memory where ROMs other than the oddness with those Shrek videos and some homebrew top out at 32 megabytes) then no. The GBA cartridges do use very fast memory which allows things to appear in the memory bus and be used at CPU instruction level compared to some more abstract things seen elsewhere.
http://problemkaputt.de/gbatek.htm#gbamemorymap
Equally most things even at GBA ROM level won't use the location within the ROM itself and instead be where it appears in the GBA memory map (that is to say between 08000000 and 09FFFFFF in most cases).
On GBA CPU memory then it does also have a small area of memory onboard the CPU beyond and registers and cache that can be used for code as well. Occasionally you will see things copied from ROM to this and used for ultra fast code. I don't know if this is what you meant by temporary storage. Similarly you might find things decompressed to RAM, and graphics tend to want things to be in VRAM to do any good so there is also that but that is fairly standard computing.

 

[YoshiMoshi]

Hey thanks for the replies.

I found an interesting video online, where they a decapsulated AGB-CPU

This is interesting and I've realized a few things. I want to make sure I'm understanding the architecture correctly. So the CPU IC itself is not simply a ARM7TDMI chip. It looks like a custom system on chip design. Where Nintendo took a ARM7TDI core and hooked it up to different storage units, a peripheral circuit, and a prefetch buffer. This whole assembly was put into a custom system on chip?

Is there any documentation on who made the VRAM, WRAM or ROM modules on the CPU? As far as I know Nintendo doesn't actually create an manufacture there own ICs.

As the datasheet for the AGB-CPU ever been "leaked" or made available?

I was thinking I could just look at the datasheet for ARM7TDMI and that it was equivalent to the AGB CPU. But this doesn't appear to be the case at all. It's a custom made IC?

Do I have the correct understanding?

 

[Jayro]

Hey thanks for the replies.

I found an interesting video online, where they a decapsulated AGB-CPU

View attachment 289579
This is interesting and I've realized a few things. I want to make sure I'm understanding the architecture correctly. So the CPU IC itself is not simply a ARM7TDMI chip. It looks like a custom system on chip design. Where Nintendo took a ARM7TDI core and hooked it up to different storage units, a peripheral circuit, and a prefetch buffer. This whole assembly was put into a custom system on chip?

Is there any documentation on who made the VRAM, WRAM or ROM modules on the CPU? As far as I know Nintendo doesn't actually create an manufacture there own ICs.

As the datasheet for the AGB-CPU ever been "leaked" or made available?

I was thinking I could just look at the datasheet for ARM7TDMI and that it was equivalent to the AGB CPU. But this doesn't appear to be the case at all. It's a custom made IC?

Do I have the correct understanding?

From what I have gathered, it is indeed a custom made chip made by Sharp. You might be able to find the CPU datasheets within the gigaleak files, but of course I can't link you to those, nor am I positive that they are even in there. It's just a place you *could* look.

 

[FAST6191]

Nice. Always like decap stuff.

ARM don't sell their own chips anyway, certainly did not back then as them being fabless was quite a noted thing, and it was mostly designs sold so having an integrator put one on a die is nothing remarkable in the slightest compared to Intel doing it or something.

As far as datasheets then most don't care about the things you are contemplating -- instruction list, register descriptions, timings of all things, DMA functionality, extra memory and peripherals and that does for most homebrew, debugging and emulator purposes. That sort of thing was on the stock ARM7TDMI datasheets that arm provides, to a lesser extent the leaked SDK (happened before launch so emulation was available in half decent fashion actually before it hit the US), gbatek linked earlier, http://members.iinet.net.au/~freeaxs/gbacomp/#BIOS Decompression Functions http://belogic.com/gba/ https://www.cs.rit.edu/~tjh8300/CowBite/CowBiteSpec.htm plus older stuff like https://web.archive.org/web/20170630222745/http://reinerziegler.de/GBA/gba.htm http://www.devrs.com/gba/software.php and other fun things most do for what they need.