In October 2006, I was working hard on CALCnet2.2, the then-latest incarnation of my long-suffering calculator networking project. After years of effort, I had finally succeeded in sending data over CALCnet2.2, emulated on the PTI debugger. Due to time constraints with schoolwork, I never got a chance to pick up the project again, until the end of this August when I finally finished and released Doors CS 7.0. I decided that in the foreseeable future I'm going to try to pick up and either finish or let hibernate three of my past projects, CALCnet, my N-game pseudo-clone M-Game, and Civilization Simulator II. Over the past week I've been sporadically toying with CALCnet2.2 in the midst of my other projects and work, and I'm happy to say that CALCnet2.2 has sent its first few successful messages over two real networked calculators. The evidence:



This evening I'm going to write the simplest of two-calculator pong demos (first just bouncing, and maybe later with players and paddles), then I need to implement a send-to-all broadcast functionality before I can demonstrate a four-calculator network. CALCnet can theoretically support an arbitrary number of calculators, but I have only a limited number of unit to unit cables to cut apart. Feel free to donate some.

Comments and thoughts? Suggestions? Suggested applications? Questions?

OHHH EHMMM GEEEE!

This is great Kerm, I cant wait for a beta release

Congrats KermM!

I was wondering:
1) ...will this eliminate (or at least minimize) the delay for linking? Usually, it's so slow that it's pretty painful to watch. (I tried to write a ping pong program once in BASIC, and it was like 1 second per transfer...)

2) ...will this be available anytime? In BASIC, you would have to be at the home screen or on an Input/Pause to be able to fetch a variable. If the program calls Calcnet2 (enables it), will it be available for communication at all times, regardless of the current state?

3) ...does this support USB linking? (As in using the mini USB B to mini USB B cable) I'm hoping this isn't just limited to the ordinary, 2.5mm link cable!

Very nice stuff here! My suggestion (and hope) is to implement this in DCS as Basic and ASM APIs. That would really start a new revolution!
(And possibly allow dual player MARIO ) Also, a separate implementation (apart from DCS) would be great too.

Our (graphmastur and I) project is a bit different from this (more like gCn with some more goodies). Are there any plans for gCn in the future? Or will we be the first to implement some truly fun/useful calculator <-> internet?

Thanks qazz. I haven't figured out exactly how I want to package it yet. The networking driver itself is just under 1K, so it seems a bit silly to package it separately. However, I'm hesitant to put it into Doors CS, because I only have slightly above 1K free in the app total. What would people think of it being a (GASP) ALE? I think that would be exactly the kind of thing the ALE system should be used for.

*bump*

It'll certainly reduce the latency of transfers. They won't be super-duper speedy, no more than a handful of KB per second.

Not at this point. Because of the power it has, especially the opportunities for misusing that power and making things go freezy or crashy, I'm (for now) thinking of only permitting Cn2 inside DCS ASM programs that use the ALE.

No, it's for 2.5mm link cables. There's no point in trying to override the USB protocol with a multipoint-to-multipoint protocol.

Oh geez, a dual-player Mario. >_< I should make my pong sprite be Mario.

There are indeed plans for gCn, and I've been careful to preserve its functionality while I work on the Cn2 drivers. No promises on a timeframe, though.

I wasn't expecting super speedy, just speedy enough so that I don't have to wait 1 second per pong frame.


That's kind of disappointing, considering the awesomeness of Calcnet2. It is a good point, but you could add a security layer to enable/disable both ASM and Basic API access.

That's pretty disappointing, considering that USB is equally slow too. Maybe a small wrapper for USB in Calcnet2?

I was , but lols for that.


Could you name some plans, or are you keeping that secret for now?
For us, we'll try to get it up and available+running by late Fall 2010, but as always, no guarantees!

I agree that a BASIC interface might be nice, but that's a bit further down the line. I'm not sure exactly how the USB part would work; it's not like you can just splice USB lines together the way you can with 2.5mm serial lines. As far as I can tell, that would only be useful for two-calculator transfers, which I guess would be most people's use of CALCnet2 as well.

