Dual port ram

[BigDumbDinosaur]

KhanTyranitar wrote:

Ok, so PH0 is only for timing the CPU. My CPU (65816) does not have a PH1 or PH2 output which means I must generate those signals externally. What is the cleanest way to generate those signals? Flip-flop?

Two-Phase Clock Generator

[BigEd]

?? Surely in the case of an '816 system, one must use the CPU's input clock as the (only) timing reference. There's no need for any other clock.

[BigDumbDinosaur]

BigEd wrote:

?? Surely in the case of an '816 system, one must use the CPU's input clock as the (only) timing reference. There's no need for any other clock.

You are correct. Where the Ø1 signal would be useful is in the bank latching circuit. I don't even generate Ø1 on POC V2, even though it has a meg of RAM.

[KhanTyranitar]

Ok, is that CLK in PH0 at double the frequency of your outputs?

[banedon]

KhanTyranitar wrote:

Ok, is that CLK in PH0 at double the frequency of your outputs?

Yep. The D type flipflop changes it's output (Q and /Q) to go high or low for each full cycle of the clock being fed into it. This has the affect of dividing the clock by 2. Also, one of the benefits of using the flip flop is that the clock signals being outputted on Q and /Q will have better rise and fall times than the original clock.

[edited: typo correction]

[KhanTyranitar]

Ok, that's good to know. So a related question my VIC-II chip outputs 1 MHz but I need to generate a PH1 and PH2 off that for timing the slow side of the RAM and for other 1 MHz devices. How do I do that?

[BigDumbDinosaur]

KhanTyranitar wrote:

Ok, that's good to know.

Also useful is the below circuit. This can be used with RAM, ROM or I/O hardware that has separate /OE and /WE inputs. This circuit only drives /OE (aka /RD) when RWB and Ø2 are both high, and only drives /WE (aka /WD) when RWB is low and Ø2 is high. Two requirements are thus fulfilled: Bus contention on D0-D7 during Ø2 low in a 65C816 circuit is prevented (read cycle), and devices are written to only when Ø2 is high and D0-D7 contains actual data (write cycle).

[BigDumbDinosaur]

KhanTyranitar wrote:

Ok, that's good to know. So a related question my VIC-II chip outputs 1 MHz but I need to generate a PH1 and PH2 off that for timing the slow side of the RAM and for other 1 MHz devices. How do I do that?

Well, your problem will be that using a flip-flop to generate Ø1 and Ø2 divides the flop input frequency by two. You probably will have to use something other than the VIC-II as the primary clock source.

[KhanTyranitar]

On the 1 MHz bus I have to use the VIC-II clock as the source because it is the bus master. The VIC-II uses its own clock to time its memory access. The 20 MHz bus however has no such limitation as it does not have to be in sync with the 1 MHz bus.

[BigDumbDinosaur]

KhanTyranitar wrote:

On the 1 MHz bus I have to use the VIC-II clock as the source because it is the bus master. The VIC-II uses its own clock to time its memory access. The 20 MHz bus however has no such limitation as it does not have to be in sync with the 1 MHz bus.

Well, I'd say you appear to have an intractable timing problem. You are going to have to decide which bus master is in charge in this circuit: the 65C816 running at 20 MHz or the VIC-II running at 1 MHz. From where I am sitting, what you are attempting to accomplish isn't possible, unless you are able to work out a scenario in which the VIC runs at a phase-locked frequency that is a submultiple of the Ø2 generator driving the 65C816.

Incidentally, CSG indirectly solved this problem with the 8563/8568 video display controllers (VDC) of the C-128 and C-128D by giving the VDC its own RAM, thus making accessing the video RAM an asynchronous process.

[BigEd]

If we're still talking about using dual port RAM to serve a slow side and a fast side, that doesn't sound intractable to me. The two clock regimes are independent.

[BigDumbDinosaur]

BigEd wrote:

If we're still talking about using dual port RAM to serve a slow side and a fast side, that doesn't sound intractable to me. The two clock regimes are independent.

