sp193
Developer
I believe that there is a bug in HDDChecker, which prevents PFS partition checking from working correctly. So for now, I suggest not using this to check PFS partitions (particularly large ones) - although the other functions should be fine.
If the partition is small enough (I suppose that's why there are seemingly no complains about this), the in-memory buffer is used instead.
Its fsck module was originally based on the one from HDD Utility Disc v1.00J, which used a new _tmp partition to store the temporary bitmap. However, this was changed in later versions of the HDD Utility Disc to use the data region of __mbr, which is mostly unused (except for the MBR program itself).
To avoid the MBR, Sony adds 0x00020000 (64MB) to the LBA to access. Unfortuately, since my version was upgraded from the early design, this step was missed out. It's been like that ever since the feature was made.
Given the formula to compute the number of bitmaps:
2²⁰ * 512 = 1MB * 512 = 536870912 (512MB).
There are 5x bitmap buffers. So the partition would need to be larger than 2.5GB, before it starts writing to the HDD.
If the partition is small enough (I suppose that's why there are seemingly no complains about this), the in-memory buffer is used instead.
Its fsck module was originally based on the one from HDD Utility Disc v1.00J, which used a new _tmp partition to store the temporary bitmap. However, this was changed in later versions of the HDD Utility Disc to use the data region of __mbr, which is mostly unused (except for the MBR program itself).
To avoid the MBR, Sony adds 0x00020000 (64MB) to the LBA to access. Unfortuately, since my version was upgraded from the early design, this step was missed out. It's been like that ever since the feature was made.
Given the formula to compute the number of bitmaps:
Code:
bitmapCount = (sectors >> 20) + (0 < ((sectors >> 3) & 0x0001FFFF));
There are 5x bitmap buffers. So the partition would need to be larger than 2.5GB, before it starts writing to the HDD.
Last edited: