### Author Topic: WikiTI  (Read 49364 times)

0 Members and 1 Guest are viewing this topic.

#### Munchor

• LV13 Extreme Addict (Next: 9001)
• Posts: 6199
• Rating: +295/-121
• Code Recycler
##### Re: WikiTI
« Reply #75 on: November 30, 2010, 03:57:54 pm »
Returning to WikiTI:

This topic is inside the Assembly Programming Forum... WikiTI is for Assembly only?

I'm quite confused now, since I made Axe Parser's page :S

WikiTI is for whatever we make it.   It is mostly focused on assembly programming because that's where third-party documentation is most needed - TI's documentation barely scratches the surface of what assembly language can do.  But there's no reason to exclude other languages.  I don't think there's a need to document the Axe language itself - that's what the official documentation is for - but programming tips, example code, and tutorials would be very much welcome.

Thanks for the explanation, BUT this is the Assembly category, what, why?

#### Deep Toaster

• So much to do, so much time, so little motivation
• LV13 Extreme Addict (Next: 9001)
• Posts: 8217
• Rating: +758/-15
##### Re: WikiTI
« Reply #76 on: November 30, 2010, 04:00:39 pm »
As we said, WikiTI is almost completely ASM info now. And Sir made this topic about the USB documentation that he found on WikiTI. Guess it could go in Other calc disc., but not really needed right now...
« Last Edit: November 30, 2010, 04:00:53 pm by Deep Thought »

#### DJ Omnimaga

• Former TI programmer
• CoT Emeritus
• LV15 Omnimagician (Next: --)
• Posts: 55865
• Rating: +3151/-232
• CodeWalrus founder & retired Omnimaga founder
##### Re: WikiTI
« Reply #77 on: December 01, 2010, 03:44:03 am »
Returning to WikiTI:

This topic is inside the Assembly Programming Forum... WikiTI is for Assembly only?

I'm quite confused now, since I made Axe Parser's page :S

WikiTI is for whatever we make it.   It is mostly focused on assembly programming because that's where third-party documentation is most needed - TI's documentation barely scratches the surface of what assembly language can do.  But there's no reason to exclude other languages.  I don't think there's a need to document the Axe language itself - that's what the official documentation is for - but programming tips, example code, and tutorials would be very much welcome.

Thanks for the explanation, BUT this is the Assembly category, what, why?
I see no need to move the topic for now. If WikiTI ever diverges into non-ASM stuff for real, then we can consider moving the topic.

IMHO, though, I think WikiTI should continue focusing on the calcs documentation from the memory to the LCD for now.
In case you are wondering where I went, I left Omni back in 2015 to form CodeWalrus due to various reasons explained back then, but I stopped calc dev in 2016 and am now mostly active on the CW Discord server at https://discord.gg/cuZcfcF

• LV6 Super Member (Next: 500)
• Posts: 336
• Rating: +47/-0
##### Re: WikiTI
« Reply #78 on: May 11, 2014, 04:45:28 pm »
In the example, a "xor" must be used, not an "and".
Also, a little paragraph about delays between writing & reading could be necessary, don't you think ?
For what we had tested, maximum cycles was 6 in cpu speed 0, and 29 in any other (about a dozen models tested).
The cse has longer delays, but we were only able to test one calc.

#### DJ Omnimaga

• Former TI programmer
• CoT Emeritus
• LV15 Omnimagician (Next: --)
• Posts: 55865
• Rating: +3151/-232
• CodeWalrus founder & retired Omnimaga founder
##### Re: WikiTI
« Reply #79 on: May 11, 2014, 04:47:14 pm »
By the way, if you want to help improving the wiki, feel free to sign up an account (I think someone has to approve it). Follow the main page instructions.

However, it seems that WikiTI server is incredibly slow lately. When I edited the Omnimaga and DJ Omnimaga pages yesterday, each page took 1 minute to load.
In case you are wondering where I went, I left Omni back in 2015 to form CodeWalrus due to various reasons explained back then, but I stopped calc dev in 2016 and am now mostly active on the CW Discord server at https://discord.gg/cuZcfcF

#### DrDnar

