Author Topic: Link Timing (Read 16487 times)

ACagliano · « **on:** November 09, 2010, 01:51:34 pm »

This is actually an Axe question, so this is the most relevant support board for it.

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?

AngelFish · « **Reply #1 on:** November 09, 2010, 02:26:10 pm »

Test for the state of the other calc. Have a separate variable that is always returned. If the other calc is not in receiving mode, then it will not return the variable and your calc knows that the transmission has failed. You can then take appropriate action, such as waiting or repeating the message.

ACagliano · « **Reply #2 on:** November 09, 2010, 02:30:31 pm »

I'll give that a try.

I believe that I asked this before, but I forgot what the response was. Is this best to be done on a timed interrupt, or once around a main loop? Do interrupt timers fire at the same frequency on the TI-84+ and TI-83+ models?

AngelFish · « **Reply #3 on:** November 09, 2010, 02:51:16 pm »

I believe the crystal timer on the 84+ models is a bit faster. I could be wrong though.

This was the closest thing a quick Google search turned up:
http://wikiti.brandonw.net/index.php?title=83Plus:Ports:30

gangsterveggies · « **Reply #4 on:** November 09, 2010, 03:09:27 pm »

It should be since you pay more...

DJ Omnimaga · « **Reply #5 on:** November 09, 2010, 03:13:04 pm »

Well... with Texas Instruments we never know. We pay a bit more for the TI-Nspire, yet it barely has any programming capabilities, it's buggy and its TI-84+ emulator isn't even 100% compatible.

gangsterveggies · « **Reply #6 on:** November 09, 2010, 03:25:50 pm »

That's right. However, TI-NSPIRE has more resolution than the TI-84+... and it's a their new "bet". In a few years it can become the new TI-84. I kind of like it but I agree with you and prefer 84+.

DJ Omnimaga · « **Reply #7 on:** November 09, 2010, 03:58:11 pm »

Well, the problem with the Nspire is that TI is trying everything to make sure ASM and C isn't allowed on it, most likely to prevent games. We have a nice machine with high resolution, but we can barely do what we want on it.

gangsterveggies · « **Reply #8 on:** November 09, 2010, 04:00:29 pm »

Yeah that's why I use the 84... stupid TI guys... they could be much more successful. Kids would choose the TI because of the games but noooo... still... some programming is cool in the NSPIRE. What's the programming language again? I know some things but nothing too good.

jnesselr · « **Reply #9 on:** November 09, 2010, 07:24:38 pm »

Usually, you would have one calc do one line low (or maybe it is high. can't remember) and the other calc checks that before anything. In this case, they both wouldn't set it low. One would set line 1 low, and the other would set line 2 low which would say a transfer is ready, and that one calc has become the transferrer and one has become the receiver. You can do it the opposite way simply by saying that line 1 is always the transferrer and line 2 is always the receiver.

AngelFish · « **Reply #10 on:** November 09, 2010, 07:48:55 pm »

Quote from: DJ Omnimaga on November 09, 2010, 03:58:11 pm

Well, the problem with the Nspire is that TI is trying everything to make sure ASM and C isn't allowed on it, most likely to prevent games. We have a nice machine with high resolution, but we can barely do what we want on it.

Honestly, I can't see why TI would go to such lengths to block 3rd party programmers. It's not like they suffer from the sales of us bricking our calcs.

It must be the teachers...

jnesselr · « **Reply #11 on:** November 09, 2010, 08:23:37 pm »

the reason is simple. Test standards. If i can make my TI calc any os I want, then they are no long accredited for ACT/SAT use, and there is nothing TI legally can do about it, AFIK. The only thing they can do is hope the security is enough.
Also, let's not get too off topic...

ACagliano · « **Reply #12 on:** November 10, 2010, 11:54:20 am »

Quote from: graphmastur on November 09, 2010, 07:24:38 pm

Usually, you would have one calc do one line low (or maybe it is high. can't remember) and the other calc checks that before anything. In this case, they both wouldn't set it low. One would set line 1 low, and the other would set line 2 low which would say a transfer is ready, and that one calc has become the transferrer and one has become the receiver. You can do it the opposite way simply by saying that line 1 is always the transferrer and line 2 is always the receiver.

Can I pull the line low, then set it high with the command "EXP->port", or is that something else?

If I understand correctly, pulling both low sets the calc being pulled low to receive. And setting them high sets it to send. If I'm correct on that, then this should be fairly trivial. Can someone give me a better explanation of what "EXP->port" actually does.

SirCmpwn · « **Reply #13 on:** November 10, 2010, 07:40:26 pm »

This is how it works. The link port's value is mirrored on both calculators. For now, don't think about low and high. There are two bits (two binary digits) that are mirrored. Now, you can send a number to port, and it will take the lower two bits from that number and make the I/O port reflect that value. Keep in mind that when you set the I/O port, both sides are set. port→ will return the bits on the link port. This is a quick explanation of how to transfer bits:
Sending:
Keep in mind that only the last two bits matter.
00000000b = 0, so to send 00b, use 0→port
00000001b = 1, so to send 01b, use 1→port
00000010b = 2, so to send 10b, use 2→port
00000011b = 3, so to send 11b, use 3→port
This will set the value on the link port, discarding any bits other than the last two.

Receiving:
Keep in mind that only the last two bits matter.
Assuming that you only ever write 0-3 to the link port, using port→variable will make variable contain the last value written. So if calcA does 1→port, then calcB does port→A, A will contain 1 on calcB. However, keep in mind that if the following happens:
CalcA uses 1→port
CalcB uses 2→port
CalcB uses port→A
That on CalcB, A is equal to 2. The link port is shared between calculators, the last value written by either calculator is the one that is read by either calculator.

ACagliano · « **Reply #14 on:** November 10, 2010, 07:47:00 pm »

Understood, now how exactly does that value on the PORT influence the actual sending of bytes, using Send( and Get?

Author Topic: Link Timing (Read 16487 times)

ACagliano

Link Timing

AngelFish

Re: Link Timing

ACagliano

Re: Link Timing

AngelFish

Re: Link Timing

gangsterveggies

Re: Link Timing

DJ Omnimaga

Re: Link Timing

gangsterveggies

Re: Link Timing

DJ Omnimaga

Re: Link Timing

gangsterveggies

Re: Link Timing

jnesselr

Re: Link Timing

AngelFish

Re: Link Timing

jnesselr

Re: Link Timing

ACagliano

Re: Link Timing

SirCmpwn

Re: Link Timing

ACagliano

Re: Link Timing