Dual port ram

[KhanTyranitar]

Ok, so I'm looking more and more at my options for this glue logic.

So from what it seems, using the dual port ram should allow me to run the CPU at 20 MHz or whatever without having to halt or slow down to allow the VIC2 access. That part seems great. Regardless of the differences in the bus speeds, the interrupts from the VIC2 should be able to work, unless there is something I don't know about.

But for IO access, from what I can tell I can use 65c22s. That will mean that for IO access I won't need to slow down either. My design so far is using three 65c22s, two for IO functions, and one to replicate the 6510 specific pins. (If there is a better way, let me know). Also if the speed of the 65c22s presents a problem for the IEC or other data connections, I may decide to stick with 6526s instead.

So my next major hurdles are: to either buffer or slow down for SID and ROM access. If I use faster ROMs, I won't need to worry about them. I may go with some type of flash memory for the ROMs as well, I'm not sure yet, just considering the option. If I can get the ROM figured out, then that leaves me with the SID chips. I plan to set it up for dual SIDS. Since the SID uses $d400-d7ff (a whole K) then is there a way I can trigger the CPU to slow down to 1 MHz when any address in that range is accessed? Or am I thinking about this the wrong way?

[banedon]

KhanTyranitar wrote:

....So my next major hurdles are: to either buffer or slow down for SID and ROM access. If I use faster ROMs, I won't need to worry about them. I may go with some type of flash memory for the ROMs as well, I'm not sure yet, just considering the option. If I can get the ROM figured out, then that leaves me with the SID chips. I plan to set it up for dual SIDS. Since the SID uses $d400-d7ff (a whole K) then is there a way I can trigger the CPU to slow down to 1 MHz when any address in that range is accessed? Or am I thinking about this the wrong way?

Hiya

