GP2X Gp2x Emulator For Pc?


I think GPH think the idea is that you develop in SDL on Windows/Linux/etc, and then when your happy with it, you recompile and do some slight changes for the 2x.
 
Yeh but that's only rearly good for developers.
It doesn't let the general public test out & see the console in action before buyin one.

A couple of years ago I was messing about with building a web site & made up a page for an online gameboy emulator. This let u play/test out the games etc. online without having to own an actual Gameboy. It used rom images of the software & games in the same folder as the HTML on the website. I also looked at quite a few other consoles/computers that used the same system.

An emulator would be great for the public to get a decent look & a general view of what the GP2X is capable of.
It could show the menu system working with different skins & maybe a small video file or game emulator runnin on it.

Just a thought..
 
this looks interesting..
Qemu is a generic and open source processor emulator.
It say's that it can run most ARM Linux binaries.
I'm wondering if there will be a way to install this & then have it boot up the GP2X firmware.
After all it's only a standard ARM Linux distribution isn't it <_< ?
 
It'd be MUCH easier just to ask the devs to compile a Desktop version of their SDL program. Also, MUST you double post EVERY time you post ANYWHERE?
 
One problem. SDL. Most of the more popular applications are not using SDL. They are hitting the hardware directly. So we cannot just "recompile" for Windows. As a developer myself, my desire for a Windows emulator of the GP2X would be for developing purposes. Much easier to debug an application in an emulator (given a good enough emulator such as Visual Boy Advance for the GBA) than on the actual hardware.
 
There are also a lot of software developers that like to write & test programs for different systems without having to go out & purchase everyone that they develop for.
This would give them a way to do that & could bring even more developers onto the system.

@God Ginrai - It's called evolving an idea. I look for info on the subject & then post my findings to help others. Double posting is two different posts that both say exactly the same thing.
 
Considering the GP32 ran default @ 133, but the emulator could only manage 40Mhz, I don't see an emulator appearing for the GP2X running 2xARM processors at 200Mhz, so even if one was made, it's not going to be an accurate representation of the hardware, so anyone wishing to develope for it should always try the software on actual hardware before releasing.

Tripmonkey_uk: Rather than posting twice, why not just edit your first post with the new information?
 
Squidge posted on Dec 24 2005 at 12:43 PM said:
Considering the GP32 ran default @ 133, but the emulator could only manage 40Mhz, I don't see an emulator appearing for the GP2X running 2xARM processors at 200Mhz, so even if one was made, it's not going to be an accurate representation of the hardware, so anyone wishing to develope for it should always try the software on actual hardware before releasing.

Tripmonkey_uk: Rather than posting twice, why not just edit your first post with the new information?

I'll start to do that more, but it's sometimes easier for other people to see changes in a thread if a new post is added.

The Qemu accelerator module could be used to vastly speed up the emulation to near native speeds (so it says ;) ) & from what i've read the software has just started to support dual processors with the latest release.

I still agree that the software will need to be tested on a real system before general public release though but it's easier just to ask 1 person to test out some thing a couple of times than it is to have some one checking out every change that u make.
 
Last edited by a moderator:
The QEMU Accelerator Module increases the speed of QEMU when a PC is emulated on a PC. It runs most of the target application code directly on the host processor to achieve near native performance.

So, if the target was ARM, it would try and run ARM code directly on a X86 processor. I don't think that's going to work too well.
 
I think what they mean is that the signals are routed directly to the corasponding pins of the host processor instead of going through the emulation software & then into the host processor.
A lot of processors are essentialy made the same, which is why u can sometimes use more than one type to do the same job on a PCB board even though the processors have been made for completely different reasons & to fullfill different needs.
Of course it would give a lot better speed increase for running operating systems that use the same type of processor (Windows/Linux) as the host computer but even a small increase for other systems would be welcome.

e.g. The GP2X uses built in AC97 audio. If the emulator is running on a computer with the same AC97 audio on the motherboard or sound card (a lot of systems use this), then it could take a lot of the work away from the main processor & the emulator.


