Addendum to PCPMEX.DOC 
  
                 PEEKING AND POKING through PC-PURSUIT 
 
[This was mostly written July 7, 1988 in a flush of excitement.  
Though parts are now inaccurate, it serves as a record of the 
development of my learning about MexPlus's PEEK and POKE commands 
and then adapting them so powerfully for use throughout PCP.MEX.

                                  7 August 1988 ]

I have been doing feverishly intense work on this script since 
mid-June.  Having so much fun!  Funny: I was just about to release 
to the world what I had already done as of mid-June. I was just 
putting the finishing touches on the documentation, and looking 
forward to taking a rest from it, when all of a sudden I started 
running into an interesting little problem that at this time in 
PCP's history now comes up quite frequently for those of us with 
2400 baud modems.  Most of the PCP area codes are still equipped 
only for 1200 baud transmission, but 8 PCP nodes now have 2400 bps 
capability.  For a while I paid the situation no mind.  But one day 
it hit me.  In the "LABEL NEWTON" part of PCP.MEX, the part that 
contains information specific to the Newton Centre Z-Node I had 
simply put a SET 2400 command.  The call to the local Telenet number 
is then made at 2400 bps, the connection to the Boston PCP node is 
made at that speed since Boston will accept it, and finally of 
course the same with the actual BBS.  All well and good, and the 
call proceeded normally, and I logged off from the BBS.

Next I wanted to call Ladera Z-Node in Los Angeles, so I re-ran 
PCP.MEX.  At the very beginning of the script I have a SET 1200 
command; I want it to default to that speed since most of the nodes 
are set up for 1200 only, as is Los Angeles.  I enter 'PCP LADERA C' 
-- the 'C' parameter to indicate that we are sill connected to 
Telenet and that the script should therefore NOT go through the 
routine that calls the local Telenet.

The script then disconnected from the Boston node as it should and 
begin attempting to connect to the L.A. node.  But it was here I 
noticed something strange: it was dialing very slowly.  I wasn't 
sure why.  Since with a real-time clock implemented PCP.MEX displays 
the exact time -- to the second -- each attempt to connect to a node 
is made, I know that under normal circumstances an attempt is made 
every 4-5 seconds.  In other words, the string "C D/12MABOS/USERID" 
is being SENDOUTed to PCP by the script once every 4-5 seconds.  
This is a good speed.  PCP is responding with its "BUSY" message 
once every 4-5 seconds, and then the script loops back and SENDOUTs 
the string again.  But now it was making an attempt every 20 
seconds!  Why?

I scratched my had and pondered, looked through the script, tried 
modifying some stuff, took a walk and came back, scratched my head 
some more, and picked up the phone and talked to PCP customer 
service.  These guys are usually OK though sometimes curt.  We 
worked through the problem to an explanation.  What it is is this:  
If a call to the local Telenet number is made at 2400 bps a connect 
to a remote PCP node at 1200 is problematic.  Apparently the PCP 
modems don't have the proper kind of "automatic step-down" ability 
to sense what is going on.  Consequently PCP takes a very long time 
to respond to the "C D/12 MABOS/USERID" being sent out by PCP.MEX, 
and we don't get our next "BUSY" message for a full 20 seconds.  
Something about the difference in the two bps rates is confusing to 
PCP and it doesn't understand what is going on.  It finally "gets 
it" -- but very slowly.

I have never even waited for an actual connect to a BBS under this 
circumstance but one of the PCP support personnel suggests that it 
would probably resemble 300 bps!  (This with the call to the local 
Telenet at 2400!) .  Note that this is a function purely of a 
discrepancy between the speed of the call to the local Telenet and 
the speed of the attempted connect to the remote node.  If the local 
Telenet call is made at 1200 then there is no problem connecting to 
a remote node at 1200, and our successive redials are made at the 
normal fast 4-5 second rate.

