Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.csd.uwm.edu!gem.mps.ohio-state.edu!tut.cis.ohio-state.edu!ucbvax!ivory.UUCP!king
From: king@ivory.UUCP (Steven King)
Newsgroups: comp.sys.apple
Subject: (none)
Message-ID: <8909092230.AA26919@uunet.uu.net>
Date: 9 Sep 89 19:05:48 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 64

> [...] I'm sure it wasn't
> as efficient as possible, but I doubt it was all that bad either, and it had
> trouble keeping up with 1200 baud. However, it didn't use interrupts (which
> would've helped). So, I doubt that a double-high-res (which would be necessary
> for 80 columns) terminal program could sustain a fairly long burst of text
> without losing stuff [...]

Although I haven't tried it myself, I think that if properly done an interrupt
driven system wouldn't lose characters.  You set up a large queue (probably
about 1 to 5 K).  Whenever a character comes in from the remote system it 
triggers and interrupt and is stored in the queue.  Now, when the graphics
routine *finally* gets done with what it's doing the queue is searched for 
incoming characters.  With this kind of set up you'd only lose characters if
you had MASSIVE amounts of text coming in; enough to overflow the queue.  Most
applications (say, calling the local BBS or calling into work) don't deal with
that much data at once.  There's usually a prompt that will come up ahead of
time ([MORE] after a page of text, f'rinstance) that will let the graphics
routine catch up.  If there was a problem of queue overflow, the computer
could possibly send an XOFF or some other sort of handshaking when the queue
started getting full, let the queue get printed, and send XON to start the
flow again.  Using the double-hi-res screen probably WOULD be painfully slow,
though!

> The one thing I
> haven't seen yet is a transfer protocol that lets you continue with other
> things normally. As in, while the term program & BBS are (bi-directionally?)
> exchanging files, you can go on with viewing posts.

A couple years ago in college some friends and I tried to design such a beast.
We dubbed it the Houghton Terminal Protocol, named after the town the school
was located in.  The essence of it was just as you described: several packetted
"conversations" going on at once between the host and remote.  The
conversations could be used for anything.  You could set up a download as one
conversation, read your mail as another, chat with the sysop as a third, and
say nasty things about the sysop to your buddy (who dialed in on another line)
as a fourth.  We also we going to define automatic windowing commands (as
opposed to drawing every character of the window, we'd just give the command
"open window #5 at 53,18 for 10,5 columns/rows") and a broad array of
character attributes (bold, italic, colors, etc.)  After lengthy (and
heated!) discussions, the whole project died.

> Of course, the BBS would need
> a packet interpreter as a front end to keep the BBS itself from having to deal
> with the nasty details.

You hit upon one of our problems.  This was going to be a BIG project, just
to design the specs.  Then we'd have to sit down and write the end-user
programs (I was going to write the Apple version, using the double-hi-res
screen like we talked about above) and someone would have to write a BBS that
would take advantage of all of it.  Most of us were trying to graduate at
the time, and it was just too much for us.

Of course, you COULD just buy an Amiga and the "Diga!" term program.  That
allows file transfer and chatting going on at the same time, at least with
another Diga user.  Haven't seen that protocol implemented on any BBS yet,
though.
 
> Jason Blochowiak

/-----------------------------------------------------------------------------\
| It doesn't matter how good a computer it is,   | Steve King  (312) 991-8056 |
| it can't multitask running anything and being  |   ...uunet!motcid!king     |
| turned off.                                    |   ...ddsw1!palnet!stevek   |
\-----------------------------------------------------------------------------/