6502 coprocessor using dual-port RAM

[plasmo]

Gordon's recent posts about W65C134 reminds me of my dual-port RAM based multi-6502 design. It is not so much a design than a sandbox to play and add more features. The basic idea is two 6502 sharing a 4K dual port RAM. The main 6502 processor set aside 4K RAM space for the dual port RAM, but the coprocessor only has 4K for program and data. an under-utilized CPLD provides the glue logic between these two processors. There are plenty of logic left in the CPLD to add more features, whatever those may be.

At reset the coprocessor is in reset waiting main processor to write to a magic location to release the reset. The 4K dual port RAM is mapped to both coprocessor's top 4K (reset, interrupt, NMI vectors) as well as the bottom 4K (zero page, stack). The main processor first writes reset vector, interrupt vectors to top of 4K and whatever application program; write to a magic location to release the reset; and communicate to coprocessor via dual port RAM and interrupts.

The board is not standalone; it is meant to plug into a RC6502 style connector as shown in the picture.

I don't have a specific application in mind, but I'm encouraged by what Gordon is able to do with W65C134. I thought a video coprocessor to drive BadApple may be interesting; it can also bit-bang SPI, serial, I2C, PS2,so on.
Bill

[Dr Jefyll]

Looks like a dangerous amount of fun, Bill! A sandbox like that is one big Solution Looking For A Problem!

FWIW, I'll share a little fantasy of my own. How often have we see a code sequence something like this:

Code: Select all

LDA  (MyPointer)
INC  MyPointer
BNE $+2
INC MyPointer+1

