Conference hydra::amiga_v1

    I forgot: can use any fonts you like.  Comes with 80 and 132 column
    clean type fonts.

    Welcome back !
    
    As you say, your new program should be a good starting point for
    a very flexible terminal emulator package.
    
    regards
	Mike
         ( a happy smokey user...)

    Welcome back Mike!!
    
    I D/L your 220 emulator from PLINK a few days ago.  The 80/132 col
    ability is super.  I did notice that while scrolling on the screen,
    the emulator was very bursty.  I thought it might be our system
    or server, but Smokey didn't do it.  Perhaps your memory optimization??
    
    Smokey works so well with file transfer, etc. etc. etc., how about
    adding 80/132 support to it?
    
    Oh, by the way I have an A500 w/1meg and hard disk hooked to the
    net through a server at 9600 if that helps define the problem.
    
    Again,  Welcome back!
    
    John
    

Hey Mike, wanna talk TDSMP?  I'm hunting for your phone number now...

    PLINK!!!!
    
    I sent my program to ONE and only ONE bulletin board in rochester,
    and now it is on PLINK.  Neat.  I really was hoping V1.0 didn't
    make it out so quick because there are a lot of bugs in the session
    manager which I fixed.  V1.01 won't guru as much.
    
    Bursty:  I don't have a machine at school where I can hook up meshugena
    to run at rates faster than 1200.   If you are running at 9600 or
    19200, my terminal probably start buffering scrolls.  The burstiness
    can be avoided by setting a maximum number of lines to jump scroll.
    
    V1.01 terminal_setup:
    	jump scroll maximum : 4
    
    	--Mike
    

    Check out VIDEO::ENG$7:[LEIBOW.AMIGA]MESHUGENA.ARC;1
    
    	--Mike
    

    For those of you who may have picked up my emulator, played with
    it, and noticed the bursty (and sometimes slow) output,
    
    I have just found a major bug.
    
    I think all of the text in the window is being drawn twice.
    
    	--Mike
    

    Hi Mike,
    
    Just a quick note to check on the current status of MESHUGENA. 
    I've just gotten SMOKEY 1.1A and it's proven to be a dream-come-true.
    If MESHUGENA is, as you stated earlier, even better, then it's a
    must-have.  (Sheesh!  Why am I talking in clich�s and buzzwords?
     Maybe I've been working to hard...)  
    
    Did you ever add keymapping support, or even support for an A500
    keyboard (i.e. make the keypad work like an LK201)?  Also, is it
    still public domain?  There's a Digital customer down here who
    DESPERATELY wants a decent VT220 emulator for his A500 and Smokey's
    labeled "INTERNAL USE ONLY".  (Gotta keep those customers happy.)
    
    BTW, Thanks for SMOKEY.  It's made life much more enjoyable.
    
    
    					John Boy

    Hi,
    
    I've been incredibly busy with work and school.  I am currently
    taking a night class at the University of Lowell which is eating
    up all of my time.
    
    I have worked a little bit on Meshugena, but I've done more damage
    then good.  I have been trying to get Meshugena to do very optimal
    screen updates.  I was under the impression that if I delayed all
    Amiga calls to the window (scrolling and text) so that batch scrolling
    could be implemented the performance would be much better.  It turns
    out that the time necessary to compute my optimizations is longer
    then it would be to use the Amiga's blitter to do scrolls the "long"
    way.
    
    I've done other optimizations like turning the cursor off when there
    is still data being processed from the serial port.  I have made
    improvements to the way text is dispatched to each session.
    
    When I get back to school (Sep 1), I will convert some of the update
    routines to assembly language.  Meshugena now has approximately
    865 CPS performance.  I am expecting approximately 1300 CPS in about
    a month.  By that time I will release a new version with a completely
    redefinable keyboard for all of the Amigas.
    
    	Stay tuned.
    
    	--Mike
    

    University of Lowell?  You're in New England!  I don't know why,
    but I thought you were in Europe.  Zoiks! Talk about memory 
    corruption!  %-|
    
    				Johnny B. Goode
    

    I've been driving my self crazy for the last couple of days trying
    to impove the performance of Meshugena.  After pulling all of my
    hair out (I'm now bald), I decided to stop playing with the debugger
    and use the old printf().  It turns out I made a type when I was
    rewriting the initialization code, and the serial driver was sending
    me only one byte at a time.
    
    My usual benchmark for speed tests is sending 80 columns of graphics
    characters (abcde...) and then a CR LF pair.  I was getting 450
    CPS with the bug.  After I found the bug and squashed it, I improved
    the performance to 950 CPS.  Since I am operating the the terminal
    at 9600 baud, I am not going to work much more on performance. 
    I am going to rewrite some of the output routines so that smooth
    scroll will work at a reasonable rate.  Right now, it is real slow.
    I also plan on changing to SuperBitmap window to make the windowing
    features work faster.  And lastly, since I just rewrote the session
    manager while working on performance, tdsmp should be easy to hook
    up to my code.
    
    	--MIke
    

    if anybody cares...
    
    	I added TD/SMP to my code, and am removing the tiny little bugs
    that are crawling around.  Jeff Lomicka was nice enough to share
    the TD/SMP module from Whack.
    
    	I will only be here for 12 more days at the most (maybe 10)
    and have absolutely no time to make any further enhancements.  I
    will download two versions of Meshugena the day before I leave.
    Meshugena 1.2 will be the code that uses the Unix Windows protocol.
    I still have to come up with a name for the TD/SMP version.
    
    Meshugena is public domain.
    The TD/SMP version is not.  It must be used only be DEC employees
    because of the TD/SMP code.
    
    I'll leave another message here when it is downloaded somewhere.
    
    	--Mike
    
    PS: if it don't know what TD/SMP is, it stands for Terminal Device/
    Session Management Protocol, and is the protocol used by SSU and
    is also available on the DECserver200 terminal servers.

    Could somebody mail me the sources of the new keyboard mappings
    used in Smokey or Foggy, or better yet, post the new keycodes and
    what you'd like those keycodes to be.
    
    I don't have time to fix my new keyboard routines before I leave,
    but I could easily make an A500 or A2000 switch to make the keymap
    more reasonable.
    
    	Thanks,
    
    	--Mike

New terminal emulators:

	Meshugena.arc - the PD version that uses Unix Windows
	Wheat.arc - the DEC Internal Use Only which uses TD/SMP

They can be found in

	PRNSYS::DUA1:[LOMICKAJ.HOBBY.AMIGA]

8/19/88 is my last day of work, so the files will not be available in
my directory.  The directory above is owned by Jeff Lomicka.  He will
be "taking care" of my files while I am gone.  He does not own an Amiga,
but does read this news group and might be able to answer your questions
if you have any.

	Hope these are useful,

	--Mike

PS: See ya next year.
    

>    < Note 1450.14 by VIDEO::LEIBOW "Michael Leibow" >
>                          -< New Terminal Emulators >-
>
>New terminal emulators:
>
>	Meshugena.arc - the PD version that uses Unix Windows
>	Wheat.arc - the DEC Internal Use Only which uses TD/SMP
>
>They can be found in
>
>	PRNSYS::DUA1:[LOMICKAJ.HOBBY.AMIGA]
 
    Sorry, there is no amiga subdirectory there. I'm I too early ???
    Or it's somewhere else ??
    
    Miguel A.

    Both files are available on
    
    PAULY"AMIGA"::
    
                  WHEAT.ARC
                  MESHUGENA.ARC
    

You were too early.  The files are available on PRNSYS now.

To use WHEAT to get multiple sessions, you need to do one of the
following:

    - Use a V2.0 DECServer that supports the SET MULTI ENABLE ommanmd.

    - Use a VMS system that has VMS SSU installed.

    - Use ULTRIX with Ultrix SSU installed.

The following applies if you are using VMS SSU:

You must use SSU on the FIRST vax you reach.  You cannot enable the use
of SSU after performing a SET HOST.  SSU can be used on VTA: terminals,
physical terminals if they are SSU INSERTed, and LAT terminals if your
system has VTA's enabled.

To find out if your system has SSU installed, do a

	SHOW DEV TD

If it lists TDA0, you are in business.  Try the command:

	MCR SSU ENABLE

If you get some junk like "?AJ?AJ?AJ", you're all set, run WHEAT and you
can get multiple sessions.  If you are running What whenyou do this, and
have sessions enabled, you won't see the junk, it will just enable
sessions.


Things that go wrong:

- No TD device?

You need to have SSU installed.  The kit is avalable from
VIDEO::SSU$011_KIT:SSU011.A.  See the VIDEO::SESSION_SUPPORT_UTILITY
conference (hit KP7) for latest kit information.  VMS SSU is a real DEC
product used to support the multi-session VT330 terminals, and every
VMS system in DEC should have it.  Don't let your system manager push
you around.

- SSU ENABLE fails?

The easiest way for SSU ENABLE to work is if your system has VTA's
enabled by default.  This is discussed at some length in the ssu
conference topic number 29 among others.  This is the only way for LAT
terminals.

The other way is, if using a physical line, to perform an SSU INSERT
command on the line before logging in.  This is usually done from
SYSTARTUP.COM.

Again, a search through the SSU conference should get you going.  I
recommend topic 5 for a quick technical overview.

    Why ?AJ?AJ?AJ? I don't receive that junk on my VT340.

You only get junk when you are using a terminal that does not support
multiple sessions.  If you are using a VT330/340, Whack on the Atari,
Wheat on the Amiga, or VWSSSU, then the "junk" is interpreted by the
terminal as commands for enabling the multi-session capability.

Unless, of course, you have multiple sessions turned off set SET-UP.  In
that case, you should get the junk anyway.

If you are already using a VT330/340 with multiple sessions, then you
don't need to do anything different for Wheat than you do for the VT330,
except that you DO get MORE sessions with Wheat.  My instructions are
aimed at those who haven't had to use SSU before.

    Okay .. what happened to Kermit and Amiga 2000 keymaps?

    And {X,Y,Z}MODEM???

    First things first.  Hey, we've got TD/SMP AND a damn good VT200 T.E.
    Seven sessions in separate windows over a single async line.
    Could you do *that* with a VAXstation at home?  I don't think
    so. (but it should) 
    
    Kudos to Michael, Jeff and all who were involved in a job well done.  
    
    Thanks,
    
    -bw  
    
    P.S.  I must admit I salivate at the mere thought of File transfer 
    	  while reading mail or notes. ;')
    

>    First things first.  Hey, we've got TD/SMP AND a damn good VT200 T.E.
>    Seven sessions in separate windows over a single async line.
>    Could you do *that* with a VAXstation at home?  I don't think
>    so. (but it should) 

Well, yes, using VWSSSU.  PRNSYS::DUA1:[LOMICKAJ.VWSSSU]VWSSSU.EXE uses
the same TDSMP source code module as "Whack" for the Atari and "Wheat"
for the Amiga, and allows you to have multiple sessions in multiple
workstation windows under VMS using either DECWindows or VWS.  (If
you're clever, you can even use it to multiplex multiple local
terminals through a single TD/SMP serial line.)
    
>    P.S.  I must admit I salivate at the mere thought of File transfer 
>    	  while reading mail or notes. ;')

Well, you shouldn't salivate too much.  "Whack" on the Atari has a file
transfer capability, and while it is POSSIBLE to perform file transfers
while reading MAIL or NOTES, you don't generally want to, for the
following reasons:

 - If you are transferring a file from the VAX to the Atari, the file
transfer is using a lion's share of the wire, and display of MAIL or
NOTES is very, very slow.

 - If you are transferring a file from the Atari to the VAX, the
keyboard response is very slow.  While you can READ Notes or Mail
pretty well in this mode (since all you ever do is hit RETURN or
ENTER), editing is nearly impossible because of the echo delay imposed
by the computer constantly sending large packets of data on the other
session.

Now, part of the problem here is that Whack's file transfer protocol is
very line efficient.  It never pauses for ACK messages or anything - it
is happy to spew data non-stop, leaving other sessions with precious
little.  Also VAX SSU multiplexes by doing round robin sessin selection
on a per QIO basis.  Most programs do QIO per line, but Whack's file
transfer does QIO per 255 byte packet.  This means that you get one
line from MAIL, and then wait for 250 bytes of file transfer...

There are things that could be done to help this, by doing lots of clever
manipulation of credits to give interactive sessions priority over file
transfers, but when you get right down to it, a 2400 baud serial line is
limited to 2400 baud, and when you're using it, you just don't want to
share it with anything else.  I don't think the situation would get much
better at 9600 baud either.  The multiple session capability allows you
to keep multiple contexts active, but it works best if you only do I/O
to them one at a time.

    Sorry but this is slightly off the subject, but i haven't been able
    to get a PAK for SSU under V5.0.  Could some kind soul please send
    a copy or directions to a source so that I can give WHEAT a try.
    
    
    					thanks 
    
    						wayne oakley
    
    						cgou01::oakley
    

    If YOU haven't been able to get a PAK (Product Authorization Key),
    then I assume you are the licensee for 5.0 and probably running
    it on a Workstation? If you are not the licensee, you'll want to
    contact your system manager. One of the VMS product managers at
    ZK can probably help you out if all else fails.
    
    Paul

    The 'official' way of obtaining a PAK internally is to register
    through VTX.  Under the Software Services option, you will see a
    selection for PAK. It will then prompt you for your badge #, cost
    center and facility code. Then to verify you are who you say you
    are, it asks for things like hire month, hire year... I just tried
    it a few seconds ago and was able to get the PAK for SSU.  If you
    are still having problems, send me mail, I have it on my system.
    
    
    						Jim Collum
    

I had never heard of the VTX method before.  I used the one from
VIDEO::SSU$011_KIT:SSU.PAK, which works great with the SSU011.A kit in
that directory, but expires 1-Jan-89.  Does the VTX PAK last longer?

    It expires 9-May-89. It goes strictly by termination date. There
    are no version # limitations.  My understanding is that all internal
    PAKs will use this method to prevent the 'accidental' acquistions
    by a customer.  My only problem with the VTX PAK method is that
    they give instruction to save it (PF1 5 and then SAVE/ALL at the
    COMMAND: prompt.) However from any node I've tried it from , it
    says that the screen is PRINT/SAVE RESTRICTED. I end up having to
    cut and paste (via DECWindows) in into another session. If you can't
    get at it easily, I can VAXmail it (unless someone lets me know that
    its not something I should be mailing internally.)
    
    
    						Jim
    

VTX told me that it would be a VIOLATION OF YOUR EMPLOYEE AGREEMENT to
re-distribute the PAK to other organizations inside the company.  Wether
this is true or not, they clearly don't want you to, so you shouldn't
go mailing it around.

Now, does anybody have any idea what is the proper way to register this
PAK when you already have the old one registered?  I now have two SSU
entries in my license database, and who knows which one is being loaded.

>>Now, does anybody have any idea what is the proper way to register this
>>PAK when you already have the old one registered?  I now have two SSU
>>entries in my license database, and who knows which one is being loaded.

     If the PAKS have different authorization numbers (do a LICENSE LIST),
     you can enter  LICENSE DISABLE followed by a LICENSE UNLOAD. Specify
     authorization numbers with the /AUTHORIZATION=number qualifier. If
     they have the same authorization number (it can happen internally I
     think) and it seems to be working, don't worry about it. The "product
     authorizations" just combine as if you had "bought" two PAKs.
     Actually, PAKs for the same product (same version etc.) with different
     authorization numbers will load together too. 
     
     On a workstation two PAKs for the same product is generally
     redundant, but on a multiuser system or cluster more 
     PAKs sometimes means more "use" of the product. Thus, LMF can allow
     multiple PAKs in the same license database.  Some of these features
     are not particularly relevant to the more generic licenses available
     inside DEC.
     
     Dave R.
                

    ok...havent seen much on this recently, so I thought I'd ask...
    
    is anyone using wheat?  is anyone transferring files while doing
    other work...how is it?? how is it done??
    
    just trying to stir up the water...my general impression of it was
    good, but just as a terminal emulator...I really missed the scripts
    to automatically dial in, and log me in...and I miss the file xfer...
    maybe what we need is the zmodem stuff modified to use the wheat
    port for communication...yea, thats the ticket...now if I only had
    a free moment to spare...
    
    scott

    
    I'd gladly do without scripts in exchange for cut and paste between
    all those T.E. windows.
    
    oooooooooh. wouldn't that be nice!
    
    Might this be possible?   comments?
    
    Somehow I get the impression that this may be more than a few all
    night hacking sessions  :')
    
    -bw
   

I don't know about anybody else but I only gave WHEAT three hours as it was
causing my system to crash too easily ( with no scripts, it is a pain to have
to dial back in to clean up 5 disconnected sessions ).  If my system were at
work, I would probably use it but from home with a modem, it was easier to
forward to another session or if I needed a second display, dial in on my 
wife's system.

Anybody else have better luck?

	Dick

    	I use wheat quite often, although I haven't been able to use
    the multiple sessions since the DECserver I go through is not at
    rev 2.0. But the I.S. dept. is working to upgrade it.
    	As a terminal emulator, even with just one window, it (to me)
    works much better that the vt100 and vt200 emulators. Unfortunately,
    the fact that it doesn't have file transfer capabilities limits
    its use greatly.
    
    Miguel A. Alvarez 

    I've used it once or twice, but without any file transfer capability,
    it doesn't offer me much.
    
    Regarding cut/paste. You should be able to cut and paste between
    WHEAT windows with the program SNIP. I like SNIPIT better, but SNIPIT
    will not c&p across console windows.
    
    Paul

    Re: .33
    
    Me, too.  I tried using Wheat for about an hour and a half; during
    that time my machine crashed no less than three times.  Does Wheat
    need an initial stack size larger than the default?
    
    Also, I've heard mention that you can do a download in one window
    while working in another.  I don't get this.  How can I run, say
    rz in one window and work in another?  I understand it involved
    Wheat and rz sharing the serial port, but when there are two
    intermingled streams of data coming in the port at once, who decides
    which program gets which data?  Does AmigaDOS take care of something
    like this?

    included in the arc file were some sample programs that allowed
    ONE outside program to also be sending data to the emulator via
    a message port. (my terminology may not be exact)  Then WHEAT takes
    care of "merging" it into the proper "stream"..ie to the proper
    session, which is running a sender/reciever on the VAX end...
    
    So...if we had an amiga prog to do that, it could be done...
    
    scott.