Gp32 Emulation
- Thread starter DTH
- Start date
Prophet
God I'm old.
There were very few truly good commercial games for GP32 IMO. Off the top of my head... Her Knights, Super Plusha and Pinball Dreams. Everything else was pretty mediocre or just plain bad, to be honest.
But there were plenty of good emus and homebrew - and those things could be ported to Pandora.
But there were plenty of good emus and homebrew - and those things could be ported to Pandora.
Tobriand
Well-Known Member
And many of them won't be because the coders who made them have long since vanished from the community. All those games by Akuma No Houkon, for starters. And Gloop. And rather a few more at a quick glance through the archives, although I must admit, the number of Connect-4 clones is surprising, and not especially desirable unless some of them have *really* good AI.
I'm *still* hoping Spot makes it to the Pandora, and in a complete state, though I'm guessing that won't be the first thing on Squidge's mind at the moment.
I'm *still* hoping Spot makes it to the Pandora, and in a complete state, though I'm guessing that won't be the first thing on Squidge's mind at the moment.
Tobriand
Well-Known Member
If you spoke Korean, there were certainly a couple more of note - most obviously Astonisha Story and Mill.
There was also Blue Angelo, although the dialogue in that was pretty abysmal. Gameplay was good, though.
But tbh, my interest in GP32 emulation is twofold:
First: There's some *amazing* homebrew for it.
Second: If it can be done using a stupidly efficient base of emulation (which seems to be how Spot works, just incompletely), then it is *conceivable* (but no more than) that GP32 emulators may be of use, seeing as they often ran far more efficiently than their 2x counterparts (i.e. often near fullspeed at ~133MHz, and in one case, at 66MHz, iirc). I don't hold out much hope for this, however... the method by which GP32 programs were run would have to be, as mentioned, ridiculously efficient to the point of silliness. Which is just silly.
There was also Blue Angelo, although the dialogue in that was pretty abysmal. Gameplay was good, though.
But tbh, my interest in GP32 emulation is twofold:
First: There's some *amazing* homebrew for it.
Second: If it can be done using a stupidly efficient base of emulation (which seems to be how Spot works, just incompletely), then it is *conceivable* (but no more than) that GP32 emulators may be of use, seeing as they often ran far more efficiently than their 2x counterparts (i.e. often near fullspeed at ~133MHz, and in one case, at 66MHz, iirc). I don't hold out much hope for this, however... the method by which GP32 programs were run would have to be, as mentioned, ridiculously efficient to the point of silliness. Which is just silly.
Chip
[Insert Custom Title Here]
Commercial GP32 games had some kind of DRM that locked the game to the internal serial number of your unit. Breaking it is probably not that difficult, but it is a felony on many countries. Not that it is likely to ever be an issue, but is it really worth it for a handful of mediocre (at best) games? I bought Little Wizards and Die Hard With Infinite Stairs, and neither of them were spectacular.
Most homebrew titles will port with little trouble. That is probably good enough.
Most homebrew titles will port with little trouble. That is probably good enough.
Ravnos
Asleep in Samsara
shmuck said:
Last edited by a moderator:
Squidge
Certified Guru
Not going to happen I'm afraid, to make the gp32 run fast, we need to run arm code directly, but the gp32 does too much hardware hacking for that to work properly. Disabling the caching would make it work, but would also mean it being too slow.Tobriand said:
Last edited by a moderator:
Exophase
Nothing good will ever come of Exophase.
Squidge said:
Last edited by a moderator:
Squidge
Certified Guru
I've not played with it for a good while now, but I seem to recall that the problem was that it loaded an app from smc, unpacked it and then jumped to a location to execute it. It then hit an illegal instruction even though the code at that address was perfectly valid - I can only assume that what was in memory wasn't what was in the i-cache for that address for some reason.
yaustar
UK GP32 & GP2X Owner
I think Akuma No Houkon was kicking about last year and got or at least considering a GP2X. Haven't heard much since then.
Esn
(:";
chad78
Active Member
Ok - well what about a GP2X emu / compatibility layer? Or is that pretty much the same thing / problems?
You know, reading this thread does not inspire a lot of hope in the Pandora. If the system that started it all didn't produce much of anything... You know what I'm saying?
You know, reading this thread does not inspire a lot of hope in the Pandora. If the system that started it all didn't produce much of anything... You know what I'm saying?
Tobriand
Well-Known Member
Oh the system that started it all produced a hell of a lot - both in emulators and homebrew.chad78 said:
The thing is, the vast majority of that stuff ended up on the GP2x because it got ported over by the coders that made the transition (though there are still anomalies, and a fair few at that). The presumption is that the same thing will happen for Pandora.
So it's not a matter of there not being much material. It's just material that we probably would get, for the most part, anyway, without needing to emulate the system. It's just that some of them, we wouldn't (which is where an emulator would be nice).
Incidentally, I suspect that whilst a compatibility layer might be possible for programs that don't make use of the GP2x-specific hardware, it would be more problematic (I'd expect realistically impossible, but I don't know) for that which does. I'm thinking the blitter, the scaler, and the second processor in particular.
EDIT: Another thought: much of the really good homebrew for both GP32 and GP2x has been done in Fenix. That, of course, doesn't really even need porting, once Fenix itself has been ported, although tweaking is good.
Last edited by a moderator:
Chip
[Insert Custom Title Here]
All the really great programs for the GP32 are either ports or original homebrew. t would be easier to port them over to the Pandora than to try to emulate the GP32 itself.chad78 said:
The only programs you can't port are the commercial games. These were less than 2 dozen of them, and they were not terribly impressive. If you poke around various P2P networks you can probably find most if not all of them with the DRM removed. You can play them on the win/linux GP32 emulator called GeePee32.
Who knows, maybe Firefly will port GeePee32 to Pandora (or at least open up the source).
Last edited by a moderator:
Maybe somebody could clarify something for me.
There have been a number of people talking up ARM architecture on this board as being just, really spiffy. What I'm seeing here though is that it seems that every single platform requires its own set of specially customized software. Is that correct?
Naturally, I expect that any software designed to take advantage of platform-specific features (the GP2X's dual processors, for example) would have to be reconfigured, but is it out of the question to expect something more generic, but that was written for Linux on an ARM, to run without modification?
If, for example, I were to try to install an MP3 player binary that was originally written for a Zaurus, could I expect that to work?
There have been a number of people talking up ARM architecture on this board as being just, really spiffy. What I'm seeing here though is that it seems that every single platform requires its own set of specially customized software. Is that correct?
Naturally, I expect that any software designed to take advantage of platform-specific features (the GP2X's dual processors, for example) would have to be reconfigured, but is it out of the question to expect something more generic, but that was written for Linux on an ARM, to run without modification?
If, for example, I were to try to install an MP3 player binary that was originally written for a Zaurus, could I expect that to work?
No. The cpu is not the only thing that's platform-specific.shmuck said:
Binary compatibility is hard to achieve and mostly useless in the embedded world (where specialisation of software is sometimes needed). Source compatibility, possible (changes usually are required).
Last edited by a moderator:
