[Featured][Alpha] CLAP - TI Link - http://clap.timendus.com

Here you can find side projects of the staff and great projects which we think should get extra support. (Note that featured projects are not projects by staff members of MaxCoderz)

Moderator: MaxCoderz Staff

User avatar
kalan_vod
Calc King
Posts: 2932
Joined: Sat 18 Dec, 2004 6:46 am
Contact:

Post by kalan_vod »

kerm_martian wrote:Edit: actually, I guess I should make my own routines then. :)
;)
User avatar
Timendus
Calc King
Posts: 1729
Joined: Sun 23 Jan, 2005 12:37 am
Location: Netherlands
Contact:

Post by Timendus »

kerm_martian wrote:
Timendus wrote:Why would you do that?
So that I'll have something to put in DCS6...unless of course you feel like sharing the routines or the basic idea.
Like I said before, I plan to release everything. The libraries with routines, the protocol, even the demos. That's how I work. I write things so that others can benefit from them. And even though I may not be particulary fond of you, once it's public domain you may use it however you see fit if you give proper credit (and preferably link to the CLAP website).
Re: interrupts: I might as well share the modes I came up with for CALCnet2.1:

[...]
Heheh... You've been reading my publications too well :) I know what I said, but I was wrong about a few things in that essay about networking. Hey, it was almost four years ago, give me a break ;)

For one; you don't need to boost the signal. I wrote that you'd have to invert the signals, because they are active low, or otherwise you'd probably have to boost them. I now know a bit more about electronics however, and because they are active low they don't need either inverting or boosting. It's got nothing to do with current, only with resistance. The only problem that can occur is that the lines are too long, or poorly soldered, and give too much resistance or a signal delay.

The clock and data lines are still used in what I'm currently working with, but in a more time intensive way than I wrote about back then, because it adds stability and a clear byte end. Someone once wrote here that he tried to use my link routines, but he couldn't get them to sync. I thought a lot about that because it very much annoyed me, and revised my strategy. Security > speed :)

The third thing I changed my mind about is all the checking and testing and timing out. I wrote a long list of things you'd need to check and things you'd need to time out on or wait for, but all that just adds overhead, not stability. I have a different way to make sure my lines are clear now, and there's no echo, no ping, no nothing. Not yet at least. I'll probably have to put a ping back in :)
passively interrupts and checks for address byte transmission; quits if none.
How do you intend to do this? How do you make sure that you don't start listening half way a transmission and mistake random bits for an address byte? I found an answer, have you? ;)
http://clap.timendus.com/ - The Calculator Link Alternative Protocol
http://api.timendus.com/ - Make your life easier, leave the coding to the API
http://vera.timendus.com/ - The calc lover's OS
User avatar
Timendus
Calc King
Posts: 1729
Joined: Sun 23 Jan, 2005 12:37 am
Location: Netherlands
Contact:

Post by Timendus »

Woot, CoBB released a new PTI version! So check out this little networking demo:

Image

I run the same program on all four calculators, it automatically detects if a network is present or not and if not it becomes the master. You'll understand that the two rightmost calculators are supposed to be under the first two instead of next to them ;)

Binary download

You have to start the program in the right order, otherwise it doesn't know which screen goes where :P Pressing clear in the master calc screen makes all the slaves exit too, pressing clear in a slave only exits that slave.
Last edited by Timendus on Tue 16 May, 2006 3:53 pm, edited 1 time in total.
http://clap.timendus.com/ - The Calculator Link Alternative Protocol
http://api.timendus.com/ - Make your life easier, leave the coding to the API
http://vera.timendus.com/ - The calc lover's OS
User avatar
benryves
Maxcoderz Staff
Posts: 3087
Joined: Thu 16 Dec, 2004 10:06 pm
Location: Croydon, England
Contact:

Post by benryves »

Wow. This is great stuff! DOOM-style deathmatches, here we come? :D
User avatar
kalan_vod
Calc King
Posts: 2932
Joined: Sat 18 Dec, 2004 6:46 am
Contact:

Post by kalan_vod »

