Re: A86: Link Tutorial

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

Re: A86: Link Tutorial


the rom routines will throw an error for timeouts, disconnects, protocol
errors (if you use the protocol routines).  you probly want to install an
error handler if you use the system routines.  bit of a drawback i
suppose.  they throw weird error messages, i don't remember if they
indicate what kind of error happened or not, but if you don't handle the
errors yourself the os isn't really prepared to.  it won't freeze up or
anything, just give you some misleading error messages.

as for all this polling business, i still think it'd be better to have a
link routine running in an interrupt that only takes a small timeslice,
kinda like multitasking.  even if the other calc disconnected or crashed,
you'd never see a stall in the program.

-josh

On Mon, 22 Nov 1999 23:48:40 +0100 Jimmy =?iso-8859-1?Q?M=E5rdell?=
<yarin@acc.umu.se> writes:
>
>At 19:36 1999-11-21 -0700, you wrote:
>>I think that an interrupt controlled buffer system like the 89/92 
>wouldwork
>>much better, though it still might have problems.
>
>The problem is that the 89/92 has an interrupt connected to the 
>linkport,
>so when the other calc is trying to send, the receiving calc jumps 
>directly
>to the code which receives the data. Veery neat...
>
>The functions in the ROM are nice, but that part - the actual sending
>and receving of a single byte - is easy. The problems are
>
>1) The handshake (ok, not THAT big a problem)
>2) Polling (how often?)
>3) Both calcs want to send at the same time
>4) DISCONNECTION <-- major problem!!
>
>You have to make sure the calcs don't crash/freeze whenever the
>other calculator disconnects. This can happen when 1) you pull
>out the linkcable while playing (the status of R and W after this
>is non-deterministic)  2) the calc on the other side crashes/quits/
>forgets to poll etc. This must be checked ALL THE TIME (ie in all
>loops in the link routine), which is very annoying...
>
>In the polling, the hard part is setting the timeout level. How
>long should I wait for the other calc to reply before it's a timeout?
>A too long wait will cause both calcs to freeze when trying to send
>at the same time (happens in ZTetris), or a long freeze when
>disconnecting. A short wait might cause one calc to think the other
>disconnected, when it in fact didn't.
>
>The polling problem is probably best solved with a 
>master-slave(server-client)
>link routine. In fact, I believe most of these problems could be 
>solved
>with a clever implementation of such a system, which I've intended
>to write for quite some time now.
>
>Btw, when using the built in link functions, what happens if the
>other calc disconnects? External error message? Return with CF?
>
>--
>Jimmy Mårdell                   "God made machine language;
>mailto:yarin@acc.umu.se          all the rest is the work of man."
>http://www.acc.umu.se/~yarin/    
>
>

___________________________________________________________________
Get the Internet just the way you want it.
Free software, free e-mail, and free Internet access for a month!
Try Juno Web: http://dl.www.juno.com/dynoget/tagj.