Tracing the Evolution of CP/M-80 - CP/M

This is a discussion on Tracing the Evolution of CP/M-80 - CP/M ; French Luser wrote: : In other words: because one little-known computer was using 1041 does not : mean that there was a BDOS 4. Beg to differ. If the BDOS calls itself version 4, then that's what it is, pretty ...

+ Reply to Thread
Page 2 of 2 FirstFirst 1 2
Results 21 to 35 of 35

Thread: Tracing the Evolution of CP/M-80

  1. Re: Tracing the Evolution of CP/M-80

    French Luser wrote:
    : In other words: because one little-known computer was using 1041 does not
    : mean that there was a BDOS 4.

    Beg to differ. If the BDOS calls itself version 4, then that's what it is,
    pretty much by definition. If DR hadn't wanted to go to version 4, they
    could have returned 1034 or 1035 or 1036...
    For that matter, the PC1512 wasn't little-known.

    --
    ------------- http://www.seasip.demon.co.uk/index.html --------------------
    John Elliott |BLOODNOK: "But why have you got such a long face?"
    |SEAGOON: "Heavy dentures, Sir!" - The Goon Show
    :-------------------------------------------------------------------------)

  2. Re: Tracing the Evolution of CP/M-80

    Barry, thanks for the informative reply on IMSAI hardware and IMDOS.
    It's good to work this history out on comp.os.cpm, so others can add
    their accounts and refer to any original documents or disks. Barry,
    with your permission and other posters in this thread, when this thread
    runs its course I'll add our remarks to my Web site on my DRI Web page.

    I did not use the earliest IMSAI equipment at the time but I have some
    of it around now, and some docs and disks. From those, I've determined
    that IMSAI offered or intended to offer IMDOS as early as Nov 1977. The
    earliest IMDOS manuals and disks I have are Version 2.02 from late 1977
    or early 1978. in one of those, IMSAI clearly states that IMDOS is an
    "enhanced version" of CP/M from Digital Research.

    Barry, your CP/M 1.3 diskette from IMSAI is therefore very
    interesting, and it would be worth providing to others. If you can
    determine a date for it or the files on it and confirm its IMSAI and
    DRI origins, please post details.

    The following details my determinations:

    1) In my hands right now, I have 5.25" diskettes labled "IMDOS VERSION
    2.05 (c)1978 IMSAI MFG CORP". The lables are pasted on but they have
    serial numbers so I assume these are original IMSAI diskettes or copied
    from same. I also have one IMDOS V2.02 (c)1977 labled diskette. All
    these appear to have been associated with a VDP-40. I also have some
    manuals for IMDOS which state "IMDOS...is CP/M compatible." One IMDOS
    document I'm looking at now is from May 1978; in brief the IMDOS it
    describes seems by features and programs to be a superset of CP/M.

    2) In my hands is an original IMDOS User Manual for IMDOS 2.01 / 2.02
    dated 2/14/78, the earliest one I may have. It has the following
    preface: quote

    "The IMSAI IMDOS floppy Disk Operating System is an ehnanced version of
    the Control Program Monitor (CP/M) originally developed by the Digital
    Research Corporation. IMDOS contains extensive enhancements regarding
    number and variety of floppy disk drives supported, user control of
    diskette date format, and additional features in system calls available
    to user programs. IMDOS is program compatible and file compatible with
    CP/M; IMDOS's Console Commands contain several additions and
    variations. CP/M is a trademark of Digital Research" This page is
    dated 1/8/78.

    3) I have a manual for "IMDOS - II version 1.0" dated 1979. I did not
    examine it further.

    4) My original "DIO Conroller user manual" is dated Nov 1977. It refers
    to the 2-card controller set Barry described. It supported Shugart
    SA800's, GSI 110's and Persci 270's (single or double density 8-inch)
    and also SA400 (single density only 5.25").Barry, I mentioned
    readability issues because the Persci's were notrorious for alignment
    and cross compatibility problems. Also, some floppy controller
    manufacturers did not properly implement the IBM 3740 format in that
    era. In any event, this manual refers only in passing to operating
    systems, and then only the "IMSAI IMDOS System diskette" and a PCS-80
    or VDP-80.

    5) The IMSAI "Diskette System Reference Manual" for Nov 1978 is a
    hardware reference, and refers to the "IMDOS User's Manual" for
    operating system software. the hardware described in this manual is the
    FIF controller (the IFM and the FIB card set), the MDIO controller (one
    board with a 1771 chip), and the DIO controller (two board set as
    previously described).

    Again speaking of formats, the brief description of the DIO in the
    above manual, says the DIO-A original version supported IBM 3740 AND
    "format V, a 128 byte/sector double density format". It continues to
    say the DIO-B supports these and also supports a different head step
    rfate; and it mentions the DIO-C replaced the previous versions and
    supports yet other formats.

    I did not check my archives for CP/M 1.4 and 1.3 diskettes. This post
    is already rather long. But a Web search of "CP/M 1.4" suggests that
    CP/M 1.3 had a very limited distribution.

    Herb Johnson


  3. Re: Tracing the Evolution of CP/M-80

    But wait! there's more...

    6) My "IMSAI Floppy Disk System User Manual" copyright 1976 (erata page
    4/77). Test code is dated 10/75; firmware dated Oct 1976.This manual
    only covers the IFM (rev 6) and FIB (rev 3) floppy controller card set,
    so I assume it's the earliest IMSAI disk controller manual. It's all
    about hardware and firmware for those two cards and associated floppy
    drives. It has a few references to operating systems, but ALL of those
    references are to CP/M - no mention of "IMDOS". Phrases are "...now
    configured as required for ...CP/M operation" or "..[to] bring up
    IMSAI CP/M, refer to the IMSAI CP/M USER MANUAL". The 1977 section on
    "System User Guide" mentions "IMSAI CP/M documentation".

    So for some period in late 1976 through early 1977, IMSAI apparently
    offered some version of CP/M and not "IMDOS" by name. This might
    account for Barry's IMSAI CP/M 1.3 diskette.

    Herb Johnson

    Herbert R. Johnson, New Jersey USA
    web site
    domain mirror
    my email address: hjohnson AAT retrotechnology DOTT com
    if no reply, try in a few days: herbjohnson ATT comcast DOTT net
    "Herb's Stuff": old Mac, SGI, 8-inch floppy drives
    S-100 IMSAI Altair computers, docs, by "Dr. S-100"


  4. Re: Tracing the Evolution of CP/M-80

    IMSAI's motivation for IMDOS was largely a consequence of the fact that
    CP/M 1.3 and even (equally) 1.4 only supported one single format ....
    IBM 3740 eight-inch single density (77 tracks of 26 sectors of 128 bytes
    per sector). That was, also, all that the IFM/FIB controller set
    supported. However, the DIO/PDS set could support many (almost an
    arbitrary number of) formats, including 5.25" and double density
    eight-inch. But CP/M (until 2.x) could not, so I believe that was the
    primary motivation for IMDOS.

    [I think that a secondary motivation was that they could offer product
    like Microsoft Fortran and lock it to what was then an IMSAI operating
    system, thus preventing use of a copy of Microsoft Fortran bought from
    IMSAI on non-IMSAI systems.]

    The Persci drives were, when used with a soft-sector configuration,
    totally standard eight-inch floppy disk drives. Of course any given
    drive could be out of radial alignment, but that is true of any model of
    any brand of drive, and has little to do with anything else.


    Herb Johnson wrote:
    > But wait! there's more...
    >
    > 6) My "IMSAI Floppy Disk System User Manual" copyright 1976 (erata page
    > 4/77). Test code is dated 10/75; firmware dated Oct 1976.This manual
    > only covers the IFM (rev 6) and FIB (rev 3) floppy controller card set,
    > so I assume it's the earliest IMSAI disk controller manual. It's all
    > about hardware and firmware for those two cards and associated floppy
    > drives. It has a few references to operating systems, but ALL of those
    > references are to CP/M - no mention of "IMDOS". Phrases are "...now
    > configured as required for ...CP/M operation" or "..[to] bring up
    > IMSAI CP/M, refer to the IMSAI CP/M USER MANUAL". The 1977 section on
    > "System User Guide" mentions "IMSAI CP/M documentation".
    >
    > So for some period in late 1976 through early 1977, IMSAI apparently
    > offered some version of CP/M and not "IMDOS" by name. This might
    > account for Barry's IMSAI CP/M 1.3 diskette.
    >
    > Herb Johnson
    >
    > Herbert R. Johnson, New Jersey USA
    > web site
    > domain mirror
    > my email address: hjohnson AAT retrotechnology DOTT com
    > if no reply, try in a few days: herbjohnson ATT comcast DOTT net
    > "Herb's Stuff": old Mac, SGI, 8-inch floppy drives
    > S-100 IMSAI Altair computers, docs, by "Dr. S-100"
    >


  5. Re: Tracing the Evolution of CP/M-80

    On Wed, 07 Jun 2006 22:30:56 GMT, Barry Watzman
    wrote:

    >IMSAI's motivation for IMDOS was largely a consequence of the fact that
    >CP/M 1.3 and even (equally) 1.4 only supported one single format ....
    >IBM 3740 eight-inch single density (77 tracks of 26 sectors of 128 bytes
    >per sector). That was, also, all that the IFM/FIB controller set
    >supported. However, the DIO/PDS set could support many (almost an
    >arbitrary number of) formats, including 5.25" and double density
    >eight-inch. But CP/M (until 2.x) could not, so I believe that was the
    >primary motivation for IMDOS.


    Make that easily supports only one format. I have CP/M V1.4 for NS*
    MDS (single density) both the Lifeboat version and NS* versions.

    So everyone knows/remember the single density NS* MDS was
    35tracks, 10sectors of 256bytes single sided and only 3 drives
    possible. Around 82k useable space (cpm formatted).

    CP/M1.4 was the first commercially useful version and while
    it was difficult to set up for other than SSSD 8" it was doable if
    you were willing to dig inside the BDOS. Apparently DRI
    was willing to help major vendors do it.

    Allison
    >
    >[I think that a secondary motivation was that they could offer product
    >like Microsoft Fortran and lock it to what was then an IMSAI operating
    >system, thus preventing use of a copy of Microsoft Fortran bought from
    >IMSAI on non-IMSAI systems.]
    >
    >The Persci drives were, when used with a soft-sector configuration,
    >totally standard eight-inch floppy disk drives. Of course any given
    >drive could be out of radial alignment, but that is true of any model of
    >any brand of drive, and has little to do with anything else.
    >
    >
    >Herb Johnson wrote:
    >> But wait! there's more...
    >>
    >> 6) My "IMSAI Floppy Disk System User Manual" copyright 1976 (erata page
    >> 4/77). Test code is dated 10/75; firmware dated Oct 1976.This manual
    >> only covers the IFM (rev 6) and FIB (rev 3) floppy controller card set,
    >> so I assume it's the earliest IMSAI disk controller manual. It's all
    >> about hardware and firmware for those two cards and associated floppy
    >> drives. It has a few references to operating systems, but ALL of those
    >> references are to CP/M - no mention of "IMDOS". Phrases are "...now
    >> configured as required for ...CP/M operation" or "..[to] bring up
    >> IMSAI CP/M, refer to the IMSAI CP/M USER MANUAL". The 1977 section on
    >> "System User Guide" mentions "IMSAI CP/M documentation".
    >>
    >> So for some period in late 1976 through early 1977, IMSAI apparently
    >> offered some version of CP/M and not "IMDOS" by name. This might
    >> account for Barry's IMSAI CP/M 1.3 diskette.
    >>
    >> Herb Johnson
    >>
    >> Herbert R. Johnson, New Jersey USA
    >> web site
    >> domain mirror
    >> my email address: hjohnson AAT retrotechnology DOTT com
    >> if no reply, try in a few days: herbjohnson ATT comcast DOTT net
    >> "Herb's Stuff": old Mac, SGI, 8-inch floppy drives
    >> S-100 IMSAI Altair computers, docs, by "Dr. S-100"
    >>



  6. Re: Tracing the Evolution of CP/M-80

    Yes, CP/M could be modified for other disk formats, but it meant changes
    in the BDOS in versions 1.3 and 1.4, rather than in the BIOS. I worked
    with Larry Alkoff (Lifeboat) on such a modification for the Lifeboat
    CP/M on the Heathkit systems (hard sector 5.25" single density).

    However, that still misses the point regarding IMSAI's implementation
    for IMDOS.

    The Imsai systems that were the motivation for IMDOS needed to support
    multiple formats concurrently in the same system .... single and double
    desnity / sided eight-inch AND 5.25" media, all intermixed concurrently.
    And THAT was simply not possible reasonably possible with CP/M 1.3 or
    1.4, even IF you had source code and were willing to patch the BDOS. It
    was simply a too-radical departure from what those versions of CP/M were
    intended to support. It wasn't until CP/M 2.x became available that
    such versatility would be possible, but IMSAI needed those capabilities
    more than 2 years before CP/M 2 would appear.


    nospam@nouce.bellatlantic.net wrote:

    > On Wed, 07 Jun 2006 22:30:56 GMT, Barry Watzman
    > wrote:
    >
    >
    >>IMSAI's motivation for IMDOS was largely a consequence of the fact that
    >>CP/M 1.3 and even (equally) 1.4 only supported one single format ....
    >>IBM 3740 eight-inch single density (77 tracks of 26 sectors of 128 bytes
    >>per sector). That was, also, all that the IFM/FIB controller set
    >>supported. However, the DIO/PDS set could support many (almost an
    >>arbitrary number of) formats, including 5.25" and double density
    >>eight-inch. But CP/M (until 2.x) could not, so I believe that was the
    >>primary motivation for IMDOS.

    >
    >
    > Make that easily supports only one format. I have CP/M V1.4 for NS*
    > MDS (single density) both the Lifeboat version and NS* versions.
    >
    > So everyone knows/remember the single density NS* MDS was
    > 35tracks, 10sectors of 256bytes single sided and only 3 drives
    > possible. Around 82k useable space (cpm formatted).
    >
    > CP/M1.4 was the first commercially useful version and while
    > it was difficult to set up for other than SSSD 8" it was doable if
    > you were willing to dig inside the BDOS. Apparently DRI
    > was willing to help major vendors do it.
    >
    > Allison
    >
    >>[I think that a secondary motivation was that they could offer product
    >>like Microsoft Fortran and lock it to what was then an IMSAI operating
    >>system, thus preventing use of a copy of Microsoft Fortran bought from
    >>IMSAI on non-IMSAI systems.]
    >>
    >>The Persci drives were, when used with a soft-sector configuration,
    >>totally standard eight-inch floppy disk drives. Of course any given
    >>drive could be out of radial alignment, but that is true of any model of
    >>any brand of drive, and has little to do with anything else.
    >>
    >>
    >>Herb Johnson wrote:
    >>
    >>>But wait! there's more...
    >>>
    >>>6) My "IMSAI Floppy Disk System User Manual" copyright 1976 (erata page
    >>>4/77). Test code is dated 10/75; firmware dated Oct 1976.This manual
    >>>only covers the IFM (rev 6) and FIB (rev 3) floppy controller card set,
    >>>so I assume it's the earliest IMSAI disk controller manual. It's all
    >>>about hardware and firmware for those two cards and associated floppy
    >>>drives. It has a few references to operating systems, but ALL of those
    >>>references are to CP/M - no mention of "IMDOS". Phrases are "...now
    >>>configured as required for ...CP/M operation" or "..[to] bring up
    >>>IMSAI CP/M, refer to the IMSAI CP/M USER MANUAL". The 1977 section on
    >>>"System User Guide" mentions "IMSAI CP/M documentation".
    >>>
    >>>So for some period in late 1976 through early 1977, IMSAI apparently
    >>>offered some version of CP/M and not "IMDOS" by name. This might
    >>>account for Barry's IMSAI CP/M 1.3 diskette.
    >>>
    >>>Herb Johnson
    >>>
    >>>Herbert R. Johnson, New Jersey USA
    >>> web site
    >>> domain mirror
    >>>my email address: hjohnson AAT retrotechnology DOTT com
    >>>if no reply, try in a few days: herbjohnson ATT comcast DOTT net
    >>>"Herb's Stuff": old Mac, SGI, 8-inch floppy drives
    >>>S-100 IMSAI Altair computers, docs, by "Dr. S-100"
    >>>

    >
    >


  7. Re: Tracing the Evolution of CP/M-80

    1) A correction to my previous post:

    "6) My "IMSAI Floppy Disk System User Manual" copyright 1976 (erata
    page 4/77). Test code is dated 10/75; firmware dated Oct 1976. "

    The test code was dated 10/76.

    2) Barry's comments about the shift to multiple floppy formats are
    consistent with my brief read of IMSAI manuals I described. The
    earliest IMSAI floppy controller supported only one format and were
    supported by some version of CP/M; later controllers supported multiple
    formats as supported by IMDOS. IMSAI moved from a controller with its
    own processor (and code) to a single chip FDC; each new controller
    provided more format options. Likewise, outside of IMSAI (as Barry
    pointed out), other S-100 manufacturers were developing their own
    floppy disk hardware and following similar hardware trends. Their OS's
    likely have similar relationships to early DRI's CP/M.

    This IMSAI discussion dovetails nicely with the interview notes of
    "Chief IMSAI Engineer" Joe Killian on the IMSAI Web site:

    http://www.imsai.net/history/imsai_h...-m_history.htm

    ...which discuss the strong collaboration between IMSAI and DRI in 1977.
    Killian says there that Glenn Ewing, who was then Gary Kildall's
    colleague at the Naval school and who later became an IMSAI engineer,
    "talked Gary into just separating the I/O from the rest of [CP/M], with
    Glenn promising to re-write the I/O module for the IMSAI 8080 (which he
    did)".

    Let's bring this back to Howard Harte's original posts on tracing the
    evolution of CP/M.

    It's clear from IMSAI documents of the era, and from first and
    second-person accounts, that IMSAI developers worked with Gary Kildall
    on CP/M before or during version 1.3, to create IMDOS (probably version
    2.0) as licensed from Digital Research. Therefore, a code review of
    IMDOS will likely show common code with CP/M 1.4 and with the earlier
    and much rarer CP/M 1.3. In addition, a likely and major code change
    from CP/M 1.3 to 1.4 (and IMDOS) to 2.0 should be an increased
    isolation of floppy I/O from the operating system code.

    The isolation of I/O from the OS provided multiple dividends to
    developers and to users, to say the least. The flexible CP/M operating
    system, and the flexible S-100 hardware bus, were in my opinion
    essential to growth and development during the 1970's of what we now
    call personal computing. (Other computing OS's and hardware
    architectures were also important of course.)

    I hope those with original OS disks for CP/M 1.3 and IMDOS 2.X will
    make the files available as appropriate. I'll see what I can do with
    mine. Of course I've made IMSAI documents available via my Web site for
    many many years.

    Herb Johnson

    (note: do not send emails to the gmail address for this post. My email
    address is below.)

    Herbert R. Johnson, phone 609-771-1417, New Jersey USA
    web site
    domain mirror
    my email address: hjohnson AAT retrotechnology DOTT com
    if no reply, try in a few days: herbjohnson ATT comcast DOTT net
    "Herb's Stuff": old Mac, SGI, 8-inch floppy drives
    S-100 IMSAI Altair computers, docs, by "Dr. S-100"


  8. Re: Tracing the Evolution of CP/M-80

    Herb,

    Imsai really never moved to a single disk FDC using a WD chip. They
    ultimately did offer such a product, but not until very close the end of
    IMSAI, and I've never seen that board. The primary move was from the
    IFM/FIB 2-board set to the DIO/PDS 2-board set. The former was 8-inch
    SSSD only, the latter was quite versatile in terms of formats.

    Regarding CP/M 1.3 and 1.4, there is less difference than you seem to
    think, and it's not where you think. The BIOS/BDOS architecture was
    virtually unchanged. The big difference was that CP/M 1.3 was very,
    very bad about trashing your diskettes if you changed them without doing
    a warm start (control-C). In CP/M 1.4, DR began checksumming the
    directory to detect that the disk had been changed. This greatly
    reduced (but did not totally eliminate in all cases) the incidence of a
    disketts contents (actually the directory) being destroyed if the user
    changed disks at an inappropriate time and did not do a control-C. That
    was the largest single difference between 1.3 and 1.4, as I recall (in
    2.0, the checksum vector area was moved to the bios, along with the
    other disk parameters).


    Herb Johnson wrote:
    > 1) A correction to my previous post:
    >
    > "6) My "IMSAI Floppy Disk System User Manual" copyright 1976 (erata
    > page 4/77). Test code is dated 10/75; firmware dated Oct 1976. "
    >
    > The test code was dated 10/76.
    >
    > 2) Barry's comments about the shift to multiple floppy formats are
    > consistent with my brief read of IMSAI manuals I described. The
    > earliest IMSAI floppy controller supported only one format and were
    > supported by some version of CP/M; later controllers supported multiple
    > formats as supported by IMDOS. IMSAI moved from a controller with its
    > own processor (and code) to a single chip FDC; each new controller
    > provided more format options. Likewise, outside of IMSAI (as Barry
    > pointed out), other S-100 manufacturers were developing their own
    > floppy disk hardware and following similar hardware trends. Their OS's
    > likely have similar relationships to early DRI's CP/M.
    >
    > This IMSAI discussion dovetails nicely with the interview notes of
    > "Chief IMSAI Engineer" Joe Killian on the IMSAI Web site:
    >
    > http://www.imsai.net/history/imsai_h...-m_history.htm
    >
    > ..which discuss the strong collaboration between IMSAI and DRI in 1977.
    > Killian says there that Glenn Ewing, who was then Gary Kildall's
    > colleague at the Naval school and who later became an IMSAI engineer,
    > "talked Gary into just separating the I/O from the rest of [CP/M], with
    > Glenn promising to re-write the I/O module for the IMSAI 8080 (which he
    > did)".
    >
    > Let's bring this back to Howard Harte's original posts on tracing the
    > evolution of CP/M.
    >
    > It's clear from IMSAI documents of the era, and from first and
    > second-person accounts, that IMSAI developers worked with Gary Kildall
    > on CP/M before or during version 1.3, to create IMDOS (probably version
    > 2.0) as licensed from Digital Research. Therefore, a code review of
    > IMDOS will likely show common code with CP/M 1.4 and with the earlier
    > and much rarer CP/M 1.3. In addition, a likely and major code change
    > from CP/M 1.3 to 1.4 (and IMDOS) to 2.0 should be an increased
    > isolation of floppy I/O from the operating system code.
    >
    > The isolation of I/O from the OS provided multiple dividends to
    > developers and to users, to say the least. The flexible CP/M operating
    > system, and the flexible S-100 hardware bus, were in my opinion
    > essential to growth and development during the 1970's of what we now
    > call personal computing. (Other computing OS's and hardware
    > architectures were also important of course.)
    >
    > I hope those with original OS disks for CP/M 1.3 and IMDOS 2.X will
    > make the files available as appropriate. I'll see what I can do with
    > mine. Of course I've made IMSAI documents available via my Web site for
    > many many years.
    >
    > Herb Johnson
    >
    > (note: do not send emails to the gmail address for this post. My email
    > address is below.)
    >
    > Herbert R. Johnson, phone 609-771-1417, New Jersey USA
    > web site
    > domain mirror
    > my email address: hjohnson AAT retrotechnology DOTT com
    > if no reply, try in a few days: herbjohnson ATT comcast DOTT net
    > "Herb's Stuff": old Mac, SGI, 8-inch floppy drives
    > S-100 IMSAI Altair computers, docs, by "Dr. S-100"
    >


  9. Re: Tracing the Evolution of CP/M-80

    Barry Watzman wrote:
    > Herb,
    >
    > Imsai really never moved to a single disk FDC using a WD chip. They
    > ultimately did offer such a product, but not until very close the end of
    > IMSAI, and I've never seen that board. The primary move was from the
    > IFM/FIB 2-board set to the DIO/PDS 2-board set. The former was 8-inch
    > SSSD only, the latter was quite versatile in terms of formats.


    A FDC board was mentioned, with a 1771 controller, in the manual noted.
    I guess they did not produce it. And the manual went on at length about
    formats for the DIO/PDS set., as you've said. It was a stretch on my
    part to include a 1771 based board in my IMSAI remarks. But other
    companies went on to use such chips on their boards. The fact that CP/M
    could be supportted on boards with that and other FDC chips is notible
    overall.

    > Regarding CP/M 1.3 and 1.4, there is less difference than you seem to
    > think, and it's not where you think.


    Actually I'm just quoting the IMSAI interview. I've not looked at the
    IMSAI code myself or the IMSAI docs in any detail this week beyond what
    I've reported. Don't think I've ever seen CP/M 1.3 as such. I may have
    poked at IMDOS in my lifetime, on some PDS system decades ago.

    But it's possible the collaberation described between "IMSAI" and
    Kildall occurred before CP/M 1.3. That email interview did not mention
    specific versions, nor did the IMSAI docs I have reviewed mention CP/M
    versions. The interview did give dates, although they are from memory
    and even Todd Fischer suggests those dates may be inconsistent. The
    dates I gave are printed in the IMSAI docs I referenced. What dates can
    you glean, Barry, from your IMSAI CP/M 1.3 and any related docs for it?

    My point was to make a case as to why a review of early CP/M code
    should include IMDOS code. Along the way, I've confirmed most or all of
    Barry's remarks from memory - that's pretty good for 30-year-old
    recollections! Between you, Barry, myself (from the IMSAI docs) and
    Todd's interview notes I think the case is made.

    The next step is to look at some code, seems to me, and dig up some
    more docs and disk of the period.

    Herb Johnson

    (note: do not send emails to the gmail address for this post. My email
    address is below.)

    Herbert R. Johnson, phone 609-771-1417, New Jersey USA
    web site
    domain mirror
    my email address: hjohnson AAT retrotechnology DOTT com
    if no reply, try in a few days: herbjohnson ATT comcast DOTT net
    "Herb's Stuff": old Mac, SGI, 8-inch floppy drives
    S-100 IMSAI Altair computers, docs, by "Dr. S-100"


  10. Re: Tracing the Evolution of CP/M-80

    Re: "A FDC board was mentioned, with a 1771 controller, in the manual
    noted. I guess they did not produce it."

    I think it was produced in very low volume for only a few months at the
    very end of Imsai's existence. The 1771 was VERY popular and Imsai
    should have gone with it much earlier. However, Imsai and Processor
    Technology both had a penchant for doing things in their own proprietary
    way, very much to their own detriment. Very bad cases of "not invented
    here" syndrome. Tarbell, Cromemco, Vector Grahics and many other firms
    used the 1771, and ended up with better, faster, more reliable and lower
    cost products as a result.


    Herb Johnson wrote:

    > Barry Watzman wrote:
    >
    >>Herb,
    >>
    >>Imsai really never moved to a single disk FDC using a WD chip. They
    >>ultimately did offer such a product, but not until very close the end of
    >>IMSAI, and I've never seen that board. The primary move was from the
    >>IFM/FIB 2-board set to the DIO/PDS 2-board set. The former was 8-inch
    >>SSSD only, the latter was quite versatile in terms of formats.

    >
    >
    > A FDC board was mentioned, with a 1771 controller, in the manual noted.
    > I guess they did not produce it. And the manual went on at length about
    > formats for the DIO/PDS set., as you've said. It was a stretch on my
    > part to include a 1771 based board in my IMSAI remarks. But other
    > companies went on to use such chips on their boards. The fact that CP/M
    > could be supportted on boards with that and other FDC chips is notible
    > overall.
    >
    >
    >>Regarding CP/M 1.3 and 1.4, there is less difference than you seem to
    >>think, and it's not where you think.

    >
    >
    > Actually I'm just quoting the IMSAI interview. I've not looked at the
    > IMSAI code myself or the IMSAI docs in any detail this week beyond what
    > I've reported. Don't think I've ever seen CP/M 1.3 as such. I may have
    > poked at IMDOS in my lifetime, on some PDS system decades ago.
    >
    > But it's possible the collaberation described between "IMSAI" and
    > Kildall occurred before CP/M 1.3. That email interview did not mention
    > specific versions, nor did the IMSAI docs I have reviewed mention CP/M
    > versions. The interview did give dates, although they are from memory
    > and even Todd Fischer suggests those dates may be inconsistent. The
    > dates I gave are printed in the IMSAI docs I referenced. What dates can
    > you glean, Barry, from your IMSAI CP/M 1.3 and any related docs for it?
    >
    > My point was to make a case as to why a review of early CP/M code
    > should include IMDOS code. Along the way, I've confirmed most or all of
    > Barry's remarks from memory - that's pretty good for 30-year-old
    > recollections! Between you, Barry, myself (from the IMSAI docs) and
    > Todd's interview notes I think the case is made.
    >
    > The next step is to look at some code, seems to me, and dig up some
    > more docs and disk of the period.
    >
    > Herb Johnson
    >
    > (note: do not send emails to the gmail address for this post. My email
    > address is below.)
    >
    > Herbert R. Johnson, phone 609-771-1417, New Jersey USA
    > web site
    > domain mirror
    > my email address: hjohnson AAT retrotechnology DOTT com
    > if no reply, try in a few days: herbjohnson ATT comcast DOTT net
    > "Herb's Stuff": old Mac, SGI, 8-inch floppy drives
    > S-100 IMSAI Altair computers, docs, by "Dr. S-100"
    >


  11. Re: Tracing the Evolution of CP/M-80

    GKBYTE.WS4
    ----------

    - "CP/M: A Family of 8- and 16-Bit Operating Systems"
    Gary Kildall
    BYTE, June 1981, p.216

    (Retyped by Emmanuel ROCHE.)

    (...)

    System Languages
    ----------------

    A system language is a high-level machine-dependent programming
    language used to implement so-called "system software,"
    including operating systems, text editors, debuggers,
    interpreters, and compilers. In the early days of computing,
    virtually all system software was implemented in assembly
    language. One revolutionary machine, the Burroughs B5500, used a
    variant of ALGOL-60 as its only system programming tool, and
    appeared in the early 1960s. The machine was a commercial
    success against the other major mainframes, proving that
    assemblers were no longer necessary. Many successful system
    languages followed Burroughs' ALGOL, including the C language,
    produced at Bell Laboratories in the late 1960s, which served as
    the basis for the UNIX operating system.

    A system language, by definition, matches the architecture of a
    particular machine or class of machines; all facilities of the
    machine are accessible in the language, and the language
    contains no nontrivial extensions beyond the basic machine
    capabilities. The benefit is that a compiler for the system
    language is easy to implement and transport from machine to
    machine, as long as the architecture of each machine is similar.
    Further, a system language requires little runtime support since
    application facilities, such as extensive I/O (input/output)
    processing, are not generally embodied in the language.

    Refinements in system languages are made by increasing their
    usability. Their acceptance as replacements for assembly
    languages is encouraging. Today, one can publicly admit that
    system software is implemented in a high-level language without
    implying that it must be rewritten in assembly language to be
    effective.


    PL/M: The Base for CP/M
    -----------------------

    In 1972, MAA (Microcomputer Applications Associates), the
    predecessor of Digital Research, consulted with the small,
    aspiring microprocessor division of a semiconductor memory
    company called Intel Corporation. MAA defined and implemented a
    new systems-programming language, called PL/M (Programming
    Language for Microcomputers), to replace assembly-language
    programming for Intel's 8-bit microprocessor. PL/M is a
    refinement of the XPL compiler-writing language which is, in
    turn, a language with elements from Burroughs Corporation's
    ALGOL and the full set of PL/1.

    The first substantial program written by MAA using PL/M was a
    paper-tape editor for the 8008 microprocessor, which later
    became the CP/M program editor, called ED. PL/M is a commercial
    success for Intel Corporation and, although licensing policies
    have limited its general accessibility, it has become the
    standard language of the Intel microprocessor world, with
    implementations for the 8080, 8085, and 8086 families.

    MAA also proposed a companion operating system, called CP/M
    (Control Program for Microcomputers), which would form the basis
    for resident PL/M programming. The need for CP/M was obvious;
    8080-based computers with 16 K bytes of main memory could be
    combined with Shugart's new (at that time) floppy disk drives to
    serve as development systems. For the first time, it was
    feasible to dedicate a reasonably powerful computer to the
    support of a single engineer. But the use of PL/M on larger
    timesharing computers was considered sufficient, and the CP/M
    idea was rejected.


    (...)

    PL/1: The Application Language
    ------------------------------

    In 1978, Digital Research investigated the final level of
    software support: application languages. One such language was
    to be supported throughout the operating system product line,
    and the choice would have to be a multipurpose language.
    Further, the language would have to be an international
    standard, to promote the generation of software by independent
    vendors. Standard Pascal seemed a logical choice, but was
    rejected for several reasons. First, Pascal is an ALGOL
    derivative with scientific orientation. Commercial facilities in
    the standard language are absent: decimal arithmetic, file
    processing, string operations, and error exception handling were
    essential. Further, separate compilation and initialization of
    tables were not in the language. There was a temptation to
    extend Pascal in order to include these features, but these
    extensions would have defeated the benefits of standardization.

    PL/1 Subset G was the obvious choice. It satisfied scientific
    and commercial needs and, because of subset restrictions, was
    consistent and easy to use. The project was a bit daring,
    however, because Subset G was unknown in the computer community.
    PL/1 was viewed as a large IBM-oriented language with huge,
    inefficient compilers that required tremendous runtime support.

    The Digital Research implementation of Subset G was started in
    mid-1978 and completed two years later. The compiler is a three-
    pass system written in PL/M. The first two passes are machine-
    independent, and produce symbol tables and intermediate language
    suitable for any target machine. The third pass is largely
    machine-dependent, and is dedicated to code optimization and
    final machine-code production. The compiler is accompanied by a
    linkage editor (compatible with the Microsoft format), a program
    librarian, a set of runtime subroutines, and a relocating macro
    assembler.

    Thus, PL/1 completes the final level of the inverted pyramid of
    support tools. The message should be clear to the application
    programmer: it is not the system language or the operating
    system which is important in the production of a final
    application. Rather, it is the availability of a standard,
    widely accepted application language that can provide program
    longevity. Once expressed in PL/1 Subset G, the program can be
    transported through the CP/M family of operating systems to a
    variety of minicomputer systems. Digital Research has a long-
    term commitment to PL/1 support for popular operating systems
    and processors.


    EOF


  12. Re: Tracing the Evolution of CP/M-80

    GKBYTE.WS4
    ----------

    - "CP/M: A Family of 8- and 16-Bit Operating Systems"
    Gary Kildall
    BYTE, June 1981, p.216

    (Retyped by Emmanuel ROCHE.)

    (...)

    System Languages
    ----------------

    A system language is a high-level machine-dependent programming
    language used to implement so-called "system software,"
    including operating systems, text editors, debuggers,
    interpreters, and compilers. In the early days of computing,
    virtually all system software was implemented in assembly
    language. One revolutionary machine, the Burroughs B5500, used a
    variant of ALGOL-60 as its only system programming tool, and
    appeared in the early 1960s. The machine was a commercial
    success against the other major mainframes, proving that
    assemblers were no longer necessary. Many successful system
    languages followed Burroughs' ALGOL, including the C language,
    produced at Bell Laboratories in the late 1960s, which served as
    the basis for the UNIX operating system.

    A system language, by definition, matches the architecture of a
    particular machine or class of machines; all facilities of the
    machine are accessible in the language, and the language
    contains no nontrivial extensions beyond the basic machine
    capabilities. The benefit is that a compiler for the system
    language is easy to implement and transport from machine to
    machine, as long as the architecture of each machine is similar.
    Further, a system language requires little runtime support since
    application facilities, such as extensive I/O (input/output)
    processing, are not generally embodied in the language.

    Refinements in system languages are made by increasing their
    usability. Their acceptance as replacements for assembly
    languages is encouraging. Today, one can publicly admit that
    system software is implemented in a high-level language without
    implying that it must be rewritten in assembly language to be
    effective.


    PL/M: The Base for CP/M
    -----------------------

    In 1972, MAA (Microcomputer Applications Associates), the
    predecessor of Digital Research, consulted with the small,
    aspiring microprocessor division of a semiconductor memory
    company called Intel Corporation. MAA defined and implemented a
    new systems-programming language, called PL/M (Programming
    Language for Microcomputers), to replace assembly-language
    programming for Intel's 8-bit microprocessor. PL/M is a
    refinement of the XPL compiler-writing language which is, in
    turn, a language with elements from Burroughs Corporation's
    ALGOL and the full set of PL/1.

    The first substantial program written by MAA using PL/M was a
    paper-tape editor for the 8008 microprocessor, which later
    became the CP/M program editor, called ED. PL/M is a commercial
    success for Intel Corporation and, although licensing policies
    have limited its general accessibility, it has become the
    standard language of the Intel microprocessor world, with
    implementations for the 8080, 8085, and 8086 families.

    MAA also proposed a companion operating system, called CP/M
    (Control Program for Microcomputers), which would form the basis
    for resident PL/M programming. The need for CP/M was obvious;
    8080-based computers with 16 K bytes of main memory could be
    combined with Shugart's new (at that time) floppy disk drives to
    serve as development systems. For the first time, it was
    feasible to dedicate a reasonably powerful computer to the
    support of a single engineer. But the use of PL/M on larger
    timesharing computers was considered sufficient, and the CP/M
    idea was rejected.


    (...)

    PL/1: The Application Language
    ------------------------------

    In 1978, Digital Research investigated the final level of
    software support: application languages. One such language was
    to be supported throughout the operating system product line,
    and the choice would have to be a multipurpose language.
    Further, the language would have to be an international
    standard, to promote the generation of software by independent
    vendors. Standard Pascal seemed a logical choice, but was
    rejected for several reasons. First, Pascal is an ALGOL
    derivative with scientific orientation. Commercial facilities in
    the standard language are absent: decimal arithmetic, file
    processing, string operations, and error exception handling were
    essential. Further, separate compilation and initialization of
    tables were not in the language. There was a temptation to
    extend Pascal in order to include these features, but these
    extensions would have defeated the benefits of standardization.

    PL/1 Subset G was the obvious choice. It satisfied scientific
    and commercial needs and, because of subset restrictions, was
    consistent and easy to use. The project was a bit daring,
    however, because Subset G was unknown in the computer community.
    PL/1 was viewed as a large IBM-oriented language with huge,
    inefficient compilers that required tremendous runtime support.

    The Digital Research implementation of Subset G was started in
    mid-1978 and completed two years later. The compiler is a three-
    pass system written in PL/M. The first two passes are machine-
    independent, and produce symbol tables and intermediate language
    suitable for any target machine. The third pass is largely
    machine-dependent, and is dedicated to code optimization and
    final machine-code production. The compiler is accompanied by a
    linkage editor (compatible with the Microsoft format), a program
    librarian, a set of runtime subroutines, and a relocating macro
    assembler.

    Thus, PL/1 completes the final level of the inverted pyramid of
    support tools. The message should be clear to the application
    programmer: it is not the system language or the operating
    system which is important in the production of a final
    application. Rather, it is the availability of a standard,
    widely accepted application language that can provide program
    longevity. Once expressed in PL/1 Subset G, the program can be
    transported through the CP/M family of operating systems to a
    variety of minicomputer systems. Digital Research has a long-
    term commitment to PL/1 support for popular operating systems
    and processors.


    EOF


  13. Re: Tracing the Evolution of CP/M-80

    French Luser wrote:
    > Steve Dubrovich asked the following questions:
    >
    > > Now I've a few software questions of my own. Is not PL/M a subset G of
    > > PL/I? Is there a version of CP/M written in PL/I? Did Intel ever
    > > offer PL/I as one of its language tools? What DRI code is written in
    > > PL/I? Will the PL/I Compiler compile the PL/M code? Since PL/M-80 was
    > > developed first and good enough to write CP/M in, why did DRI develop a
    > > separate PL/I-80 later?

    >
    > (Wow, Steve! Are you becoming a philosopher, to ask so many questions?)

    Heh, I am therefore I is??
    No, I have a misconception so I ask alot of questions to corral the
    error.
    >
    > > Is not PL/M a subset G of PL/I?

    >

    No it isn't, as you say, and my main error. In searching where I
    might've been confused, I found this from PLMLANG.DOC, from PLM80S.ZIP
    "
    PL/M-80 is a programming language for i8080 systems. It is based most
    notable on PL/I. It has the type of block structure and scope rules
    most programmers now expect despite the fact it is a fairly small
    language.

    The one thing that may "trip-up" may Pascal programmers is that PL/M
    (and its PL/I big brother) use semicolon as a terminator, not as a
    statement separator. Semicolons mark the end of every statement.
    "
    The files in this zip are:
    -README PLM You are reading it now.
    PLM81 FOR Source for Pass 1 of the compiler.
    PLM82 FOR Source for Pass 2 of the compiler.
    PLMLANG DOC Summary of the PL/M language.
    PLMCOMP DOC Description of compiler switches.
    PLMSAMP PLM Sample PL/M program.
    PLMSAMP HEX Compiler output for the sample.
    PLMSAMP PRN Compiler listing for the sample.

    However, it was I who equated PL/M with PL/I subset G, in error.

    In my searching I also found this information:

    According to the Intel 'MCS-8 A Guide to PL/M Programming' Sept 1973 ;
    'The language is structurally similar to PL/I (in particular,
    PL/M closely resembles XPL), ...'
    And according to the cover sheet, 'The PL/M compiler is written
    in ANSI Standard Fortran IV...' That Guide also states on pg. 52,
    the Fortran unit number assignments for PDP-10 and also the IBM 360.
    Those are the machines you indicated Gary programmed on.

    Wikipedia gives a nice overview of PL/I:
    http://en.wikipedia.org/wiki/PL/I

    http://www.cs.toronto.edu/XPL/ld010.html
    - The home of XPL, states:
    "The XPL language is similar to PL/I, but is not PL/I."

    Here I quote your posting of the Article by Gary:
    " PL/M is a refinement of the XPL compiler-writing language which
    is, in turn, a language with elements from Burroughs Corporation's
    ALGOL and the full set of PL/1. "

    In looking over the examples of XPL I notice there is no DO: identifier
    at the begining of their code examples, and neither is there for
    BDOS.PLM, which is required for the later PL/M Compilers from DRI and
    Intel. Would a XPL compiler parse BDOS.PLM without complaint?
    Reviewing XCOM source, a XPL compiler written in XPL, makes me wonder,
    looks like it would to me.

    In looking around, besides Gaby's, for the CP/M PLM code, I find this
    in DRIPAK.ZIP :
    Volume5.doc :
    *** "
    This is the original .doc file on the cpm user's group
    Volume 5 - this originally contained the source of the
    public domain version of CPM, and the tape was later
    ERASED......

    ------------- start of original ----------

    BASIC-E

    THIS DISKETTE CONTAINS 2 VERSIONS OF THE BASIC-E COMPILER
    BAS2-0 AND BAS2-1, AND THREE VERSIONS OF THE RUN-TIME
    INTERPRETER RUNK2-0, RUN2-2 AND RUN2-3. THE BUGS AND
    RELATIVE MERITS ARE UNKNOWN. TRY THEM. NOTE THAT IN
    THESE VERSIONS, THE COMPILE TIME OPTIONS ARE PLACED IN
    THE COMMAND NOT IN THE FILE - EG "BAS2-1 WUMPUS $B"

    OTHELLO IS OVERFLOW BASIC-E PROGRAM FROM VOLUME 5

    MICROSOFT BASIC (AND SIMILAR)

    THE FILES ???????.ASC ARE ASCII SOURCES OF PROGRAMS WRITTEN
    IN MICROSOFT - TYPE BASIC. PROBABLY NEEDS LITTLE PATCHING
    FOR DEC PDP11 EXTENDED BASIC, TDL AND OTHERS. THE SUFFIX
    ASC IS USED TO DISTINGUISH THEM FROM THE TOKEN FILES WITH
    BINARY LINE NUMBERS, WHICH HAVE .BAS SUFFICES.

    CP/M SOURCE FILES

    THE JUNE 1975 RELEASE OF CP/M IS IN PUBLIC DOMAIN. THE PLM
    AND ASSEMBLY FILES HERE ARE PART OF THAT RELEASE.

    THE FULL RELEASE WAS:

    CCP.PLM
    BDOS.PLM
    PIP.PLM
    LOAD.PLM
    DUMP.ASM
    IOLIB.PLM

    THESE ARE CERTIFIED BY GARY KILDALL TO BE AVAILABLE FOR
    PUBLIC DISTRIBUTION FOR ANY PURPOSE WITHOUT RESTRICTION
    " ***
    However only CCP.PLM, BDOS.PLM and LOAD.PLM are found on Gaby's site
    and also in the DRIPAK.ZIP, the others in the above list are absent. A
    noteworthy thing about the DRIPAK.ZIP is that those PLM files are
    listed in cpm_v1-3 Directory, so perhaps those are that version?
    http://www.retroarchive.org has the DRIPAK.ZIP ;
    http://www.retroarchive.org/cpm/os/os.htm

    There is also a \cpm_v1-4\ and in it a file: IO4OS32.ASM which reads in
    part:
    "
    ; CP/M BASIC INPUT/OUTPUT OPERATING SYSTEM (BIOS)
    ;( TARBELL ELECTRONICS) CVE MOD OF 9-5-81
    ; 1.4 VERSION OF 7-20-79
    ; THIS BIOS CAN ALSO BE USED WITH 1.3 VERSIONS BY
    ; CHANGING BDOS EQU FROM CBASE+3106H TO CBASE+3206H.
    ; (NOTE THAT CP/M VERSION 1.3 ONLY SUPPORTS 2 DRIVES,
    ; WHILE CP/M VERSION 1.4 WILL SUPPORT 4 DRIVES.)
    ;
    "
    This indicates a V1.4 date of 7-20-79, although this is a quote from
    the BIOS source, so is it accurate also for the BDOS version date? It
    seems like a long streatch of time from v1.3 of 06/1975 to v1.4 of
    7/1979.

    The v2.2 source typically carries the date:
    title 'Bdos Interface, Bdos, Version 2.2 Feb, 1980'

    >
    > Whew! Hope it helps...


    Yes, it did, thanks,

    Steve

    > Yours Sincerely,
    > "French Luser"



  14. Re: Tracing the Evolution of CP/M-80

    Herb and Barry have many of the "facts" correctly interpreted or assumed,
    but we (IMSAI) DID have a 1771-based controller; the IMSAI MDIO, that was a
    single-board solution to a 5.25", 35-track controller intended for the lower
    end market. We offered the Shugart 35-track 5.25" drives as standard for
    this system which could support up to four of same.

    The (sub)systems which featured the MDIO included the PCS (Personal Computer
    System) line and VDP-40 (Video Data Processor) system. We sold quite a few
    i.e. perhaps a few thousand between their introduction during IMSAI's second
    phase (early 1977), and 1979 when the original company closed down in
    October of that year. Most serious business and educational users opted for
    the higher capacity DIO/PDS board set which relied on an software supported
    8085-based controller with a very temperamental analog data separator board
    (the Programmable Data Separator). Late 1977 brought out a much more stable
    PDS board that really tightened up reliability in the form of the IMSAI
    PDS-II; developed by a very gifted engineer who worked under Glen Ewing (who
    was now our new Chief Engineer, having replace Jan Vath). This same
    engineer also designed the equally improved RAM-III memory boards that added
    much improved reliability and helped ease the burden of our overworked and
    underpaid Customer Support Department.

    IMSAI never entertained the thought of a hard-sectored disk format, aiming
    instead for the greater data storage capacity of soft-sector ala IBM 3740,
    even though we strayed from the original single sided/single density 8" spec
    when we went for double and even quad density toward the end with variants
    of the DIO/PDS disc controller board set.

    As for CP/M 1.3 and IMDOS, we offered CP/M 1.3 with the original IMSAI
    IFM/FIB controller from very late 1976 until around the middle of 1977 when
    Rob Barnaby (our Chief Programmer) created the much enhanced IMDOS; a direct
    variant of the original CP/M 1.2/1.3. I still have the original hard copy
    source code initialed and serial numbered by Gary Kildall. We had license
    number 3 and were the first and only entity to have unlimited rights to
    source code and distribution at that time.

    All of the module listings in my listing copy are in assembly language, and
    it is my understanding that all development work in version 1.2 and 1.3 was
    done on an Intel MDS system, which both Gary and IMSAI had at their
    respective facilities. Gary would cruise up to our offices in San Leandro
    in his white 1975 Corvette coupe, bring in an armload of greenbar listing
    dumps and a box of Dysan 8" disks, then proceed to the programmer's office
    to work his magic with our hardware, seldom spending even a full day at our
    location.

    In contrast, when Rob Barnaby joined us in 1977, he'd lock himself in his
    office for two or three days at a stretch, programming like a demon and
    sometimes ranting about "some flakiness with his computer", at which point
    myself or my counterpart, John Coons, would work our own brand of magic to
    get him back online and in a better mood. He was difficult to work with and
    understand, but his brilliance and talent outweighed his shortcomings. This
    was the guy who later brought you WordStar, a direct descendent of IMSAI's
    NED (New Editor), and John Coon's "DAISY" and "JUSTINE" proportional print
    drivers that formed the first successful document entry and formatting
    environment, and was used starting in 1977 for in-house document and manual
    preparation.

    But that's another long intrigue, better suited for a later discussion.

    Regards to all,

    -Thomas "Todd" Fischer


    "Herb Johnson" wrote in message
    news:1149808830.818051.17190@c74g2000cwc.googlegro ups.com...
    > Barry Watzman wrote:
    >> Herb,
    >>
    >> Imsai really never moved to a single disk FDC using a WD chip. They
    >> ultimately did offer such a product, but not until very close the end of
    >> IMSAI, and I've never seen that board. The primary move was from the
    >> IFM/FIB 2-board set to the DIO/PDS 2-board set. The former was 8-inch
    >> SSSD only, the latter was quite versatile in terms of formats.

    >
    > A FDC board was mentioned, with a 1771 controller, in the manual noted.
    > I guess they did not produce it. And the manual went on at length about
    > formats for the DIO/PDS set., as you've said. It was a stretch on my
    > part to include a 1771 based board in my IMSAI remarks. But other
    > companies went on to use such chips on their boards. The fact that CP/M
    > could be supportted on boards with that and other FDC chips is notible
    > overall.
    >
    >> Regarding CP/M 1.3 and 1.4, there is less difference than you seem to
    >> think, and it's not where you think.

    >
    > Actually I'm just quoting the IMSAI interview. I've not looked at the
    > IMSAI code myself or the IMSAI docs in any detail this week beyond what
    > I've reported. Don't think I've ever seen CP/M 1.3 as such. I may have
    > poked at IMDOS in my lifetime, on some PDS system decades ago.
    >
    > But it's possible the collaberation described between "IMSAI" and
    > Kildall occurred before CP/M 1.3. That email interview did not mention
    > specific versions, nor did the IMSAI docs I have reviewed mention CP/M
    > versions. The interview did give dates, although they are from memory
    > and even Todd Fischer suggests those dates may be inconsistent. The
    > dates I gave are printed in the IMSAI docs I referenced. What dates can
    > you glean, Barry, from your IMSAI CP/M 1.3 and any related docs for it?
    >
    > My point was to make a case as to why a review of early CP/M code
    > should include IMDOS code. Along the way, I've confirmed most or all of
    > Barry's remarks from memory - that's pretty good for 30-year-old
    > recollections! Between you, Barry, myself (from the IMSAI docs) and
    > Todd's interview notes I think the case is made.
    >
    > The next step is to look at some code, seems to me, and dig up some
    > more docs and disk of the period.
    >
    > Herb Johnson
    >
    > (note: do not send emails to the gmail address for this post. My email
    > address is below.)
    >
    > Herbert R. Johnson, phone 609-771-1417, New Jersey USA
    > web site
    > domain mirror
    > my email address: hjohnson AAT retrotechnology DOTT com
    > if no reply, try in a few days: herbjohnson ATT comcast DOTT net
    > "Herb's Stuff": old Mac, SGI, 8-inch floppy drives
    > S-100 IMSAI Altair computers, docs, by "Dr. S-100"
    >




  15. Re: Tracing the Evolution of CP/M-80


    Group: comp.os.cpm Date: Wed, Jun 7, 2006, 7:34pm (CDT+6) From:
    jce@seasip.demon.co.uk (John*Elliott)

    script:

    >French Luser wrote:
    >
    >>In other words: because one little-known >>computer was using 1041

    does not mean that >>there was a BDOS 4.
    >
    >****Beg to differ. If the BDOS calls itself
    >version 4, then that's what it is, pretty
    >much by definition. If DR hadn't wanted
    >to go to version 4, they could have
    >returned 1034 or 1035 or 1036...
    >
    >****For that matter, the PC1512 wasn't little-known.

    :-)) Thank you John! ((-:

    dowcom

    To e-mail me, add the character zero to "dowcom". i.e.:
    dowcom(zero)(at)webtv(dot)net.

    --
    http://community.webtv.net/dowcom/DOWCOMSAMSTRADGUIDE

    MSWindows is television, Linux is radar.


+ Reply to Thread
Page 2 of 2 FirstFirst 1 2