Gpsp 0.9-2xb

[fusion_power]

Well, I only save so often, because I fear a crash. I always have the "luck", the crashes happen on critical ingame points. But I can play the game(s) 2 hours to without any crash. It's a true "random" function this crash-feature :lol:
I play with ram-tweaks, 266MHz and 2048k Sound buffer (other values glitch the sound to often) Auto Frameskip 2 by the way. But even with this, my last boss fight in BG was really slow (this big fat beholder thing at the end of act 1 )
Now I'm in Act 2 on a Ice Mountain and besides this stupid inventory graphic bug everything is fine.

 

[Zeladin]

2048k Sound buffer (other values glitch the sound to often)

Hmm, I found the 4096 setting gave me better stability, I was able to play a set of batteries flat on that. It didn't notice glitchy sound, maybe thats related to ram tweaks or the clock setting? I was running on a straight 250mhz.

there is a little but important ingame GFX bug: weared Items are not green highlighted so you can't see,

I noticed those graphical problems too, it goes all garbled as you bring up the inventory, and no transparency on your wargear - real annoying when dealing with your jewellery. Still it was good fun, I played an archer, and the biggest problem I had was running circles round the bosses - that stupid stick kept jamming! At 250mhz I was able to switch off FS and get an even 60fps mostly... Auto frameskip actually reduced the number of frames generated...I think.

 

[fusion_power]

Hm... I'm sure 266Mhz runs not worse than 250MHz. And I think tweaking the RAM is not a baad Idea to but someone may correct me If I am wrong in this point. We all know gpsp is a little bit special.
But I will try manual FS instead of Auto. Can bring more I know from playing Metroid.
Besides, I had trouble with running tight circles to, when I found out thats the way to beat the first big boss...thank good I could quickload so often without crashes.
It was the FIRST time ever I was not satisfied with the GP2X stick... :blink: I hope I'm not turning into a 2. DaveC now... ^^"""

Well @ Exophase: please check, if this Inventory gfx-bug in Baldurs Gate can be fixed. In VBA it's working correctly with the same Bios for example...if this say something...

 

[slaanesh]

Here's a GREAT game to try:

Ninja Five-O (U) (A.K.A. Ninja Cop (E))

What a great game! Fantastic music and amazingly cool graphics and wonderful game-play to boot!

Try it... Now!

 

[Exophase]

Hm... I'm sure 266Mhz runs not worse than 250MHz. And I think tweaking the RAM is not a baad Idea to but someone may correct me If I am wrong in this point. We all know gpsp is a little bit special.
But I will try manual FS instead of Auto. Can bring more I know from playing Metroid.
Besides, I had trouble with running tight circles to, when I found out thats the way to beat the first big boss...thank good I could quickload so often without crashes.
It was the FIRST time ever I was not satisfied with the GP2X stick... :blink: I hope I'm not turning into a 2. DaveC now... ^^"""

Well @ Exophase: please check, if this Inventory gfx-bug in Baldurs Gate can be fixed. In VBA it's working correctly with the same Bios for example...if this say something...

I haven't implemented color effects in the framebuffer modes. That's probably what it is.

 

[slaanesh]

@ Exophase:

Just wondering if gpSP does any 8-bit CLUT -> 16-bit color conversions?

PalmMAME was recently updated to include ARM assembler versions of this code to help speed up graphics rendering. This was useful as all graphics are stored as 8-bit CLUTs but always need to be converted to the PALM's 16-bit color only screen.
PalmMAME achieved some nice speed ups swapping this 'C' code out and using the assembler versions instead.

Would gpSP see any benefits here?

 

[DaveC]

Is there any idea yet as to what causes the random crashes? I would hope this could be fixed. Even if it never got any faster, fixing the crashes would really improve the useability of the emu.

 

[___]

true... i think this should be number one on the todo list.

 

[imhotep]

Is there any idea yet as to what causes the random crashes?

I think this will be hard to diagnose as some people don't seem to get them at all. Some people get them rarely and some more commonly.

 

[greenmikey]

Random crashes..I tried to put together something to find out why people are getting random crashes pages back but it was shot down as a waste of time becasue the person didn't get crashes with whatever settings.

I don't get crashes anymore and I'm not sure why exactly, but I like it.

 

[sand_man]

Is there any idea yet as to what causes the random crashes? I would hope this could be fixed. Even if it never got any faster, fixing the crashes would really improve the useability of the emu.

