HDTenEightyP/NetNews huggingface dataset:
From: dtiberio@csws17.ic.sunysb.edu (David Tiberio)
Newsgroups: comp.sys.amiga.datacomm
Subject: Re: need help writing a terminal/bbs system
Date: 5 Apr 92 06:44:50 GMT
Article-I.D.: sbcs.1992Apr5.064450.14385
Organization: State University of New York at Stony Brook

In article <2780@faatcrl.UUCP> jprad@faatcrl.UUCP (Jack Radigan) writes:
>dtiberio@engws10.ic.sunysb.edu (David Tiberio) writes:
>
>>	I am working on a BBS and terminal program that will revolutionize
>>computer use over a modem. It will make EVERYTHING easier and faster, and
>>will incorporate quality graphics and music. The drawback is that the
>>files will be BIG suckers. If JR Comm is 200k or so, my terminal may be
>>400k to keep up with everything.
>
>  Not meaning to flame you here, but do we really *need* another specialty
>comm program that can only be used with its parent BBS program?  No matter
>how great it is, it can only be used with one BBS that alot of other
>sysops are not going to want to move over to.
>
>  -jack-

	I do not take this as a flame, but here are my comments:

	It does not require my terminal to use the bbs. That would be
restrictive suicide. 

	It takes advantage of the concepts that make the Amiga the Amiga.

	No one has done it yet, and this makes life so much easier. Most
bbs programs are a real pain for the caller to use, and this is not due
to the speed the bbs operateat.

	All of the graphics will be performed by the calling system and
not the host system. Along with the music. 


	I have used JRCOMM a lot. In fact it is all I ever use. I
sometimes wonder why I can download a file but not change one of the 
prefernces options during that download. JRCOMM is not internally
multitasking. This can place a big burden on users who are used to
multitasking, even at the lowest level.
	I also have used the Workbench, the CLI, and Dir Opus to
do my daily file moving and stuff. A normal BBS is like using the
cli, but in a very restricted environment (certain commands only
work in certain areas, and you have to remember where). Also, 
a BBS does not buffer input to the terminal. A Workbench styled
interface would be great for moving around the sections of a 
BBS, such as from messages to downloads. And a Dir Opus type of
interface is great for having a plethora of commands at your
fingertips.


	My BBS system is exactly what the world needs. Period. No BBS
in existance would compete, and believe me I have seen them all.
And you may call it a burden because it introduces new methods. Didn't
they say the same when they went from kermit to xmodem to ymodem to
zmodem? And not one of these offers what I have to offer in my
new protocols, which have already been tested.

-- 
      //   David Tiberio  SUNY Stony Brook 2-3662  AMIGA  DDD-MEN   
     //  Not the llama! Come here Earl; I want to tell you something...
   \X/		Liverpool, New York	    Yes, I like 3D.
From: jprad@faatcrl.UUCP (Jack Radigan)
Newsgroups: comp.sys.amiga.datacomm
Subject: Re: Max BPS on a A2000
Date: 8 Apr 92 21:18:13 GMT
Organization: FAA Technical Center, Atlantic City NJ

clemon@lemsys.UUCP (Craig Lemon VE3XCL) writes:

>:-).  Most of what I do is not text (ie. BBSing).  It will, most likely,
>consist of SLIP, UUCP and dialup X-Windows as well as a spattering of
>ZModem stuff.  I wasn't questioning your code (I like it) but Commodore's
>hardware.

  Uh, that's what I'm saying, the hardware isn't that bad with 2.04.

>        Well, this is where the fly gets into the ointment.  Right now, I
>can get by with 2400 because my UUCP feed is cost free and I don't have my
>SLIP feed yet.  I don't have the money for V.32bis yet (but I suppose I
>could by this summer, but I'd like to save _some_ of my money for
>University next year :-).  If I'm going to end up waiting until 1993
>anyway, it may be wise to wait and never buy another modem again.

  By all means, if you can get by with 2400bps, do it.  I'm not so sure that