• LV7 Elite (Next: 700)
• Posts: 546
• Rating: +97/-1
##### Re: WikiTI
« Reply #80 on: May 11, 2014, 06:01:07 pm »
If you request an account, be sure to ping me on IRC, or might not get approved for some time, because I don't check the queue everyday.

In the example, a "xor" must be used, not an "and".
No, the example is correct. Reset for a bit means that the key is held, the following CALL instruction tests for Z, not NZ. If you use XOR, you have to reverse the test.

Also, a little paragraph about delays between writing & reading could be necessary, don't you think ?
For what we had tested, maximum cycles was 6 in cpu speed 0, and 29 in any other (about a dozen models tested).
The cse has longer delays, but we were only able to test one calc.
The TI-84+CSE uses the same ASIC (which handles the keyboard) as older TI-84+/SEs with 128 K RAM, so anything true of the TI-84+CSE ASIC is true of the older TI-84+/SE ASIC. I wouldn't be surprised if, on average, the delays required are lower on the TA2 ASIC, but you should still have some.
"No tools will make a man a skilled workman, or master of defense, nor be of any use to him who has not learned how to handle them, and has never bestowed any attention upon them. . . . Yes, [] the tools which would teach men their own use would be beyond price."—Plato's The Republic, circa 380 BC

• LV6 Super Member (Next: 500)
• Posts: 336
• Rating: +47/-0
##### Re: WikiTI
« Reply #81 on: May 11, 2014, 06:28:04 pm »
Hmm... there's something i don't get, then.
If left is pressed, (1) will return $FD.$FD and $FD =$FD, right ?
So, why checking if if the result is zero before calling ?
Can somebody tell me where i missunderstand it ?

And about the CSE delays, yes, i remember you were surprised when my code returned those results.
Maybe i f***ed up somewhere in it...
« Last Edit: May 11, 2014, 06:49:04 pm by the_mad_joob »

#### DrDnar

• LV7 Elite (Next: 700)
• Posts: 546
• Rating: +97/-1
##### Re: WikiTI
« Reply #82 on: May 11, 2014, 06:52:15 pm »
$FD and$FD = $FD, right ? Ah, you're right. It should say ~0FDh; that is, it should be ANDing with the complement of FD "No tools will make a man a skilled workman, or master of defense, nor be of any use to him who has not learned how to handle them, and has never bestowed any attention upon them. . . . Yes, [] the tools which would teach men their own use would be beyond price."—Plato's The Republic, circa 380 BC #### the_mad_joob • LV6 Super Member (Next: 500) • Posts: 336 • Rating: +47/-0 ##### Re: WikiTI « Reply #83 on: May 11, 2014, 06:57:20 pm » Actually, that should work with xor$FD.
Of course, that is only the case when only LEFT is pressed in that group...

/e : Thx for the editing, but btw, no calculator returned more than 6 cycles in cpu mode 0. All results there : http://www.omnimaga.org/asm-language/8x%28se%29-testers-needed/?PHPSESSID=4g7m837h7uo8jgcgmfpdcn1592
« Last Edit: May 11, 2014, 07:04:53 pm by the_mad_joob »

• LV6 Super Member (Next: 500)
• Posts: 336
• Rating: +47/-0
##### Re: WikiTI
« Reply #84 on: May 12, 2014, 06:53:54 am »
Allright, since i was curious about it, i did some tests, but this time, resetting the port first.
When you do that, i can confirm that no delay is needed bewteen sending the group and reading the key.
However, a delay is now needed between resetting the port and sending the group.

