TL;DR: the syscall names in libfxcg really need to be revised, even if at the expense of breaking backwards compatibility.
---
Recently I was showing some C code I had written for the Prizm to a friend, and he asked me "what strange function names are these". I explained that they were syscalls ("like library functions") and I could not change their name at whim. Obviously, the issue was that some of the names were really bad, and definitely not obvious, even for simpler syscalls.
I told him how most names came to be, that is, based on what was used in legacy SDKs and Simon Lothar's documentation. He pointed out that with these names it must be horrible to code for the Prizm, and I have to agree.

Let me point out the main issues I found with the current syscall names.

1. Many don't succinctly describe the function of the syscall, and a minority even gives wrong hints.
Some names don't mean much and are extremely ambiguous, while others are excessively verbose. Some examples:
- Box (what does this do? does it draw a rectangle on screen? just the outline of a rectangle? does it draw the 3D shape of a box? a decorated window? Looking on the Wiki it seems it's related to message boxes. We won't really know without testing it, because the name is all we know from Simon's docs).
- DisplayMainMenu (one could think this opens the proper Main Menu, but it appears to only draw it to screen - no interactivity. A better name could be DrawMainMenu).
- GetGetkeyToMainFunctionReturnFlag (this one could have a much shorter name, like GetMainMenuAvailability or GetMainMenuFlag).
- Bdisp_EnableColor (it turns out that when this function is not called, color is still enabled, it's just not full color! Why not call it Bdisp_FullColor or Bdisp_DisableIndexed, etc.)

2. Many of the names have strange or inconsistent suffixes and prefixes.
While the idea of adding prefixes to names to make it more clear what category they belong in (poor man's version of namespaces) isn't bad in itself, the way it's implemented leaves much to be desired.
Some prefixes don't make much sense, often things in the same category have different ones and some lack prefixes. Some examples:
- Bdisp AllClr VRAM (not that bad; it appears most display functions use Bdisp, and the suffix VRAM to indicate they operate in the VRAM...)
- Bdisp ShapeToVRAM16C (OK, it's a display function, operates in the VRAM... what is the 16C? 16 colors, maybe...)
- Bdisp HeaderText (is it in VRAM? DD? how many colors?)
- PrintXY (VRAM? DD? why doesn't it have Bdisp in front?...)
One could think that Bdisp is only for lower-level functions and not for text drawing, so here's one for you: Bdisp_WriteSystemMessage.

Also note the random "OS" designation:
- Bfile_GetFileSize_OS, but Bfile_DeleteEntry has no OS
- Print_OS and PrintXY (does that mean PrintXY is not implemented by the OS, since it has no OS suffix?...)
- GlibGetOSVersionInfo (what exactly is this Glib I don't see anywhere else?)
- Bkey GetAllFlags (hmm, a keyboard function... is it implemented by the OS?)
- GetKeyWait_OS (wait, turns out this is a keyboard function too... why doesn't it have a prefix then?)

(note that personally, I'm not a fan of the whole Bdisp / Bkey / Bfile... thing)

3. Overloaded variants of syscalls have strange names
It's not unusual to find syscalls that have multiple versions, with different number of parameters or slightly different meaning. But the names are awkward. For instance:
- ProgressBar (ok, it's a progress bar)
- ProgressBar2 (hmm, another version of the progress bar. Turns out this one allows for a custom caption, why not call it ProgressBarCaption or something instead?)
- ProgressBar0 (zero? a overloaded function of ProgressBar, oh well... but zero?)
- SaveVRAM_1 (where's SaveVRAM_2? I mean, it's good to account for yet-to-be-found syscalls, but so far none have appeared and it's been, like, three years...)

4. Naming conventions are not consistent
The way functions are named doesn't seem to adhere to any common standard, and doesn't appear to be consistent within libfxcg either. Some examples that clearly show why my friend called libfxcg "The International Festival of Naming Conventions":
- App_InitDlgDescriptor
- APP_FINANCE
- App_LINK_Send_ST9_Packet
- APP_SYSTEM_LANGUAGE
- App_Optimize
- APP_EACT_StatusIcon
- SMEM_MapIconToExt

My proposal is to just rename everything using a single set of rules (to be discussed), and to make things easy, not caring about backwards compatibility (it's not like people couldn't always check out an old version of libfxcg to be able to build old code trees, and in fact they'd need to do it anyway, because there are always things changing), and make sure that syscalls added from then on follow that set of rules.

The way things are now, it's a nightmare for new developers to understand anything, and it's very hard even for seasoned Prizm programmers to know the name of a certain syscall off the top of their head (was that in all caps? with underscores maybe? perhaps it doesn't start with Bdisp?...).

Discuss.

My biggest issue is as soon as we differ from Simons or the old calculators SDK naming convention even if the functions become better self documented we'll end up with a lot of existing documentation being useless.

My other worry is this is a lot of work for a platform that hasn't seen much activity and where 3rd party development has lead to bricking of multiple calculators and last I knew the cause is still unknown as to how it happens or it is at least not 100% preventable.

The only existing documentation sources I know about which are important and organized (or at least, "intended to be organized") are the Prizm wiki and Simon's docs.

Simon's documentation is, IMHO a nightmare to consult. It is also not being updated at the rhythm it used to, as he also seems to have moved on to reverse-engineering more recent Casio platforms (which are doubtlessly more closed than the Prizm). These were some of the motivations for completing the syscall documentation in the wiki, which I now use primarily. In the wiki, it's easy to add redirects from the old syscall names to the new ones, and the redirects (which can be listed) can act as documentation for "what changed".

Simon's docs can be very ambiguous in terms of names (I think I have seen two syscalls with the same name), and the only safe way to distinguish them is by their number. Lots of syscall descriptions also point to syscalls of the fx9860, which are usually quite similar but have subtle differences one has to watch for.

The lack of development activity may make it seem not worth it, but then again, if people were thinking in terms of worthiness when the whole Prizm scene started, then nothing would have been done and libfxcg wouldn't even be a thing. I know this community has pretty much moved on (despite the HP Prime and the Casio Prizm being the only two powerful calculator platforms where 3rd party development is not actively fought by the manufacturers), which doesn't mean there aren't still people interested out there, and much less that the remaining people can't fix their own tools "just for fun".
Besides this, I don't think it's such a big amount of work: there are about 250 documented syscalls, plus a few more undocumented which are in Simon's docs and the notes of other developers, but not yet on libfxcg (and thus would not need renaming). After a sensible naming convention is decided upon, I could go through all syscalls in less than a week (and that, assuming every name needs to be changed and that it will take very long to think about each new one).

As for the bricked calculators, I know of a couple of cases of bricking (and other faults, like broken keyboards) that happened with people who had never installed custom add-ins (which means that the bricking is definitely not always "our" fault), and the majority of cases can probably be explained by this: http://www.cemetech.net/forum/viewtopic.php?p=234487#234487
There are other few situations where the bricking was a definitely a result of playing with fire (my and AHelper's cases), but renaming known and widely-used syscalls is not something I recognize as "playing with fire"...

But since big-endian is dead[1], and the Prizm's SH4 runs in big-endian mode, I guess it doesn't matter anymore?
[1] http://thread.gmane.org/gmane.linux.kernel/1930358/focus=1937733

would it be possible to achieve backward compatibility still in terms of new naming convention and legacy names still compiling, basically new library would have new and old names referring to the same system call?

I think it's possible, I only suggested not to keep compatibility in order to make things easier in the future. Having to deal with the "minicompat" headers in libfxcg is already bad enough (and I think I've seen people suggesting they be dropped, something I agree with), having to keep dozens of syscall headers for "oldfxcgcompat" would be even worse.

F. i. PrintXY, locate and Bdisp_AllClr_VRAM are the original names of the CASIO SDK function.
In 2008 we (that is me and the great Andreas Bertheussen) tried to follow the naming conventions, which were difficult to recognize. Obviously there have not been any!
After we found about hundreds (and then some) of syscalls, we ceased to care. Even the 63 CASIO SDK functions havn't been named following a uniform convention. CASIO did not take their own SDK very seriously.

But believe me: The real nightmare is going down into the depths of the OSes, finding the secrets, which are not names, but functions and know-how.
You have to fight evil spirits like calculated jumps, pointers to tables of pointers to tables of pointers to tables of pointers, undocumented customized hardware features and then some...
I watched C-beams glitter in the dark near the Tannhauser gate...oh, sorry, I wander from the subject (BTW: who happens to know this quote's movie?).

Back to the problem, which seems to be not this big.
Declare some - in your opinion - well named function based on a - in your opinion - bad named function, without loosing the bad named function's interface.
Perhaps read the story of the Tower of Babel beforehand.

When analyzing and documenting the Prizm-syscalls in 2011, my primary goal has been to recognize similarities to the legacy systems.
Every detected similarity helped in understanding the Prizm. It would have been very confusing, if the names would have been changed in this course.

Additionally, using the same naming allows the use of similar or even identical source code parts for both systems.
NOTEVIEW is based on this concept.
But this only applies to people who code for both systems, which - I admit - are a minority.

Thanks for your insights, it's nice to see you posting at Cemetech.

Yes, I know that the names of some functions were copied or inspired on the limited set of syscalls available in Casio's SDK for the fx9860G. However, I believe there's not much good in staying with these names, because as you say not even Casio themselves have any naming convention. The only advantage of having the same names as the Casio SDK is to be able to copy code between SDKs. For the Prizm, that doesn't matter much, because there was never an official SDK and, as far as I know (correct me if I'm wrong) the few people still making Prizm add-ins today, use libfxcg and not miniSDK and friends.

There's also a big enough amount of differences between the legacy platforms and Prizm that make it hard to reuse code. Your Noteview program is proof that it's not impossible, but for example I think making my Utilities add-in or Eigenmath port available on both systems using the same code tree would be a big headache, with lots of preprocessor magic and rendering the code very hard to maintain.

I know it's hard to come up with names for the syscalls and it's even harder to find what each one does exactly, because when we are just starting to find out what a given piece of machine code does, we're not even absolutely sure about its function and purpose. The disassembled code is a mess, because it was compiled with at least some level of optimization, and of course compilers were not made to produce readable assembly. Furthermore, it appears to me that at least some parts of the OS were written in some language that allows function overloading and default parameters (i.e. C++), which after compilation turn up as structures like EditMBStringCtrl, EditMBStringCtrl2, EditMBStringCtrl3, EditMBStringCtrl4... that is, one version for each possible amount of parameters (and then one has to find out what each parameter does...).

Finally, Casio appears to just have some sort of post-processor that enumerates all the symbols (including tables and the like) and dumps them into the syscall table, irregardless of a given syscall being appropriate for exporting or not (some were definitely not made to be run from add-ins). This means that the syscall table contains both high-level, important functions which interest us, and "fragments" that really don't do much and weren't even made to be run alone, but as part of a well-defined process. I absolutely agree this is a nightmare to explore.

But after the "dirty work" is done, I think it is important to give things a nice finish so that they are easier for other people to understand and use. That is my idea when I say that some syscall names need changing. I brought up this discussion so that we can find out how comfortable people are with breaking compatibility with existing code, whether people don't mind trading Casio SDK-based names for more structured names, etc.

I know that "fixing" the syscall names in a way that most people will like will be really hard. That's another reason why I wanted to discuss these changes. If it turns out that people don't feel a need to change anything, or that an agreement can't be reached, then I'll just fork libfxcg for my own software and go speak my own "language" to my little corner of the "world". Since right now not many people care about Prizm development anymore, it can't do much harm if I fix the things for myself.

I would have already provided some examples of what I'd change, but did not because I don't want people to mix up discussion between "the need of changing things" and "the way I would solve the problem".

I agree using names similar to those used in legacy systems makes it easier to see the similarities. But as we find more and more things about the Prizm, perhaps it's time that the "inheritance" starts going back around (that is, older calcs benefiting from the work done in understanding the Prizm). I think it would be interesting if libfxcg, or something like it, was expanded to target other Casio platforms more easily, making it possible to use GCC instead of the Renesas compiler and replacements for the Casio libraries and tools which are not very easy to use (as you said, Casio did not take its own SDK very seriously).

As I've said before, it appears the fx-CG series is Casio's last "3rd-party-programmer-friendly" platform (I shall not say "hacker-friendly", because that word has bad connotations nowadays). Or in other words, the "damage" is done, and Casio has already started locking down stuff, even if in ways that, for now, are relatively easy to break. So I think we should make it a bit easier for people to tinker with the Prizm and to fully understand its secrets in depth.

FWIW, what you're proposing is a more comprehensive version of the existing MINICOMPAT settings.

http://prizm.cemetech.net/index.php/SDK_Compatibility