400mhz Processor In Gpx2, Please!

[Wonder Boy]

Hi,

Pardon, I imagine that already has been spoken about, but I don't know a thing and my question is:

Why will not be used a AMR microprocessor of 400MHz instead of 200MHz on GPX2?

¿This MHz ampliation elevates too much the final price of the product?

Thanx & Un Saludo,

 

[Vimacs]

the gpx2 haves 2 arm9 200mhz wich are supposed to have over 400mips wich is about equal to a 400mhz arm, however the dualcore should be much cheaper, gph wants to make the new handheld as cheap as possible.

 

[Wonder Boy]

the gpx2 haves 2 arm9 200mhz wich are supposed to have over 400mips wich is about equal to a 400mhz arm, however the dualcore should be much cheaper, gph wants to make the new handheld as cheap as possible.

​

Yeah, that I already knew it, I speak of which gpx2 has the main processor working to 400 MHz and the other (graphical) to 200MHz...
But as you say, this surely would cause that the console stopped being so cheap... (perhaps although it is worth the trouble to pay something more than money for that reason... who knows?)

Thanx for the answer & Un Saludo.

 

[Squidge]

It is not possible to use the chipset GPH are using at 400Mhz, as both processors are in a single chip along with other components, so it is not just a cost issue, it is simply not possible - the entire hardware of the GPX2 would have to be changed.

 

[Wonder Boy]

It is not possible to use the chipset GPH are using at 400Mhz, as both processors are in a single chip along with other components, so it is not just a cost issue, it is simply not possible - the entire hardware of the GPX2 would have to be changed.

​

Ah, OK. Thanx for the total aclaration

 

[Fishbong]

the gpx2 haves 2 arm9 200mhz wich are supposed to have over 400mips wich is about equal to a 400mhz arm,

​

The problem is just that a straight port wouldn´t use the 2nd processor core. That means a port of, say, snes9x would only use the primary CPU unless the source would be heavily modified (f.i. for doing the sound emulation on the secondary core). Also the development of new apps will we more complicated if the dev wants to use the GPx2´s full potential.

 

[Squidge]

the second processor supports multiple codec uploads, so no doubt, within time, people will be able to upload processor cores instead, making life a lot easier. Just upload the processor core of the machine your emulating to the second processor, and do the rest on the first, and one instant emulator within a few hours

 

[dpoarch]

This may sound stupid but the gp32 is only clocked at 133 mhz but I can overclock mine around 200. Couldn't the main gpx2 cpu be overclocked in the same way?

 

[Vimacs]

noone knows (tm)

 

[Prophet]

This may sound stupid but the gp32 is only clocked at 133 mhz but I can overclock mine around 200.  Couldn't the main gpx2 cpu be overclocked in the same way?

​

Most likely yes. ARM chips seem to always be OC'able.

How much, and how safely remains to be seen. But I recall reading there was a 250Mhz version of the 920T, so maybe the GPX2 could be OC'ed that high. Maybe even more. Or maybe less. Time will tell.

 

[reallynotnick]

Heres to hoping we can at least overclock it to 233mhz!

 

[Jarska333]

How similar is the CPU to the one in GP32? Are the mhz's even comparable?

 

[Ruune]

The biggest problem may be clocking BOTH the processors. Say one processor clocks all the way to 250mhz, but the other only 233mhz.... the highest you could go would be 233 right? then again, both cores will likely come from the same batch.... I dunno.

 

[DaveC]

The biggest problem may be clocking BOTH the processors. Say one processor clocks all the way to 250mhz, but the other only 233mhz.... the highest you could go would be 233 right? then again, both cores will likely come from the same batch.... I dunno.

​

I think the same oscillator controlls both cores. It is really one chip, it just has separate cores. They would have to be running at the same speed or they would error out and crash when talking to each other I would think.

 

[Fishbong]

the second processor supports multiple codec uploads, so no doubt, within time, people will be able to upload processor cores instead, making life a lot easier. Just upload the processor core of the machine your emulating to the second processor, and do the rest on the first, and one instant emulator within a few hours

​

Supports Core uploads??? That weans one could upload, say, the GBA´s processor core data and then already have 50% of the emu done?

Or am i talking out of my arse?

 

[Talyz]

It sounds like that could make the emulators a lot faster too!

 

[Squidge]

We could both be talking out of our arse None of us know whats possible until we can actually get our hands on one of these babies and start messing with it. I very much doubt GPH would allow us to mess with the second processor from the the word go, but if it's possible (and if you can upload codecs to it, why not?) then it'll get done with a third party sdk

The reason why I think that is that I think GPH are concentrating on a SDL library, as that makes things easier for everyone, and so hopefully more stuff with be ported. It will not be long though before we start craving for more speed and alternative ways. That's when it gets fun.

We'll just have to see what comes out.

It's possible that the cores could run at different speeds, they would just require some synchronisation, which is easy enough to implement. Most likely they'll be running from the same clock source, but the PLL may be configured differently. Again, we are just guessing until it comes out.

 

[Digitalrat]

the second processor supports multiple codec uploads, so no doubt, within time, people will be able to upload processor cores instead, making life a lot easier. Just upload the processor core of the machine your emulating to the second processor, and do the rest on the first, and one instant emulator within a few hours wink.gif

Wouldn't the emulation be even to fast then? If you aren't able to run the processors on different speeds, you won't be able to only clock the second processor to the speed of the emulated system. (you still need the other processor for different things, like sound)

 

[Prophet]

the second processor supports multiple codec uploads, so no doubt, within time, people will be able to upload processor cores instead, making life a lot easier. Just upload the processor core of the machine your emulating to the second processor, and do the rest on the first, and one instant emulator within a few hours wink.gif

Wouldn't the emulation be even to fast then? If you aren't able to run the processors on different speeds, you won't be able to only clock the second processor to the speed of the emulated system. (you still need the other processor for different things, like sound)

​

You don't clock CPU's to the speed of the emulated system. You just cycle the emulated AKA virtual CPU and video hardware at 60fps (or whatever Hz it requires). The host CPU(s) runs at, preferably, the fastest speeds you can go, allowing more clock cycles to run through your virtual hardware loops. Meaning less need for frame skipping, and more time for better accuracy.

If you can potentially have two CPU's sharing the loads, as Squidge describes, all the better.

 

[skeezix]

IMHO, it seems dumb so far. Companies go with low clock rates because the rest of the hardware can do heavy lifting.. but GP/GPH/etc use off the sehfl non-custom hardware to keep costs down.. so they shouldn't cheap out on MHz. ie; Neo Geo MVS arcade hardware, and GBA, and othe rplatforms have low clock rates, since the hardware does the work. I'm sick of 200MHz machines that have no real hardware to back them up .. give us the real deal

jeff