Re: DRAM refresh

From: Gerrit Heitsch <gerrit_at_laosinh.s.bawue.de>
Date: Sat, 15 Oct 2016 21:33:53 +0200
Message-ID: <9def0753-4c41-8880-decf-341b9fc30490@laosinh.s.bawue.de>
On 10/15/2016 09:05 PM, silverdr@wfmh.org.pl wrote:
>
>> On 2016-10-15, at 19:01, Gerrit Heitsch <gerrit@laosinh.s.bawue.de> wrote:
>>
>>> I see this I can copy and modify the code but HOW ON MOTHER EARTH SOMEONE COULD HAVE GUESSED THAT THIS NEEDS TO BE DONE IN SUCH ORDER TO GET SUCH EFFECT?!!!"
>>
>> Well, I think it started slowly... Like 'what happens when I switch to 24 rows after the beam has passed the 24 mark? Oh, the border disappears'.
>
> Borders were still "easy enough" to guess along the lines: VIC turns on the border when it reaches the end of the 25th row. It doesn't turn it on when passing through the end of 24th. But if I switch it to 24 rows right after the 24th is already rendered, then it may "think" that the border is already on and skip turning it once more. Then horizontal borders were a natural extrapolation of the same thougts. But for some of the newer effects I couldn't find convincing story to say to oneself as explanation how it could be guessed.
>

Yes, but once the borders were mastered, curious minds will look at 
other features and what happens when you enable/disable them at the 
right moment.

The breakthrough was finding out that VIC can be made to behave 
differently from the data sheet. From then on it was just a matter of 
try and error.

See what people have been able to make TED do by playing with the 
vertical and horizontal counters.


  Gerrit



       Message was sent through the cbm-hackers mailing list
Received on 2016-10-15 20:00:36

Archive generated by hypermail 2.2.0.