[OT] Re: A86: Theory question

[Prev][Next][Index][Thread]

[OT] Re: A86: Theory question


awwaiid _ wrote:
> 
> This is exactly the problem.
> ...
> 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.

  This seems a bit like token bus.

> If two calculators think they are number three, however, things start
> getting screwed up. They must all have a unique number.
> ...
> 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.

  I think you can't do that. It can go plugging one calc
  after another while already running a protocol. When you
  plug a link, it will probably generate a spurious random
  bit which will confuse the protocol. Any protocol must
  start with all the calcs already plugged.

  Yes, maybe it is possible to connect a bunch of calcs
  directly through it's links (red on red, ...). It's a
  matter of (software) protocol.

  First one must understand the hardware on the link port.
  If I'm right, and seeing the way the TI protocol and
  the parallel port work, I am, the link port has a pair
  of open-colector outputs with pull-up resistors. What
  does this mean?
  First of all, you must understand that a one '1' on the
  cable means that the other end of the cable (the one
  inside the calc) is connected to the positive power
  supply, this is, at the battery +, so it is between
  say, 3 and 6 volt. A zero '0' means the end is connect
  to the battery -, also named 0 volt or ground.
  Now, imagine 2 switchs A and B, and 2 resistors Ra and
  Rb, as the diagram below:

      +------------+---------------- Battery +
      |            |
      O            O
   Ra O         Rb O
      O            O
      |            |
      +-- La       +-- Lb
      |            |
    #####        #####
    # A #        # B #
    #####        #####
      |            |
      +------------+---------------- Battery -

  this is, I think, a simplifyed diagram of the calc's
  link port. La and Lb are points connect to the link
  jack (the wires red and green). The tird wire is taken
  from the Battery -. Is ground.

  I'm not going to explain, but from electronics science,
  if switch A is open, at La we have Battery + level,
  which is a '1'. If switch A gets closed, we have a '0'
  at La. Same for switch B (but for Lb). When switch A is
  closed, we say Ra is pulling-up La. When it is closed 
  we say the switch is pulling La low. The bits on port
  xx (I don't remember which is the link's port number)
  control the switches, opening them or closing them.
  At the same time, the calc can read the value at La
  and Lb (not represented in the diagram). This is what
  you get when you read the link port.
  When you have 2 calcs connected, you have both La's
  connected (one from each calc) and also both Lb's.
  What happens if one calc tries to get it's own La
  one way (say '1') and the other tries to get it's own
  La the other way ('0')? By electronics rules, the
  one who tries to take it '0' will win. Remember that
  each calc can read the state of their lines, so they
  (more preciselly. us, programers) kwnos what's going
  on.
  It's based on this functioning that it's probably
  possible to get a protocol to connect 3 or more
  cals toguether, by just plugging all the calcs
  'on the same cable' and having the right software.

  Let's see if I can get a draft protocol from my
  head right now... mmm ... mmmm .... ....

  well, I think a protocol like ethernet could work,
  but it would need to get all of the z80's attention,
  or else calcs could miss packets:

    To send:
       - wait for line A to be '1'
       - start to send packet. Another calc could have
         seen line A at '1' and can be sending also, so
         after sending a bit through line B, the calc would
         have to read it to be certain that the sent bit
         is it's own bit and not other's calc bit.

   To receive:
       - a calc must always be listening. It must
         listen all the packets, because some may
         be for her self.
         This is the problem, this would require
         all of the calc's attention.

  Maybe some round-robin way would work. I'm going to
  let it for someone else to think about...

  NSJ
References: