Re: strange 2001N fault

On 02/20/2018 08:24 PM, Francesco Messineo wrote:
> On Tue, Feb 20, 2018 at 7:37 PM, Gerrit Heitsch
> <gerrit@laosinh.s.bawue.de> wrote:
>> On 02/20/2018 07:28 PM, Gerrit Heitsch wrote:
>>>
> 
>>
>>
>> Oh.... If your scope is analog, try to set it to 'chop' instead of
>> 'alternate'. The reason for that is that 'alternate' will do a full trace of
>> one signal and then a full trace of the other. If you switch to 'chop', it
>> will quickly alternate between both inputs while doing the traces. This way
>> you get to see what is happening on both inputs at the same time while
>> 'alternate' will introduce a lag. With digital signals that will suggest a
>> relationship between 2 signals that might not actually be there.
> 
> yes, I already knew that. I routinely use chop mode to look at the
> relationship between two digital signals.
> Thank you for the /RAS suggestions, it wasn't clear to me that the
> corruption could happen only close to /RAS being asserted,
> I was also trying to check what was happening before /CAS going low.
> One big problem with analog scopes like mine, is that I can't see
> what's before the trigger, so if an address line is changing right
> before /RAS edge, I won't see it.

This will take a bit longer, but try to trigger on the address line 
going high or low. If that happens too early, you will then see /RAS 
going low right after.

Of course that means you need to switch the trigger to see both.


> I'll see how close is too close for a 4116 anyway, maybe I'm lucky if
> I can have a couple of /RAS cycles on the same sweep and still
> measure when an address is changing too close (if any).

It would be the best explanation for strange memory problems. If you 
can't see anything and the control signals look good, it might be time 
to swap the 74LS153 just to be sure.

Of course, you also need to verify that the refresh counter actually 
counts properly and that should be easy enough to check. 4116 want 128 
refresh cycles in 2ms. If the refresh  counter doesn't work, the memory 
accesses from the CPU will be all the refresh the DRAM gets and then it 
depends what rows the CPU is actually accessing... (since every read 
access is also a refresh).

  Gerrit


       Message was sent through the cbm-hackers mailing list