Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add fat32/exfat fragmentation tolerance #673

Merged
merged 5 commits into from Jun 16, 2022

Conversation

rickgaiser
Copy link
Member

@rickgaiser rickgaiser commented Jun 13, 2022

Pull Request checklist

Note: these are not necessarily requirements

  • I reformatted the code with clang-format
  • I checked to make sure my submission worked
  • I am the author of submission or have permission from the original author
  • Requires update of the PS2SDK or other dependencies
  • Others (please specify below)

Pull Request description

This PR adds fragmentation support to the ingame / iopcore. This applies to all BDM devices using fat32/exFat. Up to 10 fragments will be possible. If there's more fragments then the same old fragmentation message should appear.

Also in this PR I made the cloning of the lang folder a little less aggressive. 'make clean all' will no longer remove the lang folder, and only update the lang folder. 'make realclean all' will also delete the lang folder, and re-clone it.

@bignaux
Copy link
Member

bignaux commented Jun 13, 2022

Also in this PR I made the cloning of the lang folder a little less aggressive. 'make clean all' will no longer remove the lang folder, and only update the lang folder. 'make realclean all' will also delete the lang folder, and re-clone it.

was doing same stuff since it's very very boring. btw, mostlyclean is the name for this kind of target to clean what should be rebuild.

@@ -314,6 +312,10 @@ clean:
echo "-pc tools"
$(MAKE) -C pc clean

realclean: clean
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

realclean -> clean
clean -> mostlyclean
https://www.gnu.org/software/make/manual/html_node/Goals.html

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I disagree. We're talking about deleting external source files. We not talking about deleting compiled files.

From the link you provided:

mostlyclean
Like ‘clean’, but may refrain from deleting a few files that people normally don’t want to recompile. For example, the ‘mostlyclean’ target for GCC does not delete libgcc.a, because recompiling it is rarely necessary and takes a lot of time.

distclean
realclean
clobber
Any of these targets might be defined to delete more files than ‘clean’ does. For example, this would delete configuration files or links that you would normally create as preparation for compilation, even if the makefile itself cannot create these files.

Which is exactly what I think we want:

  • clean: delete all compiled files
  • realclean: delete more, like the entire git repository

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's a point of view. I thought we can avoid rebuild the compiled lang so i think mostlyclean ...

src/bdmsupport.c Outdated

// Get fragment list
fileXioIoctl2(fd, USBMASS_IOCTL_GET_FRAGLIST, NULL, 0, (void *)&part_frags, sizeof(bd_fraglist_t));
if ((settings->frags.count + part_frags.count) > 10) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

maybe 10 can be delivered from header? just in case we increase the limit so do not forget to increase it here too.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good point. But unfortunately I didn't add it to the header in ps2sdk :(. There's also another thing bothering me. Instead of 10 fragments it would be better to be able to ask for more (or dynamic) number of fragments.

Having more fragments could also make this new structure compatible with HDD fragments:

typedef struct
{
u32 part_offset; // in MB
u32 data_start; // in sectors
u32 part_size; // in KB
} hdl_partspecs_t;
#define HDL_NUM_PART_SPECS 65

Perhaps the best solution is to make the function (USBMASS_IOCTL_GET_FRAGLIST) dynamic, and pass a fixed amount of 65 fragments to the iopcore? Then as a second step, make the HDD and BDM fragments use the same structure and code?

@rickgaiser
Copy link
Member Author

I've make the fragmentation tolerance much more flexible now, and increased the maximum number of fragments 64.
In theory it can now also be used for VMC, and also for HDD.

Currently this PR will fail untill the PR in ps2sdk has been merged.

@INDRAPhilip
Copy link

Will this work with ZSO? Why does the code fill only fragmented files in ISO? Will you leave it to @JoseAaronLopezGarcia add?

@rickgaiser
Copy link
Member Author

Yes, this should work with ZSO also. It's the fragments of the 'game file', no matter the file extension.
ZSO is also a (compressed) ISO.

@INDRAPhilip
Copy link

Sim, isso deve funcionar com a ZSO também. São os fragmentos do "arquivo do jogo", não importa a extensão do arquivo. ZSO também é um ISO (comprimido).

It makes sense I was just looking at the code and not the fact that the zso is just iso compressed

@rickgaiser
Copy link
Member Author

Also note that the fragmentation support costs 512b of extra IOP RAM.
But at the same time I added a fix that actually saves 2048b of IOP RAM ;).

@INDRAPhilip
Copy link

Also note that the fragmentation support costs 512b of extra IOP RAM. But at the same time I added a fix that actually saves 2048b of IOP RAM ;).

This is definitely a great thing for new iop functions and for games that require more ram

@uyjulian uyjulian merged commit 4a1e95e into ps2homebrew:master Jun 16, 2022
citronalco pushed a commit to citronalco/OPL-Daily-Builds that referenced this pull request Sep 10, 2023
Add fat32/exfat fragmentation tolerance
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

6 participants