Here's a neat trick to detect whether a CE calculator has the newer, faster flash chip.

The way it works, in a nutshell, is to check how long it takes to calculate a summation and set a variable based on that.

You can add this to the beginning of your program and modify behavior based on the result. For example, you could adjust Wait statements to be longer if you don't want your program running too fast, or add extra visual effects to take advantage of the extra horsepower.


Code:


Note: I'm using an extremely long Output( instead of multiple Disp statements because it's slightly faster.

This feels like really bad code to me. The timer isn't accurate and I can imagine this not working 100% of the time. This should work:

Code:

It will set Ans to 0 if the calculator uses the new flash and 4 if it uses the old flash.

I understand, but I was trying to find a TI-BASIC only solution now that ASM is disabled and new production runs of calculators will be limited to TI-BASIC (at least without jailbreaking them, which some people may not want to do).

Is there a better way to do this with just TI-BASIC? I would appreciate your input.

Right, nothing comes to mind (besides writing a more optimized version of what you did), which isn't great
Add that to the list of reasons why TI shouldn't have blocked native code lol

As mr womp womp pointed out in chat, various things besides the flash type can affect the speed of TI-BASIC execution (such as the number of variables present in RAM). A simple way to account for this is to look at how much slower the test gets if it accesses 2 variables per iteration vs. 1. We also want something that is essentially unchanged between OS versions—a simple summation indeed seems like a good candidate, since it is hard to see what TI would change about it (without completely changing how the interpreter works).

So maybe compare summing a constant vs. summing a variable other than the summation index? One would need to see how these compare under different conditions, but there should be some linear combination of them that is (nearly) invariant to non-flash-type timing variation.

To synchronize the timer's starting (& thereby avoid worries about when in a second the summation starts), you could wait until the time changes by 2 seconds (not 1 in case it changed between the first clock read & the loop looking for the change). This would introduce an additional dependence on delays caused by things other than the type of flash, but it should not make the difference between the measured loop timings nonlinear. It could also fail if it could get so slow that it is executing less than 2 commands per second, but in that case, whatever else was to be done is probably infeasible.

Of course, if the goal is to ensure a game operates at the correct speed (rather than specifically to determine the flash type), one might as well just increment a variable until the clock changes by a fixed amount (after synchronizing as above) & then use the count to adjust any delay loops in the program.

Due to a newly discovered timer bug in rev M+, there is now a way to detect it.
Here's a little program I put together that makes use of that bug:

Code:

The program returns 0 in Ans if it is a pre-M and 1 if it is M+.
Basically, TI changed the timer code and introduced a really nasty bug that causes startTmr to return the wrong numbers because they screwed up the number of days in the months, so by comparing the timer in April then in January, the two versions return different results.
This relies on rand(5^^3 taking more than one full second to execute to give the timer enough time to update. 5^^3 is pretty borderline-ish (takes just barely more than 1 second), so perhaps increasing it a bit could avoid it potentially not working, but it would be even slower and I haven't experienced it not working.
We could also store the date before running this in order to set it back to whatever it was initially because the date will of course be modified if we don't do that.

We can do:


Code:

I just ran this on my 82AEP OS 5.6.3 and it returns zero like on my pre-M CE.

Just do this:

Code:

Right, obviously this code doesn't actually detect the hardware but rather the OS version, since it relies on a specific parser bug (I think 5.4.0+?). I guess TI must have decided to fix a bug for once...
I'm not equipped to test this out for myself but I'll take your word for it.