Omnimaga
Calculator Community => TI Calculators => ASM => Topic started by: the_mad_joob on April 11, 2013, 11:50:32 am
-
Hey there =]
If you don't already know, a delay is needed between writing and reading to the keyboard (using port 1).
The problem is, that the needed time is not accurately known.
Since there seems to be many different opinions about the subject, i decided to code a program to test that up.
The main purpose is to be able to have a better knowledge of the hardware, allowing more optimised low level operations.
Also, maybe we'll have some surprises (ti likes to change hardware pieces).
COMPATIBILITY
TI-83 Plus
TI-83 Plus.fr
TI-83 Plus Silver Edition
TI-84 Plus
TI-84 Pocket.fr
TI-84 Plus Silver Edition
TI-84 Plus Pocket Silver Edition
TI-84 Plus C Silver Edition
All official OS are compatible, as long as you TURN OFF MATHPRINT.
INSTRUCTIONS
Simply execute from the homescreen and follow instructions.
Important : When pressing the 0 key, you must HOLD it until the end of the test.
DOWNLOAD
black & white models : http://www.omnimaga.org/index.php?action=dlattach;topic=16102.0;attach=15043
TI-84 Plus C Silver Edition : http://www.omnimaga.org/index.php?action=dlattach;topic=16102.0;attach=15044
RESULTS
The displayed value(s) are the needed delays (in cycles) for each CPU speed mode (order : 0,1,2,3).
A question mark specifies an unknown delay.
Please don't forget to specify the model and serial number end (at the back of your calc, in the form X-XXXXX).
OWNER MODEL SERIAL DELAY-0 DELAY-1 DELAY-2 DELAY-3
the_mad_joob 83+ I-0299A 6
bhtooefr 83+ S-0504E 0
chickendude 83+ N-0305H 5
fortytwo 83+SE I-0501 4 23 30 37 overclocked
Darl181 84+ S-0305B 6 29 29 29
Streetwalker 84+ S-0107G 4 21 21 21
the_mad_joob 84+SE S-0404 6 29 29 29
DrDnar 84+SE S-0605D 4 19 19 19
fortytwo 84+SE P-0410O 4 17 17 17
willwac 84+SE P-0410O 4 20 20 20
chickendude 84+SE ? 4 18 18 18
DrDnar 84+CSE ? 22 72 72 72
THANKS IN ADVANCE FOR YOUR PARTICIPATION =]
-
84+ S-0107G (TA3 chip) :
4
21
21
21
-
Reading such results reminds me how slow is my 84+se XD
Thx a lot Streetwalker !
-
You welcome. I like to help people especially when it's that simple. ;)
-
You should ask KermM to run that on his 22 MHz TI-83+SE. (Its ASIC is a beta version of the TI-84+/C/SE ASIC.)
-
Results would be interesting, indeed.
Anyway, i'll probably post a duplicate topic on cemetech.
-
84PBE, S-0305B
6, 29, 29, 29.
-
Another slow one XD
Thx Darl181 =]
-
Iirc the older calcs are slightly slower hardware-wise. There used to be a topic, but I can't seem to find it anymore..
They make up for it in ram pages and other fun tho :P
-
How on earth does someone "time" a processor with only the processor to do so?
And the same goes for keypresses! Wahh lol
Should I test different OS versions?
-
How on earth does someone "time" a processor with only the processor to do so?
And the same goes for keypresses! Wahh lol
It's not really timing the processor with the processor. It's more like timing the keyboard delay with the processor clock.
-
How on earth does someone "time" a processor with only the processor to do so?
And the same goes for keypresses! Wahh lol
Hmm... timing the processor is definitely not the aim here.
The idea is to know how many cycles are needed between writing & reading to port 1.
Knowing that delay allows you to make sure low level interactions with the keyboard are compatible with all hardware types.
Should I test different OS versions?
That shouldn't matter, since i don't use any OS code in the delay calculation.
Just be sure to turn that mathprint shit off if using 2.53 or 2.55.
-
You can time the processor easily enough using only the processor:
Simply start a loop with a known number of cycles. Have it run long enough to get a decent length of time. (Say, 100 million cycles)
Simple math based on the time can tell you the processor's speed in Hz.
-
So, for now, the known maximum delays are :
83+ : 6
other models - mode 0 : 6
other models - mode 1+ : 29
More tests are needed...
-
Yes, there is a problem with your source code. You forgot to disable interrupts, which could cause false values to be reported.
I get {4, 19, 19, 19}. My calculator is a TA3-type unit S-0605D.
The needed wait time appears to be 1 or 2 microseconds. The keyboard circuits may involve an analog component, so external (or internal) forces could affected the needed wait time. The keyboard outputs are open-drain type, and the inputs have internal pull-up resistors. TI probably chose resistances that reduce power usage, which has the side effect of requiring longer wait times before keyboard matrix output transistors settle.
How on earth does someone "time" a processor with only the processor to do so?
And the same goes for keypresses! Wahh lol
Should I test different OS versions?
We're measuring time from the point of view of the processor itself, so we don't need an external reference. We also have more than only the processor: the so-called crystal timer circuits can not only measure time in terms of the 32768 quartz crystal (which I use in my CPU clock frequency tester), but the circuits can also measure time in terms of the CPU clock divided by any of 8 different constants.
-
Yes, there is a problem with your source code. You forgot to disable interrupts, which could cause false values to be reported.
I already tried the same code with interrupts disabled and the same values seemed to be returned.
I checked again, and the response is then a bit slower with my old 83+.
Anyway, since you're the kind of person i would definitely trust, i updated the prog & source.
Thx a lot DrDnar =]
-
The OS interrupt handler periodically scans the keyboard matrix. If an interrupt fires in the middle of testing the delay, the interrupt processing delay will definitely throw the test off, giving a lower-than-normal value. If the interrupt handler decides it's time to scan the keyboard matrix, it will leave the key group mask set to FF, which will cause the test to never read a key press. You could try to verify this by forcing an interrupt to occur in the middle of the test sequence using a crystal timer with its delay set to a specific number of clock cycles; see WikiTI for details. If you're feeling particularly ingenious, try disassembling the OS interrupt handler and determining what causes the OS to rescan the keyboard. Then, set up the test to force those conditions to occur.
Your results may be consistent across multiple runs because the interrupt timings are fairly predictable. Specifically, the OS won't start to execute the program until after the interrupt handler sees the ENTER key and stores the keycode into RAM, and then GetKey sees the keycode and returns to the home screen app, which closes the edit buffer and starts parsing it, and then the parser loads and executes the RAM program. So, this sequence can take a fairly predictable amount of time from when you hit ENTER.
-
I'm starting to understand how it works now...
Thx for the sharing =]
-
So, for now, the known maximum delays are :
83+ : 6
other models - mode 0 : 6
other models - mode 1+ : 29
More tests are needed...
What about TI-84 Plus C Silver Edition color screen models?
-
Good question.
Not even sure if the program works on those...
-
It would obviously need some modifications (as does porting a TI-82 Stats/83 program over the 83 Plus series), but I heard that most modifications are changing RAM addresses (for example cmdShadow is now at 9BAA instead of 966E) and LCD stuff. The calculator ASIC is pretty much based on the 84+SE from 2004 (the ones that had 128 KB of RAM instead of 48).
-
I'm not sure why, but screwing with curRow and curCol the way you do makes it overwrite previous text. So I switched it to using the wonderful _NewLine. Anyway, this gives 22 ? ? ? on my TI-84+CSE. This seems highly unlikely to me, but I don't see anything obviously wrong. I'll have to do some more work later.
-
I'm not sure why, but screwing with curRow and curCol the way you do makes it overwrite previous text.
Maybe those text display routines have been modified on the 84+CSE (Who knows...).
I'm specially thinking of the automatic newline performed by _puts (and putc i think) once a char has been displayed at col 15.
So I switched it to using the wonderful _NewLine. Anyway, this gives 22 ? ? ? on my TI-84+CSE. This seems highly unlikely to me, but I don't see anything obviously wrong. I'll have to do some more work later.
I just hope ti did not change the keyboard for some slow crap.
More likely, there is one or more piece(s) of hardware that is significantly faster (and that is involved in the test ofc).
EDIT :
I took some little time to modify the kbdelay.asm you provided.
It now goes up to 128.
Feel free to try it out =]
-
Some more testers around ?
@DrDnar :
So, did you try the new version ?
To tell the truth, i'm kinda curious to see the results.
-
I can get you another 83+ and 84+SE tomorrow :)
-
Yay !
-
@DrDnar :
So, did you try the new version ?
To tell the truth, i'm kinda curious to see the results.
22 72 72 72
I find it rather strange, since so far the MicrOS keyboard routines I've written appear to work fine at 32 cycles delay. I promise you the ASIC is identical to the one in my TI-84+SE. If the keyboard is slower, it would be due to hysteresis in the keyboard matrix, not the ASIC.
-
83+: 5 (N-0305H)
84+SE: 4 18 18 18 (no serial number listed, it's actually an 84+SE in an 84+ case)
-
I added a download link for 84+CSE users.
22 72 72 72
I find it rather strange, since so far the MicrOS keyboard routines I've written appear to work fine at 32 cycles delay. I promise you the ASIC is identical to the one in my TI-84+SE. If the keyboard is slower, it would be due to hysteresis in the keyboard matrix, not the ASIC.
Thx for the results dude.
They are indeed kinda paranormal XD.
83+: 5 (N-0305H)
84+SE: 4 18 18 18 (no serial number listed, it's actually an 84+SE in an 84+ case)
These are short delays !
Too bad you don't have the serial but i assume it's one of the later models.
Thx for time.
-
Yeah, it's a later model. Or at least, it doesn't have the 128kb RAM.