fx-9860gii-2 brief introduction

[Mjim]

(11-20-2019 10:21 PM)Hlib Wrote:  Battery drain in C. BASIC is almost the same: in program execution mode it is 22 mA at 5.5V (0.12W). Also, this app can run without affecting the main 60K RAM memory of the calculator.

Thank you for testing this. That seems pretty similar to what Sentaro21 gets with his other app ftune:
https://pm.matrix.jp/ftune2e.html
23mA without overclocking on the SH4A

Pretty interesting to note as well that the SH3 version of the fx-9860GII draws nearly twice the current at 43mA at stock speeds. Maybe Casio just copied the old SH3 fx-9860GII power consumption figures for the newer SH4A version.

In any case it seems pretty hard to hit 0.7W. How would you get close to this sort of power consumption?

(11-21-2019 08:13 AM)klesl Wrote:  The running of the program is different situation, Yo can expected such behaviour since the values assigned to variables are volatile.
It's the same situation similir to the Windows, when I turn the PC off (or sleep or hibernate) during some activity (e.g.video conversion), the activity or result is lost.

I was more worried about the "Main Memory" files and the Run-Matrix history in RAM being backed up; and it sounds like it is based on your input...I've now impulse purchased a fx-CG50 (please don't tell me it actually forgot your files after all now ).

I would of liked to get the fx-9860GII-2, but the price is pretty much the same as the fx-CG50, so it seems worthwhile going with the fx-CG50 for the additional OS features (though mostly minor, for example; integrating between roots in graphing mode automatically), Python and being able to make use of the xcas port.

I'm still curious though as to exactly what stuff is retained on the SRAM versions (CG-20/10/9860GII) vs the SDRAM fx-CG50.

[Eddie W. Shore]

(10-10-2019 10:25 PM)toml_12953 Wrote:  

(09-29-2019 08:47 PM)Hlib Wrote:  In recent years, it has been repeatedly noted that new models of graphing calculators have
too much power consumption at a relatively slow computational speed unlike their classic predecessors from the 1990s.
https://comp.sys.hp48.narkive.com/Zq0obS...onsumption
https://www.hpmuseum.org/forum/thread-4856.html )
I purchased the fx-9860gii-2 (OS 2.09) to get to know a typical modern member of the CASIO family. It is equipped with the custom SH-4AL(SH7305) without FPU made for CASIO. The device is supplied with two cables: SB-62 and USB mini type A.

I just bought an fx-CG50. It's Basic is very compatible with the 9860 and it also runs Micro Python. While the Basic is pretty fast, Python blows it away! The full color screen is easier on the eyes (IMHO) than the 9860. I still like my 9860 but the CG50 is my new toy. I keep discovering new things about it.

I hope to see Python expanded on the fx-CG50. Currently, it's kind of limited.

[Dave Britten]

(11-23-2019 02:42 PM)Eddie W. Shore Wrote:  I hope to see Python expanded on the fx-CG50. Currently, it's kind of limited.

According to the last post in this thread, Casio is at least planning to add graphics capabilities.

[Hlib]

Bernard Parisse wrote in this topic
"...here in France the Prime is about twice the price of the Casio Graph 90+e (local name of the CG50), and that`s the main reason why I worked hard to port Xcas to the Casio, the Prime is considered too expensive by most French students..."
Another author wrote: "...CASIO does not respect Japanese market ... SD version, fx-CP series, etc are not sold here in Japan. ... I bought imported fx-9860GII, the price was almost half of Japanese market price. I`m afraid probably many guys here are not aware of this."
CASIO currently sells 90% of its calculators in the European market. The high quality, availability and low price of these products may contribute to the popularity of graphic calculators. I regret that Hewlett Packard has not been able to fill the market in large numbers with calculators like hp-50g, 48gii, 48gx, Prime G2. Quite naturally, some of my friends bought at the stock sale NIB fx-9860gii for €25, and not HP or TI.

[xerxes]

Thanks to Hlib and Mjim for your tests. I've made some further examinations to find the best solution in C.Basic, ending up with this code:

Code:

0->A~Z
8->R
R->Dim A
For 1->N To 10
0->X
0->S
Lbl 0
X=R=>Goto 4
Isz X
R->A[X]
Lbl 1
Isz S
X->Y
Lbl 2
Dsz Y
Deg
Y=0=>Goto 0
A[X]-A[Y]->T
T=0=>Goto 3
X-Y<>Abs T=>Goto 2
Lbl 3
Dsz A[X]
Goto 1
Dsz X
Goto 3
Lbl 4
Next
S

