Hyperion announces OS 3.1 update

[psxphill]

But I'm not talking about "simple things". It depends on more than just AllocBItMap, and the register dependency is more than "oh, please use register a4 to get the MonitorInfo". I'm talking about the stack frame, and the structure layout, and there are many more structures in intuition than what is in the official includes.

Having the source would certainly be easier. Reverse engineering what needs to be done from the binary is definitely doable, if you had time. Which you don't appear to.

An emulator with a decent debugger would probably make things easier.

[psxphill]

If someone have to much time in their hands why not to fix AmigaOS4.1 FE for Classics?

If you have enough time to write this post, then why can't you come and clean my car?

[psxphill]

The only difference between eight 512 byte transfers in row and a 4096 block transfer is in the low-level signalling of the IDE transfer, so the benefit of larger block transfers is not clear at all. The scsi device, if transfering 8 blocks in a row, already uses a block-transfer command for IDE - but this already holds for the V40 version out in the wild.

In theory some drives can only do 4k transfers. In practice most of them offer 512 byte sector emulation & you might not find a PATA drive that only does 4k.

However even with 512 byte sector emulation you have a potential performance problem, especially if you are doing a lot of unaligned writes. Writing 512 bytes into a 4k sector requires a read modify write. However this might not be that bad when you consider how long it will take an amiga to transfer those extra bytes.

[psxphill]

This problem is avoidable if you align partition boundaries correctly.

Alignment helps, you also need to make sure you always write in multiples of 4k. Even when appending data to the end of a file.

[psxphill]

Due to a matter of bad luck and just coincidence, MungWall now believed that the icon.library allocation code comes from layers, though classified the icon.library (actually exec) memory release call as regular. This is because icon as well as layers are "loadmodule'd" and for that reason, the resident list, which is checked by MungWall, is a bit "unusal", so the mungwall heuristics of detecting "this PC belongs to layers" failed.

So can you fix the resident list to make mungwall happy?

All this information is in part intended for a repair operation which is currently not implemented. A repair strategy would be needed first, and I have yet to come up with one. The more I learned about what can go wrong the more alternatives to dealing with the defects revealed themselves. You may be able to correct the smaller problems, such as restoring the consistency of directories, but if the root directory is damaged, how do you rebuild its bookkeeping information without destroying other data that might still be recoverable? So, after four months of work, this is still a research project, I'm afraid.

When I've done similar data recovery, I've ended up using a "what if" algorithm that tries multiple things when there are ambiguity & picks the most consistent one.
It's a load of planning and a load of code. You shouldn't aim for perfect recovery in all cases though because it's impossible. Getting consistency back means you don't have to choose between reformatting and losing more data when the corruption upsets the file system.