I did notice that, but chose to ignore it. But for the future you should learn to curb your impatience.
Originally Posted by Asterix
Just because the right person, with the info you need, does not happen to log in and reply for some time after your question, does not mean that you are being ignored.
When specifying your PS2 type, always include the product code.
But now you gave really good replies but Northbear is right I did not present full stats.
I got v11 PS2 (it's rare and not a slime version)
Think it's speciall european version.
(Like SCPH-39004 for my european v7 PS2, or SCPH-77004 for my v15 PSTwo.)
The preferred abbreviation is "uLE" rather than "uL".
I have the latest FMCB and 4.39uL
The emulator core of these is identical. It is just the ROM browser that has been hacked for different functionality. Unfortunately we have no source code to work with for this program.
Original Sony 8MB.
USB is and MAX drive. Got it with ARMAX
I have been testing with both the USB and hdd2 versions of the elf. Think it was similar result.
That is what the SRAM was for, in an original SNES.
Ok trying to see if I have gotten this right.
I first have to make an in game save to use SRAM if its possible to use SRAM?
Saving progress of a game to battery-backed static RAM, for future reloading.
The difference with an emulator is only that it can save this SRAM to separate files.
That is the purpose.
I think I get that Save game state saves everything.
A full minute seems a bit long, especially for an 8MB MC. But OK I guess...
So it's like this I have tested SRAM and it starts to save I guess and it takes about a minute to save.
That's perfectly normal, since the SRAM is not normally 'interactive' with a SNES game. But if you play an RPG, for example, and go to a savepoint where you can do in-game saving or loading, then you will notice that the visible saves (in the in-game save menu) will depend on what SRAM file you loaded. But this also assumes that you are moving the SRAM files externally between attempts (like with uLE FileBrowser), since the filename used will always be the same for a given ROM. So you can not switch between two different SRAM files for the same ROM in a single emulation session.
When I try to load the SRAM nothing happens.
Also, if the emulator finds a matching SRAM file when starting a ROM, then that SRAM file will be loaded automatically, so normally you never need to use the explicit load command for it. (Unless you had the wrong MC in, and swapped that for the right one in mid-session.)
Again, that sounds much to long for normalcy.
When I make the save game state it takes pretty much 6 minutes to save.
Did you really time this, or is it just how long it 'felt' to you ?
The latter is the bug I told you about, where the save command returns instantaneously, and you are correct in assuming that nothing was saved then. And once that bug has struck it will remain active for the remainder of the session. You must reset the console to get rid of it, meaning that the current in-game progress is doomed to be lost. (A good reason to save often, so as to minimize possible losses.)
I can get two symptoms for next save either it will start to save for 6 minutes again and after loaded save state I wont return to the last Save but to the very first or it it will make an really fast "Save" for like a second meaning you just press the button on the save game state and nothing starts to save I guess.
The former problem, where saving time is the same as when it worked, and it still doesn't seem to update the save file, that is a brand new problem to me. I never heard of it nor experienced it myself.
Again, that is something I've never seen or heard of, so I can say nothing conclusive about it. Are you sure that this is a permanent freeze, and not just your impatience with the file-write delay causing you to believe it froze ?
There is just one anoying thing more; when I enter options in snesstation and want to quit it just freezes. Initially I thought that I could have some space problem so I cleaned out some old saves on the MC but that didn't help a bit.
Exit from the option menu always means that the program must resave its settings file on MC, and if your reports on timing are correct for other such operations above, your MC seems unusually slow. (Very unusual for Sony original MCs.) So you might have mistaken the temporary 'freeze' in menu response for a real freeze-up, and reset the console just before that 'freeze' would have ended with the emulator going back to the ROM browser (like it always does for me).
Eh ? What ROM ? You didn't mention any specific ROM before.
Just to mention I have both the European and the US version of the rom in the same folder.
I have lots of ROM files in some of my ROM folders, including duplicate versions of some games (differing in regions, release versions, patches etc). That is not a problem as long as each ROM file has a distinct name.
It might, but I can't see exactly how.
Does that have anything to do with the problem?
One problem I already mentioned is if similar ROMs have similar names, differing only in characters beyond the first 27. That will cause problems as different ROM files will then be using the same SRAM and saved state files, and the data in those files will probably be compatible only to the ROM file used when making the save. Launching another similar-named ROM may cause unknown in-game bugs due to incompatible SRAM, and loading a saved state file may then even crash the emulator as the emulator variables loaded may not fit the current ROM.
Other potential problems are of course that some ROM files may be faulty, or just happen to be incompatible to this emulator. (No emulator supports all existing SNES 'mappers' perfectly.)
Helping each other is all that these forums exist for, though it may occasionally take some time to 'connect'. (One of many reasons why we should always try to be patient with each other.)
By the way thanks!
Best regards: dlanor