Under The Hood: 200mhz... 385mhz... ;)

[Prophet]

IGNORE THIS POST, I was looking at the wrong datasheets. Sorry.


*NOTE* I accidentally posted this in News Zone first, so mods please ignore that post and delete it. I meant to post it here in General.

I looked up the two chips mentioned on GPX2.com:

Dual CPU Cores
ARM920T : Host processor
ARM940T : Video Coprocessor

Apologies if this is old info here, but see this PDF from ARM:

http://www.arm.com/miscPDFs/4491.pdf

Both chips are fully functional CPU's. the 940T is not merely a "video coprocessor" (like the ATI W4200 chip in the Zodiac was) - it's a bonifide multipurpose CPU clocked at 185Mhz. In fact, according to ARM the 920T is the one best suited for video decoding applications. But the point is - these are both full fledged CPU's - not merely a CPU and a 2D acceleration chip, as people have been thinking. We've got both a 200Mhz 920T and a 185Mhz 940T working together.

So the GPX2 is not merely a 200Mhz handheld with a graphics chip tacked on folks. That's the key point here. And a very important point it is.

Nor would it be proper to combine clockspeeds and call it a 385Mhz device.

But there's definitely more under the hood than the whole 200Mhz thing has been leading people to believe. This is definitely NOT merely a GP32 with an extra 33Mhz as I've seen some people suggest. Not at all.

Wait and see. We may be in for some pleasant surprises once devs get a handle on how to optimize code to make full use of both CPU's concurrently. Similar to the PSP in that regard.

 

[carlgeorge]

I agree that the GPx2 will be more powerful than a 200MHz GP32. However a dual processor system is not very well suited to emulation -- I remember Connectix saying this about running Virtual PC on the dual processor macs.
Now I'll just wait for someone to flame you for 'another' GPx2 post

 

[Prophet]

This is not a Mac, and we aren't looking to emulate an x86 PC (which is a daunting task in itself). Apples and oranges. I know of a prominent MAMEdev who once declared that MAME could never work on low powered handhelds like GP32. I think we all know otherwise, eh? <_< Take declarations of what's possible with a big grain of salt.

Proof:

If anyone wants to know what can be done with a dual CPU handheld to speed up emulation, ask YoyoFr - he's been doing exactly that on PSP for SNES. The result - great speed WITH full sound and transparencies. I've used it and know what a difference it made using the 2nd CPU to handle some graphic and sound aspects of the emulator.

 

[dr.no]

If anyone wants to know what can be done with a dual CPU handheld to speed up emulation, ask YoyoFr - he's been doing exactly that on PSP for SNES. The result - great speed WITH full sound and transparencies. I've used it and know what a difference it made using the 2nd CPU to handle some graphic and sound aspects of the emulator.

​

I don't know a lot about the PSP, but the stable speed may also result from the PSP's processors being strong enough anyways (220MHz is enough to emulate SNES - my GP32 emulates SNES just fine at 232MHz). A single strong processor would have had the same effect, I guess.

The problem I see in a dual CPU system is that it is harder to code for them in assembler. Of course there are still people like YoyoFr who have no problems with that, but the average guy who just tries to port over some SDL game might run into problems when finding out that his game runs too slow.

But all this is just estimations, we will see what will actually happen when it comes out. Hopefully the machine itself will attract even more developers this time.


PS: While I'm at it - check out the marketplace for my 232MHz GP32, because I am selling it and need cash bad. :/

 

[Prophet]

I don't know a lot about the PSP, but the stable speed may also result from the PSP's processors being strong enough anyways (220MHz is enough to emulate SNES - my GP32 emulates SNES just fine at 232MHz). A single strong processor would have had the same effect, I guess.

I can tell you don't know a lot about the PSP... I do know about the PSP, I own two and have been following emulation on PSP very closely. Prior to YoyoFr's SNES9x port, you had to turn transparencies off and lower sound quality to get good speeds. YoyoFr used the 2nd CPU to offload some of the sound and graphic processing, and the transparency/sound bottleneck was gone

That is what a 2nd CPU can do for you.

And there is no issue with using an ASM core - the core would run on one CPU, and the 2nd CPU would handle AV tasks.

