Re: [hatari-devel] Yanartas demo doesn't work in ST mode

[Nicolas Pomarède <npomarede@xxxxxxxxxxxx>]

Le 09/02/2015 22:44, Troed Sångberg a écrit :
> Right, now back. I've remade my measurements with newly developed code
> to minimize any possibilities for mistakes. The code does the following:
>
> vsync
> synclock
> open right border successfully (this is to make _sure_ I know which
> cycle I'm on)
> wait 199 lines minus above switch
> open right border successfully (again .. )
> wait X cycles
> open lower border
>
> (A pattern in videomem makes sure I can see opened borders etc)
>
> "Switch" results table for synclocked STE lower border:
>
> 488/502 = fail
> 488/504 = open
> 492/500 = fail
> 494/504 = open
> 492/500 = fail
> 496/504 = open
> 498/508 = open
> 500/504 = open
> 500/508 = open
> 502/512 = open
> 504/512 = fail
> 508/4 = fail
>
> = the STE check for 50/60Hz with regards to number of lines is at cycle
> 502. The same cycle as I've documented for ST WS1/WS3.
>
> I'm sorry it doesn't match your measurements but I cannot find where in
> the above I would've made a mistake. I did however pick up on one thing
> in the test code you described - you used the screen address and detect
> a different value (two bytes less) for STE compared to ST. On
> Atari-Forum I've just had a discussion in the old horisontal scrolling
> thread with Steven Seagal on when the "MMU" in the STE updates the
> screen adress considering it must've put the address on the bus for the
> Shifter to be able to _preload_ its registers with data for a possible
> hardware scroll early pixel display. I'm wondering if that might confuse
> code relying on the screen adress but haven't researched it further.
>
> (I've attached my code in the event that this is all just about us
> counting cycles differently)
>
> regards,
> Troed

Hi

I see what you mean about prefetching pixels earlier to allow hscroll, 
but in that case, I don't think it matters. It could show a difference 
if I tried to read ff8209 just before cycle 56 (which for me is the end 
of the left border), but in my test I really read ff8209 much later, 
around cycle 90, so the prefetching should not come into account.

Here's part of my test :

        lea     .wait_bottom2(pc,d6.w),a5
        jmp     (a5)

;-- line 198+63, pos 408
..wait_bottom2
        dcb.w   BottomBorder_CyclesStart/4,$4e71

        move.b  d0,(a2)                 ;  8 cyc
        REPT 10                         ; 40 cyc
        nop
        ENDR
        move.b  d2,(a2)                 ;  8 cyc
        REPT 20-2                       ; 76 cyc
        nop
        ENDR
        move.b  (a0),d3                 ;  8 cyc

        move.w  #$700,(a1)              ; red
        move.w  #$777,(a1)              ; white

        tst.b   d3
        bne.s   .done

        add.w   #4,BottomBorder_SkipCycles
        dbf     d7,.loop

In total, we have 30 nop between switch to 60 Hz and switch back to 50 
Hz, and then I read ff8209.
So, either d3=0 and this means bottom border was not removed, or we have 
d3!=0 and border was removed, but with 120 cycles I should really be 
after the start of the line.

In the value I printf at the end of my test, cycles since sync is the 
number of nop used in BottomBorder_SkipCycles :

STF :         BottomBorder : cycles since sync=$25c, vid counter=$1c, 
line bot cycle=$1f8
STE :         BottomBorder : cycles since sync=$258, vid counter=$1a, 
line bot cycle=$01f4

Do you get similar values on your STE ?

We have a 4 cycles difference in the number of nop before doing the 
60/50 switch, so this is coherent with the difference in video counter 
1c instead of 1a.

It's not that I don't agree with your values, but maybe there's 
something else, because with the same program under STF and STE we 
really see that the number of nop is different, even after synchronizing 
with ff8209 at line 198.

Nicolas