Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.csd.uwm.edu!bbn!bbn.com!slackey
From: slackey@bbn.com (Stan Lackey)
Newsgroups: comp.sys.atari.8bit
Subject: Re: dead-list..???
Message-ID: <45059@bbn.COM>
Date: 31 Aug 89 14:30:37 GMT
References: <BL152896@TECMTYVM> <8908311018.AA04330@ucbvax.Berkeley.EDU>
Sender: news@bbn.COM
Reply-To: slackey@BBN.COM (Stan Lackey)
Organization: Bolt Beranek and Newman Inc., Cambridge MA
Lines: 27

In article <8908311018.AA04330@ucbvax.Berkeley.EDU> UCPL030@UNLVM.BITNET ("Douglas J. Evans") writes:
>Well, not dead, but mighty quiet.
>One project started years ago with some friends, but set aside when they
>went on to bigger machines, was an attempt to network several Ataris,
>not as in a LAN, but actually running as one game system, with slave
>Ataris acting as displays to one main system as the game driver.

I think a good way to do this, albeit slow, is to use VBI and/or DLI
as a 'timebase', and build a simulated UART using the controller ports.
Received data can even go into a queue, so that data isn't lost while
the CPU goes into a long latency operation.

Does anyone know if the VBI is synchronized to the power line?  If so,
one-bit-per-VBI is possible, even if the two ataris happen to be
plugged into opposite phases.  It seems with some care, one BYTE per
VBI might be possible (if the synchronization is there).

I have used the internal timer interrupt for stuff like this, in
particular my mouse/trakball driver.  There were interactions, though,
when I turned on DLI to twiddle the screen; at least a few DLI
interrupts were lost, and some VBI's were lost, resulting in a lot of
screen flicker because the VBI/DLI's sometimes weren't doing their
respective thing.  What I ended up doing was to put a DLI on every
[text] line, and in the DLI routine inc a line count and check for (do
I do something this time?), and not using the timers at all.

-Stan