And BTW - the PSP SNES emus don't (yet) use an ASM CPU core for SNES. PSP has MIPs CPU's, not ARM. And 222Mhz mode is too slow - you have to use 333Mhz for really good speeds. Then again, as I said, there are no ASM cores for MIPs yet. We already have plenty for ARM however. And GPX2 is ARM.

The problem I see in a dual CPU system is that it is harder to code for them in assembler. Of course there are still people like YoyoFr who have no problems with that, but the average guy who just tries to port over some SDL game might run into problems when finding out that his game runs too slow.

But you wouldn't be using the 2 CPU's together for emulated CPU cores. One CPU would run the core, the other would handle AV tasks, typically. So there is no issue of prgramming a CPU core that utilizes dual processors. I think this is what Connectix was talking about, and is what people are getting confused by. We're not looking to emulate a complex x86 CPU over two parallel processors. We're looking to run relatively simple CPU cores (65816, 68000, 6502, Z80 etc.) on one CPU, and offload time intensive video and audio processing to the 2nd CPU. It's a master/slave setup, not a parallel processing setup. With many emus rendering graphics is a major bottleneck (i.e. transparencies in SNES slows things down a LOT) so being able to offload such processes to a co-processor would mean a great deal.

As for average guys porting apps - this will be an open source scene - so any average guy could simply see how things are done and implement those techniques. Just like the GP32 scene.

THE POINT IS THIS: people shouldn't think of the GPX2 as a "200Mhz handheld." This is a case of Mhz not telling the full story. GPX2 seems to be potentially more powerful for emulation than some here have initially thought. I'm just trying to shed some light on that from a technical point-of-view.

PS - check the PDF I linked. It's pretty interesting.

 

[Vimacs]

so, whats new? thats all been assumed for a long time, useless topic.

 

[Prophet]

The topic was made to clarify things to those people complaining about "only 200Mhz."

As for useless - a lot of your posts are pretty useless Vimacs.

 

[carlgeorge]

This is not a Mac, and we aren't looking to emulate an x86 PC

I am fully aware that the gpx2 is not a mac, and I also know that we are not looking at emulating the x86 platform, however it is still true that dual processors can not be fully utilised when emulating systems with one major processor (like a pc).

Phophet, calm down.

 

[Prophet]

Read my 3rd post carefully - I explain how the dual CPU's can be used to great benefit for our purposes.

And how exactly am I not calm? I assure you I'm sitting in a nice office chair and drinking coffee, and aside from the caffeine rush I'm quite relaxed...

 

[Squidge]

Someone's been reading the wrong datasheet The datasheet for the processor in the GPX2 says the following:

Dual 32bit CPU 400+ (Main Processor, Coprocessor) Embedded Architecture
- Main Processor used for Operating System & System Control, Audio Processing: ARM 920T CPU (200MHz, >220MIPS), 16KB I-Cache + 16KB D-Cache + MMU
- Coprocessor used for Video Header Parsing, Video Post Processor Control: ARM 940T CPU (200MHz, >220MIPS), 4KB I-Cache + 4KB D-Cache

So the second processor is pretty much dedicated to video processing duties. Whether we will be able to override this in the future remains to be seen, but since both GPH and the manufacturer of the above IC refuse to release detailed information, it's not going to be done near release time (all they say is "we will release sdk").

 

[efegea]

http://www.mesdigital.com/english/Products/product_mmsp2.asp

That's the SoC (system on a chip) the GPX2 uses (confirmed by GPH)

 

[Inopia]

please people, if you don't know anything about hardware please don't try to make bullshit statements about things you don't have the slightest clue about.

or, in the words of napoleon dynamite:

SUCH AN IDIOT! GOSH!

 

[Prophet]

Someone's been reading the wrong datasheet The datasheet for the processor in the GPX2 says the following:

Dual 32bit CPU 400+ (Main Processor, Coprocessor) Embedded Architecture
- Main Processor used for Operating System & System Control, Audio Processing: ARM 920T CPU (200MHz, >220MIPS), 16KB I-Cache + 16KB D-Cache + MMU
- Coprocessor used for Video Header Parsing, Video Post Processor Control: ARM 940T CPU (200MHz, >220MIPS), 4KB I-Cache + 4KB D-Cache

