Alright, I found a photo... perhaps no longer up-to-date, but it'll serve. I see you have bypass capacitors connected directly to the chips -- which is good -- but instead I wanna talk about the connections between chips. I'll start with the data-bus connections between the RAM (which is at issue in this thread) and the CPU.

When I say connections, I'm including both the signals and their return paths. The image above shows that these form a loop, with the signal wiring in yellow on the bottom and left of the loop, and the return wiring in black along the top and right. (For clarity I'll ignore the red Vcc wires, but they too act as a return path.)

The signal wiring offers little scope for improvement. It's long, and not much can be done about that. But can the return wiring be improved? Yes, and one improvement is to add a diagonal directly between the two chips. But, interestingly and counterintuitively, that's still not the ideal path -- the route the return current most wants to take. What it wants most of all is to hug the signal path, even though that's *longer* than a direct route (ie, diagonal)! So, I'd consider adding a ground wire that takes the same, long-ish route as the yellow signal path. (This new ground wire needs to be connected at both ends; otherwise it isn't a path.)

Of course the CPU and RAM aren't the only chips, and signal connections go every which way, helter skelter. All these signals paths should have prospective return paths available, but that'd result in a complete rat's nest. A ground plane would solve the problem -- because it attaches every point with every other point -- but we can't do that, either.

More practical (though much less satisfactory) than a plane is to provide a coarse grid of return connections. The idea of the grid is to help ensure that any two arbitrary points will have a return path close by. The grid needn't be perfectly orderly. But, operating on the premise that any two arbitrary points may have a signal path between them, we want a return path reasonably close by. As an example, consider C and D in the image below. I would add a horizontal path from C to D, and also extend the path to meet the columns to the left and right. I'd also put a return path from A to B. Right now there's no chip at A, but presumably there will be one in future, and it might have a signal path to B. And right now the only return path to B involves a drastic detour. I hope I've managed to write this in a way that makes some kind of sense. If there are some edits later it won't be surprising.

Cheers!

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

Wow! Very impressive! All - dolomiah's breadboard work AND Dr Jefylls analyze AND his suggestions of possible countermeasures!
If you can establish a grid like suggested it might work.

Two or three bulk caps (22...100µF) at the top/mid/bottom of each of the supply rails may assist further.

Very roughly! In the future, I'll say the address becomes valid sometime after the fall of Ø2, which will be almost as unhelpful as saying "roughly midway."

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

> In the future, I'll say the address becomes valid sometime after the fall of ϕ2

Thanks BDD - I genuinely believe that will be more helpful! (Personally I'd probably say something like 'some tens of nanoseconds after...' if talking about today's WDC parts. Of course with other implementations it will differ, as indeed it will differ with supply voltage, and so a vague statement is more accurate.)

Everyone, thank you very much for the enlightenment. I have attached a bang up to date higher resolution picture as the one Dr Jefyll found is now more than 2 years old.

I have learnt some fundamental things here, and so amazed that I have somehow managed to build a fully featured microcomputer

Things I've learnt:
1) The 6502 is not off the bus during Phi2 low - the address bus will become valid sometime during this half of the cycle. I read the datasheet from GaBuZoMeu on the CRTC in more detail, and yes I can now see that it does need a multiplexor to allow access to memory without contention. My decoding logic has been qualifying all chip select lines with Phi2 - at the moment timing seems fine for 5.36Mhz, even though I can now see how to do this with more time for devices to respond during the second half of the cycle.

2) I had found my breadboard to have been a bit unreliable at times during the build - I did add both power and ground wires at various random places which seemed to help. I now have a better understanding of signal and return paths as outlined by Dr Jefyll, and so the reason why adding extra power and ground connections can help. I will also add some capacitors across the 5V and 0V lines - I assume this is to help smooth spikey demand current in fast switching devices.

The picture shows the full set up as it is today:
- Bottom row left to right : AY-3-8910, TMS9918a, 65c22-2, 65c22-1, 65c02, address decode logic. I will list everything else relative to this row for ease of identification.
- Above the AY-3-8910 is a 6551 ACIA
- Above the TMS9918a is the CAS/RAS address latching to connect to modern SRAM
- Above the 65c22-2 is the SRAM for the TMS9918a. Also, this 65c22 drives the SD card SPIO pins
- Above the 65c22-1 is the ROM (topmost) and SRAM. This 65c22 drives the BBC keyboard interface. The SRAM is the 70ns part working fine @ 5.36Mhz
- Above the 65c02 is more decode (3 to 8 decoder) to select one of 8 IO devices (I have 4 today - 6551, TMS9918, 2x65c22)
- Above the address decode logic is clock and reset circuitry, including the 4 bit counter which I use to divide the 21.4772Mhz crystal frequency down for use by TMS9918a, 65c02 and AY-3-8910

With this new insight, it means that due to it bugging me, I will likely redo the address decoding to be more efficient. Maybe the board can run at more than 5.36Mhz with more time in Phi2 high for devices to respond (I tried 10.7Mhz, but seems to be completely unresponsive!). I will also look at return paths and hopefully result in a more stable set up going forwards.

Very much appreciate everyone's input - such a great and knowledgeable forum

Cheers, Dolo

Hi dolomiah,

Have a look at this thread: http://forum.6502.org/viewtopic.php?f=4&t=5179

I had a similar problem with a W65C02 running with fast (15ns) RAM.

The problem ended up begin that the propagation delay involved in qualifying the write signal with Phi2 (call the qualified write /QW) caused the /QW to extend beyond the RAM /CE. While the RAM specifies that there can be 0ns between the release of /CE and /W, there can't be, say -6ns (a negative value).

