While doing other miscellaneous stuff, I have begun giving some thought to my Star Trek 2 player game, particularly the issue of link timing. Now I'm not asking for coding help. It's more conceptual I'm looking for. I plan on using a master variable, like the first term of a SafeRam area to hold the data for whether or not stuff needs to be transmitted. I know that, in CALCnet 2.2, Kerm Martian utilizes checking cycles, where a calc that acts as a receiver pings for data for a certain time, thus giving the sender adequate time to enter the transmission phase before the receiver times out. My idea is to do this.

Calc 1 and 2

setup
loop start
transmit
receive master & enemy
If master
receive other
loop end

Where the receiving calc pings for the enemy's location, which updates each time the loop cycles, and the master variable, which should be 1 if there is data (an attack or other data) to be received and 0 if not. If the m.v. is 0, the receiver phase ends and the loop cycles to the top. If it is one, it waits for the data it needs, then, upon completion, cycles back to the top.

My only issue with this setup is that the two calcs will enter transmission mode at the same time, then receiver mode at the same time, meaning nothing will actually be received. Any ideas? This is an Axe program, and thus, I don't have the range of "play" with the link that asm does.

Actually, that's a slight misunderstanding of the CALCnet2.2 protocol; allow me to clarify. The transmitting calculator is the one to initiate any transaction, unlike the TI-BASIC GetCalc() function. The transmitting calculator will keep retrying the transmission if the receiving calculator is busy until the frame is successfully received and confirmed by the receiver. The only exception is broadcast frames sent to the entire network; no guarantee of reception is given, since no confirmation is requested from the receivers. What happens for non-broadcast (that is, directed or one-to-one) frames is that the transmitter holds the clock line low long enough for the receivers' ISRs to each get to a point where they're actively watching for the frame to begin.

Ah, I see. For the purposes I would need, we would be taking more of a one-to-one transmission, correct?

That's correct. In one-to-one transmission (since I presume you're just dealing with a two-calculator link) you know that there's exactly one calculator connected, so you don't have to mess around with broadcast things like telling the other calculator your address.

The main problem with your code (as with all kinds of unmediated two-endpoint communications) is how to effectively decide who is the master. If you pick a random number, for example, both calculators might decide they're the master, or neither might, both of which are undesired. You can do something like have the first calculator to transmit claim it's the master, and wait for the second one to acknowledge that the first calc is indeed the master before the first one sets its master status to itself. That way, if both try to claim the master at the same time, the first one to acknowledge that the other one is the master becomes the slave. Makes sense? Should I draw a diagram?

No, when I use the word master, I don't mean assign one calc as a master. What I mean is this:

Let us say I have the following 3 bytes of data, starting at AppBackupScreen ( {L1} in Axe)

0 0 0

0 1 2


0 is the master variable.

Now, let us say that within this loop, I deal no damage to the enemy. When I enter transmission mode, the calc sees the 0 at {L1+1}. When the receiver gets that 0, both calcs skip what remains of the transmission phase for calc 1.

If there is damage, those bytes would look like this

1 [damage points] [section hit]

When calc2 receives the first byte, the value of 1 tells it it needs to get more data, so it proceeds to take the next two bytes, the damage, and the part of the ship hit.

I referred to the first byte as the "master variable", but it is independent of assigning master or slave. It just tells the receiver whether it needs to get any data.

when the

That makes sense so far. I think that the tail end of your post might have gotten lost, though...? Have you tried implementing this yet?

I have another idea for inducing transmission. I will set one calc as the master and the other as the slave. I still have to figure out how to assign those statuses in a fool-proof manner...

So I will set up an interrupt routine for the linking, and a variable N. According to SirCrpwn, Axe's PORT command works like this:

00000000 = 0
00000001 = 1
00000010 = 2
00000011 = 3

doing [value]->PORT stores one of those 4 values to the link port.

So, lets say I have a piece of Axe code that looks like this:

1->A
A->PORT


That sets the port's value to 00000001.

Now, both calcs do this:

PORT->A

The result is 1. On both.


So, here's my idea. I have one calc set as the master and one as the slave. When, in the game, the master inflicts damage on the slave, the master stores 0 to A. When the slave inflicts damage on the master, the slave stores 3 to A. That is the only two possible occurrences of needing to send data. Now for the magic.

If the master's A is set at 0 and the slaves is set at 3, one of the calcs will send their value to the PORT first. The other calc will see this and skip the transmission on both ends, as if the two weapons collided in the air and exploded, without hitting either.

In the other cases, if the PORT is set to 0, the master calc calls a SEND routine, and the slave calls a RECEIVE routine. There will be no need for the slave to then send data back, so why waste memory and slow down the game in this routine with something that will never happen.

If the PORT is set to 3, the slave calls a SEND routine and the master calls a RECEIVE routine. There will be no need for the master to send anything back. so, again, why include it in this routine.


My previous thoughts involved the slave and the master EACH performing a send AND a get each time around the loop, but now I've realized that in any one cycle, a calc will either send OR receive, never both. So why should I code for both. Give it two separate routines, one to receive, one to send. Based on the PORT value, each calc will call the OPPOSITE routine, so I will never have conflicting transmissions. Axe provides commands for SEND and GET. I'm really optimistic about this line of thought.

You have a slight misunderstanding about how the link port works. Those numbers that you gave, first of all, are just binary to decimal translations; they're nothing specific to the link port. Second, as you'll note from reading the CALCnet2.2 whitepaper or other link port documentation, if any calculator holds a link line low, then [both|all] calculators see it held low. In this case, 0 means both lines are high, 1 and 2 mean one line is high and one is low, and 3 means both are held low. Now, If one releases both lines (0) and the other holds them both low (3), both calculators will see both low (3) even if the first calc repeatedly sets (0). The line state won't change until the second calculator releases one or both lines. Makes sense?

i understand. However, the way it was explained to me is that Axe's PORT command treats PORT as kind of like a "shared" variable, that both calcs can reference and store to, and that the SEND/GET commands are just simplifies versions of what PORT would need to be cycled many times to do. I may be wrong. I'll give it a go and see what happens.

It is a shared variable, but with several limitations, as I mentioned. I believe that Axe directly sets the port value; I don't think it has any abstraction above it that makes my point invalid. I'd appreciate if you'd write a pair of programs, one that sets (3) and waits, and another that sets (0) in a loop and repeatedly tests the link state, and see if as I expect the second will always read 3.

That is actually my goal. To see if it works in two programs. But, I'd need someone with 2 calcs to test, as I dont have.

Ah, that makes sense. Why don't you use PindurTI to test, then? It allows up to four simultaneous linked calculators.