Hello,
Please review and discuss this document:
(Download)

Here's what my interpretation of the TIOS link handshake is:

1) The lines read high by default
2) If the other calculator or pc is sending, it will pull their line low, which will make yours read low
3) You pull your line low to say your ready for transfer

after this, I dont know squat.can someone clear up how the bits are transferred?I dont get this at all.

I'm not sure if this thread is the appropriate medium for that, honestly.

First, let me copy-paste a bit of relevant material from the CALCnet2.2 Whitepaper:

"2.2 Electronic System
"To understand the protocol that CALCnet2.2 represents, it is necessary to understand that electronic systems available for inter-calculator communication. Every z80 graphing calculator has a two-wire link port, that is, two signal lines and a ground. These two lines may each represent a binary bit, a logical one represented by electrical ground or 0 volts and a logical zero represented by 5 volts, as per convention. Each line floats at 5v and can be pulled low by any calculator. If one calculator pulls a line low, it is pulled low for all calculators, and only when all calculators have released that line does it float high on every calculator. These two lines can be respectively termed tip and ring from their positions on a 2.5mm stereo phono plug, but in CALCnet are called the clock and data lines. In the canonical CALCnet2.2 implementation, the data line of every calculator is connected to every other calculators’ data line, all the clock lines are tied together, and all calculators share a common ground.

"Therefore, no special hardware is required in order to set up a CALCnet network. Future designs for network extenders or boosters, CALCnet2.2 over Internet (globalCALCnet) adapters, and wireless modules may be constructed, but the simplest type of CALCnet network involves simply splicing link cords together. Figure 1 shows a seven-calculator network with six of the calculators connected. The circuitry on the breadboard is partly to support LED network activity indicator and partly a microcontroller board to trace and debug the network, but none of that peripheral circuitry is necessary for CALCnet2.2 itself to function."

Now, as for the TI link protocol:

EDIT: Ignore me, apparently I'm mentally retarded. Read benryves' link.

I'll address your proposal separately if this makes sense to everyone.

How are you going to handle timing? The TI-83+ uses an RC oscillator for timing and its clock speed varies wildly with temperature and battery life. The TI-OS link protocol avoids this as each transferred bit is acknowledged. (If you're purely aiming for the TI-83+ SE or above I suppose this is not an issue). Failing that, Manchester coding may be useful for the sake of reliability.

There are two lines; which one goes low first indicates whether the bit being transferred is a 0 or a 1. See the TI Link Protocol & File Format Guide for more information.

To handle timing, I figure that I will allow plenty of wiggle room for the receiving calculator. No need to use exact timings, that would be absurd.
KermMartian, that makes sense, thank you. Would you mind reviewing my document?

Kerm failed, actually. Here's how it works in a nutshell:

* Both calcs leave the lines high.
* The sending calc pulls the tip low if sending a 0, or pulls the ring low if sending a 1.
* The receiving calc sees that a line is low and records the sent bit, then handshakes with the sending calc by pulling the other line low.
* The sending calc sees that the other line is low and releases the original line.
* The receiving calc sees that the original line is high and releases the other line.
* Rinse and repeat.

Edit: Bugfixing

Yeah, as I already noted in my post.

SirCmpwn, regarding your spec:
1) Your handshake won't work. If the receiving calc is pulling the lines low, the sending calculator can see it but can't do anything about it. Better would be to have the receiver pull both lines low for XXXms, release them, and wait for the sender to then pull them low for XXXms and release. Alternatively, the receiver could pull one line low, and the sender could pull the other low in response, then the receiver could release its line and the sender could release its too. I think that latter would be the best.

2) You generally play extremely fast and loose with high and low and pull, to the extent that I'm having trouble critiquing your Transfer section.