[TI-H] Re: TI Networking.


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

[TI-H] Re: TI Networking.





On Wed, 02 May 2001 10:32:40 +0200 Olle Hedman <oh@hem.passagen.se>
writes:
> 
> At 07:43 2001-05-02, you wrote:
> 
> >The standard protocol only works with 2 calculators on the line.
> 
> If you had read more carfully, you would have seen that I mean just 
> cable 
> protocol, not tho whole protocol.
> I can't see why cable protocol (just the bytesender) wouldn't work 
> with 
> more then one calc.

Even at byte level, it only works with 2 calculators.  Each line
transition requires a response from the other end. 

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!

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

> >The built in system, at least on the z80 calcs, is completely done 
> within
> >the processor.  The only work it saves is the programmers'.
> 
> you sure? I thought I remembered a port to write bytes too, and 
> another to 
> write directly to link, but I might  remember long. I have only had 

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.

> the 89 
> for 2½ year now, so I have forgotten most about the details of the 
> z80 calcs.
> In the 89 the bytesender is in hardware.

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

> >Other methods could potentially perform network operations in an
> >interrupt routine, freeing the game from having to wait for the 
> operation
> >to complete.
> 
> 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.

Not using interrupts, otoh, takes a lot of processor time since you can't
use an asyncronous protocol like TI's.

> >Why?  You already know where the packet starts, the first byte sent 
> is
> >the beginning of the packet.
> 
> no you don't. not if you have many packets to send, and want to send 
> different packets to different calcs.
> there is also the chance to get out of alignment, and you then want 
> some 
> way to come back on track.
> this adds extra reliability. maybe a bit overkill, but I think its a 
> good idea.
> but anyway, details always change in implementation

Ah, I see.  I was expecting to be able to tell the end of the packet by
counting bytes (every calc needs to read every byte either way), but I'm
not sure how that would work if there was a transmission error somewhere.

If done properly, I think you should be able to put a one or two bit gap
in the data stream between packets fairly easily.

> >
> >What kind of game are we talking about here?
> >You'd have to have a VERY complicated game to require packets of 
> that
> >size.
> >
> >Small fixed-size packets would probably be better, say 8 bytes 
> including
> >address.
> 
> smallest size in my packet is 5 bytes with one byte payload. I think 
> variable length could be nice vor versatility, and doesn't add much 
> complexity or overhead.

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

> >Having a read/write bit is probably redundant, it already needs to 
> know
> >WHAT is being read/written, you can encode the read/write bit with 
> that.
> 
> that is true..  can also be seen as an extension of the adress 
> range, and 
> that every calc has a range of adresses.

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.

> >Also, checksums aren't very useful, unless they're correcting.  
> There
> >probably isn't time in a game to resend the packet, especially if 
> it's
> >this large.
> 
> It doesn't have to be large. Nice though with support for a bit 
> larger 
> packets. I still don't think 262 bytes is very large.

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)

-josh
________________________________________________________________
GET INTERNET ACCESS FROM JUNO!
Juno offers FREE or PREMIUM Internet access for less!
Join Juno today!  For your FREE software, visit:
http://dl.www.juno.com/get/tagj.



Follow-Ups: