I have two, but no way to link them...

i do(i own two and could borrow another from a friend)

Awesome. You probably have zero I/O cables that you'd feel comfortable cutting apart for the sake of testing out 3-calculator linking though, I'm assuming. I should publish "hub" plans so you don't have to cut apart I/O cables to test this stuff, you just need as many I/O cables as calculators.

@EpicFail: No I/O cable?

Nope I had checked out an I/O cable from the library before, and until my school library opens, I won't have one.

actually, Kerm, i have about 3 i/o cables lying around(including not including the one i cut already and spliced with christmas light wires to make it 14 feet long ). dunno if i can find them all, though... my mother is always moving my stuff around because my room doubles as the guest room and she gests embarrassed if anyone sees what a "slob" i am

Oooh, then I might definitely be calling on you to help test out various things!

Anywho, HERE is the video! I'll try very hard to have a video demonstrating a three-calculator network up tomorrow, assuming I don't run into any unexpected glitches from a network containing more than two devices.

SO EPIC! Great work Kerm!

Thanks a lot; I'm quite happy with it.

I really wanna see 3 calc linking, the video reminded me of the sopranos how it cut off right at an important pa-

Epic awesomeness Kerm!!!

forget the video, where can i get that song?! XD
oh, and i'd definitely be willing to help

Hahahaha, then you caught the subtle hint I was trying to make when I plugged in the third calculator at the end...

I don't envision broadcasting to be that bad. The main problem is that it will not be possible for the receiver(s) to acknowledge any broadcast packet's checksum, so the sender will have no way of knowing if any other calculators actually received anything, or if they're busy trying to send at the same time. Indeed, broadcasting is more like UDP, and normal CALCnet transmission and reception is more like stateful TCP with some slight guarantees. I'm going to have to basically:

1) Make each receiver detect if the recipient address is $0000000000, and if so, listen to the packet regardless of what its address is
2) Make each receiver NOT try to ACK the checksum if the recipient address was $0000000000
3) Make each sender not wait for or acknowledge the checksum ACK for any receiver if the recipient of the current packet is 0

I can't think of any link-level changes that will need to be made.

Okay, I have a question. How does the two calculator hook-up differ from the TI-OS routine? It's got SendByte in BASIC. I bet a user could do the same without CalcNet on two calc setup. Just send V for velocity, A for angle and R for row the ball exited the last calc screen on.

But, three Calcs I can see an advantage. Or, if the two calcs worked together to speed up BASIC programs under CN2, that'd be something

Kerm, my friend has an 84+SE like me with the usb to usb, I could use his to test.

An excellent question. First, the TI-OS routines are blocking (and for BASIC, you can only get variables from another calculator that is at a Pause or Menu(), not send or get when the other calculator is doing random things). Blocking means you call SendAByte or GetAByte, and the routine returns once the byte has been successfully sent or received (or failed after a certain amount of time). With CALCnet2.2, transmission is non-blocking or asynchronous. You dump the data to be sent into a buffer, then continue running your program normally. CALCnet2.2's interrupt will run eventually, notice the data in the buffer, and try to send it. It will reset a bit in that buffer once the data has been sent successfully, so you'll know. On the receiving side, you can occasionally check a bit of the receive buffer, and once it gets set, you know there's a packet waiting for you. You can easily leave it there for a while until you're ready to deal with it, then eventually grab it out and clear two bytes of the buffer so Cn2.2 can start accepting more data on your behalf.

Besides the blocking/non-blocking, CALCnet2.2 allows, and in fact is built upon, packets that are larger than a single byte. This is helpful for most of the calculator's link-based applications, like most current games, plus bulk data transfer like programs.

Finally, and most importantly, CALCnet2.2 is built for >2-calculator linking, which will be tested and demonstrated tomorrow if the fates are with me.

That would be cool too.

WE CAN HAZ LINKED POKEMON PURPLE TRADING AND BATTLEZ!?!


...and if TIFreak happens to impliment it...

And if I happen to implement BASIC libraries. The BASIC interface would be quite challenging, because I'd have to make sure the interrupt would play nice with BASIC _and_ with the xLIB/DCS/Celtic/PicArc/Omnicalc libraries. That might end up requiring me to make them blocking for BASIC programs, which isn't an idea I relish at all.

Nice stuff here! Assuming that you didn't cheat with math vector calculations (and that both calcs know EXACTLY where the ball is at all times), this is really really REALLY REALLY promising. Maybe you haven't realized it, but you just revolutionized TI calc multiplayer gaming. Congrats!

Anyway, some evil little demands:

- BASIC BASIC BASIC BASIC support! Yes, I've seen your replies - maybe you can integrate it into the BASIC parser itself? (And no, I'm not confused with DCS - I'm actually talking about the TI-BASIC parser) And as always, you can have those security settings inside DCS (or outside, should you also distribute it separately).

- USB USB USB USB support! Not that I want to really put more on your plate, but it's pretty essential IMO. For those who have TI-84s, we won't be having little link wires, but mini USB A to mini USB B cables. And personally, I don't really want to have to buy a regular I/O cable just to have fun with Calcnet2. (I will, eventually) You can use perph8x (or so I've heard) as a base for USB comm perhaps?

- AXE AXE AXE AXE support! Just a thought, maybe you could implement an AXE plugin with the Axiom SDK? That would be a pretty fun thing to play with!

Again, congrats on your success! I'm hoping to see where this project will go. Will it be in DCS? Separate lib?

Cheers, I was hoping that might be the case.

We'll see. It sounds like a pretty mind-boggling complex task, though, at this point.

If I do this at all it will be far, far in the future.

Someone needs to teach me how to make Axioms.

At this point it's going to be an ALE (Appended Library Extension), basically a shared library for you *nix users.

Maybe use some code from DCS? (Random speculation)

You can always contract the work out to Mr USB PRO (hint: BrandonW)

http://ourl.ca/6229 or http://www.cemetech.net/forum/viewtopic.php?p=105494

Good idea! I'm assuming that'll be for DCS? Or am I missing the point? (The closest thing I could think about is the TI-84 OpenLib(, ExecLib( feature.)