Date   : Thu, 24 Apr 1986 16:04:13-MST
From   : Rick Conn <RCONN@SIMTEL20.ARPA>
Subject: Re: Zsys

Paul, Re your message ...

"... I noticed that each file starts with
LXI H,SYSENV ;pointer to sys env
CALL ???INIT ;init for program
and I assume that it is the address after the LXI instruction that the
install program fills in.  If this is the case then why not replace that
code with
LHLD zero_page_pointer_to_SYSENV
CALL ???INIT
this would mean that the tools could be run WITHOUT (re)installing!
It seems to me that this would be a big plus for people that have many
systems, or that load systems of different memory sizes.  A side feature
would be that you could load more than one ENV table for debugging or
what ever and just have to change ONE pointer to use the other one."

       -- Your suggestion would be nice, but there is a problem in
that there is no "free" space on page zero which would provide two
bytes (or even one byte for a page address) that can be guaranteed to
be free in all CP/M implementations ... note that the "standard"
external path location is a variable since some implementations use
this area for BIOS constants; take heart, tho, for in ZCPR 3.3 (the
new version which will go into beta test soon), there are many radical
differencences, one being that the tools do NOT require installation
(the address of the ENV is passed in HL from the ZCPR 3.3).

"Also I was wondering why there was a POINTER -in- the ENV_table that points
to the WHEEL_byte instead of the actual WHEEL_byte itself?  This would save
one byte in the ENV and free up the zero_page entry for something else
(maybe the pointer to sys_env), and it would also save programs from having
to index to get to the wheel_pointer then index to wheel from the pointer.
I thought that maybe this was because many programs have the wheel address
"hard-wired-in" but can't think of any that use wheel that don't allow
you to change the address...  This change would also mean that this would
no longer be necessary for Z-systems, while everyone else could still
patch as always."

       -- Two years ago, when I completed ZCPR 3, I was concerned
with having TWO wheel bytes on a RAS (Remote Access System) - one
wheel byte which was implemented by some other user software, and one
for the ZCPR3.  With the evolution of ZCPR 3.3 into an os/comm system,
of which I have total control, this concern is gone, and ZCPR 3.3 now
has a Wheel BIT in the ENV as well as a variety of access control bits

"I sure think the idea of non-installed tools is a great hack!
So what did I miss, you're far too great a programmer to have passed this
up with out some good reason."

       -- non-installed tools are now common under ZCPR 3.3, as well
as built-in CM; you should try to come to my talks (like the one I
just gave at Trenton, which was packed) - lots of details are coming
out there and in planned articles as well as Z-News; ZCPR 3.3 forms
the basis for ZCPRB3 (Banked ZCPR3) and ZCPRM3 (Multitasking ZCPR3),
so the non-installed tools are here to stay, as well as the new CM
system and communications system attributes of the Z System

               Rick