Gpsp2x Goes Public With V9008!
- Thread starter zodttd
- Start date
Anonelbe
Still Fresh
Finally free again... worst thing is, they don't have any cold beer in purgatory 
. Anyway, glad I could be of help; I'll keep my eyes open if there's anything new on the Japanese site, but it seems like there hasn't been much activity lately.
I also tried to fiddle around a bit with the linux version of VBA yesterday, but unfortunately it doesn't come with a disassembler... guess there's no way around the Windows version for now.
slashank, how long did it take you to find these new loops? Did you stop "Automatic Update" every now and then to check the addresses? Maybe we should start a separate thread, or use the wiki to keep track of our findings.
On a different note... it's just a wild guess, but is it possible that the random freezes might be related to SD cards and/or size of the ROMs? I've got quite a mess of data on my main 2GB card, so I tried loading a couple of ROMs from the NAND; Warioware Inc. and Mojipittan worked like a charm, but Gyakuten Saiban 3 froze after about 10 minutes in the game. Also, I couldn't get any ROMs larger than 8 MB file size to load from NAND; though admittedly I only tried two ROMs with 16 MB file size.
I then used a 64 MB card I had lying around to give it another shot: I was able to play FF4j (8 MB) for about an hour, before I quit and loaded up Rhythm Tengoku (16 MB), played for maybe 15 minutes without any problems, then went to sleep (as it was already past 2 a.m. :rolleyes. Maybe it's got something to do with gmenu2x as well, since I only put the gpsp2x files and some ROMs on the smaller card..
Now I don't know if this information is of any use, it could just be nothing more than random observations. However, it seemed to me as though "smaller" ROMs (=8 MB) ran more stable... both Mojipittan and Warioware froze up on me only a couple of times; but when playing 16 MB ROMs like Advance Wars 1+2 or Rhythm Tengoku lockups seemed to appear more frequently.
Btw, I'm running gpsp@240Mhz, FW 2.1.1, using gmenu2x.
. Anyway, glad I could be of help; I'll keep my eyes open if there's anything new on the Japanese site, but it seems like there hasn't been much activity lately.I also tried to fiddle around a bit with the linux version of VBA yesterday, but unfortunately it doesn't come with a disassembler... guess there's no way around the Windows version for now.
slashank, how long did it take you to find these new loops? Did you stop "Automatic Update" every now and then to check the addresses? Maybe we should start a separate thread, or use the wiki to keep track of our findings.
On a different note... it's just a wild guess, but is it possible that the random freezes might be related to SD cards and/or size of the ROMs? I've got quite a mess of data on my main 2GB card, so I tried loading a couple of ROMs from the NAND; Warioware Inc. and Mojipittan worked like a charm, but Gyakuten Saiban 3 froze after about 10 minutes in the game. Also, I couldn't get any ROMs larger than 8 MB file size to load from NAND; though admittedly I only tried two ROMs with 16 MB file size.
I then used a 64 MB card I had lying around to give it another shot: I was able to play FF4j (8 MB) for about an hour, before I quit and loaded up Rhythm Tengoku (16 MB), played for maybe 15 minutes without any problems, then went to sleep (as it was already past 2 a.m. :rolleyes
. Maybe it's got something to do with gmenu2x as well, since I only put the gpsp2x files and some ROMs on the smaller card.. Now I don't know if this information is of any use, it could just be nothing more than random observations. However, it seemed to me as though "smaller" ROMs (=8 MB) ran more stable... both Mojipittan and Warioware froze up on me only a couple of times; but when playing 16 MB ROMs like Advance Wars 1+2 or Rhythm Tengoku lockups seemed to appear more frequently.
Btw, I'm running gpsp@240Mhz, FW 2.1.1, using gmenu2x.
cowai
hellolo.
Can someone check if Mario Kart has any loops? I can't seem to find any... But I'm not sure if I'm doing it right...
Exophase
Nothing good will ever come of Exophase.
Fortunately (or not, depending on your perspective) a majority of games do the right thing and use the BIOS routines to wait for interrupts rather than using idle loops. When I say a majority I mean more than half. Most popular games that do have idle loops have already had them detected. For some games that do idle loop it'll barely make a difference to have them eliminated (like later MMBN games).
If anyone wants me to find if a game has an idle loop and what it is I can do is within a few minutes - if the game is trying to run ~280,000 or more instructions per cycle with every instruction timed to take one cycle then it's probably using idle loops (a real GBA could never run this many), so that's easy to check for. Finding them isn't that hard, I can get a rough idea in the PC version of gpSP then fine tune it in an emulator with a disassembler.
BTW, I recommend using something like Boycott Advance, Mappy VM, or Advance Debugger instead of VBA. The debugging utilities for the Windows version are almost nonexistent. The SDL/debug version has a good debugger (especially the version on the CVS) but lacks the benefits of having a GUI.
The thing is, to really know if something is an idle loop you need to carefully inspect the entire loop to see what it's doing; it's somewhat of a fixed point problem. If nothing's changing overall in registers then it's probably an idle loop. But if you don't really understand the ARM disassembly then you're liable to crush code that isn't an idle loop at all, potentially wrecking the game (if you've improved FPS substantially but the game runs as bad or worse then you might have just skewered the game's timing resulting in "internal lag"). Of course, if the game spends a huge percentage of the frame time in that loop (especially for an obscene number of cycles that wouldn't be feasible on a real GBA) then it's probably an idle loop. But these aren't things that you can really find out in VBA or any other disassembler that I know of. Maybe I should release a modified version of the PC gpSP to aid in this.
Oh, and some games are going to be abnormally slow for other reasons, to varying degrees. This is because they thrash code in IWRAM forcing constant recompilations. The "translation gates" are there to try to minimize this but it doesn't do enough for some games (and they're a real pain to find). Most games do not suffer from this problem (it's probably a few percent) - known culprits are games by Camelot, Doom/2, Driver 2, and some others. I'm working out a new self modifying code handling scheme to try to alleviate it some (or a lot, hopefully). The work is more in the front end of the recompiler (the portable part) than the backend (the part that's specific for PSP, GP2X, PC, etc) so the changes should propogate to all versions with dynarecs.
If anyone wants me to find if a game has an idle loop and what it is I can do is within a few minutes - if the game is trying to run ~280,000 or more instructions per cycle with every instruction timed to take one cycle then it's probably using idle loops (a real GBA could never run this many), so that's easy to check for. Finding them isn't that hard, I can get a rough idea in the PC version of gpSP then fine tune it in an emulator with a disassembler.
BTW, I recommend using something like Boycott Advance, Mappy VM, or Advance Debugger instead of VBA. The debugging utilities for the Windows version are almost nonexistent. The SDL/debug version has a good debugger (especially the version on the CVS) but lacks the benefits of having a GUI.
The thing is, to really know if something is an idle loop you need to carefully inspect the entire loop to see what it's doing; it's somewhat of a fixed point problem. If nothing's changing overall in registers then it's probably an idle loop. But if you don't really understand the ARM disassembly then you're liable to crush code that isn't an idle loop at all, potentially wrecking the game (if you've improved FPS substantially but the game runs as bad or worse then you might have just skewered the game's timing resulting in "internal lag"). Of course, if the game spends a huge percentage of the frame time in that loop (especially for an obscene number of cycles that wouldn't be feasible on a real GBA) then it's probably an idle loop. But these aren't things that you can really find out in VBA or any other disassembler that I know of. Maybe I should release a modified version of the PC gpSP to aid in this.
Oh, and some games are going to be abnormally slow for other reasons, to varying degrees. This is because they thrash code in IWRAM forcing constant recompilations. The "translation gates" are there to try to minimize this but it doesn't do enough for some games (and they're a real pain to find). Most games do not suffer from this problem (it's probably a few percent) - known culprits are games by Camelot, Doom/2, Driver 2, and some others. I'm working out a new self modifying code handling scheme to try to alleviate it some (or a lot, hopefully). The work is more in the front end of the recompiler (the portable part) than the backend (the part that's specific for PSP, GP2X, PC, etc) so the changes should propogate to all versions with dynarecs.
Tobriand
Well-Known Member
Ok, I'm back from France - was amazing. Managed to borrow a thumbdrive yesterday and upgrade to 9007 for the trip (didn't see 9008), so this could be out of date, but maybe not for those of you with random freezes. I may have found the culprit! Or rather, Zod identified it a bit tacitly, and it worked like a charm.
The first time I used 9007 everything worked fine and looked lovely. Brilliant brilliant release, and pretty much everything running silky smooth for me at 265MHz. However, come back to it this morning, and I had the following symptons:
1) Savestates wouldn't load. They did, however, save accurately still.
2) Every game developed a tendency to freeze randomly. Each freeze could happen at anything after about 5 seconds into a game, but might take a while - I managed 10 mintues on Klonoa before it died. This was NOT overclocking related; the freezes were just as likely at 240MHz, and I'd been playing on the train for hours at 265MHz earlier that day with no issues (on v9004).
So, what went wrong? Remember the config file Zodttd said he didn't include? Well, having browsed through here in the Heathrowe departure lounge to see if anyone had come across a fix, I notice this and wiped the main config file and Pokemon Emerald's (my main game at the moment). Result? No more crashes, and the savestates work once again.
Why does this happen? It's directly related to whether sound is on (with sound off, things go weird again), and the audio buffer (if anything other than 2048, crashes happen, savestates don't load). More than that I don't know.
So to reiterate: DELETE ALL YOUR CONFIG FILES and see if you still get crashes. And don't forget that they're saved per-game as well...
On another note, there's a bug in the way savestates are listed in 9007. If you use the savestate options dialogue, it seems that after you've loaded, there's a bias of +1 to the number and picture displayed. I've not investigated this properly yet, nor overwritten anything I don't want to yet, but I did load the wrong savestate repeatedly for a bit before I worked out what was happening!
The first time I used 9007 everything worked fine and looked lovely. Brilliant brilliant release, and pretty much everything running silky smooth for me at 265MHz. However, come back to it this morning, and I had the following symptons:
1) Savestates wouldn't load. They did, however, save accurately still.
2) Every game developed a tendency to freeze randomly. Each freeze could happen at anything after about 5 seconds into a game, but might take a while - I managed 10 mintues on Klonoa before it died. This was NOT overclocking related; the freezes were just as likely at 240MHz, and I'd been playing on the train for hours at 265MHz earlier that day with no issues (on v9004).
So, what went wrong? Remember the config file Zodttd said he didn't include? Well, having browsed through here in the Heathrowe departure lounge to see if anyone had come across a fix, I notice this and wiped the main config file and Pokemon Emerald's (my main game at the moment). Result? No more crashes, and the savestates work once again.
Why does this happen? It's directly related to whether sound is on (with sound off, things go weird again), and the audio buffer (if anything other than 2048, crashes happen, savestates don't load). More than that I don't know.
So to reiterate: DELETE ALL YOUR CONFIG FILES and see if you still get crashes. And don't forget that they're saved per-game as well...
On another note, there's a bug in the way savestates are listed in 9007. If you use the savestate options dialogue, it seems that after you've loaded, there's a bias of +1 to the number and picture displayed. I've not investigated this properly yet, nor overwritten anything I don't want to yet, but I did load the wrong savestate repeatedly for a bit before I worked out what was happening!
Elektranox
Well-Known Member
- Joined
- Dec 3, 2005
- Messages
- 1,805
- Age
- 34
- Location
- Oldenburg, Germany, Earth
- Website
- elektranox.dyndns.org
Blah posted on Mar 19 2007 at 12:16 AM said:
as far as I know, the linux version has no debugger?!
Last edited by a moderator:
reiboul
Peace sells... but who's buying?
Tobriand posted on Mar 19 2007 at 05:36 PM said:
Glad you liked my country
laetst build is .9008, I think Zod added some sync(). I have no problem with SRAM or savestates with the latest version. I also experience crashes, but very few and random. I don't play many different games, though.Take care with config files : some holds SRAM saves, and you may lose your saves
h34r:Zod is taking random crashes as a priority
(What about a GP2X Hero status? B) )
Last edited by a moderator:
Tobriand
Well-Known Member
Meh. Deleting the respective ones didn't get rid of the sram and did solve my problems, so hey. Probably worth making a save-state before doing so though, if it could result in weird results...
Amazing emulator, as ever
Amazing emulator, as ever
Burbruee
Member
Elektranox posted on Mar 19 2007 at 05:42 PM said:
Have you tried the winversion through wine?
Last edited by a moderator:
Elektranox
Well-Known Member
- Joined
- Dec 3, 2005
- Messages
- 1,805
- Age
- 34
- Location
- Oldenburg, Germany, Earth
- Website
- elektranox.dyndns.org
Burbruee posted on Mar 19 2007 at 07:31 PM said:
jepp, there was an non existing *.dll. I downloaded it from the inet and retried - nothing happend (but CPU was hat 100%, I killed the process after ~ 2 min).
Last edited by a moderator:
Tobriand posted on Mar 19 2007 at 04:36 PM said:
I think you're on to something here!
I had v9006, and I was experiencing crashes.
I updated to v9008, and deleted the config file as Zod said, but kept the v9006 launcher on my gp2x.
When I noticed that v9008 was really slow, I started using v9006 again, but I noticed that it no longer crashed. Before I read Tobriand's post, I didn't realise that the point from which it didn't crash was from when I deleted the config file.
Btw, I'm also working through Emerald at the moment
Last edited by a moderator:
Elektranox
Well-Known Member
- Joined
- Dec 3, 2005
- Messages
- 1,805
- Age
- 34
- Location
- Oldenburg, Germany, Earth
- Website
- elektranox.dyndns.org
btw.: For all, who are not reading the blog - exophase will try to optimize the code the next weeks
Tobriand
Well-Known Member
Ok, updated the compatibility list for POkemon Leaf Green, Vrally3, Motoracer, and Klonoa. And Quiddich world cup, which fails badly in game
I think you might be right about this. Another option is to update (replace) the config file by altering frame skip or something like that (the emulator generates a new config file AFAIK).Tobriand posted on Mar 20 2007 at 03:36 AM said:
Anyway, when my config file is replaced it seems I get no more crashes. I have been playing for hours on different games that used to give me random, infrequent crashes.
Last edited by a moderator:
zodttd
Solving your premature emulation since the Tapwave
Sorry for the lack of replies lately. I spoke to Exophase and we agreed to let him handle the dynarec until March 31st. Basically we decided he should work on it for the next two weeks and see what we land up with. It should be very impressive but there's never a sure thing with this stuff. So while there may be little news until he gets his dynarec based off mine, up and running, a lot is going on with this project.
Anyone need some help with some things in the meantime? I havent caught up with the thread yet. I can say that translation gate optimizations aren't worth the time invested to figuring them out as they may be removed from future versions. I might be able to get us an x86 version of gpSP that will assist in finding idle loops though!
So not much news yet, but definitely some good news coming...
Anyone need some help with some things in the meantime? I havent caught up with the thread yet. I can say that translation gate optimizations aren't worth the time invested to figuring them out as they may be removed from future versions. I might be able to get us an x86 version of gpSP that will assist in finding idle loops though!
So not much news yet, but definitely some good news coming...
That's fantastic news, Zod. Hopefully some of the people who donated to you will also show some love to Exophase (if they haven't already).
What did you think of Tobriand's possible solution to stop random crashes? (Basically renewing the config files of every game). I have found that I get no more crashes since doing this (several hours game time).
But I do have to use a slightly lower overclock than on other emulators.
Hopefully some of the people who donated to you will also show some love to Exophase (if they haven't already). What did you think of Tobriand's possible solution to stop random crashes? (Basically renewing the config files of every game). I have found that I get no more crashes since doing this (several hours game time).
But I do have to use a slightly lower overclock than on other emulators.
Anonelbe
Still Fresh
imhotep posted on Mar 20 2007 at 12:03 PM said:
Same here... so far I didn't get any crashes after deleting the config files, first time I've been able to clear a map in Advance Wars without freezing. Can anybody else confirm this works?
Last edited by a moderator:
Tobriand
Well-Known Member
Ok, here's another bug. Transparency in 3D. It doesn't happen a lot of the time. Good examples? Lens flare in Super Monkey Ball Jr., Tokyo Xtreme Racer Advance name entry screen. Lots of other similar games, but can't remember them at the moment...
Oh, and there's a really serious amount of rippling that goes on in Pokemon Emerald when you're inside and walking slowly up or down. I don't know if that is my LCD or the emu being a pain. Pay attention to finely textured objects (e.g. the design on the table) to see it go particularly weird...
Oh, and there's a really serious amount of rippling that goes on in Pokemon Emerald when you're inside and walking slowly up or down. I don't know if that is my LCD or the emu being a pain. Pay attention to finely textured objects (e.g. the design on the table) to see it go particularly weird...
Exophase
Nothing good will ever come of Exophase.
Tobriand posted on Mar 20 2007 at 05:54 PM said:
I never implemented color effects in modes 3-5 (the extended rotation frame buffer modes, most 3D is done in this). Mode 4 is a matter of getting around to it, modes 3/5 are likely to not happen because the different color format doesn't go well with the way I handle compositing. Almost all games should be using mode 4.
Tobriand posted on Mar 20 2007 at 05:54 PM said:
I don't know what you mean by "rippling", but this is probably the LCD and/or lack of vsync, something along those lines. I doubt it has anything to do with the rendering in the emulator.
Last edited by a moderator:
ydderf45
Member
tmnt runs good on this emu
