@critor, I can't reproduce the problem on Casio's fx-CG 50 emulator.

It seems the drawRectangle function stopped working properly on real hardware:
https://github.com/gbl08ma/eigenmath/blob/master/src/graphicsProvider.cpp#L289

I guess it's probably due to the hardcoded VRAM address. But since it works correctly on the emulator, they must have changed it only on real hardware or it might be specific to the French version.
This means that not all fx-CG10/20 add-ins will be fully compatible with the Graph 90+E and maybe the fx-CG50. Add-ins will only be fully compatible if they are checking the VRAM address through the proper syscall, GetVRAMAddress. Utilities does not exhibit this problem, because it uses this syscall. See the following issue and associated commit:
https://github.com/gbl08ma/utilities/issues/28

Eigenmath has the VRAM address hardcoded, so it is not fully compatible.

Unfortunately, even though the solution is simple, I don't have the means to fix this now and I don't foresee having them any time soon. I no longer have a development environment set up. With a bit of luck, and if you nag me about this by then, I'll have some days in mid-summer I can allocate to this.
My add-ins are only supported on the fx-CG 10/20 platform until further notice.

Since I don't have much time right now, I hope someone spreads the news about the possible VRAM address incompatibility in other forums.

Only one big capacitor used... my Prizm which has undergone repair came back with none... the earlier Prizm models had two. Interesting.

Also, RAM that's not an epoxy blob. This might make unbricking a bit easier, given the right tools...

Quote from: DJ Omnimaga on March 29, 2017, 06:22:13 AM
Have you tested the compatibility of this new emulator? I remember that some add-ins had speed issues in the old fx-CG manager (I think something about timers behaving the other way around, such as short timer delays lasting much longer while long timer delays last much shorter, but I could be wrong since it has been half a decade since I read about it) and IIRC some also had key input problems.

The emulator appears to be based on the exact same technology as the one for the previous model, so it's unlikely any of that has changed.
The OS and official add-ins don't need simultaneous key presses to work, so they don't need to emulate that.
The CPU clocks and timing appear to be as poorly emulated as on the previous model.

The fx-CG 50 really is just a fx-CG 20 with a different shell, higher CPU clock, French model and exam diode, and a OS that has a different UI theme. Plus a few new add-ins, which as we are finding out, work on the previous models as well.

Utilities seems to work fine: https://www.cemetech.net/forum/viewtopic.php?p=258204#258204

The only really incompatible thing so far is the looks of the main menu icons. Probably that can only be solved by providing two g3a, for each model, that while otherwise identical, have different icons. Everything else can be solved using model/OS detection inside the add-ins.

The big question remains, which is whether add-ins for the older model will work on the new one.

At this rate, the only way they wouldn't be compatible, was if Casio purposefully did something to block them.

I just pushed an update for Clouttery for Windows that was preventing the client from working in certain time zones (in fact, about half of the world!).

The only reason I found out about this was because this night lots of European countries including mine entered daylight saving time.

This is all the more embarrassing because an extremely similar problem had already been detected when we exited DST. I'm pretty sure that at the time I tested the fix with multiple timezones, and the problem didn't occur. Now, and for future reference, I did the same, for time zones ranging from UTC-12 to UTC+12. If things go south again next October, I think I'll lose my mind.

I just realized, if you want something in the same vein as the riddles in this thread, but quite a bit easier, you can try looking at the message format used by the Clouttery API:

https://api.clouttery.xyz/

There are actually additional modes, including encryption after a session is established, POST requests, etc.. If people are interested I can set some things up and post details for more entertainment

Actually the speedup can be explained by the different CPU clocks alone, even though it's possible they did further optimizations to the 3D app. This is because not only the CPU clock is higher, but the peripheral bus is probably also clocked higher, making it possible to achieve higher frame rates. There's also the possibility that finally Bdisp_PutDisp_DD is not blocking (although that would break compatibility with older add-ins, that could modify the VRAM while the DMA transfer is in progress...), but I find this very unlikely. It's also possible that different planes produce wildly different rendering times (it would be strange, but seeing the bugs related to calculation time on the latest Classpad...).

 

The only thing that looks really out of place is the icons, and that's only because of the white background. The key labels are not in the same place, as we had already discussed at Cemetech, but that's not too bad.
Let's hope for a 03.00 OS for the fx-CG 10/20 with a white main menu (or some sort of clever runtime icon patching to get rid of the white background).

How thoroughly have you tested the add-ins? I'm still kind of surprised they don't depend on any new syscalls, and that the syscall table has not gone through major changes.

Also, given that, as far as I could understand, the add-ins were transferred from a prototype fx-CG 50, it's quite possible that once the add-ins are released (on the internet and on consumer units), they will have added some checks to prevent running them on earlier models. Not that such checks would be hard to patch out...

Out of curiosity I decided to take a look at the Linux client written in Go that I was writing before I decided going for Python instead.

After removing all webkit4gtk related stuff and compiling it with the latest version of the GTK3 bindings, it actually worked better than I expected.