Since we have two CPU's available, maybe the main CPU should do only the first instruction -- the LDA. Then it'd immediately hurry on to attend to other important business... and leave the helper CPU with the mundane task of updating the pointer for next time! (I guess this implies there'd be an interrupt issued to call attention to the chore.)

A pretty wacky idea, I admit. But in some circumstances the performance boost could pretty substantial... for example, if the pointer were being used at the heart of a Forth inner interpreter or as dispatch for some other Virtual Machine.

-- Jeff

[Proxy]

facny concept, but DPRAM is usually pretty slow which would limit not only the Co-Processor's clock speed but also the overall bandwidth through it, plus they can be expensive if you're unlucky.
while it would make logic a bit more complicated, you could get away with using regular SRAM and some extra stuff to have an external Processor access it when the Co-Processor is paused.

the W24512AK-10 for example is a single 64kB 10ns SRAM chip that could be mapped to the whole 65C02's Address space, making decoding logic very very simple which could allow the CPU to run at insane speeds.
if you're using a CPLD you have more than enough room for logic that gives the main system some control, like sending an NMI to the Co-Processor, resetting it, or pausing it (ie pulling BE+RDY low) to allow access to it's memory through some tri-state buffers.
then you could also do some very minimal communication in the other direction, for example when the Co-Processor writes to address $0000 it sends an interrupt to the main system.
the whole thing could be done in 6 ICs (plus a clock), making for a very compact little card.

i did toy around with this exact idea before, with a 65816 based system that has slots for multiple of those "compute cards" that would each take up 1 bank in the 65816's memory space and some extra logic to capture every card's interrupt signal and stuff like that.

[plasmo]

Oh good, lots of interesting ideas already.

"Big Solution Looking For A Problem" is exactly correct. I have to confess that this is not my first dual-port-ram-coprocessor design. There is one for Z80 for about 4 years now that looks the same. 6502.org has many innovative members and I am hopeful many interesting ideas will come. This particular dual port RAM (IDT7134) has several semaphore flags that I don't know how to use. NMI, IRQ, and RDY (perhaps I should include BE as well?) can be generated from main processor to coprocessor. I'm intrigued by the notion of programmable RDY that allows coprocessor to run programmable number of cycles. The CPLD is intentionally under-utilized to allow experimentation. I use this dual port RAM as video buffer for 25MHz Z80 and 6502, so I know it is fast enough to handle inter-processor communication up to 25MHz 6502.

IDT7134 is one of my "essential" IC that is used in many designs. It is inexpensive, $2 each in quantity, and I keep it stocked up at 50 pcs level. I hardly ever sell them so they are for my own tinkering; in fact, I need to order more.
Bill

[Agumander]

Quote:

IDT7134 is one of my "essential" IC that is used in many designs. It is inexpensive, $2 each in quantity, and I keep it stocked up at 50 pcs level. I hardly ever sell them so they are for my own tinkering; in fact, I need to order more.

What speed of IDT7134 have you been using? I've been trying to source cheap 7134's but had terrible luck with getting actual working 20ns chips like I need. The listings I find don't list the speeds, so I get assorted bags where even some of the ones labelled for 20ns don't work. My success rate is low enough to justify buying them from Mouser for full price.

[barnacle]

And mouser is listing their cheapest part at over twenty euros in bulk...

Neil

[fachat]

You can run two 6502 on the same (data) bus with 180° clock shift. Just switch the address on the shared RAM and you can use single port RAM instead of dual port.

[gfoot]

Indeed, you just need to take a little care around the transitions, e.g. truncating the PHI2 clocks a bit and delaying write-enable until a while after the address bus transition takes place.

[plasmo]

Agumander wrote:

What speed of IDT7134 have you been using? I've been trying to source cheap 7134's but had terrible luck with getting actual working 20ns chips like I need. The listings I find don't list the speeds, so I get assorted bags where even some of the ones labelled for 20ns don't work. My success rate is low enough to justify buying them from Mouser for full price.

My source for IDT7134 is UTSource. The specific part is IDT71342LA35J so it is a 35nS part. It is involved mostly in video application with 25.175MHz clock. The video controller is reading it continuously from one port at 25MHz and Z80-class processor is reading/writing the other port. Lately I'm replacing Zx80 with 25MHz 6502 and find it capable of supporting 25MHz read/write which is effectively 20nS access time.
Bill

[barnacle]

I'm trying to get my head around how one can do this and still maintain the requirement for active chip select prior to ph2 rising to keep a 6522 happy - though in my case I'm using BE to actively disable the 6502 while a resistor-coupled address signal is supplied from the video circuit.

At the moment, my design has a 2.5MHz clock, so 200ns half-clock. I'm currently disabling BE for the first 100ns of the ph2 low, clearing it for the second half and for all of ph2 high - which ought to let everything run including a (non-essential) 6522; grabbing the video data as BE goes high. The ram is 45ns so it should have plenty of time, if the decoding is fast enough. I'll find out when I build it!

Neil

[plasmo]

I flirted with Apple II style video using single port RAM and a CPLD to manage switching between video controller and 6502. It was 1-1/2 year ago so I need to revisit the design, but I recall the video portion is 25MHz, but I can only run 6502 at 12.6MHz.
Bill
Edit, my feeling is in case of dual 6502, single-port RAM may work with help of CPLD, but the speed may be limited.

[barnacle]

I wonder if you just need a non-overlapping clock generator and quick enough ram? I vaguely remember the 6800 as needing such a beastie...

Neil

[Dr Jefyll]

On the subject of a single RAM receiving its address alternately from two different CPUs, it might be worth considering using a FET-based bus switch as mux. There's a major advantage in regard to speed, because the usual notion of propagation delay (as with a conventional mux) doesn't apply. Instead, the signal path through the switch behaves very much as a resistor, on the order of 10 ohms or less. Based on the capacitance of the load (in this case the address inputs of the RAM), you do end up with an RC delay, but it'll be almost negligible -- just a fraction of a ns!

I'm attaching a screen shot from a 2004 TI selection guide. Various logic families are represented, and I find the "Mux/Demux" and "Bus Exchange" offerings especially intriguing...

-- Jeff

[plasmo]

Oooh, I think a non-overlapping clock with significant dead zone is a very interesting idea!

[Proxy]

fachat wrote:

You can run two 6502 on the same (data) bus with 180° clock shift. Just switch the address on the shared RAM and you can use single port RAM instead of dual port.

feel like the timings would be way too tight to do that between 2 seperate boards. plus that would requite both CPUs to run at the same speed, while DPRAM (or the compute card concept i mentioned) would allow both CPUs to run at different speeds. plus it wouldn't scale beyond 2 CPUs without slowing them down.

plasmo wrote:

My source for IDT7134 is UTSource

eyy, that's also where i get all my ATF150x CPLDs, IDT720x FIFOs, and 8/16kB IDT700x DPRAM chips from as well.
though my DPRAM chips are much slower at 55ns. so sadly i can't run them at high speeds, even for video stuff 12.5MHz is roughly the fastest i can go.
that's where a Co-Prcoessor with it's own fast single port SRAM would come in handy. then you could use slower DPRAM for the interface to the main system (or some FIFOs to take up less memory space)

.

wouldn't even having 2 non-overlapping clocks have the same scaling issues (ie having more than 2 CPUs on the same bus will reduce the speed of each individual CPU) as running 2 CPUs on 1 clock with opposite phases?