OMG, sorry the the unintelligible post....but it looks great! and a big thanks to CoBB!
User avatar
Timendus
Calc King
Posts: 1729
Joined: Sun 23 Jan, 2005 12:37 am
Location: Netherlands
Contact:

Post by Timendus »

Hmm, I tried to quickly edit the demo to put all the screens next to each other. The total screen size is a define, so that was easy. Changing the order of the screens wasn't too difficult either. But 4*96 pixels can't be stored in one byte, so I had to change my one byte x-coord to two bytes everywhere, and now the program has a bit of a bug... Sigh... I'm too bored and too tired to try to fix it, so good night y'all :)

@Ben: I think I'll need to optimize the hell out of my routines, and make them an interrupt, before they can effectively be used in any type of real time game, let alone a Doom game ;)
http://clap.timendus.com/ - The Calculator Link Alternative Protocol
http://api.timendus.com/ - Make your life easier, leave the coding to the API
http://vera.timendus.com/ - The calc lover's OS
threefingeredguy
Calc King
Posts: 2195
Joined: Sun 27 Mar, 2005 4:06 am
Location: sleeping
Contact:

Post by threefingeredguy »

Holy crap on a stick. That looks incredible.
Image
User avatar
KermMartian
Calc Wizard
Posts: 549
Joined: Tue 05 Jul, 2005 11:28 pm
Contact:

Post by KermMartian »

Timendus wrote:
kerm_martian wrote:
Timendus wrote:Why would you do that?
So that I'll have something to put in DCS6...unless of course you feel like sharing the routines or the basic idea.
Like I said before, I plan to release everything. The libraries with routines, the protocol, even the demos. That's how I work. I write things so that others can benefit from them. And even though I may not be particulary fond of you, once it's public domain you may use it however you see fit if you give proper credit (and preferably link to the CLAP website).
Good to know. By now actually, I'm considering just making my own routines anyway, especially if DCS6 is a SoC project.
Timendus wrote:
Re: interrupts: I might as well share the modes I came up with for CALCnet2.1:

[...]
Heheh... You've been reading my publications too well :) I know what I said, but I was wrong about a few things in that essay about networking. Hey, it was almost four years ago, give me a break ;)
Some of it is based on that, but imho I added some new stuff since then. My biggest improvement was the bit-level, lowest protocol.
Timendus wrote:For one; you don't need to boost the signal. I wrote that you'd have to invert the signals, because they are active low, or otherwise you'd probably have to boost them. I now know a bit more about electronics however, and because they are active low they don't need either inverting or boosting. It's got nothing to do with current, only with resistance. The only problem that can occur is that the lines are too long, or poorly soldered, and give too much resistance or a signal delay.
I'm not entirely sure about that...you think one calc running 4 AAA batteries can send sufficient current to trigger the link ports of 250 other calcs? 'Cause I sure don't.
Timendus wrote:The clock and data lines are still used in what I'm currently working with, but in a more time intensive way than I wrote about back then, because it adds stability and a clear byte end. Someone once wrote here that he tried to use my link routines, but he couldn't get them to sync. I thought a lot about that because it very much annoyed me, and revised my strategy. Security > speed :)
Indeed, and I plan to add as many checks to prevent misreads and hangs as possible.
Timendus wrote:The third thing I changed my mind about is all the checking and testing and timing out. I wrote a long list of things you'd need to check and things you'd need to time out on or wait for, but all that just adds overhead, not stability. I have a different way to make sure my lines are clear now, and there's no echo, no ping, no nothing. Not yet at least. I'll probably have to put a ping back in :)
. The only way to do that is to use just assume all calcs are still there, adding on new ones at the end instead of bothering removing old ones, and then ping specific ones to check if they're still available. Also, this would prevent problems with calcs accidentally quitting just because they don't hit an interrupt for a while.
Timendus wrote:
passively interrupts and checks for address byte transmission; quits if none.
How do you intend to do this? How do you make sure that you don't start listening half way a transmission and mistake random bits for an address byte? I found an answer, have you? ;)
Indeed I have. It depends on making the clock pattern for the start and end of byte transmission unique from any pattern that could possibly be sent in the middle of a packet: ie, specific, longer times for holding the clock line low before and after the transmission of each byte.
Image Image Image
User avatar
Timendus
Calc King
Posts: 1729
Joined: Sun 23 Jan, 2005 12:37 am
Location: Netherlands
Contact:

