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 shared memory array. 65C02 and Hitachi 6309 would also have been viable CPU choices, but in the pre-Internet early 80's when I built this, 6809 seemed like the hottest thing going! The "master" CPU (on the left) runs the user application, and the "slave" CPU on the right functions as a smart peripheral. The slave CPU can run normal code, but its main duty is as the address counter for a Don Lancaster style "Cheap Video" system, rapidly reading consecutive memory locations so the data can be output as pixels.

The two CPU's require no arbitration and no Wait States because the DRAM array is capable of 3 million accesses per second -- twice what each CPU requires, allowing the two to simply take turns on alternate clock phases. Nowadays it seems strange that the memory speed is double that of the CPU's. 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 horrific performance penalties!

The video system teases anomalous behavior out of the slave CPU by disabling the '245 that connects its data bus to RAM and instead feeding the CPU dummy op-codes -- essentially NOP's -- throughout each horizontal scan line. In response, the CPU produces a linear, 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.

In this particular machine, the byte strings fetched from RAM can be output either in bit-mapped mode or as a character-oriented display.

• In bit-mapped mode, each byte fetched from memory contains four adjacent two-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 a 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. Whenever that CPU accesses the top 512 bytes in the 64K range, an XOR gate in address line A8 inverts that signal before it gets sent to RAM. The effect is to exchange the 256-byte page at $FF00 with the page at $FE00, but only 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!

Of course the 6809 is a highly Forth-ophilic CPU! And, right from the start, my goal was that this machine would run FIG Forth. I'd had an offer to supply the necessary files (this was pre-Internet, remember); but, as more and more time went by, it became clear I would either have to find another source or manually type in the code myself (I did have printed FIG doc on hand). Instead the project got shelved, because during the delay an even more ambitious Forth project had caught my fancy. I'm pleased with this dual 6809 design -- well, mostly! -- and maybe someday I'll pick it up again, but so far the machine has gotten no further than some basic debugging of the I/O and video systems.

Today I'm happy 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
edit: More tweaks. Fix broken link. Mention 6309 and 65C02. Add 2nd-last paragraph.

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.