Hi all,

Does anyone have any reference on how to share ram in a system? For example - let's say I want to pump some bits to an dac to output some music - so I have another circuit that cycles thru an address range to get the audio bits out.... My question is how to connect that ram into my main raim bank so my cpu can place data into it.

I figure I need some isolating ic's and some sort of buffer to hold data to write into the ram while the ram is being accessed by the audio output section, but I'm really not sure how to attack this.

Any links would be appreciated.

_________________
-Tony
KG4WFX

I would use the 6502/65816's support for alternating clock phases on this one.

Let the DMA engine cycle through memory via phase-1. Let the CPU access the RAM on phase-2. That way, the clock signal doubles as an input to the address bus MUX, and depending on other control signals, also decides when to enable one of two data bus transceivers.

If the memory is going to be accessed at a different clock speed than the CPU, then the CPU will have to wait for a window when it can safely access the RAM. Use the RDY line (for the 65816) for this purpose, OR, you can synchronize the CPU clock with the memory clock.

(Whatever was going through Chuck Peddle's head when he decided the 6502 won't wait if RDY is negated during a write operation must have been drug-induced, if you ask me. Yet another reason to switch to the 65816!)

There's also dual-port RAM, made by Cypress ( www.cycpress.com ) and other companies.

I've done what you're talking about many times Tony, but always used interrupts instead of some special hardware scheme.

Hi Garth,

I've been thinking of the dual port but I was thinking of having a fairly large buffer - between 64K and 256K - and the dual port chips are just sooo expensive, a 32kx8 is about $28... I was hoping to get it a bit cheaper, or to find some other solution...

kc5tja: Conveniently enough I'm using a 65816.

Overall tho I was hoping to find a way to allow the cpu to continue on its business while the other circuit is doing its thing.

Interrupts could work, I'll just have to see if I can mangle it into the design...

I really wanted to do dual port ram, if it wasn't so darn expensive....

_________________
-Tony
KG4WFX

So, I guess I'm confused then -- why would the CPU have to wait for the audio circuitry, if the CPU is able to access non-audio RAM? Or are you intending all of system RAM to be accessible from the audio hardware? As I envisioned it, the CPU would have to be synchronized with the audio subsystem only when touching audio memory.

> Overall tho I was hoping to find a way to allow the cpu to continue on
> its business while the other circuit is doing its thing.
>
> Interrupts could work, I'll just have to see if I can mangle it into the
> design...

