[TI-H] Re: TI Networking.
[Prev][Next][Index][Thread]
[TI-H] Re: TI Networking.
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.
>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 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.
>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.
>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
>
>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.
But you are right about that the checksum isn't very needed. ofcourse it
would be correcting if it was there, it isn't just for show :)
hmm.. the question is if the net is reliable enough to send without any
errorcorrection.
>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.
>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.
///Olle
Follow-Ups:
References: