Working Port Of Gngeo


Ok, fair point, the battery thing. (and also the challange and demoscene thing i like those to and optimization to the last bit is a challange, but i'm still not sure if its worth the effort) I did not know that emulation has so mutch to offer for assembler. My knowlage was based on x86 assembler and a smal study a workinggroup at my university did. Lets see what we can do. (so its not first priority, that would be the frontend ... still loocking for rage2x source. link enyone?)
For everyone interested in what compiler optimizations can do, check my post on numpty physics. There are 2 different builds. the first one ist build without any optimizations flags. The second one is build with all processor specific optimizations flags i could find.
 
Last edited by a moderator:
manolis said:
Lets see what we can do. (so its not first priority, that would be the frontend ... still loocking for rage2x source. link enyone?)

... agreed ;) !

Have a look at this ;) :

http://dl.openhandhelds.org/cgi-bin/wiz.cgi?0,0,0,0,46,420
 
Last edited by a moderator:
manolis said:
Why is everybody so stoked about arm asm? With modern compilers its very hard and often nearly impossible to write asmcode that is significantly faster than generated asmcode. And why would anybody write some asm witch gives a plus of 1% maybe 2% when the software already runs at fullspeed?

Greetings
Manolis

The difference is actually enormous as daveC pointed out. It ~ doubles the speed of the emulator. Meaning people can clock down, plus it's always best on these devices to have the software as optimised as possible. Why should a GP2X be able to play GNgeo at 200mhz and the Pandora needs 500mhz? You will get people comparing the devices based on those flawed statistics.

The Pandora is not going to get stuck in that trap which seems to haunt many other devices.
 
Last edited by a moderator:
craigix said:
Why should a GP2X be able to play GNgeo at 200mhz and the Pandora needs 500mhz?

Craigix do you know who was the "wizard" achieving such a result on the GP2X :blink: ?!

... maybe we can convince him to step in and give us an hand with the Pandora as well ;)

craigix said:
The Pandora is not going to get stuck in that trap which seems to haunt many other devices.

1K points to Craigix :lol: ! ... fighting spirit: I like it ;)
 
Last edited by a moderator:
wizboy said:
craigix said:
Why should a GP2X be able to play GNgeo at 200mhz and the Pandora needs 500mhz?

Craigix do you know who was the "wizard" achieving such a result on the GP2X :blink: ?!

... maybe we can convince him to step in and give us an hand with the Pandora as well ;)

There isn't a wizard required, just using the cyclone 68k core which is already there.
 
Last edited by a moderator:
craigix said:
wizboy said:
craigix said:
Why should a GP2X be able to play GNgeo at 200mhz and the Pandora needs 500mhz?

Craigix do you know who was the "wizard" achieving such a result on the GP2X :blink: ?!

... maybe we can convince him to step in and give us an hand with the Pandora as well ;)

There isn't a wizard required, just using the cyclone 68k core which is already there.


Why not use Drz80 for the Z80 core as well? Or is that less compatible than the C Z80 core? I know Cyclone is regarded as v compatible.
 
Last edited by a moderator:
craigix said:
The difference is actually enormous as daveC pointed out. It ~ doubles the speed of the emulator. Meaning people can clock down, plus it's always best on these devices to have the software as optimised as possible. Why should a GP2X be able to play GNgeo at 200mhz and the Pandora needs 500mhz? You will get people comparing the devices based on those flawed statistics.

The Pandora is not going to get stuck in that trap which seems to haunt many other devices.
You are absolutely right! (did I really sayed this? :ph34r: )
It is good that a program can run that easily Full Speed onto the Pandora. But the coders often forget, that we don't have a PC here but a Battery driven Handheld that always benefit from everything that saves battery Time :)
I would be very disappointed, when the Coders onto the Pandora go the same way as coders onto modern PC's: Unoptimized Code because we still have Full Speed with Quad-Cores and GIGA-Graphics Cards.
Onto the old days, the Coders simply have to optimize to run their programs, C64 or Amiga hadn't that much reserve in Processor Power.

Yes, I see the GP2X and I see that GNGeo runs at 200MHz. So I'm sure, we don't need 500MHz onto the Pandora if the program will be more optimized. :) It is always a benefit to optimize (IF possible). Me and my Pandora battery will be thankful. ;)
 
Last edited by a moderator:
silver said:
craigix said:
wizboy said:
craigix said:
Why should a GP2X be able to play GNgeo at 200mhz and the Pandora needs 500mhz?

Craigix do you know who was the "wizard" achieving such a result on the GP2X :blink: ?!

... maybe we can convince him to step in and give us an hand with the Pandora as well ;)

There isn't a wizard required, just using the cyclone 68k core which is already there.


Why not use Drz80 for the Z80 core as well? Or is that less compatible than the C Z80 core? I know Cyclone is regarded as v compatible.

It may well already be there too. I'd like it to use it if it uses it on the gp2x.
 
Last edited by a moderator:
craigix said:
There isn't a wizard required, just using the cyclone 68k core which is already there.

... even better then ;)

fusion_power said:
Onto the old days, the Coders simply have to optimize to run their programs, C64 or Amiga hadn't that much reserve in Processor Power.

... very true ! ;)
 
Last edited by a moderator:
On GP2x at 200MHz you don't play Neogeo game, you need 300MHz to have fullspeed neogeo without frameskip and with sound (22KHz and for some games 44KHz). Not for last game because of .gfx used but in Pandora with all the memory we don't need this files then no slowdown.
We can speculate that on Pandora we need 300 or 400MHz to have fullspeed (without framskip) with fullsound (44KHz).