So the second processor is pretty much dedicated to video processing duties. Whether we will be able to override this in the future remains to be seen, but since both GPH and the manufacturer of the above IC refuse to release detailed information, it's not going to be done near release time (all they say is "we will release sdk").

​

Well fuck damn. I searched around the ARM site for nothing then. <_<

My apologies. I had no idea about the SoC implementation being used, just found that data sheet from ARM and went from there.

Inopia - granted I was wrong, because I was going by a general datasheet from ARM and didn't know about the SOC being used (this is the first time I saw that link). But the theory of what I wrote IS true and proven. It just unfortunately may or may not apply here. I do "have a clue" I just didn't have the right link. It's not like the MagicEyes SOC is mentioned on the GPX2 spec page, just the ARM chip model numbers, so looking through the ARM data sheets for those chips is a pretty understandable mishap I think. I will also admit I didn't read all the threads on this board so I obviously missed what some of you already knew. Sorry.

And remember: No children or small animals were harmed in the making of this thread. :rolleyes:

 

[moz]

Someone's been reading the wrong datasheet The datasheet for the processor in the GPX2 says the following:

Dual 32bit CPU 400+ (Main Processor, Coprocessor) Embedded Architecture
- Main Processor used for Operating System & System Control, Audio Processing: ARM 920T CPU (200MHz, >220MIPS), 16KB I-Cache + 16KB D-Cache + MMU
- Coprocessor used for Video Header Parsing, Video Post Processor Control: ARM 940T CPU (200MHz, >220MIPS), 4KB I-Cache + 4KB D-Cache

So the second processor is pretty much dedicated to video processing duties. Whether we will be able to override this in the future remains to be seen, but since both GPH and the manufacturer of the above IC refuse to release detailed information, it's not going to be done near release time (all they say is "we will release sdk").

​

Well fuck damn. I searched around the ARM site for nothing then. <_<

My apologies. I had no idea about the SoC implementation being used, just found that data sheet from ARM and went from there.

Inopia - granted I was wrong, because I was going by a general datasheet from ARM and didn't know about the SOC being used (this is the first time I saw that link). But the theory of what I wrote IS true and proven. It just unfortunately may or may not apply here. I do "have a clue" I just didn't have the right link. It's not like the MagicEyes SOC is mentioned on the GPX2 spec page, just the ARM chip model numbers, so looking through the ARM data sheets for those chips is a pretty understandable mishap I think. I will also admit I didn't read all the threads on this board so I obviously missed what some of you already knew. Sorry.

And remember: No children or small animals were harmed in the making of this thread. :rolleyes:

​

no probs mate, what this has shown is that there are some people that need to chill and not use any excuse to jump down the throats of others.

 

[DaveC]

Someone's been reading the wrong datasheet The datasheet for the processor in the GPX2 says the following:

Dual 32bit CPU 400+ (Main Processor, Coprocessor) Embedded Architecture
- Main Processor used for Operating System & System Control, Audio Processing: ARM 920T CPU (200MHz, >220MIPS), 16KB I-Cache + 16KB D-Cache + MMU
- Coprocessor used for Video Header Parsing, Video Post Processor Control: ARM 940T CPU (200MHz, >220MIPS), 4KB I-Cache + 4KB D-Cache

So the second processor is pretty much dedicated to video processing duties. Whether we will be able to override this in the future remains to be seen, but since both GPH and the manufacturer of the above IC refuse to release detailed information, it's not going to be done near release time (all they say is "we will release sdk").

​

Well fuck damn. I searched around the ARM site for nothing then. <_<

My apologies. I had no idea about the SoC implementation being used, just found that data sheet from ARM and went from there.

Inopia - granted I was wrong, because I was going by a general datasheet from ARM and didn't know about the SOC being used (this is the first time I saw that link). But the theory of what I wrote IS true and proven. It just unfortunately may or may not apply here. I do "have a clue" I just didn't have the right link. It's not like the MagicEyes SOC is mentioned on the GPX2 spec page, just the ARM chip model numbers, so looking through the ARM data sheets for those chips is a pretty understandable mishap I think. I will also admit I didn't read all the threads on this board so I obviously missed what some of you already knew. Sorry.