I'll be revealing some details as soon as I finish some more demos and implement broadcasting.

*bump* Success of project [size=x-small]Mario[/size] CALCnet2.2 Pong demo! I have a tentative program written, I've (somewhat painfully, sorry Buckeye) tested it emulated between two calculators, and I've tested in working for a few volleys on two hardware calculators! Currently a [size=x-small]Mario sprite[/size] ball bounces around the screen; if it reaches one of the shared screen edges, it continues bouncing on the other calculator until it comes back to the shared edge and continues on the first calculator. As expected, there are some glitches with synchronization that incur some slight delays at the shared edges; I'll be working on that next. In fact, my Cn2.2 plan of attack from here:

1) Track down and eradicate sync issues
2) Screenshot, record, and post the program in action
3) Implement broadcasting
4) Debug broadcasting
5) Update Cn2.2 Pong to use real SSIDs instead of fakes ones.
6) Update Cn2.2 Pong to automagically span arbitrary numbers of calculator screens
7) More publicity!

*bump* Before work this morning I quickly fixed one silly bug that was making both calculators lose the sprite eventually; it was something with my demo program, not with any CALCnet2.2 failure. I will continue to stare at the Cn2.2 driver code to try to figure out whence the synchronization bug. My debug display pixels show that while the sync bug is occurring, both calculators are actively in the send and receive states respectively, so the problem must be that one of the calculators is either timing out or NACKing the transfer.

Edit: Oh, and a note to myself or any other interested parties: I realized that when the receiver was started before the sender in my Cn2Test program, partial messages were sometimes being transmitted because I was simply ldir'ing the message to the buffer, and since the flag that the message is ready for sending is in the size byte near the beginning of the message, the interrupt was, well, interrupting the ldir before it was finishing, seeing that flag, and trying (and succeeding) to send the partially-complete message.

Very nice KermM I hope we get a basic interface for this soon

On my subway ride to work this morning, I figured out what I think is the solution to the sync problem, plus a way to halve the latency of sends. I'll post momentarily if it's successful. What immediate applications would everyone have for CALCnet2.2?

You must be insane to not know the answer to that! Multiplayer gaming, of course!

It's a LOT faster, and the old silliness of TI's linking is horrifying. Ever heard of Chopper? That game, with 2 players, is just like watching a movie in slow motion (1 fps)... With this, it's definitely going to be MUCH faster!

(Which is why I'd like to see a Basic/ASM API for it)

Multiplayer gaming of course, but what games in particular? Oh, one thing I'm going to try to do is benchmark a one-way saturated link at different packet sizes on networks of different sizes, and see what kind of speeds I can burst. I don't expect them to be too insanely impressive in terms of blowing away existing protocols, but I expect the average latency of <1/55th of a second (more like 1/110th + epsilon) to be fairly impressive.

Certainly pong, a battle engine, and maybe another game.

For my more-than-two calculator pong demo, I'm planning on making you line up all the calcs side-by-side, and making the play field 64 pixels x (96*number_of_calcs) pixels long, with the end calculators controlled by the two different players. How does that sound? Can you think of some other fun arrangement, like some odd kind of four-or-more-player Pong?

*bumpity bump* Success on the timing fix! A TI-84+, TI-84+SE, and a TI-83+ have been successfully tested in all three possible configurations sending and receiving to one another with little to no latency! \o/

Should I post a video of this working before I move on, or should I just into the three- or four-calculator setup, which will require me to write the broadcasting code and write quite a bit more code in the CN22PONG program.

Hmmm.... Go for an Epic battle like some sort of stick wars game with swords, guns, and anything else. :O

A video would be nice, to see the timing and all.

HUZZAH
you should post a video WHILE moving on.
this will be a thing of beauty

Shmibs and EpicFail, sounds good then, lemme quickly take it now, then.

Edit: Videos take, uploading soon. How many people other than me actually have two, three, or more calculators to test this out?