How hard would it be to reverse-engineer Convert.g3a and see if we can get a CAS addin to give extra functions to Run-Mat mode? This actually seems to me to be ideal, since then we could have access to the functions in all modes.

This is just an idea, I realize that actually reverse-engineering the addin could end up being more difficult than it sounds...

I believe the Converter G3A file has no code in it, just a header with the icon, and that screen that says the file enables the converter function. It may eventually contain some magic key inside which the OS checks for. If that magic inside a Conv.g3a file is found, the OS makes the converter functions available. If not, conversion is not available.

This is what makes me support this theory of mine:
- On the Run-Mat OPTN menu, if the Conv.g3a file is not present, the space for the converter menu is still there, but blank.

- The function key icons for the converter menus are present in the OS itself and not in the add-in (I checked this with the help of INSIGHT). For example, I don't believe the icons "TMPR", "PRESSURE" or "FORCE" are used anywhere in the OS but on the conversion functions, and still, they are present in the ROM: icons 012B, 013F and 0139 respectively.

- There is no delay in accessing the conversion menus, ever (but this can be explained). I'd expect to see a hourglass even for just a fraction of a second when we enter the menu, because if the functions really are on the g3a file, then for executing code from it, it would need to be loaded. To load it, the file would have to be read. And the OS syscalls for file reading all display a hourglass even if the file is very small.
Let's admit the code was cached. It would need to be loaded at least once, at system startup (after reboot), when Run-Mat is run for the first time, or when the conversion menu is entered for the first time after a reboot. But I don't see an hourglass or any different delay the first time any of these are loaded...
If the conversion code was loaded at system startup, and then never get touched after, then deleting the Conv.g3a file in-calc wouldn't make the conversion menu disappear immediately after. If in your Run-Mat history there were any conversion "characters", they will be replaced with @ symbols that return syntax errors when executed (this is probably the only way to insert @ on the Run-Mat ). This kind of defeats my point saying the code isn't in Conv.g3a. But it may just be a clever trick by Casio. Then if the code is in Conv.g3a, how does it get loaded so fast, and without hourglass? I'm so confused now...

Hmmm... well maybe.

But the official SDK for the 9860 had an option for making the addin have an eAtivity strip.

Maybe we can't get it built in to run-mat, but we may be able to at least get an eActivity strip.

eActivity strips are possible, even on the Prizm OS. The Geometry, Picture Plot and Physium add-ins have one.

maybe is possible, in g3a structure there are some references to eActivity, like a icon with 64x24 pixels at adderess 0x0290, and eactivity app name in diferente languages...


but why we need it? maybe only to integrate in future a .png or .bmp image reader with eactivity (if anywone do 1)...but maybe never be released to avoid troubles with casio

