This topic will be the clearinghouse for information I generate while I work on the CALCnet 2.2 Whitepaper, discussing the motivations behind CALCnet, the hardware necessary, the software/driver model, other alternatives, the protocol and its use, and sample implementations. I'll start with diagrams that I've been working slowly over the past three days, representing the frame-level protocol, the byte-level protocol, and the bit level protocol. Each set of timing diagrams notes the states of the clock and data lines at each stage of transmission. No explicit receiving diagrams are provided, since it is assumed that any programmer sufficiently skilled to understand these diagrams will be competent enough to write receive routines that robustly handle these transmission schemes.


Every CALCnet frame is a series of 1 to 256 payload bytes sent from one calculatlor to another calculator or broadcast from one calculator to every other calculator on the network. Every CALCnet2.2 frame begins with a period of 5,000 to 15,000 6MHz cycles, or 0.8ms to 2.5ms, in which it waits to see if anything else is sending. It starts counting up from zero to 5,000 cycles; every time it sees activity, it resets that counter. If 15,000 cycles have passed at the counter hasn't reached 5,000, then it assumes that the network is busy, and waits until the next time the interrupt is triggered to try sending. At any point before 15,000 cycles have passed, when 5,000 idle cycles are seen, the protocol transitions from listening phase (1) to jamming phase (2). In phase (2), the calculator holds the clock line of the network at logical high / electrical ground, serving two purposes. First, it prevents any other calculator from beginning a transmission. Secondly, the sum of the time spent in (1) and (2) is the same as the interval between interrupts triggered 110 times a second, so even for calculators with staggered interrupt timing, every calculator on the network will notice the jamming and get ready to receive data. In the ideal case, after (2) completes after a total of at least 9.8ms of (1)+(2), every other calculator in the network is waiting for the clock or data line to start to fluctuate, indicating the beginning of the frame's real contents. First, five bytes are send, indicating the recipient calculator's ID. There are two special values: AAAAAA represents the gCn bridge on the network, while 000000 denotes a broadcast transmission that should be received by all calculators on the network. The recipient ID is placed first in a frame so that every calculator can immediately stop receiving and resume normal execution if the frame is not intended for them. Next are five bytes of transmitter ID; the only special value is AAAAAA for a transmission from a gCn bridge. Note that the special value of AAAAAA is merely a convention for ease of finding the bridge, and may be changed or supplemented in real-world CALCnet 2.2 use. Next is a two-byte payload length field. Unfortunately, because of buffer size, CALCnet2.2 should be restricted to a maximum payload length of 256 bytes, but future versions may allow larger frames. Next are the actualy payload bytes, between 1 and 256, in stage (6). Stage (6) is a simple two-byte modulus checksum of all the bytes in the payload only. The receiver should be summing the incoming bytes in parallel with their reception so that when the last byte is received from the transmitter, it can immediately send back the checksum it calculated. The transmitting calculator then ACKs the checksum with the one-byte value $AA, or may choose to either NAK with a different value or immediately stop transmitting, triggering a timeout on the receiver. Any NAK should invalidate the frame.

Note that broadcast frames do not follow the checksum/checksum/ACK-NAK convention. After the transmitter sends its checksum, the frame is complete, and receivers are solely responsible for checking the checksum and validating or invalidating the received data. A valid set of data received is indicated in the buffer with the MSB of the MSB of the data length set. If that bit is not set, there is no valid data available. Similarly, a calculator may only begin receiving if that bit is reset, so after a calculator program reads data out of the buffer, it is responsible for resetting this bit so that further data may be received.


The byte-level protocol starts with a 312-cycle stage (1) (still 6 MHz cycles, so 52us) in which the calculator pauses to allow any receiving calculator to catch up, add the previously-received byte to the stored checksum, and perform other quick management tasks. It then listens to the network for an additional 660 cycles, or 110us, to ensure that no collision occur. If any link activity, as indicated by the data or clock line transitioning to logical high / electrical low, is seen during this period, a collision is assumed to have occured, and the frame is immediately aborted. the calculator will then proceed to jam the network for 3,780 cycles, or 630us, to ensure that all calculators see the collision condition, whether receiving or transmitting, and cease activity so that the network can recover. If no collisions are seen in stage (2), the transmitting calculator then holds both the clock and data lines high in stage (3) for another 52us to signal the start of this byte. IT follows with another 43us period, stage (4), to guarantee sychronicity, then transmits eight bytes in quick succession as per the bit-level protocol. An important note: although to function correctly, the routine that CALCnet2.2 implements to transmit reverses the byte to be sent, the most significant bit (MSB) of the byte is sent first, and the LSB last. No ending guard is provided to mark the end of the byte, as the provisions of the bit-level protocol are sufficient.


