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?


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".

  • \$\begingroup\$ I was considering dual port RAM for quite a while, but it's not cheap, quite sadly. I'm probably just going to settle for a small 8-bit memory inside my CPLD that both CPUs can access. \$\endgroup\$ – Tristan Seifert Nov 29 '11 at 3:14
  • \$\begingroup\$ You can get similar or better results on Digikey by filtering the products list for Memory, and selecting "Memory Type" - SRAM - Dual-port. \$\endgroup\$ – Kevin Vermeer Nov 29 '11 at 4:11
  • \$\begingroup\$ I might just be going for a 1kbit memory. It's $6, but it'd solve all these issues I have pretty much immediately and give me more memory than I could ever need. \$\endgroup\$ – Tristan Seifert Nov 29 '11 at 15:48

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.

  • \$\begingroup\$ This idea does sound interesting, as both CPU clocks are the same from the same clock divider that divides a 20MHz oscillator. I'm assuming I would just run it through an inverter to get this? \$\endgroup\$ – Tristan Seifert Nov 29 '11 at 3:18
  • \$\begingroup\$ @TristanSeifert - whatever it takes to get them on opposite phases of the clock, if that's possible. \$\endgroup\$ – JustJeff Nov 29 '11 at 12:05
  • \$\begingroup\$ Amiga extensively uses "channels" to share access to "CHIP" ram between blitter, sound and CPU. I think it's the same principle. \$\endgroup\$ – Prof. Falken Jan 7 '12 at 12:41

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.)

  • \$\begingroup\$ While this sounds like a great idea, sadly the MC68000 is data and address bus based so at most I can control the individual data bits, but only for a short time. \$\endgroup\$ – Tristan Seifert Nov 29 '11 at 3:18
  • 1
    \$\begingroup\$ You have custom peripheral ICs available that provide async and synchronous 68000 comms and you can easily address non system specific parts like a parallel UART. And you can easily set up a one byte latch that can be written by one processor and read by the other - a 1 Byte dual port RAM and then handshake between the two. This is all well within its little brother MC6800 capability. 68000 is not less capable. \$\endgroup\$ – Russell McMahon Nov 29 '11 at 6:57
  • \$\begingroup\$ Sounds very workable! \$\endgroup\$ – Prof. Falken Jan 7 '12 at 12:42

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.