That shouldn't be the case, If anything I'd think the faster the better and I'm using 10ns ram myself.

Delaying the clock to the CPU effectively means that PHI2 to the rest of the system comes slightly sooner which is only used for qualifying /WR right? (besides being used by the peripherals)

With the RAMs CE tied low and the OE tied to the address decode but not qualified by PHI2 it would mean that before PHI2 rises your RAM is driving the bus. Perhaps delaying the clock to the CPU causes /WE to be asserted sooner or at the same time as /OE?. Might this cause conflicts with the CPU ?

It could be that the NMOS part has slightly different timing that doesn't cause this issue?

And this is working with a W65C02S? Would you be able to share your schematic?


Yes.


/CE and /OE are currently tied together on the RAM and the /WE signal is qualified by PHI2.

However, even if /CE were tied to ground I'm not sure why it should be an issue for the RAM to be driving the bus before Phi-2 rises as this will only happen during a read cycle. During a write cycle /WE is asserted while PHI2 is still low and at the same time as the address is asserted. Therefore due to propagation delay in the GAL/glue /WE will be asserted before /OE is asserted ensuring the RAM output is off for the entire cycle. The CPU will only drive the bus with write data ~25nS after PHI2 rises, so I don't see where a conflict could possibly occur.


It sounds like you saying that delaying the clock to the CPU should cause problems, is that right? The opposite is actually the case. It was not until after I delayed the clock to the CPU that things started to work. But see above. I can't see how a conflict can occur - either way.


Perhaps - and the same with the older CMOS parts. The only question is, what is the real issue?

Connecting /CE and /OE made no detectable improvement. The only thing that worked is the short delay on the clock going to the CPU. In fact, connecting /CE and /OE will only maximize the propagation delay in reading data from the RAM, not that that is a real issue with these fast parts. One advantage to keeping /CE low is that it will mean the RAM is powered on all the time and not causing switching noise on the power lines.

This weekend I'll try some additional things as well as get some timing on a scope with and without the delay.

I'm delighted it's working - I'd just like to know why.

_________________
Bill

In this area, I tend to draw timing diagrams, but at the moment, I don't have the time to devote to such an effort. However, my suspicion is that with the CPU clock delayed relative to the clock on the GAL, the address lines to the SRAM have a stable address on the rising edge of nWE. High-speed RAMs like the ones I suspect that you are using have a requirement, in addition to the nCE requirements, that the address be stable especially on the rising edge of nWE. In fact, they have a access mode other than nCE which is based strictly on the address lines. The address-driven select (read/write) is faster than the nCE driven cycle. There should be a statement somewhere in the RAM data sheet regarding this effect.

Therefore with the CPU clock delayed a gate delay or two, I suspect that it doesn't change the address bus for the next access until after the rising edge of nWE has been generated by the GAL and presented to the SRAM. Whenever I've looked at the specifications for the address change during Phi1, I've been left scratching my head as to the time reference for the event: the rising edge of Phi2, or some other internal timing reference. I've always been relatively unimpressed about the precision of the bus definition for both the 6502 and 6800, and it's because the exact timing reference of the address change is somewhat nebulous.

_________________
Michael A.

Oh yes, I too would like to know why.

What did change? You delayed the CPU clock a little against the oscillator clock. The only chips that are affected are the GAL providing the /WE for the RAM and the 6551 (which works fine before and after this mod).

As R/W and addresses are still related to the CPU their timing relation is still unchanged. Only /WE out of the GAL now terminates a little earlier relative to R/W - which cuts the time for the RAM to fetch the data - and that is somewhat counterproductive. The only advantage I see is that the coming transition of data & address lines & R/W cannot affect the stored information.

Perhaps there are some brief data bus collisions during address change. The 245 bus driver is very quick. Its select signal is GAL driven, its DIR signal is R/W. Could it be that it somehow have disturb the data bus during data hold time for RAM writes?

The only thing I would definitely make different is qualifying the various /CS signals with the clock. I don't know whether this would change much, I just would (and do) qualify them by PHI2 (or E).


Please do keep us informed about your observations!

