http://www.planet-casio.com Programmes Casio, Jeux, Cours pour Calculatrices Casio fr-FR https://www.planet-casio.com/images/logo.gif http://www.planet-casio.com 55 50 Programmes Casio, Jeux, Cours pour Calculatrices Casio. Wed, 11 Nov 2026 19:01:19 GMT Wed, 11 Nov 2026 19:01:19 GMT contact@planet-casio.com (Planet Casio) contact@planet-casio.com (Planet Casio) 5 https://www.planet-casio.com/Fr/forums/topic19770--.html Je cherche comment optimiser le calcul de `xor` entre deux octets en BASIC. À l'origine c'est pour générer les codes d'erreur de QR codes, mais ça pourrait potentiellement servir ailleurs... je suis preneur d'idées. Il y a bien la commande `xor` du mode BASE, qu'on peut utiliser en mode normal si on écrit l'opcode direct un g1m avec un éditeur hexadécimal (vu qu'il est pas dans la catalogue et qu'on peut pas copier/coller en mode BASE), mais ces commandes binaires sont leeeentes. Pour vous donner une idée, sur ma Graph 75+E, sans overclock : For 0→I To 255:Iand255:Next '7.30 s (!!) For 0→I To 255:I Rmdr 256:Next '1.30 s C'est pas super étonnant dans la mesure où les nombres en BASIC sont stockés en BCD (en base 10) donc les opérations binaires sont pas rapides, mais là c'est vraiment catastrophique. Du coup je cherche des alternatives arithmétiques. Voilà mon benchmark... For 1→A To 4 Locate 1,1,A For 100→I To 115 For 100→J To 115 IxorJ Next:Next:Next:ClrText '26.90 s (!!) Dans la suite, tout reste fixe sauf la ligne `IxorJ`. La seule piste qui marche à peu près pour l'instant est de coder la fonction sur 4 bits dans une matrice 16×16 et de recombiner les deux moitiés à la main : 16MatA[1+I Int÷ 16,1+J Int÷16]+Mat A[1+I Rmdr 16,1+J Rmdr 16 '20.10 s Sachant que `MatA[1+I,1+J] = IxorJ`, précalculé. J'ai aussi essayé dans une liste, en espérant que je gagnerais sur le calcul mélangé des indices : 16List 9[1+16(I Int÷ 16)+J Int÷ 16]+List 9[1+16(I Rmdr 16)+J Rmdr 16 '20.76 s Avec `List 9[16I+J] = IxorJ`, précalculé. La variation où les bits du haut sont obtenus par soustraction est plus lente : 16List 9[1+I-(I Rmdr 16)+J Int÷ 16]+List 9[1+16(I Rmdr 16)+J Rmdr 16 '23.20 s Je suis un peu à court d'idées, je me demandais si y'a pas moyen de tricher avec d'autres fonctions hardcodées, e.g. donner une expression de A xor B comme `List 1+List 2[A+B]`, mais y'a pas de solution pour cette forme-là et je sais pas trop par quel autre bout la prendre. Wed, 11 Nov 2026 15:06:35 +0100 https://www.planet-casio.com/Fr/forums/topic19769--.html Now the crash issue,reported bucket bug,and saving failure was completely addressed on fx-9860GIII.Infinite world generation and walls are also introduced.(To be exact, the idea of an infinite world actually comes from the limitations of RAM.It seems that PRAM on fx-9860GIII can be only used to read or write inside it.When i tried to save the info in PRAM,they disappear) You can download it at https://github.com/caiji-xd/terrario (forked from KBD2's repository）.The repo is also under MIT License and CC 4.0 License. The game theoretically can alse work well on fx-9860GII.Incompatible with fx-9860G. Mon, 09 Nov 2026 10:48:57 +0100 https://www.planet-casio.com/Fr/forums/topic19768--.html Hello :sry: I'm looking for any information on the Hitachi HD62119A02, the CPU used in the Casio CFX-9800G. Does anyone know anything about its architecture, instruction set, or relationship to other Hitachi processors? Datasheets, documentation, or previous research would be nice to have (found none in bibliography) So far, I've found a few interesting references: https://martin.poupe.org/casio/ https://github.com/mamedev/mame/blob/master/src/devices/cpu/hcd62121/hcd62121.cpp https://forums.bannister.org/ubbthreads.php?Board=1&main=3073&type=thread&ubb=printthread https://www.shared-ptr.com/sh_insns.html The CFX-9800G service manual also provides a CPU pinout. It identifies a 19-bit address bus, an 8-bit data bus, and several I/O and control signals. The other identified components include a Fujitsu MB834000 4-Mbit ROM and NEC uPD43256 32K × 8 SRAM. As some of you know I'm planning to reverse engineer the CFX-9800G myself (for Linux), so I need to gather whatever information is already out there before getting started (so I don't spend 300 years implementing it). (and so it doesnt cost me a lot of money) Thanks! Mon, 09 Nov 2026 06:32:21 +0100 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. Lephe 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 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 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 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 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 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 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