I've added a loop to have an accuracy of 3 significant digits and discovered, that C.Basic also offers a vector or array type.

Here the results for the FX-9860G SD:

- 0.774 FX-9860G SD C.Basic 2.37 / Integer Mode

- 0.406 FX-9860G SD C.Basic 2.37 / Integer Mode / Fast Mode x1.9 (29.5->118 MHz)

- 0.278 FX-9860G SD C.Basic 2.37 / Integer Mode / Fast Mode x2.8 (29.5->118 MHz / -1 wait state)

The fx-9860gii-2 should be a little bit faster.

[Mjim]

(11-23-2019 02:42 PM)Eddie W. Shore Wrote:  I hope to see Python expanded on the fx-CG50. Currently, it's kind of limited.

I downloaded the emulator first to try it out, and I was pretty surprised at all the functions missing from the math library; but I was still impressed that I could run some basic programs that I had made in Python on it.

(11-23-2019 03:14 PM)Dave Britten Wrote:  

(11-23-2019 02:42 PM)Eddie W. Shore Wrote:  I hope to see Python expanded on the fx-CG50. Currently, it's kind of limited.

According to the last post in this thread, Casio is at least planning to add graphics capabilities.

I didn't use Python beyond a basic ability, but being able to graph stuff is something I did use. I guess there isn't much graphing to be done without pylab; fingers crossed more libraries (hopefully full ones) make their way to MicroPython. There aren't any unofficial, but more complete ports of it are there for SH architecture?

On another note, my fx-9750GII (9860GII firmware) is now permanently dead (those benchmarks I posted above are among the last things it ever did). I opened it up to see if I could fix the squeaky navigation button, but the ribbon connecting the button PCB and CPU/Flash/LCD module was pretty fragile and got broken. I spent a day or so fixing it (80pin IDE ribbon cable worked best), but my shaky hands created a couple of lifted tracks, so I needed to reroute a couple of traces.

