Date   : Thu, 23 Sep 1982106:06:00-PDT
From   : lauren@Rand-Unix
Subject: MARC comments

Thanks for your comments.  I can address your points as they reflect
on the current state of the software...

1) Booting.  No matter what you do, booting is a difficult problem.
   I've spent alot of time looking at this issue, and
   so far have found no "universal" way of allowing users to patch a 
   bootable image into their system tracks -- particularly when they
   have other than single-density 8 inch disks.  There are just too
   many variations.  Yeah, given alot of implementation info and a
   wizard, it could be done for any given system, but I don't see how
   to automate the process.  I have the code here for a coldstart MARC
   loader that does part of the work... but it's not enough.  Frankly,
   I can't see spending much more time on this issue until I'm sure
   that the parasitically booting version comes up on everyone's machines!
   There are so many variations that coming up with *anything* that can
   boot *somehow* has been enough work.  Once I see how the initial
   MARC does in mass distribution, I can start worrying about cold
   booting again.  One thing at a time.

   By the way, the MARC boot program, called MBOOT, allows the user to
   customize (with SID or DDT) for default selections of root device,
   reserved memory, and a bunch of other parameters.  These can all
   be overridden by command line options, of course.  MARC takes
   considerable pains to make rebooting a rarity unless you manage
   to totally wipe out the kernel... all "obvious" parameters such
   as pseudo-interrupt traps, control-chars, and the like are reset whenever
   a program terminates (or at user logoff, as appropriate).


2) CP/M 1.4 vs. CP/M 2.X.  No worries there.  I have finally dropped support
   for 1.4 systems and MARC now assumes a 2.X-type system for all operations. 
   Since it derives all its info from the disk parameter tables and uses
   seldsk for disk operations, it should work properly on all legit
   BIOSes.  I know that it has come up under several complex hard disk/floppy
   bioses without any difficulty, and with no "customizing" in the usual 
   sense.  The CP/M emulator attempts to handle all "reasonable" calls to
   the CP/M 2.X type functions.  There are a couple that don't make sense
   in the MARC environment but very few programs ever use them anyway.
   There are some limitations on file size and such under the emulator, but
   these should not normally be of any concern.  The emulator is not
   perfect, but it tries.

3) Display support.  As far as I'm concerned, this does not belong in the
   operating system.  A Berkeley termcap type system would be nice, but
   I sure don't have the time for it now... particularly since no existing
   programs would be using it!  Such an item might be added to Leor's
   wish list of things to add to BDS C generally, but I don't think it
   should be MARC specific.  MARC does have a stty option for console
   type that could be used in conjunction with such a feature if it
   ever appeared.  Maybe some nice info-cpm reader will take it upon
   him/herself to write such a package.  Berkeley termcap is public
   domain, but is rather large.  Any individual effort should at least be
   able to make use of the existing Berkeley /etc/termcap database and
   should be compatible with the formats in that database.

That's about it.  Frankly, my biggest concern now is regarding CP/M 3.0.
I have a sneaky hunch that support for MARC under 3.0 may be difficult
or perhaps impossible.  Concepts such as the disk deblocking being in
the BDOS would make life incredibly difficult, as would the other
inherent kludginess for bank switching and the like that I assume will
be in there.  No doubt that's why they're only releasing to OEM's now --
they figure it will only be useful in "packaged" systems where the
configuration is carefully controlled.  If everyone decides to jump
on the 3.0 bandwagon, I will have to decide if it makes any sense to
try push MARC at all when it depends on 2.X systems.  If large numbers of
people punt 3.0 and stay with 2.X, then the problems will not be
so severe.  I would appreciate any comments from people who have some
feelings about how much impact CP/M 3.0 is actually going to have.
I fear that a new era of incompatibility is about to emerge... with some
programs demanding bank switching for large TPA's, and others being
capable of running in both 2.X and 3.0 environments.  I have no idea how
it's going to turn out.

--Lauren--