[hatari-devel] Interrupt assert triggered by video.c

[npomarede at corp.free.fr]

On Fri, 10 Jul 2009, npomarede at corp.free.fr wrote:

> On Fri, 10 Jul 2009, Eero Tamminen wrote:
>
>> There seems to be a pretty obvious bug in Video_ConvertPosition():
>> -------
>>        *pHBL = nHBL;
>>        *pLineCycles = FrameCycles - ShifterFrame.ShifterLines[
>> nHBL ].StartCycle;
>>
>>        if ( *pLineCycles < 0 )                                 /* reading
>> from the previous video line */
>>        {
>>                *pHBL = nHBL-1;
>>                *pLineCycles = FrameCycles - ShifterFrame.ShifterLines[
>> nHBL ].StartCycle;
>> ===> "nHBL" instead of "nHBL-1"
>>        }
>>
>>        else if ( *pLineCycles >= nCyclesPerLine )              /* reading
>> on the next line, but HBL int was delayed */
>>        {
>>                *pHBL = nHBL+1;
>>                *pLineCycles -= nCyclesPerLine;
>>        }
>> -------
>>

>
> Yes, there could be a problem when *pLineCycles < 0, I need to check this
> next week, I'm away at the moment.

Hello,

I had some time to check the case when *pLineCycles < 0 ; in fact this is 
really rare case, that can only happen when reading screen counter with 
Video_CalculateAddress because in that case we need to substract 12 cycles 
to get the correct value (such programs are those doing "sync protection", 
repeatly reading the content of $ff8209 to decrypt a piece of code).

So, if a program tries to read $ff8209 between cycle 0 and 12 of a line, 
you will get a <0 result. But as this value is not used to compute any 
interrupt, it's just a one time error, even the video counter value will 
be correct because it's the same anyway at position 0 or -12 (as display 
is off).

I committed the fix for the correct value in that case, but unless further 
traces could be made, I don't think this was the cause of the lock up 
you observed :(


Nicolas