V.fast is going to be consumer-ready by 1993.  It took Rockwell several years
to get a V.32/32bis chipset to market, it's probably going to take as much
time, if not longer, for V.fast to follow and for the prices to drop.

  -jack-
From: enelrad@ucscb.UCSC.EDU (Paradox)
Newsgroups: comp.sys.amiga.datacomm
Subject: Commodore Installer Program (was: opinions on Term 2.1)
Summary: Asking about availability of installer
Keywords: frop
Date: 16 Apr 92 04:04:54 GMT
Article-I.D.: darkstar.33045


Where is the full distribution of this available? I found it in
the "C" directory of "Term 2.1" and people have mentioned that it is
by Commodore. Where can I find it in an archive with docs? Or does
it only go out to registered developers?
From: jprad@faatcrl.UUCP (Jack Radigan)
Newsgroups: comp.sys.amiga.datacomm
Subject: Re: Max BPS on a A2000
Date: 11 Apr 92 21:15:47 GMT
Organization: FAA Technical Center, Atlantic City NJ

clemon@lemsys.UUCP (Craig Lemon VE3XCL) writes:

>        Well, are your spec single-tasking (so to speak) or multi-tasking. 
>When you test scroll-speed there are no disk accesses.  What about if I
>take a directory during a UUCP connection, will there have to be a timeout
>and retry (at high speed the wait wastes a lot of useful data transmission
>time).  I know that I've heard problems from people who get errors every
>time their HD writes during a download.  I better buffer would help or cure
>this problem even if the fault may lie with the HD controller in question.

  The scroll speeds are for a relatively idle system.  And yes, the rate will
definately slow down as you load the system with other tasks to run.  But, that
doesn't necessarily mean that you're going to lose data so long as flow
control is present and there are no design problems with an other resident
programs or hardware devices that are in your system.

  I do plan to help those out that have HD controllers that cause data loss
during disk writes.  I'm not totally sure if it will help the people that
have a controller that uses a device driver that runs at an excecssively
high task priority though, but it should cure the problems for those DMA 
controllers that write an entire block of data in one write action.

  -jack-
From: rock@lakes.trenton.sc.us (Rockerboy)
Newsgroups: comp.sys.amiga.datacomm
Subject: Re: NComm 2.0 at last!
Date: 8 Apr 92 13:20:54 GMT
Organization: The Greg Lake Fan Club

jprad@faatcrl.UUCP (Jack Radigan) writes:

> disk@lakes.trenton.sc.us (Diskraker) writes:
> 
> >These twerps made the Commodore 64 the most popular personal computer in 
> >the world for over 8 years...
> 
>   That's a matter of personal opinion.  Going strictly on the basis of
> units sold, yes, it sold alot.  But, how many of those machines became a
> doorstop or occupied some dark corner of little Johnnie's closet 6 weeks
> after Christmas/birthday?
> 
>   -jack-

Why did they become doorstops, Jack?  That is another consideration.  
They died because they were old, and for a few dollars more you could get 
a 16-bit or better machine.  They _should_ have died years before, but 
they were kept alive by the underground.


"Sometimes what you say is going to fly right in the faces of the 
powerful people who really run this world, but you don't care...you know 
it's your place to challenge authority..."

                                          Rockerboy
Newsgroups: comp.sys.amiga.datacomm
From: karkan@msdrl.com (Jim Karkanias)
Subject: Re: Terminal emulators and TCP/IP
Organization: Merck Sharp & Dohme Research Laboratories
Date: Fri, 10 Apr 92 19:23:10 GMT

roachp@wl.aecl.ca writes:
: Tssnet from Syndesis has tcp/ip support and decnet, for use with ethernet or through the serial port. Good luck trying to get info from them, though.PJR

I know.  Their response time (and ability to respond) is less than optimal. 
We're looking at installing a not insignificant number of workstations here
and thought that it would be a good idea to give Syndesis a shot at it.  Did
they send us an eval. copy?  No.  Will they?  Who knows but the damage they've
done to their professional image may be irreparable.

