Correctly format a ControllerPak

[networkfusion]

Still requires formal testing from someone.

For note, the Original PR was: rasky#7 which includes lots of extra detail.

Linked to (but does not fix) #105

[networkfusion]

@meeq and @bryc are you able to check that this works / looks correct?

[bryc]

The code itself seems fine to me. It correctly implements a full Controller Pak initialization.

But does this have a place in libdragon?

If libdragon were to get a robust C-Pak and repair function, this would largely become obsolete. An argument could also be made that it would be better for a general N64 library to only modify what is absolutely necessary instead of completely overwriting the entire system area.

IMHO this kind of function is more suited for initializing empty C-Pak data in emulators or flashcart C-Pak managers, not homebrew games and such.

[networkfusion]

The code itself seems fine to me. It correctly implements a full Controller Pak initialization.

But does this have a place in libdragon?

If libdragon were to get a robust C-Pak and repair function, this would largely become obsolete. An argument could also be made that it would be better for a general N64 library to only modify what is absolutely necessary instead of completely overwriting the entire system area.

IMHO this kind of function is more suited for initializing empty C-Pak data in emulators or flashcart C-Pak managers, not homebrew games and such.

My take is to fix what is broken, and then deprecate it (since we should be looking at a new API anyway).

And thanks for the response.

Going further, I would suggest that this becomes an internal function that is only called upon in a replacement API when the repair function has failed.

But since the PR is valid with the suggested changes, It seems fine to merge with unstable.

[rasky]

Well flashcart cpak manager could be written with libdragon too. I agree that homebrew games shouldn't call this function and that we need to rewrite the whole module. At the same time if this PR works better than what its in now, I think merging it is a good idea anyway

[bryc]

This is certainly better than what currently sits at format_mempak. Which merely writes an array of bytes taken from old era Mupen64, under the assumption that the emulator is doing it right (it was not).

Anyway, I'd be happy to assist if and when someone wants to work on a proper complete C-Pak lib 😃. Much of the logic in MPKEdit could be adapted (though it's in JS, it should be possible to port). The only thing MPKEdit lacks currently is a 'smart' IndexTable repair routine, which wasn't a priority because the app doesn't interact with live hardware.