This is a project that I've been working on for a while, but I finally finished the screen mirroring part and decided to release it.
Calc2KeyCe allows you to bind calculator keys to keyboard/mouse keys to control your computer and optionally mirror your main display to your calculator.

https://github.com/dnmalenke/Calc2KeyCE

Let me know what you all think, I'm open to suggestions and some help improving the speed and stability of the screen mirroring part.

I'm hoping to improve the fps of the screen mirroring, but I can't seem to store more than around 51200 bytes in a buffer on the calculator to perform a multipart usb transfer and decompress.

Edit: I forgot I posted a demo of this a while back on Reddit
https://www.reddit.com/r/Rainbow6/comments/ie9hkw/trying_to_get_kills_with_a_ti84/

one word: YESSSSSS!!!!!!! I'm so excited to try this out!

TIny_Hacker only has a mac and is sad

Wow that's really cool!

Have you thought about only sending parts of the screen that have changed, could speed things up in some circumstances?

That's a limitation of how much heap space there is. There are a couple potential ways around it though. We recently determined that a bug in the OS will corrupt a specific portion of the heap if you use certain OS display routines; if you don't use the offending routines, you can get another 10 K of heap space. If you're using 8-bit color mode and aren't using double buffering, then you could use the unused buffer as extra buffer space for decompression. Finally, you could create a variable in RAM and use it for buffer space. By bypassing FileIOC, you can even allocate a buffer bigger than 64 K, assuming that the user has left you more than 64 K of free RAM. This is done by just calling _InsertMem more than once on the same variable, but you have to undo it before the program quits or else you'll leak a ton of memory.

This is such an awesome project! I really want to see this released one day (hopefully soon). If you're looking for beta testers, then please consider me one.

They have a release on the github: https://github.com/dnmalenke/Calc2KeyCE/releases

Unfortunately I'm getting an error about .NET 5.0 not being present on my system. I think that's a me issue though.

I'm currently decompressing directly into lcd_Ram, so I don't think I'm using any display routines??, but switching color modes is a good idea and it could be implemented on the PC side to reduce the amount of data that needs to be transferred on more complicated screens.
For now, I'm just turning off decompression and sending data from usb directly into lcd_Ram if the compressed data is too large.

I'm definitely planning on working on Mac and Linux ports of this project, so it would be greatly appreciated if people are willing to test it out because I don't have a Mac or a true Linux device.



https://dotnet.microsoft.com/download/dotnet/5.0/runtime

Here's a link to the .NET 5.0 download if you haven't found it yet.



I've thought about it, but a diffing algorithm would probably be difficult to implement in a fashion that can be easily transmitted and read into the lcd_Ram. It's a good idea though

I'm definitely willing to help test on Mac or Linux.

Oh wow, This is absolutely very cool! Just awesome!

I would gladly help testing for Linux once you start working on Linux support!

Yes I've tried installing it, running repair tools, and restarting my computer multiple times. I dunno why my laptop still can't recognize it's there. I really want to try this program so I'll just find a different computer to use.

This is really impressive work As for decompressing only the changing parts, do it using only the y-coordinate, so that way decompression spans the width of the screen.

When the run the program on my calculator, it quickly shows a black screen and then returns to the home screen? (My calculator is plugged into the computer.) Am I doing something wrong?

I get this issue with my revision M CE but not my pre-A. I finally got .NET working, but now I'm having issues using zadig.
EDIT: TLM 1700th post

Interesting. I'm using a revision O. I guess there might be a difference in how the program handles different hardware revisions. (I'm not an expert though, so... )

I have the same issue when using my Rev M. I wonder if there is a problem with Post-M revisions?

It could be something with the faster flash in the newer models loading the program faster than planned and windows sending a three byte transfer? Currently I'm checking for any three byte message and exiting the program as a way for the windows program and calculator to "safely" disconnect from each other.
I can add something in to check if the data is garbage or the zero bytes the windows program is sending.

Does the usb test program work?
https://github.com/CE-Programming/toolchain/tree/usbdrvce/examples/usbdrvce/test

I cannot seem to get the program to compile. I have the header file in the right folder and it starts to compile fine, but then it just stops. This is the error that I'm getting:

It's possible that you're running the program with a different USBDRVCE version than it was compiled with - the interface isn't stable yet.

As for the compilation error, make sure you've installed the usbdrvce branch of the toolchain, or at least the .lib and .h files for it.

It looks like usbdrvce.lib in CEdev/lib hasn't been updated.
Is there a place where we can get a prebuilt/nightly version of usbdrvce.8xv? Or would I be allowed to add a prebuilt version for download in the Calc2KeyCE repo?