Hi all

I decided to have another go at doubling the main Phi2 frequency from 2.68Mhz to 5.36Mhz - this is due to using a 21.47727 crystal and then using a counter to divide down by 2, 4, 8, 16. Divide by 2 is needed for the TMS9918 and divide 16 by the AY-3-8910.

When I doubled the Phi2 frequency with no other changes, the system seemed unstable. I decided that my SRAM was too slow - it is a UM621024 70ns part. My rough calculations told me that at 5.36Mhz, one clock cycle is 186ns, and half a clock is only about 93ns. That leaves 23ns for things like chip select logic, which in theory is not enough. I know that many times one finds that parts will reliably operate at higher frequencies than indicated, but given that I was having issues, my view that the SRAM was too slow seemed logical.

Luckily, I had a 15ns SRAM to hand - UM61512. Basically pin compatible except a 64KiB rather than 128KiB part (and I only use 64KiB) - I just need to make sure both pin 1 and 2 are left unconnected on the 64KiB chip (pin 2 is tied to ground when using the 128KiB part).

So I swapped out the 70ns for 15ns part. The system seemed to get further, but very glitchy. So I started to suspect software and started putting in delays in various low level routines which drive the VDP. Still glitchy. I then tried the original frequency of 2.68Mhz and even 1.34Mhz for Phi2 with the 15ns chip - and it was still very glitchy!

I kind of gave up and put the 70ns part back, things seemed back to normal. But then I tried 5.36Mhz with my modified software - works a treat! I had some further minor software timings to sort out (VDP cannot be accessed too quickly in some modes, and the BBC keyboard also can't respond quickly enough), but now this is done, I have a 5.36Mhz homebrew on a breadboard working fine.

Sorry for the long story but wanted to give folks the context - my question is why would the faster 15ns SRAM not work where a slower one would?

Although I'm happy it is working, very curious as to the answer or any theories. I don't have any other SRAMs I could try unfortunately, so can't do more experiments.

Thanks in advance!

You are working on a breadboard - the GND and VCC distribution is not very well. A very fast RAM like your 15ns one will require very very well supply bypassing to work fine. Slower types don't surge that much current when switched from unselected to selected and back. This may be the reason of what you observed.

From where did you get the idea that only 23ns were available to handle chip selects? The 65C02 generates a vaid address roughly midway through Ø2 low. Assuming you didn't make the mistake of qualifying chip selects with Ø2, you will have loads of time with which to work. That 70ns RAM should easily handle 5.36 MHz.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

Another possible cause of instability with very fast parts is hold time violations - in a sense, the part is too fast. And at high speeds, clock skew between different components in the system will make this worse - with faster parts in the system, you'll need better clock distribution, or just possibly deliberate skew.

Thanks for the response folks, some very interesting comments:
1) On the possibility that the 15ns part needs better bypassing : Well, I have been rather lax about using bypass capacitors on the RAM, but tried this with no noticeable difference. But yes I take the point that I probably have power VDD and GND, I have certainly chased spurious issues in the past down to this. Until I create a PCB design for this, I will have to live with it.
2) Hmm. Yes, I am qualifying chip selects with Phi2, I based my decode logic approach from Garth's primer back in 2015, and it's been fine all that time! But I thought the CPU is not accessing the bus during Phi2 low - that's when other components can drive the bus e.g. DMA, 6845 Video? I need to look in to this more, clearly I have misunderstood all this time
3) Yes I did wonder if perhaps the part was too fast, but to investigate clock slew issues will take rather more investigation. Not sure I understand the possibility of hold time issue?

Quick sketch of hold time issue - may not apply if you're using Phi2 to qualify: at the end of a read of a slow peripheral, the 6502 needs to latch the value on the falling edge of the clock, and needs the value to stay put for a few nanoseconds. If there's a fast chip on the bus which might drive the bus in the very next cycle, it could overwrite the value in time to disturb the latched value, and the 6502 will operate on the wrong value.

If chips can only drive the bus in phi2, and if that decode logic is glitch-free, then it feels like this isn't a concern.

As another point: when a fast chip drives the bus, it turns on 8 drivers, and the current demand could pull up the ground line, causing some other chip to interpret a low as a high. This is why you need bypass near the pins of both the disturbing chip and the potentially-disturbed chip.