A bit more visual explanation :
LD A,$FF OUT (1),A < resetting the port ... < that is where i mesured how many cycles are needed before writing to the port again (likely to include an instruction to actually load the group to be monitored in A) OUT (1),A < sending the group (no delay needed here) IN (1),A < reading the keys I only tested my 84+se for now, but it is a good reference (had the longest possible delays in my previous tests). That is what i got : cpu speed 0 > 4 cycles needed (maybe less, but that is the minimum cycles you need to load your group in A anyway) cpu speed 1,2,3 > 17 cycles needed That is interesting, cause it could imply that writing to port 1 is faster than reading from it. When i have time, i'll check if the delays are similar when using the C register for input/output... EDIT : When using the C register for input/output (as expected) : cpu speed 0 > 4 cycles cpu speed 1,2,3 > 16 cycles (one less than on the previous test, but that is probably because in/out operations take 1 more cycle) « Last Edit: May 12, 2014, 07:14:15 am by the_mad_joob » #### Runer112 • Moderator • LV11 Super Veteran (Next: 3000) • Posts: 2289 • Rating: +639/-31 ##### Re: WikiTI « Reply #85 on: May 12, 2014, 08:33:01 am » I'm of the opinion that resetting the group port is not necessary. Axe's direct key input routine has never done so, and if it didn't work, I'm sure we'd have heard about it from any one of its hundreds of users by now. (I did actually hear about problems a few times, but simply upping the delay seemed to fix any issues) For reference, the current version of the direct key input routine explicitly waits for a fairly generous 40 cycles, or if you want to count the cycles of delay in the out/in instructions themselves, 51 cycles. « Last Edit: May 12, 2014, 08:36:47 am by Runer112 » #### the_mad_joob • LV6 Super Member (Next: 500) • Posts: 336 • Rating: +47/-0 ##### Re: WikiTI « Reply #86 on: May 12, 2014, 08:53:50 am » 40 is very generous, indeed =] Anyway, there seems to be 2 methods : - no reset : delay required between setting group and reading it - reset : delay required between resetting and setting the group (delays a lot shorter, but you have to spend some cycles to actually do the reset) I'm currently thinking of a safe way to know if the current group has been updated or not. Maybe it's possible by using a trick, involving the blank group$7F...

• LV6 Super Member (Next: 500)
• Posts: 336
• Rating: +47/-0
##### Re: WikiTI
« Reply #87 on: May 12, 2014, 11:17:11 am »

I finally found a little something.
The challenge was to find a way to know if the current group has been updated (similar to reading bit 7 of port $10 for the LCD). It seems impossible, since reading port 1 doesn't actually give any infos about that. But, fortunately, there is a way to know if : the group has been updated AND a key is being pressed on that group. I believe it is compatible with all possible hardware types, for all CPU speeds. There you go : LD A,$FF
OUT (1),A
LD BC,\$??01 < ?? = group to be checked
LOOP
OUT (C),B < using C to make the loop faster
IN A,(1)
INC A
JR Z,LOOP < JP maybe better, not sure...
< group updated & key(s) pressed
DEC A
< A holds the key map for the desired group, safe to check it.

Of course, that is the safe way, not necessarily the fastest.

/e : just corrected it

/e2 : realised that it only allows to test one group at once =/
« Last Edit: May 13, 2014, 12:13:54 am by the_mad_joob »

#### Streetwalrus

• LV12 Extreme Poster (Next: 5000)
• Posts: 3821
• Rating: +80/-8
##### Re: WikiTI
« Reply #88 on: May 12, 2014, 11:38:00 am »
I'm of the opinion that resetting the group port is not necessary. Axe's direct key input routine has never done so, and if it didn't work, I'm sure we'd have heard about it from any one of its hundreds of users by now. (I did actually hear about problems a few times, but simply upping the delay seemed to fix any issues)

For reference, the current version of the direct key input routine explicitly waits for a fairly generous 40 cycles, or if you want to count the cycles of delay in the out/in instructions themselves, 51 cycles.
Wow that's a lot. is it for 15MHz compatibility ?

#### Runer112

• Moderator
• LV11 Super Veteran (Next: 3000)
• Posts: 2289
• Rating: +639/-31
##### Re: WikiTI
« Reply #89 on: May 12, 2014, 12:51:44 pm »
I'm of the opinion that resetting the group port is not necessary. Axe's direct key input routine has never done so, and if it didn't work, I'm sure we'd have heard about it from any one of its hundreds of users by now. (I did actually hear about problems a few times, but simply upping the delay seemed to fix any issues)

For reference, the current version of the direct key input routine explicitly waits for a fairly generous 40 cycles, or if you want to count the cycles of delay in the out/in instructions themselves, 51 cycles.
Wow that's a lot. is it for 15MHz compatibility ?

It is. If you look at the old data the_mad_joob collected, some people's calculators were recorded as needed up to 29 cycles of delay at the high CPU speed. So I overshot that to be safe.