For example, NeuralWare makes an extremely powerful, advanced, expensive
(about $2000) package that we want to look at.  Did they send us one to play
with?  Yes.  Will we trust them now?  Yes.  Will we buy it?  Probably.

It's how professionals do business.  Maybe Syndesis will learn that and sell
more copies of their product.  Maybe not.


Jim
From: stealth@ac.dal.ca
Newsgroups: comp.sys.amiga.datacomm
Subject: Graphic MUD's
Date: 9 Apr 92 18:41:20 GMT
Organization: Dalhousie University, Halifax, Nova Scotia, Canada

The actual name of the client program to  be used on the visual mud is
AmigaClient.  It works really well to.  The main disadvantage of the 
visual MUD is that it really slows down processes.  However, at least it 
keeps the rooms that you have already been to in some sort of buffer
Steve
From: huebnere@mentor.cc.purdue.edu (Robert Huebner)
Newsgroups: comp.sys.amiga.datacomm
Subject: Supra Fax v.32bis problem(?)
Summary: Problems with BUSY signal detection?
Date: 7 Apr 92 05:30:37 GMT
Organization: Purdue University Computing Center

I hate to be the first person to post a complaint regarding this wonderful
product, but I was wondering if anyone else has had similar difficulties:

Sometimes when the modem is DIaling and the speaker is on, I hear a clear
ring from the remote modem but suddenly the Supra hangs up and declares the
line to be "BUSY".  Other times a real busy signal won't register at all
and the modem will just eventually timeout.  And still OTHER times the
modem disconnects with the BUSY return code before I hear ANY noice from
the speaker (I have it set to atm1 when testing this).  I imagine it might
be able to detect a busy signal even faster than I can hear it, but this
sort of worried me.

Does anyone know why this might occur?  I am reluctant to blame it on the
modem, as it might be a characteristic of our local phone service but I'd
at least like to be able to turn this off if it continues to hang up on
potentially valid connections.

Rob
From: WGLP09@SLACVM.SLAC.STANFORD.EDU
Newsgroups: comp.sys.amiga.datacomm
Subject: Re: VLT keypad emulation: changed?
Date: 17 Apr 92 02:05:14 GMT
Organization: Stanford Linear Accelerator Center

Yes, the VLT keypad emulation changed. VT100's always send the same thing
for the top four keys, whether in numeric mode or not. A lot of people
have complained about this, so I'll change it back, but this was an intended
feature. I got complaints on version 5.045 because it didn't work like a
VT100 in that regard.

        Willy.
----------
Willy Langeveld - Bitnet: WGLP09 @ SLACVM - BIX: langeveld
Newsgroups: comp.sys.amiga.datacomm
From: paws@cray.com (Daniel Baehr  (1252))
Subject: X*Press drops Amiga...more info..
Organization: Cray Research, Inc.
Date: 9 Apr 92 11:21:00 CDT


      I am a ?proud? owner of the Amiga X*Press package.  I called 
 them to get more information on why they dropped the package since
 the only thing they have to do is make copies of the disks.  I was
 told that they couldn't get in touch with the Author of the Amiga 
 software and due to the small number of Amiga packages sold it wasn't
 worth their time to track the author down.  Too bad!  I'd LOVE to get
 a hold of the source code to fix a couple of the problems it has.

   Daniel Baehr   paws@artgate.cray.com

  p.s.  I hope the thing is 2.0 compatable!!!!


-- 
+---------------------------------------------+
|   Daniel Baehr    paws@artgate.cray.com     |
|                                             |
+---------------------------------------------+
From: Reid_Bishop@a68k.denver.CO.US (Reid Bishop)
Newsgroups: comp.sys.amiga.datacomm
Subject: Re: HELP!  Zmodem/SupraFax
Date: 14 Apr 92 10:06:29 GMT
Organization: The Arvada 68K BBS- Westminster, CO

In a message dated Mon 13 Apr 92 07:34, Jmarin@messi.uku.fi (jukka Marin)
wrote:

 JM> My brother installed a V.32 V.42bis modem to his A2000 system
 JM> yesterday
 JM> which supports DTE speeds up to 57600 bps.  At the 1100 cps transfer
 JM> rate his vanilla 68000-based A2000 had no problems with the data - in
 JM> fact, much less than 50% of CPU time was being used.

