New Gba Emu In Progress
- Thread starter weirdocollector
- Start date
xinfernoofdantex
Member
- Joined
- Feb 18, 2006
- Messages
- 404
check the dev forum or his site, i'm too lazy to link you
Beefy is the last word I would use for the GBA's processor. Crippled is a better term. Big N did just about everything possible to slow this thing down. Realisticaly, instead of the prescribed 90-95% mips to megahertz you should get out of an ARM, the GBA is going to get about 2-3 mips. So far I have the gp2x at 177mips at 200mhz, about 60 times faster than the GBA. There shouldnt be a problem executing the GBA _code_ at full speed.
You are right on the money though, its the video hardware that is the issue. Its the only thing that saved the GBA in the first place (with its crippled processor). It shouldnt be too hard to take an emulator (with source), modify it to find out how many layers are being used, etc. Find a game that takes full advantage of the video hardware, lost of layers and transparency, extract the tile and other screen information for a single frame or handful of frames. Have the gp2x emulate the rendering of that one frame over and over again. If it cant do it as fast as the gba, then we have a shot at emulating at full speed, if not then we cant emulate at full speed with this approach. That doesnt make the project a bust, just means that someone has to work on the video side. It sounds like a fun project actually...
I say crippled because no cache, no write buffer, mostly 16bit busses with wait states. It wasnt the ARM that crippled it but what big N put around it. In fact the ARM helped save them with thumb mode, even though it takes more instructions to do the same task it can execute on every (set of) memory cycle(s) insted of every other. If they had spent only a few cents more per unit (at a cost of a few dollars more per unit to us) that platform could have been much faster. Of course then there may not have been much interest in the gp32 and then the gp2x if the GBA had any decent performance. To put this into perspective. The 16.75mhz gba running in thumb mode, no cache, no write buffer, around 3mips with a typical gcc 3.x build. The 200mhz gp2x running in arm mode, no cache, no write buffer, around 3 mips with a gcc 4.x build. From that perspective, yes, the GBA has a beefy "processor" compared to the gp2x if it can match performace with 1/12th the mhz.
Whoever is working on this project, I highly recommend you start with a mode 7 game. After weeks or months of work on a tile based game you may be so dissapointed in the performance that you just give up.
Dont get me wrong, I am eager to see this emulation/translation work. Sounds like a lot of fun, if someone had not already started I would want to start a project like this...Going from ARM to ARM opens new possibilities that you dont get when going from dissimilar platforms.
Epicenter
Well-Known Member
You must keep in mind that while typical bizarro-Nintendo design (they've done this forever; e.g. the pitifully slow CPU in the NES when much faster alternatives existed, or the SNES' godawful 16-bit hack of the 8-bit 6520, on an 8-bit bus) kept the ARM7TDMI in the machine from performing optimally as it sat idle for much too many cycles, compared to the pitiful 8 MHz Z80 that came before it in the Game Boy Color and the 4 MHz one that powered classic GB games, which formed the vast majority of the GB/GBC game library-- it is a MASSIVE performance increase. The power draw of the unit was also EXTREMELY low due to this processor selection; I've left my GBA running a Sonic Advance 2 cart in Demo Play mode overnight and over 12 hours later it was still going. I was trying to use it to kill my AAs so I could recharge them and they were still going strong. The low-battery indicator was not even on.
So true, while Beefy isn't what you'd call the GBA's ARM7TDMI @ 16 MHz compared to the 2x's ARM920T at *200* MHz with more cache and a less limited bus, for 2001 this was an impressive, impressive unit and its 2D subsystem certainly helped supplement it. If you've played games that pushed the hardware to its limits like say, Gunstar Super Heroes (try the 'Seven Force' battle in the mine, you will be in awe the GBA can handle this) you'll agree the machine has a whole lot of kick to it.
As for suggesting a 'Mode 7' game be tested before a tile-based one? I don't see your logic there, as the simpler functionality of the graphics subsystem and just game logic and tile placement functionality on the CPU being the most heavily utilized functions there, you'd likely see the best performance. If something DIDN'T run at full speed in such an emulator it'd be scaling/rotation/Mode7 heavy titles that actually required imitation of weird proprietary Nintendo graphics hardware-- like how things go with the SNES. Odds are this could run at full speed too though, if written in full ARM9 ASM and not C.
So true, while Beefy isn't what you'd call the GBA's ARM7TDMI @ 16 MHz compared to the 2x's ARM920T at *200* MHz with more cache and a less limited bus, for 2001 this was an impressive, impressive unit and its 2D subsystem certainly helped supplement it. If you've played games that pushed the hardware to its limits like say, Gunstar Super Heroes (try the 'Seven Force' battle in the mine, you will be in awe the GBA can handle this) you'll agree the machine has a whole lot of kick to it.
As for suggesting a 'Mode 7' game be tested before a tile-based one? I don't see your logic there, as the simpler functionality of the graphics subsystem and just game logic and tile placement functionality on the CPU being the most heavily utilized functions there, you'd likely see the best performance. If something DIDN'T run at full speed in such an emulator it'd be scaling/rotation/Mode7 heavy titles that actually required imitation of weird proprietary Nintendo graphics hardware-- like how things go with the SNES. Odds are this could run at full speed too though, if written in full ARM9 ASM and not C.
So the 2nd CPU twiddles its (har har) thumbs and the extra graphics/hw acceleration of the GP2X goes unused too eh?
I guess the overclocking and MMC cache tricks won't help either.
Let alone the fact that the GBA tile-mode graphics are probably very easily decompressed into a pre-made buffer for taking advantage of fast copies to the frame-buffer, as well.
Sad, I think _only_ a pathetic 3x to 4x times speed Vs. the regular GBA is possible. Oh well, its not very playable at those speeds anyhow. Mostly due to Big-N's always funky PPC abilities.
But boy will this "emulator" need good patching support of code, and excellent BIOS clone routines and jump-tables up the wazhoo.
Also I've heard the Z80 is ACTIVE during GBA use. (For music or sound effects or something)
I guess the overclocking and MMC cache tricks won't help either.
Let alone the fact that the GBA tile-mode graphics are probably very easily decompressed into a pre-made buffer for taking advantage of fast copies to the frame-buffer, as well.
Sad, I think _only_ a pathetic 3x to 4x times speed Vs. the regular GBA is possible. Oh well, its not very playable at those speeds anyhow. Mostly due to Big-N's always funky PPC abilities.
But boy will this "emulator" need good patching support of code, and excellent BIOS clone routines and jump-tables up the wazhoo.
Also I've heard the Z80 is ACTIVE during GBA use. (For music or sound effects or something)
Epicenter
Well-Known Member
There is the possibility of offloading some graphics handling functionality or other emulation tasks to the ARM940T, and the blitter would be used to accelerate drawing of the tiles to the GP2X display, I am certain. The MMU hack *would* be beneficial (MMC? MultiMedia card, forerunner to SD?) as it would accelerate access to the framebuffer and actual GBA ROM data that may be stored at least partially in the upper 32MB of RAM due to the large size of some GBA ROM files (16MB+).. ordinarily the 920T can't cache data from this upper 32MB so access to it is VERY slow, and now, with the hack, this area IS cacheable and much faster-- probably as fast as the ARM920T's native RAM area.
3 to 4 times original GBA speed would be 'lowly'? I wouldn't say so. The task of imitating the GBA's video subsystem accurately is a hefty one, so if enough headroom is left for the ARM7 code to run at 3-4x native speed, that's pretty good.
As for the GBA's Z80 being used for music/sound, I don't believe I'm wrong when I say that unit is disengaged when the GBA is in operation. After all, I believe the Z80 clone is actually just integrated into a System on a Chip that is essentially a self-contained Game Boy Color. Sound code should all be being handled on the ARM7.
3 to 4 times original GBA speed would be 'lowly'? I wouldn't say so. The task of imitating the GBA's video subsystem accurately is a hefty one, so if enough headroom is left for the ARM7 code to run at 3-4x native speed, that's pretty good.
As for the GBA's Z80 being used for music/sound, I don't believe I'm wrong when I say that unit is disengaged when the GBA is in operation. After all, I believe the Z80 clone is actually just integrated into a System on a Chip that is essentially a self-contained Game Boy Color. Sound code should all be being handled on the ARM7.
Yes, I still think the 940T can be used to do the video emulation with the 920 doing the code emulation, or the other way around, however. I think splitting the task will make it faster and/or easier I am this " close to having answer to those questions. I have the 940 licked, that was easy. I need to understand more about uboot, sdk2x (and trampoline). Basically find a way to completely take over the 920 from linux and run some tests, find some ways to demonstrate that the two processors can run faster than one. Right now I am worried about bricking the thing and having to buy a jtag wiggler and wire it up and whine and whine.
It sounds like the last successful 920/940 tests showed that there was no speed improvement by using the 940. Quite frankly I dont believe it. I believe there are many ways to have the two compete for the bus and end up slower than just one processor, but the fact that they both have caches, the chip is designed to have up to four simultaneous bus masters competing for i/o, there has to be a way to have one or both live inside their caches or perhaps they have to be in separate memory banks, who knows, caches alone will allow two to run faster than one. On the other hand if you turn off the cache and write buffer, the 200mhz machine goes down to 3mips, no faster than a 16.75mhz gba. That is some really really slow memory.
Yes, every indication I have is that the other core in the GBA is not available when in gba mode. The arm doesnt have a cache, I doubt the z80 has a cache, the two would probably compete for resources and two would be slower than one.
I see a blurb her that says GBC compatible sound, perhaps that was the confusion, its not gbc does sound but gbc compatible sound, perhaps the two cores share the same peripheral...
It sounds like the last successful 920/940 tests showed that there was no speed improvement by using the 940. Quite frankly I dont believe it. I believe there are many ways to have the two compete for the bus and end up slower than just one processor, but the fact that they both have caches, the chip is designed to have up to four simultaneous bus masters competing for i/o, there has to be a way to have one or both live inside their caches or perhaps they have to be in separate memory banks, who knows, caches alone will allow two to run faster than one. On the other hand if you turn off the cache and write buffer, the 200mhz machine goes down to 3mips, no faster than a 16.75mhz gba. That is some really really slow memory.
Yes, every indication I have is that the other core in the GBA is not available when in gba mode. The arm doesnt have a cache, I doubt the z80 has a cache, the two would probably compete for resources and two would be slower than one.
I see a blurb her that says GBC compatible sound, perhaps that was the confusion, its not gbc does sound but gbc compatible sound, perhaps the two cores share the same peripheral...
Unless the docs I've been reading are wrong, the Z80 is not active while the ARM is running, so no competing for resources there.
.... I hope.
I've been thinking about that, haven't actually made any tests yet, but from what I've seen the coprocessor won't be much use for video emulation (too much data to analyze on a small cache, would result on more RAM access and a lot of cache misses, slowing down the main CPU). Alternatively, the main CPU could do the video (larger cache, less misses) and the GBA code could be thrown to the coproc. It's not used to having a large cache anyway, so that wouldn't be much of a hit. Since it's a RISC processor, most of the work won't involve RAM, and with static / dynamic compilation even less RAM is needed at run-time. Problem is, I don't know how the memory bandwidth would react to this, but the idea of not having to pause the GBA's CPU emulation to do hardware sounds nice. For now I'm not too worried about it, I have enough work on my hands and this is an optimization that can come later, without too much trouble....
.... I hope.
sam fisher
Well-Known Member
I don't know much about emulation but Have suggested this before, along with a few others. Noone has really even though about it except you. Hopefully if optimisation is required, this could give it a boost. And be the first GP2x application to effectively use the second processor. Or maybe the second, Vektar uses it for sound.TKF15H posted on Jul 30 2006 at 04:13 AM said:Unless the docs I've been reading are wrong, the Z80 is not active while the ARM is running, so no competing for resources there.
I've been thinking about that, haven't actually made any tests yet, but from what I've seen the coprocessor won't be much use for video emulation (too much data to analyze on a small cache, would result on more RAM access and a lot of cache misses, slowing down the main CPU). Alternatively, the main CPU could do the video (larger cache, less misses) and the GBA code could be thrown to the coproc. It's not used to having a large cache anyway, so that wouldn't be much of a hit. Since it's a RISC processor, most of the work won't involve RAM, and with static / dynamic compilation even less RAM is needed at run-time. Problem is, I don't know how the memory bandwidth would react to this, but the idea of not having to pause the GBA's CPU emulation to do hardware sounds nice. For now I'm not too worried about it, I have enough work on my hands and this is an optimization that can come later, without too much trouble....
.... I hope.
Last edited by a moderator:
Epicenter
Well-Known Member
dwelch posted on Jul 29 2006 at 09:59 PM said:
Pretty much any processor is insufferably slow with its cache disabled. For example, my K6-2-500 MHz machine used to take about 20 seconds to boot from hitting the button to getting to the Win2000 desktop. I turned off the *L2* cache because it was damaged in a power surge and made the system unstable. It ran about the speed of a 12 Mhz 286, and took over 8 minutes to boot. And it didn't have very slow RAM, it had the fastest available at the time.
It is true the Z80 definitely has no cache. It's a pretty primitive processor, compared to some of the earlier processors with cache that came a lot later, like the Motorola MC68010. While I am unsure if the ARM7TDMI in the GBA had cache, a quick glance at ARM reference materials indicates the ARM7TDMI can utilize it.
The GBA definitely doesn't do sound processing through the Z80, though from what I'm told by a knowledgeable friend of mine (he does a good bit of console development) the Z80 has no involvement and is disengaged during GBA operation. Though, most GBA games use more pre-recorded PCM than the waves that SoC can generate.
Last edited by a moderator:
nubie
Recovering Jerk-A-Holic
No, I was actively involved in spreading this news about 8 months ago.Paradox posted on Jul 29 2006 at 05:08 AM said:
Yes, unless someone did what they are doing now.Magnulus posted on Jul 29 2006 at 05:15 AM said:
Last edited by a moderator:
Epicenter
Well-Known Member
Exactly, it's pretty much been the concensus that GBA emulation would be achieved at full speed only if the ARM7 code was run natively on one of the ARM9 cores. Otherwise there's just too much to manage to be able to realistically expect >20-30 FPS performance, and that's being optimistic.
Paradox
oh em gee
so what, can we expect fullspeed then or what (w/sound)? you said yes then no in you post?
Epicenter
Well-Known Member
Paradox posted on Jul 30 2006 at 03:41 AM said:
I don't think I contradicted myself, unless I made a typo somewhere. What I meant was, there's no reason full-speed operation couldn't be achieved with the method in use; that is, translating ARM7 instructions to ARM9-compatible ones. I did say, though, that without this method it would NOT be feasible. Sound shouldn't be much of an issue since most sound processing is done on the ARM7 CPU anyway, so those are instructions the ARM920T can process at low cycle cost. Video emulation should be the toughest thing, and it's not THAT bad with native execution of about everything else.
Last edited by a moderator:
AcidiC
Member
This thread makes me happy
dennis20014
Member
Sweet Nector!
@TKF15H: hehe I just derived the Team Kill from your nick... TKF15H seems quite obvious. Well yeah, I know that it involves a heavy amount of work to get an emulator running. Hell, I can only output Hello World in cpp, and I have no skills when it comes to ASM. I did a little reverse engineering on those reverse mes that some pages offer but in now way skillful. Just wondered if you were already coding for longer. Sweet. I hope you are getting nice results. Best luck and thank you for the effort.