The new OS adds an auto-parentheses insertion feature and the list of supported projectors has been updated. Also, there is a new version of the Geometry add-in.

The updated manual lists a new Prizm device: fx-CG20 CN
Could be a Chinese version.

At the moment I do not see another way to bypass the CG10-restriction.

OS modding is a last resort only.

I have another idea:
Instead of cracking the image checksum and changing the type ID (which is hopefully not required for decompression, because this would mean complete repackaging using zlib), couldn't we just modify the image converter to write the ID 0x3C1B instead of 0x789C before the checksum calculation takes place? Worth a try...

Holy crap, the image converter does not seem to be protected.

Won't that completely nullify the point of them making the CG-10?

Yep.

So this will allow us to change the Prizm Startup screen and system screens?

As far as I know, these are simple bitmaps inside the OS. On legacy models, OS patching is not too complicated from within an add-in as you can use flash writing syscalls. But I don't know if the Prizm adds extra security against modifications. Well, the OS checksum is already known.

These CASIO guys are funny. They had a Catalog Help implemented on the fx-9860 slim and dropped the idea with the following systems.

This is Casio's policy for years. The help functionality is an exclusive fx-9860G Slim feature.
Or compare this with the fx-7400GII series: The predecessor had 20k of RAM and a crappy display. What did Casio? Took a totally crippled fx-9860GII code base and a piece of sh** of LCD, just to "convince" people this is a refresh of a legacy design.
They could have used an fx-9750GII without USB instead.

I meant, what's the difference between .g3b and g3p files?

Sorry, I did not expect such a basic question.

.g3p is the Prizm's image format
.g3b is the Prizm's animation format
The latter is only used along with the Picture Plot add-in.

All hacking has been stopped because of recent concerns expressed by the community.

KermMartian writes:

I am one of the Prizm hackers who had been expressing concerns on #cemetech. I've been in various contact with Casio marketing and engineering personnel over the past year or so, and they have made it clear that they're currently turning a blind eye to mature, responsible third-party hacking. Officially, they're supposed to both not support it and potentially disallow it, but that hinges on how we behave. [...]

We do not want to drive Casio into the same cat-and-mouse game the Nspire developers have to work around.

---

General header format:

AAACBDAF90889A8D _xFF_yFF_yFF..FE
_a_a_a_a.._b_c_c 00000000_._._d_d

_x : file type
- .g3a=0xD3; .g3e=0xB6; .g3p/b=0x82; .g3m=0x8A

_y : unknown
- if (.g3a) then 0xFE else 0xEF

.. : check bytes
- upper=LSB_of_a+0xBF
- lower=LSB_of_a+0x48

_. : CP check bytes
- rightmost=if (Casio Provided) then LSB_of_a+0x85 else LSB_of_a+0x17
- leftmost=(checksum of LSW_of_a) + ...
-- if (Casio Provided) then (.g3p/b=0x9B; .g3e=0xCF) ...
-- else (.g3p/b=0x09; .g3e=0x3D; .g3m=0x11)

_a : inverted file size

_b : unknown
- if (.g3m) then 0x01 else 0x00
- could be related to _d

_c : unknown
- if (!.g3a) then 0x0000
- seems to be unrelated to _a

_d : inverted element count
- if (!.g3m) then 0x0000

The .G3P format:

A 32-bit ckecksum seems to be stored at the end of the image data block (starts at 0xD0), but before any footer. The procedure to calculate this checksum is not known. Without disassembling the Prizm's CAPTURE routine, further analysis appears to be a waste of time.

References to zlib inside the OS imply they are using this for data compression. Also, it is not known if the type ID at _o (see below) is required for the decompression part.

