Image Map Image Map
Page 5 of 18 FirstFirst 12345678915 ... LastLast
Results 41 to 50 of 178

Thread: Memory problem with PET 2001

  1. #41

    Default

    It's easier to see with no CPU. You should just get FA0...FA6 incrementing and nRAS toggling at 2x; that should be enough for refresh. Everything looks fine so far... which is why I keep mentioning voltages...

  2. #42
    Join Date
    Jun 2012
    Location
    UK - Worcester
    Posts
    4,459

    Default

    Post #28 should cover the rail voltages.

    Worth double-checking them though with an oscilloscope - looking for dc level and ripple/noise.

    That should put the rail voltage issue to be fairly quickly.

    Can we then look at the data bus in more detail please please?

    Dave

  3. #43

    Default

    Quote Originally Posted by daver2 View Post
    Post #28 should cover the rail voltages.
    "The +/- 5 and 12 V lines all are very close to the desired value and with about 10 mV of ripple."
    Ah OK. Missed that. If these were measured AT the DRAM sockets then fair enough.

  4. #44
    Join Date
    Jun 2012
    Location
    UK - Worcester
    Posts
    4,459

    Default

    I suppose it is also worth pointing out that there are two (2) +5V regulators (and, therefore, two +5V rails) on the PET 2001N.

    Obviously, both dc supplies need to be within tolerance for the PET to function correctly...

    Dave

  5. #45

    Default

    Quote Originally Posted by Nivag Swerdna View Post
    It's easier to see with no CPU. You should just get FA0...FA6 incrementing and nRAS toggling at 2x; that should be enough for refresh. Everything looks fine so far... which is why I keep mentioning voltages...
    I pulled the CPU as you suggested and get exactly what you describe:
    refresh_counters_RAM_address_at_muxes_nocpu.jpg

    I also looked at the RAM supply voltages again, which I'll cover in a post below.

    Greg

  6. #46

    Default

    Quote Originally Posted by daver2 View Post
    Post #28 should cover the rail voltages.

    Worth double-checking them though with an oscilloscope - looking for dc level and ripple/noise.

    That should put the rail voltage issue to be fairly quickly.

    Can we then look at the data bus in more detail please please?

    Dave

    I checked the voltages at the RAM chips again and looked at them on the scope. The results are below. All scope traces were taken AC coupled at 20 mV/division

    pin 9, 5V: 4.97 V
    5V at DRAM.jpg

    pin 8, 12V: 12.17 V
    12V at DRAM.jpg

    pin 1, -5V: -5.06 V
    -5V at DRAM.jpg

    These were taken with the PETTESTER running. Whenever the screen changes (about every second) the details of these waveforms "jumps" but then settles back down. I neglected to measure 5V at the processor end of the board, which I think is what the other regulator drives. It's hard to know which handles what without following the traces.

    I also looked at the data lines at the buffers near the RAM chips (I10 and I11) with the logic analyzer. An image of the waveforms is below. I only have 16 channels so I'm showing the 7 lowest bits and the two control signals. The high order bit seems to behave pretty similarly, though.
    RAM_buffers.jpg

    Again, it's a little hard to totally understand this, but by setting the triggers for the data lines on each side of the buffers to the same bit pattern and looking at the signals when the LO READ and LO WRITE signal are low, I think that the signals are the same on both sides of the buffers when they're supposed to be. I think this means that the buffers themselves are probably ok.

    However, there are a bunch of correlated "glitches" on the data lines on the DRAM side of the buffers, all or most of the data lines spuriously going high at the same time when they're not attached to the data bus. This can also happen during a read, which the buffer seems to propagate back across to the rest of the buffered data bus. When writing, the buffers seem to be able to pull those signals to the correct value and the values on the DRAM side of the buffers follow the input values. There are also often transients in the LO READ signal when it should be low.

    My thinking is that these inconsistent signals are the next step up the chain of causality as to why the RAM isn't working properly. Are there any ideas as to what could be causing this? I wish I had a digital scope so I could try to capture these transients in more detail than just with the logic analyzer. Maybe that should be my next purchase.

    Again, thanks for all the help so far and for any more help you can offer.

    Greg
    Last edited by grbrady; January 21st, 2021 at 08:57 PM.

  7. #47

    Default

    If you plot FA0...FA6 and nRAS (and maybe a few more for good luck) at the DRAMs when there is NO CPU present you should get clear refresh signals on that side. That would eliminate most things.

    Also... Have you depopulated the DRAM? Maybe going to a small number of devices would help if they are contending with each other?

  8. #48
    Join Date
    Jun 2012
    Location
    UK - Worcester
    Posts
    4,459

    Default

    Assuming RDx is the RAM Data, then the logic analyser is indicating potential problems somewhere...

    Unfortunately, a logic analyser is no good for looking for this type of potential fault. You need to use a scope.

    Can I suggest doing what is in post #47 and I will think about how to proceed on the data bus?

    What make and model is your scope? I will see if we can interconnect your logic analyser and scope together...

    Are any if your DRAM chips in sockets by any chance?

    Dave

  9. #49

    Default

    I'm sorry I only just understood your plot...

    The only times that really matter are when LO_READ or LO_WRITE are low. (It's nice to see that LO_READ and LO_WRITE are mutally exclusive!)

    Now when LO_READ is low this means read from DRAM... RD0 and friends are not positively driving... bad news... and on the other side of the buffers it is doing its best but it's glitchy because of the DRAM side. The 74LS244s are schmitt triggered and you can see this as they square up the incoming glitch.

    When LO_WRITE is low the CPU drives... and you see this happening.

    I think that proves the buffer on the plot is fine and that LO_READ and LO_WRITE are good.

    It does however show the the DRAM isn't driving.

    That's my 2c anyway.

    PS

    I see on an earlier trace that MUXA is flat. That's not good. MUXA is needed to select the row/col.

    If MUXA is always low... look at pins of H4.
    Last edited by Nivag Swerdna; January 22nd, 2021 at 09:55 AM.

  10. #50

    Default

    Quote Originally Posted by Nivag Swerdna View Post
    I see on an earlier trace that MUXA is flat. That's not good. MUXA is needed to select the row/col.
    My error there... MUXA was working in earlier plots... MUXA will be a bit indeterminate with no CPU fitted as it is partially derived from R/nW output. My bad.

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •