SAGE@LL.ARPA.UUCP (06/04/87)
Peter Teuben's comments about the ZCPR33 release that appeared today
over the network finally got me to sit down and compose this message. These
comments are in no way addressed specifically to Peter; his remarks simply
provided the impetus for me to collect these thoughts in writing. Although
I follow the INFO-CPM exchanges on the DDN, I do not spend much time
contributing to the discussion. My work with 8-bit computers is almost
entirely a personal-time activity, and I try to avoid spending time at work
on it. For those of you who do not know, in real life I am an ANALOG device
physicist, always trying to show that only analog devices, and not digital
ones, can solve the world's really pressing signal-processing problems.
Right now I am working in two areas: analog focal-plane image preprocessors,
chips that use the same devices (CCDs for example) not only to capture an
image but also to figure out what it means (an artificial retina, to put it
in grandiose terms); and artificial analog neural network chips, integrated
circuits that function in a simplified brain-like way to perform
associations and to recognize patterns.
First of all, I hope everyone has seen my message about the files on
SIMTEL20. In brief, those files were NOT authorized versions. They were
beta-test versions that were improperly sent to Keith Petersen. I do not
know for sure, but they may contain code that is not up to date, code that
will malfunction in subtle ways with release versions of system segments and
utility programs.
Second, on the matter of the assembly-language format. The release
files are in a format that permits assembly with Echelon's ZAS assembler.
Bear in mind that ZCPR33 is a COPYRIGHTED COMMERCIAL product. Its release
for personal, noncommercial application at no cost is a privilege, not a
right. Understand that Echelon is trying to stay in business so that all of
us can continue to benefit from further developments. Without Echelon, I
think it is quite likely that ZCPR, if not 8-bit computing in general, would
come to an end. Some of you know that Echelon and I have not always been on
the best of terms. It is not my love for Echelon but rather our common
purpose in advancing 8-bit computing that has brought us together.
One of the famous sore points between me and Echelon concerns the ZAS
assembler and, among other things, its idiosyncratic use of square brackets
where standard assemblers use ordinary parentheses. Nevertheless, I
understand that it is not only reasonable but entirely appropriate that
Echelon products, like ZCPR33, be capable of assembly using THEIR assembler.
I personally use the highly professional assembly-language tools from SLR
Systems and adjust for ZAS compatibility when the development is complete.
Fortunately, Steve Russell (SLR) was kind enough to make his tools accept
ZAS-format expressions, which greatly facilitates this process. ZAS, by the
way, is currently undergoing a significant upgrade (by a different
programmer), and I have good reason to believe that my objections to it will
soon be corrected and that it will become an acceptable product that will
function particularly nicely in a Z environment.
With ZCPR33 we made a conscious decision not to be tied to the
limitations of the 1970s-vintage CP/M. Six-character labels may have been
reasonable in the early days of computing, but that is no longer the case.
We have worked very hard to make the ZCPR33 source code extremely readable
and educational. It is carefully organized and heavily commented. Using
meaningful labels makes the code easier to understand and maintain (if
anything, the labels are probably still too short). We have also dropped
support for 8080/8085 processors and made free use of highly efficient
Z80-specific opcodes. This includes not only the commonly used relative
jumps but also word subtraction, direct double-register transfers, block
moves and compares, and the alternate register set.
What about those people with older assembly-language tools or computers
with 8080 or 8085 processors? The basic answer is that the ZCPR33
COMMERCIAL PRODUCT does not support them. The market does not justify the
work required to do so. For users, there are two solutions. First of all,
I think it is entirely reasonable for someone to spend $69 for ZAS/ZLINK or
$50 for the SLR Z80ASM or SLR180 assembler (plus $50 for SLRNK if they want
a linker, too) so that they can take immediate advantage of the released
code without significant effort on their own part. If they do not wish to
do so, the source code is there, and they have the alternative of spending
their time to make whatever conversions are required. The same comment
applies to conversion to work with Intel microprocessors.
Converting the code to work with M80 or ZASM (the copyrighted Cromemco
assembler) is actually rather easy for those who are expert at using those
assemblers. A number of my beta-testers did it quite regularly (though I
wondered why they were willing to waste their time when they could be using
Z80ASM with its five-times speed advantage). The files can most likely be
adapted to Z80MR as well, though I don't know of anyone who has done it
already. Files will undoubtedly appear in due course (from the user
community) that will describe the procedures in detail or even perform them
semi-automatically (using SUBMIT or ZEX scripts). Some owners of 8085-based
computers may even have the necessary motivation to put in the time to
develop 8080 versions of the code, as Charlie Strom did for ZCPR2.
Installing ZCPR33 on a system that is currently running ZCPR30 is
extremely easy (provided, of course, that you have a suitable assembler).
No changes in the memory map are required; the ZCPR33 command processor is a
simple drop-in replacement for ZCPR30. Highly detailed procedures,
including some new techniques that take advantage of existing ZCPR3
facilities, are described in the ZCPR33 User Guide available from Echelon
(while the code has been released for personal, noncommercial use, the
documentation will be available only in printed form).
This brings me to an important general comment. I have enjoyed working
in the 8-bit world, despite the rip tide sweeping people in the direction of
'DOS' machines, because I like the values and attitudes in the community
much better than those I perceived in the 16-bit world. Programmers in the
8-bit world freely shared their source code and their ideas so that the
talents of the entire community, and not just those of a single programmer,
could be brought to bear on a given program or problem. This is good.
But there is a bad side aspect to the attitudes in the 8-bit world.
Too many have come to assume that they have a RIGHT to receive everything
for free -- both the programs themselves and instruction and help in their
use. I recently experienced an extreme example of this when one of the
users of my Z-Node kept calling me on voice with questions, for hours at a
time, during the most critical period of ZCPR33 development. I finally lost
patience with this person when he starting asking for help using Z80ASM,
which I knew he had not paid for but had stolen. His attitude seemed to be
that because of HIS GREAT INTEREST in 8-bit computing he had a right to ask
for all this free consulting time.
The trouble with this attitude is that without adequate financial
compensation to those programmers who spend exceptional amounts of time
developing programs, there will be fewer and fewer programmers developing
significant new 8-bit programs. We will then all be complaining that the
trouble with CP/M is that there are no new application programs available!
If we refuse to spend even modest sums of money to purchase programs and if
we illegally copy them, then to be sure no more will be developed.
Programmers will turn to the 16-bit world. As a general rule, the software
products offered by Echelon, SLR Systems, Plu*Perfect Systems, and the few
other remaining producers of CP/M-compatible software (and hardware) are
very reasonably priced. I stronly encourage people to support them (and
have been doing so since long before I found myself on the other side of the
fence as a member of the Echelon team).
My case is a simple example of this. Unlike the people at SLR Systems
or Echelon, who devote full time to their activities and have to support
themselves on the income from them, I do programming in my spare time,
largely for the fun and challenge of it. The development of ZCPR33 from my
experimental ZCPR315, however, took about three and a half months of full-
(spare)time work, typically from middle evening until one or two in the
morning. Unless that effort realizes some 'spending' money that my whole
family can enjoy, there is no way I will be able to devote that kind of
energy to further developments. So much for the soap box.
One final comment. Many further developments are still anticipated,
not only for the 64180 and Z280 processors (the ZOS operating system) but
also for the Z80. I have actually started work already on ZCPR34 (any
suggestions?). The RCP package that was released with ZCPR33 is far from
finished (actually, it was very little more than RCP145, the experimental
version that complemented ZCPR315). If things go well with this first
release, there will be many follow-on developments appearing at a rapid
pace.
Jay Sage
June 4, 1987