The bit-level protocol is fairly straightforward compared with the byte-level protocol, requiring three stages totalling 104us. This would yield a maximum raw throughput of 9.6kbps, but this of course is infeasible given all the synchronization, error-proofing, and checksuming that must be performed. First, the data line is set to either high or low, based on the value of the bit to be transmitted. 17us later, the clock line is set high. As soon as the clock line goes high, each receiver should immediately read the data line and store the bit seen. After another 35us, the clock and data lines are both released, and a 52us pause, denoted stage (3) above, is added to allow the receivers to rotate the byte being received and loop to accept another bit.

Some serious work you had with this! Of course, I suck at any kind of electronic engineering, and barely understood what you were talking about! (Well, I got the gist of everything tho, but don't expect me to implement anything soon!)

Great technical writing here! It's very detailed and specific about every aspect of the protocol.

Yup, as it evolved from CALCnet 0.1 to 2.2 over the eight years I've worked on it, I've had a chance to do a ton of refinement. I hope I didn't obfuscate the protocol any more than necessary in my description, but hopefully my stock drivers will be stable and reliable enough that no one has a great need to implement their own CALCnet 2.2 drivers (unless of course they do so for other devices, which would be very much encouraged).

Great work, Kerm. This is a pretty straight-forward protocol, which is great. I especially like that the receiver ID comes first, that way the other devices can just ignore the data. What's the protocol for initial connections, though? Do calcs just send a packet with their ID in it?

There's no provision for "network discovery" if that's what you mean. In NetPong, I implement network discovery by having each calculator occasionally broadcast a one-byte frame, allowing the other calculators on the network to build a list of all the calculators, while is a fairly straightforward method. I decided that should be abstracted to a higher level though, if you happen to be fond of the OSI model, so I didn't build it into CALCnet. Needless to say, because the 5-byte ID is the serial number of the calculator, it never needs to be negotiated, so it's more like a MAC address than an IP address.

Ah, well, that makes sense. It sounds similar to some of the protocols I learned in my networks class for stuff like this, except in this the calcs are arguing over who gets what number.
I don't remember the algorithms that well, just that 16 was infinity.

Anyway, I'll be quite excited to get my hands on the drivers and maybe get something going once I get my other calcs and cables.

I wrote the earliest CALCnet specs based on zero formal networking experience, and indeed even CALCnet 2.2 was entirely designed (other than the broadcast aspect) a year before I took Computer Networking, but I was happy to see that it is indeed mostly consistent with accepted common-sense tenets of network design, and even sorta fits the OSI model. What do you mean about calculators arguing, though? In an ideal collisionless network there's no argument, and even in a real network the only "argument" necessary is resolving a collision with random backoff...

You and me both.

I honestly don't remember enough about it to say. It was at the tail-end of the semester, and we started talking about clusters and stuff I'm not terribly interested in, so I kind of don't remember anything. Except for 16 being infinity.

Ohh, you were just equating calculators with computers, not saying that CALCnet offered a peered arbitration mechanism, correct?

Yes.

(Brevity is the soul of wit, you know).

I'm glad we cleared that up. Since you and alberthro are busy pondering and building hardware, I think I'll probably write the section on using CALCnet 2.2 in one's own programs next.

oh god, I dont understand this O_O

That would be wonderful!

Aight, I will definitely try to get to this within the next several days.

@Qazz: Which part don't you understand? Don't just say you don't understand because you're intimidated by my wall of text. I think you'll find if you read it through once or twice that it's surprisingly straightforward, and that I'd be able to easily answer any remaining questions you would have.

lol, I am just joking about the huge wall of text that is all about calcnet

Oh, so you actually do understand the protocol completely and have no questions about it whatsoever?

err, I actually do understand it for the most part, it is just that I got kinda bored and stopped reading it half way

Meh, allow me to rant about the shortness of the American attention span. Stop watching so much TV kthxbye. Thanks for not finding it interesting.

Allow you to rant about what? I don't unde

Hahahaha. I'm still waiting for qazz's real questions on CALCnet.