kerm_martian wrote:Edit: actually, I guess I should make my own routines then.
[Featured][Alpha] CLAP - TI Link - http://clap.timendus.com
Moderator: MaxCoderz Staff
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).kerm_martian wrote:So that I'll have something to put in DCS6...unless of course you feel like sharing the routines or the basic idea.Timendus wrote:Why would you do that?
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 breakRe: interrupts: I might as well share the modes I came up with for CALCnet2.1:
[...]
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
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?passively interrupts and checks for address byte transmission; quits if none.
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
http://api.timendus.com/ - Make your life easier, leave the coding to the API
http://vera.timendus.com/ - The calc lover's OS
Woot, CoBB released a new PTI version! So check out this little networking demo:
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 Pressing clear in the master calc screen makes all the slaves exit too, pressing clear in a slave only exits that slave.
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 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
http://api.timendus.com/ - Make your life easier, leave the coding to the API
http://vera.timendus.com/ - The calc lover's OS
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
@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
http://api.timendus.com/ - Make your life easier, leave the coding to the API
http://vera.timendus.com/ - The calc lover's OS
-
- Calc King
- Posts: 2195
- Joined: Sun 27 Mar, 2005 4:06 am
- Location: sleeping
- Contact:
- KermMartian
- Calc Wizard
- Posts: 549
- Joined: Tue 05 Jul, 2005 11:28 pm
- Contact:
Good to know. By now actually, I'm considering just making my own routines anyway, especially if DCS6 is a SoC project.Timendus wrote: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).kerm_martian wrote:So that I'll have something to put in DCS6...unless of course you feel like sharing the routines or the basic idea.Timendus wrote:Why would you do that?
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: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 breakRe: interrupts: I might as well share the modes I came up with for CALCnet2.1:
[...]
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: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.
Indeed, and I plan to add as many checks to prevent misreads and hangs as possible.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
. 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: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
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.Timendus wrote: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?passively interrupts and checks for address byte transmission; quits if none.
In that case I cannot allow you to use or even read my routines Anyway, good luck with itkerm_martian wrote:I'm considering just making my own routines anyway, especially if DCS6 is a SoC project.
What did you improve on it? You're still using a clock and a data line, aren't you? Added checksums or something?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.
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.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.
Once more; good luckIndeed, and I plan to add as many checks to prevent misreads and hangs as possible.
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.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.
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 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
http://api.timendus.com/ - Make your life easier, leave the coding to the API
http://vera.timendus.com/ - The calc lover's OS
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
http://api.timendus.com/ - Make your life easier, leave the coding to the API
http://vera.timendus.com/ - The calc lover's OS
- KermMartian
- Calc Wizard
- Posts: 549
- Joined: Tue 05 Jul, 2005 11:28 pm
- Contact:
Thanks, I hope it turns out well.Timendus wrote:In that case I cannot allow you to use or even read my routines Anyway, good luck with itkerm_martian wrote:I'm considering just making my own routines anyway, especially if DCS6 is a SoC project.
Point taken. What about if the calcs are separated by several hundred feet of wire though?Timendus wrote:What did you improve on it? You're still using a clock and a data line, aren't you? Added checksums or something?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.
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.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.
diTimendus wrote:Once more; good luckIndeed, and I plan to add as many checks to prevent misreads and hangs as possible.
How can a calc "accidentally" not hit an interrupt for a while? It's pretty closely defined how and when interrupts are triggeredThe 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.
Since when?! I also want my routines to be compatible with non-+s.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.
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: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.
Good luck with the fix.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 I'll try to fix it this afternoon
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 longkerm_martian wrote:Point taken. What about if the calcs are separated by several hundred feet of wire though?
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.di
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 itSince when?! I also want my routines to be compatible with non-+s.
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.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 fixed it! Yay And I added another little somethingGood luck with the fix.
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
http://api.timendus.com/ - Make your life easier, leave the coding to the API
http://vera.timendus.com/ - The calc lover's OS
- KermMartian
- Calc Wizard
- Posts: 549
- Joined: Tue 05 Jul, 2005 11:28 pm
- Contact: