December 05, 2021, 04:29:34 AM


Now with 20% more walruses

Join us on Discord!
You can help CodeWalrus stay online by donating here.

Show posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Topics - Lionel Debroux

Over the past few days, the word has started spreading about a ~university project of a team of 25 French students working part-time for several months, which yielded the Symbolibre graphing calculator effort, based on modern, cheap hardware components and
open source / libre software :)
I'm not involved in that project, I'm just relaying news. To date, most information about the Symbolibre remains written in French, AFAICT.

It's based on a $5 RPi Zero module without networking capabilities (not a "W" model), which brings hardware characteristics previously unheard of on a graphing calculator: 1 GHz ARM CPU, 512 MB of RAM + e.g. 8 GB of Flash (well, whatever one puts inside the internal SD card slot). Only the Prime G2 isn't completely dwarfed by this. The screen is 320x240, like all other graphing calculators with ""high-resolution"" screens.
On the software front, unsurprisingly, it's running Linux, and therefore, it enjoys the widest collection of user-space programs, including giac/xcas, a full-blown Python implementation with a full-featured IDE, etc. There's a screenshot taken on a computer, so it looks like there's a computer version of the software.
They used 3D printing for the case and also keyboard buttons, though their pictures don't show the keyboard buttons.

The best aspect, and it's not surprising, is that the Bill of Materials, detailed in at least one of the topics linked below, amounts to around 80€ in the current setup, and can be decreased by using other power circuits... yes, 80€ is just about the (commercial) price tag of a TI-83 Premium CE or a NumWorks calculator, both of which have immensely weaker hardware characteristics.
Technically, the Symbolibre has much more raw power than needed to run the cores of CEmu, the NumWorks simulator, TilEm and TIEmu, though the input (keyboard...) and UI might be less obvious. Firebird should work, but I'm not sure about full speed emulation of a CX, let alone a CX II in the future.

In France, there's (fortunately) no official list of calculators allowed for the main standardized tests, and as long as the SD card slot is not user-accessible during an exam without opening the case (it isn't), such a calculator probably wouldn't run afoul of stupid standardized testing constraints, especially if a blinking LED is added. This requirement of an exam mode with blinking LED was supposed to be enacted last year, after a 3-year notification period, but it wasn't, because unsurprisingly, many pupils still only had working, but older, models without exam mode.

One of the students is an administrator at Planète Casio; two of the TI-Planet admins (critor and Bisam) met the team and saw the calculators for themselves on April 3rd and 4th. The project was publicly showcased at the ~university on April 4th.
The students' plan is to keep developing the project as time permits, of course. And judging by the interest the project is generating, they might receive external contributors, like NumWorks :)

Official site:
Forum topics in other calculator communities: , , .
We'd like CW people to be informed of a set of exciting recent developments for TI's current higher-end models, and what they could mean for us hobbyists as well as educational users :)

A quick recap of recent events:
  • a month ago, TI released OS 5.1.5 for the 84+CE and 83PCE. This version features several bugfixes, but more to the point of this article,  new TI-Basic USB I/O commands (Get, GetStr, Send), as well as the ability to receive input from an USB HID keyboard out of the box, provided one has the appropriate USB mini-A male <-> USB A female (or equivalent) cable.
    Pictures of the keyboard mappings were recently uploaded to, and people can contribute to them :)
  • more recently, TI released OS 4.2 for the Nspire CX series. Besides the announced features (new graphing capabilities, etc.) and the unannounced anti-features (downgrade protection, blocking Ndless 4.0 but that was quickly fixed by Ndless 4.2, etc.), this OS version also brings the same new TI-Basic USB I/O commands, as well as a new set of APIs for Nspire Lua, the "Asynchronous Serial Interface". The commands are described in their respective programming manuals, with examples, e.g.
Get "READ GREEN 1", green1
Wait 0.5

Looks like TI wants to provide the same kind of serial I/O compatibility on the USB-only models as they did on the models with legacy I/O, which is a good thing for increasing the versatility of their calculators, and probably for selling more of them !

Using the new Nspire Lua ASI APIs, Jim Bauwens, Adriweb and critor tried to determine which cheap USB devices exposing a serial interface might be supported. The Nspire computer software detected the devices which the computer detected as serial communication ports, but the real Nspire calculators didn't detect most of them. Out of the box, the Arduino boards and a TI Stellaris board were not detected by the calculators. However, a TI Launchpad MSP432 board with USB IDs 0451:bef3 was detected. It exposes a standard USB Communications Device Class (CDC) interface, and Jim had his Arduino Leonardo board (which exposes that same interface) detected after changing the USB IDs - so there's some filtering.
You can check your own boards using the testing code uploaded to as well, and report on your results ;)

TI probably has good things in store (well, they added such features to their OS for some reason, we should assume :P), we can just hope that they won't be too expensive for end users.

For more details and pictures, see:
Since the previous public build, there have been, guess what... improvements and bugfixes :)
Excerpt of the changelog:
  • internal: added per-handle pre / post receive and pre / post send hooks functionality. It's the foundation for more interesting stuff which shall be implemented later.
  • added DUSB packet dissection to libticalcs and CLI front-end to it. It makes it possible to input packets straight of, say, Wireshark, and have them analyzed in a human-readable way:
Enter calc model (usually 13, 14, 18-21): 14
Enter raw DUSB packet as hex string of up to 4 * max raw packet size (non-hex characters ignored; CTRL+D to end):

0000002E (04)                                                   | PC>TI: Virtual Packet Data Final
        00000028 {0007}                                         | CMD: Parameter Request
                00 13 00 0A 00 08 00 02 00 03 00 04 00 06 00 07
                00 09 00 0B 00 0C 00 0D 00 0E 00 0F 00 10 00 11
                00 1E 00 1F 00 2D 00 4B
Requested 19 (13) parameter IDs:
        000A (OS mode)
        0008 (Device type)
        0002 (Product name)
        0003 (Main part ID)
        0004 (Hardware version)
        0006 (Language ID)
        0007 (Sub-language ID)
        0009 (Boot version)
        000B (OS version)
        000C (Physical RAM)
        000D (User RAM)
        000E (Free RAM)
        000F (Physical Flash)
        0010 (User Flash)
        0011 (Free Flash)
        001E (LCD width)
        001F (LCD height)
        002D (Battery level)
        004B (Exact math engine)
  • added automatic detection of 83PCE vs. 84+CE. When USB scan at startup is enabled (it has been by default for years), TILP will now correctly detect 84+CE calculators, which used to be detected as 83PCE calculators. This item was implemented thanks to the previous feature;
  • added 7 new functions related to screenshots: one receives and converts the result to RGB888, five convert raw screenshot data from the calculator to RGB888 (four of them used to be part of TILP, but they belong to libticalcs), and the last one is a helper for freeing screen data returned by ticalcs_calc_recv_screen() and ticalcs_calc_recv_screen_rgb888() (part of the ongoing software engineering work to abstract the memory allocator behind libti*, so that clients have fewer hard-coded g_free() calls).
The usual links:
EDIT in 2021: updated the link to the *nix install script.
Powered by EzPortal