Squidgesnes 0.34

[deadlychicken22]

FrankenSNES 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

 

[DJprocyon]

Does the sound adition affect games' fps that much? Has anyone noticed anything?

This is great news.

​

Yeah, for me, it's now slower than SNESGP2X. But I can save my games now, so I'm not really that fussed!

 

[DJprocyon]

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]

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?

 

[DJprocyon]

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!

 

[Squidge]

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

​

Placed them in the same directory as the executable with the filename being <romfilename>.srm - eg. mario.srm

 

[EvilDragon]

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]

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

 

[Squidge]

you didn't put the executable in a directory?

EDIT: Hmmm, you lot seemed to have killed my website 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.

 

[Zero3K]

DA = Download Accelerator
FDM = Free Download Manager

 

[FluffyPanda]

Heh, you don't get those kinds of numbers on many sites

Firefox for teh win!

 

[pkostrze]

This is an excellent improvement... it actually runs a tad fast for me now. I can now play Castlevania: Dracula X while out and about. Kudos!

 

[kingconga42]

first of all, great job with this release, squidge!

is there a way to lower the volume yet? it's super loud.

 

[Squidge]

Try what other people have suggested - adjust the sound in the music player (or whatever it was, I forget).

 

[subin]

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]

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]

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]

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]

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]

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