Talk:Savegames: Difference between revisions

Line 7:

3. Re-ordering hashes in the partition table and the blocks of data associated with them (without changing anything) yields a "corrupt data" error. How to get around that?

~~It probably means~~ the hash table for the partition, is being hashed to verify the hash table itself, but if you modify just the filler data following the hash table ( same block ) it will not cause "corrupted data" messages on a game cartridge.

Probably the hash table for the partition is being hashed to verify the hash table itself, but if you modify just the filler data following the hash table ( same block though ) it will not cause "corrupted data" messages on a game cartridge.

That means the ~~entire~~ 0x1000 block of data, where the hashes are contained, ~~must not be what~~'s hashed, ~~since~~ only editing or re-arranging ( to not invalidate hashes in the list ) ~~anything of~~ the first 0x200 bytes ~~or so~~, ~~where the hash data is actually~~ generates data corruption errors.

That means the 0x1000 block of data, where the hashes are contained, aren't hashed, only editing or re-arranging ( to not invalidate hashes in the list ) the first ~0x200 bytes, generates data corruption errors.

~~However~~ I cannot locate ~~any hash~~ for either the 0x1000 block or ~~for~~ just the data that ~~is causing the~~ errors if modified ( the first 0x200 bytes ).

I cannot locate hashes for either the entire 0x1000 block or just the data that will cause those errors if modified ( the first 0x200 bytes ).

@@ Line 7: / Line 7: @@
 . Re-ordering hashes in the partition table and the blocks of data associated with them (without changing anything) yields a "corrupt data" error. How to get around that?
-It probably means the hash table for the partition, is being hashed to verify the hash table itself, but if you modify just the filler data following the hash table ( same block ) it will not cause "corrupted data" messages on a game cartridge.
+Probably the hash table for the partition is being hashed to verify the hash table itself, but if you modify just the filler data following the hash table ( same block though ) it will not cause "corrupted data" messages on a game cartridge.
-That means the entire 0x1000 block of data, where the hashes are contained, must not be what's hashed, since only editing or re-arranging ( to not invalidate hashes in the list ) anything of the first 0x200 bytes or so, where the hash data is actually generates data corruption errors.
+That means the 0x1000 block of data, where the hashes are contained, aren't hashed, only editing or re-arranging ( to not invalidate hashes in the list ) the first ~0x200 bytes, generates data corruption errors.
-However I cannot locate any hash for either the 0x1000 block or for just the data that is causing the errors if modified ( the first 0x200 bytes ).
+I cannot locate hashes for either the entire 0x1000 block or just the data that will cause those errors if modified ( the first 0x200 bytes ).