http://wiki.gp2x.org/wiki/GnGeo2x#List_of_games

The people using this version of gngeo what is the sound option in the emulator?
 
manolis said:
Ok, fair point, the battery thing. (and also the challange and demoscene thing i like those to and optimization to the last bit is a challange, but i'm still not sure if its worth the effort)
It still is, main reasons are:
- gcc does rather poor job generating code for anything that isn't x86
- it does it even worse with NEON, might even generate broken code
- in some special cases like asm cores, you can designate registers for things that are used most, what compiler will have hard time figuring out. You can also do things you can't in C, like reading flags directly after operations.
 
Last edited by a moderator:
Nice port, was looking forward to Neo-Geo on my P! Looking forward to a nice frontend and options.
Couple of points, Super Sidekicks 3 and 4 doesn't display the pitch, also Overtop crashes as u r about to start a race, other than that seems great, although as someone has mentioned it won't load games bigger than 30mb, which cuts out 25-30 games, hope u can sort these soon, thanks again!
 
notaz said:
manolis said:
Ok, fair point, the battery thing. (and also the challange and demoscene thing i like those to and optimization to the last bit is a challange, but i'm still not sure if its worth the effort)
It still is, main reasons are:
- gcc does rather poor job generating code for anything that isn't x86
- it does it even worse with NEON, might even generate broken code
- in some special cases like asm cores, you can designate registers for things that are used most, what compiler will have hard time figuring out. You can also do things you can't in C, like reading flags directly after operations.
Ouch, I didn't know that. Is there an alternative (edit: a free alternative, I know there is RVDS, but that costs, what, 10'000$ or so...) for compiling C/C++ code to ARM that fares better? Or is it at least possible to configure GCC so it behaves a little better for ARM?
 
Last edited by a moderator:
Lafazar said:
notaz said:
manolis said:
Ok, fair point, the battery thing. (and also the challange and demoscene thing i like those to and optimization to the last bit is a challange, but i'm still not sure if its worth the effort)
It still is, main reasons are:
- gcc does rather poor job generating code for anything that isn't x86
- it does it even worse with NEON, might even generate broken code
- in some special cases like asm cores, you can designate registers for things that are used most, what compiler will have hard time figuring out. You can also do things you can't in C, like reading flags directly after operations.
Ouch, I didn't know that. Is there an alternative (edit: a free alternative, I know there is RVDS, but that costs, what, 10'000$ or so...) for compiling C/C++ code to ARM that fares better? Or is it at least possible to configure GCC so it behaves a little better for ARM?

GCC is pretty much the best, even with its flaws.

-God Ginrai
 
Last edited by a moderator:
Thanks so much for this :D
can someone try viewpoint i get CTD when inserting coins.


cheers
 
jaycee900 said:
Nice port, was looking forward to Neo-Geo on my P! Looking forward to a nice frontend and options.
Couple of points, Super Sidekicks 3 and 4 doesn't display the pitch, also Overtop crashes as u r about to start a race, other than that seems great, although as someone has mentioned it won't load games bigger than 30mb, which cuts out 25-30 games, hope u can sort these soon, thanks again!

Mh...37 MByte worked for me

manolis said:
DaveC said:
Also does this not support large ROMs or is there a trick to get some games working?
I'm not that familiar with neogeo games an the emultation of those (i just wanted to play MetalSlug witch i loved in arcade halls as a child). Maybe your game is a neogeo CD game? As far as i know gngeo only emulates neogeo (the arcade thing).

EDIT:
I just tested the largest neogeo rom compatible with gngeo i had in my mame collection (garoup.zip with around 37 MByte). It took some time to load but it started. It did not run smooth, but this was maybe caused by me pushing data via sftp over usb to the pandora.

EDIT 2:
Jap, it worked smooth after the transfer was done.

Greetings
Manolis
 
Last edited by a moderator:
manolis said:
Ok, fair point, the battery thing. (and also the challange and demoscene thing i like those to and optimization to the last bit is a challange, but i'm still not sure if its worth the effort) I did not know that emulation has so mutch to offer for assembler. My knowlage was based on x86 assembler and a smal study a workinggroup at my university did. Lets see what we can do. (so its not first priority, that would be the frontend ... still loocking for rage2x source. link enyone?)
For everyone interested in what compiler optimizations can do, check my post on numpty physics. There are 2 different builds. the first one ist build without any optimizations flags. The second one is build with all processor specific optimizations flags i could find.
I do agree that asm is probably not the first priority. I think the bugs like garbled sprites and missing backgrounds etc would probably be more important now. A front end like you say too is probably more important.

After that there is the source to GNGEO on the gp2x that maybe could be used as reference to help with adding cyclone ASM etc.
 
Last edited by a moderator:
The problem comes from the cyclone core, but the z80 asm core works fine, so you guys could maybe rebuild it with the z80 asm core enabled. Else for the cyclone core, you would have to update it to latest notaz cyclone and update the blob to reflect changes (which is out of my knowledge :) )
 
Pickle said:
DaveC said:
After that there is the source to GNGEO on the gp2x that maybe could be used as reference to help with adding cyclone ASM etc.

my build is from the gp2x sources

But your Build is not a PND yet, so....

-God Ginrai
 
Last edited by a moderator:
Back
Top