Drass wrote:
Not sure I have this right, but it appears that the DRAMs have latches internally and capture the row and column addresses
on the falling edge of /RAS and /CAS respectively. On my C64, the DRAMs are HM4864-3 ICs.
Looks like the DRAMs have latches internally.
Quote:
For these DRAMs, the Row Address Hold Time (tRAH) is 25ns and the Column Address Hold Time (tCAH) is 55ns.
The timing diagrams on page 4 of the PDF are a bit hard to read, but I agree on the address hold time values for tRAH and tCAH.
Quote:
The setup times don't seem to be an issue, so it seems everything should work if we meet the hold times.
The setup times don't seem to be an issue.
Of course, after some years of working in hardware design your confidence in chip datasheets might become somewhat... limited.
Quote:
Here is a capture showing a relevant write-cycle:
The "glitch" on A0 is clearly evident, but it happens over 200ns after /CASRAM has gone low, and presumably also after both
row and column addresses have been safely latched.
Looks safe, but at the moment those glitches are the only hint we seem to have.
BTW: at which frequency your logic analyzer samples those signals ?
Quote:
I agree that absent the internal latches, the timing is a problem (and of course, we do have a problem since the machine won't boot!).
The glitch on A0 is clearly triggered by things happening "too fast" after the fall of PHI2 (btw, who knew "too fast" would turn out
to be an issue!). If the address lines have to remain stable until /CAS rises, then for sure the glitch will "confuse" the DRAMs.
Delaying PHI0 is a clever solution in that case (which would have never occurred to me!).
Your estimate of 50ns for that delay seems about right based on the LA capture.
Timing in a C64 is a bit tricky, and if something is too slow or too fast the C64 won't be running stable.
Hmm... if we would have wanted a computer that won't be running stable we just would have bought another PC instead of building a CPU.
Quote:
Of course, delaying PHI0 also means that the data to be read from the CPU has to be stable for a longer time
on the data bus, but I think for using the CPU in a C64 this won't be too critical.
Quote:
I agree. The above capture shows that the data lines remain unchanged for quite some time after the fall of PHI2.
There should be plenty of time to grab the data on a read even with a delayed input clock.
I think that the problem is more related to the address bus than to the data bus.
If delaying PHI0 won't fix the problem, maybe we would be going to need a logic analyzer with more inputs...
...don't worry, building your own logic analyzer ain't too difficult (except for transferring the sampled data to a PC and processing it there).
Edit: buying a used HP1630D at ebay might be cheaper than building your own logic analyzer.
Edit2: check shipping costs for "boat anchors" first.
Quote:
Hmm... when building the next CPU, it would make sense to use transparent latches as buffers for all of
the output signals of the CPU for getting around that sort of timing problems somehow.
Quote:
I remember you tried to explain this to me before, many months (years?) ago, and I remember also not understanding it then!
Now I get it.
Ja, tried to explain this to you in 2016. But back then, to me it didn't look like a real and serious problem.
Point is: as a hardware designer, you are getting paid to be a little bit paranoid about what could go wrong with your design,
so if you "smell" that something in a design could cause trouble later, your duty is at least to mention that possible\hypothetical problem.
Quote:
Maybe a special C64 socket-adapter is in order, one that incorporates some transparent latches enabled by /PHI0 for the address bus.
For now, I'm very open to trying the PHI0 delay to see what it does. I do wonder, though, if the DRAM latches mean that something else might be
going on.
IMHO speculating about what might have gone wrong and how to properly fix it would be a waste of time and effort now.
First, we need to collect some more "evidence" for identifying the source of the problem, and it feels like delaying PHI0 would be a good starting point.
Quote:
On another note, thanks for sharing the TI Application Book! I was interested to read the section on "Bus Conflicts" which happened
to start on page 86. I always find these things so interesting!
Ja, there might be "issues" when bringing together chips from different logic families on the same bus.
Insisting to have resistors plugged into a socket for all of the signals between the CPU and the host computer sure didn't simplify
making the PCB layout, but it might simplify debugging now.