Date   : Wed, 24 Nov 1982 20:18:41 PST
From   : Lauren Weinstein <vortex!lauren@Lbl-Unix>
Subject: CP/M 3.0, continued.

I appreciate Tony's message about 3.0, but it leads me to suspect there
is still alot of confusion about 3.0 flowing around.  First of all,
the D.R. Graphics PACKAGE is, as far as I know, a completely separate
offering from CP/M itself, and in fact does conform to certain
graphics standards.  The rumors I was addressing were the ones
that said "... and CP/M 3.0 will support graphics".  This implies that
a graphics package is PART of 3.0, which I have no reason to believe
to be true.  In fact, Tony DID say that the graphics package was 2.2
compatible.  So I guess we've laid *that* rumor to rest.

Let's review what we know about CP/M 3.0 to date:

(I do not claim this to be an unbiased view, as will rapidly become
clear):

1) Provides more "menu-oriented" features/help command.  
   -- probably good for SOME OEM's but probably inadequate for most
      users, or at least unwanted by many.  Probably aimed at the
      turnkey business market.

2) Automatic searching of USER 0 if program not found on current
   user area.  
   -- what an advance!  ZCPR has provided this sort of functionality,
      and MUCH, MUCH more, for free, for a long time.

3) Disk blocking/deblocking moved to BDOS.
   -- this is a feature???  D.R. only claims "functional" compatibility
      between 2.2 and 3.0.  I suspect there are some assumptions about
      the sophistication of your programs -- I'd bet any reasonable
      amount that ALOT of heavily used programs will not work without
      modification under 3.0.  

4) Some sort of date/time stamping.
   -- reasonable I suppose.  Most other systems have provided such
   a feature all along.  Whether it is sophisticated enough for
   easy interfacing to different sorts of clocks, etc. is another
   matter.  See, I am TRYING to be fair!

5) Some sort of file I/O redirection.  Gee, just what Microshell
   does now!  Why do I get the feeling that there will be some
   sort of restrictions to redirection, like, maybe only BDOS
   output (not BIOS output) will work properly with redirection?
   (We had to do both for MARC and it was a PAIN.)

6) Memory Usage.  Now we get to the real nitty gritty.  Supposedly there
   will be two versions of CP/M 3.0.  One for people without bank-
   switched memory and one for people with additional memroy.  If you
   are running a simple 64K system, the *other* features of CP/M apparently
   take up at least another 4K from standard 2.2.  (We know that these
   features must be coming from somewhere, and obviously you can no
   longer overlay that portion of the BDOS which has the disk blocking/
   deblocking code unless you a running a very simple program.
   
   If you have more than 64K memory, and someone to figure out how
   to interface it with your new 3.0 bios (apparently D.R. has NO
   interest in helping other than large, turnkey-type OEM's with
   such support), you can let the system reside in a different
   bank of memory, and give yourself a larger TPA.  Also, apparently
   you use the additional memory in such a manner as to provide the
   same "sort" of functionality that FAST/SPEED have provided under
   1.4 and 2.2 to do reasonable disk buffering.  How well this works
   under the D.R. implementation, or how difficult it is to interface,
   remains to be same.  I'll bet that > 64K memory bioses are a real
   PAIN to get working right, and will be very highly system dependent.

   The idea of having a larger TPA sounds nice at first, unless you
   consider having any sort of compatibility with 2.2 to be
   important!  If you plan to write programs that will still run under
   2.2, you will still be restricted to the "standard" size TPA's,
   and there are one hell of alot of 2.2's out there!

I claim that the bottom line remains the same -- 3.0 has been oriented
almost totally toward the OEM who plans to run many "identical"
systems (or nearly so), and doesn't mind a very complex bios since
there is only one hardware configuration to worry about.  The fact
that D.R. has told non-OEM's to "go away" when it comes to 3.0 is
highly suspicious.  I won't even drag up the issue of documentation
quality again... we all know about that.  The issue of CP/M 2.2
compatibility is also less important to such OEM's since, often they
will just be running their own collection of programs on their hardware,
and won't even try to distribute their software more widely.

---

In answer to a number of questions I've received, I'm hoping to get
MARC out in some form quite early in '83, and I will take a look
at the issues of CP/M 3.0 compatiblity.  But, frankly, I don't
consider it to be a priority task.  In fact, I don't know if I really
want to take the time to get my complex hard disk/floppy bios running
under 3.0!  If I use the bank-switched version, I've got system
dependencies again, and if I use the the non-banked version, I lose
4K off the top!  Neither of these options is particularly appealing.
For now, MARC will be a 2.2 compatible product, period.

By the way, I've been "warned" that there will be some sort of review
of MARC in the December BYTE (apparently as a text "box" included in the
review of two other software products).  The person who wrote the
article is one of the beta test sites -- though he has not had the
most up-to-date version of the system or utilities by any means.
I think he wrote the article about eight months ago and it has 
taken until now to get into print!  Anyway, it might be amusing
reading.  I *hope* it's amusing...

--Lauren--