[TI-H] Re: TI Networking.

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

[TI-H] Re: TI Networking.


At 21:01 2001-05-02, you wrote:
>Even at byte level, it only works with 2 calculators.  Each line
>transition requires a response from the other end.

no? what kind of response?
you send data by pulsing the two lines, the order of the pulses define if 
it is 0 or 1.
no response needed that I know of. all responses on byte level, and in the 
overlaying routines. (send 4 byte request, get 4 byte responce, things like 
that)
please explain in more detail, I could ofcourse have missed something.

>In a multicalc environment, you can't respond to anything until you get
>to the level where each calc is addressable.  No bit acknowledgement, no
>single byte retransmissions, only packet level ack/retransmit.  It's
>quite annoying!

ofcourse.

>This means larger packets are much less efficient when link errors occur,
>as the whole packet needs to be resent.

that is true. maybe the variable length packets are overkill.

>I am ambsolutely certain.  I could even show you the rom routines if you
>like.
>There is a port to write to, but it's essentially two bits wide, one for
>each data line.

ok. I take your word for it, I am quite focused on the 68k calcs since I 
don't have any z80 calcs.


>That seems strange, the 68k calcs have more processor power to spare...
>Oh well, no use trying to figure out TI's motives ;)

You'll have to take my word on this :)

> >
> > ofcourse it would be on interrupt.
>
>Ah...  using the interrupt SEVERELY limits your bandwidth.  Maximum of
>300 bits/sec, and then you expect to have to retransmit about 5% (rough
>guess), distributed evenly so large packets ALWAYS have link errors.
>Dropping to 150 bps, retransmission is no longer expected (just random
>errors), but that's very slow.

ah, another problem with the z80 calcs. on the 89 I can generate interupt 
at link activity, or at a given intervall up to 1/4 or 1/8 don't remember 
really, of the clock. wich is 10-12MHz.
sorry, was focused on the 68k calcs here too.
would probably be more tricky with this scheme on the z80 calcs. I remember 
now of very limited interrupt architecture. Probably isn't a good idea with 
interruptdriven on thoose.


>True, I was suggesting a fixed length to keep packet size small.  A byte
>indicating packet size is a byte not carrying data.

yes.. maybe it is overkill.

>That makes sense if everything addressable in the packet can be read &
>written.
>I would think that in a master/slave architecture (I program for one at
>work...) there would be a much larger amount of write than read commands.

That depends entirly of what you have on the bus. if it is a temp sensor, 
you would almost only read.
a multiplayer game would have more writes though, probably. read status of 
all calcs, and then write to the others. hmm.. lot of work for the master...
would be nice with no master, but collision detection is tricky.

>1 byte can be sent in 5 1/3 line transitions. (if you're sneaky)
>5.3333*262 = 1398 line transitions
>line transitions at 100 Hz = 1398/100 = ~14 seconds
>(that's 150 bps, at 300 you'd never make it)
>
>Dedicating all your time to link transfers (maybe as a master/server),
>you can probably send a maximum of about 30 large (262 byte) packets per
>second on a z80 calc (running, as they do, at 6 MHz)

sounds like the z80 calc owners have even more problems doing any good 
networking then I with a 68k calc...
If I do anything, I will probably focus on 68k...

///Olle
References: