Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!apple!voder!pyramid!athertn!paul
From: paul@athertn.Atherton.COM (Paul Sander)
Newsgroups: comp.sys.apple
Subject: Re: BBoard protocols (none)
Summary: Someone's working on it
Message-ID: <12526@athertn.Atherton.COM>
Date: 10 Sep 89 22:54:41 GMT
References: <8909092230.AA26919@uunet.uu.net>
Organization: Atherton Technology, Sunnyvale, CA
Lines: 61

In article <8909092230.AA26919@uunet.uu.net>, king@ivory.UUCP (Steven King) writes:
> 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!

Two things:  A 2K buffer is all that is needed to store a single screenful
of text.  Most systems I've ever used that stream their output without some
sort of automatic paging understand XON-XOFF protocol, so implementing the
queue with high- and low-water marks and sending appropriate handshaking
characters shouldn't let any characters go.

Second, using hi-res graphics text doesn't have to be slow.  It all depends on
how you do it.  I've gotten such things working on a ][ Plus, though  it
still wasn't fast enough to keep up with 1200 bps while scrolling.  But it
did run fairly fast when drawing characters (in a 7x12 grid instead of the
more conventional 7x8 grid) and scrolling was quick to the eye.

[Jason Blochowiak wrote:]
> > 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.

[stuff about the "Houghton Terminal Protocol omitted]

> > 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.
> 
[stuff about Amigas and "Diga!" omitted]

There's a guy named Asko Kauppi in Finland who's taking on this challenge.  He's
designed a suitable protocol, and was finding people to develop it along with
a number of applications before starting his duty in The Service.  I'll forward
a copy of this article to him to see if he wants to begin a discussion of his
progress here.
-- 
Paul Sander        (408) 734-9822       | If a machine is powerful enough
paul@Atherton.COM                       | to have a DWIM button, why bother
{decwrl,sun,pyramid}!athertn!paul       | with the button?  -- Eric Black