[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference hydra::amiga_v1

Title:AMIGA NOTES
Notice:Join us in the *NEW* conference - HYDRA::AMIGA_V2
Moderator:HYDRA::MOORE
Created:Sat Apr 26 1986
Last Modified:Wed Feb 05 1992
Last Successful Update:Fri Jun 06 1997
Number of topics:5378
Total number of notes:38326

1450.0. "Meshugena Terminal Emulator" by VIDEO::LEIBOW (Michael Leibow) Tue May 31 1988 20:59

    NEWS:  When I went back to school, I had given up smokey.  After
    I was there for about a week, I realized that I just needed a better
    terminal then the old VT100 2.4 which Smokey was based on.  So,
    not having the executable or sources for Smokey, I started a new
    terminal from scratch.  I now have V1.0 of "Meshugena."  Meshugena
    is a much much much better VT220 emulator then Smokey ever was.
    The main reason it is better is because the code is re-entrant and
    can do multiple sessions with the "Unix Windows" protocol developed
    for the macintosh circa ?1985?.  It also does some of the more bizarre
    modes correctly (origin mode).  I have a public domain version
    that I will post here when I can get my machine hooked up to a phone
    line again.
    
    Meshugena in many instances is better than Smokey, but is a step
    back in others.  It has no graphic protocols (regis, sixels, tek,
    etc).  It also has a cruddy keyboard driver.  I am working on an
    emacs style keyboard driver where you will be able to redefine keys
    whenever you wish.  Some of the improvements are: Multiple session,
    I/O control from another process, transcript buffer, scroll bars,
    cursor coupling, and the startup file is pretty complete.  Some features
    that need to be added : completely redefinable keyboard in terms
    of an LK201, SSU compatibility, cut-and-paste (clipboard), file
    transfer, script control, photo sessions, whatever else you can
    think of.
    
    The I/O control mechanism is probably underdeveloped but I think
    it is a good start.  When Meshugena starts up, A command port is
    created.  Another process can do a "findport()" to get the address
    of this port.  This process then starts the conversation with Meshugena
    by sending an INIT command.  After that, the process becomes the
    control process.  All Meshugena I/O (keyboard, serial) must go through
    the controlling process' reply port before it can get displayed
    or sent over the serial line.
    
    You may ask, "why did he do this?"
    
    Because:
    This is an excellent way to do file transfer and script control
    without wasting tons of memory.  Most programs have all of the code
    sitting in memory.  My attempt was to free space by doing it from
    a different process.  So, when you need to do a file transfer, you
    can start another process from workbench that has your favorite
    file xfer protocol.  Also, I don't have to write all of the code.
    If I leave again (3 months), now you can write your own extra features
    without changing the original code.  If someone can send me the
    source code for kermit (the real one with a command line interface)
    I will make it work as a controlling process for Meshugena.  Then,
    you would start meshugena and then kermit.  The session would like
    something like this:
    	KERMIT-Meshugena> set session 1
    	KERMIT-Meshugena> connect
    
    and then you could use session one.  WHen you have the remote kermit
    in server mode, you would hit some gadget that would bring the local
    kermit back into command mode:
    	KERMIT-Meshugena> put file1
    
    And while the transfer is taking place, you could start another
    session and do something else.
    
    Another thing you can do with the I/O control is emulate other
    terminals.  All you have to do is write a parser which translates
    the non-dec stuff into dec-stuff.  I have already written a televideo
    925 translator for a crappy machine at school.  It worked great.
    
    ideas anyone?
    
    	--Mike Leibow (glad to be back)
    
    
    
T.RTitleUserPersonal
Name
DateLines
1450.1addendum .-1VIDEO::LEIBOWMichael LeibowTue May 31 1988 21:282
    I forgot: can use any fonts you like.  Comes with 80 and 132 column
    clean type fonts.
1450.2ADODEM::MCGHIElooking for a door...Wed Jun 01 1988 09:128
    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...)
1450.3Bursty???FSDEV1::JBERNARDJohn Bernard YWO/292-2591Wed Jun 01 1988 12:1017
    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
    
1450.4Oh neat.PRNSYS::LOMICKAJJeff LomickaWed Jun 01 1988 13:462
Hey Mike, wanna talk TDSMP?  I'm hunting for your phone number now...

1450.5VIDEO::LEIBOWMichael LeibowWed Jun 01 1988 14:0117
    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
    
1450.6spamVIDEO::LEIBOWMichael LeibowThu Jun 02 1988 03:284
    Check out VIDEO::ENG$7:[LEIBOW.AMIGA]MESHUGENA.ARC;1
    
    	--Mike
    
