And then? If the idea was to explain how Casio add-ins do it, here it is. They probably have an internal list with all the translations for every string, then they just have a Print_XY-like function on all the add-ins that checks the system language and selects the appropriate strings. Or alternatively, all the strings used in the Casio add-ins are already contained in the OS (very strange, almost impossible).

My theory: Casio put the conversion algorithms in an addin so that if a bug exists in the conversion rates or anything, they can just release a new addin rather than a new OS. The menu structure is part of the OS, so the addin doesn't control it.

ignore my other post, i dont read any documentation since may (busy, etc)...
the add-in use msgno 907,909,910,911

edit
texts like Energy1, Energy2, etc... is saved in Os Messages List



...

Oh, yeah, sorry, thats what i meant. But the strings will auto-translate, as in you do not have to hard-code strings for different languages into the addin.

You may have to hard-code strings into add-ins, because I don't believe Casio already planned strings like those found on Physium when they designed the OS... or was that one of the reasons the update to 1.03 was mandatory to use Physium (and 1.04 to use the new Geometry App)?

After checking the strings helder7 points, I believe the translations really need to be put into the OS. In other words, if we want translations in our own add-ins, we'll have to implement our own PrintXY_2 but with a list of strings for our add-in.
(this is pretty stupid - it means that at every add-in Casio develops, they'll have to release a new OS version in order to have translation...)

Another interesting strings I found (OS 1.03; 1.04 has updated language): http://tny.im/eu
The conclusion I take after analyzing these strings:
- Once upon a time, the OS was much more complete in terms of battery settings. You could select other battery types (Alkaline, Ni-MH, Manganese and "Chargeable"!), you could select the battery brand (what's the use for that, anyway?) and the battery capacity (probably for "chargeable" batteries). The calculator probably could charge the "chargeable" batteries as there are strings for that, as well as Function key icons.
- There may have been a password lock (for system "login", not for username protection)
- The add-ins store their translatable strings in the OS itself... except Physium (unless these are on really high indexes I didn't check).
- The last four strings seem to be from a (removed/hidden) Import/Export functionality.

I guess a separate topic for "Prizm OS curiosities" should be created, as well as some of this information should be copied to the wiki...

To relate this with the topic: I'm now more sure than ever that the Conversion functionality isn't in the add-in, but in the OS (also, the strings for the Conversion add-in appear way before then those for Picture Plot or Geometry, which probably indicates it was developed before these two).

i think, the latest geometry add-in version need os 1.04 because it need more language translations

add-in Physium only use 4/5 strings from "calculator translations base" (tittle, etc)

and have their own language system:

On OS version 1.04 the Portuguese translation changes a lot, and I'm not going to upgrade because I fear losing these "Manganese batteries" strings. Like I suspected Physium uses its own translation strings (adding strings to the OS for each element would take too much space).

I would guess that the battery issue may have been the other way around. I think that in the beginning, they probably wanted to allow more battery types, but later decided for some reason not to.

Also, about charging batteries, it would be awesome if we could make an addin to charge the batteries (assuming we could find the syscall, etc.)

...and how is that contrary to what I said?

In that I don't think the OS ever actually supported it.

Not the public versions at least. I meant to say "once upon a time" as in "during development..."

Also, the fact that the Prizm can be powered and run perfectly fine just with USB power (in most situations it will refuse to, though. When you take off the batteries, the calc will think its batteries are so low it will shut down in a few seconds) may indicate it was originally designed to charge a special battery pack sold by Casio which they decided to never support.

Hmm.. ok, that makes sense.

now, im shearching for strings in OS, i found today references to:


apparently the OS use this library: http://gailly.net/

ps: maybe should be to create a thread to OS curiosities/exploration.

The OS has built-in compression and decompression features for g3p pictures, and there are syscalls related to that. If the OS has Gailly's library, then it's probably zlib, and it is used for g3p pictures (I see no other place in the OS where things are compressed). But zlib is also used for PNG...

If zlib really is in the OS and we manage to isolate it to a point where we can use it as if we included it ourselves in our add-ins, then developing a PNG-viewing add-in or a file archiving add-in will be easier.

That's a great find! Now we at least know where the compression routines come from

Added your post here.

Not to mention potentially compressing files and programs and decompressing them on-the-fly, but that's something that will require us to have more of a shell at that point, I think. Certainly something that I would be interested in...

Is there any news about a cas for the Prizm?

Actually, there is, unless you already know about AHelper's work with libc++ and xcas/giac. He is trying to get it to run on the Prizm, and has made a lot of progress in getting a version of libc++ to work on the Prizm. He has let the project lapse a bit with the semester starting, but I trust that he'll get back to it at some point.

I'm already more than half way done with my quarter here, so I will have free time in 4 weeks to work on giac again, or just getting another OS on the Prizm that will fully support libc and libstdc++ (POSIX features as well) to support giac without modification.

regarding conv.g3a add-in: I'm 100% convinced that it would not be possible to have extra functionality in it directly to enable CAS in Run-Mat.

All conv.g3a is needed for is for Runmat to be able to verify it by:
1) file name: "conv.g3a"
2) two particular strings at two addresses in the file above
3) and (unfortunately) the checksum of the original conv.g3a in the usual places

First couple of requirements are super easily achievable, and the last one as far as I could see is only achievable with add-ins of quite small size as their size impacts the checksum and if it exceeds the original conv.g3a's one the add-in will be rejected by RUN-MAT and convert option will disappear.

Hope it is not too hackish to be posted here - let me know if the above should not be shared for whatever reason please