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

Target device is full #28

Open
RevQuixo opened this issue Jan 4, 2021 · 9 comments
Open

Target device is full #28

RevQuixo opened this issue Jan 4, 2021 · 9 comments

Comments

@RevQuixo
Copy link

RevQuixo commented Jan 4, 2021

As was mentioned in a previous ticket Jo Engine does throw an error if the target device is full. Perhaps instead of blue-screening we could have a message pop-up that "Target Device is full, cannot copy save". Kind of getting into the weeds of just QOL changes, which is awesome :)

@slinga-homebrew
Copy link
Owner

The problem is jo_backup_save() only returns a true/false. So i can detect the write fail, but I have no idea why. I can change it to no longer pop a blue error message and just say something like: "Failed to copy save". What do you think?

@RevQuixo
Copy link
Author

RevQuixo commented Jan 5, 2021

Given the limitation that could work.

@amerika13
Copy link

I'd put something like, "Failed to copy the save to {target}, possibly due to a lack of space".

And, as part of this request, can you read how much internal and cart memory is allocated and how much is left available similar to how the BIOS screen displays it? Or, I guess since those values don't change, simply display the known quantity of memory for both internal and ram cart and then do a quick add for how much is being used at the time. This would let people who see the above message easily identify what the issue is on their own without much work on your part or a change to Jo I believe.

@slinga-homebrew
Copy link
Owner

I tweaked the error message in trunk. I need to look how to read the values of internal\cart memory. I know Jo Engine does it, I'm not sure there's a function to access it.

@amerika13
Copy link

I don't think you need that. The internal value and the cart value is always the same. Just do an add for the save files you currently have and then subtract from the total of the internal or the total of the ram cart.

Ex:
1800 blocks internal total
1500 blocks taken up by saves
300 blocks remaining

Those are random numbers but I think you get the idea. No need to actually access the values from the console unless it ends up being easier to do.

@slinga-homebrew
Copy link
Owner

I agree internal value should always be the same, but what about cart? There are different size carts available as well.

And blocks can be fragmented. A 1 byte save and a 25g byte save both take 1 block (assuming blocks are 256 bytes each, dunno). I am able to pull back the block size of each save. I hid it because I ran out of room.

@amerika13
Copy link

Hrm, I didn't know there could be different external cart values. My OEM and my all-in-one have the same size memory. I guess if you can't read in the actual values, you could do internal only, as it's the more important anyway, and do a best guess when it comes to block size count despite fragmentation. Mostly just need it to be in the ballpark. And, at the end of the day, it's just an QoL change that isn't super important.

@RevQuixo
Copy link
Author

I also was unaware that there were different size external memory cards..are there ones bigger than the official?

@slinga-homebrew
Copy link
Owner

I'm basing my info on: https://segaretro.org/Saturn_third-party_memory_cartridges. Looks like there are multiple cart sizes.

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

No branches or pull requests

3 participants