AAACBDAF90889A8D 82FFEFFFEFFF..FE
_a_a_a_a..000000 00000000_._.0000
4350_b_b_b_b_c_c _c_c_c0000000000
_d_d_d_d0000_e_e _f_f_f_f00000000
00000000000000_g 0000000000000000
0000000000000000 00000000000000_h
00000000000000_i 0000000000000000
0000000000000000 0000000000000000
0000000000000000 0000000000000000
0000000000000000 0000000000000000
0000000000000000 0000000000000000
0000000000000000 _b_b_b_b_j_j_j_j
??_k_l_l_m_m???? ????????_n_n_n_n
_o_o???????????? ????????????????

Main header:
.. : check bytes (see 'General header format')
_. : CP check bytes (see 'General header format')
_a : inverted file size

Sub header:
_b : if "CP" then 0x00010000 else 0x30313030
_c : if "CP" then 0x00 else 0x4C79373535
_d : file_size - 0x20
_e : if "CP" then (0x0001 or 0x0009) else (0x0A09 or 0x0009)
_f : file_size - (0xB8 + _g + _i + _h)
_g : if _e=0x0001 then 0x00 else 0x8C // length footer 1
_h : if _e=0x0A09 then 0x2C else 0x00 // length footer 3
_i : if _e=0x0A09 then 0x?? else 0x00 // length footer 2
_j : file_size - (0xCC + _g + _i + _h)
_k : if CAPTURE then 0x01 else 0x00
_l : image_width
_m : image_heigth
_n : file_size - (0xD0 + _g + _i + _h)
_o : type ID (see 'Sub formats' below)

Sub formats:

"CP" format with _e=0x0001 and _g=0x00
- no footer; Casio Provided (ID: 0x3C1B)

"CP" format with _e=0x0009 and _g=0x8C
- one footer; Casio Provided (ID: 0x3C1B)

"CP0100" format with _e=0x0001 and _g=0x00
- no footer; CAPTURE Format (ID: 0x388D)

"CP0100" format with _e=0x0009 and _g=0x8C
- one footer; Converter Format (ID: 0x789C)

"CP0100" format with _e=0x0A09 and _g=0x8C; _i=0x??; _h=0x2C
- three footers; Casio Provided (ID: 0x3E93)

The .G3B format:

A 32-bit ckecksum should be stored at the end of the image data block (starts at 0xD0), but before any footer.

AAACBDAF90889A8D 82FFEFFFEFFF..FE
_a_a_a_a..000000 00000000_._.0000
4350_b_b_b_b_c_c _c_c_c0000000000
_d_d_d_d0000_e_e 00000000_f_f_f_f
0000000000000000 0000008C00000000
000000000000002C 0000000000000000
000000_z00000000 0000000000000000
0000000000000000 0000000000000000
0000000000000000 0000000000000000
0000000000000000 0000000000000000
0000000000000000 0000000000000000
0000000000000000 _b_b_b_b_j_j_j_j
_l_l_m_m???????? ????????_n_n_n_n
_o_o???????????? ????????????????

Main header:
.. : check bytes (see 'General header format')
_. : CP check bytes (see 'General header format')
_a : inverted file size

Sub header:
_b : if "CP" then 0x00010000 else 0x30313030
_c : if "CP" then 0x00 else 0x4C79373535
_d : file_size - 0x20
_e : if "CP" then 0x0492 else 0x0092
_f : file_size - (0xB8 + 0x8C + _z + 0x2C)
_z : if "CP" then 0x10 else 0x00 // length footer 2
_j : file_size - (0xCC + 0x8C + _z + 0x2C)
_l : image_width
_m : image_heigth
_n : unknown length
_o : type ID (see 'Sub formats' below)

Sub formats:

"CP" format with _e=0x0492 and _z=0x10
- three footers; Casio Provided (ID: 0x3C1B)

"CP0100" format with _e=0x0092 and _z=0x00
- two footers; Casio Provided (ID: 0x3C1B)
- two footers; Converter Format (ID: 0x789C)

The wiki seems to be unreachable at the moment.
And don't shut this down. There are some direct links to the wiki pages.

I guess, some bug fixes.
There was no news on the front page...