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

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

On Wed, Feb 4, 2015 at 5:25 PM, Troed Sångberg <troed@xxxxxxxxxxx> wrote:

Thanks Nicolas, I'll take a look at both your code and redo my own measurements (pasted below). Besides a general small cycle difference my assumption would be that your STF measurements were in WS2/WS4 which would explain why they're "later" compared to STE (and ST WS1/WS3). The only thing that still puzzles me is how you could get a border to open with 50Hz active at cycle 502.

synclocked ST WS3/WS1:

488/502 fail

496/504 ok

502/512 ok

504/512 fail

502/40 ok

502/52 ok

502/54 ok +2

synclocked ST WS2/WS4:

496/504 fail

500/508 ok

502/512 ok

504/512 ok

506/4 fail

... but for STE I only have a comment in my notes, not a table like above, as to 502 being the correct cycle:

-> cycle 502 is the latest a move to 60Hz can happen to open the lower border on an STE (just after hsync end)

-> cycle 504 is the earliest a move to 50Hz can happen to open the lower border on an STE (just after hsync end)

I'll get back to you.

/Troed

On Wed, Feb 4, 2015 at 12:39 PM, Nicolas Pomarède <npomarede@xxxxxxxxxxxx> wrote:
Le 04/02/2015 00:26, Troed Sångberg a écrit :

Right, so, the GLUE has no concept of switches ;) It's just a question
of what values are in the registers when the state machine reaches a
possible state change. I looked into my notes and my recall was
incorrect - the position in question is cycle 502. So, if $820a is 60Hz
at that cycle on line 33 or 199 the corresponding border will "open".

And according to my notes this is valid for STE & ST WS1/WS3. For ST
WS2/WS4 it's 504. (Tests done on synclocked lines - there are other
issues if counting from HBL.) Of course, any RES detection we already
know differs between wakestates so this is as expected.

Being back at 50Hz already at cycle 500 (and staying there) shouldn't
work according to my own synclocked tests :/

Hi

Back in 2007-2008, when I started hacking on Hatari I noticed some demos sometimes worked or not, due to the combinations of several problems : bad cycles for some instructions, bad emulation of write cycle position inside an instruction, but also difference when using STF or STE mode.

So, I wrote a lot of test programs to measure as precisely as possible some important video timings :
- when does vbl start
- when does hbl, timer b start
- how long take an interrupt
- how many jitter in interrupt, with which patterns
- where to remove top/bottom border
- overscan, 4 pixels hardscroll
- and so on

The purpose of those tests is to be as "simple" as possible by disabling all other possible sources of "randomness" to get a 100 % repeatable test that can be run on any STF/STE or emulator.

Attached, you will find 2 programs that do self-calibration to see where the 60/50Hz switch can be done at max to still remove top/bottom border.

- testtop : I wait for line 198 on VBL N-1, sync with ff8209 and wait a big number of nop before doing the 60/50 switch during VBL N. At start, the switch will be too late (around line 35 maybe), then I decrease the delay until top border is removed. After that I wait a constant number of cycles to be sure display has started and I read ff8209. On STF, we get ff8209=$1c, but on STE we get $1a.
So the top border removal on STE could only be made 4 cycles earlier than on STF.

- testbot : similar test, I wait for line 198, sync with $ff8209 and decrease a delay by doing 1 NOP less on each try, until bottom border is open. Here again, after reading ff8209 on STF we get $1c, but on STE we get $1a.
Same result, bottom border removal max position on STE is 4 cycle earlier than on STF.

Those tests were made on my STF and on Anders/Evil STE, so I'm rather confident the results are correct.

When converted in cycles, this gives a max position of cycle 504 for STF and 500 for STE.

Other tests show that the VBL interrupt position has also a 4 cycles difference on STE when compared to STF.

Of course, there're some differences in STF due to WS, and my programs have 4 cycle precision (not 2) because they only wait with nop, but as most demos write to IO reg with 4 cycles precision, that's not too important for the comparison.

The point is that the same code when running on a STF will be able to remove border at pos 504, but on STE it won't work. On STE latest possible position is 500.

Here're the result you will get on screen :
testtop :

STF : TopBorder : cycles since sync=$aa5c, vid counter=$1c, line top cycle=$01f8
STE : TopBorder : cycles since sync=$aa58, vid counter=$1a, line top cycle=$01f4

testbot :
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

If we look at the emulator Steem, it's also known that Steem emulated STE timings, not STF. That's why some STF demos requires some patches to work anyway under Steem 3.2 (since then, the new Steem versions have timings for STF and STE).

So, based on my measures on different HW, I really see a difference on where some freq values are interpreted to do video tricks.

Nicolas