Somehow it worked after that (so I was able to do the benchmarks), but I wasn't happy with the shocker of a job, so decided to touch up those solder pads, but in the process ended up dropping a big blob of flux across the flash pins, that I didn't pick up until it was too late (First couple of times it powered on, but the keyboard wouldn't work, then it would power on and off immediately, then it wouldn't power on. Finally the last time I saw the screen was when I plugged it into the computer; but even that doesn't happen anymore). I'm not absolutely certain, but I'm pretty sure that it saves to flash memory as soon as the power switches off, and it corrupted the flash memory. The blob was pretty much covering pins 9 to 17 of the spansion chip; and while I'm not very good with electronics, it looks like that was not a great place to short out from the datasheet.

The Calculator to be fair was already broken when I got it many years ago (only $5), but I managed to fix the problems on it after spotting a fracture on the board which had cut some of the tracks on the keyboard PCB. It served me very well with some of my study materials over the years; and I grew to appreciate it how useful a tool it was. For example it made solving stress-strain matrices with 6 unknowns really easy (Just linear elastic behaviour ie Hooke's Law is as far as I got with that topic). Also learned recently about the great "Sequence" and "nSolve" functions, both of which are super useful (nSolve unlike solve will return up to 10 values over a range if there are multiple solutions). Shame to see it go, as I was rather fond of it. RIP

[Hlib]

Thanks to xerxes for this final result. With array type fx-9860gii-2 appears bit faster, in C.Basic it gives the same time regardless of whether USB is connected or not:
- 0.673_s / INT% mode (32 bits) / C.Basic 2.37
- 1.034_s / DBL# mode (64 bits) / C.Basic 2.37
I do not use the FTune program for fast mode, since the speed here is proportional to the drain of batteries, and there is no great benefit.
It seems that CASIO ended the era of the classic graphic calculator with the most successful model in this class, returning to it the former advantages of the best calculators of the first half of the 1990s: economy, versatility and speed.
Edit: minor typo

[Mjim]

Hlib, did you happen to record the part number of the flash chip used in your fx-9860GII during the tear down?

One of the things that impressed me about the fx-9750GII is the presence of a very high endurance (1,000,000 cycle, 20 year retention) 4MB, 0.13 micrometer process, flash memory chip; the spansion S29JL032H. I'm interested to know whether they changed the chip for the second generation fx-9860GII (since my fx-9750GII is basically the first generation).

While the newer fx-CG50 has more storage (32MB, 0.065 micrometer process), it looks like it suffers by a factor of 10 in terms of endurance (100,000 cycles endurance):
https://www.hpmuseum.org/forum/thread-75...l#pid97225

I don't know if Casio uses any wear leveling for their OS, but it could be possible the fx-CG50 might be better off on account that more space is reserved for backing up the contents of RAM to flash on power down, or it could be worse off if it simply rewrites the same sector of flash memory.

[Hlib]

(11-24-2019 07:52 PM)Mjim Wrote:  Hlib, did you happen to record the part number of the flash chip used in your fx-9860GII during the tear down?

No, I didn`t write down the flash chip number. Getting to it without damaging the loops is not easy, so I did not disassemble the calculator completely.
Once upon a time I researched this issue in connection with other devices from CASIO. They are very serious about the issue of data saving. In particular, cooperating with the company SunLight, which dealt with this problem, CASIO introduced advanced developments in the AFX-2.0 and PV-250/460/660 back in the late 90s. In AFX-2.0/2.0+, for example, data of type List for some reason at saving were duplicated also in hidden flash-RAM area. All manipulations with them affected reading/writing from flash, which greatly slowed down the speed of the calculator in programs, but it had 146KB of RAM available to the user. And this is much more cycles than when you turn off and turn on modern calculators with flash-RAM. However, these worked for me for more than 15 years and remained serviceable. Now these technologies have become more reliable and cheaper. There is no cause for concern, but sometimes they deceive us. My hp-39gii could not withstand a few thousand cycles during a year. It often lost all the data from the RAM, then stopped saving them at all when turned off, although it had a flash chip with a capacity of several tens of megabytes. Very strange.

[Mjim]

(11-24-2019 10:55 PM)Hlib Wrote:  No, I didn`t write down the flash chip number. Getting to it without damaging the loops is not easy, so I did not disassemble the calculator completely.
Once upon a time I researched this issue in connection with other devices from CASIO. They are very serious about the issue of data saving. In particular, cooperating with the company SunLight, which dealt with this problem, CASIO introduced advanced developments in the AFX-2.0 and PV-250/460/660 back in the late 90s. In AFX-2.0/2.0+, for example, data of type List for some reason at saving were duplicated also in hidden flash-RAM area. All manipulations with them affected reading/writing from flash, which greatly slowed down the speed of the calculator in programs, but it had 146KB of RAM available to the user. And this is much more cycles than when you turn off and turn on modern calculators with flash-RAM. However, these worked for me for more than 15 years and remained serviceable. Now these technologies have become more reliable and cheaper. There is no cause for concern, but sometimes they deceive us. My hp-39gii could not withstand a few thousand cycles during a year. It often lost all the data from the RAM, then stopped saving them at all when turned off, although it had a flash chip with a capacity of several tens of megabytes. Very strange.

I didn't realize that the flash chip was hidden on the fx-9860GII. On the fx-9750GII it is easily visible just from opening the case. As someone that has already broken the connector loop between the motherboard and keyboard, I can fully understand not wanting to risk that!

I managed to find a version 2 of the fx-9750GII which uses a different flash chip here:
https://tiplanet.org/forum/gallery/image...ge_id=8422 and I think this may be the datasheet for the flash chip (It seems to be 100,000 cycles as well): http://static6.arrow.com/aropdfconversio...es-70g.pdf

Fascinating stuff about Casio and SunLight partnering up to deal with data storage. Would love to hear more, but I'll see if I can't exercise my Google skills to look into this so I don't take more of your time. Appreciate the extra info, thanks!

[Mjim]

I managed to pick up a fairly good condition second-hand fx-9750GII SH4 model (didn't realize it would be an SH4 version). The fx-CG50 is still on it's way...but I'm a little more excited about that now as I had no idea that the screen was much bigger (just thought they were all the same size, even the fx-9860G2 is noticeably bigger).

First impressions:
Much better condition than my now dead SH3 one. The old display also had some stress marks on it (slightly darker spots); but I must say that I did prefer the lighter background on the SH3 version; it still has great contrast, but the other display was a little more reflective so would probably be a tiny bit better under low light (can't test it now since it is deceased).

I had a look inside and it is also using a different flash chip: MX29LV320EBTI-70G. This is quoted as having a 100,000 rewrite cycle lifespan, with 20 year data retention. This is still hugely more reliable than the multi-layer flash seen in high capacity computer drives, though not as fantastic as the old SH3 version of the fx-9750GII I had. My guess is that bigger flash chips are more reliable (I think the SH3 one was 0.13 micron), but you get more chips on a smaller process, so it probably makes sense to abandon an older process for a new one so that you could sell more chips using the same amount of silicon.

SH3 fx-9750G2 PCBS:
Keyboard: GY362-E4W
Motherboard: GY362-1

SH4 fx-9750G2 PCBS:
Keyboard: GY362-E4W
Motherboard: GY801-1 (some of the text is written over, so this may not be correct).

I'll do some benchmarks using xerxes code (Divided by 10 for a per loop count):

- 0.857 C.Basic 2.38 / Integer Mode (Nrm mode in Ftune3, 29.49MHz - Defaults)
- 1.290 C.Basic 2.38 / DBL Mode (Nrm mode in Ftune3, 29.49MHz - Defaults)

- 0.757 C.Basic 2.38 / Integer Mode (F3 mode in Ftune3, 29.49MHz - SH3 timings)
- 1.129 C.Basic 2.38 / DBL Mode (F3 mode in Ftune3, 29.49MHz - SH3 timings)

- 0.219 C.Basic 2.38 / Integer Mode (F4 mode in Ftune3, 117.96MHz)
- 0.329 C.Basic 2.38 / DBL Mode (F4 mode in Ftune3, 117.96MHz)

- 0.152 C.Basic 2.38 / Integer Mode (F5 mode in Ftune3, 235.93MHz)
- 0.245 C.Basic 2.38 / DBL Mode (F5 mode in Ftune3, 235.93MHz)

That first benchmark is fairly interesting, since Hlib did quite a bit better there (0.673s & 1.034s respectively). I was under the impression that the fx-9860G2-2 and fx-9750G2-2 were very similar hardware-wise, but maybe this isn't the case. Were any timings or the code changed to get that sort of result?

EDIT:
Ftune2 gives better results on the highest setting:
- 0.122 C.Basic 2.38 / Integer Mode (F5 mode in Ftune2, 235.93MHz)
- 0.188 C.Basic 2.38 / DBL Mode (F5 mode in Ftune2, 235.93MHz)

[Hlib]

Hi, Mjim! Thanks for these informative tests. You asked:

Quote:Were any timings or the code changed to get that sort of result?

No, I didn`t change anything in the last code from xerxes. I do not understand it myself (0.673 s/1.034 s), because in the genuine benchmark 9750gii-2 is faster than 9860gii-2 (45s vs 58.7s) Maybe it`s all about different OS versions (mine has ver.2.09.0201 and shows 54.9s in that benchmark).These discrepancies in the results are trifles.

[xerxes]

I've checked all the results of the SH-3/4 CASIOs and I think the result of 45.0 seconds for the FX-9750GII-2 was measured with
connected USB without reporting this. I don't have a FX-9750GII-2 to confirm, but the difference to the FX-9860GII-2 is too high.

Thanks to Mjim for the new results. I also don't understand why C.Basic is clearly faster at default speed settings on the FX-9860GII-2.
Possibly there are differences in the default wait state settings, but I assume these are the same on the FX-9860GII-2 and the FX-9750GII-2.

[Mjim]

Speaking of the built in Basic, I get some interesting results. As pointed out USB does definitely make a difference. OS is 02.05.0201 (It is modified with the SH4 9860G2 firmware).

Using the stock NQUEEN benchmark program:
'Nrm' / Not Overclocked (Screen captured, so actual):



Built in Basic:
52 seconds (somewhere between the quoted 45 & 58.7s)
38 seconds / USB connected

C.Basic (USB has no effect overclocked or stock, so I'll just compare DBL# & INT%:
1.60 seconds / DBL Mode
0.97 seconds / INT Mode

'F5' / Fully Overclocked (Screen captured, so actual):



Built in Basic:
10 seconds
5 seconds / USB connected

C.Basic::
0.23 seconds / DBL Mode
0.13 seconds / INT Mode

Having the USB connected makes a huge difference for the built in Basic app, at least with this OS version.

[xerxes]

It's really strange to see, that C.Basic seems a bit too slow on your device, while the stock Basic results are slightly too fast at
default speed but not at full speed. I'm not sure how to handle this regarding the list. I'll try to make some further tests
to understand the reason. Thanks for yor effort.

[Mjim]

ftune3 uses slower BFC clock (59MHz instead of 118MHz in ftune2) on the highest 'F5' setting. I'm actually a bit lost about what the differences are between ftune2 & ftune3 (apart from different default timings at maximum) as both are supposed to be for the SH4A fx-9860g2. Even after doing a full reset and removing all of the add-in apps (including ftune), it still seems to take 52 seconds.

In any case I discovered ftune2 isn't stable on my calculator with the default F5 settings. I'm hoping the cause was due to increasing temperatures (Southern Hemisphere), as I had a lot of stability problems with reboots clearing the contents of the RAM. The fact it was perfectly fine after posting my results and then a couple of days later having lots of issues was alarming (especially in context with what I have heard about some earlier Prizm CG-10 models).

After switching to ftune3 the stability returned but I would still get these occasional pauses when registering input commands, but no crashing even with rather intense benchmarks (for example in C.Basic I use the sequence function with a formula to build a table of 15,000 values to fill the 250k of RAM, which seemed to trigger a crash on ftune2).

I have changed the PFC bus speed back to it's default of 14.75MHz as it doesn't seem to make too much of a difference in results, and from Ptune's included text document seems to have an effect on the flash memory (I have no idea whether it is directly controlling the flash speed). The flash memory chip datasheet seems to list 60ns access times which corresponds to about 17MHz, so I'm keeping it at 14.75MHz to see if those occasional pauses/stutters go away.

EDIT: It's Flash chip is 70ns (14.3MHz), not 60ns. My older SH3 fx-9750G2 spansion flash chip was 60ns access surprisingly despite being on an older process node (0.13um), also faster to program from the specs(11us/word vs 3us/word). Standby current is significantly better in the old chip as well..(0.2uA vs 5uA). I'm going to miss that old reliable SH3 fx-9750G2.

[Mjim]

I received the Casio fx-CG50 yesterday and was very happy to learn that the display is transflective!:



Taken under direct sunlight (back light at it's dimmest setting after 30 second timeout), but angled as such so that you can see the shadowing of the LCD on the reflective part of the display.

So the display is easy to read under direct sunlight (well to be fair the surface of the screen could do with anti-reflective coatings). The reflective layer isn't quite good enough to function under fairly normal indoor light levels, so you do need the back light then, but it's nice to know you aren't limited to the back light for all lighting conditions.

[Steve Simpkin]

(12-06-2019 12:33 AM)Mjim Wrote:  I received the Casio fx-CG50 yesterday and was very happy to learn that the display is transflective!:
...

Very cool. I never used mine outside so I didn't notice this.

If you haven't already done so, check out KhiCAS. It is a port of Bernard Parisse'S Giac/Xcas computer algebra system (CAS) for the Casio CG50 or Graph90+e (as mentioned by Hlib above). It provides algebra, calculus, solvers, linear algebra, graphs, ... commands for the CG50.
https://www.cemetech.net/forum/viewtopic...88&start=0

[Mjim]

(12-06-2019 04:49 AM)Steve Simpkin Wrote:  Very cool. I never used mine outside so I didn't notice this.

If you haven't already done so, check out KhiCAS. It is a port of Bernard Parisse'S Giac/Xcas computer algebra system (CAS) for the Casio CG50 or Graph90+e (as mentioned by Hlib above). It provides algebra, calculus, solvers, linear algebra, graphs, ... commands for the CG50.
https://www.cemetech.net/forum/viewtopic...88&start=0

That was actually one of the biggest selling points for me

I'm pretty abysmal at using it though. I'm going through Calculus 2 (self-study), so I've been relying on Microsoft Mathematics for checking some of my integral/differential calculus answers, but it can't really cope with Calculus 2 integrals, so I found XCAS (which I'm also hopeless at using), which led me to discover KhiCAS.

I think as well some benchmarks should be added for the fx-CG50. Once again the default NQUEEN test (not the optimized one):

fx-CG50 default clock (Ptune3 "NORMAL"), v03.30.0202



Built in Basic:
27 Seconds
27 Seconds / USB connected

C.Basic CG v1.39beta:
0.52 seconds / DBL Mode
0.31 seconds / INT Mode

Probably relatively good news for Prizm CG10/20 owners is that the slower memory timings on the fx-CG50 means the clock rate being doubled doesn't translate into double the speed. In fact with some memory tweaks you can get the same performance at half the clock rate (Ptune2 memory wait tuning).

Also decided to do some power current draw tests:

Casio fx-CG50 Backlight current draw (Mode 1, idle), average value is after a minute approximately:

Backlight 0/5 (screen time-out brightness):
min: 2.129 mA
max: 7.037 mA
avg: 2.62 mA

Backlight 1/5:
min: 3.016 mA
max: 7.932 mA
avg: 3.50 mA

Backlight 2/5:
min: 4.012 mA
max: 8.942 mA
avg: 4.50 mA

Backlight 3/5:
min: 5.435 mA
max: 10.386 mA
avg: 5.92 mA

Backlight 4/5:
min: 7.275 mA
max: 12.225 mA
avg: 7.76 mA

Backlight 5/5:
min: 9.552 mA
max: 14.565 mA
avg: 10.07 mA

Casio fx-CG50 Backlight current draw (Mode 1, scrolling up and down through history):

Backlight 1/5:
~34mA

Backlight 5/5:
~41mA

Casio fx-CG50 Backlight current draw (C.Casio Basic summation), average is after a minute.

Backlight 1/5:
min: 38.449 mA
max: 38.781 mA
avg: 38.67 mA

Backlight 5/5:
min: 45.735 mA
max: 46.099 mA
avg: 45.98 mA

The backlight power consumption seems about the same as the fx-CG10/20/9860G2 which is around 7 mA. The power consumption overall is slightly higher than the fx-CG10/20 at stock speeds (~39mA vs ~34mA on ftune's website), and much hungrier than the fx-9860G2 (22mA). To be fair though it is faster at it's stock speeds, so less time processing can translate to an overall decrease in power consumption (more time in idle).

Sleep mode current draw:
After 30 minutes:
min: 0.682 mA
max: 2.764 mA
avg: 0.959 mA

I'm betting that this is because the SDRAM is still being refreshed at this point.

Sure enough, after 1 hour it goes in to low current standby:

After 1 hour:
min: 35.11 uA
max: 35.81 uA
avg: 35.5 uA

I did the voltages last, but I'm not as thorough here:

Casio fx-CG50 Backlight voltage (Mode 1, idle), average value is after a minute approximately:

Backlight 1/5:
min: 5.2952 V
max: 5.3047 V
avg: 5.3037 V

Backlight 5/5:
min: 5.2844 V
max: 5.2947 V
avg: 5.2931 V

Casio fx-CG50 Backlight voltage (C.Casio Basic summation), average is after a minute.

Backlight 5/5:
min: 5.2202 V
max: 5.2296 V
avg: 5.2231 V
*Note, you can see the voltage dropping through the discharge of the batteries with this test, so the results were decreasing over time.


Sleep mode voltage:
min: 5.2907 V
max: 5.2953 V
avg: 5.2946 V

This probably wasn't all that great a measurement since I did it straight after the high current draw test. After 7 or so minutes:
min: 5.2956 V
max: 5.2998 V
avg: 5.2992 V

So maximum measured power consumption (C.Basic summation test, maximum brightness) is:
5.2296V * 46.099mA = 0.24W

Still a lot better than the 0.6W quoted on the back; definitely more than the fx-9860G2 though which states 0.7W on the back.

EDIT:
C.Basic seems to have 1.7MB of additional RAM for use on the fx-CG50, so I was able to build a table with nearly 100,000 values.

[xerxes]

(12-08-2019 03:48 AM)Mjim Wrote:  Also decided to do some power current draw tests:

Interesting results. I'm using Eneloops in my FX-9860G SD without any complications even at 118 MHz.

(12-08-2019 03:48 AM)Mjim Wrote:  I think as well some benchmarks should be added for the fx-CG50. Once again the default NQUEEN test (not the optimized one):

Apropos optimized: Trying to find the optimual solution for each language, I've noticed that the 8-bit CASIOs are faster with
unstructured code using a list or an array, but the SH-3/4 models are faster with structured code using a matrix. C.Basic however
is faster with unstructured code using an array. So it can be said, that all versions are optimized.

Could you please test the C.Basic code from post #25 on the CG50 at normal and maximum speed? Thank you.
Which OS version is installed on your CG50?