Best way to include a new tool into PrizmSDK, if I should even do that?

[Heath123]

I've developed a tool that uses the new USB communication syscalls (#87) to speed up the development cycle.

Instead of going through the slow USB bulk transfer process every time to test an add-in, you launch a helper add-in on the calculator, and then a tool on the PC side pushes the data to the calculator. This gets copied to the CG50's 6MB of extra unused RAM, and then the add-in jumps to the address the add-in was copied to. The child add-in then completely takes over from the loader, overwriting its memory. When the child exits, the loader immediately reloads itself, making sure not to assume that its memory is intact.

This is far faster than the manual copy process; the transfer usually takes less than a second, even for large add-ins. Also, if you assign a key like EXIT that causes the main function to return, then you can instantly get back to the loader by just pressing this. This means testing a new version of an add-in takes seconds, rather than minutes, and in some cases means you won't need a PC port for fast testing.

Support for this has already been added to development builds of gint, with the PC side of the loader (which is quite simple) added to the fxlink tool from fxsdk. I'd like to add support to PrizmSDK too, but some cooperation would be needed from the SDK to make it seamless.

The only change in the compile process is that the ROM start address 0x00300000 needs to be changed to 0x8C200000. Then, fxlink can to used to send the generated .bin file to the calculator.

While this can be done manually by editing the linker script, rebuilding, and changing it back when you want a working g3a, that feels a bit janky. If support for this was added to libfxcg, it would probably be a relatively simple Makefile change to have another target to build the add-in like this. However, I'm not sure if it make sense to upstream something that relies on a tool from an entirely different SDK, so I'm wondering if I could upstream that, and also have a standalone sending tool packaged with PrizmSDK?

If this is something you'd be interested in, I'm not sure what the best way to package it would be, especially for the Windows builds. Would the code be in the repo and built with it, or separate like mkg3a? How does the mkg3a executable get included in the Windows releases, is this done manually? Also, some some cases Zadig may need to be used on Windows, is that a problem?

[Heath123]

Demo of how it works:

IMG_4473.mp4

This addin is over 330KB, and would take a while to transfer over USB Mass Storage

[dr-carlos]

The only change in the compile process is that the ROM start address 0x00300000 needs to be changed to 0x8C200000. Then, fxlink can to used to send the generated .bin file to the calculator.

If support for this was added to libfxcg, it would probably be a relatively simple Makefile change to have another target to build the add-in like this. However, I'm not sure if it make sense to upstream something that relies on a tool from an entirely different SDK, so I'm wondering if I could upstream that, and also have a standalone sending tool packaged with PrizmSDK?

If the only change needed (apart from in packaging) is to add a separate make target, this seems reasonable to do. toolchain/prizm_rules already uses mkg3a, so having a feature only used by one program seems reasonable, especially if it's not a dependency of the project.

Anyway I think it's a really cool project and it will certainly help people write addins.

[Heath123]

What do you think about packaging this tool in PrizmSDK on Windows like mkg3a is at the moment? That seems like the biggest challenge here to me, if that's wanted

especially if it's not a dependency of the project.

I was thinking that the make target would automatically call the program if it's installed but everything else in PrizmSDK would work without it so it still wouldn't be strictly needed for PrizmSDK to function

Anyway I think it's a really cool project and it will certainly help people write addins.

Thanks!

[dr-carlos]

What do you think about packaging this tool in PrizmSDK on Windows like mkg3a is at the moment? That seems like the biggest challenge here to me, if that's wanted

I don't use packaged or Windows versions, hence I didn't answer it originally. It seems to me like it would make sense for your addin project to package a version of libfxcg which works with it (after upstreaming the non-packaged version).

I was thinking that the make target would automatically call the program if it's installed but everything else in PrizmSDK would work without it so it still wouldn't be strictly needed for PrizmSDK to function

This seems fine to me.

[tari]

Would the code be in the repo and built with it, or separate like mkg3a? How does the mkg3a executable get included in the Windows releases, is this done manually?

Automatic builds of libfxcg also compile mkg3a; there's no issue with building a tool that lives in another repository, though if a user needs to do additional setup (like using Zadig) we'd have to document that clearly.

I agree that it's no issue to have some option for our makefiles to target your tool instead of a regular g3a even if it requires manual setup to start using, especially if that's a non-default option.

[Heath123]

Would you rather have the PC tool’s source code within or outside of this repo?

[tari]

Outside seems like the logical choice to me.