Re: DRAM refresh

On 10/14/2016 12:20 PM, Hegedűs István wrote:
> Hi,
>
> Yes. It was a surprise for me also. Indeed it rolls over inside the
> visible screen area several times, however there is a forced clear in
> scan line 0 thus the refresh is uneven. Some rows get more refresh.

Now we only have to find out if VIC does the same which would mean they 
just took that block from VIC when making TED.

We still lack a highres die shot of an 8360R2. The only one I have is 
from a 8360R1 and is only 2176x2061.


  Gerrit



> Hege
>
> -----Original Message----- From: Gerrit Heitsch
> Sent: Friday, October 14, 2016 8:26 AM
> To: cbm-hackers@musoftware.de
> Subject: Re: DRAM refresh
>
> On 10/13/2016 11:10 PM, Hegedűs István wrote:
>> Hi,
>>
>> I have played a lot with TED's refresh counter. The counter's enable
>> signal is maintained by a latch which is triggered by the horizontal
>> counter at position 296. Horizontal position 336 clears this enable
>> signal.
>> Playing with hcounter and setting the right value at the right time I
>> have managed to bypass this clear signal but the refresh single clock
>> signal ended normally (single clock change is triggered by different
>> hcounter value). The result was that refresh counter stayed on and
>> counted while the CPU was running already on double clock. This way I
>> have managed to identify that TED clears the refresh counter at
>> horizontal position 431 when the scanline is 0 (or the refresh counting
>> has stayed on by manipulation or TED stop bit is active).
>
> You mean that the refresh counter is cleared at a certain position
> instead of just rolling over? I wonder why they did that since it will
> produce an uneven refresh.
>
>  Gerrit
>
>
>
>       Message was sent through the cbm-hackers mailing list
>
>       Message was sent through the cbm-hackers mailing list
>
>


       Message was sent through the cbm-hackers mailing list