Squidgesnes 0.34


deadlychicken22

Man is a reasoning rather than a reasonable animal
Joined
Mar 18, 2004
Messages
1,501
Location
MN, USA
Website
Visit site
FrankenSNES :D I like it !

As for SRAM, currently it saves the SRAM ~30 seconds after the snes has finished modifying the SRAM, so if you save your game and then immediately quit, chances are the SRAM is updated but not written to the SD card yet. I intend to change this to be more configurable - the 30 second wait will still be there, but it'll only save once every 5 minutes or so, or when you exit back to the menu (in which case the 30 second wait doesn't apply).

Personally I find savestates a lot easier, even though they are cheating slightly - but hey, you have to have some fun :)
Where do you put regular .srm saves in order for them to be loaded if I am using /roms/snes as my roms directory?

BTW, thanks for the awsome emu
 
Last edited by a moderator:

DJprocyon

Still Fresh
Joined
Dec 26, 2005
Messages
33
One thing though, I'm having no trouble saving games (I make it a matter of principle to exit an app and wait a few secs before powering off my GP, as it can have some nasty consequences with Quake (I.E. corrupting your savegame and rebinding all your controls :angry: ), but for some reason I CAN'T GET ANY SOUND!! (Ironic or what?)
The only thing I can think may be amiss is that I'm running 1.0.1 firmware, but I don't wanna upgrade unless really necessary, as I have mortal GP-Brick-fear :unsure:
Anybody get the same? Or even better, know a solution??
 

deadlychicken22

Man is a reasoning rather than a reasonable animal
Joined
Mar 18, 2004
Messages
1,501
Location
MN, USA
Website
Visit site
One thing though, I'm having no trouble saving games (I make it a matter of principle to exit an app and wait a few secs before powering off my GP, as it can have some nasty consequences with Quake (I.E. corrupting your savegame and rebinding all your controls :angry: ), but for some reason I CAN'T GET ANY SOUND!! (Ironic or what?)
The only thing I can think may be amiss is that I'm running 1.0.1 firmware, but I don't wanna upgrade unless really necessary, as I have mortal GP-Brick-fear :unsure:
Anybody get the same? Or even better, know a solution??
happened to me the first time I tried it, i turned my gp2x off, waited a couple seconds, then turned it on again and it worked fine.....

Where do you put your .srm files for it to load up regular saves?
 
Last edited by a moderator:

DJprocyon

Still Fresh
Joined
Dec 26, 2005
Messages
33
One thing though, I'm having no trouble saving games (I make it a matter of principle to exit an app and wait a few secs before powering off my GP, as it can have some nasty consequences with Quake (I.E. corrupting your savegame and rebinding all your controls :angry: ), but for some reason I CAN'T GET ANY SOUND!! (Ironic or what?)
The only thing I can think may be amiss is that I'm running 1.0.1 firmware, but I don't wanna upgrade unless really necessary, as I have mortal GP-Brick-fear :unsure:
Anybody get the same? Or even better, know a solution??
happened to me the first time I tried it, i turned my gp2x off, waited a couple seconds, then turned it on again and it worked fine.....

Where do you put your .srm files for it to load up regular saves?
Argh, my mistake actually... I powered off my machine and now it doesn't load the SRM at all! Awch well, I can live with savestates.
Thanks for the advice on sound though, that worked like magic! :D
 
Last edited by a moderator:

EvilDragon

Administrator
Staff member
Joined
Mar 4, 2003
Messages
29,513
Age
42
Location
Ingolstadt
Problems with saving?
It's most probably the drive cache.

Open up sterm and type "sync" (or create a shell script that does that) and run it after you saved in any program before you turn your gp2x off.
 

Ando

Member
Joined
Dec 27, 2005
Messages
193
Location
DE
Website
Visit site
squidge would you by any chance make it so that the savestates are sent to a folder titled "save" they are cluttering up my card and it would be much appreciated :D
 

Squidge

Certified Guru
Joined
Nov 16, 2003
Messages
8,495
Location
UK
Website
Visit site
you didn't put the executable in a directory?

EDIT: Hmmm, you lot seemed to have killed my website :eek: and the only file hosted there was squidgesnes.zip :) Apparently, it was creating too much traffic, so you'll have to get your fix from the gp32x file archives for the next 24 hours until they allow file downloads again.

I did get a nice free usage report though, which includes browser's used to access the page:

