CALCnet2.2: Success!
Moderator: MaxCoderz Staff
- KermMartian
- Calc Wizard
- Posts: 549
- Joined: Tue 05 Jul, 2005 11:28 pm
- Contact:
CALCnet2.2: Success!
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:
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:
- KermMartian
- Calc Wizard
- Posts: 549
- Joined: Tue 05 Jul, 2005 11:28 pm
- Contact:
- benryves
- Maxcoderz Staff
- Posts: 3087
- Joined: Thu 16 Dec, 2004 10:06 pm
- Location: Croydon, England
- Contact:
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.
- KermMartian
- Calc Wizard
- Posts: 549
- Joined: Tue 05 Jul, 2005 11:28 pm
- Contact:
- KermMartian
- Calc Wizard
- Posts: 549
- Joined: Tue 05 Jul, 2005 11:28 pm
- Contact:
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.
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.
- thegamefreak0134
- Extreme Poster
- Posts: 455
- Joined: Mon 23 Jan, 2006 10:09 pm
- Location: In front of a Computer, coding
- Contact:
- KermMartian
- Calc Wizard
- Posts: 549
- Joined: Tue 05 Jul, 2005 11:28 pm
- Contact:
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.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?
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
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.
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 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.kerm_martian 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.
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
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:
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: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
As far as I know the protocols are completely different, so I doubt it would work for mine.Timendus wrote: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.kerm_martian wrote:
I know that... dunno why Vincent thought I was saying you were a Maxcoderz member.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'm doing better than that - I'm replicating your "pong" demo with Cn2.2.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 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...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'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.As far as I know the protocols are completely different, so I doubt it would work for mine.
Because ofI know that... dunno why Vincent thought I was saying you were a Maxcoderz member.
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.htmlMaxCoderz' Timendus
Well, good luck, copycatI'm doing better than that - I'm replicating your "pong" demo with Cn2.2.
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:
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.
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.
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.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.
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
http://api.timendus.com/ - Make your life easier, leave the coding to the API
http://vera.timendus.com/ - The calc lover's OS