This is really a lousy transfer rate for v.32bis connects.  A regular,
stock v.32 modem can easily do 1100 cps, which equates to only about a 9600
bps DTE rate. (Or less...)

I'd say that either the connect was indeed _not_ v.32bis, and if it was,
you were running very inefficiently.

-- Via DLG Pro v0.991

...........................................................................
 /\  /\  \  /       | Reid Bishop- Cust. |INTERNET: rbish@a68k.denver.co.us
/  \/  \. \/. MICRO | Suppt & Prgrming   |    UUCP: csn!a68k!rbish
Suppt BBS: The Arvada 68K BBS (303) 424-6208 * 310 Megs * AMIGA * 1:104/224
From: jprad@faatcrl.UUCP (Jack Radigan)
Newsgroups: comp.sys.amiga.datacomm
Subject: Re: "64 Mentality" vs "PC/Corp Mentality"
Date: 10 Apr 92 13:04:09 GMT
Organization: FAA Technical Center, Atlantic City NJ

spice@drycas.club.cc.cmu.edu writes:

>Nope , you dont steal hardware because there's a significant chance of
>getting caught and getting punished which isnt the case when
>stealing software. After all , the chances of the police breaking
>your door down when you copy a program from a friend or download it
>from a pirate BBS are microscopic. If stealing hardware was as easy
>and risk free as stealing hardware you and you friends would do
>that too.

  I actually have more respect for the common car thief or any other criminal-
type that takes the risk of getting caught during the act of taking something.

  It's also amazing how someone would never think of walking into an Egghead
or similar store to physically steal a program yet doesn't even blink when
copying the same damn thing from someone else.  Better yet, the ultimate
rationalization, spliting the cost of the program amongst two or more people,
yeah, that's a real cute one.

  -jack-
Newsgroups: comp.sys.amiga.datacomm
From: djkucera@descartes.waterloo.edu (Dylan Kucera)
Subject: Term 2.1 problems
Keywords: term 2.1 speech problem
Organization: University of Waterloo
Date: Thu, 16 Apr 1992 03:21:47 GMT

    I cannot seem to get the SPEECH option to work in Term 2.1!
Is there a bug?  Have I not set something up?  I put the "Speak on" from
the preferences menu, but it doesn't want to yack at me about anything!?

Anyone else have this problem?

DK.
From: robbel@fwi.uva.nl (Robert Belleman)
Newsgroups: comp.sys.amiga.datacomm
Subject: VLT keypad emulation: changed?
Date: 15 Apr 92 08:52:01 GMT
Organization: FWI, University of Amsterdam

What happened to the keypad emulation in the last version of VLT? The PF1
to PF4 keys and the PLUS don't do anything anymore. The rest perform their
normal "application" functions. I tried the various keymaps, but none
solved the problem. Willy?

-- Rob

-- 
[] Robert Belleman              robbel@fwi.uva.nl     "If live is a stage,  []
[] Dept. of Computer Systems    robbel@nki.nl          I want some better   []
[] University of Amsterdam                             lighting."           []
[] the Netherlands.                                                         []
From: Ray_Hines@dream.uucp (Ray Hines)
Newsgroups: comp.sys.amiga.datacomm
Subject: Re: Max BPS on a A2000
Date: 13 Apr 92 22:32:05 GMT
Organization: DreamStates BBS & CyberNet HQ in G'ville, FL   1-904-331-4317

In a message dated Mon 13 Apr 92 13:04, Jprad@faatcrl.uucp (jack Radigan)
wrote:

 JR>   By all means, if you can get by with 2400bps, do it.  I'm not so
 JR> sure that
 JR> V.fast is going to be consumer-ready by 1993.  It took Rockwell
 JR> several years
 JR> to get a V.32/32bis chipset to market, it's probably going to take as
 JR> much time, if not longer, for V.fast to follow and for the prices to