You can delay the CPU when needed using a simple but elegant JK flip-flop circuit which has been posted somewhere on these forums (I'll try and dig it out). If memory serves, the circuit uses 3 inputs: PHI2 (the main clock), the active low device enable pin (ROM select, VIC select, etc.) and (optionally) the CPU reset pin. The output is to the RDY on the CPU.

Here's a version of it, but please note that I did not design this (kudos lies elsewhere) and it's done from memory so I've hopefully remembered it correctly! :

CPU_DELAY.gif (4.23 KiB) Viewed 1113 times

BTW hello to everyone: Long time, no see!

[Dr Jefyll]

banedon wrote:

I've hopefully remembered it correctly! :

Glad you like the circuit! Your version will work fine; and, as you point out, it's optional to use the CPU reset signal. (Alternatively the CLR\ input of the FF can simply be tied high.)

The original discussion (and a version for TWO wait states) are here.

cheers,
Jeff

[BigDumbDinosaur]

banedon wrote:

[You can delay the CPU when needed using a simple but elegant JK flip-flop circuit which has been posted somewhere on these forums (I'll try and dig it out). If memory serves, the circuit uses 3 inputs: PHI2 (the main clock), the active low device enable pin (ROM select, VIC select, etc.) and (optionally) the CPU reset pin. The output is to the RDY on the CPU.

Here's a version of it, but please note that I did not design this (kudos lies elsewhere) and it's done from memory so I've hopefully remembered it correctly! :

CPU_DELAY.gif

The 680 ohm resistor should be replaced with a small signal Schottky diode, with the anode connect to RDY on the MPU. Otherwise, that should work.

That said, Jeff published a more elegant circuit, which he mentions above.

[Dr Jefyll]

BigDumbDinosaur wrote:

The 680 ohm resistor should be replaced with a small signal Schottky diode, with the anode connect to RDY on the MPU. Otherwise, that should work.

That said, Jeff published a more elegant circuit, which he mentions above.

It wouldn't be surprising if multiple people independently hit upon the same circuit. But there's evidently some confusion somewhere; AFAICT the circuit I posted is identical to the version banedon recollected and redrew (other than the detail about reset, noted as optional). I also don't understand the benefit of using a diode as suggested. Am I missing something? (Edit: Hmmm... It does let the MPU pull its own RDY pin low, as happens following a WAI instruction, without drawing excessive current from the Q output of the flip-flop. But so would the resistor -- that's why it was put there.)

[KhanTyranitar]

banedon wrote:

KhanTyranitar wrote:

....So my next major hurdles are: to either buffer or slow down for SID and ROM access. If I use faster ROMs, I won't need to worry about them. I may go with some type of flash memory for the ROMs as well, I'm not sure yet, just considering the option. If I can get the ROM figured out, then that leaves me with the SID chips. I plan to set it up for dual SIDS. Since the SID uses $d400-d7ff (a whole K) then is there a way I can trigger the CPU to slow down to 1 MHz when any address in that range is accessed? Or am I thinking about this the wrong way?

Hiya

You can delay the CPU when needed using a simple but elegant JK flip-flop circuit which has been posted somewhere on these forums (I'll try and dig it out). If memory serves, the circuit uses 3 inputs: PHI2 (the main clock), the active low device enable pin (ROM select, VIC select, etc.) and (optionally) the CPU reset pin. The output is to the RDY on the CPU.

Here's a version of it, but please note that I did not design this (kudos lies elsewhere) and it's done from memory so I've hopefully remembered it correctly! :

CPU_DELAY.gif

BTW hello to everyone: Long time, no see!

That does look simple and elegant. It seems I would use some type of latch to trigger the proper select, which would then trigger this circuit to slow things down, while simultaneously switching the data and address signals to the appropriate devices.

[BigDumbDinosaur]

Dr Jefyll wrote:

I also don't understand the benefit of using a diode as suggested. Am I missing something? (Edit: Hmmm... It does let the MPU pull its own RDY pin low, as happens following a WAI instruction, without drawing excessive current from the Q output of the flip-flop. But so would the resistor -- that's why it was put there.)

If a Schottky is used for isolation, RDY will draw no current from the flop's Q output when WAI is executed (other than a few microamps from diode leakage). This consideration becomes important if the WAI instruction is intentionally used in a high speed interrupt scenario, as the MPU will not stop upon executing WAI if it cannot internally pull RDY to or below VIL max.

Going the other way, when Q is low, as it would be for a wait-state, the low forward drop of the Schottky will guarantee that RDY will be pulled close to Q's voltage. Assuming use of a 74AC74 flop and an SD103 Schottky, RDY will be sunk to about 0.4 volts when Q is low, well below VIL max.

[Dr Jefyll]

Yes, but weren't you going to tell us why you consider a diode superior to a resistor? The diode has two drawbacks I can think of (though they're not actual show-stoppers).

The best choice may be "none of the above." In the other thread I duly note Garth's suggestion of a capacitor (shunted by a resistor). And in the other thread is probably where this discussion belongs -- not here, as we're kinda straying from the dual-port RAM topic!

[KC9UDX]

If the VIC-II is the only thing that needs dual port RAM, it seems to me that you only need 16k of dual port RAM.

Unless, of course, you are going for strict C64 compatibility. In which case, you've got a much bigger problem in that the 65816 does not mimic a 6510.

[KhanTyranitar]

While it is true that the VIC-II only sees 16K at a time, it's abiliity to switch to different 16K banks is pretty crucial to its function. Many graphics tricks depend on that. Having 64K of dual port RAM is not an issue for me.

As for mimicking the function of a 6510, that's not really a problem either. Replacing a 6510 with a 65816 is documented. It does require support circuitry to mimic the IO ports of the 6510, but once the cuircuitry is added you get the same result and the result is transparent to software.

[Dr Jefyll]

KhanTyranitar wrote:

It seems I would use some type of latch to trigger the proper select, which would then trigger this circuit to slow things down, while simultaneously switching the data and address signals to the appropriate devices.

(empasis added.) I hope you'll soon have a diagram such as we discussed earlier, showing how the buses of the various devices interconnect. The dual-port RAM is a powerful solution but it introduces some complexity in this regard. In particular, it's insufficient to merely make address and data connections between the VIC and the RAM; address and data connections must also exist between the VIC and the CPU as explained in my earlier post. Perhaps you've already accounted for this, but such details aren't clear to us until we see the diagram.

[KhanTyranitar]

I'm still working on it. Since timing is critical, I've been researching components to make sure that they can switch fast enough.

The solution for the 6510 mimicking involves using a 65c22 to provide IO pins. The 65c22 uses some logic chips to latch on to memory addresses $00 and $01. In this case that is just a couple memory locations.

I need a similar (though more complex) circuit to latch on to any fixed memory addresses used by the VIC-II such as its registers or the Color RAM. When this latch occurs the CPU will first be halted, then synchronized with the VIC-IIs 1 MHz clock (PHI2 actually). It will then be able to read or write those registers. The same approach would be used for the SID as well.

[KC9UDX]

But you'll never reasonably emulate the undocumented opcodes of the 6510/NMOS 6502.

I don't know how much of an issue that is. I always assumed it would be a problem given all the books I've read on how to exploit the undocumented behaviour.

[KhanTyranitar]

Undocumented opcodes don't matter much to me. If I need to run something that uses them I have a couple real C64s.

[KhanTyranitar]

Ok, here is the schematic I have so far. It probably has some newb mistakes. It is obviously not the entire board, just the interface to the DP RAM, and the LATCH trigger (which is another circuit as well).