Planète Casio - Tout le forum - Flux RSS http://www.planet-casio.com Programmes Casio, Jeux, Cours pour Calculatrices Casio fr-FR https://www.planet-casio.com/images/logo.gif Planète Casio - Tout le forum - Flux RSS http://www.planet-casio.com 55 50 Programmes Casio, Jeux, Cours pour Calculatrices Casio. Sun, 08 Nov 2026 19:00:53 GMT Sun, 08 Nov 2026 19:00:53 GMT contact@planet-casio.com (Planet Casio) contact@planet-casio.com (Planet Casio) 5 Investigating the slow file transfer of calculator under Linux https://www.planet-casio.com/Fr/forums/topic19765--.html One of the longstanding issues I encountered when switching from Windows to Linux is the file transfer of Casio USB mass storage calculators between both platforms. That is, Windows is much faster than Linux in this case. For instance, transferring a 3.4 MB KhiCAS MPM add-in to my Graph Math+ takes about 3-4 minutes in Linux, whereas it is only 30 seconds at most in Windows. To figure out what happened during the write operations, I decided to capture and dissect these UMS packets using Wireshark, and I have to say this is wild. For context, UMS devices are managed by the `usb-storage` driver in Linux. The parameter `max_sectors` controls the maximum amount of data that will be transfered to or from the device in a single command. Its default value is 240, which means a maximum transferred data size of 120 KiB where a sector is 512 bytes. The send retrial happens when dCSWDataResidue is non-zero and bCSWStatus = 0 (partial success), and its maximum is SD_MAX_RETRIES = 5. dCSWDataResidue must represent the difference between the amount of data expected from dCBWDataTransferLength and the actual amount of data transferred. Let's take look at the 1 MB file capture in Linux. Applying `usbms.dCBWSignature` filter: https://i.imgur.com/htTLfBs.png Each 4096-byte packet advances LBA as expected and has a duration of 0.01 s. Keep this delta in mind because it will be important later. Now you can see the following 6 packets of 120 KiB data are at LBA = 0x5e70, and it is the same for the next group at LBA = 0x5f60 and so on. Applying additional `usbms.dCSWSignature` filter and zooming in LBA = 0x5e70: https://i.imgur.com/jNxLHom.png The calculator USB driver reports dCSWDataResidue = 118784, implying it only receives 122880 - 118784 = 4096 bytes from the host, and here is the problem. If the calculator really receives 4 KiB of data only, its delta should be the same as the one for the previous packets which is 0.01 s. However the value here is 0.3 s, thus having the same flash write speed, i.e. 4096 / 0.01 = 400 KiB/s and 122880 / 0.3 = 400 KiB/s. Combining with the fact that bCSWStatus = 0x00 (Good), this indicates the 120 KiB of data is actually written to the calculator storage on the first packet, and its driver is lying about the data residue that misleads the Linux SCSI driver to re-send the exact CBW command for 5 times. In Windows case, USBSTOR ignores the entire field and continues to send the next CBW, hence a faster speed. Even worse, the misleading residue also affects the read operation, which leads to a detection failure that surfaces whenever I update systemd to 261 or higher. Lephenixnoir has previously documented on this matter and identified that it was due to the constant I/O errors generated from the USB calculator. Taking an example from his libblkid log: [ +0.000011] sd 0:0:0:0: tag#0 CDB: Read(10) 28 00 00 00 01 f0 00 00 10 00 [ +0.000006] I/O error, dev sda, sector 496 op 0x0:(READ) flags 0x880700 phys_seg 2 prio class 2 [ +0.028607] sd 0:0:0:0: tag#0 FAILED Result: hostbyte=DID_ERROR driverbyte=DRIVER_OK cmd_age=0s The 8th and 9th byte of CDB `00 10` represents the transfer length that specifies the number of contiguous logical blocks to read. Here 0x0010 = 16 blocks * 512 bytes = 8 KiB, which is larger than 4 KiB and triggers the bug. We can reproduce this with the following bash script, and the expected result would be "ok" for the first 4k and "EIO" for the rest. for bs in 1k 2k 3k 4k 5k 6k 7k 8k 9k 10k; do sudo dd if=/dev/sda1 of=/dev/null bs=$bs count=1 iflag=direct \ 2>/dev/null && echo "$bs ok" || echo "$bs EIO" done Linux has various "USB quirks" flags to deal with finicky storages, and the relevant one for our calculators is US_FL_IGNORE_RESIDUE in `drivers/usb/storage/unusual_dev.h`. The following patch was submitted to the upstream Linux kernel by Cakeisalie5 and is under review. Thanks @Cake <3 UNUSUAL_DEV( 0x07cf, 0x6102, 0x0100, 0x0100, "Casio", "fx-CP400", USB_SC_DEVICE, USB_PR_DEVICE, NULL, US_FL_IGNORE_RESIDUE ), UNUSUAL_DEV( 0x07cf, 0x6103, 0x0100, 0x0100, "Casio", "fx-CG50", USB_SC_DEVICE, USB_PR_DEVICE, NULL, US_FL_IGNORE_RESIDUE ), While waiting for the merge, you can immediately apply the equivalent fix with the following commands: echo "options usb-storage quirks=07cf:6102:r,07cf:6103:r" | sudo tee /etc/modprobe.d/casio-usb-quirks.conf sudo modprobe -r uas; sleep 2; sudo modprobe -r usb-storage; sudo modprobe usb-storage The temporary alternative is to set `max_sectors_kb` to 4 so that every read is then split into 4096-byte commands and the residue arithmetic never goes wrong: echo 4 | sudo tee /sys/block/sda/queue/max_sectors_kb sudo udevadm trigger In a nutshell: https://i.imgur.com/VhgWee0.png Fri, 06 Nov 2026 20:12:13 +0100 <fstream> in fxSDK https://www.planet-casio.com/Fr/forums/topic19761--.html I was tempted to rewrite my C project in C++, but GCC complained that <fstream> is not available in free standing mode. I'm not quite sure what that means. Did fxSDK implement that or only <stdio.h> is availble? Thu, 05 Nov 2026 10:48:51 +0100 first ever J2ME emulator for the fx 9860G series https://www.planet-casio.com/Fr/forums/topic19760--.html Recently i finished making the worlds first ever J2ME emulator for the fx 9860G series (.g1a). It currently only runs KoalaMines but i plan to hope to add compatability for more apps in the future. Now, I will admit it was AI-Assisted, but hopefully this doesnt devalue what this program has done. If you want to try it, it's avaliable at https://github.com/Legendary-Games-Studios/fxj2me, i also attached the first version below Thanks for reading and i hope you enjoy it! :) Wed, 04 Nov 2026 22:00:23 +0100 mot de passe change tout seul ? https://www.planet-casio.com/Fr/forums/topic19759--.html mon mot de passe a changer tout seul, je sais que je peux faire mdp oublier mais j'aimerais bien savoir pourquoi sa a changer tout seul (le mot de passe de base je l'ai notée sur un papier en plus) Wed, 04 Nov 2026 20:38:47 +0100 new python library: gama(game engine for casio_fx-9750Giii) https://www.planet-casio.com/Fr/forums/topic19757--.html this link should hopefully bring you to the project page: https://www.planet-casio.com/Fr/programmes/programme4666-last-gama-tcmods10-a8.html this is a AABB game engine python library that was typed out and developed by tcmods10, he wrote it over the course of a month and then came back to it a month later to add level loading from a 2dlist. every line was written using the calculator's built-in keyboard, screen, and text editor, and tested likewise on the calculator... but the interpreter is the pythonExtra add-in's interpreter. features: AABB physics objects world gravity per object gravity multipliers static and non static objects tying a gint.image to a physics object, or just drawing it as a square tying 2 objects together(it is kind of a rubber band effect, the joint itself doesn't collide with anything it just clips through all objects. it works by testing if the objects are too far away from each other, and then pushing them towards each other if they are too far away from each other) loading a level of squares tied to a grid from a 2dlist that is a coordinate plane allowing for faster collision with the world instead of testing collisions with abstract positions velocity(or energy) transfer on collision uses a step function to call the math, and has a function that draws the world if you want it to draw the world for you this project is completely modular and was designed to be a library... and runs on less than 50KBs of ram(I haven't measured it's ram usage directly yet but i tested it with the interpreter, gama, and a program using gama on top of those on the 50KBs of ram that the casio fx-9750Giii has. and it gave the game that was using gama a seemingly reasonable amount of ram) I would be deeply honored if you used my library. enjoy Thu, 29 Oct 2026 15:47:13 +0100 Looking for Statistics Software / Recherche de logiciels de statistiques https://www.planet-casio.com/Fr/forums/topic19755--.html Bonsoir, Je ne parle pas français, donc ce message a été traduit à l’aide de l’IA. En raison de la barrière linguistique, il m’est parfois difficile de naviguer sur ce site et de trouver ce que je recherche. Je suis étudiant à l’université aux États-Unis et je suis des cours de statistiques appliquées aux affaires (business statistics) et de méthodes quantitatives. Certains intitulés de cours et certaines expressions ne se traduisent peut-être pas directement entre nos systèmes éducatifs, mais je me demandais s’il existe des applications ou des add-ins pour la Casio fx-9750GIII (j’ai appris qu’elle porte un autre nom en Europe) qui pourraient être utiles pour les statistiques, les méthodes quantitatives, les probabilités, la régression ou d’autres matières similaires. Je peux traduire moi-même la documentation, les menus etc. Ma principale difficulté est de parcourir le site et d’identifier les programmes susceptibles d’être pertinents. Si quelqu’un pouvait me recommander des applications utiles ou des catégories à explorer, je lui en serais très reconnaissant. Merci beaucoup pour votre temps et votre aide. Merci Y'all, Un Américain ignorant Mon, 26 Oct 2026 04:57:23 +0100 Serial (3-pins) dans gint, ça progresse gentiment ... https://www.planet-casio.com/Fr/forums/topic19753--.html Salut la Commu, désolé j'étais pas très actif en "ON" en ce moment car j'ai passé beaucoup de temps en "OFF" sur un sujet que j'ai eu du mal à faire avancer mais qui me tenait à cœur : le serial dans gint. Il y a un bon moment j'avais encapsulé les syscalls de l'OS dans une librairie LibSerial, mais on avait le plus grand mal à s'en servir et la philosophie de gint consiste autant que faire ce peut, à avoir un vrai driver et ne pas appeler les syscalls. J'avais commencé à faire du RE sur l'OS 3.60 (oui ça date un peu) de la G90+E et on avait intégré avec Lephé dans gint les entêtes décrivant le SCIF, mais sans vraiment s'en servir. Ces derniers temps, j'ai donc retranscris "au propre" les fonctionnalités de communications via le port série (asynchrones seulement) pour que l'on puisse à terme les intégrer à gint. J'ai pu aussi regarder du côté du SH3 avec un dump (merci Ghidra et la bible Casio) de l'OS 2.01 de la fx9860G. Pour le moment, voici ce que j'arrive à faire (il y a encore des trucs qui plantent, c'est pour cela que je ne pousse pas encore de PR): - 2 machines identiques communiquent parfaitement (2 fxCG50, 2 fxCG100, désolé j'ai pas pu tester sur les autres) - 2 machines différentes communiquent aussi : testé sur fx9860G (SH4 et SH3), fxCG 20/50/100 et bonne surprise fxCP400+E (honnêtement je n'y croyais pas trop, mais rien ne change a priori sur l'utilisation du SH4 entre fxCG et fxCP pour la partie serial) ! - la subtilité des machines "overclockées" est gérée, on peut recalculer les paramètres de connexion en fonction de la fréquence, et souvent même sans tuer une connexion déjà ouverte. Avant de releaser, j'aimerais avoir la négociation du baud rates, mais cette partie ne fonctionne vraiment pas à ce stade. Je sais que certains travaillent sur la partie "son", pour moi c'est complètement hors scope, je me suis focus seulement sur l'aspect communication série. Je vous en dis rapidement plus, je vais avoir qq jours de vacances bientôt, je devrais pouvoir finaliser à ce moment là. A plus. Fri, 23 Oct 2026 08:32:50 +0200 Downtime du 21 et 22 Octobre https://www.planet-casio.com/Fr/forums/topic19752--.html Planète Casio a été mis en maintenance le 21 Octobre (ce Mercredi) pour gérer la correction de deux vulnérabilités importantes de PHP, dites "php2shell", jusqu'au 23 Octobre (Vendredi) dans la nuit. Avant cet épisode, Planète Casio tournait sous PHP 7.3 avec le framework Laravel 6, i.e. des antiquités. Officiellement seules les versions 8.2 à 8.5 (la dernière) ont reçu des patchs. Il y a eu des backports pour 8.1, 8.0 et 7.4, qui ont été appliqués par notre hébergeur, mais rester sur 7.3 ne se justifiait pas. J'ai donc profité du downtime pour migrer la v4 vers PHP 8.2 avec Laravel 10 et les dépendances qui vont avec. Ce travail a été fait avec l'aide précieuse d'Eragon sur les montées de version des paquets et des conseils de redoste sur l'infrastructure interne. Le site est normalement complètement opérationnel, mais il est possible que vos rencontriez une 500, auquel cas veuillez bien sûr la faire remonter. ^^ À bientôt sur Planète Casio ! ;) Fri, 23 Oct 2026 04:21:41 +0200 p3 - a graphical shell/os-like for the fx-cg50 https://www.planet-casio.com/Fr/forums/topic19748--.html Hey all, it's me again, and I'd like to share one of my most developed projects: p³! https://www.usthreeink.com/public-dump/p3/pic1.png https://www.usthreeink.com/public-dump/p3/pic2.png https://www.usthreeink.com/public-dump/p3/pic3.png https://usthreeink.com/public-dump/p3/demo.mp4 p³ the PoC in the demo is short for Proof of Concept is a OS-like shell for the fx-cg50, built in MicroPython and based on ventris, aiming to do, well, basic shell stuff. Current features include: * login system (username/password) * stylable interface * running external programs since it's via import, only once; I'm looking for a workaround * saveable user settings * (WIP) pinning programs for easy running Admittedly, that's not a lot, but it's my first major project and it does what it currently does well enough, so :E . Also, like ventris, it was 99% programmed on my fx-cg50. Source is here: https://github.com/7amithorn/p3; the program requires ventris, with the ventris folder in the same folder as p3a. Thanks for having a look. Sun, 18 Oct 2026 08:04:23 +0200 Linux on the Casio's graphing calculator hardware https://www.planet-casio.com/Fr/forums/topic19747--.html https://i.imgur.com/8OE4SRH.jpeg Bonjour, everyone So far, I've managed to get the kernel loading through a .g1a application, and I've been working on SH7305 support, memory mapping, and Device Tree support for a full contribution. Update here as well: I'm not looking to target ROM system implemention, for newer models as this doesn't serve any warranty for your device's life and might void yours when it is unfixable. Please refer to Licenses on projects. =========================================== SUPPORT =========================================== FX-9750GIII is only supported device, FX-9760GIII family has not been tested yet, you can be the one testing it, reply on this branch. upd: cfx-9800 reverse engineering design is currently under development.. some work was implemented for FX-9750GIII but has not been deployed to that repository, also im looking to collect garbage on Forge Git as well. 4.1GB --> 2.7 via a .pack. Accessories i use: 2.5mm TRS breakdown wire (male tips), RPi Pico 2 (RP2350), RPi 1 Model B Rev 2.0. :E (i tried finding sb-88 or sb-62 locally, did not find any. manuals say it uses 2.5mm TRS as for the accessories), and vintage software Casio FA-121 on Windows XP, however main development is on Linux. Only regarding Casio CFX-9800G for contributers: To download FA-121 from archive.org library use wget or paste the link into the browser. wget https://archive.org/download/casio-link/FA-121%202.0%20%28Windows%29%20%281994%29.zip or use browsing via this link https://archive.org/details/casio-link Most resource is from: Cahute It is also very important for me that on this thread to drop some information about this calculator about this CPU that's inside this model. Thanks! ^^ ============================================================================================ CONTRIBUTION ======================================================================== Regarding any contributing 8-) . You can PR on Forge Git repository, and I would appreciate, not emailing any patches (git send-email to SuperH branch contributing, upstream) with code that has my name on it. And anything that has not been verified its either working or not. If you're the one who is using any LLM's or AI and is about to contribute with a PR request . YOU are responsible for testing and if anything breakes. :here: Reason I'm also opening this because I'm looking for volunteers who own Casio graphing calculators and would be willing to test Linux builds. Hardware testing will help verify that each calculator's development branch works properly before I submit patches to the Linux kernel maintainers. If you're interested in helping, please let me know which calculator model you have ;) . Forge Git (hyperlinked) Find latest patches here. Sun, 18 Oct 2026 00:08:26 +0200