CALCnet2.2: Success!

A forum where you can announce your awesome project(s).

Moderator: MaxCoderz Staff

User avatar
KermMartian
Calc Wizard
Posts: 549
Joined: Tue 05 Jul, 2005 11:28 pm
Contact:

CALCnet2.2: Success!

Post by KermMartian »

Please don't kill me for the messianic tone of this post; it's copied straight from the Cemetech news page, and I love writing overblown articles. Looks like it's on now, Timendus!

A historic occasion! At 8:31AM EST, on this Friday, October 13th, 2006, CALCnet2.2 successfully sent and acknowledged its first message across a calculator network. In roughly 1/200th of a second, one of four networked emulated calculators sent 5 receiver SID bytes, 5 sender SID bytes, 2 size bytes, and the ascii message, "Cemetech shall rule the world!" to another one. The CALCnet2.2 routines were running as semi-blocking interrupts coexisting with a Doors CS 6 beta running at nearly full speed in the foreground. This heralds a major milestone for Doors CS, CALCnet2, and globalCALCnet: now that sending and receiving between calculators is possible, all of the wide and varied applications of calculator networking are ready to be explored.

For those unfamiliar with CALCnet2.2, it is the third major revision of the CALCnet protocol, and the first to be brought fully to fruition. CALCnet, later appended the designation 1.0 when later CALCnet protocols were developed, was interrupt-based yet built on a highly error-prone system. Since it was one of my first forays into z80 assembly programming, the code was extraordinarily buggy, not to mention uncompilable. CALCnet2 was my second wave of efforts on the project, in which I made great numbers of improvements to the theory behind the protocol. CALCnet2 owed a substantial percentage of its inspiration to a networking paper published by MaxCoderz' Timendus on ticalc.org, yet even this version was never completely written. Finally, in July 2006, I sat down and worked out a version of CALCnet based enough on CALCnet2 not to deserve a new major version number, but encompassing a vast number of improvements. Especially stressed was the amount of error checking; unlike any previous iteration of CALCnet, it was specifically designed to be used as an interrupt. Calculators are now identified not by cascading, dynamic assignation during network connection, but by the 5-byte unique serial number every real (non-emulated) calculator contains from its creation. This eliminates all of the network integrity checks that had been necessary in CALCnet2.2. In addition, all routines are heavily protected against locking up the calculator, and by using a pair of buffers instead of directly sending data between client programs and the interrupt, the CALCnet2.2 interrupt's actions are completely transparent to the client programs running on the calculator.

In the next few days, CALCnet2.2 will continue to be debugged, and I will be working on some fancy-looking demos. The only minor drawback of testing CALCnet2.2 on emulated hardware is that I also have to fake SIDs, since ROM images do not contain SIDs. Oh, and I have successfully tested Cn2 as working across all known TI-83+ ROM images.

Without further ado, here's the proof of this momentous occasion: the contents of the receiving calc's 256-byte receive buffer:

Image
Image Image Image
User avatar
benryves
Maxcoderz Staff
Posts: 3087
Joined: Thu 16 Dec, 2004 10:06 pm
Location: Croydon, England
Contact:

Post by benryves »

Excellent stuff. :) Looking forwards to seeing a demo!
User avatar
KermMartian
Calc Wizard
Posts: 549
Joined: Tue 05 Jul, 2005 11:28 pm
Contact:

Post by KermMartian »

Thanks! I'm debating what to do for the demo; I'm considering replicating Timendus' bouncing ball demo, but I'm not completely set on that yet. Any suggestions?
Image Image Image
User avatar
benryves
Maxcoderz Staff
Posts: 3087
Joined: Thu 16 Dec, 2004 10:06 pm
Location: Croydon, England
Contact:

Post by benryves »

I'd be quite interested in seeing something that involved parallel processing - when you plug in the second calculator it can offload half of the task to it and the "results" can be passed back to the first (so you can see a noticable increase in speed). I can't think of a good example, though, as a simple "render something cool" wouldn't work so well given that it's probably more expensive to transfer the two halves of the image than to generate them in the first place.
User avatar
KermMartian
Calc Wizard
Posts: 549
Joined: Tue 05 Jul, 2005 11:28 pm
Contact:

Post by KermMartian »

Yeah, you're probably right about that. I'll continue pondering, I suppose.
Image Image Image
CoBB
MCF Legend
Posts: 1601
Joined: Mon 20 Dec, 2004 8:45 am
Location: Budapest, Absurdistan
Contact:

Post by CoBB »

Well, if you tell me where the serial numbers come from, I could make PTI to ensure that it will be different in each slot (unless this breaks something, of course).
User avatar
KermMartian
Calc Wizard
Posts: 549
Joined: Tue 05 Jul, 2005 11:28 pm
Contact:

Post by KermMartian »

That would be pwnsome; say, make them 00000001, 00000002, etc.
The problem is, I'm not positive where it's stored in ROM; I get it via a ROMCall, which I assume reads from a privileged page. The call is to $807E.

Ah, here's some data:
http://wikiti.denglend.net/index.php?ti ... ertificate

O.o No idea how to fake it from that....

Update! An oncalc screenie.
Image
Image Image Image
User avatar
thegamefreak0134
Extreme Poster
Posts: 455
Joined: Mon 23 Jan, 2006 10:09 pm
Location: In front of a Computer, coding
Contact:

Post by thegamefreak0134 »

Forgive my ignorance here, but I fail to see what exactly the breakthrough of the hour is. Why is this any different than normal communication?
I'm not mad, just a little crazy.

