Multi user CP/M - CP/M

This is a discussion on Multi user CP/M - CP/M ; How was multi-user ability typically accomplished on the cp/m systems? Was it a task switch / time slice where the same CPU switched between multiple users, or were multiple CPU's used and the hardware shared? Bill H...

+ Reply to Thread
Results 1 to 17 of 17

Thread: Multi user CP/M

  1. Multi user CP/M

    How was multi-user ability typically accomplished on the cp/m systems?
    Was it a task switch / time slice where the same CPU switched between
    multiple users, or were multiple CPU's used and the hardware shared?

    Bill H

  2. Re: Multi user CP/M

    On Sun, 2 Mar 2008 04:54:20 -0800 (PST), Bill H
    wrote:

    >How was multi-user ability typically accomplished on the cp/m systems?
    >Was it a task switch / time slice where the same CPU switched between
    >multiple users, or were multiple CPU's used and the hardware shared?


    Oh, about the same way ''multi-user''s would share say a pocket
    calculator, or an automobile, or a toilet.....

    You could stick multiple processors in a bigger box, allowing one
    CPU per user, but those things usually cost more than the
    equivalent number of stand-alone computers. I suspect it was
    most;y done to make sales easier to Information Technology types
    used to the one-big-processor-many-terminals ''mainframe'' paradigm

    Personal Computer = one user, one computer.

    You're talking about something else.

    Bill


    now...I've got a question....

    In the sixties, we dreamed about what computers could do for
    us, ''one day''. NOBODY wasted time imagining games. Now that
    the 'dream' has arrived, it's a nightmare. The most incredible
    invention of mankind is nothing but a toy. People are losing the
    ability to discern reality from fantasy - belief in magic and such
    is ubitquitous. Microsoft alone has held back development by
    at least twenty years in order to wring maximum profit from their
    crap. Teaching (and learning) in the sciences is unbelievably
    retarded. We need to import > a quarter million engineers a year.

    What went wrong?

  3. Re: Multi user CP/M



    "Bill H" wrote in message
    news:5687418d-57f4-4d6b-80db-4253136a9208@q33g2000hsh.googlegroups.com...
    > How was multi-user ability typically accomplished on the cp/m systems?
    > Was it a task switch / time slice where the same CPU switched between
    > multiple users, or were multiple CPU's used and the hardware shared?


    Multi-user CP/M machines usually had multiple CPU boards.
    MP/M used time-slicing.

    Tom Lake


  4. Re: Multi user CP/M

    CP/M proper was not itself multi-user, but there as another OS offered,
    MP/M (and MP/M-86) which was true multi-user. It time-shared the single
    CPU and all resources. It actually worked fairly well within the limits
    of the CPU and memory available (banked memory was supported in MP/M-II,
    the 2nd version of the 8080 variant of MP/M). It worked better than
    most people expected it to work or would believe, today, that it
    probably would have worked.


    Bill H wrote:
    > How was multi-user ability typically accomplished on the cp/m systems?
    > Was it a task switch / time slice where the same CPU switched between
    > multiple users, or were multiple CPU's used and the hardware shared?
    >
    > Bill H


  5. Re: Multi user CP/M

    On Sun, 2 Mar 2008 04:54:20 -0800 (PST), Bill H
    wrote:

    >How was multi-user ability typically accomplished on the cp/m systems?
    >Was it a task switch / time slice where the same CPU switched between
    >multiple users, or were multiple CPU's used and the hardware shared?
    >
    >Bill H


    If you mean multiuser with each running independent applications you
    are looking at MP/M or multiple cpus running CP/M (one per user) and
    MP/M as a server to those cpus all on the same bus.

    If you mean multiple users interactive with the same program such as
    a databse or game you could do that as cooperative multiuser on
    CP/M but the application must be written to accout for the
    interactions of the users and all.

    Bottom line CP/M single user real time OS without task scheduling
    and MP/M allowed for multitasking/multiuser via mnultiple CPUs or
    time slicing.

    FYI Altair(MITS) and NS* also had a version of their software that did
    time
    slice multiuser.


    Allison

  6. Re: Multi user CP/M

    On 2008-03-02, Jim Higgins wrote:
    > On Sun, 02 Mar 2008 18:23:22 GMT, Roger Ivie
    > wrote:
    >
    >>On 2008-03-02, Bill wrote:
    >>> In the sixties...

    > And then there's the holodeck...


    Holodeck didn't happen 'til the 80s.
    --
    roger ivie
    rivie@ridgenet.net

  7. Re: Multi user CP/M

    >>>> In the sixties...
    >> And then there's the holodeck...


    >Holodeck didn't happen 'til the 80s.


    During my recent Ubiqitious / Pervasive computing course,
    I was reminded how Star Trek was really NOT that futursitic
    about how computers and computing technology would occur.
    They were right about portable/hand-held units
    but they were all specialized (communicator,
    medical/engineering tri-corder, blinky-light clip-boards)
    whereas Space 1999's "Com-link" was the best guess at today's cellphone
    (communicator with 2 way TV a-la Dick Tracy, door lock, computer console, etc).
    And none originally guessed that computers would have enough
    spare CPU cycles or memory to be used for recreation.

  8. Re: Multi user CP/M

    On 2 Mar 2008 19:35:27 -0500, Jeff Jonas wrote:

    >>>>> In the sixties...
    >>> And then there's the holodeck...

    >
    >>Holodeck didn't happen 'til the 80s.

    >
    > During my recent Ubiqitious / Pervasive computing course,
    > I was reminded how Star Trek was really NOT that futursitic
    > about how computers and computing technology would occur.
    > They were right about portable/hand-held units
    > but they were all specialized (communicator,
    > medical/engineering tri-corder, blinky-light clip-boards)
    > whereas Space 1999's "Com-link" was the best guess at today's cellphone
    > (communicator with 2 way TV a-la Dick Tracy, door lock, computer console, etc).
    > And none originally guessed that computers would have enough
    > spare CPU cycles or memory to be used for recreation.


    Nonsense.

    The AIM65 was bought by a friend of mine exactly because it could play a
    game (I think it was an adventure type); and I seem to remember a primitive
    game that I played with the Digicomp1.

    There weare countless other recreational activities - making lineprinters
    play music and so on.

  9. Re: Multi user CP/M

    On Tue, 04 Mar 2008 00:28:24 GMT, _
    wrote:

    >On 2 Mar 2008 19:35:27 -0500, Jeff Jonas wrote:
    >
    >>>>>> In the sixties...
    >>>> And then there's the holodeck...

    >>
    >>>Holodeck didn't happen 'til the 80s.

    >>
    >> During my recent Ubiqitious / Pervasive computing course,
    >> I was reminded how Star Trek was really NOT that futursitic
    >> about how computers and computing technology would occur.
    >> They were right about portable/hand-held units
    >> but they were all specialized (communicator,
    >> medical/engineering tri-corder, blinky-light clip-boards)
    >> whereas Space 1999's "Com-link" was the best guess at today's cellphone
    >> (communicator with 2 way TV a-la Dick Tracy, door lock, computer console, etc).
    >> And none originally guessed that computers would have enough
    >> spare CPU cycles or memory to be used for recreation.

    >
    >Nonsense.
    >
    >The AIM65 was bought by a friend of mine exactly because it could play a
    >game (I think it was an adventure type); and I seem to remember a primitive
    >game that I played with the Digicomp1.
    >
    >There weare countless other recreational activities - making lineprinters
    >play music and so on.


    I think the whole point was StarTrek and other SF missed the boat with
    computers as entertainment. Most SF had a military mindset of the
    computer is there to navigate, run the engine, aim the guns or do
    science related activity. However a few, and very few would have
    the computer play chess or interact in a more entertaining way.

    Allison

  10. Re: Multi user CP/M

    On Mar 2, 4:00 pm, "Tom Lake" wrote:
    > "Bill H" wrote in message
    >
    > news:5687418d-57f4-4d6b-80db-4253136a9208@q33g2000hsh.googlegroups.com...
    >
    > > How was multi-user ability typically accomplished on the cp/m systems?
    > > Was it a task switch / time slice where the same CPU switched between
    > > multiple users, or were multiple CPU's used and the hardware shared?

    >
    > Multi-user CP/M machines usually had multiple CPU boards.
    > MP/M used time-slicing.
    >
    > Tom Lake


    MP/M used a preemptive priority-based real-time multitasking
    scheduler.
    It also supported cooperative multitasking in systems without real-
    time
    clock interrupts. It was quite advanced for its time, even the 8080
    version
    supported queue-based inter-process communications, flags, multiple
    terminals, bank switching and was virtually fully compatible with CP/
    M.

    Hector.


  11. Re: Multi user CP/M

    On Mar 2, 5:15 pm, Barry Watzman wrote:
    > CP/M proper was not itself multi-user, but there as another OS offered,
    > MP/M (and MP/M-86) which was true multi-user. It time-shared the single
    > CPU and all resources. It actually worked fairly well within the limits
    > of the CPU and memory available (banked memory was supported in MP/M-II,
    > the 2nd version of the 8080 variant of MP/M). It worked better than
    > most people expected it to work or would believe, today, that it
    > probably would have worked.


    Both 8080 versions supported bank-switching. IIRC, MP/M-II
    added a file/record locking mechanism, and used a variant
    of the CP/M-3 BDOS (MP/M 1 used CP/M 2.2 BDOS)

    Hector

  12. Re: Multi user CP/M

    hperaza wrote:
    > On Mar 2, 4:00 pm, "Tom Lake" wrote:
    >> "Bill H" wrote in message
    >>
    >> news:5687418d-57f4-4d6b-80db-4253136a9208@q33g2000hsh.googlegroups.com...
    >>
    >>> How was multi-user ability typically accomplished on the cp/m systems?
    >>> Was it a task switch / time slice where the same CPU switched between
    >>> multiple users, or were multiple CPU's used and the hardware shared?

    >> Multi-user CP/M machines usually had multiple CPU boards.
    >> MP/M used time-slicing.
    >>
    >> Tom Lake

    >
    > MP/M used a preemptive priority-based real-time multitasking
    > scheduler.
    > It also supported cooperative multitasking in systems without real-
    > time
    > clock interrupts. It was quite advanced for its time, even the 8080
    > version
    > supported queue-based inter-process communications, flags, multiple
    > terminals, bank switching and was virtually fully compatible with CP/
    > M.
    >


    I have a working OSM box... it runs OS/M, which, is kind of a mix of
    cp/m 2.2/ + cp/m 3.0 + mp/m... what I like about it best is all console,
    etc is 100% serial, no funky video boards to explode! It has a whopping
    21MB hdd, 21MB tape, and 8" disk! I still need to refurbish the tape
    deck, but I had refurbished the power supply some time ago. The "master"
    cpu actually runs a slightly modified cp/m 2.2, and feeds "processor
    cards" containing 4 z80 each on an internal 9600 baud parallel network.
    so the network runs at 9.6kBytes/sec (9600 * 8 bits in parallel) and
    despite what you might think, it's actually pretty snappy.

  13. Re: Multi user CP/M

    On Mar 10, 12:41*pm, "Andrew J. Kroll" wrote:
    > hperaza wrote:
    > > On Mar 2, 4:00 pm, "Tom Lake" wrote:
    > >> "Bill H" wrote in message

    >
    > >>news:5687418d-57f4-4d6b-80db-4253136a9208@q33g2000hsh.googlegroups.com....

    >
    > >>> How was multi-user ability typically accomplished on the cp/m systems?
    > >>> Was it a task switch / time slice where the same CPU switched between
    > >>> multiple users, or were multiple CPU's used and the hardware shared?
    > >> Multi-user CP/M machines usually had multiple CPU boards.
    > >> MP/M used time-slicing.

    >
    > >> Tom Lake

    >
    > > MP/M used a preemptive priority-based real-time multitasking
    > > scheduler.
    > > It also supported cooperative multitasking in systems without real-
    > > time
    > > clock interrupts. It was quite advanced for its time, even the 8080
    > > version
    > > supported queue-based inter-process communications, flags, multiple
    > > terminals, bank switching and was virtually fully compatible with CP/
    > > M.

    >
    > I have a working OSM box... it runs OS/M, which, is kind of a mix of
    > cp/m 2.2/ + cp/m 3.0 + mp/m... what I like about it best is all console,
    > etc is 100% serial, no funky video boards to explode! It has a whopping
    > 21MB hdd, 21MB tape, and 8" disk! I still need to refurbish the tape
    > deck, but I had refurbished the power supply some time ago. The "master"
    > cpu actually runs a slightly modified cp/m 2.2, and feeds "processor
    > cards" containing 4 z80 each on an internal 9600 baud parallel network.
    > so the network runs at 9.6kBytes/sec (9600 * 8 bits in parallel) and
    > despite what you might think, it's actually pretty snappy.- Hide quoted text -
    >
    > - Show quoted text -

    ---
    There was also Cromemco's Cromix, a sort-of-UNIX that also ran
    multiple CP/M and CDOS programs. The first version ran everything on a
    single 4MHz Z80 using bank switching; then came the DPU and XPU, dual-
    processor cards that ran Cromix on a 68000/68010 and switched to the
    Z80 when needed, while the later 68020+ single processor cards used
    the Z80 on one of the I/O co-processors.

    mike

  14. Re: Multi user CP/M

    Bill H wrote:
    > How was multi-user ability typically accomplished on the cp/m systems?
    > Was it a task switch / time slice where the same CPU switched between
    > multiple users, or were multiple CPU's used and the hardware shared?
    >
    > Bill H

    A bit OT, but the "other" multi-user CP/M contender (and the only one I
    know anything about) was TurboDOS from Software 2000. It basically left
    most of the multitasking implementation up to the system builder.

    Usually it worked out as a dedicated "master" computer (CPU,Memory, I/O,
    bus interface) with a number of almost identical "slaves", one physical
    slave per user. Most interprocessor comms was done with semaphores and
    simple FIFO utilities - declare a global FIFO pool, assign per-user
    access rights, and each user can send and receive from their FIFO. Even
    many file operations (buffering, read and write journalling) was done
    through FIFOs in many implementations. The good part was, that as long
    as you built your common interprocessor channel right, you could put any
    kind of processor on the other end almost transparently - so some users
    could have an 80186 CPU with a meg of dedicated physical RAM running
    TurboDOS86, sending great gobs of data to a user with a 6MHz Z80B with
    128k of banked memory.

    Clumsy? yes! elegant? no! worked? nyeahh, kind of. Mostly. Until you got
    to more than tens of users, where physical limitations like the size of
    the power supply got way out of hand (I built and maintained one
    installation with 22 parallelled switchmode power supplies in the bottom
    of a 9-foot high 19" rack. SOunded like a hovercraft, and we needed four
    of them for 122 users. Oh the horror.)

    Some companies then started to implement SDLC high-speed serial
    networks, kind of like precursors to clusters, but were usurped by the
    coaxial ether thingy. Whatever it was, I'm sure it never lasted...

    --
    --
    "I want to die peacefully in my sleep, like my grandpa, not screaming
    and crying, like the passengers in his car." -Unremembered source from
    the (19)90's.

  15. Re: Multi user CP/M

    On Mar 2, 8:54 am, Bill H wrote:
    > How was multi-user ability typically accomplished on the cp/m systems?
    > Was it a task switch / time slice where the same CPU switched between
    > multiple users, or were multiple CPU's used and the hardware shared?


    In a traditional CP/M Forth system, typically using cooperative round-
    robin with a serial card per User task. So a CP/M system used that way
    would have used task-switch on I/O access or explicit call to PAUSE.

    Of course, Forth was multi-tasking and multi-programming from the
    beginning, and a full 64K RAM CP/M 2.2 system with drives was a
    substantial step up from the original "minicomputer" systems that
    Chuck Moore started out developing the multi-tasker for ... the
    DDP-116 had 16KB and the H316 had 32KB, and the persistent store was
    tape.

    Mind you, comfortably supporting multiple users in that way required
    that all the software be in Forth, since it was running as a single
    user and single task and performing the multi-tasking itself ... one
    more factor in the tendency of the early traditional Forths to not
    play well with others.

  16. Re: Multi user CP/M

    On Wed, 02 Apr 2008 00:43:08 +1100, PC Pete
    wrote:

    >Bill H wrote:
    >> How was multi-user ability typically accomplished on the cp/m systems?
    >> Was it a task switch / time slice where the same CPU switched between
    >> multiple users, or were multiple CPU's used and the hardware shared?
    >>
    >> Bill H

    >A bit OT, but the "other" multi-user CP/M contender (and the only one I
    >know anything about) was TurboDOS from Software 2000. It basically left
    >most of the multitasking implementation up to the system builder.
    >
    >Usually it worked out as a dedicated "master" computer (CPU,Memory, I/O,
    >bus interface) with a number of almost identical "slaves", one physical
    >slave per user. Most interprocessor comms was done with semaphores and
    >simple FIFO utilities - declare a global FIFO pool, assign per-user
    >access rights, and each user can send and receive from their FIFO. Even
    >many file operations (buffering, read and write journalling) was done
    >through FIFOs in many implementations. The good part was, that as long
    >as you built your common interprocessor channel right, you could put any
    >kind of processor on the other end almost transparently - so some users
    >could have an 80186 CPU with a meg of dedicated physical RAM running
    >TurboDOS86, sending great gobs of data to a user with a 6MHz Z80B with
    >128k of banked memory.
    >
    >Clumsy? yes! elegant? no! worked? nyeahh, kind of. Mostly. Until you got
    >to more than tens of users, where physical limitations like the size of
    >the power supply got way out of hand (I built and maintained one
    >installation with 22 parallelled switchmode power supplies in the bottom
    >of a 9-foot high 19" rack. SOunded like a hovercraft, and we needed four
    >of them for 122 users. Oh the horror.)
    >
    >Some companies then started to implement SDLC high-speed serial
    >networks, kind of like precursors to clusters, but were usurped by the
    >coaxial ether thingy. Whatever it was, I'm sure it never lasted...
    >
    >--



  17. Re: Multi user CP/M

    On Wed, 02 Apr 2008 00:57:15 GMT, no.spam@no.uce.bellatlantic.net
    wrote:

    >On Wed, 02 Apr 2008 00:43:08 +1100, PC Pete
    > wrote:
    >
    >>Bill H wrote:
    >>> How was multi-user ability typically accomplished on the cp/m systems?
    >>> Was it a task switch / time slice where the same CPU switched between
    >>> multiple users, or were multiple CPU's used and the hardware shared?
    >>>
    >>> Bill H

    >>A bit OT, but the "other" multi-user CP/M contender (and the only one I
    >>know anything about) was TurboDOS from Software 2000. It basically left
    >>most of the multitasking implementation up to the system builder.
    >>
    >>Usually it worked out as a dedicated "master" computer (CPU,Memory, I/O,
    >>bus interface) with a number of almost identical "slaves", one physical
    >>slave per user. Most interprocessor comms was done with semaphores and
    >>simple FIFO utilities - declare a global FIFO pool, assign per-user
    >>access rights, and each user can send and receive from their FIFO. Even
    >>many file operations (buffering, read and write journalling) was done
    >>through FIFOs in many implementations. The good part was, that as long
    >>as you built your common interprocessor channel right, you could put any
    >>kind of processor on the other end almost transparently - so some users
    >>could have an 80186 CPU with a meg of dedicated physical RAM running
    >>TurboDOS86, sending great gobs of data to a user with a 6MHz Z80B with
    >>128k of banked memory.
    >>
    >>Clumsy? yes! elegant? no! worked? nyeahh, kind of. Mostly. Until you got
    >>to more than tens of users, where physical limitations like the size of
    >>the power supply got way out of hand (I built and maintained one
    >>installation with 22 parallelled switchmode power supplies in the bottom
    >>of a 9-foot high 19" rack. SOunded like a hovercraft, and we needed four
    >>of them for 122 users. Oh the horror.)
    >>
    >>Some companies then started to implement SDLC high-speed serial
    >>networks, kind of like precursors to clusters, but were usurped by the
    >>coaxial ether thingy. Whatever it was, I'm sure it never lasted...
    >>
    >>--


    oops wrong button...

    Anywho you hit the key problem square on the nose. While it works the
    limitations of CPU speed, memory size, bus speed and then system
    size(physical) limited the number of CPUs that were possible. The key
    was CPU speed then was adaquate for a single users applications and
    having a server do the disk and other inter cpu work helped but not
    enough to make it reasonable to do more than a few users per cpu.
    In the end it was a CPU per user thing.

    Most of the intel/zilog machines didn't multitask well as the code
    needed to save and restore the users state was very costly (in cpu
    cycles). so the more tasks and the more interactive the tasks got the
    more CPU bound you were. Using a faster chip helps but the bottleneck
    is still there.

    I went through the exercise of multiple cpus in the ealy 80s and found
    that one really fast (8mhz) Z80 did better than two 6mhz parts by any
    standard used. In the end big memory, fastest possible CPUs work
    better. It also helps if the CPU has an archetecture that helps or
    actively supports things that aid multitasking like a good integrated
    MMU and better instruction set.

    Allison

+ Reply to Thread