So if you want to try it, check out:
https://clouttery.xyz/static/linux/v0.1/x86_64/clouttery-nix
SHA256 sum: bcfc3e893c3a1a6a3074a6639303e11cfc30c8f36422946007d0c1d51b6b1040

Requirements: a relatively recent version of GTK 3.
It's a (mostly) static Linux binary, chmod +x it and run.
It will create a config.json file on the same directory where the executable is the first time it is run. So it's not a good idea to copy it to any system directory. Keep it in your home directory for now. Later I'll add the option to specify a config file path, and make it look under ~/.config by default, etc.

What works: you find out (not much).

If people can actually use this, I guess I'll try to build a Linux client on top of it instead. It's much easier to package a Go program as a single binary, with assets and everything, than a Python program.

Did you follow the instructions to install the required packages? I think some of them are not available in Windows, namely the GTK bindings might not work correctly.

I'm not racing for posts

Right now, the officially supported operating systems are Windows and Android. Some work has been made on a Linux GUI client, but it isn't finished yet. I even sent @DarkestEx a alpha version for testing, but never heard back, and looking at the server it doesn't seem like he's ever used it. From my testing, it works, but installing it requires lots of different packages, that aren't called the same on all distros (and some must be installed through pip as they aren't in the distro repos). I tried to package the app (which is written in Python) as a single binary, using multiple methods, but all of them failed, namely due to how the GTK bindings work.

iOS support will require at least $1500-$3000 in profits/donations, since I'd need Mac hardware for developing and the Apple dev account for store publishing, and of course some real iOS hardware would more or less mandatory, since I suppose the battery stuff and standby synchronization is kind of hard to test on the simulator. All of this, assuming of course that Apple even made the necessary battery info APIs available (I think we already discussed this a while back, but I don't remember the conclusions?).
A client that can only show information for other devices in your account would be more or less useless, for that you might as well just use the website.

Data is currently stored in one of my VPSs in the US. Data is encrypted in transit (without any MITM like Cloudflare proxies), options for protecting the data while stored in the database are being studied. It's kind of hard, because the server should be able to open the data up for analysis, this means that it would need to store any encryption keys, making database encryption pointless.

EDIT: I forgot to mention, but earlier today I fixed a problem that was preventing the pairing of new devices. This also meant that new users were having trouble signing up. All should be fixed now.

I mentioned some posts ago that I was working on a complete redesign of how the Clouttery server stores data.

It was using a simple key-value store (Bolt). I slowly came to the realization that some of the features I have planned would be kind of hard to implement using Bolt; that the nested buckets structure used with Bolt was too limiting, by forcing a hierarchy (or interpretation, if you wish) on the data. The databases course I took last semester forced me to get my hands very dirty with SQL, and after seeing the benefits, I decided to move to a relational database.

Another reason for moving was that Bolt can't scale (no replication, it's meant for use by a single app, like SQLite), and while the server software is not yet ready to be clustered, moving away from Bolt (and, in general, uncoupling the server from the database) is a giant step towards that goal. I had known for long that I had to use something other than Bolt if I wanted to make the server distributed, I just wasn't sure whether to move to a relational database, another barebones key-value store, or some amalgamation of solutions involving specialized time series databases or what-have-you.

The database can now be accessed transparently by multiple applications, which means that, for example, in case I want to do some complex analysis on the battery histories, I no longer have to stuff that code into the server. I can even use a language other than the one the server is written in (Go), like Python, which I really don't like but has many libraries for data analysis.

Clouttery is now powered by a traditional PostgreSQL database.

The changes were pushed to production less than a hour ago - after extensive testing on the staging environment, which unfortunately didn't catch all the bugs.
A few hotfixes later, everything appears to be working fine.

It would be great if over the next few days users could pay a bit more attention to the behavior of Clouttery, namely making sure that battery histories are updating as they should, and that notifications are generated when they should, according to their settings.

I'm available to answer questions about the database design (both the new one and the previous one), the reasons for the switch, or really anything. I'm a bit too much proud of this (until I find out more horrible bugs...) so I really want to talk about it but I don't know where to start

Yeah, I won't buy it either: I barely use my fx-CG 20 now (in fact, its batteries are empty right now and I keep forgetting to charge them), and it doesn't look like I'll have much use for a graphic calculator in the next few years. I have way more pressing stuff to spend my money with...
But if I was going into high school now and the fx-CG 50 was available and custom native code was not crippled, I'd go for it without any doubt. Because if it was locked down, then I'd go for anything else, perhaps even an older generation fx-CG 20 or something from TI.

On the fx-CG 20, the screen could be updated much, much faster than BASIC could. The bottleneck is on the BASIC interpreter and/or the graph system it uses for all drawing commands, not the screen.

They probably increased the CPU clock to be the same as on the fx-CP 400. Since the OS apparently didn't change much, I suppose the speed feels like a fx-CG 20 when overclocked. The Main Menu probably has a much smaller delay when opening...

The message versions are already at 03.00 which confirms that will probably be the OS version at launch.