From: kehlet@kehlet.adsp.sub.org (Jesper Kehlet)
Newsgroups: comp.sys.amiga.datacomm
Subject: Re: Amiga Kiosks?
Date: 18 Aug 92 19:17:36 GMT
Organization: Compos Mentis Software Systems
X-NewsSoftware: GRn 1.16e (7/4/92) by Mike Schwartz & Michael B. Smith

In article <1992Aug13.142013.4460@TorreyPinesCA.ncr.com> jgrimm@TorreyPinesCA.ncr.com (Jeffrey Grimmett 9999) writes:
> In article <kehlet.060m@kehlet.adsp.sub.org> kehlet@kehlet.adsp.sub.org (Jesper Kehlet) writes:

> >Too bad!  NComm is full of bugs, try to be professional, shareware, and now
> >they even want to make Torkel do work on another package?
> 
> Beg pardon, but could you follow-up and be more specific?  With the exception
> of 2.03 (a hacked pirate version), I've found no more bugs in NComm than in
> JRComm, and far less than Term, Baud Bandit, or ATalk III.

I'll be more specific later on.


> >It's not, that I have anything thing against his programming -- I haven't
> >seen one bit, but the ANSI bug, the SLOOOOW speed, the nasty setup, the
> >square look of it...  nah, there's too much wron with it.
> 
> Actually, it sounds like you're talking about version 1.921, which was free,
> so what's to gripe about?  :-)

Nope!  The *REAL* 2.0.  Shareware version, not anything like bogus 2.03 or
freeware 1.921.  ;-)


> >It might not be perfect yet, but it's BLAZINGLY fast, it does perfect
> >ANSI/VT-100 (and will be doing VT-220) -- even IBM ANSI (there's a bug with
> ><ESC>[2J in IBM ANSI).
> >
> >Even in 16 color mode, it scrolls a screen full of colored ANSI graphics so
> >fast, you can't possibly keep up with it...
> 
> What is this, BlazeMongerComm or something?  And is not being able to keep up
> with a screen a good thing?
> 
> Seriously, if you are writing a comm program, more power to you.  Just make
> sure you address all your gripe's with NComm and combine the best features
> of all the good programs out there.  (personally, a lookalike of Access! would
> be great!).

It's finished and ready for shipping at a price of US $50 or so when it
reaches you.

A demo will be out soon, so I need to know how to put that one up for ftp.


> >Good programming of the serial.device gives ~238 cps throughput on normal
> >Zmodem (built in) transfers -- I'd be surprised if I'd ever see NComm go
> >beyond 230...
> 
> Not using the XPR libraries, are we?

Sure ain't!  ;-) Built-in transfer protocols to reduce the library
overhead, that is of great importance when doing file transfers...

XPR *WILL* be available in the future, but why use them if the built-in are
faster and even more reliable?

Besides you get a lot more flexibility with built-in protocols.

And now for the NComm bug stuff:

	- When trying to open the serial ports in shared mode (3 lines,
	  actually) and it fails, it doesn't close down what it has already
	  opened, so a reboot is necessary.

	- NComm in general opens the serial port in a bad way.  It simply
	  won't work under future revisions of OS.

	- It's SLOW in file transfers.  It uses XPR and very badly
	  implements this, thus it gets major overhead on those XPR
	  libraries.

	- The ANSI is awfully implemented.  I have experienced problems
	  with at least 30 BBS's here in Denmark and more than 50 foreign
	  ones.  I think this relates to the fact, that NComm uses CON:
	  compatible ANSI, so it's very non-compatible.

	- It's screen/ANSI is SOOOOOOO slow...  Probably a CON:  problem,
	  too...

I could give you a lot more, but let's keep this posting down in size...
;-))


> Jeff Grimmett

-- 
     Jesper Kehlet, Compos Mentis Software Systems -- A Kind Of Magic

        (uunet|pyramid|rutgers)!cbmvax!cbmehq!cbmden!kehlet!kehlet
             cbmehq!cbmden!kehlet!kehlet@cbmvax.commodore.com

      As long as I speak for myself, my employees can do that, too...