Author Topic: WikiTI (Read 83884 times)

Munchor · « **Reply #75 on:** November 30, 2010, 03:57:54 pm »

Quote from: FloppusMaximus on November 29, 2010, 11:26:16 pm

Quote from: ScoutDavid on November 27, 2010, 09:31:32 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?

Deep Toaster · « **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...

DJ Omnimaga · « **Reply #77 on:** December 01, 2010, 03:44:03 am »

Quote from: ScoutDavid on November 30, 2010, 03:57:54 pm

Quote from: FloppusMaximus on November 29, 2010, 11:26:16 pm
Quote from: ScoutDavid on November 27, 2010, 09:31:32 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.

the_mad_joob · « **Reply #78 on:** May 11, 2014, 04:45:28 pm »

About that : http://wikiti.brandonw.net/index.php?title=83Plus:Ports:01
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 · « **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.

DrDnar · « **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.

Quote from: the_mad_joob on May 11, 2014, 04:45:28 pm

About that : http://wikiti.brandonw.net/index.php?title=83Plus:Ports:01
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.

Quote from: the_mad_joob on May 11, 2014, 04:45:28 pm

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.

the_mad_joob · « **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...

DrDnar · « **Reply #82 on:** May 11, 2014, 06:52:15 pm »

Quote from: the_mad_joob on May 11, 2014, 06:28:04 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

the_mad_joob · « **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

the_mad_joob · « **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)

Runer112 · « **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.

the_mad_joob · « **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...

the_mad_joob · « **Reply #87 on:** May 12, 2014, 11:17:11 am »

Still about the keyboard :

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 =/

Streetwalrus · « **Reply #88 on:** May 12, 2014, 11:38:00 am »

Quote from: Runer112 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.

Wow that's a lot.

is it for 15MHz compatibility ?

Runer112 · « **Reply #89 on:** May 12, 2014, 12:51:44 pm »

Quote from: Streetwalrus on May 12, 2014, 11:38:00 am

Quote from: Runer112 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.
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.

Author Topic: WikiTI (Read 83884 times)

Munchor

Re: WikiTI

Deep Toaster

Re: WikiTI

DJ Omnimaga

Re: WikiTI

the_mad_joob

Re: WikiTI

DJ Omnimaga

Re: WikiTI

DrDnar

Re: WikiTI

the_mad_joob

Re: WikiTI

DrDnar

Re: WikiTI

the_mad_joob

Re: WikiTI

the_mad_joob

Re: WikiTI

Runer112

Re: WikiTI

the_mad_joob

Re: WikiTI

the_mad_joob

Re: WikiTI

Streetwalrus

Re: WikiTI

Runer112

Re: WikiTI