On Tue, Feb 20, 2018 at 8:40 PM, Gerrit Heitsch <gerrit@laosinh.s.bawue.de> wrote: > 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: >>>> > > > > 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). I've already checked on the datasheet, the 4116 doesn't need any setup time before /RAS, it just needs 35 ns minimum hold time on the row address (on the slowest grade, but I expect the PET timings must be ok for a 250 ns DRAM). > > 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). yes, refresh counter was one of the first things that I checked, since the faults seemed to be related to the activity I was doing on the machine (they're not related actually). Crossing fingers to see an address changing too early after /RAS now... Frank Message was sent through the cbm-hackers mailing listReceived on 2018-02-20 20:02:42
Archive generated by hypermail 2.2.0.