Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.csd.uwm.edu!dogie.macc.wisc.edu!uwvax!puff!rt20.cs.wisc.edu!blochowi
From: blochowi@rt20.cs.wisc.edu (Jason Blochowiak)
Newsgroups: comp.sys.apple
Subject: Re: Telcom Program of the Gods
Message-ID: <2937@puff.cs.wisc.edu>
Date: 7 Sep 89 20:37:20 GMT
References: <8909070021.AA03717@trout.nosc.mil>
Sender: news@puff.cs.wisc.edu
Reply-To: blochowi@rt20.cs.wisc.edu (Jason Blochowiak)
Organization: U of Wisconsin CS Dept
Lines: 54

In article <8909070021.AA03717@trout.nosc.mil> lhaider@pro-sol.cts.com (Lawrence Haider) writes:
>Network Comment: to #10769 by mailrus!ulowell!m2c!wpi!dseah@ames.arc.nasa.gov
>>  What I'm looking for is suggestions.  What you want, what you don't
>>want, what kind of user interface it should have [...]
>One other thing I'd like to see added, although you couldn't do it in text
>mode on the Apple.  ANSI color graphics are somewhat of a standard on MS-DOS
>machines, and a lot of their BBSs support it.  It is more functional than
>ProTerm Special and allows more freedom than what we Apple user's currently
>have.  If done in graphics mode, it would be slower; but it sure would be nice
>to have!

	I wrote a terminal program awhile back called "WimpyTerm" - it allowed
me (as a ][+ owner) to type/view 40 column lowercase (yeah, I know, there are
hardware mods, but that's too easy!) using the HGR screen. 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, which can be particularly dangerous considering that
color commands could be lost (look, ma, it's bright green text, from now 'till
I logout!). On the other hand, that was on a 1Mhz ][+ with a 6502 - perhaps it
would work out well if it were written as a //gs program that just used the
DHR screen.

	As far as suggestions for a terminal program go: 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. Basically, the whole thing
would just be packeted, with the file data packets length being variable (so
that when a key was pressed, the term program could terminate the current file
data packet, send the key, and then send the next file data packet). Of course,
the whole protocol should be windowed. Granted, this'd be pretty much of a
bitch to write, but if it was, it'd be damn nice! 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. Think about it, though - go to the file transfer
section first, pick out the files that you want, start sending them, go back
to the boards, and start reading. Considering that a fair amount of time is
spent reading the posts (I'm a fairly quick reader, and at 2400 bps, I can't
keep up with the modem), the posts could be sent in a burst (simple buffering
technique - buffer until 1) the buffer is full, or 2) the BBS makes an input
request). Well, looks like I went off on a sidetrack there...
	For a nice terminal program you need: Scripts, macros, file transfers
with a continously updated estimated time of transfer (well, not continously,
but not "well, we'll guess, and use the guess throughout", but "well, we'll
guess, but then we'll modify the original guess by what actually happens"),
things like automatic on-line charge billing (x for first minute, y for each
additional) calculation, with a possible alarm for going past a certain amount.
It seems that there are only a few terminal emulation types that you HAVE to
support (perhaps Datamedia 1500 or ProTERM special for backwards compatibility,
VT-52, VT-100 or ANSI, there are some others, but...). Inclusion in the scripts
of something to allow for scheduled calling. I think that's really all you
need, and the rest is implementing it smoothly.

	Jason