Date   : Wed, 22 Sep 1982 19:21:00-PDT
From   : fylstra.tsca@Sri-Unix
Subject: MARC comments

Lauren,

Here is the message I promised a long time ago.  As you may remember, a
couple of years ago I purchased a copy of OS-1, another Unix-on-a-Z80,
from Electro/Software Labs.  I was able to get it running on my system
and spent a fair amount of time studying the manuals.  This message is
a synopsis of some of the critical gaps in OS-1 that I hope MARC fixes.
I won't touch upon E/S Labs as an organization or their customer
service.  I'm sending this to the whole list because I think others may
be interested in developing custom operating systems or may have ideas
about how to handle some of the problems.

There are only two areas that I feel are crucial, namely booting and
customization for disk formats other than 8" SSSD.

Booting OS-1 was similar to booting UCSD Pascal from CP/M: you first
booted CP/M; then you ran something such as BOOTER.COM; it asked for
the name of a drive from which to boot the OS-1 system disk; you
inserted the diskette and typed a return; and after a minute or so of
disk churning, OS-1 would appear.

Obviously this was something of an ordeal.  I'd be willing to bet that
most CP/M users hit the boot switch pretty frequently during a given
session of hacking.  One reason for this is to guarantee a fresh copy
of everything, resetting the system to a known state.  Another is that
you might be testing a program that has gone to meet its maker in the
infinite loop in the sky.  Any C programmer can recount with grief the
story about the dynamically allocated block that got away.  I really
really hope that it will be possible to boot MARC from the system tracks
on the disk, rather than go thru a multi-stage liftoff.  It seems to
me that it should be possible to stitch a copy of the booter along
with a standard CP/M BIOS into the SYSGEN image, probably on top of
where the BDOS would otherwise reside.  This should enable anyone with
SYSGEN to create a bootable version of MARC.

The second problem with OS-1 was that it had a CP/M 1.4 mentality.
That is, it assumed that your BIOS was only capable of dealing with
8" SSSD soft-sectored disks.  This can be very frustrating when your
system disk contains space for 64 inodes, 62 of which are jammed with
all of the useful utilities that are needed to repair broken heirarchical
file systems, manage user groups, etc, and you know that your disks
can handle four times that amount of space.  So...I really really hope
that MARC can make use of a CP/M 2.x BIOS.  It seems to me that the
CP/M 2.x BIOS design provides a reasonable paradigm for device-independent
access to any type of disk drive, and it is obviously a standard.
Heirarchical filesystems really shine when you have 10 megabytes worth
of files to organize; it would be a shame not to take advantage of
the existing 2.x BIOS.  How many people are still running 1.4 BIOSes?

A third area that I feel strongly about, although I believe it's not
as crucial as the above, is the provision of a standard display control
paradigm.  CP/M provides an implied virtual terminal, which is the
ASR-33.  (I'm stretching it.  The CP/M virtual terminal might have
Backspace, and it probably has lower case, but it doesn't need either.)
We're all used to watching our friends with Apples and IBM PC's run
their display-oriented menus and graphics.  It's a shame that CP/M
doesn't provide a standardized set of primitives to get at the CRT
that is connected to 95% of the consoles, so that all of the public
domain software could do neater things.  I know that recent software
products such as WordStar and Mince take care of this problem with
a configuration program; and if MARC follows the Unix world view,
it will probably use a Termcap data base with an elaborate display
library.

I'd like to suggest an alternative.  Provide a minimum set of display
control primitives (definitely putchar, gotoxy, clrscreen; maybe
clr-to-eol; probably not ins/del line/char).  Have a standardized way
of invoking these primitives from C, hopefully in such a way that the
primitives can be imbedded in strings and be transmitted with printf().
Then interpret the special commands in the BIOS.  One method would be
to set the sign bit on any byte containing a display command, which the
extended BIOS would notice and process seperately; all other characters
would be output just as always.  I'd bet that gotoxy, clrscreen, and
clr-to-eol would add about 30 bytes to my BIOS.  A linkable library
of screen-control functions could instead be bound into each program,
but that presumes you get the source to everything, or at least the
relocatable objects.  My proposal allows distribution of display-oriented
software in binary form.

Well, that's enough on OS-1 and CP/M for now.  I hope you'll say
that it's already implemented.

Dave Fylstra