Then I looked at redump for FF8 UK and it looks like that all 4 disks have the same magic-word anyway, so I guess Jokes on me ? That is updated in the magic-word branch. If this works well we might have mostly solved the issue of creating EBOOT.PBP packages for PS3.ĮDIT2: I have fixed pop-fe now so that it checks the game-id for each disk and generates a unique MagicWord for each disc in multi-disc games, instead of just checking the first disk and then using the same magic-word on every disk in the series. But lets at least test disc1 and a bunch of single disc games. I will have to change this to check the game id and generate a magic word for each disk in the set before it will likely work. If it works, it should make it easier to test since you dont have to manually go and hexedit the and stuffĮDIT: for multi-disc games it is probably only going to work for the first disk, since that is the only disk I use when checking the game-id.

Then if it is recognized as libcrypt, it fetches the data from and generates the magic wordĪnd finally injects it at 0x12b0 in psisoimg0000.Ĭan you test it, if it works for your disks and the generated looks good ?

It attempts to detect if the disk is libcrypt enabled by checking the game-id to a new dict gamedb/libcrypt that I built from the webpage but I must have missed about ~10 disks or so since it does not contain all 229 disks. The patch is only in the magic-word branch for now. The relative offset of the 'magic word' discussed in the latest posts here depends of where we consider it starts the 'Game Params Table'Ĭlick to expand.Can you try out the magic-word branch of pop-fe ? The real annoyance about this detail is the area that comes next 'Game Params Table' in the actual version of the table is not starting at an offset aligned to 0x400, is hard to know where it starts because a lot of the values are unused/filled by zeroes but i would say it 'should' start at 0x1400 (following the offsets of the table in wiki that represents the first disc of a multidisc game) so it would be needed to change the names to give them a common name and represent it as a single entity In ther words, it would include the area we are naming in the actual version as 'Game Params Table'. If the audio tracks table is really bigger than one block we should represent it as a contiguous area of two blocks (0x800) The previous versions of the table was considering all the areas are aligned to 0x400 (the size of a block), the area that was named 'tracks table' in that edit (and 'Audio tracks table' in the actual version) was given a size of 0圆20 (exceeds one block), you have been working with audio tracks latelly, what do you think about this ? Ronnie can you check this ?, there is a disalignment in the 'section' table in wiki introduced since this edit

Gekido psx iso