Re: Fat40 RAM problem?

From: A. Fachat <>
Date: Sun, 31 Aug 2014 16:14:34 +0200
Message-ID: <37095541.nPA6rObfk4@euler>

On Friday 29 August 2014 11:15:37 William Levak wrote:
> > On Fri, 29 Aug 2014, A. Fachat wrote:
> > What looks interesting is that the data I/O pins of the RAM even stays
> > high
> > when I write a zero into it! I.e. either the RAM is broken and pulls the
> > line high, or the driver (or something else) is broken. However, I cannot
> > see why the combination of address bits should create a driver failure.
> Internal short in the driver chip.  I've run into this before.  Only
> certain combinations of bits produce the error.

I've tried to trace the error a bit more. See some scope pics here

What I find interesting is that the address lines are all stable and look 
correct, the /RAS and /CAS1 lines look clean,  all looks like it should.

Yet, of the two memory accesses (it's a STA ($11),Y in the BASIC POKE 
command), on a bad memory address it always reads "1" then writes a "0", on a 
good memory bit it also reads the "0" it had written there before.

The data lines do not conflict - in my previous mail I only actually looked at 
the first access, the read. In fact the dRAM data lines directly connect to the 
CPU's data lines.

So if it is not the RAM, what could happen in the driver - probably UE9 or 
UE10 here 
that causes this? Probably a slight delay in switching the line on or off?

Is it probably a mixup of somewhat larger delay in the driver, and a specific 
low tolerance (high setup time) in this particular RAM chip?


       Message was sent through the cbm-hackers mailing list
Received on 2014-08-31 15:00:03

Archive generated by hypermail 2.2.0.