Ram Card Design Help - CP/M

This is a discussion on Ram Card Design Help - CP/M ; On Fri, 26 Oct 2007 05:08:00 -0400, CBFalconer wrote: >no.spam@no.uce.bellatlantic.net wrote: >> >... snip ... >> >> This hits on the next step that CP/M (any) never achieved which is >> virtualization or memory and application space. To do this ...

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

Thread: Ram Card Design Help

  1. Re: Ram Card Design Help

    On Fri, 26 Oct 2007 05:08:00 -0400, CBFalconer
    wrote:

    >no.spam@no.uce.bellatlantic.net wrote:
    >>

    >... snip ...
    >>
    >> This hits on the next step that CP/M (any) never achieved which is
    >> virtualization or memory and application space. To do this with
    >> CP/M you need a fine grained mapper of say 4K balancing code space
    >> and overhead and code to allocate, deallocate and keep a catalog of
    >> whos where. The implication is multitasking on either cooperative
    >> or preemptive basis and possibly both. Even simple cooperative
    >> with something like ESC-TAB to switch from task A to B to C and so
    >> on is a useful addition. The closest to this that most would know
    >> is Handyman in rom as on Kaypros. There are issues doing this
    >> under CP/M but are solvable.

    >
    >I supplied virtual code-space under CP/M. This was possible
    >because the code-space was read-only, and didn't require hardware
    >to virtualize. See the PascalP system.


    I've done it to a point as well and it worked very nice. Of course
    NONE of the usual CP/M programs take advatage of it directly.
    The handiest was being able to run one ap, open a partition
    and start another and bounce back and forth. Sorta like having
    multiple machines and one keyboard.

    Allison

    >--
    > Chuck F (cbfalconer at maineline dot net)
    > Available for consulting/temporary embedded and systems.
    >



  2. Re: Ram Card Design Help

    On Fri, 26 Oct 2007 15:05:17 +0200, Udo Munk
    wrote:

    >On Fri, 26 Oct 2007 03:00:22 +0000, no.spam wrote:
    >
    >> On Tue, 23 Oct 2007 20:18:44 -0700, Herb Johnson
    >> wrote:
    >>
    >>>On Oct 21, 10:31 pm, Grant Stockly wrote:

    >...
    >>>But READ THE MANUALS to see what various companies did. Enough S-100
    >>>manuals are on line that you can find some memory board manuals and
    >>>look them over. But also pay attention to Udo et al, who want to run
    >>>MP/M and other OS's. You might ask Chuck Falconer and others who
    >>>supported CP/M compatible OS's to see what banking they supported.

    >>
    >> Uzi Unix wasnted (needed!) banked memory and 4K pages would be about
    >> right.

    >
    >When it comes to Unix and the like, just paged memory is not good enough,
    >stuff is not that easy. You also need a MMU that is capable of generating
    >page faults, whenever a JMP is made to a page not mapped and whenever a
    >memory read/write is made to a page not mapped. Such a MMU must be coupled
    >pretty close with the CPU, because it needs to know what address the CPU
    >is going to use, and then trap that based on some tables. I don't
    >know it anyone ever build such a MMU for the Z80, probably not worth the
    >afford because of other CPU/MMU combinations available, that can do this.
    >This is why DRI used another process model for MP/M, with a common
    >segment for the OS entry, and one bank for every running process. They
    >made a design failure with that 16kb common segment, don't know why. A 4kb
    >common is enough for the OS entry, as CP/M 3 shows. Then you would have
    >lots of 60kb banks to run processes and all that very efficient.
    >Also the Z80 can't use virtual addresses, it's limited to a 16bit address
    >space.


    I'm ignoring unix...

    For the cp/m case, MPM took a sane approach. I did take another.
    The assumption however was an up front no program will exceed
    60k and for most CP/M programs out there that is valid. The system
    then could swap a programs space, and create a sized space in ram
    for an application. The programs if they crash would do so in their
    space and it they touch the system page (F000h) an interupt was
    forced ( in hardware)

    The Z280 can exceed the 16bit space as it has both the MMU
    and the I&D space split.

    >> With 4K scatter/gather efficientcy is higher. Also applications can ask
    >> for thram they need and the manager can set that space aside and put the
    >> program there for it's time slice. The management cost is modest and
    >> hardware easy being basically a pair of 74189 or similar plus glue. This
    >> is closest to the mapper used in Z280 and also the PDP11.

    >
    >If you write in assembler and think a lot about segmenting your programs,
    >that can be done, yes. On systems like Unix you just want to write real
    >huge programs and don't be bothered with the memory management, kernel
    >does it all for you. If you want to do page faults just with software, you
    >need to inspect every JMP and every MOV, if it would address memory
    >outside the current active page. Writing a C compiler that does this is
    >quite a challenge, and it's a lot of overhead.


    Again unix... It's nice if the system can.

    I cheated. I said never exceed 60k and the OS will grant it and track
    it. If for some reason you ask for 60k and there is not enough ram
    left the system finds a program (least recently used) and pushes it to
    disk and uses the recovered space. The idea is Z80 programs are
    generally small but multiple tasks require many spaces often less than
    16 or 32K. It's a small system model not an attempt ot make a Z80
    into a VAX.

    >
    >I could build a descent MMU for a virtual Z80, because there I get at it
    >innermost parts. No point in doing it tho, because probably no one will
    >build it in silicon then. Could be done with PGA's of course, but why?
    >There are much better CPU/MMU combinations readily available. Even the Z80
    >got improved ages ago and has been replaced with better CPU/MMU.


    Depends on which one you call better. Z8000 was interesting as was
    the Z380.

    Clearly a 32 or better 64 bit cpu solves the address space issues
    and they also support page faults and the like. I was trying to apply
    big ideas in a scaled way.


    Allison

    >
    >Udo Munk



  3. Re: Ram Card Design Help

    On Fri, 26 Oct 2007 22:54:40 +0000, no.spam wrote:

    > On Fri, 26 Oct 2007 15:05:17 +0200, Udo Munk
    > wrote:

    ....
    > I'm ignoring unix...


    I'm totally ignorant about Windows :-)

    > For the cp/m case, MPM took a sane approach. I did take another. The
    > assumption however was an up front no program will exceed 60k and for
    > most CP/M programs out there that is valid. The system then could swap
    > a programs space, and create a sized space in ram for an application.
    > The programs if they crash would do so in their space and it they touch
    > the system page (F000h) an interupt was forced ( in hardware)


    Yep, that is something else to keep in mind, it should be possible to
    write-protect the common memory, or generate an interrupt on write to the
    area, so that the OS can be protected.

    > The Z280 can exceed the 16bit space as it has both the MMU and the I&D
    > space split.


    Right, that one is more useful for more advanced stuff.

    >>> With 4K scatter/gather efficientcy is higher. Also applications can
    >>> ask for thram they need and the manager can set that space aside and
    >>> put the program there for it's time slice. The management cost is
    >>> modest and hardware easy being basically a pair of 74189 or similar
    >>> plus glue. This is closest to the mapper used in Z280 and also the
    >>> PDP11.

    >>
    >>If you write in assembler and think a lot about segmenting your
    >>programs, that can be done, yes. On systems like Unix you just want to
    >>write real huge programs and don't be bothered with the memory
    >>management, kernel does it all for you. If you want to do page faults
    >>just with software, you need to inspect every JMP and every MOV, if it
    >>would address memory outside the current active page. Writing a C
    >>compiler that does this is quite a challenge, and it's a lot of
    >>overhead.

    >
    > Again unix... It's nice if the system can.


    Yeah, well, other OS's can do too if the hardware is given. I know
    how this stuff is done in the Unix kernel, so I used it as example.

    > I cheated. I said never exceed 60k and the OS will grant it and track
    > it. If for some reason you ask for 60k and there is not enough ram left
    > the system finds a program (least recently used) and pushes it to disk
    > and uses the recovered space. The idea is Z80 programs are generally
    > small but multiple tasks require many spaces often less than 16 or 32K.
    > It's a small system model not an attempt ot make a Z80 into a VAX.


    Yes, the swapping can be done with a Z80 too, that won't be a problem.

    > Clearly a 32 or better 64 bit cpu solves the address space issues and
    > they also support page faults and the like. I was trying to apply big
    > ideas in a scaled way.


    Right so, trying this too, so I hope the discussion helped a bit.

    > Allison


    Udo Munk
    --
    The real fun is building it and then using it...


  4. Re: Ram Card Design Help

    On Fri, 26 Oct 2007 22:36:32 +0000, no.spam wrote:
    ....
    > I've done it to a point as well and it worked very nice. Of course
    > NONE of the usual CP/M programs take advatage of it directly.
    > The handiest was being able to run one ap, open a partition
    > and start another and bounce back and forth. Sorta like having
    > multiple machines and one keyboard.
    >
    > Allison


    Hm, but that's just what MP/M is about. You detach terminal from the
    current running program, start another one and switch between the
    programs, by attaching terminal to one of them.

    Udo Munk
    --
    The real fun is building it and then using it...


  5. Re: Ram Card Design Help

    On Sat, 27 Oct 2007 01:34:06 +0200, Udo Munk
    wrote:

    >On Fri, 26 Oct 2007 22:36:32 +0000, no.spam wrote:
    >...
    >> I've done it to a point as well and it worked very nice. Of course
    >> NONE of the usual CP/M programs take advatage of it directly.
    >> The handiest was being able to run one ap, open a partition
    >> and start another and bounce back and forth. Sorta like having
    >> multiple machines and one keyboard.
    >>
    >> Allison

    >
    >Hm, but that's just what MP/M is about. You detach terminal from the
    >current running program, start another one and switch between the
    >programs, by attaching terminal to one of them.



    True, but I was more interested in using what I had in 1982 and that
    was V2.2.

    Allison
    >Udo Munk



  6. Re: Ram Card Design Help

    On Sat, 27 Oct 2007 01:25:04 +0200, Udo Munk
    wrote:

    >On Fri, 26 Oct 2007 22:54:40 +0000, no.spam wrote:
    >
    >> On Fri, 26 Oct 2007 15:05:17 +0200, Udo Munk
    >> wrote:

    >...
    >> I'm ignoring unix...

    >
    >I'm totally ignorant about Windows :-)


    I'm not but sometimes I wish I were. It's mind pollution.

    >
    >> For the cp/m case, MPM took a sane approach. I did take another. The
    >> assumption however was an up front no program will exceed 60k and for
    >> most CP/M programs out there that is valid. The system then could swap
    >> a programs space, and create a sized space in ram for an application.
    >> The programs if they crash would do so in their space and it they touch
    >> the system page (F000h) an interupt was forced ( in hardware)

    >
    >Yep, that is something else to keep in mind, it should be possible to
    >write-protect the common memory, or generate an interrupt on write to the
    >area, so that the OS can be protected.
    >
    >> The Z280 can exceed the 16bit space as it has both the MMU and the I&D
    >> space split.

    >
    >Right, that one is more useful for more advanced stuff.
    >
    >>>> With 4K scatter/gather efficientcy is higher. Also applications can
    >>>> ask for thram they need and the manager can set that space aside and
    >>>> put the program there for it's time slice. The management cost is
    >>>> modest and hardware easy being basically a pair of 74189 or similar
    >>>> plus glue. This is closest to the mapper used in Z280 and also the
    >>>> PDP11.
    >>>
    >>>If you write in assembler and think a lot about segmenting your
    >>>programs, that can be done, yes. On systems like Unix you just want to
    >>>write real huge programs and don't be bothered with the memory
    >>>management, kernel does it all for you. If you want to do page faults
    >>>just with software, you need to inspect every JMP and every MOV, if it
    >>>would address memory outside the current active page. Writing a C
    >>>compiler that does this is quite a challenge, and it's a lot of
    >>>overhead.

    >>
    >> Again unix... It's nice if the system can.

    >
    >Yeah, well, other OS's can do too if the hardware is given. I know
    >how this stuff is done in the Unix kernel, so I used it as example.
    >
    >> I cheated. I said never exceed 60k and the OS will grant it and track
    >> it. If for some reason you ask for 60k and there is not enough ram left
    >> the system finds a program (least recently used) and pushes it to disk
    >> and uses the recovered space. The idea is Z80 programs are generally
    >> small but multiple tasks require many spaces often less than 16 or 32K.
    >> It's a small system model not an attempt ot make a Z80 into a VAX.

    >
    >Yes, the swapping can be done with a Z80 too, that won't be a problem.


    I'd almost forgotten. During that time I was doing most everything in
    Z80 asm and I'd written a macros for jump long and call long to get
    around the out of 64k pool problem. The macros were really a
    subroutine to get another allocation or ram, set the program counter
    inside the code and then catually do a jump to some lower address.
    The call did that and saved the return address and page. Essentially
    making all of the page fault logic inside the program. Basically I
    arrived at it by making a possible fault, not possible except by a
    bug. There was never an intent to try and protect the OS save for
    limiting space used. Later I added hardware to detect an attempted
    write to OS protected space and if it happened force an interrupt
    and reporting an illegal write and halting that ap. It was an
    interesting exercise both software and some extensive hardware.

    In the end since no ap ever used extended memory I started playing
    with banked BIOS where the return on effort was higher (63k+ tpa).

    No when I build a system I don't bother with more than 96K of ram
    and usually as three 32k low pages Rom, ram0 and ram1, and the
    upper page as ram allways. It's simple and allows for banked
    bios and maybe a few small background functions. It's a lot simpler
    and cheaper.

    Allison

    >
    >> Clearly a 32 or better 64 bit cpu solves the address space issues and
    >> they also support page faults and the like. I was trying to apply big
    >> ideas in a scaled way.

    >
    >Right so, trying this too, so I hope the discussion helped a bit.
    >
    >> Allison

    >
    >Udo Munk



+ Reply to Thread
Page 2 of 2 FirstFirst 1 2