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

[ Thread Index | Date Index | More Archives ]

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


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.


Description: Zip archive

Mail converted by MHonArc 2.6.19+