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

[Troed Sångberg <troed@xxxxxxxxxxx>]

Your testprograms testbot/testtop.prg gives me the same values (on STE) as you posted, but I'm still not sure about the videocounter not making a difference. The reason I added removal of right border (which is cycle exact) to my test was to not rely on synclock being positioned the same on different machines (since it depends on the videocounter, back to pre-fetch uncertainty).

(Also I would be wary about a 120 cycle wide switch - on STE you'd risk creating a +2 line already at cycle 36 while on ST you're safe up until cycle 52. But that depends on how you do all the detection etc when adding cycles of course)

/Troed

On Mon, Feb 9, 2015 at 11:07 PM, Nicolas Pomarède <npomarede@xxxxxxxxxxxx> wrote:

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