Cross-CPU Communications

Question

So - I have a little situation. I have a MC68000 as my system's main CPU, and a 68008 as my sound CPU to interface with a YM2612 and my RGB video generator. Right now, I'm just going to stop the sub CPU whenever I need to tell it something, but that seems horridly inefficient.

I've programmed the Sega Mega Drive before, and they implement a concept of "Comms RAM" which is basically a part of memory one CPU can write to and the other reads. How would I implement something like this without bus collisions?

Answer 1

What you are referring to can be accomplished with a "dual-port RAM", which allows simultaneous access of the same memory location using on-chip arbitration logic.

They are available from 1KB to several MB, and are not cheap -- a 16KB device costs $30 in quantities of 1, and $22 in hundreds at Digi-Key. Here is a datasheet for the device. I assumed you wanted an 8-bit interface since you are interfacing one side of it to a 68008. You can find more devices at Digi-Key searching for "dual port".

Answer 2

I don't recall the details of the 68K series well enough, but here's the gist of an idea: if your RAM is fast enough, and the two CPU clocks are derived from the same master oscillator, you may be able to get conflict-free access by interleaving. Motorola used a scheme like this with the 6809/6847/6883 chip set, where the 6809 CPU got the bus during the E clock high, and the 6847 video chip got it during the E clock low times. It worked b/c each bus master could complete a read or write in one cycle, and they were synchronized from the same clock.

If I recall, the 68K had capability to stretch memory access across several clocks using DTACK or BUSERR to complete the cycles. Just because it can stretch clocks doesn't mean it has to, or even should. If your RAM is fast enough, which is a distinct possibility given modern static RAM and the probably low 68K clock rate, you might be able to run with DTACK grounded, to get down into the realm of single-cycle access. The only wrinkle is whether you have something like the 6800 E clock with a 68K and with the 68008. It's worth looking at, b/c if you can make it work, neither CPU has to slow down and you get glitch-free shared memory.

Answer 3

Assuming either is allowed to address a common bus - and this is not clear from description, then you can transfer data blocks with two semaphore bits.Bits in RAM imply shared non-collision access. But bits can be on port pins- see below.

Many moons since I last did this but it should be as simple as

• Master: Deposit data. Set "Data ready"
• Slave: Read data. Set "Data taken"
• Master: Reset "Ready" (first). Reset "taken" cycle complete.

If your hardware does not allow this directly you can implement a hardware device that flips from bus to bus using a similar protocol with the "bits" on port pins. (Slight change in handshaking but same principle).(M:Take this, S:OK, M:Noted, S:Thanks = eg GPIB)

BUT - why limit yourself to "genuine shared RAM" when you can achieve a functionally equivalent result with a coms link?. Speed may be a reason. How much speed do you need. Some of the methods below can be very fast.

There are a large number of serial interconnect schemes that allow this sort of interaction - some made for interprocessor use and some easily enough adapted. SPI, IIC (multimaster), RS485 ( ... CAN), and even / of course RS232. When all else fails there is "ethernet" in all its variants (up to ~Gb/s) or USB (up to hundreds of Mb/s.)