drop.

Can some of you tell us more about v.fast?  How fast does it go?

-- Via DLG Pro v0.991

* IF replying by MAIL, please reply to the addresses listed below...
--__-----------------------------------------------------------------------
 / /\     Raymond Hines              Internet: Ray_Hines%dream.uucp@ufl.edu
/_/  \  DreamStates BBS                    or: dream!Ray_Hines@ufl.edu
\ \  /   1-904-331-4317                  UUCP: uflorida!dream!Ray_Hines
 \_\/ FidoNet 1:3601/30  DreamStates: An Amiga supporting Amiga, Mac, IBM!
From: Les_Jenkins@lppl.mi.org (Les Jenkins)
Newsgroups: comp.sys.amiga.datacomm
Subject: Re: BBS Software
Date: 7 Apr 92 20:52:59 GMT
Distribution: world
Organization: Les's Place BBS

In a message dated Tue  7 Apr 92 02:26, Kendrix_j@mims.enet.dec.com (john R
wrote:

 KR> I'm thinking about putting up a BBS, could someone tell me which BBS
 KR> software
 KR> is best?  I'd like to take a look at DLG pro and SKYLINE so if
 KR> someone could
 KR> give me the phone numbers for these support boards I would appreciate
 KR> it. 
 KR> Sorry if this text is screwed up... I'm using the VT100 Emulation
 KR> which came
 KR> with TERM 2.0...  Pretty nasty stuff all together!!

I suggest you look to someone else running a DLG system other than the
support HQs as an example of what can be done. Being that TpT is quite busy
with working on the software itself, their board isn't exactly a stunning
example of what can be pulled off with the software. (It's not too bad, but
it's not the best example I have seen.) Call the support HQ to get more
in-depth info on the system, but don't count it as a prime example of what
the software can do. I find this is true in most support HQ BBSs for any
software. 


-- Via DLG Pro v0.991

---------------------------------------------------------------------------
E-Mail to:     | If God had meant for Man to have meaningful signature    |
Les@lppl.mi.org| files, then we would have been born with them!           |
---------------| <Insert Cute ASCII picture here.>                        |
               ------------------------------------------------------------
Newsgroups: comp.sys.amiga.datacomm,comp.dcom.modems,comp.protocols.misc
From: dwh@vaxeline.ftp.com (David W. Hamaker)
Subject: Re: New modem transfer protocol
Organization: FTP Software, Inc., Wakefield, MA
Date: Tue, 14 Apr 1992 02:50:48 GMT

In article <kujvqgINNi76@news.bbn.com> pplacewa@bbn.com (Paul Placeway) writes:
>My reply to "Why frame the blocks at all?" is because Real Life isn't
>fair.  Theoretically a 99.99999997% data protocol looks very nice, but
>VERY few computers can withstand a sustained 57.6kbps async input
>stream for many MB without blocking....

Fair?  I wouldn't even call it "good." :-)

I think Paul's observation that he sees overrun usually at about 4K argues
that computers USUALLY CAN withstand that input, unless hardware FIFO's
are that large these days.  Smaller, more frequent dropouts would be a
more convincing scenario.  It sounds more like intermediate buffering
resource problems and/or operating system overhead in the software is at
fault.  UNIX, in particular, is not famous for its interrupt latency.

Stripped of it trappings, I think his argument (correct me if I'm wrong)
is that most machines are easy to overrun so the protocol has to be
crippled some to work.

I don't think that's necessary.  It may not be something to avoid for an
unambitious protocol, but when the whole point of the protocol is its
performance, I think you gotta try harder.  You owe it to the "VERY few"
computers that are up to the task, and you may be able to give the more
slothful ones a reason to try to improve.

The application running the protocol is likely not told about the
overruns by the operating system but just sees gaps in the data (of
which it is unaware).  (The OS may even have thrown out an XOFF
before it "hit the wall" - the layering may preclude a better
response.  In fact, I think something like XOFF is the right thing to
do, but the backpressure has to get back far enough and fast enough
to actually stop the flow in time.)

If you have the check data going down the back channel you can fill
up the back channel with check data without adding more overhead to the
forward channel.  In many cases, (the sloths will no doubt be unhappy
about the increased interrupt rate) this means the "packet" size can
effectively be reduced so the sender can get feedback about the gap soon
after it happens.  With "go-back-n" recovery, it would be interesting
to see how this by itself would operate.

But the problem can be dealt with much more directly.  Give the sloths
a window they can enable.  Then if the sloths are not timely in returning
their check information, the sender can just wait a bit until they do.
The window needs to be sized to the buffering available and allows the
sender to get ahead enough to make sure the receiver has something to 
keep chewing on if it can keep up.

-Dave Hamaker
 cfcl!dwh@apple.com
 dwh@ftp.com
Xref: sparky comp.sys.amiga.datacomm:3440 comp.dcom.modems:6415 comp.protocols.misc:327
From: floyd@hayes.ims.alaska.edu (Floyd Davidson)
Newsgroups: comp.sys.amiga.datacomm,comp.dcom.modems,comp.protocols.misc
Subject: Re:  New modem transfer protocol
Date: 8 Apr 92 21:28:39 GMT
Organization: University of Alaska Institute of Marine Science

In article <1992Apr8.194254.13083@crd.ge.com> davidsen@crd.ge.com (bill davidsen) writes:
>In article <dej.00jj@qpoint.amiga.ocunix.on.ca>, dej@qpoint.amiga.ocunix.on.ca (David Jones) writes:
>
>|  PEP is real bad in that it's unidirectional.  Send ONE byte down the
>|  back channel and you take 10 seconds to retrain for the turn-around.
>|  If you have a PEP, stick with Zmodem.
>
>  Why? You have spoofing for Xmodem, Kermit, and uucp 'g', so you
>shouldn't see any diference in throughput, with those protocols, unless
>you fail to run the serial link fast enough.

Not to mention that PEP will turn around a couple times in that
10 second period anyway!  It makes no difference if you send one
byte or none, it still turns around every so often to see if there
is anything for the opposite direction.  It hardly takes 10 seconds
to accomplish.

The time problem, when not using spoofing, is not how long it takes
to turn around so much as it is how long before it decides to do
it...  while the sending end waits until it does.
From: pat_meloy@outbound.wimsey.bc.ca (Pat Meloy)
Newsgroups: comp.sys.amiga.datacomm
Subject: Re: RexxArpLibrary 3.0
Distribution: world
X-NewsSoftware: Amiga GRn V1.28 2/25/92 (Beta) by Mike Schwartz
Date: 11 Apr 92 12:28:32 PST

In article <92102.000343WGLP09@SLACVM.SLAC.STANFORD.EDU> WGLP09@SLACVM.SLAC.STANFORD.EDU writes:
>I'll tell you why it is *wrong* to include all the "required" libraries
[tons-o-reasons deleted]

My #1 problem with including the libraries is that I usually already HAVE
them on my hd. Having to download the same files over and over doesn't
sound like a great idea in the first place and justifying it with "But I
don't want to have to download the single library" is definately out to
lunch.
From: rock@lakes.trenton.sc.us (Rockerboy)
Newsgroups: comp.sys.amiga.datacomm
Subject: Re: Flame war has gone on long enough
Date: 10 Apr 92 12:59:54 GMT
Organization: The Veronica Lake Fan Club

dej@qpoint.amiga.ocunix.on.ca (David Jones) writes:

> For the past month or so, I have been reading endless flame wars for
> and against shareware.  Enough already!  Please stop!
> 
> Software development is expensive.  Authors have the right to charge
> for their work if they want to.  If you don't like it, tough.
> But this isn't the place to bitch about it.

No flame intended, but wher _is_ the appropriate place?  Is there a sig 
devoted to these types of discussions.  (Other than advocacy, which seems 
like nothing but a general purpose crank sig.)


"Sometimes what you say is going to fly right in the faces of the 
powerful people who really run this world, but you don't care...you know 
it's your place to challenge authority..."

                                          Rockerboy