The P7 project is a project made of libraries and utilities under free software licences (LGPL3 for libraries, GPL2 for utilities). These utilities currently only covers communication with modern CASIO calculators, using the latest proprietary protocol, called "Protocol 7.00" by Simon Lothar. In the next version, it will also be made of utilities for managing files under free and proprietary formats surrounding CASIO calculators, and utilities to link the two.

>>> Find out more on the current version of the project here <<<

History
Everything started more than a year ago. I was already running on a Linux distribution (Debian at the time), and there was not much software for my little fx-9750GII (Graph 35+USB) that could run on my PC. For transferring, there was UsbConnector (xfer9860 did not work with my calculator), although it could only send files to the calculator (not receive), and for making add-ins, there was GCC and an approximate conversion of CASIO's fxlib (set up using this tutorial).

After some time working with these, I really wanted something better, so I started gathering some documentation and making it: in August 2016, thanks to the help of Simon Lothar, P7 (for "Protocol 7") was born. At the time, it was a quick project made in one week, with already a static library (I didn't know how to make dynamic libraries at the time), called libp7, and the transfer utility using it. The P7 project was "born" later, regrouping the library and the utilities, later regrouped under a single subproject, the p7utils; this project then evolved to become a more general project of freeing software surrounding CASIO calculators.

Goals and elements
You can find the website of the in-development project here (source here), I'll formulate in another way here.

This project started as a Protocol 7.00 implementation, so let's start with the communication part of the project. It is made of libp7 and p7utils It currently aims at supporting more CASIO calculators, in a cross-platform way, which means:
- supporting the CASIOLINK legacy protocols (CAS40 and CASDYN, which has the CAS50 and CAS100 variants);
- adding the MCS files exchanges;
- implementing SCSI/UAS (using proprietary commands) for the support of Prizm screenstreaming (and file exchange in general?);
- correcting the existing built-in streams (such as the one using the Windows API), adding more for exotic platforms (if needed).

There is another part, not in the current release of the project yet (and probably won't be for the next weeks/months), which is the file formats management and documentation. The element representing this in the P7 project is libg1m, using other utilities in the p7utils (which in fact regroup all of the binary utilities linked to the project in general). All of the documentation is in the headers, see the main header and the formats headers folder.

There is yet another part about mastering CASIO's encoding. I've made, and am managing, the FONTCHARACTER reference, which is made in Yaml, and is distinguished from any other source files in order to be usable in any other project. It contains information about the character name, representation, flags, tokens (CTF, CAT, Casemul, ...), Unicode equivalent, et caetera. I am making a library aside that uses it to offer some conversions functions callable from C, the libfontcharacter, but this is a young project which might take an other orientation later (like not including the reference in the library itself, but loading external files, making it accessible to update these instead [runtime!], but making it more difficult to cross-platform).

The last part is about accessibility of this project to the end user. After the command-line utilities (the p7utils), there is a GUI project, p7gui (by someone else back at Planète Casio). There is also a Python 3.x module, pyp7, which basically serves as an interface to basic libp7 interactions.

Who's working on this?
I'm the creator and almost only developer of all of this. I have received some contributions to the FONTCHARACTER reference, and other minor things (someone else started e-activities support in libg1m, and someone else started adding the --no-init/--no-exit options in p7).

Currently, a contribution system is not set up on libp7 and libg1m, I'm working alone on these as, at least, contribution guides need to be made (for the coding style, what type of contributions I'm accepting, et caetera). I'm trying to train myself on making them on another project of mine, libcarrot, which is an alternative fxlib/libc for the fx-9860G, so don't worry, I'm on it.

On the other side, I'm accepting contributions to the FONTCHARACTER reference (which, once it is done, can contribute to everyone, so don't hesitate to contribute to it instead of making your own thing beside!). Also, if someone would like to take over the libfontcharacter, I'd be glad.

I hope that my project will be useful to you, and thanks in advance if you want to contribute/help in any way

Those transfer commands are quite useful - I wonder if there is a windows version of that utility please?

Well, everything can compile on Linux for Microsoft Windows (with ./configure --target=i686-w64-mingw32, DLL and EXE files will be generated, just test with wine to make sure you have all the DLLs, and put everything somewhere in your Microsoft Windows installation).

But I recently had problems with the CESG502 driver. In fact, I want to manage it and serial drivers, but the CESG502 has a different read buffering logic than everyone else : where serial drivers (like FTDI ones) copy what's available and waits for more, CESG502 fails if you don't give him a buffer large enough. The two ways of managing the buffer are incompatible. A month ago, I asked for a solution on MSDN, and some solutions were given (at the end), but I couldn't make them work and eventually more or less abandoned for now.

So either replace CESG502 with a WinUSB driver, wait for me to correct this (it might be in a few months, considering I'm on Linux and Windows isn't my top priority at all), or go ahead and try to correct it (the stream is there). Sorry for the disagreement (thank CASIO).

Sorry for double posting earlier - i must have left my iPhone screen on while putting it away.

I don't have any linux machines to compile unfortunately - do you have a compiled windows version to test please or some easy way to compile this on windows directly perhaps? No rush at all - any time which suits you

Thanks again

Here you go. This is the in-development version of p7/libp7, and it should not work with the CESG502 driver, but if you replace the CESG502 driver by WinUSB as said earlier, or if you use a serial cable (SB-88(A) doesn't work yet, use active cables, see this), it should work.

And honestly, the fact that it can run under Windows is enough for me, this platform not being made for developers IMO. But if you think this is important, you can still suggest how to modify the build utilities so this is buildable under Windows
Also, and I have to try that again, it doesn't build under Cygwin yet, but that's something I'll have to investigate.

Thank you

It is an interesting project.
Thank you for adding the extended command of C.Basic to FONTCHARACTER reference.
I develop it now in the CASIO official SDK of Windows,
I think that development on linux is necessary in port to CG10/20/50.
I wish your project will have many more successful years.

Well, as I'm trying to be as complete as possible, it seems normal to me to also add extensions. If I'm missing any step (character/opcode), just tell me, I'll add it! (by the way, I hope it also helps you to look for characters you might be overwriting :p)


Linux is love, Linux is life. We have GCC, POSIX-compliant shells, plenty of utilities, a real developement-friendly environment, everything you can dream of. And if there's something you're missing, well, probably not for long :p

And thanks! I think it should be finished in a few months (if I don't encounter too many Pandora's boxes), all that will be left to do is to make the platform-specific applications of the abstractions (streams, buffers, ...), and to add the things that'll come out. :p

Thank you for your kind reply.

About C.Basic,
Because the extended command code has not yet hardened,
If the stable version is completed, I want to inform it.