I'm not a programmer so the technical side of this is completely beyond me i'm afraid :( .

I've left an enquiry on the forum so we'll just have to wait & see if anyone gets back with any more info.
 
Squidge posted on Dec 24 2005 at 08:20 AM said:
The QEMU Accelerator Module increases the speed of QEMU when a PC is emulated on a PC. It runs most of the target application code directly on the host processor to achieve near native performance.

So, if the target was ARM, it would try and run ARM code directly on a X86 processor. I don't think that's going to work too well.

The QEMU accelerator obviously only works when you're emulating x86 on an x86 host system.
 
Last edited by a moderator:
Tripmonkey_uk posted on Dec 24 2005 at 06:48 AM said:
@God Ginrai - It's called evolving an idea. I look for info on the subject & then post my findings to help others. Double posting is two different posts that both say exactly the same thing.

Double posting is an act of making two posts one after the other in a topic, NOT SPECIFICALLY making the exact same post twice in a row.

Tripmonkey_uk posted on Dec 24 2005 at 08:04 AM said:
Squidge posted on Dec 24 2005 at 12:43 PM said:
Considering the GP32 ran default @ 133, but the emulator could only manage 40Mhz, I don't see an emulator appearing for the GP2X running 2xARM processors at 200Mhz, so even if one was made, it's not going to be an accurate representation of the hardware, so anyone wishing to develope for it should always try the software on actual hardware before releasing.

Tripmonkey_uk: Rather than posting twice, why not just edit your first post with the new information?

I'll start to do that more, but it's sometimes easier for other people to see changes in a thread if a new post is added.

Just put edit in all caps before the new information, or maybe something like:

*****************************{EDIT}*****************************

Above whatever you add in.

EDIT: btw, here's a link to the definition of Double Post Look at the first definition. http://double-post.urbanup.com/1104193
 
Last edited by a moderator:
If you had a MMSP2 chip on a PCI card, THEN you could have 'hardware' accelerated emulation.

Not a bad idea actually, as it would allow really fast debugging and testing.

Direct access to the MMSP2 hardware/memory from a x86 PC.

Of course such development hardware would cost $1000's of dollars due to the fact that only a few will ever be made. (which means they will never be made... catch-22)
 
Series-8 posted on Dec 27 2005 at 12:34 AM said:
If you had a MMSP2 chip on a PCI card, THEN you could have 'hardware' accelerated emulation.
Agreed.. Although I was thinking more along the lines of the emulator just sending the signals to the correct pins on the audio chipset, rather than having to use the exact same chip. Not too sure if all AC97 audio compatible cards/motherboards have the same pinouts for full compatability though <_<
This might work but would probably be way too much trouble thinking about it.

@God Ginrai: I'd rather take more notice of the second definition than the first one. That's the one that the most people agree with (& the one that proves me right :p).
I guess it's one of those things that comes under personal preference at the end of the day, so whatever makes u feel good.
Thanx for the heads up anyway. I've checked all of my former posts & noted the ones that I can improve on by editing.

We're getting way off topic with this thread. Back to the matter in hand if no one minds..

I didn't even know that there was an emulator for the GP32. Why did it run so slow?
 
Last edited by a moderator:
If emulators were required, It would have a similar approch to dos box: DosBox emulates Soundblaster, Soundblaster Pro, And Gravis Ultra Sound, maybe a few more, and when it gets actual audio output it prolly converts it to sdl compatible output and sends it to sdl's audio processing system. Although, I think SDL can be considered a "limit" to dosbox, becuase it seems to slow it down. Remember, the lower level of access, the faster the speed.

Maybe i could try my best to make an emulator for it. i have made a game engine that could run a special binary type file, so this would just be sticking to GP2Xs type of compiled binarys (GPE i believe. It would take some time to fully figure it out...)

I believe emulators are always capable of going faster... its just about inefficiancy and the rush to complete(NEVER USE A LIBRARY LIKE SDL TO TO EMULATE NEWER MACHINES LIKE THE GP2X! SPEED PROBLEMS WOULD ARISE VERY QUICKLY)
 
Back
Top