DarkNova - a little side project I run.
User avatar
kv83
Maxcoderz Staff
Posts: 2735
Joined: Wed 15 Dec, 2004 7:26 pm
Location: The Hague, Netherlands
Contact:

Post by kv83 »

Tim is not actual MaxCoderz Staff btw :)
Image
User avatar
KermMartian
Calc Wizard
Posts: 549
Joined: Tue 05 Jul, 2005 11:28 pm
Contact:

Post by KermMartian »

thegamefreak0134 wrote:Forgive my ignorance here, but I fail to see what exactly the breakthrough of the hour is. Why is this any different than normal communication?
Because it allows *networking*, although I've only shown it here between two calculators. It can synchronize and detect packet collision over a scalable network. I'm working on a demo to show its multicalc abilities.
Image Image Image
User avatar
Timendus
Calc King
Posts: 1729
Joined: Sun 23 Jan, 2005 12:37 am
Location: Netherlands
Contact:

Post by Timendus »

Well congratulations, you've got something working! :) It was about time, wasn't it? ;)

Thanks for the credit, by the way... it is unexpected after your prior denial that you had read my stuff, but all the more appreciated :)
kerm_martian wrote:Image
I see you use my debugging thingy too. There's a new and improved version of that on the CLAP website if you didn't know that, which can also receive, buffer and display a datastream. That is; if you use the same basic protocol as I do which I kinda expect.

As Vincent said; I'm not a member of Maxcoderz. I'm officially a member of Smitemeister Software, but since I'm pretty much the only member left of that group, I "work" independant and post ideas on this forum.

So, why don't you start up another DCS screen and transfer that string from one calculator to another without bothering the third..? And then from calculator two to calculator three or whatever. That would be a good first (quick) "demo" that it's actual networking and not just one on one transfer.
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 »

Timendus wrote:Well congratulations, you've got something working! :) It was about time, wasn't it? ;)

Thanks for the credit, by the way... it is unexpected after your prior denial that you had read my stuff, but all the more appreciated :)
I read your thing about cascading checks long ago on ticalc.org, but I've never so much as glanced at a single opcode of CLAP.
Timendus wrote:
kerm_martian wrote:Image
I see you use my debugging thingy too. There's a new and improved version of that on the CLAP website if you didn't know that, which can also receive, buffer and display a datastream. That is; if you use the same basic protocol as I do which I kinda expect.
As far as I know the protocols are completely different, so I doubt it would work for mine.
Timendus wrote:As Vincent said; I'm not a member of Maxcoderz. I'm officially a member of Smitemeister Software, but since I'm pretty much the only member left of that group, I "work" independant and post ideas on this forum.
I know that... dunno why Vincent thought I was saying you were a Maxcoderz member.
Timendus wrote:So, why don't you start up another DCS screen and transfer that string from one calculator to another without bothering the third..? And then from calculator two to calculator three or whatever. That would be a good first (quick) "demo" that it's actual networking and not just one on one transfer.
I'm doing better than that - I'm replicating your "pong" demo with Cn2.2.
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 read your thing about cascading checks long ago on ticalc.org, but I've never so much as glanced at a single opcode of CLAP.
I never said you did. I said I thought you had read those old articles. Anyway, let's not get back to that debate. And the CLAP is a project that is meant to be read and meant to inspire others, so in a way it's too bad you didn't read it... seems we're the only two people working on this... :)
As far as I know the protocols are completely different, so I doubt it would work for mine.
I'm talking about low level "protocol"; you seem to use the tip as a clock and the ring as a data line too, so if you also use a low signal as a one (I think that's how I did it, not sure anymore though) and a high signal as a zero and bytes are eight bits long, then you could read bytes from it just the same.
I know that... dunno why Vincent thought I was saying you were a Maxcoderz member.
Because of
MaxCoderz' Timendus
with a link to the MC boards. Would've made more sense to leave the "Maxcoderz" part out and use a link that refers to me, like www.timendus.com or http://clap.timendus.com or http://www.ticalc.org/archives/files/fi ... 29418.html
I'm doing better than that - I'm replicating your "pong" demo with Cn2.2.
Well, good luck, copycat :)
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 »

Ah, now I gotcha re: the Maxcoderz thing. My mistake. I was trying to imply that you were a member here, not necessarily staff.

Re: compatible protocols: mine uses some rather intricate timing mechanisms to ensure the receiving calculator knows when it starts listening in the middle of a packet, so chances are my protocol would start throwing collisions if receiving from or sending to yours.

Agreed, let's not get back to that debate. I didn't want to read CLAP because I wanted mine to be completely original. I didn't even look up TCP/IP documentation in case I accidentally killed off any new form of synchronization I would have thought up otherwise.

And the pong demo is to prove to me as much as anyone else that my routines have at least as much functionality as yours; I figured that would be a nice, reliable way to show it. ;)
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:Re: compatible protocols: mine uses some rather intricate timing mechanisms to ensure the receiving calculator knows when it starts listening in the middle of a packet, so chances are my protocol would start throwing collisions if receiving from or sending to yours.
I still don't think you understand what I'm saying... It just listens to whatever clocksignal it reads on the tip line, tries to capture bytes from the data line on every clock fall, and when you press some key it'll output the received bytes on the screen. It's like a packet sniffer. It doesn't "do" anything. Anyway, never mind, seems you don't need it much yet.

Oh, and if you really want to go for the honest comparison, here's the source of my bouncy demo:
http://timendus.student.utwente.nl/~cla ... Bouncy.zip

But judging from your screenshot the CLAP will win that :)
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
Post Reply