Savegames: Difference between revisions

Line 239:

| 0x68

| 8

| Hashed Block Length

| Hashed Block Length (1<<value)

|-

| 0x70

Line 246:

|-

|}

'''DPFS'''

Line 277:

Line 275:

* The u64 at 0x40 is an offset because if you summarize the hashtable's length and the partition's length you'll get sometimes less then this value. so it isn't the length of the total partition but an offset.

~~====~~ The ~~SAVE~~ partition ~~====~~

The first partition starts at 0x2000. First comes the hashtable (usually start @ 0x40 into the partition) and then the filesystem.

~~Savefiles are stored on the FLASH in a custom filesystem called SAVE. SAVE has a header which describes~~ where the ~~various bits of~~ the ~~filesystem live~~.

The hashtable entries' size is 2^x where x is the 'Hashed block size' from the IVFC block.

The first ~~partition starts at 0x2000. The hashtable at the start of the partition describe each in-use block in the partition with a SHA256~~ of ~~the 0x200 sized block~~.

* The first 0x40 bytes are still unknown (possibly hash of some kind).

* The ~~first two hashes don't seem to be associated with any 0x200 block~~.

==== The SAVE file system ====

Savefiles are stored on the FLASH in a custom filesystem called SAVE. SAVE has a header which describes where the various bits of the filesystem live.

Finding the file system file base:

Line 289:

* Otherwise the file base will be at ('active_table' & 0xFFFFFFFE) into the DATA partition.

~~Finiding~~ the file system table:

Finding the file system table:

* If the uint32 @ 0x58 and uint32 @ 0x6C into the SAVE header aren't 0 then the table is at [@0x58] + [@0x6C]*0x200.

* Otherwise, (meaning the files are at another partition) the exact offset into the SAVE is @ 0x68.

~~Once you~~'~~ve found the FST, parsing it is fairly straightforward.~~

File system's entry structure:

<pre>

struct fs_entry {

@@ Line 239: / Line 239: @@
 | 0x68
 | 8
-| Hashed Block Length
+| Hashed Block Length (1<<value)
 |-
 | 0x70
@@ Line 246: / Line 246: @@
 |-
 |}
 '''DPFS'''
@@ Line 277: / Line 275: @@
 * The u64 at 0x40 is an offset because if you summarize the hashtable's length and the partition's length you'll get sometimes less then this value. so it isn't the length of the total partition but an offset.
-==== The SAVE partition ====
+The first partition starts at 0x2000. First comes the hashtable (usually start @ 0x40 into the partition) and then the filesystem.
-Savefiles are stored on the FLASH in a custom filesystem called SAVE. SAVE has a header which describes where the various bits of the filesystem live.
+The hashtable entries' size is 2^x where x is the 'Hashed block size' from the IVFC block.
-The first partition starts at 0x2000. The hashtable at the start of the partition describe each in-use block in the partition with a SHA256 of the 0x200 sized block.
+* The first 0x40 bytes are still unknown (possibly hash of some kind).
-* The first two hashes don't seem to be associated with any 0x200 block.
+==== The SAVE file system ====
+Savefiles are stored on the FLASH in a custom filesystem called SAVE. SAVE has a header which describes where the various bits of the filesystem live.
 Finding the file system file base:
@@ Line 289: / Line 289: @@
 * Otherwise the file base will be at ('active_table' & 0xFFFFFFFE) into the DATA partition.
-Finiding the file system table:
+Finding the file system table:
 * If the uint32 @ 0x58 and uint32 @ 0x6C into the SAVE header aren't 0 then the table is at [@0x58] + [@0x6C]*0x200.
 * Otherwise, (meaning the files are at another partition) the exact offset into the SAVE is @ 0x68.
-Once you've found the FST, parsing it is fairly straightforward.
+File system's entry structure:
 <pre>
   struct fs_entry {