I agree with BDD, the clock ringing does look a bit scary, if it's real. I don't worry about overshoot immediately after a transition (perhaps I should) but I do worry about the subsequent rebound - you can see how that might start to look like a second pulse, especially if it is interpreted by a chip with a disturbed ground reference. It's important that clocks are monotonic, as much as it's important that their edges are fast. Which is to say, the edges can be too fast. If I were feeling experimental I might put a small resistor in line with the clock driver - but it's a wild idea.

Yup.

Barring unstated assumptions, no -- this is incorrect. A 65xx CPU generates a valid address tADS after the beginning of the Ø2 low period. Possibly that'll happen to coincide with midway through, but more likely not. In this diagram from my Visual Guide to 65xx CPU Timing we see tADS remains constant, but the midway point of the Ø2 low period changes according to the choice of clock speed.

_________________
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html

The situation with your wireless breadboard can perhaps be improved to some extent. But before making suggestions I'd like to see it. Have you posted photos of your project? So far, there are none in this thread, and you've not linked to any other threads.

_________________
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html

During Phi2 low the address bus is settling to a new address. In case of DMA you need bus drivers or a multiplexer so that only one bus master feds its address onto the bus. I would also use drivers for each bus master for the data bus to avoid contentions when one went active while the other is a bit lazy in going off.


The hold time is the time a signal should stay unchanged after the actual data transfer is nominal done. For the 6502 this is the falling edge of Phi2, where the µP is latching the data from the data bus. To avoid any uncertainty the signals on the data bus should held unchanged for a few ns.

Thanks for the further responses folks, appreciate your knowledgeable input.

@GaBuZoMeu - I didn't know this. When first thinking about video for my computer, I was considering a MC6845 and I thought that pushed out addresses when the 6502 was quiet (Phi2 high) rather than needing a multiplexor. But it was a while ago so probably I am wrong, will look in to how that was actually going to work!

@Df Jefyll - I have a website on hackaday with various pictures, hope that gives you an impression of what I have done. It's a little Heath Robinson in places but certainly would be interested in your opinion as I know from your site that you have done some pretty cool projects. I'm a software engineer turning his hand to hardware, so maybe not everything has been done 'right' and possibly lucky to have got as far as I have with it

[url]https://hackaday.io/project/5789-6502-homebrew-computer
[/url]

Hence the word "roughly".

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

Really not sure that's a helpful way to think about it, though, BDD.

With respect to the 6845 - it's really just an address and control signal generator, and needs glue logic to make it actually interface with a RAM array and drive a video output. With the right glue, I'm sure you could interface it to HDMI.

The way the BBC Micro does it (which I think is typical for 6502-based micros) is to derive everything from a 16MHz master clock. A ULA chip is responsible for most of the CRT glue and incorporates several divide-by-2 stages, producing 8, 4, 2 & 1 MHz signals. In the highest resolution graphics mode, the 16MHz clock is used directly as the dot clock, consuming 2MB/s. The 6502 itself is also run at 2MHz.

The trick is that the BBC Micro's RAM is not SRAM but DRAM (32KB of DRAM was costly enough back then; 32KB of sufficiently fast SRAM would have been prohibitive), and requires multiplexed row-address and column-address inputs for every access. The 6845's continuous address generation is used to trigger the necessary DRAM refresh cycles, by not gating the row-address strobes by any chip selectors. But the use of DRAM means that the address bus is actually in *three* parts - one from the 6845, one from the 6502, and one leading to the DRAM chips, with glue logic in the middle. The DRAM address bus therefore works at 8MHz to satisfy the 4MHz data accesses by a 2MHz CPU and a 2MB/s pixel stream.

@dolomiah: you may take a deep look into http://archive.6502.org/appnotes/synertek_an3_6545_crtc.pdf

Assuming a 5V supply, the max tADS for a modern WDC 'C02 is 30ns. If we do the math for clock rates in the range from 1 MHz to 14 Mhz (and some systems are even slower/faster than that) we see that 30 ns puts us 6% to 84% through the Ø2 low period -- or roughly midway.

_________________
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html