Post by Timendus »

kerm_martian wrote:I'm considering just making my own routines anyway, especially if DCS6 is a SoC project.
In that case I cannot allow you to use or even read my routines ;) Anyway, good luck with it :)
Some of it is based on that, but imho I added some new stuff since then. My biggest improvement was the bit-level, lowest protocol.
What did you improve on it? You're still using a clock and a data line, aren't you? Added checksums or something?
I'm not entirely sure about that...you think one calc running 4 AAA batteries can send sufficient current to trigger the link ports of 250 other calcs? 'Cause I sure don't.
Like I said; it's got nothing to do with current. Only with resistance. You just close the circuit between one of the lines and the ground, and that will route the 5 volts, 250x[whatever] ampere power to 250 grounds, because everything is connected.
Indeed, and I plan to add as many checks to prevent misreads and hangs as possible.
Once more; good luck :)
The only way to do that is to use just assume all calcs are still there, adding on new ones at the end instead of bothering removing old ones, and then ping specific ones to check if they're still available. Also, this would prevent problems with calcs accidentally quitting just because they don't hit an interrupt for a while.
How can a calc "accidentally" not hit an interrupt for a while? It's pretty closely defined how and when interrupts are triggered :) Also; the link port itself probably gives a useful interrupt. So I intend to disable all interrupts except for the link port interrupt, so that my routine will be called as soon as something happens. Next to that they will synchronize before each byte in a way that will even work without the interrupt trick working, and in a way that is distinguishable from the Ti-OS replies.

Also; we're not dealing with a real network here. It's not like on the Internet; we don't know what's going on in that server in Hongkong, so we have to fear the worst, and check for everything. On calculators you know exactely what's going on, you have all machines right in front of you, and if something goes wrong I intend to just ditch (and perhaps auto-reconnect) the machine that fucked up. Also; most people don't keep adding and removing calculators from the network. They will set up a network to play a game with or something, play the game, and take the network apart when they're done.

I think I know what causes my bug, by the way, I think I found the answer when I was lying in my bed this night :P I'll try to fix it this afternoon :)
http://clap.timendus.com/ - The Calculator Link Alternative Protocol
http://api.timendus.com/ - Make your life easier, leave the coding to the API
http://vera.timendus.com/ - The calc lover's OS
CoBB
MCF Legend
Posts: 1601
Joined: Mon 20 Dec, 2004 8:45 am
Location: Budapest, Absurdistan
Contact:

Post by CoBB »

Timendus wrote:Also; the link port itself probably gives a useful interrupt.
You can't rely on that, since only the 83+ and its descendants do so.
User avatar
Timendus
Calc King
Posts: 1729
Joined: Sun 23 Jan, 2005 12:37 am
Location: Netherlands
Contact:

Post by Timendus »

You mean the Ti-83 doesn't? Well, like I said, the synchronize should work with or without the interrupt trigger, but if I can rely on the interrupt I could make things faster...
http://clap.timendus.com/ - The Calculator Link Alternative Protocol
http://api.timendus.com/ - Make your life easier, leave the coding to the API
http://vera.timendus.com/ - The calc lover's OS
CoBB
MCF Legend
Posts: 1601
Joined: Mon 20 Dec, 2004 8:45 am
Location: Budapest, Absurdistan
Contact:

Post by CoBB »

Neither the 82-85-86.
User avatar
KermMartian
Calc Wizard
Posts: 549
Joined: Tue 05 Jul, 2005 11:28 pm
Contact:

Post by KermMartian »

