The Background
It all starts from 2002. The two heated topics about calculators — actually only Casio® fx-3900Pv — were: n-in-1 programming and overstepping. Overstepping means to increase the space of storage of the calculator by hacking. This has been investigated throughout, from practical to theoretical, from 333% increase to 1333% increase… Every calculator programmer has devoted his/her heart to push the calculator to the limit. For what? The storage size of fx-3900Pv is only 300 steps distributed among 4 programs, which is insufficient for lagre programs. By increasing the storage size, larger programs can be installed. This also put forward the availability of n-in-1 programs. This kind of programs is actually a mixture of several small programs. The use of n-in-1 program had overcame the limit of 4 programs.
Most of the n-in-1 programs share the same structure. They all based on a modified form of Ken Kwok’s telephone book program. Therefore the programmers started to think: is it possible to write a computer program that generates n-in-1 programs according to user’s will? The answer is positive. Paladin (now the chairperson of HKACT) had created a document that guides people to make their own n-in-1 programs. But this is not a pretty solution; users have to search for their own subprograms among the five pages of commands and plug those into the frame for the combined program by themselves. It is not easy for those who do not know programming much. Moreover, it is easy to make mistakes during combining. Therefore, in mid-2002, the Javascript-based “n-in-1 program creator” (1.3 beta) was released. Comparing to the this, the current version (2.0) had little difference, except adding 7 new subprograms and the implementation of PKC.
PKC (Programming Keystroke Codes) was begun as a sub-feature of the creator. Its creation is to reduce typing error found in the older versions of the creator. In the creator, the PKC’s are shown as strings of hexadecimal numbers. To make editting simpler, individual encoder and decoder are created, both using Javascript as basis.
The PKC was initially kept as a “secret feature” of the creator, until the developer, KennyTM~ (now the vice-chairperson of HKACT), has told the other members of the HKACT on its “official chatroom”. At that time, HKACT was still not an “association”; it just exists as a “hobby group”. No one would expect HKACT grows into this extent in such a little time. Neither does PKC.
Evolution of SICK
Even though PKC seems to be a perfect way to store calculator programs, the developer had initially not considered to split PKC from the n-in-1 program creator. It was Zinedine Zhou (now also the vice-chairperson of HKACT) who proposed that PKC be developed individually and set as a standard for storing calculator programs. He also suggested that PKC be renamed as SICK (Standard Identifier for Calculator Keystrokes) for easy pronounciation.
SICK for Casio fx-3900Pv/3800P/3600Pv/50F used the old core as PKC, so the PKC encoder and decoder can be directly used as SICK encoder and decoder. But that is not all. Firstly, PKC is just for fx-3900Pv. However, fx-3900Pv, 3800P, 3600Pv and 50F are often considered as a group of calculator “fx-3x00” that share the same programming language. PKC lacks a number of commands unique to fx-3800P, 3600Pv and 50F. SICK adds those into the command table. Secondly, fx-3x00 was not the only programmable calculator series. There were Sharp® EL-5020, HP-20S and the new Casio fx-3650P/3950P. The command tables for those were created with reference to PKC. The standards for SICK was completed around the second official meeting of HKACT in mid-2003.
SICK standard composes of the following parts: CSI, CKISS and Display. “Display” is self-explanatory; CKISS (Computer Keyboard Input System for SICK), designed by Frandix (now the external secretary of HKACT) is an interface that commands are entered directly from keyboard, not pressing buttons like the PKC encoder. CSI (Calcuator Simulation Interface) is another input interface that simulates the keyboard a the calculator and retrieve the command according to the keystoke. It was suggested by Zinedine Zhou and implemented by KennyTM~.
The first implementation of SICK was the SICKGen, which was released in early-2003 as a demonstration program before the standardization of SICK. It is just an enhancement of PKC encoder — nothing else. Not until after the meeting. So there comes CalcProgGen.
CalcProgGen is not only a SICK encoder/decoder. It is a web page designer with built-in support for SICK. It supports the old PKC encoding, as well as CKISS and CSI. Saving and loading SICK files are permitted. It is so powerful that programmers do not need to typeset their programs manually — maybe.
CalcProgGen was still not as popular as PKC encoder/decoder. This was because CalcProgGen is “massive” compared to the encoder/decoder, platform-dependent, requiring quite a number of libraries and cannot be run online. Some programmers still like to typeset their programs by themselves for a better flexibility. It seems that using CalcProgGen to create webpages for programs is not useful at all.
Was SICK came to a dead-end? Not really. In late-2003, KennyTM~ created another program “Visual 3900”, which is an fx-3900Pv simulator. It uses SICK as the storage format of the programs. However, there seems to be no calculator website actually distributing SICK files.
SPICES Takes Over
What really makes SICK decline is the retrieval of fx-3x00 from the market. When Casio decided to stop the production line of fx-3900Pv, 3800P and 3600Pv to boost the sellings of fx-3650P and 3950P, everyone was shocked. Both PKC and SICK bear a close relationship with fx-3x00: almost all applications of SICK's target are toward fx-3x00. Nowadays, almost no new calculator-buyers know about fx-3x00 (Well, except the buggy fx-50F). They are all using fx-3x50P now. SICK was getting sick in late-2002 when fx-3x50P was out, and we declare it is incurable now.
SICK is actually not a really good system, especially after the introduction of fx-3x50P. The complete internal command table of fx-3x50P was received in early-2005. The exciting thing is that, the computer can communicate with fx-3x50P directly without much translation; the weird thing is that, there are command sharing. For example, the code-point A0 is shared by both “∠” (the cis function) and “xnor”. SICK is not capable for this: SICK is CKISS plus displaying, one code-point for one command, that’s it. Moreover, all special commands not exist in the internal command table like f(A) is a part of SICK too, which may cause error in the calculator (the calculator cannot recognize what is f(A)). Besides, SICK can only be exported to HTML or plain text; if I want to use SICK in TEX system, you will either have to install a package that converts HTML to TEX or just accept it is fated.
No? I don’t think so either. Therefore the idea of SPICES (Standard Programmable Identifiers for Calculator Enumeration and Storage) is born. SPICES is an enhancement to SICK. However, unlike SICK, which was just a closed standard within HKACT, SPICES attempts to collect infomation from the public before standardized. What the user’s requirements can be fully reflected.
SPICES enhance SICK in quite a number of aspects. First of all, SICK can only take 8-bit code points but SPICES can take any size upto 2048-bit, so a large variety can be included for complicated programs. Also, there are “special code-points” and modifiers that overcomes many problems due to limitation of internal command table. Finally, SPICES allows input method other than CSI, CKISS and “encoder”, and display as formats other than HTML and plain-text. To summarize, SPICES is SICK with much more extensibility.
For instant, the code-point A0 functions as “∠” in <CMPLX> mode, and “xnor” in other modes. So we can set up a modifer called mode that responsible for recording the current mode, and the code-point A0 is set such that it will work as “∠” when mode is CMPLX, and “xnor” otherwise. How about f(A)? We just create a special code-point to represent that. But there are also f(B), f(C), f(X), f(n), f(Σx3), and f(A, D)! Don’t worry. We can create a category of special code-points, and put them into this category.
Was this over? Not really. Put forward your idea in the forum and make SPICES better!