Yeah, especially given all the years TI had after Casio Prizm's release since 2011.
If Casio were to slim down its prizm by replacing 4 aaa batteries with a rechargeable one like on TI CE, Prizm would become the best choice for school in my opinion...
However i'm more and more convinced that there is a big regional differences in market shares of TI and Casio probably due to what schools are used to or prefer and recommend to their students.
I'm under impression Staples in North America stock TIs mostly, and Europe Casios, same thing with other stores
Caleb_J wrote:
I've always wondered... why does TI have so many waitstates on its calculators? Does it deliberately want to slow the calc down?
I believe I read something in the post Kerm had made when he came back from t^3 about teachers wanting the calculators to remain slow (but not CSE slow) so that students can take the time to see the graph being drawn, so I think ti kind of made a compromise between speed and justifying the cost on the CE, maybe trying to get it's speed to feel like a ti-84 plus which is pretty much the model preferred by students and teachers.
No, the CE has so many wait states because of lazy-a** engineering.
The problem is that the eZ80 CPU core is designed for use with a low-frequency (48 MHz), low-bandwidth, low-latency data bus. However, TI built the TI-84+CE's ASIC/SoC largely out of standard ARM logic blocks, including the internal data bus. Standard ARM data buses are designed for high-frequency, high-bandwidth (> 100 MHz), high-latency operation, and the ARM CPU core compensates for the high-latency (that is, large number of wait states on reads) of the bus using an internal cache. (All modern ARM- and x86/x64-based systems use high-latency RAM, and require caching to compensate; this is why a high-end CPU might, for example, be advertised as having a 16 MB L3 cache.) The eZ80, having been designed for use with low/zero-latency RAM, has no cache to compensate for the performance impact of wait states.
TI chose to interface the eZ80 with the ARM logic blocks in the laziest way possible. As a result, the eZ80 gets none of the benefits of having been designed to run with low/zero-latency RAM, while getting hammered with the full, unmitigated performance impact of a high-latency data bus. A fully zero-wait-state design would improve throughput by nearly an order of magnitude. I should point out, however, that the flash chip can't operate at 48 MHz with zero wait states; however, if TI switched to accessing the flash chip in 16-bit mode and implemented a simple 1-byte cache, they could probably get the amortized access time down to 3 wait states, an improvement by a factor of 3!
To be clear, it isn't necessarily bad to combine the eZ80 with standard ARM logic blocks. But TI should have split the data bus into two segments, a zero-latency eZ80 bus for RAM and flash access, and a high-latency separate bus for all the on-chip peripherals. While it's tempting to ascribe this decision to incompetence, it's more likely just TI wanting to save money by designing as little custom logic as possible. (Although I tend to act like I believe it's sheer incompetence in the hope that some engineer will be insulted enough to defend TI's honor by fixing the problem.)
It's quite a shame, too, because with better CPU performance, the TI-84+CE could probably run Lua code at a speed competitive with TI-BASIC on current models.
EDIT: This is all conjecture. I've no proof showing any of this. But I think it's the best theory that fits the information we have, and certainly has plausibility. I also don't buy the explanation that the TI-84+CE had its performance deliberately curtailed at the behest of teachers. A similar rumor ran around for the TI-83+SE over a decade ago.
See, the discovery of the fact that TI-83+SE and TI-84+/SE get unstable at a little over 20 MHz seems to disprove the rumor that TI nixed a 25 MHz mode on those calculators because teachers asked for it. The real reason was simply that the RC-tank circuit used to regulate CPU speed isn't accurate enough. The tolerance on that circuit is huge, +/- 20 %, so a 20 MHz mode would, on > 30 % of calculators, exceed the ca. 22 MHz limit. (Getting exact numbers using a normal distribution is left as an exercise for the reader.) Also, it'd leave an uncomfortably small safety margin, potentially making the calculators prone to random crashes, or even worse, giving incorrect results with no warning.
So I'm not buying the same rumor a second time. Even if teachers did ask for slower graphing, TI could easily provide it by throwing in an animation option on the Window menu and having it default to some non-zero value; most students would never bother zeroing it.
Sorry to start up this thread again, but I am curious as to why the fx-9750g II is so fast - even compared to similar Casios (or are they not that similar?)?
My Classpad 330 did it in just under 3 seconds, although the cp400 was nearly instantaneous.
I would have thought even the older Classpad would still have been faster than the 9750g II.
I think it is just visual presentation delayed on purpose and as programmernerd said before processors casios have can graph most things nearly instantly
Why would teachers want calculators to graph slow? Also one could just busy loop after each pixel or make the calculator do something useful like anti aliasing (for color calculators) or graph with a high resolution and downsample using averaging as another means of making the lines appear smoother.
Also why does the case size matter for the Prizm. Is it not small enough already?