Then I'll try to throw one together tomorrow! Please feel free to nag me if I happen to forget.

Kerm, did you happen to make that little program you said you would throw together for us?

Hooray for necro-nagging!

Oh yeah, forgot about this topic

Several nifty little debugging tools would definitely help making a full port of CALCnet, which would be a major improvement over my one-way implementation which supports only broadcast sends.
For maximum usability of the CALCnet implementation, we have to write the Punix implementation on top of a standalone implementation, provided in a function archive for static linking with user programs.

Gar, never did throw it together. It should display the five bytes of the target address of each frame sent, perhaps the size, and the first few bytes of the frame?

Yeah, the sender's address would be helpful too. But don't worry too much about getting this done right away. I don't know about Lionel, but for me this is a low-priority, back-burner type of project.

You sent me a program which displayed some of this information (and I used it to confirm that the frames generated by the 89 and 89T are understood by the 83+/84+), but I think that both christop and I are thinking about tools even more detailed than this, if possible

And indeed, it's a rather low-priority project for me as well.

Indeed, but we might as well bang out what exactly would be helpful for you guys so that I can thread it into the rest of my work. What more detailed tools are you imagining?

Perhaps some more readable information on why a packet was rejected by the reference implementation (bad checksum, etc.) would be useful ?
christop, any ideas ?

How about a Wireshark-like GUI with a list of packets and all fields decoded so it's easy to see exactly what the fields mean.

Actually I can't think of anything else to add to it. To be honest, I haven't thought about it much since I originally didn't have a TI-83+ to play with, but I do now so I can try to test it out. Unfortunately, I don't know where I placed my TI-86 now.... :/

Maybe I'll try my hand at a version for Punix. Since it doesn't have any infrastructure for networking yet, I'll just hack it in as a character device (eg, /dev/calcnet) whose destination can be set/altered with ioctl(). Actually I'm trying to think how it could be incorporated into networking since CALCnet doesn't have port numbers or anything else to determine which process owns each packet, so it'll be limited to a single process at a time. That's one reason I'm making my own protocol.

By the way, Kerm, I read that old MaxCoderz thread about the CLAP and your own development of CALCnet. It's an interesting read, and it makes me think that Chrisnet (the working name for my frame-level protocol) is to CALCnet as CALCnet is to the CLAP. They are similar at the low level in some ways, but they have different designs because they serve different purposes. So Chrisnet is not competing with CALCnet, just as CALCnet was not competing with the CLAP.

Fair enough. I actually do plan to have "port" numbers with CALCnet 3, which could be as simple as a one- or two-byte hash based on the name of the program currently using CALCnet if the program doesn't explicitly declare a port. The biggest roadblock for me is figuring out how I'm going to hack that into CALCnet without breaking backwards compatibility. Currently my ideas center around something that will make CALCnet2 clients ignore all CALCnet3 packets and have CALCnet3 tag its special packets by using one of the unused bits in the high byte of the size word.

Can Doors CS have more than one program running simultaneously? I didn't know that. So currently only one program can use CALCnet at a time, I presume?

I would set bit 14 of the payload length to indicate a Cn3 packet. To Cn2 clients, it will look like a payload larger than 16384 bytes, and Cn2 clients already ignore payloads larger than 256 bytes. Then send the port number immediately after the payload length.

No, Doors CS can only run one program at once, but multiple calculators running different programs can be on the same CALCnet network at once.

Unfortunately, that doesn't appear to be the case. I just looked at the reference implementation, and it will happily try to receive big frames. I wish that wasn't the case; I can only make it not the case starting in DCS 7.2, if at all.

Then I would think that the destination and source addresses would suffice to determine which program should handle the packets...? Except, I guess, if one program sends packets to a different, incompatible program, which will probably confuse both programs.


Buffer overflow? Ouch.

Yeah, but the problem is not directed frames, but the broadcast frames that most programs use to find which other calculators on the same CALCnet network are running that program.

Great read. I think I actually learned a little bit from the whitepaper. Some possible mistakes I noticed.

Page 2 Line 3 Word 7 s/modications/modifications/
Page 2 Line 16 Word 8 s/my/by/
Page 2 Line 34 Word 5 r/period after Messrs
Page 5 Line 2 /send/sent/

Nice catches, ParkerR; if and when I update the whitepaper for future versions of CALCnet, I will certainly fix those. Out of curiosity, what sort of things did you learn from the Whitepaper that you didn't already know about CALCnet?

It was more of getting a grasp of the basics of low level networking. Honestly I didn't understand it all, but I feel like I came out with a greater appreciation of Calcnet and the people behind it. Great work.

Cheers, glad to hear it. I'm confident that one day, if you care to, you'll be able to do something of the same magnitude. It certainly took me many years to be able to fully grasp all of the necessary skills to design and implement something like CALCnet, which is why it took so long for the project to finally reach maturity.

I think I found something wrong. On page 5 of the whitepaper, wich explains the frame-level protocol, I found it says this:

The marked "6" is wrong, because the picture on the top shows that stage 7 is the 2-byte checksum.
So the marked "6" should be replaced with "7".