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

[Nicolas Pomarède <npomarede@xxxxxxxxxxxx>]

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

Attachment: st_test.zip
Description: Zip archive