Re: In search of bad 4164, 41256 DRAM

From: Gerrit Heitsch <gerrit_at_laosinh.s.bawue.de>
Date: Tue, 17 Sep 2019 19:10:59 +0200
Message-ID: <6caef421-93c4-5d88-1096-abee6d80ecc0_at_laosinh.s.bawue.de>
On 9/17/19 7:02 PM, Mia Magnusson wrote:
> Den Tue, 17 Sep 2019 18:27:39 +0200 skrev Gerrit Heitsch
> <gerrit_at_laosinh.s.bawue.de>:
>> On 9/17/19 6:19 PM, Mia Magnusson wrote:
>>> That is simple to do on a PC/XT as you can control the refresh
>>> circuit. You have to do some tricks though as a parity error on ram
>>> read will trigger an NMI.
>>
>> It also depends on the architecture. To do it correctly, you need at
>> least 2 memory banks that are not serviced by the same /RAS signal.
>> Many systems run all RAMs on the same /RAS and select the banks with
>> the /CAS signal. Unfortunatly, in this case, /RAS is all you need for
>> refreshing a row and running your code in bank 0 will also refresh
>> bank 1.
> 
> Well, assuming you can disable all interrupts so the CPU doesn't fetch
> any data from low memory, you could put your idle code in the
> graphics/display card ram. That would most likely make sure it won't
> cause any RAS signals, unless the DRAM controller asserts RAS even for
> addresses outside the DRAM area.

It depends... Simple DRAM controllers will just assert /RAS on every 
single cycle (looking at you, VIC and TED) and use /CAS to determine 
whether RAM access is needed after all. Keeps the logic simple. But as 
soon as you use page mode and other tricks, asserting /RAS only when 
needed would be comparatively simple to add.

  Gerrit
Received on 2020-05-29 22:45:03

Archive generated by hypermail 2.3.0.