1450.7slow?VIDEO::LEIBOWMichael LeibowTue Jun 14 1988 21:079
    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
    
1450.8How's the patient, Doctor?ODIXIE::MCDONALDSurly to bed, surly to rise...Wed Aug 03 1988 16:1318
1450.9been real busyVIDEO::LEIBOWMichael LeibowThu Aug 04 1988 20:3029
    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
    
1450.10Uh-Oh! Bugcheck....ODIXIE::MCDONALDSurly to bed, surly to rise...Fri Aug 05 1988 03:316
    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
    
1450.11squashVIDEO::LEIBOWMichael LeibowThu Aug 11 1988 03:2021
    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
    
1450.12SMPVIDEO::LEIBOWMichael LeibowMon Aug 15 1988 09:2323
    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.
1450.13I need keyboard informationVIDEO::LEIBOWMichael LeibowWed Aug 17 1988 11:3411
    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
1450.14New Terminal EmulatorsVIDEO::LEIBOWMichael LeibowThu Aug 18 1988 22:4721
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.
    
1450.15Can't be foundPUERTO::ALVAREZMiguel,from sunny Puerto RicoFri Aug 19 1988 12:1616
>    < 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.
1450.16MTWAIN::MACDONALDWA1OMM 7.093/145.05/223.58 AX.25Fri Aug 19 1988 14:547
    Both files are available on
    
    PAULY"AMIGA"::
    
                  WHEAT.ARC
                  MESHUGENA.ARC
    
1450.17Whack for the Amiga!PRNSYS::LOMICKAJJeff LomickaFri Aug 19 1988 15:2057
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.

1450.18MTWAIN::MACDONALDWA1OMM 7.093/145.05/223.58 AX.25Fri Aug 19 1988 17:031
    Why ?AJ?AJ?AJ? I don't receive that junk on my VT340.
1450.19If you have a VT330, you don't get junkPRNSYS::LOMICKAJJeff LomickaFri Aug 19 1988 19:1314
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.


1450.20MTWAIN::MACDONALDWA1OMM 7.093/145.05/223.58 AX.25Sat Aug 20 1988 05:061
    Okay .. what happened to Kermit and Amiga 2000 keymaps?
1450.21X & Y & ZTEACH::BOBBob Juranek EKO/339-4312Sun Aug 21 1988 16:181
    And {X,Y,Z}MODEM???
1450.22Thanks!RLAV::WEGERBruce WegerMon Aug 22 1988 00:4014
    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. ;')
    
1450.23VMS TD/SMP, File transfer while reading mail?PRNSYS::LOMICKAJJeff LomickaMon Aug 22 1988 15:1250
>    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.



1450.24SSU PAK???CGOU01::OAKLEYWhat am I doing here...Fri Aug 26 1988 04:0011
    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
    
1450.25MTWAIN::MACDONALDWA1OMM 7.093/145.05/223.58 AX.25Fri Aug 26 1988 12:487
    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
1450.26Try VTXWINERY::COLLUMFri Aug 26 1988 16:2611
    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
    
1450.27Oh, neatPRNSYS::LOMICKAJJeff LomickaFri Aug 26 1988 19:014
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?

1450.28But you need a workstation for it to work...WINERY::COLLUMFri Aug 26 1988 23:3914
    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
    
1450.29More PAK problemsPRNSYS::LOMICKAJJeff LomickaMon Aug 29 1988 17:389
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.

1450.30STAR::ROBINSONMon Aug 29 1988 22:1022
>>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.
                
1450.31whats been happening with wheat recently??PCCAD7::BAEDERD. Scott DTN 237-2961 SHR1-3/E19Tue Sep 13 1988 22:4613
    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
1450.32Cut & Paste?RLAV::WEGERBruce WegerWed Sep 14 1988 01:1813
    
    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
   
1450.33WHEAT = many GURUsMANTIS::LONGWed Sep 14 1988 12:4611
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
1450.34Great as emulator, but...PUERTO::ALVAREZMiguel,from sunny Puerto RicoThu Sep 15 1988 12:179
    	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 
1450.35MTWAIN::MACDONALDWA1OMM 7.093/145.05/223.58 AX.25Thu Sep 15 1988 14:508
    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
1450.36Crashes a lot on me, tooVTHRAX::KIPNo Dukes.Fri Sep 16 1988 21:0613
    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?
1450.37SSU takes care of who gets what data...PCCAD7::BAEDERD. Scott DTN 237-2961 SHR1-3/E19Fri Sep 16 1988 21:2210
    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.