MathGroup Archive 1992

[Date Index] [Thread Index] [Author Index]

Search the Archive

sending MMA graphics to a PC

  • To: mathgroup at yoda.physics.unc.edu
  • Subject: sending MMA graphics to a PC
  • From: xinwei at otter.stanford.edu (Sha Xin Wei)
  • Date: Wed, 19 Feb 92 18:24:07 PST

[ Here's unsolicited but perhaps useful information. 

Sha Xin Wei
Stanford Mathematical Software Users Forum]

>From: mark at relgyro.Stanford.EDU (Mark Jacobs)
Subject: MMA graphics to PC

I found two ways to get MMA graphics to display on a PC over SUNet [university ethernet].
I thought I'd tell you so you can tell other people who might be
interested.  The computer consultants at Sweet Hall [Stanford], particularly a guy
named Aaron and another whose name I don't know, gave me the general
procedure and I hammered out the details on my own.  It would take
forever to go into all the details, so from here on I'm going to
pretend that whoever is interested has read the documentation
associated with what I'm going to describe, and can figure out how to
apply what I say.

Cf: mark               Thu Jan 30 10:21   21/651   MMA graphics on PC
    xinwei at otter       Tue Feb  4 14:37   54/1566  graphics to PC
    xinwei at otter       Tue Feb  4 15:19   36/1403  graphics on a remote PC

---------------------------------------------------------------------------
 

EQUIPMENT:
Hardware: PC with graphics display (CGA, EGA, VGA...) with an ethernet
          card.
Software: WIN/TCP and/or MS-Kermit 3.xx.  If you get an ethernet *packet*
          (as opposed to device) driver, as described in the Kermit
          documentation, Kermit can handle things on its own.  (But see
          below in the part about WIN/TCP.)


KERMIT:
Kermit is configured to emulate a vt100, with Tek graphics enabled.
That means that it will switch to Tek emulation when it starts
receiving Tek control codes.  This is better than emulating a Tek all
the time, because you have separate text and graphics screens and can
toggle between them.

I found the most difficult part of the process to be getting Kermit
configured properly.  Probably the easiest thing to do is just
include a copy of the relevant lines in the init file (mskermit.ini):

    set port bios1
    set flow none
    set handshake no
    set send packet-length 500
    set receive packet-length 500
    set key \270 \008 ; bksp key = ^H
    set key \324      ; don't translate F10
    set term vt100    ; default is vt320
    set terminal graphics vga

The default settings for everything else should be ok.  (In particular,
Tek graphics is enabled by default.)  The crucial line is the one "set
port bios1" -- this is what makes Kermit behave like a terminal
emulator on top of telnet.  (The people at Sweet Hall told me about
this.)


WIN/TCP:
Assuming you've got WIN/TCP up and running, when you want to make a
connection you tell telnet to use kermit as a terminal emulator instead
of the default, vt100.exe:

	telnet -e kermit.exe otter

It goes like this:
1. You type "telnet ..."
2. Connection is made, Kermit starts and reads its init file.
3. You tell Kermit "connect" (maybe in the init file).  It won't
   do this automatically.
4. Now you're talking to the remote machine.
   Alt-- toggles text and graphics screens.
   Alt-X gets you back to the Kermit prompt, and from there you can
         get to DOS and WIN/TCP finger, lpr, ftp, etc.  Then "exit"
         (to the DOS shell) and "connect" (to Kermit) brings you back.
5. Log out from remote machine -- use Alt-X to get Kermit back, and
   then type "quit".  You're back to DOS.  (telnet quits on its own.)

Unfortunately you lose the ability to run multiple sessions.  My
solution to this is to use a Unix program called "screen" to handle
that on the other end.  In any case, you still have access to the other
goodies like lpr, finger, ping, and ftp that WIN/TCP provides on the
PC, by suspending Kermit.  That's why I prefer this way to using
Kermit with the packet driver.


MATHEMATICA:
On the MMA end, you just have to tell it what you're up to by putting
"<< Tek.m" in your init.m file or something.  Also note that "tekps"
must be available to sh, since MMA calls it to do the translation from
PostScript.  An aside: MMA also knows how to send graphics to a VT320,
which Kermit knows how to emulate as well.  The translator in this case
is "vtps".  I haven't gotten this to work yet, though, 'cause I can't
find all the files MMA needs.  It would be nice to see if you can get
gray scales this way; the Tek doesn't do that, of course.  (Surface
graphics with the Tek emulator are kind of ugly.)

--------------------------------------------------------------------------
 

There it is.  I think that's enough for other people to figure it out.
In fact, I don't see any reason why this procedure wouldn't work over a
modem (using Kermit in the normal way) as well.  Graphics would just be
a bit slow.  You might want to tell the folks at WRI.  This seems like
something a lot of people would like to know, but I don't know how to
disseminate it.

-- Mark









  • Prev by Date: Front-end sluggishness
  • Next by Date: Ray Tracing Interfaces
  • Previous by thread: Front-end sluggishness
  • Next by thread: Ray Tracing Interfaces