CP/M/CPM_CDROM.iso/jsage/znode3/z3doc/mex2z.azt/MEX2Z.ART

Text File | 1993-06-07 | 5.9 KB | 102 lines

SETTING THE BAUD RATE WITH MEX2Z
by Rick Charnes, San Francisco, 9/20/87

    I'd like to share with fellow Z users the solution I created to a
problem I was having with the superb MEX2Z, the program by Bruce Morgen
and Jay Sage that gives Mex or MexPlus the ability to run as a "virtual
shell," i.e. to execute a ZCPR3 command and then automatically return to
itself.  The problem is described by Jay on p. 20 of the ZCPR33 User's
Guide.  For those who aren't familiar with it...

    The way MEX2Z works is as follows.  Suppose I want to exit MEX, edit
a file called JOE.LTR with VDE and then immediately return to MEX.
Rather than having to completely exit MEX, wait till returning to the Z
command line, and then entering commands, instead at the MEX command
line I can simply type 'CPM VDE JOE.LTR'.  Although 'VDE JOE.LTR' is of
course completely incomprehensible to MEX itself as they are not MEX
commands, we have created an alias in which MEX2Z.COM is invoked next.
This picks up in memory the "trace" left behind by this MEX command line
and sends it to ZCPR3 for execution.  After this is run MEX2Z supplies
the command line ';MEX' which is now reinvoked and we are back to where
we started; a very nice shell.

    MEX2Z's ability to pick up this trace is fine for MEX command line
text, because it is left in memory * above * where MEX2Z runs so the
latter program can get to it.  Suppose, however, the information we wish
to restore from MEX is located in LOW TPA which is normally overwritten
by MEX2Z, or by any other program for that matter.  And it so happens
that the particularly information I want from the previous execution of
MEX -- the baud rate at which it was running -- is indeed kept in the
first record of memory.  I use PC- Pursuit to call Z- Nodes across the
country.  As of yet Telenet does not have it set up for 2400 baud
communication, so I have to run my Courier 2400 modem at 1200 when I use
this service.  When I am making local calls, however, I am free to gun
my accelerator to the max at 2400.  I have a *.MEX script file ("read"
file) containing a menu, login ID's and other information for each of
these two applications -- one for local 2400 calls and one called
PCP.MEX.  In each script file I set the baud rate appropriately, but
when MEX2Z reinvokes MEX it re-loads the program anew from its default
baud rate.

    How to deal with this problem?  Well, one solution pointed to by Jay
in this section is create a type-3 MEX2Z that will run at 8000h, high
above this information that we want.  But my knowledge of assembly
language is about as extensive as Bill Gates' knowledge of ZCPR33.  I
did nothing but get frustrated about it for a month or two, simply
trying to remember to do 'SET 1200' or 'SET 2400' as appropriate after
MEX2Z loaded MEX for the second time.  But then an idea came to me.

    I have the commercial MexPlus (easily the most exciting non-ZCPR3
program available for CP/M computing) and it has a (seldom-used) POKE
command.  The only time I've ever seen it used from within a script file
is when its author Ron Fowler releases a bug fix.  Ron very cleverly
writes his bug fixes as ... MexPlus script files!!  Using a program to
fix itself is clever.  This POKE command does exactly what the ZCPR3
POKE command does -- it changes a byte in memory.  So I started thinking
about ZCPR3 registers and the superb feature of our operating system:
the ability of sequential tasks to leave messages to each other.  I
settled on an out-of-the-way ZCPR3 register, number 6, which in my
system is located in memory at F3B6.  In my MEX read file for 2400 baud
calls I included a line 'POKE $F3B6 24' and in PCP.MEX 'POKE $F3B6 12'.
Here we are able to get a non-Z program to feed information to ZCPR3.  I
made a second copy of MEX2Z.COM and named one MEX2Z24.COM and the other
MEX2Z12.COM so their respective functions would be easy to remember.  As
an ASCII patch at the top of MEX2Z.COM you write the text of the command
line you would like it to re-execute after it exits.  I simply entered
the text ';MEX SET 1200' in MEX2Z12.COM whereas in MEX2Z24.COM I put
';MEX SET 2400'.  I've renamed MEX.COM to REALMEX.COM.  My alias that
runs the whole shebang is:

   MEX realmex;resolve if eq $$r6 24;mex2z24;else;mex2z12;fi

When I run at 2400 baud my script file pokes ZCPR3 register #6 to 24.
Then when REALMEX.COM exits, the flow control checks the register, sees
its value and runs the appropriate version of MEX2Z, which returns the
favor by reloading MEX at the appropriate baud rate.  Note that RESOLVE
is necessary here.  Remember that ARUNZ builds its command line and sets
the values of any of its parameters such as '$Rn' and '$Mnnnn' _at the
moment the alias is invoked._  None of the values that will be changed
by the operation of the alias have yet taken into effect.  At the moment
this alias is invoked my MEX scripts have not yet POKEd those memory
locations, hence the value of register 6 returned by the alias would be
the incorrect one.

    There are two ways to deal with this situation.  The one used here
is to preface the operation with the symbol in question with RESOLVE.
Note that the '$r6' symbol then becomes a parameter of RESOLVE.  Since
in an ARUNZ script we must enter '$$' to produce a '$', hence the need
for '$$r6' to provide the '$r6' symbol for RESOLVE.COM.

    The other solution would be to make two aliases out of it, as in:

    MEX realmex;mex2
    REALMEX2 resolve if eq $$r6 24;mex2z;else;mex2z12;fi

    Ah, the multi-colored wonders of Z...

                                          Rick Charnes
                                          San Francisco
                                          [phone]
ck Charnes
                                          San Francisco
                                          (415) 826-