[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

PT3, AT2.0 and me. :)



Part I:

This part has been posted before, so I'll keep it short.

The so-called 'hardware bug' in the GS's serial ports was all in my
imagination.  It turned out to be a programming error on Greg's part and I
heard that a similar error was also corrected in some other software(s)
(anyone now for sure?) at around the same time as Greg corrected his.  Greg
initialized the SCC with the Xmit clock ON (using an example from the Zilog
book instead of the GS hardware ref).  The CTS signal and the Xmit Clock
signal both use the same circut from the SCC thru the various chips to the
same pin on the modem port on the GS - you could say that the signals are
tied together once they get out of the SCC.  On some systems, the Xmit Clock
being on didn't cause problems.  On other systems it did.

However, fixing the software made the difference no longer important.

However, it embarrased the hell out of me.  :)

Part II:

This is in response to Greg Boh, but if Paul Parkhurst is out there, can you
check out at least the end of the message and preferably the whole thing?

> From: fnet@randell.cba.csuohio.edu (Greg Boh)
 
> Wrong. METAL's Y-modem G protocols stream in both directions, Up AND
> Downloading. They work just fine. I receive MUCH better throughput with
> the METAL Protocols (Based on the onscreen CPS and Efficiency ratings)
> than I do with ProTerm 3.0 or the old AnsiTerm's Z-modem.

Granted I'm sort of a heavy ProTERM 3 user and so I have some biases, but I'd
just like to clear something up.

Greg's CPS calculations are "conservative".  From what [I] understand, PT3
starts timing a transfer (er - reads the clock) as soon as the status box
goes up (before negotiation) and stops timing right before the dialog goes
down (eg after the final ACK packets are sent and both sides know the
transfer is over).  No time is subtracted for disk access, startup delays,
etc.  Granted its a very simple way to get the CPS values, but it won't get
him in trouble for OVERSTATING PT3s abilities.  He might get in trouble for
understating them...

I wonder how AT2.0's and METAL's CPS rating are calculated.  Any answers?

ObSideNote:  When I do null modem connections with Telix on a P/70 connected 
via null modem to my GS running PT3, Telix always shows CPS values higher
than PT3 reports.

The best way, IMHO, to check out which programs are fasters (vrrrm, vrrrm! -
I can feel that testost...I mean those electrons flowing!) would be to do
PT3<->PT3, AT<->AT, and PT3<->AT null modem transfers at 57600 and make a
table of the numbers reported by both programs.

I must admit I'd *LOVE* a bigger editor such as AT2.0 will have/has.

However, I use PT3's macros extensively for various things.  They are quite
powerful and are very very handy.  I've heard that someone may be programming
a (less than full featured) mini-bbs system via the macros.  It could be
interesting.  Yes its possible - macro files can be loaded & unloaded on the
fly and a modular approach could work.  It would probably be slow, but it
would work.

One problem I see with AT2.0 is the slow scroll speed.  Now, I DO understand
that this is because of the limited graphics/speed capabilities of the GS and
I think the Jump Scroll feature will definitely help in this situation. 
However, let me give you an example of where I think I may have problems
using AT2.0 if I were to buy it.

I call the 01 Networking (distributors of ZyXEL modems in the US) BBS system
a few times a week.  My connection is usually:

Port Speed:  57600
Data Link Rate:  ZyXEL 19200 (sometimes V.32bis 14400 if lines are bad)
Compression: V.42bis

and I tell the system to dump all new messages to me all at once.  I get
about 10-45 seconds or so of faster than 38400bps scrolling screenfuls of
text, including lots of lines that are very short because they are examples
of AT commands and responses in the bug report section.  Why is this
significant?  The shorter the lines of text are, the more memory moves there
are per byte received on average.  You end up scrolling say...every 10
characters instead of every 70 or so.

PT3 can handle this fine on my system, flow controlling very very rarely, but
more heavily duing the AT command listings.

I then log out and spend the next half hour or so reading all those messages
off line in scrollback.

What value will Jump Scroll have to be set to in order to keep up with such a
connection?  Will I still be able to usually complete the connection in less
than a minute, saving me money?  Will the demo allow me to try it out?

Suggestions for The Demo. :)

Full baud rate selection.
Time limit.
Maybe transfer size (in KBs) or # of files limited.
Maybe # of transfer per session limited.

Oh yeah....will the Special (akin to ProTERM Special) emulation support
'music'?

No room 4 sig