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:
ClrHome
Output(5,8,"PLEASE WAIT...")
startTmr→T
Σ(X,X,1,1000)
If checkTmr(T)<3
Then
1→M
ClrHome
Output(1,1,"YOU SEEM TO BE USING A    NEWER REVISION CALC. DUE  TO A FASTER FLASH NAND,   THIS PROGRAM MAY RUN      FASTER THAN EXPECTED.     CONTINUE ANYWAY?")
Output(8,8,"PRESS ENTER")
Pause
Else
0→M
End
ClrHome
M


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:
3A 05 00 E0    ld   a, (0E00005h)
CD 08 0B 02    call _SetXXOP1
CD 30 0F 02    call _StoAns
C9 -  -  -     ret

It will set Ans to 0 if the calculator uses the new flash and 4 if it uses the old flash.
mr womp womp wrote:
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:
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.
prime17569 wrote:
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 Laughing
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:
setDate(2016,4,9
rand(5^^3
startTmr→A
setDate(2016,1,1
rand(5^^3
startTmr-A
abs(Ans)=Ans

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.
mr womp womp wrote:
Due to a newly discovered timer bug in rev M+, there is now a way to detect it.
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:

:getDate->L1
:setDate(2016,4,9
:rand(5^3
:startTmr→A
:setDate(2016,1,1
:rand(5^3
:startTmr-A
:Disp abs(Ans)=Ans
:L1:setDate(Ans(1),Ans(2),Ans(3
:"
mr womp womp wrote:
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:
setDate(2016,4,9
rand(5^^3
startTmr→A
setDate(2016,1,1
rand(5^^3
startTmr-A
abs(Ans)=Ans

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.
I just ran this on my 82AEP OS 5.6.3 and it returns zero like on my pre-M CE.
Just do this: Wink

Code:

ClrHome
Disp "Are you using a Revision M","Calculator?","1:Yes","2:No
Repeat (K=92)+(K=93
getKey→K
End
If K=92
Then
ClrHome
Disp "This program may run","faster than normal.
End
...
DJ Omnimaga wrote:
I just ran this on my 82AEP OS 5.6.3 and it returns zero like on my pre-M CE.

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... Rolling Eyes
I'm not equipped to test this out for myself but I'll take your word for it.
  
Register to Join the Conversation
Have your own thoughts to add to this or any other topic? Want to ask a question, offer a suggestion, share your own programs and projects, upload a file to the file archives, get help with calculator and computer programming, or simply chat with like-minded coders and tech and calculator enthusiasts via the site-wide AJAX SAX widget? Registration for a free Cemetech account only takes a minute.

» Go to Registration page
Page 1 of 1
» All times are UTC - 5 Hours
 
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum

 

Advertisement