I think this is important generally and probably crucial here. Looking at the pins of the CPU, the falling edge of Phi2 is the only reference. At some point after the falling edge, the address lines will begin to change, and at some later point, they will stabilise at their new values. The timing of that will vary from one instruction to the next, and will also vary between address lines. There is no single instant when they change from the old bus value to the new bus value.

As a consequence, any decoder driven by the address lines is going to stay valid only for a little time after Phi2 falls, is liable to glitch as the various address lines change, and is going to become finally valid a little time after the address lines settle.

Any RAM, or writeable register, connected to the address bus, and a decoded chip select and write enable, could be responding to these changing addresses and changing chip select throughout the process. To avoid a stray write, we need to hold off any reaction until all the inputs are stable - and yet, the 6502 provides no timing reference for that moment.

It is common to use Phi2 again, or a version of it, for this purpose. So long as the half-cycle low period is long enough, and starts soon enough, it will correctly mask off the chip select and/or the write enable until both of them are valid.

In this particular case, I think we're interested in what happens at the beginning of a clock cycle, at nanosecond scale. Neither clock cycles nor clock phases are zoomed in enough to see what's happening.
We might be interested in a write cycle after a read, in a read cycle after a write, or even two write cycles back to back.

If the clock into the CPU is advanced relative to the rest of the circuit, then the address lines and RnW will be changing early, and if they are gated by a clock which is delayed, and if they change before that clock squashes the chip select and write enable, then a stray write could happen.

If the CPU clock is delayed relative to the rest of the circuit, it's more likely that the address lines and RnW are still stable at the point the chip select and write enable are deasserted. Whether that's successful depends on the relative speed of the CPU, among other things. A slow CPU - such as an NMOS part - might be unable to move the signals too soon, and so be safe. It might even be safe with no delay. A faster CPU - such as a modern CMOS part - might need more delay because it moves the signals sooner.

The hazard of delaying the CPU clock is that the CPU will capture data on a read cycle somewhat later, so it's important that devices writing to the bus (RAM, ROM, peripherals) don't move the datalines before the CPU is done: the CPU needs to see the falling edge of the clock and then the hold time needs to elapse. Fortunately, an undriven bus won't move terribly fast, so this is less likely to cause a problem, provided the output drivers of the driving devices are disabled.

For the W65C02S the addresses are specified to be stable after a maximum of 30nS from the falling edge of PHI2. See tADS (address setup time) in the datasheet. according to that data sheet addresses and R/W should both be stable by then.

For the RAM (Wiinbond W24257A) chip I'm using, while there is an address controlled read cycle, the only write cycles are /OE clocked high during write or low. The case where /OE is always low (or low during write) holds output data valid further into the write cycle - as long as 6nS after /WE is asserted. This might cause conflicts with the write data coming from the CPU, but I'm not sure it would amount to much. Undesirable but not problematic.

Their specifications are that /WE can be asserted with the addresses (minimum address set-up time is 0nS) (or at some point later) and this chip requires no data hold time after /WE goes high provided it was low for a minimum of 9nS and the data was valid for the last 6nS.

Assuming no CPU clock delay, a clock speed of 14mHz, RAM access time of 15nS and a 7nS GAL:
If we are using a PHI2 qualified R/W we would get /WE asserted approximately 7nS after PHI2 goes high. This would be about 5nS or more after /CE was asserted and some 12nS after the addresses were stable. All good so far.

Now if we have /OE low we could have RAM output data available on the bus for up to 13nS after PHI2 goes high. The write data delay time from the CPU is specified at a max of 25nS - this at first seems fine, but the data sheet gives us no idea what the CPU is doing with the data bus during that time so we can't eliminate the possibility of a temporary conflict on the data bus.

All that said, as long as there is no conflict happening for at least 6nS before /WE going high, there should be no corruption of the written data. Is this the case? Well, data should be valid 10nS before PHI2 goes low and hold for another 10nS after that. That means the RAM chip output should have gone to hi-z 12nS before the CPU write data is guaranteed valid. Also, /WE will not go high for about 7nS after Phi2 goes low, so we should have 17nS of valid sable data on the data bus with no conflict from the RAM data out. Further the PHI2 qualified write pulse on /WE should be ~35nS, well beyond the 9nS minimum.