1 4318 61.05% Mozilla/5.0
2 1892 26.75% MSIE 6.0
3 321 4.54% Opera 8.5
4 86 1.22% MSIE 5.0
5 67 0.95% Opera 9.0
6 65 0.92% DA 7.0
7 49 0.69% Googlebot/2.1
8 37 0.52% Konqueror/3.5
9 28 0.40% Opera 8.0
10 27 0.38% Konqueror/3.4
11 21 0.30% Download Master
12 19 0.27% MSIE 5.5
13 17 0.24% FDM 1.x
14 11 0.16% Avant Browser (http://www.avantbrowser.com)
15 9 0.13% Googlebot/2.1 (+http://www.google.com/bot.html)

It seems like most of you really like Firefox and the like. I've no idea what DA or FDM are though.
 

Squidge

Certified Guru
Joined
Nov 16, 2003
Messages
8,495
Location
UK
Website
Visit site
Try what other people have suggested - adjust the sound in the music player (or whatever it was, I forget).
 

subin

Member
Joined
Jan 3, 2006
Messages
326
one thing i noticed immediately was that the bottom portion of the emulated screen flickers grey quite a lot. this happens unless i turn on vsync.. which i assume takes up more CPU cycles. btw, i am using the alternative .gpe file you released to stop the problem where some of the screen wasn't showing.

does everyone else get this?
 

Squidge

Certified Guru
Joined
Nov 16, 2003
Messages
8,495
Location
UK
Website
Visit site
without vsync turned on, the screen buffers will be swapped before vsync is reached, so a portion of another frame may be rendered by the lcd hardware as it doesn't update it's address until vsync. This will completely depend on how fast the game is going - the higher the fps, the more chance of flicker.

With vsync turned on, it wait for the lcd hardware to reach a point on the screen that is not visible (the vertical synchronisation period) before swapping the buffers. However, this means the lcd hardware is running at 60fps which gives roughly 17ms for each frame. If an emulated frame takes 20ms (50fps), it will have to wait until the next vsync, which will mean an actual frame time of 34ms, which gives 29 fps - losing you 20 fps.

The way I intend to work around this is to implement a quadruple display buffering system on the other processor and limiting emulator speed to 60 fps. This means that each frame is simply placed into a circular buffer, and the second processor decides when to pull out the next frame based on the vertical sync interrupt coming from the lcd hardware.
 

Minkoff

Member
Joined
Oct 18, 2005
Messages
212
Are you going to have to have the 2nd CPU on for that? Would that use alot of power, or no?
I thought you mentioned in the dev forum that you wanted to control when the LCD refreshes yourself. Is that not possible?
 

abigsmurf

Member
Joined
Apr 4, 2004
Messages
436
I think way to do it would be to store each complete frame in a buffer of it's own, the frames are rendered as normal and as soon as any frame is fully drawn it's put to this this frame and whenever the LCD asks for something to draw it looks to that one rather either drawing something incomplete or waiting for the next frame. I think this way you only get an occasional dropped frame rather than dropping every other.

That said I hated frame buffers at uni so god knows if I'm right...
 

Squidge

Certified Guru
Joined
Nov 16, 2003
Messages
8,495
Location
UK
Website
Visit site
The problem is that since we are running on top of Linux, we can only poll the LCD hardware to see if we are in the vsync, and without doing that in the middle of the emu (sapping valuable time) we can't tell when the LCD asks for something to draw - it's all taken care of by Linux. My plan was to rob Linux of it's valuable vsync interrupt and redirect it to the other processor, where we have full interrupt access, and get that one to do the buffer stuff. If we used a quad (or probably triple would do too) buffering system, the LCD would always draw the frames faster than the emu could draw them, so it would mean no frames dropped and no incomplete frames drawn (as if the buffer is empty, we can simply redraw the last one).

This would cause an extremely minimal work load for the 940, very little memory bus access (there would be no data copying) and therefore hardly any interruptions to the 920 - the 940 could sit in sleep for most of it's time until it's waken up by an interrupt.

Minkoff: No, that's not possible. The way the system is designed means that it just slowly blanks the display until there's a constant feed of data.
 

subin

Member
Joined
Jan 3, 2006
Messages
326
minkoff? all this sounds like great use of the hardware squidge. i hope you can implement something. i'll probably be sending some donations round soon :D
 
Top