delorie.com/archives/browse.cgi   search  
Mail Archives: opendos/2000/07/17/15:24:36

To: opendos AT delorie DOT com
Date: Mon, 17 Jul 2000 19:21:14 5
Subject: Re: Hi !
Message-ID: <20000717.192121.-238167.2.editor@juno.com>
X-Mailer: Juno 4.0.9
MIME-Version: 1.0
X-Juno-Line-Breaks: 0-1,3-183
X-Juno-Att: 0
X-Juno-RefParts: 0
From: Bruce Morgen <editor AT juno DOT com>
Reply-To: opendos AT delorie DOT com


On Mon, 17 Jul 2000 19:23:16 +0100 "Ben A L Jemmett"
<ben DOT jemmett AT ukonline DOT co DOT uk> writes:
> > > > Even CP/M  86, Kildall's alternative for the original IBM-PC, 
> was
> > > > released *after* M$'s PC-DOS
> > > It was written at the same time,
> > Yes, if you consider QDDOS and PC-DOS 1.0 to be the
> > same animal.
> Sort of.  However, IBM approached DRI to write CP/M-86 before they
> approached MS, and MS went off and bought/modified QDOS.  So the 
> development
> work was going on concurrently, but MS had a head start with their 
> buyin of code.

Exactly.
> 
> > > but was in testing for longer ->
> > > fewer bugs.
> >
> > No doubt about that -- it was also extremely expensive,
> > assuring buggy PC-DOS's predominance in the
> > marketplace.
> IIRC, the three OSes available with the PC were IBM's Personal 
> Computer DOS
> (nice and cheap), CP-M/86 (extra 100 bucks or so), or the UCSD 
> P-System
> (*big* money).  It was IBM's decision to price DOS and CP/M that 
> way, as
> they were annoyed at DRI for being slow and not wanting to sign 
> contracts too early.

Kildall was also stubborn 
about pricing -- at the 
time, CP/M was *the* brand 
for serious microcomputer 
operating systems, and 
Kildall *vastly* 
underestimated the power 
of IBM to establish a new 
rival brand overnight.  
Gates was much smarter 
about the situation, 
foregoing the per-unit $$ 
and realizing that time-
to-market was much more 
important than delivering 
quality code in 1981.
> 
> > Remember, M$ bought QDDOS from Seattle
> > Microcomputer and did some adaptation to the specifics
> > of the IBM-PC hardware, so PC-DOS was much less of a
> > porting job than CP/M 86.
> Well, yes, but QDOS was pretty much a disassembly/reassembly of 
> CP/M-80,
> wasn't it?  

There's quite a debate 
about that, it surfaces 
from time to time on the 
comp.os.cpm newsgroup.  As 
a DRI OEM, Seattle did have 
access to some DRI code -- 
I suspect what they did was 
more of a functional clone 
(sort of like the first 
Phoenix BIOS was a functional 
clone of the IBM PC-XT BIOS) 
than "disassembly/reassembly."

> So the porting would be similar, although most of it was 
> already done I guess.

Yup, the big job was getting 
it adapted to a new CPU 
family, interfacing to the 
rest of the hardware was 
originally intended to be via 
the BIOS ROM, which was done 
by IBM, not M$!  When things 
like serial port access and 
video maniplation via BIOS 
turned out to be major 
performance limiters on such 
a sluggish platform, folks 
began learning how to access 
the hardware directly, e.g. 
Lotus 1-2-3, bypassing both 
DOS and BIOS.
> 
> > > It was just a port of CP/M-80 though, so technically the
> > > system was around for more than half a decade before MS-DOS.
> >
> > That's a bit of a stretch in the context of this
> > thread, since CP/M wasn't designed to be portable
> > between CPU architectures the porting job was
> > distinctly non-trivial compared to what M$ did to
> > adapt it's purchased DOS to IBM's requirements.

> Yes, it's a very big stretch, but the core of CP/M - the interaction 
> of the
> BIOS, BDOS and command processor in CPM.SYS, and the BDOS calls 
> available
> etc. - were layed out in the early to mid 1970s (CP/M 1.0 was early 
> 1974, > but was significantly different from 2.2.  

CP/M 2.2 (the first popular 
version) didn't have any 
CPM.SYS except perhaps as an 
intermediate system image -- 
the three modules, BIOS (from 
the hardware manufacturer), 
BDOS, and CCP (from DRI) were 
loaded from dedicated "system 
tracks" on the floppy (and 
later hard) disk.  The BIOS 
determined what comprised the 
famous CP/M "Warm Boot" -- 
one could reload the CCP or 
both the CCP and the BDOS 
depending on how many tracks 
the BIOS counted!  They 
weren't part of the file 
system at all and CPM.SYS (or 
whatever you decided to name 
the system image file) wasn't 
need for booting.  CP/M 3.0 
introduced a command 
processor loaded from a file, 
(B)DOS and (generic) BIOS as 
runtime-loadable disk files 
never existed in the 8-bit 
CP/M world.  For CP/M 2.2, 
the system image was created 
as a binary file (essentially 
a concatentation of the BIOS, 
BDOS, and CCP binaries as 
they were to reside in RAM, 
with BDOS and CCP being of 
fixed size from DRI) and 
transferred to the system 
tracks with a hardware-
specific "SYSGEN" program.

The most remarkable thing 
is the tiny size of the 
code in those days -- CP/M 
2.2 fixed the BDOS at 3584 
bytes (3.5K) max and the 
CCP at 2048 bytes (2K) max -- 
and aftermarket drop-in 
replacements for these 
modules crammed much more 
functionality into those 
cramped confines than DRI 
could even dream of (with a 
lot of help from Z80-
specific opcodes, 
particularly relative jumps).  
The code for things like Hal 
Bower and Cam Cotrill's 
ZDOS/ZDDOS and Jay Sage's 
ZCPR 3.4 (developed over the 
course of a couple of years 
from Rick Conn's original PD 
ZCPR3) has been released and 
is an educational in sheer 
assembly language 
craftsmanship.  Now that 
everyone and his granny has 
more RAM than an entire 
shop of CP/M coders, all in 
a single cheap PC, I guess 
that level of the coding art 
is lost forever.

> CP/M-86 was based on CP/M 
> 3, and DOS Plus/DR DOS on CP/M 4).
> 
I've never heard of "CP/M 4," 
and I was intimately involved in 
the 8-bit CP/M world throughout 
the '80s.  What did I miss?

________________________________________________________________
YOU'RE PAYING TOO MUCH FOR THE INTERNET!
Juno now offers FREE Internet Access!
Try it today - there's no risk!  For your FREE software, visit:
http://dl.www.juno.com/get/tagj.

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019