Loading ...
Sorry, an error occurred while loading the content.

Re: Parallelf memory map

Expand Messages
  • ajparent1
    ... If you ponder it long enough the issue is task oriented or process oriented. In one the whole task is dedicated to a cpu and may share resources like ram,
    Message 1 of 10 , Jul 1 4:23 PM
    • 0 Attachment
      --- In cosmacelf@yahoogroups.com, "Richard" <r.dienstknecht@...> wrote:
      >
      > Good morning!
      >
      > Yes, I think you are right. Up to now I had been busy coming up with a practicable concept, now it's time to write down what I have and what not. If I had not to go to work right now, I would get on it right away.
      >


      If you ponder it long enough the issue is task oriented or process oriented. In one the whole task is dedicated to a cpu and may share resources like ram, io or whatever. The other the process decomposed and serialized so that one cpu does say input stream processing, the next does some further work to the data and the third though N do more with the last outputting the results. One may dictate a configuration but the tasks at hand may not be efficiently performed with that topology.

      There are many issues to overcome locking and prioritizing the who gets what resource first when there are multiple requests. Job overlap and inter-job or inter-task communications to be resolved.
      The more flexibility you build in the greater complexity and debugging.

      I've done this on S100 bus with Z80s and it was fun, enlightening
      and loads of work. But the end result was not faster by much.

      An alternate approach is build a 1802 in TTL (or fast CMOS) and run at 20mhz or faster. As CPUs go the 1802 is one of the simplest
      and going faster has it's potential when you consider most run
      it at sub 3mhz. This has been done for many other classic cpus but 1802 has not been to my knowledge done. I've pondered it but every time I find myself wondering down the road to a stretched 16 or 32bit variant with byte oriented bus and instructions.


      Allison
    • Richard
      Hello Allison, indeed you mention some things which are on top of the list at the moment. ... Besides deciding between those two points, there also are more
      Message 2 of 10 , Jul 1 11:32 PM
      • 0 Attachment
        Hello Allison,

        indeed you mention some things which are on top of the list at the moment.

        > If you ponder it long enough the issue is task oriented or process oriented. In one the whole task is dedicated to a cpu and may share resources like ram, io or whatever. The other the process decomposed and serialized so that one cpu does say input stream processing, the next does some further work to the data and the third though N do more with the last outputting the results. One may dictate a configuration but the tasks at hand may not be efficiently performed with that topology.

        Besides deciding between those two points, there also are more things to think about. I started out with getting myself one of those boards:

        http://www.conrad.de/ce/de/product/521238/EURO-BUS-PLATINE-EP-2032-x-128/SHOP_AREA_14742&promotionareaSearchDetail=005

        Sorry, the shop is in German, but you can at least take a good look at the board. It's simply a bus which offers ten slots. The connectors are a standard (at least over here) and are therefore easy to get and not too expensive. The connectord have 96 pins, which should be plenty for everything we may want to put onto the bus.

        At the moment I have worked on three different boards, of which only two are needed to get the basic configuration running.

        The first board holds the shared logic for the CPUs. Right now this would be the logic to provide the CPUs with clock signals and synchronize their access to the bus. Also, there are a 32k ROM and a 32k RAM. Those two are not supposed to be shared. Instead, each CPU gets its own private 4k portion of both. The ROM is intended for booting and the RAM is supposed to provide a fixed private memory space for each CPU's stack and similar private data.

        The second board would, obviously, be a CPU board. Right now it is really just a CPU and the logic for the bus multiplexer. Depending on the pc board layout, one board can then hold two or perhaps three CPUs.

        Getting those two things working should be the first milestone. It's not really useful. Just up to eight single board computers with 4k ROM and RAM each. Still, it would be an important step before moving on to the more complicated things. Especially the synchronization of the bus multiplexers is one thing I would like to have working before going on.

        The third board is the RAM. It is shared by all CPUs in 32k pages and each CPU can select one of up to 256 pages at any time. A fully eypanded Parallelf therefore can have up to 8 mb shared RAM. I had a hard time finding a suitable SRAM (runs at 5V, no SMD, easy to get, low price and as big as possible), so the memory board holds only 4 mb right now and two boards would be needed to go all the way.

        Once we get here, we really must think about some things. Obviously, this computer will not work with at least a basic operating system and there still is no IO. As much as I would like it for flexibility, I see some problems with making the IO ports shared as well. At the moment my best idea is a specialized CPU board with all IO ports in one spot.

        > There are many issues to overcome locking and prioritizing the who gets what resource first when there are multiple requests. Job overlap and inter-job or inter-task communications to be resolved.
        > The more flexibility you build in the greater complexity and debugging.
        >

        Right, without an OS this would not really work.

        > I've done this on S100 bus with Z80s and it was fun, enlightening
        > and loads of work. But the end result was not faster by much.

        That depends very much on what you are doing. Some tasks require such heavy synchronization between processes or threads that you really gain little or nothing. Others, like graphics rendering, can be executed in parallel with little synchronization and can profit a lot.

        > An alternate approach is build a 1802 in TTL (or fast CMOS) and run at 20mhz or faster. As CPUs go the 1802 is one of the simplest
        > and going faster has it's potential when you consider most run
        > it at sub 3mhz. This has been done for many other classic cpus but 1802 has not been to my knowledge done. I've pondered it but every time I find myself wondering down the road to a stretched 16 or 32bit variant with byte oriented bus and instructions.

        True, but then I also could get myself some FPGA. Or emulate the whole thing on a PC. While I'm absolutely willing to throw overboard all things which no longer are useful (like hex keyboards and LED displays), I would not like to throw the 1802 overboard as well. For the full 1978 look and feel I have my old Elf II, but no 1802, no Elf. :)


        Richard
      • Paul Backhouse
        Same shop, english version..... http://www1.conrad-uk.com/scripts/wgate/zcop_uk/~flN0YXRlPTI5MDk4Mzc1MTI=?di
        Message 3 of 10 , Jul 2 6:36 AM
        • 0 Attachment
          Same shop, english version.....

          http://www1.conrad-uk.com/scripts/wgate/zcop_uk/~flN0YXRlPTI5MDk4Mzc1MTI=?di
          rekt_aufriss_area=SHOP_AREA_14736&~template=PCAT_AREA_S_browse&p_page_to_dis
          play=&catalogs_sub_id=sub6&aktiv=6&navi=oben_2

          PB

          -----Original Message-----
          From: cosmacelf@yahoogroups.com [mailto:cosmacelf@yahoogroups.com]On
          Behalf Of Richard
          Sent: 02 July 2011 07:33
          To: cosmacelf@yahoogroups.com
          Subject: [cosmacelf] Re: Parallelf memory map



          Hello Allison,

          indeed you mention some things which are on top of the list at the moment.

          > If you ponder it long enough the issue is task oriented or process
          oriented. In one the whole task is dedicated to a cpu and may share
          resources like ram, io or whatever. The other the process decomposed and
          serialized so that one cpu does say input stream processing, the next does
          some further work to the data and the third though N do more with the last
          outputting the results. One may dictate a configuration but the tasks at
          hand may not be efficiently performed with that topology.

          Besides deciding between those two points, there also are more things to
          think about. I started out with getting myself one of those boards:

          http://www.conrad.de/ce/de/product/521238/EURO-BUS-PLATINE-EP-2032-x-128/S
          HOP_AREA_14742&promotionareaSearchDetail=005

          Sorry, the shop is in German, but you can at least take a good look at the
          board. It's simply a bus which offers ten slots. The connectors are a
          standard (at least over here) and are therefore easy to get and not too
          expensive. The connectord have 96 pins, which should be plenty for
          everything we may want to put onto the bus.

          At the moment I have worked on three different boards, of which only two
          are needed to get the basic configuration running.

          The first board holds the shared logic for the CPUs. Right now this would
          be the logic to provide the CPUs with clock signals and synchronize their
          access to the bus. Also, there are a 32k ROM and a 32k RAM. Those two are
          not supposed to be shared. Instead, each CPU gets its own private 4k portion
          of both. The ROM is intended for booting and the RAM is supposed to provide
          a fixed private memory space for each CPU's stack and similar private data.

          The second board would, obviously, be a CPU board. Right now it is really
          just a CPU and the logic for the bus multiplexer. Depending on the pc board
          layout, one board can then hold two or perhaps three CPUs.

          Getting those two things working should be the first milestone. It's not
          really useful. Just up to eight single board computers with 4k ROM and RAM
          each. Still, it would be an important step before moving on to the more
          complicated things. Especially the synchronization of the bus multiplexers
          is one thing I would like to have working before going on.

          The third board is the RAM. It is shared by all CPUs in 32k pages and each
          CPU can select one of up to 256 pages at any time. A fully eypanded
          Parallelf therefore can have up to 8 mb shared RAM. I had a hard time
          finding a suitable SRAM (runs at 5V, no SMD, easy to get, low price and as
          big as possible), so the memory board holds only 4 mb right now and two
          boards would be needed to go all the way.

          Once we get here, we really must think about some things. Obviously, this
          computer will not work with at least a basic operating system and there
          still is no IO. As much as I would like it for flexibility, I see some
          problems with making the IO ports shared as well. At the moment my best idea
          is a specialized CPU board with all IO ports in one spot.

          > There are many issues to overcome locking and prioritizing the who gets
          what resource first when there are multiple requests. Job overlap and
          inter-job or inter-task communications to be resolved.
          > The more flexibility you build in the greater complexity and debugging.
          >

          Right, without an OS this would not really work.

          > I've done this on S100 bus with Z80s and it was fun, enlightening
          > and loads of work. But the end result was not faster by much.

          That depends very much on what you are doing. Some tasks require such
          heavy synchronization between processes or threads that you really gain
          little or nothing. Others, like graphics rendering, can be executed in
          parallel with little synchronization and can profit a lot.

          > An alternate approach is build a 1802 in TTL (or fast CMOS) and run at
          20mhz or faster. As CPUs go the 1802 is one of the simplest
          > and going faster has it's potential when you consider most run
          > it at sub 3mhz. This has been done for many other classic cpus but 1802
          has not been to my knowledge done. I've pondered it but every time I find
          myself wondering down the road to a stretched 16 or 32bit variant with byte
          oriented bus and instructions.

          True, but then I also could get myself some FPGA. Or emulate the whole
          thing on a PC. While I'm absolutely willing to throw overboard all things
          which no longer are useful (like hex keyboards and LED displays), I would
          not like to throw the 1802 overboard as well. For the full 1978 look and
          feel I have my old Elf II, but no 1802, no Elf. :)

          Richard






          [Non-text portions of this message have been removed]
        • thinkpast
          I ve read Allison s comments and Richard s reply. My impression is that Richard is really looking at this project as building a prototype, to see where it
          Message 4 of 10 , Jul 5 10:18 AM
          • 0 Attachment
            I've read Allison's comments and Richard's reply. My impression is that Richard is really looking at this "project" as building a prototype, to see where it will take him. So I think my request for a "design document", is simply premature and off the point. I thought he was further along in design.

            The point seems to be, to have some discussion here as Richard builds his design, which he's designing as he goes. Since there's no real application or piece of software or other real "things" to design TO - no standards - then he's pretty free to do whatever the 1802 allows him to do.

            I appreciate Allison's points, but as she points out these sort of designs produce only modest improvements in "performance". Since there's no application to "perform", that's kind of moot. I don't mean to be annoying but with nothing at "stake", either a result or performance criteria, how does one make any choices among alternatives?

            So I wish Richard luck. It will be interesting to see what he implements. "The proof of the pudding is in the eating," results trump what-if's. He's encouraged me to think about it, as he's also encouraged others who have given him their thoughts. That seems to be what's going on with this particular project.

            Herb Johnson
          Your message has been successfully submitted and would be delivered to recipients shortly.