The end result is, given the information in the data sheets, this should be working fine without the delayed clock going to the CPU.

_________________
Bill

I'm not going to be able to get back to this until Saturday or Sunday, but it keeps my thoughts busy.

One thing I'm going to try is to modify my test board to control /OE on both RAM and ROM with an inverted R/W signal from the CPU, run the chip selects to /CE and use the buffered PHI2 for everything. I feel that should work and eliminate all the possible conflicts and timing issues we've been discussing. If it fails, I will take some timing pictures with a 4 ch. scope of the way it is now (with buffered PHI2 to the CPU and 65C51) and the way it does not work (direct PHI2 to CPU + buffered PHI2 to 65C51).

_________________
Bill

That'd be great - 4 channels should be enough!

I have had a bit of a windfall today. My big meeting was cancelled. This allowed me to make the changes I detailed above and it works. This is comforting as my analysis for the RAM timing sowed that should not have been a problem, and moving to an access mode with /OE toggled low during the write cycle (inverted R/W) would even improve the timing by completely eliminating any possibility of data bus contention with a W65C02. Now all devices use the same PHI2 so it seems the problem as I had originally was that the buffered PHI2 going to the 65C51 followed the one going to the CPU by ~6nS. It does not seem like it would matter much, and it doesn't to the NMOS chips or the R65C02, but it apparently matters a lot to the WDC chip.

I could still do the timing traces on Sunday if anyone is really interested, but as this configuration 'makes sense' (it should work and does) I am pretty comfortable with it.

The attached schematic represents the current configuration.

_________________
Bill

Just in case anyone is interested in what this looks like, I'm attaching a couple of photos. I'll do a little write up (and another project) at some later point. Perhaps when I get new boards made up. It's so cheap these days.

The one pictured uses a Rockwell NMOS 6502B and is running nicely at 4mHz.

_________________
Bill

Nice board layout! Glad you have everything working. It looks like you have an Intersil sourced 65C51 ACIA on the board. I also one of these rated for 4MHz. Mine is a NOS part, but I tend to get intermittent glitches on it once in a while, so I put a Rockwell CMOS part in and all is fine. Just saying in case you find some odd things with the console.

Any plans for the I/O boards yet?

_________________
Regards, KM
https://github.com/floobydust

You are using Phi0 on all 65x02 and gate /WE with BPhi2 = Phi0. So the lag between Phi0 and Phi2 (out of the CPUs) isn't that much that writes into RAM are affected? Even at 14 MHz? I would appreciate some timing traces (Phi0 / Phi2 / DBx / nWE) perhaps at different supply levels ( 4.5 / 5.0 / 5.5 V ) if you have the time

Sorry, that's an old IC model I'm using so the label says Phi0 (Phi-zero) for pin 37 rather than PHI2I . If you look, there is nothing connected to pin 39 and pin 37 is fed from BPHI2. The oscillator feeds into the '245 then comes out as BPHI2 which then goes to the CPU, the GAL and the 65C51. Everything is now dancing the same dance.

_________________
Bill

Thanks.

Yes, that's an Intersil 65C51. It's just like the one on the W65C02 test board that is now running as stable as a rock at 15.5mHz as I write this. I'm not sure what the rating on it is. The part number is CDP65C51AE2. Edit: Looks like that is only a 2mHz part - wonder why it's running at 15.5mHz?

Lots of plans for I/O boards. ADC, DAC, stepper controller, hardware PWM generator, dual W65C22S, I2C, relays, MOSFETs, Graphical and character LCDs, etc...

I'll build up prototypes on those generic boards I have to get the interfacing right, then do up multi-device PCB boards so that I can mix and match as required. The way I have it set up there can be up to 4 8-bit devices per slot with nothing more than a 74xxx32 to select between them. Or a GAL can be used for more complex stuff or go beyond the 4 devices.

_________________
Bill

Yes, correct. The timing charts of WDCs 6502 are referenced to Phi2 (in). I'm used to the NMOS charts where Phi2 (out) is referenced. But there is no information about the delay between Phi zero in to Phi 2 out, except for an old Commodore datasheet where they say its 5 ns. And 5 ns wouldn't matter anyway.

And yes, the board is looking very nice!