🚀 go-pugleaf

jmunkki@kampi.hut.fi(Juri Munkki) writes in comp.sys.mac
>In article <46100258@uxe.cso.uiuc.edu> leonardr@uxe.cso.uiuc.edu writes:
>>Those of you interested in ZMODEM might also want to check out the Software
>>Ventures booth at the MacWorld Expo this week.  They will be showing a version
>>of MicroPhone II (v3.0) which includes not only ZMODEM, but a number of other
>>nice new features as well.
>
>The file transfer capabilities of MicroPhone II already are wonderful, but
>I'm much less exited about the terminal emulation itself. The most disturbing
>feature is the blinking cursor that always hides for a moment after it has
>moved. It takes a lot more time to find it than a cursor that is either always
>visible (when idle) or always starts out by being visible.
>
	Thank you very much for the compliment, but as I pointed out - ZMODEM was
not the only thing that we did for 3.0 (see later for larger list).

	I agree with you and this problem has been fixed. 

>MicroPhone II is also a lot slower than VersaTerm Pro and it supports only
>a 24 line VT100 emulator. I'm used to 36 lines with Versaterm or 40 lines
>with my own program...
>
	You will find the the Text I/O of MicroPhone II v3.0 is now FASTER than
Versaterm and considerably more reliable. Try doing a text dump to VTPro at
9600 (or above, 19.2 is good) WITHOUT Xon/Xoff and see how much text you
lose!!

	Also note that a >24 line VT100 is NOT a real thing.  It is someting that
has been added MUCH later  (around the time when personal computers came about)
and is NOT part of the ANSI/VT100 spec.  We are aware that such a featurew 
would be nice, but have chosen not to implement it until it becomes more of
a 'standard'.

>On the good side: the scrollback buffer is not "jumpy". The screen does not
>jump to the end when new text arrives. This is a great help when reading
>digests or other long files without more/less. The only programs that I know
>of that can do this are MicroPhone and my program.
>
>Why is Microphone so slow? Why does it take so much disk & RAM space?
>Why does it have over 60 code resources with an median size of about
>1-2KB. Those subroutine calls between segments must cost something...
>
	There are many reason why the current products screen I/O is so slow and
also why we improved them for v3.0.  I am sorry that you were unable to 
attend the Expo (too long a drive, eh :-) as I would have liked to have shown
off the new speed.
  As far as disk space, the program is 270K (approximately in v2.0) and think
about what you have in that...On the whole, the largest parts of the program 
(obviously) are the Scripting language (which is QUITE powerful as you well
know), and the File Transfer protocols.  I can't say anything than, considering
all the other applications out there - it still fits on a 400K disk!!
	RAM space?  Do you realize that MicroPhone II will run on a 512K Mac,
though it prefers a 512KE?!?!  In this day and age, that's an accomplishment
for such as powerful product!!  If you are refering to the default multiFinder
partition size, please feel free to reduce it as it can be reduce to about 256K,
though we don't recommend it less than 300.  The only effect that lowering the
partition size has is to reduce the number of lines in the scrollback buffer -
the application itself is quite well behaved as far as memory managment...
	This brings me to your next point - the reason for the small code segments
is called SEGMENTATION!!!  MicroPhone II is heavily segmented so that it can be
used EFFICIENTLY on 512K machines and in small MF partitions.  I dont' know
whether we pay any penalty for that (though I would doubt it?!?) but we feel
that it is important to support both smaller machines and smaller partitions.
-------------------------------------------------------------------------
For those interested, here are some of the features of v3.0
-------------------------------------------------------------------------

Some of the things you can expect to see are:
	ZMODEM - a very powerful file transfer protocol
	Enough scripting power to write a Navigator-like suite of scripts
		including arrays and file variables!
	Terminal emulation enhancements in speed and support for color
	Support for Apple's extended character set for international use
	Command Key equivalents in menus and dialogs for power users
	Additional goodies such as a buffered keyboard & Buffer Searching
   Full Color Icon Bar which can be moved/resized and scrolled
		This replaces the previous fixed position button bar
	Ability to write graphical front-ends to systems like UNIX
	and much more....


+---------------------------------+-----------------------------------+
+                                 +  Any thing I say may be taken as  +
+   Leonard Rosenthol             +  fact, then again you might decide+
+   President, LazerWare, inc.    +  that it really isn't, so you     +
+                                 +  never know, do you??             +
+   leonardr@uxe.cso.uiuc.edu     +                                   +
+   GEnie:  MACgician             +  MacNET: MACgician                +
+   Delphi: MACgician             +  AppleLink: D0025                 +
+                                 +                                   +
+---------------------------------+-----------------------------------+