I saw in the archives for TI-84+CE assembly there was a program that made it about 30% faster. Is making the calculator faster harmful in any way to it? For example, does it go too fast, or is it just helpful/cool?

I have tested the program numerous times, since I have programmed it to run every time the calculator turns on. It is not harmful to the calculator, and it is extremely helpful/cool.

EDIT: I would like to add that, the day before yesterday, my calculator randomly crashed and reset all RAM (I wasn't using any Apps or Assembly programs--in fact, I wasn't even running a BASIC program), which might be caused by this program.

When is it helpful? Is the graphing that much faster?

No, it doesn't make the calculator too fast, it just fixes a TI's solution to a problem the calculator doesn't have (or at least shouldn't have if the hardware is designed well).

EDIT:That's entirely possible. I'll have to release an update with two programs, FASTER and FASTEST. "If your calculator ever crashes with FASTEST, try FASTER instead."


The TI-84+CE CPU is clocked at 48 MHz, but by default, the calculator only allows the flash chip containing the OS to run at 4.8 MHz (or rather, 4.8 Mbytes/s) by forcing the CPU to wait 10 clock cycles whenever it requests a byte (1 normal read cycle, plus 9 wait cycles). The Faster program decreases that to 7 clock cycles. The worst that could happen is the CPU could get invalid data back and crash. But that doesn't seem likely, because the flash chip should be able to operate at 15 MHz. It's the same family of chips used on the TI-84+CSE, and most calculators can operate fine at 20 MHz if you overclock them. (They normally start to get unstable at 21-22 MHz depending on your hardware.)

We don't know why TI designed the calculator to force such a huge number of wait states between flash reads. In theory, it should only require only 1 to 3, depending on how optimistic you are about flash chip performance (0 wait states is a definite no-go at 48 MHz). We can't set the number of wait flash states to less than 5, and reads fail at 5, so Faster sets 6. There appears to be two different logic blocks in the calculator adding wait states. The one we can control appears to actually interface with the flash chip, and we would expect it to require 1-3 wait states; the 4 TI defaults to is over-conservative (though understandable, I guess, as it would eliminate otherwise mysterious read failures). But where the other 5 wait states come from is a complete mystery, just like why it adds five wait states that appear entirely unnecessary.

EDIT: So, I looked at the Z80 datasheet. The Z80 gives external chips 1 (opcode fetch) to 1.5 (non-opcode read) clock cycles between when it asserts chip-enable and when it samples the data bus, plus it puts the address on the bus 0.5 cc before asserting CE. The datasheet specifies 70 ns (gives ~14.2 MHz, but recall that the Z80 gives 1.5 cc minimum for reads) minimum read cycle time. So the flash chip is definitely not safe to operate with less than 2 cc time per read, and 3 is pushing it. 4 is safe. If I'm right about the programmed 4 cycles only going to the external bus and the 5 fixed cycles being internal, then my Faster program is running the flash chip over its specified performance limit. If, on the hand, one or more of the 5 extra wait states are also being applied to the flash chip, then Faster is probably safe to some degree, and it also means that there's no reason for TI to program 4 cycles. I wouldn't rule out the possibility that two different people were involved. One person designed 5 wait states into the hardware, and somebody else programmed 4 into the boot code, not realizing that a hardware guy already took care of that.

Additionally, reading instructions/data from RAM also incurs a 3-wait state penalty, while writes incur 1. This is also strange, because the RAM should be SRAM, which can generally operate at very high speeds (CPU registers are made from SRAM); cheaper DRAM would kill battery life due to far higher power consumption. We haven't found any way to control those wait states, but we have found that the LCD's palette RAM and cursor RAM is executable. That 1.5 K of RAM only incurs 2 wait states (the VRAM performs just like regular RAM), so anybody writing high-performance code should put their most CPU-demanding code there.

The eZ80's performance is limited by its 8-bit data bus and lack of a cache, so performance is heavily affected by bus latency; unless you use MLT a lot, there's no reason to clock the CPU any faster than the data bus. From a performance standpoint, it would make more sense to add a 3x clock divider (maximum of 16 MIPS if using all 1-byte instructions) and eliminate all wait states, rather than their current hardware adding 9 wait states (maximum of 4.8 MIPS if using 1-byte instructions with 10 clock cycles per fetch). (Also, that assumes the eZ80's opcode fetch and memory read timings are similar to the Z80's; a 4x divider may be needed instead.) The old Z80-based calculators used no wait states between the CPU and flash chip (except later production runs use 1 wait state on flash opcode fetches; zStart can turn that off for you), probably sharing the same bus, and ran fine at 14-17 MHz depending on the particular unit (for reference, due to a lack of pipelining, the Z80 can do 1-4 (avg. ca. 3) MIPS at 16 MHz depending on the instructions used).

Oh, and for the record, I don't actually care enough to run Faster every time I turn my calculator on. I just thought it was neat to see some operations run a little faster, and nobody else had published an assembly program yet, so I put it out there.

I strongly suspect that the problem is with flash part tolerances. I'd expect some kind of normal distribution, so the bell curve of unit failures would rise as the number of wait states is reduced. Presumably the value they set at system initialization effectively eliminates returns directly related to end-of-the-curve Flash chips.

On the other hand, it seems that there's a sum of 5 + 4 wait states coming from somewhere, so it's not entirely clear why also impose this many wait states on the RAM to me.

Well, yes, they use 4, not 3, external wait states because using 3 places the chip close to its specified performance limit, and they want to be able to reliably use slightly under-performing chips---after all, high performance really isn't a major requirement. RAM uses 3 wait states on reads, so perhaps the internal bus adds 3 wait states on both flash and RAM reads for some lame reason (bus size?). And then 2 more are added to the external bus by hardware, possibly as a consideration for boot-up. 2 is plenty good enough when the CPU clock divider is set to 4x (and still necessary when it's set to 1x), but when you switch to 1x, they wanted to set 4 total states, and programmed that into the external bus controller. That would explain Faster working fine when it sets 1 wait state but not if you set 0: they programed 4 additional states when they meant to program 4 total states. Or maybe not; the CPU might be able to have a different clock divider than the other on-chip peripherals.

But really I'm just making up BS at this point.

Clearly it's time to break out the fuming nitric acid and microscope.

Well, I do have friends in the chemistry department. Donate a calc, and I can do a die extraction.