It's the only thing that's stopping me from using it now.

 

[Exophase]

@ Exophase:

Just wondering if gpSP does any 8-bit CLUT -> 16-bit color conversions?

PalmMAME was recently updated to include ARM assembler versions of this code to help speed up graphics rendering. This was useful as all graphics are stored as 8-bit CLUTs but always need to be converted to the PALM's 16-bit color only screen.
PalmMAME achieved some nice speed ups swapping this 'C' code out and using the assembler versions instead.

Would gpSP see any benefits here?

No, something like that isn't useful because the conversions only occur when the palette is written to (which in the grand scheme of things isn't often), they're stored natively as 16bpp after that.

To everyone talking about crashes, there really isn't anything I can do about it until someone can reliably reproduce it. Until then I recommend deleting your .cfg files because they might be getting corrupted (I had constant crashes once, until I deleted them, and this basically came out of nowhere). Or it could be cache related, I really don't know.

Also, run it over telnet to see what kind of crash it is, if the system just dies or if it's a segfault. I got segfaults.

 

[fusion_power]

I have no clue about Telnet so all I can do is play GPSP, fear the crashes and watch, when they happen. I can't have a config problem because The games I play are new on my GP2X so no old rom-cfg's exist and I had deleted the GPSP- standard -cfg of course.
Like I sayed before, the crashes are absolutely random. Ok, I had a reproducable series of crashes, when I want to load a Savegame in Metroid but after some resets, this was gone to. (GP2X need his 15-30 Seconds to lose his Ram-content until he can turned on again I think so I shouldn't instant turn OFF/ON this Thing.

I mentioned only another phenomenon: Many games "Hangs" for some miliseconds, maybe reloading stuff, graphic, music... I don't know. Maybe these are the points where crashes can be happen?

 

[Zeladin]

QUOTE
To everyone talking about crashes, there really isn't anything I can do about it until someone can reliably reproduce it. Until then I recommend deleting your .cfg files because they might be getting corrupted (I had constant crashes once, until I deleted them, and this basically came out of nowhere). Or it could be cache related, I really don't know

My gaming has been far more stable after doing these things.

@fusion_power; I think Exophase is saying that starting from a clean sheet, your cfg's may be liable to become corrupted, so if suddenly experiencing lots of crashes deleting them can help - maybe.

I think the savestates are unstable as well, I had problems loading up some a few times (luckily I use about four in rapid succession so I hadn't lost too much progress). Is it possible there is something dodgy with writing to the Sd card?

I might try doing some rigorous bug testing, maybe try narrow down the environments in which a crash occurs - it can of course take several hours - this could be really tricky to nail down. I know how to telnet into my Gp2x so I'll maybe give that a shot over the next few weeks, once I figure out how to reliably crash it... I can understand the whole "hands up" feeling.

@Anyone; I wouldn't let the spurious crashing put you off, the more people playing and recording crashes the more likely we find out what's up. It can definitely be stable enough to get a good gaming experience, either that or I have a fluke Gp2x (Which would suggest HW/FW at fault ).

 

[DaveC]

To everyone talking about crashes, there really isn't anything I can do about it until someone can reliably reproduce it. Until then I recommend deleting your .cfg files because they might be getting corrupted (I had constant crashes once, until I deleted them, and this basically came out of nowhere). Or it could be cache related, I really don't know.

Also, run it over telnet to see what kind of crash it is, if the system just dies or if it's a segfault. I got segfaults.

How about the cyclic losses of framerate that I mentioned a while back? Do you have any idea of what causes it or how to fix? In almost all games I try it will suddenly start skipping alot of frames for no reason (even does it on animated title screens when nothing is going on) then recover back to normal for several seconds then it will start skipping again. It is very regular too, the invervals don't seem to change much. It will continue to do this no matter what game or what it is doing. It may be a bug in the autoframeskip? I use FW 2.1.1 and run at 240 MHz.

 

[Jaguarandine]

To everyone talking about crashes, there really isn't anything I can do about it until someone can reliably reproduce it. Until then I recommend deleting your .cfg files because they might be getting corrupted (I had constant crashes once, until I deleted them, and this basically came out of nowhere). Or it could be cache related, I really don't know.

Also, run it over telnet to see what kind of crash it is, if the system just dies or if it's a segfault. I got segfaults.

Has anyone beat Circle of the Moon with Gpsp 0.9-2xb? If not, maybe I can help. Using version 2xa, everytime I faced Dracula, the game freezed. Or rather, it would always freeze randomly against him at least, but when I did the super jump, it would freeze instantly.

 

[mamewarrior]

QUOTE
I have no clue about Telnet so all I can do is play GPSP, fear the crashes and watch, when they happen. I can't have a config problem because The games I play are new on my GP2X so no old rom-cfg's exist and I had deleted the GPSP- standard -cfg of course.
Like I sayed before, the crashes are absolutely random. Ok, I had a reproducable series of crashes, when I want to load a Savegame in Metroid but after some resets, this was gone to. (GP2X need his 15-30 Seconds to lose his Ram-content until he can turned on again I think so I shouldn't instant turn OFF/ON this Thing.

I mentioned only another phenomenon: Many games "Hangs" for some miliseconds, maybe reloading stuff, graphic, music... I don't know. Maybe these are the points where crashes can be happen?


I think you missed the point Exophase was making here.

As a developer, bug reports which are vague (i.e. "crashes are absolutely random") are usually of little help in debugging a system and getting it to work. I think Exophase would benefit more if you mentioned OC speeds, firmware, loaded rom, config, game location, etc. If this seems to be of no relevance then its probably best to leave Expohase and any devs to find the problem for themselves.

If you manage to find any consistant way of making gpsp crash then this gives Exophase something to work on.

 

[Creature XL]

First to the random crashes:
I just had it ONCE, and that was when the soundbuffer was set to 2048. I didn't changed it on purpose :-O. After resetting it to 4096, the same game works, as all other I am playing, without crashes.
FW: 3.0.0,
CPU: 240MHz (I set it with the annoying program which runs before gpSP to 238MHZ)
RAM: I don't change the settings.


Second, compilation of gpSP failes for me. To be more precise: The compiled code gives me just a black screen. Is there anything I missed out? Its the second program after the SDL-Testprogram I have compiled with the cross-dev toolchain ( I using the one from open2x, cause I didn't managed to incooperate the HW-SDLlib with the devkitPro-gp2x). So I am not too familiar with possible oodities of GP2x coding.


salut,
creature

 

[Zeladin]

Well for a start I only get that cyclical frame stutter when I have Autoframeskip on, standing in one place, I'm almost certain it shouldn't do that... Exophase already mentioned that that might be a source of issues I think.

Definitely something unstable about the savestates too, doing a bunch of saves, loading at state then, going to game, loading a new state, and again gave a black screen... I just figured out the problem there. If the audio buffer is set to 2048 and I try loading a save where the audio buffer was set to 4096, it black screens - maybe, it worked twice in a row.. and now it won't, strange. Anyway major point a savesstate that gives a black screen may not be irrecoverable. I was able to successfully load a state after it crashing the Gp2x to BS four times!

Ahhh! It doesn't always load the right state!!! Some thing is wrong there, I load up the same state twice in a row and it loads up the previous state instead... No its even weirder, I have no idea whats going on, but its like some variable isn't being reset or something... That might just be a bug in the front end I would suspect.

Can anyone report a crash that definitely occurred with autoframeskip off, because I suspect it could be a source of crashyness - I'm almost certain its not working as it should... I still haven't managed to reproduce a crash other than the new buggyness I've found...

What was changed since v9008 perhaps it would be easier to reimplement some of those changes, a bit at a time? But don't look at me, the most complicated thing I've had to debug is a scientific calculator in C using a console - so I probably don't really know what I'm talking about...

I'm going to try a clean run at this, on a completely compatible 1gb sd card, just starting with a rom and the bios. I had the most crashes before I did anything to try and stop them.

Edit; Hmm I notice the latest release version doesn't have a roms folder, and yet I have a roms folder on my Gp2x. This shouldn't affect it in anyway surely?

 

[DaveC]

Well for a start I only get that cyclical frame stutter when I have Autoframeskip on, standing in one place, I'm almost certain it shouldn't do that... Exophase already mentioned that that might be a source of issues I think.

Isn't the autoframeskip the ideal thing to use (other than the cyclic stutter) though? I found manual causes alot of slow-down at certain points in a game. I suppose if you are lucky enough to OC to 270 MHz or so then it is not as much of an issue. For those that can't auto seems the best.