So we have an interesting situation.  For those nodes with 2400 
capability we should dial the local Telenet at 2400 but for all 
others we must make our original connection at 1200!  Though we 
might curse Telenet and PC-Pursuit for this rather primitive state 
of affairs (auto-step-down technology has been around for quite a 
while, don't you know?), I prefer to look at "problems" like this as 
merely challenges and opportunities for more enjoyable and exciting 
learning, writing, and creative experimentation.  Boy, was I right...

After much thought I have decided that the only way to deal with 
this situation is to have the script disconnect from local Telenet 
and then redial if there is a difference between the bps rate of the 
previous and current nodes.

I have therefore added the capability in PCP.MEX to do this.  It 
was't easy.  It was, however, a hell of a lot of fun!  When it 
happens it appears to the user that the script "senses" a difference 
in the baud rate, and then appropriately disconnects.  It took a lot 
of conceptualizing to figure out how to do it.  At first I thought I 
had it -- and then realized I had ignored one crucial situation: if 
the user exits MexPlus completely then reloads MexPlus WITHOUT 
RELOADING PCP.MEX SIMULTANEOUSLY ALONG WITH IT.  (I had originally 
set up two different schemes: (1) for if the user stays within 
MexPlus, and (2) for if the program is exited but the next execution 
is done from the command line.  But more on that later...)

The scheme I came up with -- at first -- is as follows.  I simply 
assigned the present baud rate to a string variable ('E') and put a 
E="12" command in at the top of the script since that still is the 
most common and therefore should be the default speed.  I then did a 
COMPare on the string variable "B" -- the one that after going to 
the BBS log-on script part of PCP.MEX contains the PCP node code -- 
to the various PCP node codes that allow 2400 bps.  If the COMPare 
was successful then I assigned E to "24" instead.  I then issued the 
command "SET {e}00".  Believe it or not this actually works!  (I had 
learned from Fowler's FIX165A.MEX that you can use the "{}" to force 
a command that normally does not accept a string variable as a 
parameter to do so.)  This sets the baud rate appropriate to each 
individual PCP node and then dials the local Telenet.

Then, with the STORE command, I STOREd "e" off into "f" so that the 
script would "remember" what this current baud rate was, and then 
compare it for the next call we make.  At that next call I did a 
"COMP E F" and if VALUE=0 then we do our disconnect.  It took quite 
a bit of coding, but the conceptualizing is simple.  And that was 
all fine and good, and I rejoiced in my victory and creativity for a 
day or so, until....

[August 6 note:  I no longer use string variables for the baud rate 
-- rc]

I realized that one of the promises I made to myself for this script 
was that it must be completely usable even after exiting from Mex 
and returning again.  While logged on to BBS's I often temporarily 
<ESCAPE> to my own computer to do any of various tasks; check for 
whether I have a file, write a message with my editor to be 
uploaded, check for disk space before downloading, etc.  This 
presented a problem, however: once you exit the program the value of 
string variable "f" would be lost -- and the previous baud rate with 
it!  Hmm... More pondering, more head-scratching, more late-night 
walks...

I remember pacing up and down my living room floor muttering like 
a madman, babbling incoherently to my roommate explaining to him 
about the problem and noticing his amused chuckling and patronizing 
bewilderment in response to my passionate proclamation of 
frustration -- as if I were someone for whom he was ready to make a 
call to the local emergency psychiatric services, when all of a 
sudden -- I have found pacing and muttering like a madman to 
whatever poor soul happens to be in the room always helps me 
generate "Eureka!" situations -- it hit me.  Good God: I know 
MexPlus has a POKE command -- did it also have a PEEK???  

It's not in the documentation, but like DO, DUPE, AND, OR, GOSUB and 
ENDP that didn't deter Ron from putting it in the program, so I gave 
it a try.   Holy CP/M!  There it was -- MexPlus displaying 16 bytes 
of memory starting at the specified address.  And, just as I suspect 
-- and more importantly, just what I needed -- it puts the value of 
that byte into the VALUE variable.  Oh great god of Irv Hoff, Ward 
Christensen, Keith Peterson and all our other forefathers who art in 
heaven: happy days are here again.

So what did I do?  After PCP.MEX determines the appropriate baud 
rate for each individual node, it then POKES into memory a "12" or a 
"24" respectively.  But where, you might ask!  Well, what do you 
think the ZCPR3 registers are for?  They're certainly not there 
because they have nothing better to do or because they like hanging 
out unused in a computer's RAM.  They're there to GO TO WORK FOR 
YOU.  As I've said time and time again one of the beautiful things 
about the ZCPR3 command processor is its ability to act as a conduit 
for programs and utilities to LEAVE MESSAGES FOR EACH OTHER.  (See 
my DATELT11.LBR for more rhapsodic exposition on this subject.)

Now for everything Ron Fowler did for the CP/M community he lived in 
a state of idolatrous ignorance in regard to ZCPR3 -- even if he was 
instrumental, as Jay has pointed out, in developing ZCPR1 -- and we 
have been bequeathed a straight CP/M, non-Z-ified MexPlus.  (By the 
way, Ron -- why don't you come on back to the fold and see what 
we've done since you left -- I don't see hordes of people flocking 
to the 16-bit MEX-PC...)  In any case, as I often do in my aliases I 
chose the ZCPR3 registers to store this information.  But WHICH 
registers?  Well, in Boy Scouts I learned to tread lightly and leave 
a gentle footprint, and generally I like exploring dark caves and 
places where others haven't gone, so I chose the registers that are 
known as the "system reserved bytes" in the ZCPR3 message area.  

Now this is funny.  If you turn to page 222 of _ZCPR3: The Manual_ 
there is a most ironic comment concerning these bytes from Rick Conn 
to us intrepid users of his system:

       The messages from Z3MSG+3AH to Z3MSG+3FH are 
       reserved for the ZCPR3 System Designer (Richard 
       Conn) and should not be used by any other person.  
       This will leave an opening for future expansion of 
       the ZCPR3 System.

Well, Rick.  From one Rick to another ... Jay Sage took the first 
tentative and exploratory steps in releasing these to the public 
when he officially made these 6 bytes -- along with the 9 bytes 
following them in memory formally known as the "user-defined 
message bytes" -- part of his $Rtnn symbol format in ARUNZ09N, 
which he originally developed only for the 10 "official" 
registers.  With the issuance of this document, then, I would like 
to register the following statement in the official ZCPR3 historical 
archives:

  ****************************************************************
  *                                                              *
  *  [Gaude's Eagle goes here]                                   *
  *                                                              *
  *  I, Rick Charnes, in the name of the general and broad       *
  *  ZCPR3-using public, in my self-assumed capacity as its      *
  *  spokesman, hereby officially RELEASE, LIBERATE and PUT      *
  *  INTO THE PUBLIC DOMAIN the six bytes of memory ranging      *
  *  from Z3MSG+3A to Z3MSG+3F formerly known as the "reserved   *
  *  message bytes", and hereby rename them "Registers A         *
  *  through F".                                                 *
  *                                                              *
  *                                                              *
  *                                        Signed with the       *
  *                                        "Seal Of The Z"       *
  *                                                              *
  ****************************************************************

With the severing over a year ago of the contract between Echelon 
and Rick Conn, these bytes may no longer to be held hostage.  The 
jail is opened, the Eagle is released, they are free to go, and we 
are free to use them as we see fit.

For more information about joining the R.B.L.F. inquire at the 
address below.

In any case, I store this information in the first byte of what 
must now be called (Jay started the tradition) "register 0a".  If 
a PCP node should be called at 2400, PCP.MEX pokes a "24" into 
this byte.  Now here run into what is actually now two problems, 
stemming from the fact that MexPlus (1) is not a Z-System utility, 
and 2) is not an NZCOM utility!  My ZCPR3 message buffer starts at 
F580 and my register "A" is therefore at F5BA.  But yours may not be 
the same!  Furthermore, with NZCOM and everything being potentially 
relocatable with any temporary new configuration of my memory map it 
may not be at F5BA at all times!  I would suggest determining where 
your ZCPR3 registers will be when using the system configuration you 
will most likely be using when using MexPlus and then plugging in 
the values from there.

MexPlus is actually a perfect candidate for NZCOM's dynamically 
configurable TPA capabilities.  If you're running NZCOM, great! -- 
then I won't have to feel like a bad programmer for writing such a 
large script.  Jeez -- life in CP/M, huh?  DOS's ProComm is -- what? 
240k? -- and I feel guilty for writing a 16k script.  Life ain't 
fair.  Though knowing how live lightly on the land is going to be a 
handy skill to have in the coming dark ages...

I must emphasize, then, that YOU MAY NOT RUN PCP.MEX under more than 
one Z-System memory configuration.  These POKEs and PEEKs are 
hard-coded.

In any case, once I saw how MexPlus's PEEK and POKE commands worked, 
I quickly adopted them for use for many purposes throughout the 
script, as you can see.  I find it perfectly in the Z spirit of 
programs leaving gentle messages for each other (or here, for 
itself!)

Thus ended my saga of POKEing and PEEKing through MexPlus...