Timendus wrote:
kerm_martian wrote:I'm considering just making my own routines anyway, especially if DCS6 is a SoC project.
In that case I cannot allow you to use or even read my routines ;) Anyway, good luck with it :)
Thanks, I hope it turns out well.
Timendus wrote:
Some of it is based on that, but imho I added some new stuff since then. My biggest improvement was the bit-level, lowest protocol.
What did you improve on it? You're still using a clock and a data line, aren't you? Added checksums or something?
I'm not entirely sure about that...you think one calc running 4 AAA batteries can send sufficient current to trigger the link ports of 250 other calcs? 'Cause I sure don't.
Like I said; it's got nothing to do with current. Only with resistance. You just close the circuit between one of the lines and the ground, and that will route the 5 volts, 250x[whatever] ampere power to 250 grounds, because everything is connected.
Point taken. What about if the calcs are separated by several hundred feet of wire though?
Timendus wrote:
Indeed, and I plan to add as many checks to prevent misreads and hangs as possible.
Once more; good luck :)
The only way to do that is to use just assume all calcs are still there, adding on new ones at the end instead of bothering removing old ones, and then ping specific ones to check if they're still available. Also, this would prevent problems with calcs accidentally quitting just because they don't hit an interrupt for a while.
How can a calc "accidentally" not hit an interrupt for a while? It's pretty closely defined how and when interrupts are triggered :)
di
Timendus wrote:Also; the link port itself probably gives a useful interrupt. So I intend to disable all interrupts except for the link port interrupt, so that my routine will be called as soon as something happens. Next to that they will synchronize before each byte in a way that will even work without the interrupt trick working, and in a way that is distinguishable from the Ti-OS replies.
Since when?! I also want my routines to be compatible with non-+s.
Timendus wrote:Also; we're not dealing with a real network here. It's not like on the Internet; we don't know what's going on in that server in Hongkong, so we have to fear the worst, and check for everything. On calculators you know exactely what's going on, you have all machines right in front of you, and if something goes wrong I intend to just ditch (and perhaps auto-reconnect) the machine that fucked up. Also; most people don't keep adding and removing calculators from the network. They will set up a network to play a game with or something, play the game, and take the network apart when they're done.
True, but if one calc freezes up during transmission because of faulty game programming, I don't want it to take the whole network down with it.
Timendus wrote:I think I know what causes my bug, by the way, I think I found the answer when I was lying in my bed this night :P I'll try to fix it this afternoon :)
Good luck with the fix.
Image Image Image
User avatar
Timendus
Calc King
Posts: 1729
Joined: Sun 23 Jan, 2005 12:37 am
Location: Netherlands
Contact:

Post by Timendus »

kerm_martian wrote:Point taken. What about if the calcs are separated by several hundred feet of wire though?
Then you'll have a delay to take into account, and less noticeable differences in resistance that can be a problem (since "no resistance" now means "a bit of resistance" because of the length of the cable). The rest is the same. Just don't use cables that long ;)
di
Okay, so you have a program that sets a custom interrupt handler for networking purposes, and you make that program di..? Why the hell would you do that? ;) Besides, that's not very accidentally.
Since when?! I also want my routines to be compatible with non-+s.
Since when what? And it's a shame that Ti-82/83/85/86 don't have the link port interrupt, but I'll work around it :)
True, but if one calc freezes up during transmission because of faulty game programming, I don't want it to take the whole network down with it.
I don't give a damn about faulty game programmers. If you can't code, that's none of my business. The networking routines, when used properly, will be stable enough for normal use purposes.
Good luck with the fix.
I fixed it! Yay :mrgreen: And I added another little something :yes:

Image

I noticed however, that the calcs have trouble connecting sometimes in PTI when I just sent a file to it. That has probably something to do with the lines being set wrong by the emulated HUB when it auto disconnects for a file transfer or something, but that's not really important. The point is that it can be a pain in the ass if the transfers end up non-aligned and one of the calcs gets stuck waiting for more bits to come. At that point I can choose to reset it or manually send some more bits untill it pops out... So that's no good. I'll have to add some timeouts or something.
Last edited by Timendus on Tue 16 May, 2006 3:54 pm, edited 1 time in total.
http://clap.timendus.com/ - The Calculator Link Alternative Protocol
http://api.timendus.com/ - Make your life easier, leave the coding to the API
http://vera.timendus.com/ - The calc lover's OS
User avatar
KermMartian
Calc Wizard
Posts: 549
Joined: Tue 05 Jul, 2005 11:28 pm
Contact:

Post by KermMartian »

Enough stuff for me for now. Congrats. :)
Image Image Image
Post Reply