7779Re: Parallelf memory map
- Jul 1, 2011Hello 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:
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.Right, without an OS this would not really work.
> The more flexibility you build in the greater complexity and debugging.
> I've done this on S100 bus with Z80s and it was fun, enlighteningThat 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.
> 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 simplestTrue, 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. :)
> 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.
- << Previous post in topic Next post in topic >>