I would completely agree with you if it weren't for the fact that the VIC-II is a typical 65xx peripheral, in which its internal activities are slaved to the PHIN (Ø2) clock input. My understanding of the VIC's behavior is that it and the microprocessor that is reading and writing it must run at the same frequency in order for the VIC to know when it can steal bus cycles to gain access to RAM. That this is the case is demonstrated in the Commodore 128 by setting bit 0 of VIC register $30, which changes the Ø2 rate from 1 MHz to 2 MHz (setting that bit is one aspect of BASIC's FAST command). The display generated by the VIC-II turns into incoherent garbage because the VIC continues to run at 1 MHz, which prevents it from reading RAM.

Interesting aside: the reason the VIC's registers can be read and written when the 8502 is running at 2 MHz is because all I/O device accesses in the C-128 occur at 1 MHz due to clock stretching. If that weren't the case, once switched to 2 MHz mode, it would not be possible to return the machine to 1 MHz, since the VIC would be incommunicado.

[Dr Jefyll]

On a more basic level, the VIC has internal registers -- just like a 6522, for example -- which need to be readable and writable by the CPU. 65xx peripherals don't have Output Enable or Write Enable inputs because the Ø2 input (combined with the R/W input) fulfills that function.

As for Phase-Locked Loops, this technology is wonderfully accessible now. I'm sure one can find a one-chip solution that will take the existing 1 MHz clock and generate a synchronized clock running at 14 MHz (or almost any other integer multiple you care to choose).

There are so many products available it's actually hard to choose. On the down side, many of them are offered only in surface-mount packages with rather fine lead pitches. You'd either need to do a PCB or buy a little breakout adapter PCB.

[KhanTyranitar]

Except that since I'm using dual port RAM, the VIC-II almost never needs to steal CPU cycle in order to gain access to the RAM, since in my setup, the VIC-II has its own dedicated RAM port.

This will be a separate thread, but for now here is the summary.

At startup, the system does in fact run at 1MHz with the VIC-II generating the CLK for everything. A logic circuit latches the clock signal and routes the data where it needs to go. There is a transceiver that connects the CPU with the ROMs, the VIC-II, the SID(s), and the CIAs. When the VIC-II needs to read the RAM, because it has its own dedicated ports, it does not need to steal CPU cycles. The exception is that if the CPU is attempting to read or write to a ROM, or any of the IO chips at the same time as the VIC-II is reading, in which case the CPU is halted until the process is completed. Again this halting will only occur if those two things are happening at the same time. Otherwise, since the CPU has its own RAM port it can do its own thing.

Now as you recall, the 6510 has some IO pins (P0-5) that enable ROM banking and cassette port communication. I have a circuit that mimics that feature, only mine adds two more pins (P6&7). One of these when switched high will enable turbo mode, which basically tells a logic circuit to decouple the CPU (and everything on the fast side) from the 1 MHz clock and instead couple to the 20MHz clock. The VIC remains master of the slow bus. At this point however, if the CPU attempts to access a ROM, SID, CIA, or VIC-II register, the CPU is halted, then re-coupled to the 1MHz clock again. The CPU completes its access, then it is decoupled and switched back to the 20MHz clock.

I am still working on this latching system and the logic that will control it. That will be its own thread. I know it's complicated, but it should still function. I may loose a cycle here and there during the switches depending on how synchronized things happen to be, but those missed cycles should not be a major issue so long as things are timed so that data isn't lost.

As far as I can tell from going through this process, the two busses can be though of as operating separately with a common RAM access and a form of forced synchronization when needed. And to minimize slowdowns, some things can be done. For example, if I read the ROMs and copy them to RAM, I can then bank the ROMs out. Then when those routines are accessed, they can execute from RAMat full speed. Then the CPU only has to slow down for IO access.

The approach I'm taking will be mostly transparent to the software. If I try to write a VIC-II register for example, as soon as the CPU outputs it's address lines, and a positive address match occurs, then the CPU is halted using the RDY pin. Then the 20MHz clock is decoupled and the 1MHz clock is swapped in. When the clock is in the right phase, the RDY signal is released and the CPU will complete its operation. Once the cycle is complete, the RDY pin is held again, the 1MHz is swapped out with the 20MHz clock, and when the clock is in the right phase, the RDY pin is released.

I am not opposed to some type of phase locked loops, or having one chip handle all the logic functions. And generating all the signals from the VIC-IIs clock output. Alternately I can also do it from the VIC-IIs 8MHz input.

[KhanTyranitar]

Dr Jefyll wrote:

On a more basic level, the VIC has internal registers -- just like a 6522, for example -- which need to be readable and writable by the CPU. 65xx peripherals don't have Output Enable or Write Enable inputs because the Ø2 input (combined with the R/W input) fulfills that function.

As for Phase-Locked Loops, this technology is wonderfully accessible now. I'm sure one can find a one-chip solution that will take the existing 1 MHz clock and generate a synchronized clock running at 14 MHz (or almost any other integer multiple you care to choose).

There are so many products available it's actually hard to choose. On the down side, many of them are offered only in surface-mount packages with rather fine lead pitches. You'd either need to do a PCB or buy a little breakout adapter PCB.

Yes, finding through hole and DIP packages is difficult. Some components will definitely need to be surface mount with adapter boards. The DP RAM is available as a socket, but not a dip package. So I'll need to adapt it for sure. Where possible I want my final board socketed so that components can be replaced if needed without having to desolder. I may have to implement daughtercards in some cases.