The solution was to delay the clock going to the CPU by the amount of delay in producing the /QW signal. Another solution would be to use faster gates (74ACXX). It seems a delay in generating /QW around 6ns or 7ns is fine, but the 15ns I had was enough to cause problems.

_________________
Bill

Hi Bill

Yes, I have already been tracking your thread (very interesting), and this might be an issue for me too. I will try a single gate delay of Phi2 to the CPU and see if I get different results.

I am using 74HC04 and 00 parts which at 5V are around 7-8ns delay - so that should be enough I think.

** Correction - I need to have 2 gates delays, a 04 will invert the clock with one gate, then I need to invert again - so that's going to be around 16ns. Too much? **


Cheers, Dolo

According to what happens to Bill I assume 16ns are too much. Perhaps you can "invert" the logic instead of inverting the clock twice? Or simply use the /OE and /WE qualifier BDD has posted there. Then you are using a "known good" solution.

I agree, 16ns might be too much.

If you have to real estate, then this solution offered by BDD to produce a qualified write (/QW) should work as an alternative to delaying the clock to the CPU:



The AC logic is speedier than the HC logic. If this doesn't cure the problem then it may be elsewhere.

Do you have dual trace scope? It might be helpful to see the relationship between Phi2 at the CPU and you /QW and also between RAM /CE and /QW.

_________________
Bill

After reading some datasheets and reconsider what Bill did observe with his design, I think you are suffering from the same problem that nagged Bill. This small delay between PHI2 getting 0 and /WE getting 1 and the short data hold time after write of the WDC CPU will cause all that trouble, if (!!) your RAM is very fast! (And b.t.w. with this circumstances my advice to stabilize the power supply is counterproductive as it causes the RAM not to slow down!)

Well, if you look at the specs of a moderate speed RAM it requires a data setup time (frequently named tDW) of about say 30 ns or more. The faster the RAM goes, the shorter this time is. And nearly no RAM requires the data to be valid after /WE gets 1. I think one can imagine that this setup time (with some safety margin) is the time it takes for the signals to travel from the pins to the memory cells. This means as well, that if the data starts to get floating it takes again this time to change the memory cells state. So using a slow RAM allows you to violate the proper timing sequence (first /WE becomes 1 and then data may start to float)!

Of course you cannot rely on using slow RAMs to mediate timing errors . So using BDD's suggested /WR and /OE logic (or perhaps the refined one by Dr Jefyll http://forum.6502.org/download/file.php?id=6403&mode=view) is highly recommended.

Hello Bill and GaBuZoMeu

Thanks for your continued interest. So I have a cheapo PC scope, but have managed to get a 2 channel dump from it (100ns sweep, 2V per division). The screenshot is below - yellow trace is Phi2, green trace is the /CE line (active low) from my address decoding.

The output is based on a very simple loop:


Before this loop starts, the machine goes through the normal boot code and then disables interrupts. So the above is the only code that runs which means there is 1 cycle where the 6502 is reading RAM, the rest of the time reading ROM. My scope has very limited memory, so I ran it machine at 1.34Mhz to get a longer trace at 1us sweep and confirm there is only 1 regular RAM access. At 100ns sweep this is the most the scope can show.

So the interesting thing here is it looks like /CE is starting to fall as Phi2 is rising - looks like no delay?!? But the fall of Phi2 and the rise of /CE seems to be in the order of 40ns to my eyes. I will dig out the decoding logic later and check where Phi2 is getting involved.

I'm out of time for a couple of days due to work, but I hope this may yield some further theories

So that's RAM /CE?

It looks very like what I was seeing whe I was having trouble.

The more important signal to compare to Phi2 is the signal going to the RAM write line (the phi2 qualified write signal (/QW)) anad also the /QW with RAM /CE.

Also, the important place to look is when Phi2 is falling (end of cycle) and both /QW and RAM /CE are rising. Ideally Phi2 will fall followed (not ny much) by /QW rising followed by RAM /CE rising. The really nasty thing with fast RAM is when RAM /CE rises before /QW.

BTW, in your Hantek software, you should have the option to save an image under the file menu.

_________________
Bill

Please be careful: the screen shot is a nicely connected dot picture coming from 48 Msps measuring some signals around 5 MHz. Thats only 10 dots per cycle! This can be used to check whether a signal appears or not and whether its levels seemed to be correct. For timing analysis in this range you need faster equipment.

Hello Bill and GaBuZoMeu (and all)

I updated the code so the lda is now sta, this means I have one write cycle at regular intervals.

So I did a data dump out of my PC scope of Phi2 vs /CE and Phi2 vs /WE in to Excel, then aligned the time axis to show a graph of Phi2 vs /CE vs /WE. Hopefully you can see the jpeg.

What do you make of this - it looks ok to me, I think, but I am not sure what problem I am looking at any more! It appears that /CE is not far behing Phi2 going high, within 10ns, and /WE is around 20-25ns behing Phi2 going low. The distance between /WE and /CE is in the region of 80-90ns. /CE rises around 20ns before /WE.

@GaBuZoMeu - agree with your caution, but unfortunately this is the only sampling hardware I have. But the scope is consistent with the readings in terms of relative difference in time and level between the various data series.

Well, if there is no more difference between using a fast or a slower RAM then you are one step further!

If you going to increase the speed I recommend the /WE and /OE logic the way Dr Jefyll suggested. (BTW I wonder how many people use /CS for gating reads and writes. To me this is somehow "unusual" although it works. I do prefer the classic(?) way using /OE = PHI2 & RWB and /WE = PHI2 & !RWB)

When it comes to video RAM - what are you going to implement? Should it be text or graphics or color graphics? 11,xx MHz reminds me that could be black&white pixel clock for 50 Hz screens?


Arne