final fantasy type-0 iso merge file issue

[SkyBladeCloud]

Yup, it uses block device mode (umd0:, and yeah, the syscall takes the sector of the umd where it has to seek in $a0). I wasn't really hoping that anyone would "fix" this (specially because it's not really wrong, I mean, that's how the PSP officially works ). But if you wanna have a look at it, just tell me and I'll put a video at the end of a +2GB ISO and pad the rest, unnecessary files (let's hope it's not too big xD). Otherwise I'll end up having a look at the code myself (yeah, I mess around with it a lot xD)

~Sky

[[Unknown]]

In BlockDevices.cpp, try changing:

Code:

fseek(f, blockNumber * GetBlockSize(), SEEK_SET);

To:

Code:

fseeko(f, (off_t)blockNumber * (off_t)GetBlockSize(), SEEK_SET);

And:

Code:

    fseek(f,0,SEEK_END);
    filesize = ftell(f);

To:

Code:

    fseek(f,0,SEEK_END);
    filesize = ftello(f);

And also:

Code:

    u32 idx = index[blockNumber];
    u32 idx2 = index[blockNumber+1];
    u8 inbuffer[4096]; //too big
    z_stream z;

    int plain = idx & 0x80000000;

    idx = (idx & 0x7FFFFFFF) << indexShift;
    idx2 = (idx2 & 0x7FFFFFFF) << indexShift;

    u32 compressedReadPos = idx;
    u32 compressedReadSize = idx2 - idx;

    fseek(f, compressedReadPos, SEEK_SET);
    u32 readSize = (u32)fread(inbuffer, 1, compressedReadSize, f);

To:

Code:

    u32 idx = index[blockNumber];
    u32 idx2 = index[blockNumber+1];
    u8 inbuffer[4096]; //too big
    z_stream z;

    int plain = idx & 0x80000000;

    off_t compressedReadPos = (idx & 0x7FFFFFFF) << indexShift;
    off_t compressedReadEnd = ((idx2 & 0x7FFFFFFF) << indexShift);
    off_t compressedReadSize = compressedReadEnd - compressedReadPos;

    fseeko(f, compressedReadPos, SEEK_SET);
    u32 readSize = (u32)fread(inbuffer, 1, compressedReadSize, f);

Does that make it work with iso and cso (make sure you're running a 64-bit build, it probably won't work with 32-bit)? If not, it probably takes just a bit more than that.

-[Unknown]

[SkyBladeCloud]

Thanks [Unknown], but looks like that didn't do the trick, I'm trying in windows (yeah, x64 build, building ppsspp as x64). The +2GB ISO still working as usual; what I could notice is that e.seekPos in ISOFileSystem::ReadFile is not being updated after the last successful read.

So for example, if the last correctly read sector was sector 1, when trying to read a sector beyond the 2GB limit, it will actually read block number 2 (and that's the argument in FileBlockDevice::ReadBlock).

Anyway, thank you very much for your time

~Sky

[[Unknown]]

Hmm. I suppose sce_lbn references may not work properly with a 2+ GB iso, although umd: access will (it's by LBA.)

If you change seekPos from unsigned int to u64, as well as openSize. Then also change startingPosition of the TreeEntry struct to u64. Might need to add some casts to this line:

e->startingPosition = dir.firstDataSector() * 2048;

And then change:

Code:

        u32 sectorStart = 0xFFFFFFFF, readSize = 0xFFFFFFFF;
        parseLBN(filename, &sectorStart, &readSize);

To:

Code:

        u32 sectorStart = 0xFFFFFFFF;
        u64 readSize = 0xFFFFFFFFFFFFFFFFULL;
        parseLBN(filename, &sectorStart, &readSize);

(both times)

And then in parseLBN:

Code:

bool parseLBN(std::string filename, u32 *sectorStart, u32 *readSize)

...

    if (sscanf(filename_c + pos, "%x", readSize) != 1)
        *readSize = 0;

    return true;
}

Code:

bool parseLBN(std::string filename, u32 *sectorStart, u32 *readSize)

...

    if (sscanf(filename_c + pos, "%llx", readSize) != 1)
        *readSize = 0;

    return true;
}

If that works, it'll mean some hassles to make savestates upgrade, but that could maybe/hopefully do the trick.

Oh, also, you'll need:

Code:

u32 positionOnIso;

Change to u64, and possibly some related casts.

If not (very possible, I'm not sure why it would be reading the second sector...), hmm...

-[Unknown]

[ade32]

(12-30-2013 12:58 AM)SkyBladeCloud Wrote:  Thanks [Unknown], but looks like that didn't do the trick, I'm trying in windows (yeah, x64 build, building ppsspp as x64). The +2GB ISO still working as usual; what I could notice is that e.seekPos in ISOFileSystem::ReadFile is not being updated after the last successful read.

So for example, if the last correctly read sector was sector 1, when trying to read a sector beyond the 2GB limit, it will actually read block number 2 (and that's the argument in FileBlockDevice::ReadBlock).

Anyway, thank you very much for your time

~Sky

oh mine,sir sky, what's happen to ff type-0 merging file when english patch done?? are you combined or something different??

[SkyBladeCloud]

@[Unknown]:

Hum, this is weird, the ISO still working as usual, even if I go and modify currentMIPS->r[6], so the LBA to seek is correct, and trace the execution, making sure that the emulator is correctly reading the data (and after all this it IS correctly reading the data after 2GBs).

However, it's not showing anything, and works as always, there must be something else I'm missing

@ade32:

We'll see, so far it looks like I will have to lol...

...

[ade32]

(12-30-2013 04:21 PM)SkyBladeCloud Wrote:  @[Unknown]:

Hum, this is weird, the ISO still working as usual, even if I go and modify currentMIPS->r[6], so the LBA to seek is correct, and trace the execution, making sure that the emulator is correctly reading the data (and after all this it IS correctly reading the data after 2GBs).

However, it's not showing anything, and works as always, there must be something else I'm missing

@ade32:

We'll see, so far it looks like I will have to lol...

...

sir,,i hope so

@unknown : may i ask to u about other problem here???

[ade32]

hello sir sky,,so far how many percent the english patched has been completed??

[LunaMoo]

Oh didn't notice this thread was updated with soo much info;o.

@SkyBladeCloud I wonder would it be possible to cut some of those movies of the iso or even divide the whole data archive and load that externally as dlc's from /game folder or that would require too much change in the game?
I have no clue how psp games loads external dlc's/updates so this might be totally bothersome/stupid idea or simply too late seeing how fast the translation goes(ends?), but would certainly avoid problem with iso size on all devices without need for additional plugins and stuff.
Anyway's thanks a lot for all your and your teams work, hope you guys don't haste the release just because of all the fanboy pressure;O.

[TheDax]

I'm going to go ahead and close this, since this problem will be fixed soon: https://github.com/hrydgard/ppsspp/pull/5194.

[TheDax]

Reopened at the TC's request.

[ddkktt]

hi i have cfw 6.60 ME 1.8 final fantasy type 0 run pretty good but ME dont have infernus, so the videos are pitch black
my question is i have to downgrade to 6.60 pro B-10?

[ZeroX4]

(06-16-2014 02:14 AM)ddkktt Wrote:  hi i have cfw 6.60 ME 1.8 final fantasy type 0 run pretty good but ME dont have infernus, so the videos are pitch black
my question is i have to downgrade to 6.60 pro B-10?

for me its like more u should update cfw

i think 660PRO-C2 is latest