Re: A86: Theory question
[Prev][Next][Index][Thread]
Re: A86: Theory question
This is exactly the problem.
As to the hardware you've got the right idea. Just splice some links
together, so that anything sent on one end is recieved on all the rest....
just splice red to red, green to green, etc.
As to multiplayer games... thats software.
There are several ways to do a multiplayer game. The easiest is in games
where the players take turns, like a board game. All you really have to do
for these games is make it so that when a calc inputs from the user during
their turn, it sends the keycode over the link. All the other calcs wait for
that, and then pretend it came from their own keyboard. Each calc takes
turns sending, while the others wait, which is why it is most suitable for
turn-type games.
The same theory can be applied to live games, but you have to start being
careful. If you make all the calcs wait while the one is getting input, or
even if it is sending a byte saying that there is no input, it could
possible slow the game unacceptably. This is especialy true for games with
more than two calculators.
With this method of exchaninging keyboards, so to speak, as well as other
methods of multicalc networking, one of the issues you will quicly come
accross is the initial connection. The easiest way of course is to just ask
the user, "What calc am I?" The answer you would give it would be a number
from 1 and the last calc... say 4. Then if you are number 1, it is your turn
to send first while the others wait. After they recieve the data, they
proccess it, and increment the number telling whose turn it is. After one
goes 2, then 3, then 4, then 1 again.
If two calculators think they are number three, however, things start
getting screwed up. They must all have a unique number.
There are several automatic hand-shaking methods however.
One involves random numbers... time outs and other strange things.
However, the best method, I think anyway, is a routine that is lower level
then sending a byte.
First off, there are two lines in the link, we will call them red and green,
since I don't know what they are really called.
The protocol goes like this (not my protocol, but the hardware one)
R G
0 0 wait
0 1 0
1 0 1
1 1 error
or something like that, I should probably look it up cause I just know
someone is going to yell at me. I don't remember exaclty how it works
anyway.
The point is...
You plug the first calculator in. It checks to see if the line is 1. If it
isn't, it assigns itself to be calc 1, and then sets the line to 1 and
waits.
calc 2 gets plugged in.
calc 2 checks to see if the line is 1. It is. Calc 2 changes it to soemthing
else... error I think. this tips off calc 1 that a new calc has been plugged
in. The line is then cleared for data transfer. Only one byte is sent, and
that is the number assigned to the new calc, given by calc 1.
after that calc 1 once again sets the line to 1, and waits. calc 2 just sits
there. several more calcs could be added.
then, when all calcs are done, calc one is told by the user (it has been
monitoring a key or something) that all calcs are in. calc 1 then sets the
line to low, and sends a $ff, indicating that all calculators are connected
and that the rest of the calcs can now start listening again.
so there ya go, a nice little handshake that will give all the calcs a
number, and only one person who is playing has to actualy do anything, and
even then it is only a confirmation that all calcs are connected.
After that how your game goes about doing the data transfer could be done
lots of ways, as previously mentioned.
Another way would be to send game data... such as a board layout, or a
current move, instead of the current keyboard action, during a calcs turn.
ok, I'm leaving now. Most of you probably won't read all this anyway.
I will post again in several more months. I am still mad at some idot who
flamed me even though I was right. Anyway. Good luck guys.
--awwaiid ( Retupmoc / Brock )
----Original Message Follows----
From: Cassady Roop <croop@oregontrail.net>
Reply-To: assembly-86@lists.ticalc.org
To: assembly-86@lists.ticalc.org
Subject: Re: A86: Theory question
Date: Tue, 11 May 1999 22:18:27 -0700
The link protocol in the 86 was designed for the expected calc-to-calc
interface, not calc-to-multicalc interface. The two calculators send
control commands back and forth between them, such as stop and start
bytes, machine ID codes, filenames, etc. Each calc only expects to
recieve one set of replies, not two or three sets that you would have on
a hub. I think it will only work on custom-made link routines.
> speaking of this.....my friend and i took a link cable and cut it in
half.
> then we split another link cable and hooked the 2 together. but when we
> tried to send a program (hoping to send on 1 and receive on the other 3)
it
> didn't work. think it was too slow(?) or something like that?
_______________________________________________________________
Get Free Email and Do More On The Web. Visit http://www.msn.com
Follow-Ups: