[velvet]

hi, i have VBA on my Mac osx. the roms i have play but an error comes up saying "error creating file battery saves/spyro - season of ice.sav
How do i fix it so it can save?

 

[velvet]

hello???

 

[proger]

hello???

Noone has responded because not many people around here know how to use, or even have macs.

 

[Anbu1_3]

I have a mac but when i played spyro the same thing happened to me.
So i just think it's the rom.

 

[Valcrist]

gee how did I miss this thread o.0

Check other roms to see if they save, also you might want to go to your disk utility and validate and fix persmission on the whole disk.

 

[velvet]

gee how did I miss this thread o.0

Check other roms to see if they save, also you might want to go to your disk utility and validate and fix persmission on the whole disk.

none of my other roms save either.. are the games suppose to be in a certain folder or something?..

 

[kelvSYC]

IIRC, this is a known issue with Mac VBA. Since AFAIK the code for battery saves are in the core, it's probably some nonportable code therein. The only thing I can tell at this point is that it may be a problem with the code in Util.cpp (since all roads practically lead there) - it is most likely an endian issue (a similar issue prevented CB decryption from working on the Mac) from casting something something with inherent byte sex to void*, ie. where every byte is sexually ambiguous. I suspect that any build on VBA on a big-endian system (eg. vba on solaris-sparc) will have similar issues.

 

[Forgotten]

No, the saving issue is not an endian problem. There must be something else wrong in the system. All it tries to do is write to a file in the specified battery directory. I don't know at what state flea left the Mac port, so I have no idea how you even configure it.

 

[kelvSYC]

Ah I see. I was looking at the wrong sources (Flash.cpp and EEprom.cpp). The problem stems from the file pointer from calling std::fopen() in CPUWriteBatteryFile() in GBA.cpp returning null.

Still, I have found that utilGzWriteInt() is not endian-safe in any case...

 

[Forgotten]

Endian-safe is different from the problem writing to the file. I never worried about producing the correct endian-safe files, but the saves I think are endian safe, maybe with the exception of the compression on top of them, because aside from that, they are just bytes in the order the game writes. It is up to the game and emulator to read it correctly.