Here's a project I was tempted to mention on 6502.org -- but it makes more sense to post it here! As you can see from the diagram, this is a computer with two 1.5 MHz 6809 CPU's attached to a common memory array. The "master" CPU (on the left) runs the user application, and the "slave" CPU functions as a smart peripheral. Its main duty is to output memory data at high speed, feeding a video display.

No arbitration and no Wait States are required because the DRAM array is capable of 3 million accesses per second -- enough to fully supply the needs of two CPU's. In hindsight it seems strange that the memory is faster. It's such a conspicuous contrast with modern PC's, whose CPU's are far faster than memory -- so much so that elaborate on-chip caches are the only way to avoid a horrific performance penalty!

Addresses for the video system are generated using a variation on the scheme made popular by Don Lancaster. This involves manipulating a CPU by disconnecting its data bus from RAM and sending it dummy op-codes -- essentially NOP's. In response the CPU produces an ascending sequence on its address bus, fulfilling a function like that of a DMA controller. For more detail please see the section, "Cheap Video and Lying To the Machine," here.

The data fetched can be output as a character-oriented display or in bit-mapped mode. In bit-mapped mode, each byte fetched from memory contains four adjacent bit fields. Each two-bit field corresponds to one pixel on screen. The two-bit value acts as a lookup, selecting one of four gray-scale values stored in a 74_670 register file used as a "palette" RAM. The DAC is a simple weighted resistor network. In character mode basic ASCII encoding applies when bit 7 of the character is clear. Two options are associated with bit 7 being set. Either reverse video appears (courtesy of an XOR gate, not shown), or else custom characters are selected which have been uploaded to the RAM portion of the Character Generator.

Operating two processors from a single memory array involves some fancy footwork in regard to interrupt vectors. In order to provide vectors which are specific to each CPU, one CPU has the top portion of its address map slightly distorted. An XOR gate in address line A8 inverts that signal when the top 512 bytes of RAM are addressed. The effect is to exchange the 256-byte page at $FF00 with the page at $FE00, from one CPU's point of view. Each CPU thinks its vectors are fetched from page $FF00 but -- like the phantom DMA controller mentioned earlier -- it's all done with smoke and mirrors!

I'm pleased to dust off this project (literally) and present it to the anycpu.org forum. The unit itself may be somewhat the worse for wear -- I notice quite a few IC's have gotten "borrowed" over the years -- and my memory of the details is spotty, but I'll do my best to answer questions if there are any.

cheers
Jeff

edit: extra detail in diagram & text

http://LaughtonElectronics.com

I was thinking about doing something like that for video, actually my raster graphics on analog oscilloscope, using one processor to take in commands over a serial line and calculating the graphics array and putting it in the memory, and another processor to keep reading the memory and feeding the 'scope. The first one would take in graphics commands to draw lines and circles and elipses and whatever, plus text with font size and angle and so on, and turn it into the raster-graphics info. It might use more memory than just what the second processor feeds to the 'scope, so it can have overlays and whatnot. I was thinking of using dual-port RAM, but I have not really researched it yet. If I can reduce the number of steps by capitalizing on your experience, is there a reason you did not do it that way?

What about using a 8051 like mcu for feeding the scope?
I found(and bought) a cheap 1k dual port ram on ebay, it is the CY7C130.

Edit: I think we should move this topic under commercial, since it uses commercial CPUs/MCUs.

Yes, that's a good way of putting it -- I should edit the lead post to clarify that. One processor calculates and writes the image to memory, and the other simply reads what's in memory in the course of refreshing the display.

Dual-port RAM is a powerful solution alright. Both CPU's get maximal bandwidth. But I guess you know that might be more bandwidth than is really required, depending on the goals (such as resolution & refresh rate). We could start a new topic for this discussion -- heck, there sure is plenty of space on this forum right now!

As for my 6809 board, the tradeoff is that the RAM is single port and the available bandwidth is divided. (The split is exactly 50:50, since the two CPU's simply take turns; the pattern never varies). But, on the upside, all 64K is shared -- not just a fraction. That means you can have very large bit maps, or even multiple bit maps (for buffering). All memory can be used as display memory.

It also means that code can be shared between the CPU's, as long as the routines are written to be reentrant. I know I said the slave CPU was just for reading & outputting, but in fact during the vertical blanking interval it could could assist the master with calculating the graphics array and putting it in memory. Or, if you were willing to drop some frames, both CPU's could churn away for as long as necessary -- rendering an image, or for that matter doing any other suitable task.

Using modern IC's a project like this could be streamlined quite a bit. Nowadays a single SRAM IC can easily hold the entire 64KB. It'd be feasible to eliminate the '257 multiplexers and hook both processors' address buses directly to the SRAM, activating each processor's Bus Enable on an alternating basis. If you were in a sweat to minimize PCB area, it might even be fairly easy to piggyback the CPU's one on top of the other! Multi-threading 6809's, eh? Hmmmm!!!

cheers
Jeff

Nice. (Data sheet here.)

As for dual-port ram and dual processors, maybe there doesn't need to be a tradeoff with size (per my comments above). Are there 64KByte dual-port rams on the market now, and are they affordable and easy to work with (not insanely fine lead pitch)? I haven't checked.

Nice SBC Jeff!

Thanks, Ed. After poring over the old schematics I was able to post a diagram that shows better detail. And I was mistaken earlier when I stated that the DRAM refresh was software-based, triggered by a periodic interrupt.