(offtopic: I have a project for a PNG code, paused because of polemics with Casio "would be" lockdown of the platform, like TI did, blah blah... I'll probably just wait until the Prizm is an abandoned platform, like the ZX Spectrum, for finishing and releasing that PNG viewer...)

i found a great cas library (open source) pompt based and coded in c++/c

if anywone want port it to prizm, there is the source: http://5bm.60.sl.pt

Perhaps Convert.g3a just stores the values for conversion, so that any updates don't require an entire firmware upgrade.

Reo, most of the conversion values are simple decimal operations (e.g. converting square kilometers to square meters) and things that are not prone to change (e.g. 0 Kelvin is always -273.15 ºC). You have a point, though.

Is there any good disassembler for SH3 binaries?

gbl08ma, that's some great sleuth work about the mysterious Conv.g3a app. I must add one additional clue, though. I can use the Converter app to "end" other add-ins. If I run Graph3DP, then [MODE] out of it, run Converter and use [MODE], and re-enter Graph3DP, then Graph3DP restarts from the beginning. This makes me suspect that Convert/Converter shares at least SOME architecture with standard add-ins.

I turned into :-O when I look at the source code as it simplifies stuff by doing strcmp against hard-coded strings :-O

Yes, you can use the converter app to end other add-ins. I was not implying it was built-in into the OS (in my theory, the code for drawing the "this enables conversion" message is in the G3A) nor I was implying Conv.g3a is a "dead" file. But even if it was, well, you can use any built-in "add-in" to end other add-ins, so that makes your point invalid.

(If you run Graph3DP, then MENU out of it, run eActivity, and re-enter Graph3DP, then it will restart from the beginning, too. Do you understand what I mean? )

Conv.g3a shares all the architecture with standard add-ins - it is an absolutely normal add-in, the only thing it does (according to my theory) is showing that message in a yellowish background. So, of course you can use it to end other add-ins.

But, in my opinion, the core of the conversion functions is located in the OS and not in the add-in. The OS only uses the Conv.g3a file to decide if it should enable the conversion functions or not.

If the core of the conversion functions really is in the add-in, and the OS really is executing add-in code when the conversion functions are used, then I must say: loading add-ins through Run-Mat must be much faster than pressing EXE at the menu for loading them.

You see, there's little way executing code contained inside a file could ever be so fast. If you fill the Run-Mat history with conversion operations, then go to the top of the history and press EXE, the conversions will execute really fast - IMHO, there's no way it could be loading an add-in to execute the line, each time.
And if you ever want to bother yourself, you can also fill Run-Mat, starting with simple operations like 7*9 and sin 34, and then (when you've filled about half of the Run-Mat history list) with operations like 4[cm]>[ft]. Go to the top of the history and execute.
You'll see the algebra operations (first half) will run as visibly fast as the conversion operations (second half). I did this experience myself.

Either the conversion code is cached, or it is contained in the main OS code.
I'd like to be proven wrong, it would be a sign someone still cares about this mysterious (at least I think it is) conversion thing. I believe it even opens possibilities for OS modding, if the conversion code is cached - or we could learn to cache our own add-ins in Run-Mat, making e.g. a CAS add-in be much faster and practical!

You know, I wonder if they make conv.g3a so teachers can delete it if they dont want their students to use conversion functions.

if we rename Conv.g3a to a random name, conversion doesnt work:
(only tested with emulator)



... i also tested rename a random add-in to Conv.g3a and also conversion doesnt work

my theory: system shearch for add-in Conv.g3a, and use some part of this add-in code (or check the size, etc...) to active or disable conversion functions (as gl08ma said, maybe this conversion function is part of the OS)

in fx9860, we doesnt need any add-in to use this function, it is native...

Thanks for testing, helder7. If in the fx9860 the function is native, and since Casio basically ported the OS from it to the Prizm, I think that supports my theory the conversion code is contained in the OS. The OS must perform some check on the Conv.g3a file, it may check its size and/or look for a specific bit sequence inside it.



I believe that's the point Casio made this an add-in (which according to my opinion is just a switch to enable/disable the conversion function). If it was native on the fx9860, you can consider this "switch" an upgrade, from the technical side, because more code was written in order to enable/disable the function.

I'm going to do some more testing... like creating a random (junk) file with the same size as the Conv.g3a file, and calling it Conv.g3a and putting it in the calc, then see what happens.

EDIT: nah, a junk file with exactly 29180 bytes doesn't enable the conversion function. Now I'm going to open the original Conv.g3a and look for something that could be used as a "fingerprint" of the file.

EDIT2: I didn't find anything special, but looks like only the last ~1020 bytes of the Conv.g3a file are executable code. In other words: apart from the g3a header, there's little in that file.

more useful than shearch about enable/disable conversion, is shearch by multilanguage system

@helder7: We already know how that works, it's using PrintXY_2. Read here: http://prizm.cemetech.net/index.php?title=PrintXY_2

Hmm, i would guess that it just uses Print_XY2, which auto-translates

No, it doesn't auto-translate like Google does (it doesn't work with any string, just strings that already exist in the OS).

only works with msgno (not custom text)