Dual port ram

[BigEd]

(Ah, of course, yes, you have a need to share a slow peripheral too. So indeed, normally you'd generate both the fast and slow clocks from the same circuit, so you know the phase relationships and can switch or stretch. It's tricky to do this safely, but it's something which has often been done.)

It would be great to see a block diagram! A picture being worth a thousand words.

[KhanTyranitar]

I actually need to update my block diagram.

The final design will probably have either a CPLD or a FPGA, but I have no experience with those. The initial proof of concept (on protoboard) may end up using simple logic gates. But I need to have a good block diagram to lay that out.

It look like I've gotten a few good ideas from this discussion so far. I guess for me to go much further the rough logic diagram must be completed. That will take its own thread. In the mean time I think I'm pretty close to both confirming that the dual port RAM will in fact work and does in fact solve problems without introducing any new problems that aren't easily resolved.

[KC9UDX]

It will be interesting to see if you run into problems using P6 and P7. I've seen examples of software that assumes the unused bits should be 1 and some that assumes they should be 0. But that situation may be as rare as using the unsupported opcodes.

[KhanTyranitar]

KC9UDX wrote:

It will be interesting to see if you run into problems using P6 and P7. I've seen examples of software that assumes the unused bits should be 1 and some that assumes they should be 0. But that situation may be as rare as using the unsupported opcodes.

Officially according to Commodore, just like any register where you change selected bits, you should OR or XOR to change only the ones you want and leave the others untouched. How many programmers follow this convention? I don't know. Obviously such software could cause unexpected behavior.

As far as unsupported opcodes, they are very common in the demo scene. But if something doesn't work, I won't run it. Or I'll have to try my hand at patching it.

[KhanTyranitar]

Related question. In an application where there is only 4 data lines (yeah, 4 bit) can I use an 8 bit chip? Will that represent a problem? I would assume that I only connect the 4 low byte lines.
My reason for asking is that apparently Commodore installed a 1k 4 bit RAM as the Color RAM in a C64. But in my design, assuming the 4bit limitation doesn't present a problem, can I use 8 bit RAM instead? Or is there a technical reason it won't work?

[BigDumbDinosaur]

KhanTyranitar wrote:

Related question. In an application where there is only 4 data lines (yeah, 4 bit) can I use an 8 bit chip? Will that represent a problem? I would assume that I only connect the 4 low byte lines.
My reason for asking is that apparently Commodore installed a 1k 4 bit RAM as the Color RAM in a C64. But in my design, assuming the 4bit limitation doesn't present a problem, can I use 8 bit RAM instead? Or is there a technical reason it won't work?

You would connect the unused data bits to ground. You don't want them to be floating.

[KhanTyranitar]

BigDumbDinosaur wrote:

KhanTyranitar wrote:

Related question. In an application where there is only 4 data lines (yeah, 4 bit) can I use an 8 bit chip? Will that represent a problem? I would assume that I only connect the 4 low byte lines.
My reason for asking is that apparently Commodore installed a 1k 4 bit RAM as the Color RAM in a C64. But in my design, assuming the 4bit limitation doesn't present a problem, can I use 8 bit RAM instead? Or is there a technical reason it won't work?

You would connect the unused data bits to ground. You don't want them to be floating.

Ok thanks.

[BigEd]

Strictly it feels like you should connect through resistors, because they are bidirectional signals. Although in practice there might be no issue - the circuit writes zeros and reads them back. But it will eagerly be reading before any writes have been done.