[hatari-devel] New video code with STF wakeup state :)

[Nicolas Pomarède <npomarede@xxxxxxxxxxxx>]

Hello

I just committed a major rewrite of video.c that deals with all the 
border removal tricks used on STF/STE (top, bottom, overscan, hardscroll 
and so on).

Based on research made by several people since a few years, we now have 
a very good understanding of the inner work of the glue/shifter (and gst 
mcu on STE), which explains a lot "unstabilities" people observed on the 
ST since the 1st try of removing borders.

For the detail of this, as well as for some history of how it happened 
in atari-forum.com, have a look at Troed's wiki article 
http://www.atari-wiki.com/?title=ST_STE_Scanlines where he made a 
description of the state machine in STF/STE (thanks a lot for the huge 
work !)

So far, Hatari basically had some video timings that "just worked" with 
99% of all demos/games. But some advanced video trick (eg 3 lines 
hardscroll on STF) couldn't work in Hatari due to the lack of proper 
wakeup state selection, as well as the corresponding timing (Hatari 
behaved like a mixture of WS1/WS3 timings).

Another limitation in Hatari was the way border detection were made : 
such tricks are often based on switching freq to high res then low res, 
or to 60 Hz then 50 Hz.
To detect changes when a hi/lo or 60/50 transition happened, Hatari 
triggered on the closing switch (ie low res or 50 Hz) and then checked 
if the opening switch was made at a compatible position to overlap left 
border, right border, ...
So, Hatari checked for interval, which can lead to more complex code 
when both switches are not on the same line. This worked, but it gave 
rather long "if" statement sometimes.

This is now all gone too, the new video code will work more like a state 
machine where each change immediately sets some new parameters (start, 
end, number of cycles per line, ...). Consecutive switches can then 
cumulate or cancel previous changes.

I also measured on my STF some less kwown effects of some rare switches 
(those that disturb sync signal) and Hatari should now be much more 
robust / accurate.


Regarding wakeup state, the more difficult part to handle which required 
a lot of rewrite is that freq/res change should be checked with a 1 
cycle precision. In practice, 2 cycles precision is enough, but just 
that implied a lot of changes.

On real STF, there're 4 wakeup states WS1, WS2, WS3, WS4. On power up, a 
state is randomly picked. Not all states appear with the same 
probability, this really depends on the ST model, revision, country, 
...., any internal component could create differences.

Under Hatari, you can choose a random state at each boot or a fixed 
state. By default, I put a fixed state WS3, because this is the state 
where most demos will work (we don't want people to start complaining of 
regressions were such demos worked before and now randomly bugs)

You can use the "--video-timing" parameter when starting Hatari, with 
the following values : ws1, ws2, ws3, ws4, random
(option will be added later in the UI too)

Note that demos requiring wakeup state need to be able to change 
freq/res on a 2 cycle boundary (instead of the usual 4), which means you 
*need* to run in cycle exact mode.


If we consider STF's video, we have 2 main parts :
 - glue/mmu : this will decide when border are opened/closed and pixel 
are displayed
 - shifter : this will display pixel in the right color and at the 
correct resolution

(see Alien / ST Connexion article from old ST Magazine for more details)

With this new code, Hatari should have a very good emulation of the 
glue/mmu process.

Next step will be to emulate the shifter depending on when resolution 
changes happen and during how many cycles ; this is used to stabilize 
overscan as well as the so called "4 pixels hardscroll" (for now, Hatari 
uses some hardcoded cases for these)


Here's a list of some demos affected by wakeup states :

 - Death of the left border by TNT : works in all mode under Hatari 
(although on real ST we should get vertical black bands every 32 pixels, 
but that's not emulated yet (shifter))

 - Omega 1st full screen : work only in ws2

 - TCB in Swedish New Year demos : the TCB logo will be centered only 
in WS2, else it's more on the left side.

 - Musical wonders 1990 by Delta force : this demo only works in STE 
and in WS1/WS3. Under WS4 bottom border won't be removed and under WS2 
right border and bottom border won't be removed. It was not noticed at 
this time, but this demos proved in fact that the STF had at least 3 
different wakeup states (later discussions in 2000 concluded to 2 states 
only, which was wrong)

 - Nostalgic-o-demo main menu by Oxygene : only works in WS1/WS3, looks 
broken in WS2/WS4

 - shforstv by Paulo Simoes : the 1st demo making use of the "0 byte" 
line, which is wakeup state dependant. Works in all 4 states.

 - LoSTE by Sync : works in all STF wakeup states and in STE (STE uses 
hardscroll too by combining border removal)

 - Closure by Sync : works in all STF states as well as STE. This is 
certainly the most advanced hardscroll demo and the ultimate test for 
Hatari new video code :)


All those changes took a lot time, I tried a lot of demos with different 
overscan methods and did a lot of comparison with a real STF too. 
Hopefully, all demos that worked before should still work. Depending on 
the wakeup state, some top/bottom border could also flicker more or 
less, this is often due to some bad timings in the demos.

As a development tool, Hatari should now be much more accurate to test 
some code under some fixed states condition, which can be a huge gain of 
time instead of powering your STF dozens of time before reachign the 
wakeup state you want to test :)

Run all your favorite demos now, try to se different wakeup states (ws1 
can often give bad result) and report any possible regression, to see if 
the demos is really not stable on real STF or if there still some 
emulation issue (it's quite possible I miss a few cases, the glue state 
machine can imply a lot of combinations)


Nicolas


PS : I left a few warning and some old code in video.c, they will be 
removed later when everything is considered stable.