And remember: No children or small animals were harmed in the making of this thread. :rolleyes:

​

So what all of this really means is that this Gpx2 really IS only a GP32 with only 33 MHz more? We are back to this thing kind of sucking for emulation but good for movies?

 

[moz]

Someone's been reading the wrong datasheet The datasheet for the processor in the GPX2 says the following:

Dual 32bit CPU 400+ (Main Processor, Coprocessor) Embedded Architecture
- Main Processor used for Operating System & System Control, Audio Processing: ARM 920T CPU (200MHz, >220MIPS), 16KB I-Cache + 16KB D-Cache + MMU
- Coprocessor used for Video Header Parsing, Video Post Processor Control: ARM 940T CPU (200MHz, >220MIPS), 4KB I-Cache + 4KB D-Cache

So the second processor is pretty much dedicated to video processing duties. Whether we will be able to override this in the future remains to be seen, but since both GPH and the manufacturer of the above IC refuse to release detailed information, it's not going to be done near release time (all they say is "we will release sdk").

​

Well fuck damn. I searched around the ARM site for nothing then. <_<

My apologies. I had no idea about the SoC implementation being used, just found that data sheet from ARM and went from there.

Inopia - granted I was wrong, because I was going by a general datasheet from ARM and didn't know about the SOC being used (this is the first time I saw that link). But the theory of what I wrote IS true and proven. It just unfortunately may or may not apply here. I do "have a clue" I just didn't have the right link. It's not like the MagicEyes SOC is mentioned on the GPX2 spec page, just the ARM chip model numbers, so looking through the ARM data sheets for those chips is a pretty understandable mishap I think. I will also admit I didn't read all the threads on this board so I obviously missed what some of you already knew. Sorry.

And remember: No children or small animals were harmed in the making of this thread. :rolleyes:

​

So what all of this really means is that this Gpx2 really IS only a GP32 with only 33 MHz more? We are back to this thing kind of sucking for emulation but good for movies?

​

guess were back to nobodys got a clue til its in our mits and read the hype that no doubt craigix will have selling the thing. time to appriciate the GP32 again

 

[BobBorakovitz]

So what all of this really means is that this Gpx2 really IS only a GP32 with only 33 MHz more? We are back to this thing kind of sucking for emulation but good for movies?

lol...what, in your opinion DOESN'T suck for emulation...
sometimes you're so negative it's frustrating to read....

 

[x68000]

So what all of this really means is that this Gpx2 really IS only a GP32 with only 33 MHz more? We are back to this thing kind of sucking for emulation but good for movies?

lol...what, in your opinion DOESN'T suck for emulation...
sometimes you're so negative it's frustrating to read....

​

why does he keep spamming every damn post with the same old thing.

Healthy speculation is a great thing and keeps the community thriving, whilst constant unfounded negativity is just boring.

 

[abigsmurf]

Lets think about this

what possible reason would GPH have to lock the 2nd CPU for set video related commands? It doesn't contain any protected instructions, there's no copy protections to get round. There's a huge performance boost in general usage from having 2 fully accessable CPUs.

About 2 CPUs not being helpfull for emulation. I can't think of a single console that needs lots of horsepower to emulate that operated using a single processor (wether they be sound, video or CPU). Splitting up these chips between the two CPUs frees up clock cycles allowing for faster emu.

 

[Squidge]

Lets think about this

what possible reason would GPH have to lock the 2nd CPU for set video related commands? It doesn't contain any protected instructions, there's no copy protections to get round. There's a huge performance boost in general usage from having 2 fully accessable CPUs.

​

GPH may not have a choice. MagicEyes (the manufacturer of the chip) provide the chips and some drivers for Linux and Windows CE. GPH decided on Linux, so they may not actually know anything about how the two processors work internally - they may simply be using the API given to them by MagicEyes, and provide an abstraction of this API with there own SDK.

The MagicEye's API isn't public, and they refuse to give out any detailed information about there SoC, so it may take a lot of reverse engineering to find out if it is even possible to run code on the second processor.

No doub't doubt we'll find out soon after the machine is released.