einstein95 / vba-wii

Automatically exported from code.google.com/p/vba-wii
2 stars 0 forks source link

SRAM and Snapshots are written but cannot be read #53

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
What steps will reproduce the problem?
1. Load a game (tried FFTA, Fire Emblem, Zero Mission) and save your game 
and/or make a 
snapshot
2. Attempt to load snapshot or SRAM

What is the expected output? What do you see instead?
I expect it to succeed and allow me to load my game in-game or setup the 
snapshot as it was 
saved.  Instead I see "Error loading file! Press A to continue" followed by 
"Save file not found Press 
A to continue" for loading SRAM, similar for loading snapshot.

What version of the product are you using?
1.0.6 on Wii

Please provide any additional information below.
I'm using an SD card.  Everything works fine except loading these files, they 
are actually written 
out to the sd card and they aren't 0 length or anything like that but the 
emulator cannot read 
them.

There is no problem with the SD card it's verified and all of this was 
reproduced before and after 
a clean format with fat32.

It might be worth noting that while in the game, if I save then reset I can 
load my save (in FFTA, 
at least)  However, if I reload the rom or load it fresh from a fresh startup 
of VBA, then it fails to 
find the files.

Original issue reported on code.google.com by zacheryj...@gmail.com on 4 Jan 2009 at 1:38

GoogleCodeExporter commented 9 years ago
[deleted comment]
GoogleCodeExporter commented 9 years ago
I can't reproduce this, seems to work fine for me. remember that in games SRAM 
saves 
only let you save at savepoints, but snapshots should work all the time.

Original comment by dborth@gmail.com on 6 Jan 2009 at 7:53

GoogleCodeExporter commented 9 years ago
Yes I know I am not an idiot. Just because you can't reproduce a bug does not 
mean it is "Invalid." If we 
handled our difficult-to-reproduce bug reports this way we would have gone out 
of business in the first year. 

If you actually read the report you'll note that I said the files are where 
they should be, written by the 
emulator. It is only when the emulator tried to read them that it can't find 
the files. I tried changing casing of 
the directory names and removing the space I had in the SD card name as if that 
had any impact. I tried 
running off USB but I don't think that worked at all. In the last couple 
attempts I started to notice messages 
stating that the SD card couldn't be found when trying to choose a rom then 
when I try again it works. 

Looking at some of your other bugs you have ignored it seems like this app or 
one of it's dependencies has 
broken SD access code. The Wii itself never has trouble using my card. It is a 
2GB card, perhaps that is 
relavent?  Excite Truck plays music off the card, no sweat...

So instead of jumping to the wrong conclusion that the report is invalid you 
should instead, use what you 
know about the code and it's libraries to probe for more useful information. 
Unless you don't care if your 
project displays any competency in working with its users as beta testers...

Original comment by zacheryj...@gmail.com on 6 Jan 2009 at 8:20

GoogleCodeExporter commented 9 years ago
I decided I wanted to play these games on my Wii bad enough that I'd give 
debugging this problem another 
shot.  

I found out what the issue is.  And it's trivial to reproduce.

Apparently, somehow unbeknownst to me, my rom files all got a space prepended 
to their name so they were 
all named something like " Game Name.gba"  and " Game Name.gb"  with that 
leading space there.

The interesting thing, then, is that the emulator writes the save files using 
the same name as the game, 
however, it apparently strips leading spaces because those files did not have 
the space.  But, when the 
emulator looks for the files to read (sram/snapshot) it looks for them *WITH* 
the leading space and never 
finds them, of course.

So basically the bug is simple, fix the treatment of filenames so that they are 
honored as-is with the leading 
spaces or whatever characters included in all cases and the problem will go 
away.

The workaround is, of course, obvious: rename the files so they don't have a 
leading space.

Please, in the future, don't make the assumption that problems aren't real just 
because the report doesn't 
include the exact cause and reason for the problem.

Original comment by zacheryj...@gmail.com on 6 Jan 2009 at 9:38

GoogleCodeExporter commented 9 years ago
Thanks for investigating further and finding the cause. I haven't verified it, 
but 
I'll accept the problem. I'm not running a business on this, this is my hobby. 
I can 
choose what bugs to fix, or not fix any. I could just make sure it works for 
me. I 
could not release any of my work. Or I could devote several hours a day to this 
project, like I do. Sorry, I'm not going to let it take over my life, I have a 
job 
and social life too. Other people are free to join the project, or find AND fix 
the 
bugs - I wish more people would! Or better yet they could make significant 
contributions or port their own GBA/GB emulator.

Original comment by dborth@gmail.com on 6 Jan 2009 at 5:29

GoogleCodeExporter commented 9 years ago
Ok, I looked at this and it's a libfat bug. The same thing doesn't happen over 
SMB, 
for example. So, I've reported the bug to chishm, who maintains libfat.

Original comment by dborth@gmail.com on 7 Jan 2009 at 8:10