Depending on the sample rate (it's only audio-- I'm sure you'll be under 45,000 interrupts per second) and the µP clock speed, the interrupts will not take a very high percentage of the µP's time. But to keep the jitter down to an acceptable level, you might need to use the NMI if other things are using IRQ at the same time. Edit: I have a discussion of jitter at http://wilsonminesco.com/6502primer/potpourri.html#JIT.

With my 5MHz 65c02 workbench computer doing 44,000 8-bit samples per second on interrupts with little other related overhead, the performance penalty to other jobs running simultaneously is noticeable but not major. It gets to be more major when I'm doing a little software anti-alias filtering or something like that. It's nice in the experimenting however to still have the 65c02 computer able to simultaneously process commands to change coefficients and sampling rates, or even assemble or compile new pieces of programming (in Forth) to implement on the fly instead of stopping the sampling for every operation. It's one of many situations I've had where simple interrupts give the illusion of full multitasking if not multiprocessing. [Edit, 5/15/14: I posted an article on simple methods of doing multitasking without a multitasking OS, at http://wilsonminesco.com/multitask/index.html.]

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

Just a quick note about dual-ported RAM chips. They have a WAIT signal that can be asserted if/when both ports attempt to access the same byte. This implies that one port can take priority over the other (i.e. make the other port wait). So, you must allow for that in your design. Most likely, you'd make the CPU wait so that the analog system can maintain a constant sample rate.

Personally, I'd go for a two-phase scheme based on the Phase2 signal. CPU accesses the RAM when Phase2 is high, DAC accesses when it's low. I'm looking at a design that'll use this scheme for access to video memory. You'll need a set of address multiplexers that switch over with Phase2, and a data bus buffer that can route CPU and DAC accesses properly.

Hi all,

Let me be clear on something - audio was just an example - it's a scheme I'd like to use for several things if possible, including, but not limited to data recording and shared video ram. I suppose audio was a poor choice to put forth as audio is sooooo slow, it would be easy to do on a shared clock scheme, read a bye, and hold the output for a given length of time based upon sampling rate, 50-60ns difference in between reads wouldn't be a real problem considering at a 44KHz sample rate your talking one byte represents ~22.7 uS and that is a long time compared to the 10MHz cpu clock, to a point where a 2 byte buffer in the output circuitry would be all that would be needed to guarantee that you remain within the proper timing.

But, when it comes to video which I would like to use this scheme for as well - I'm a little more stumped.

I mean, at 640x480 in vga w/ 25.175MHz clock 60hz refresh, that is about 40ns per pixel if I understood what I've read correctly - the timing I can't see how to make it work, I'm sure there has to be a way with shared ram, but I just don't see it. at a 10MHz system clock, best case scenario of the video system having an entire half cycle is 50ns, with a 50ns delay before the next time it can access the ram. I'm sure I'm just looking at this the wrong way which is what is causing me so much trouble.

Dual port ram would be much easier to work with overall, but the cost on it is just rather difficult to absorb. I know there has to be a way to do this with single port ram.

you mentioned that you were looking at a process coredump - is there a reference your basing this on or experimentation or what?

_________________
-Tony
KG4WFX

OK -- I'm basing my design on a combination of classic 8-bit machines: BBC Micro, Acorn VDU card and the UK101's video circuit. But I'm also arranging for it to work with a 2MHz bus speed, and for it to support a 6809 (or 6309) CPU chip as well as the 6502 (or 65C02). One crucial point is that for a Phase2-based scheme to work, the bus speed and the VDU scan rates are interlinked. In the UK101, the VDU generates 64 characters per line, and actually uses the middle 48 columns (the rest is margins and blanking). To do this, the basic VDU clock is 1MHz, so a 1MHz bus could be synchronised to it. The UK101 doesn't actually do this, so it suffers from "snow" on the VDU during CPU access. The BBC Micro has a 2MHz bus, and runs the VDU at 2MHz, avoiding "snow" and giving an 80 column display (128 character cells per scan-line).

As for your VGA display, remember that there's an 8-bit shift register between the VDU RAM and the TV output, so the RAM can be run at one-eighth of the pixel clock. The UK101 uses a 74165 for this function, clocked at 8MHz. I plan to do the same, but clock it at 16MHz. My design is for PAL, of course (50Hz frame, 15.625kHz line).

Oh, and I can also recommend "The CRT Controller Handbook", by Gerry Kane, for more info about this topic.

I think I understand what's being asked here... for two processors or subsystems to share the same RAM.

Turning the way back machine, way, way back I once used a 6809 card which ran in a an Apple II. As I remember they both used the same memory, in fact that was how one would transfer data between the two processors. Unfortunatley I don't remember the name of the board, but I'll bet someone does, and looking at the schematic of the 6809 board and the Apple II board just might help. If this helps, good, if not, sory to have taken up the space.

Later,

Andy

This is something that I'd be really interested in doing also. It's been talked about a few times on the NESdev hardware forum, but I haven't had or heard any ideas that I could actually implement by myself. Maybe I'm just hoping there's an easy way, heheh.

On an NES cartridge there's 2 buses, one for the CPU (1.789Mhz) and one for the graphics (PPU - 2.68Mhz). And like any other game consoles, the CPU can only write to PPU memory when the screen isn't being rendered.

The inverted Phi2 setup sounds like the best solution, unfortunately the NES PPU doesn't output a signal like that (there is /RD and /WR though).

I've seen cheap SRAM as fast as 12 and 15ns, seems like if the control logic is fast enough there's some pretty nice possibilities.

Some thoughts (please note that I could be wrong in a large variety of ways)...

For video, especially high-performance video, there's a few options. In the good old days, they'd use VRAM, which has one random-access port and a serial-access port. I've never tried to build something around it, but it takes advantage of the fact that DRAM really has rows and columns, and you can end up with 1024 columns or rows, therefore letting you load an entire row or column at once into a shift register internal to the VRAM chip. So you hang the random-access port off of the main bus and then put the serial-access port under the control of the video logic. Or they'll use burst-mode, page-mode, or EDO DRAM (which lets you do roughly the same thing, but more general purpose and single-port) which let you read an entire column or row of DRAM at a time on the main port.

Or you just have 8 bit pixels and a 32 bit wide DRAM array, with tri-state buffers to bridge the gap to an 8 bit bus on the CPU side and a shift register on the video side.

It would be awful useful to make a relatively minimalist contention-logic block that people can use in their designs. Because it's not always good enough to "steal" cycles from the processor when it's not accessing memory. I'm thinking that you need a tri-state buffer on one side, a tri-state latch on the other side, and some logic to halt the latch-using-side until the buffer-using side is finished. Or just two latches, if neither side has hard deadlines.

You could use a software trick in lieu of real synch logic, depending. The latch-using side could have a flip-flop wired to an IO location in memory. The processor does a write and then spinlocks (meaning it loops as long as the IO location isn't set to zero) before writing the next byte. This works if there isn't a ready line or other such thing to use to halt the execution of the current instruction. I'm not sure if you are saving gates or using more gates this way, however.