horizontal scrolling on ST

[troed]

Ah, there we are! The switch to 60Hz happens just before HSYNC. It's not the first time I suspect there's an init happening there - it really needs to be investigated and codified. I'm not really sure why that would affect the checks though so currently I can offer no help. Paulo's investigation (STF) says the 60Hz switch can be as early as 378 on the line before so whatever causes it could be STE specific (even preload-related .. hmm. Another thing to test).

Now tested. So the question was how come some demos (DSOTS) don't produce +2 lines on STE even though they switch back to 50Hz at cycle 40, being in 60Hz since the line before. Unfortunately my test did not support STE init behaviour different from STF and as Paulo has documented the switch to 60Hz can be just after the right border position. I just ran the following test suite tonight:

60Hz/50Hz

Code: Select all

432/36     160
432/38     162
432/40     162
432/42     162
432/52     162
452/52     162
464/52     162
476/52     162
488/52     162
500/52     162
0/52         162

CODE: SELECT ALL
-30 - 456:S0000 512:T0100 512:#0000
-29 - 040:S0002 344:S0000 392:S0002 440:R0000 456:R0000 508:R0002 512:T2008 512:#0158

.. and so would still consider switches like the ones above to produce an NTSC-position 160-byte line (+2 left and -2 right) on STE. It's very strange if they don't on real hardware.

Is this correct? [edit: I ask because I suspect it's wrong]

It's fully possible I've misunderstood posts on which type of modifications to BLANK start and HSYNC start/end cause long-duration lines without increasing HBL. I'll have to either test myself or re-read the old threads Or defer to Paulo who might have that documented already.

Coming back to 184 bytes lines, running tests reminded me of this case:

CODE: SELECT ALL
Frame freq: 60 shift mode: 1 WU: 0
Disk A: HighResMode STE
-34 - 390:V000C 394:M0006 416:v0000
-33 - 120:j0006
000 - 452:w050C 456:w0706 468:w0948 504:R0002 508:TC000 508:#0160
001 - 012:R0001 432:R0002 444:R0001 504:R0002 508:T20000 508:#0184
002 - 012:R0001 432:R0002 444:R0001 504:R0002 508:T20000 508:#0184
003 - 012:R0001 432:R0002 444:R0001 504:R0002 508:T20000 508:#0184
004 - 012:R0001 432:R0002 444:R0001 504:R0002 508:T20000 508:#0184
...


In HighResMode, the frames stay at 60hz all the time, there's not a single sync switch.
Conceptually (nice word), those are 60hz lines without left border, hence, directly, 184 byte lines.
By the way the res switches are exclusively R2/R1.

Yeah, what happens is that the left border is opened (using the hires/71Hz position at cycle 0 to activate preload - which is finished and DE raised at cycle 4) and then by always being in 60Hz the check at cycle 56 will produce a 508 cycle line and the check at 372 for deactivating DE will be true.

(372-4)/2 = 184

/Troed

[Steven Seagal]

Now tested. So the question was how come some demos (DSOTS) don't produce +2 lines on STE even though they switch back to 50Hz at cycle 40, being in 60Hz since the line before. Unfortunately my test did not support STE init behaviour different from STF and as Paulo has documented the switch to 60Hz can be just after the right border position. I just ran the following test suite tonight:

60Hz/50Hz

Code: Select all

432/36     160
432/38     162
432/40     162
432/42     162
432/52     162
452/52     162
464/52     162
476/52     162
488/52     162
500/52     162
0/52         162

/Troed

Well, the test results are clear. Is it possible that DSOTS was broken on STE?

[troed]

Well, the test results are clear. Is it possible that DSOTS was broken on STE?

So I have an HxC floppy emu with No Fragments 1 on the SD-card and an STE right next to me ...

*booting up Dark Side of the Spoon*

Which screen do you mean by "first screen" btw? The intro with the repeating coloured balls background and rotating info-logo? "The intro".

It looks fine. Can't see a single line off and the info-logo is centred. (Slight discolorization of 8 pixels at the extreme right sometimes which I recall to be fully normal)

(My next guess would be the leftmost door - the syncscrolling woman holding up a scroll text. It also looks fine)

I love this demo. What a masterpiece.

edit: There are three images of DSOTS on No Fragments 1: SPOON.MSA, SPOON_P.MSA and DARKSIDE_P.MSA. "P" means patched, as far as I've understood, but I've tested the intro screen on all three with the same results.

/Troed

[Steven Seagal]

Which screen do you mean by "first screen" btw? The intro with the repeating coloured balls background and rotating info-logo? "The intro".

/Troed

Yeah, the first fullscreen after boot.
It's great that you can test such thing.

There are other possibilities:
- for some reason timing is off in Steem and DSOS actually never hits S2 at cycle 40
- your cycles are off by 4 in the test, I'm surprised by 432/38 162

About the demo, I appreciate it for its test-value, but also the rotating ball screen for itself, found it impressive.

[troed]

There are other possibilities:
- for some reason timing is off in Steem and DSOS actually never hits S2 at cycle 40
- your cycles are off by 4 in the test, I'm surprised by 432/38 162

Well, don't know about Steem but I don't think my test is off It's compliant with the other research on the state machine for STE:

Code: Select all

0	IF(RES == HI) PRELOAD = TRUE
...
36	IF(FREQ == 60) && (RES == LO) PRELOAD = TRUE
40	IF(FREQ == 50) && (RES == LO) PRELOAD = TRUE
56	IF(FREQ == 50) LINE = PAL
...
376	IF(FREQ == 50) && (RES == LO) H = FALSE

Line being in 60Hz since cycle 432 on the line before doesn't trigger the check at cycle 0 but it does trigger at cycle 36 (which preloads for 16 cycles and then raises DE at cycle 52). The switch back to 50Hz can be done at any time from cycle 38 to cycle 56 (if we want a PAL 512 cycle line).

(376-52)/2 = 162

DSOTS was released in 1991 so I'm sure they tested it extensively on STE. Whether the switch back is really at cycle 36 instead of 40 (the "nearest" error) or if there's an STE test that changes the code but isn't picked up in emulation is difficult to know without stepping through the actual code.

/Troed

[Steven Seagal]

No, I think timings are the same for STF & STE.
There must be a bug in Steem then (VBI timing?).

[troed]

No, I think timings are the same for STF & STE.
There must be a bug in Steem then (VBI timing?).

I'm not sure what such a bug would look like - the timings in the frame you posted make perfect sense otherwise.

However, recall that LoSTE top border also works perfectly on my STE but fails on an NTSC-MSTE. I also spent quite some time making it stable in Hatari*. Top border removal is sensitive to MFP timer differences and I guess since there are differences between ST hardware models that applies to emulators vs hardware as well. Maybe that's why you see the switch back at cycle 40 in Steem even though my STE doesn't.

/Troed

*) From my LoSTE testing notes just minutes before I decided it was time for release:

Done: That same image is completely unstable in Hatari ST. Looks like top border +2. In Hatari STE it's ok. Loading logo correct in both 1Mb and 4Mb config on both ST and STE.

The unstableness is not connected to EXG before first switch. It might be connected to #20 instead of #17 delay though. If we switch this on, it might work on all my hardware but I'm wary about those STs with different clock chips …

(It did work on all my hardware, incl. emulators, but not on slower STFs nor faster STEs ... I'll release an updated version within the next 22 years or so)

[Steven Seagal]

edit: There are three images of DSOTS on No Fragments 1: SPOON.MSA, SPOON_P.MSA and DARKSIDE_P.MSA. "P" means patched, as far as I've understood, but I've tested the intro screen on all three with the same results.

The patch is for a CPU exception in the loader that wasn't correctly handled by emulators before (low stack?):

Code: Select all

Exception #2, 2 bombs (BOMBS_BUS_ERROR) during Write
PC=4AE-IR=1941-Ins: move.b d1,+$2476(a4) -SR=2708-Bus=6396D7-Vector $8=4FE
D0=CF8 D1=78E507C6 D2=FFFF D3=1180000 D4=FFEC D5=14 D6=72FB0 D7=467265FF 
A0=20300 A1=4B6 A2=FFFFF6E6 A3=48 A4=20637261 A5=50953577 A6=484 A7=1C 
Push PC 4B2 on 18
Push SR 2708 on 16
Push IR 1941 on 14
Push address 6396D7 on 10
Push status 1945 on E

I'm not sure what such a bug would look like

Bugs look like this:

Ha ha

- the timings in the frame you posted make perfect sense otherwise.

It's because after the suspect 40 S2, the timings are synchronised on the video counter:

Code: Select all

-29 - 040:S0002 048:r0900 068:r0902 392:S0002

However, recall that LoSTE top border also works perfectly on my STE but fails on an NTSC-MSTE. I also spent quite some time making it stable in Hatari*. Top border removal is sensitive to MFP timer differences and I guess since there are differences between ST hardware models that applies to emulators vs hardware as well. Maybe that's why you see the switch back at cycle 40 in Steem even though my STE doesn't.
/Troed

Yes, but Steem's should be a PAL STE, its CPU/MFP timings are like SainT's and Hatari's.
Now I think that the 40 S2 is at its place and that the mystery could be something different and very interesting.
Remark that the frame ends like this:

Code: Select all

244 - 012:R0000 376:S0000 392:S0002 512:T0011 512:#0230

This is an unstable 230 byte line, and this could very well have an impact on the line +2 of next frame.
Didn't Paolo say that a scanline at 60hz resets the Shifter?
This is no precise explanation but I will go with this theory like I did for Dragon by Ghost, because unless timings are wrong, it's the thing that makes most sense to me (and it's fun).

Code: Select all

T0011 -> Shifter PreLoad=3 

Line +2 test positive -> If PreLoad=0, +2, if PreLoad<>0, reset Shifter

Note that the Shifter is reset by another sync line even if there's no "+2", eg:

Code: Select all

-26 - 012:R0000 376:S0000 392:S0002 440:R0001 456:R0000 508:R0002 512:T2011 512:#0230

So that screen is guaranteed to work.

[Steven Seagal]

*) Cancel HSYNC at 462 doesn't really produce a 0-byte line as it produces "no line". The behaviour of a double length (in duration) line is very TV/monitor specific but from the ST point of side it doesn't exist.

I agree with this: there's no HSync, the line is fetched but the monitor can't display it, so it has the same effect as a 0 byte line.

Code: Select all

scanline 1
scanline 2 not fetched  (other tricks)
scanline 3

scanline 1 | scanline 2  (this trick)
scanline 3

visible effect:
scanline 1
scanline 3

Is this correct? [edit: I ask because I suspect it's wrong]

Case: Beyond/Pax Plax Parallax STF

HBL isn't increased so there will be an extra line at the bottom of the screen.

In emulation we mustn't add an extra line, I think HBL++ occurs at around cycle 500 when HSYNC is cleared.

Extending HSYNC at 502 might produce something similar although I'm less sure.

Here you have a 0-byte line and you must add one line at the end. That's why I would place HBL++ at that cycle.
Cases: No Buddies Land, Delirious 4/NGC

After looking at it again...

- My little schema wasn't correct. It was as if the screen was scrolled upward, but it's scrolled downward. The monitor displays one extra line while the video RAM isn't fetched.
My explanation "the line is fetched but the monitor can't display it" is wrong.
I think now that when HSYNC isn't completed (no start or no end), the machine state won't set DE on next line. Exactly how I don't know.
But the cathodic ray doesn't depend on HSYNC to go downward, its movement is continuous (I learnt that today), hence the scrolling effect.

- Timing of HBL++ could be HSYNC stop, or depend on HSYNC being completed at the end of the line.
Concretely in emulation we must count one bonus HBL for D4/NGC (end HSYNC), but if we count one for Pax Plax Parallax, it's fine too.

[Dio]

But the cathodic ray doesn't depend on HSYNC to go downward, its movement is continuous (I learnt that today), hence the scrolling effect.

I would expect it to depend on the circuitry inside the TV - assuming it's a PLL, then you'll get a 'default period' HSYNC which will be about right, but not exactly right.

[Steven Seagal]

While messing with display size in emulation, I wondered about the real maximal visible width of a scanline.
Is it 412 or 416 pixels?
For example, the intro of Forest says it's 416.
But ljbk's demos, including Forest, are limited to 412 visible pixels because removing the left border loses the first 4 pixels.

You can also compare this Steem display, 412 pixels:


with an Atari ST screenshot (supposedly!):


The right border cut looks precisely the same.

For the moment, considering these (rare) elements, I would go with 412.
I ask this because in last beta I put 416, but it seems useless now. Many demos have problems.
Eg: Transbeauce 2 boot screen fine, menu not fine.

[Steven Seagal]

Nobody dares contradict me, I will do it myself. Still in Steem, I noticed some demos deliver trash between pixels 412-416 but some are fine. Here's a list, with more 'Fine' than 'Trash':

Code: Select all

Program                           Right border 48
======================================================================

Amiga Demo                        Fine
BBC52                             Fine
Beyond/Kruz Finland               Fine
Beyond/PPP                        Fine (trash in left)
Beyond/Twin twist                 Fine
Beyond/Universal Coders           Stop + trash (+trash in left)
Cuddly fullscreen                 Fine
Darkside of the Spoon boot        Trash 
Darkside of the Spoon menu        Fine
Darkside of the Spoon distort     Stop
Darkside of the Spoon scrollers   Trash (look well)
Death of the Left Border          Fine
D4 Menu                           Trash
D4/Tekila                         Fine
Dragonnels Great plazma           Fine
Dragonnels Unlimited Bobs         Fine
European Demos boot               Fine
European Demos menu               Fine
Forest                            Stop
Musical Wonder 1990 (WU1)         Fine
Nostalgia menu                    Fine
Omega Full Overscan               Fine (they planned 464 pixels)
Overscan Demos                    Stop
Phaleon Beast menu                Trash (top OK)
SoWatt menu                       Stop
SNYD/TCB                          Fine
Transbeauce 2 boot                Fine
Transbeauce 2 menu                Trash
Transbeauce 2 DNT                 Fine
Union/Level 16                    Stop
Vodka Demo/Kill that Beast        Trash (bottom OK)

Those cases push me toward having both 412 and 416 as options.
"Theory" would also support 416 pixels, I will post this later as some revelation about the right border.
Though the question is still open.

[npomarede]

Due to the stabilizer after removing right border and the hi/lo switch used for this in most cases, you will get some altered pixels at the last part of the visible line during the time the switch is made at hi res. When going back to low res, the internal shifter's register will have rotated in hi res, so it will also alter pixels.

I don't have a crt monitor now connected to my 520 STF, but in the end, you get some kind of vertical zone of 16 pixels at the right on all overscan lines, with some pixels only displayed with 1 plane, and others completely black (can't remember exactly). That's why most demos often don't care about the last 16 pixels, because :
- you would not see them anyway on most CRT (except if you stretched the image or scroll it to the left with the CRT settings)
- the pixels are altered anyway by the hi/lo switch (or med/lo), so there's no real benefit in wasting cpu time to "paint" correctly this zone.

Of course, with "death of the left border" or any demo which doesn't use stabilizer, all pixels will be cleanly displayed.

That's why you should not make assumption on the fact that some demos draws the last 16 pixels or not to guess how many pixels were really cleanly displayed with or without a stabilizer.

Nicolas

[Steven Seagal]

But when Flix, Paolo or others say '416' they must mean useful pixels?
If the stabiliser messes up the last 16 pixels, do we have only 400 pixels?
Would a demo like Forest display better in emulators than on a real ST?
In that case 412 is more than enough, yet 416 is necessary for "plasmas".

[npomarede]

Not all 16 pixels will be trashed by the stabilizer, maybe 4 or 8 with different colors.
If you want to display all "plasma" screens correctly, you will need to display 416 pixels.

But in that case, you will get "problems" with demo that do overscan and expect the last pixels to be trashed by the stabilizer and draw less "real" pixels in the right border.

"forest" will maybe have internally 416 defined pixels because it's only a scrolling of a predefined buffer ; but the hi/lo stabilizer will alter them anyway on a real ST. So, yes, in that case an emulator will display more correct pixels that a real STF/STE would do.

The safest solution is certainly to display 412 pixels, 4 pixels are not a big difference as on a real ST they would not be always correctly displayed anyway.

Nicolas

[troed]

Sorry, I've been off doing other things for a while

As I wrote earlier the commonly used HI/LO stabiliser (444/456) actually modifies BLANK - see http://atari-forum.com/wiki/index.php?t ... disrupting

Alien has a comment on this:

At position 108, a secondary effect occurs: the Blank signal is activated 2us later on an STF, causing 16 pixels to be displayed further right that is usually possible.

Now, BLANK (front porch) is there for a reason. If the Shifter is raising data close to HSYNC that might cause distortion on some monitors - and so the recommendation is to not use those pixels for graphics (separate from whether they might be displayed in full).

Also, switching to HI always causes some black pixels (since the RGB pins are no longer active on the Shifter for the duration) - so even if you were to use the extra pixels they would appear after that black line anyway.

Note: I'm guessing a MED/LO stabiliser will look a lot better but I haven't researched it. It will likely shift bitplanes, but it shouldn't cause black pixels and it might not delay BLANK.

[Steven Seagal]

"forest" will maybe have internally 416 defined pixels because it's only a scrolling of a predefined buffer ; but the hi/lo stabilizer will alter them anyway on a real ST. So, yes, in that case an emulator will display more correct pixels that a real STF/STE would do.

I see it now, there's no way that 416 or 412 pixels of stabilised overscan are visible on an ST. I wonder how Flix etc. came by this value if it's wrong.

The safest solution is certainly to display 412 pixels, 4 pixels are not a big difference as on a real ST they would not be always correctly displayed anyway.

Nicolas

I think it's a nice compromise plasma/overscan. In Steem, it costs little to have both. I propose 4 sizes:
384 x 270 normal
400 x 278 max fullscreen
412 x 280 max overscan
416 x 286 max plasma

As I wrote earlier the commonly used HI/LO stabiliser (444/456) actually modifies BLANK - see http://atari-forum.com/wiki/index.php?t ... disrupting

Alien has a comment on this:

At position 108, a secondary effect occurs: the Blank signal is activated 2us later on an STF, causing 16 pixels to be displayed further right that is usually possible.

Is it supported by traces? This seems incompatible with the idea of a state-machine, where the test happens at cycle 452 if R<2, and if not, no HBLANK.

Now, BLANK (front porch) is there for a reason. If the Shifter is raising data close to HSYNC that might cause distortion on some monitors - and so the recommendation is to not use those pixels for graphics (separate from whether they might be displayed in full).

Also, switching to HI always causes some black pixels (since the RGB pins are no longer active on the Shifter for the duration) - so even if you were to use the extra pixels they would appear after that black line anyway.

Note: I'm guessing a MED/LO stabiliser will look a lot better but I haven't researched it. It will likely shift bitplanes, but it shouldn't cause black pixels and it might not delay BLANK.

The stabiliser effectively does like HBLANK for 12 cycles.
When the stabiliser stops, we're beyond the HBLANK position and beyond 416 pixels, maybe out of reach of monitors. If you see pixels after the stabiliser, maybe there was no HBLANK.

[troed]

As I wrote earlier the commonly used HI/LO stabiliser (444/456) actually modifies BLANK - see http://atari-forum.com/wiki/index.php?t ... disrupting

Alien has a comment on this:

At position 108, a secondary effect occurs: the Blank signal is activated 2us later on an STF, causing 16 pixels to be displayed further right that is usually possible.

Is it supported by traces? This seems incompatible with the idea of a state-machine, where the test happens at cycle 452 if R<2, and if not, no HBLANK.

The stabiliser effectively does like HBLANK for 12 cycles.
When the stabiliser stops, we're beyond the HBLANK position and beyond 416 pixels, maybe out of reach of monitors. If you see pixels after the stabiliser, maybe there was no HBLANK.

The HI/LO stabiliser is at 444/456. The state machine in that region does the following:

Code: Select all

450	IF(RES == LO) BLANK = TRUE
462	IF(RES == LO) HSYNC = TRUE && H = FALSE

So HSYNC isn't affected by the switch, but BLANK is. I'm assuming BLANK is simply delayed until start of HSYNC (which fits with Alien's observation since BLANK normally would stop the Shifter from putting out graphics). I wonder if Alien really measured that it was 16 extra pixels though - I would've assumed 8 (start of HSYNC minus end of stabiliser - note wakestate when calculating).

The reason (as I've understood it) for BLANK to surround HSYNC is to make sure the monitor picks up the analog sync signal cleanly. Without BLANK ("front and back porch" depending on which side of HSYNC we're talking about) it's possible that the monitor would become confused if pixels (i.e, signal) is close to where the HSYNC signal appears.

DHS' investigation into useable line lengths might be relevant: http://dhs.nu/misc.php?t=special&feature=overscan

It would be interesting to add the calculation of these lengths to the wiki, but I think I'm missing something. My naïve version below doesn't add up completely yet:

Fullscreen lines are affected by the following states:

Code: Select all

4	IF(RES == HI) H = TRUE
450	IF(RES == LO) BLANK = TRUE
462	IF(RES == LO) HSYNC = TRUE && H = FALSE

From starting the line at cycle 4 by going to HI res we then get DE at 8, detected by MMU at 12 which then needs 16+2 cycles for Shifter to LOAD so pixels should start appearing at cycle 30. For an unstabilised line they will then continue to render until we hit BLANK at cycle 450 (which if delayed by anything would be on the order of 2 cycles or so). 450-30 = 420 so I guess we're getting close to the theoretical maximum for a non-stabilised line although the calculation seems 4 cycles off (it should be 416).

A stabilised line would render between 30 up until 444 where we switch to HI (again causing black output since the RGB pins aren't used), that's 444-30 = 414 pixels. However, since BLANK has now been delayed the switch back to LO at 456 has a few more cycles before HSYNC where pixels might be visible - but this is after the 12 pixels of black just before and the bitplanes will also have been shifted around.

So, it seems this is (or should be) following logically from the state machine and be calculable just like the line lengths in bytes used. Any ideas on where I'm 4 pixels long anyone? It would be worth the effort to put this info on the wiki as well.

/Troed

(Btw, are emulators currently outputting black as soon as HI res is set for the duration until switched back? There's a difference in how it's handled on ST and STE but at least for ST that's the simple case)

[npomarede]

(Btw, are emulators currently outputting black as soon as HI res is set for the duration until switched back? There's a difference in how it's handled on ST and STE but at least for ST that's the simple case)

No they don't, neither for left border, nor for right one ; I'm planning to had this in Hatari at some point, but that's not really required so far, users certainly prefer seeing the whole unaltered line (some users are not aware of this effect on real STF or never noticed it because their CRT settings didn't display that much of the right border).

[Steven Seagal]

DHS' investigation into useable line lengths might be relevant: http://dhs.nu/misc.php?t=special&feature=overscan


/Troed

Interesting link, I didn't know. They're more realistic about available pixels.
Their limit is when the stabiliser hits (my little Excel table indicates that at cycle 444, 408 pixels have been rendered).
Notice the only screenshot with trashed pixels uses the ULM stabiliser, this is MED RES rendering. The HI/LO stabiliser is cleaner.

(Btw, are emulators currently outputting black as soon as HI res is set for the duration until switched back? There's a difference in how it's handled on ST and STE but at least for ST that's the simple case)

No, and in Steem it could be hard/slow until we change the assembly routines.
It may be a plus of emulators: checking demos like DSOS in 416x286 without any trash.


I promised some revelation, but the fact that HBLANK determines visible pixels isn't a great one now, so here's a new hypothesis: the #pixels should depend on wake-up, between 412 and 415 (or 413-416).
We observe 412/413 pixels in DOLB because Dio's DL is 6 (WU1). The display starts later, but it ends at the same cycle (whether because of HBLANK or the stabiliser) whatever the DL. This seems incontestable.
For plasma it would always be 416.

[npomarede]

Interesting link, I didn't know. They're more realistic about available pixels.
Their limit is when the stabiliser hits (my little Excel table indicates that at cycle 444, 408 pixels have been rendered).
Notice the only screenshot with trashed pixels uses the ULM stabiliser, this is MED RES rendering. The HI/LO stabiliser is cleaner.

That's just a particular case of this demo, because ULM put pixels on the whole line, even on parts that will be trashed. The 2 other examples just put black pixels at the end of the line, so they're altered too, but you can't tell the difference between black lo/med pixels and black hi res pixel because rgb is turned off.
Any screen using the hi/lo stabilizer will alter the last pixels, you can just choose to not use that part of the line to avoid showing garbages on a real ST.

[ljbk]

Hi !

My hint on this is that:
- with hi-lo stabilizer 413 pixels will be displayed correctly (-52 + 361(pixel equivalent time of 71 Hz update));
- with ULM stabilizer, as the change to medium resolution is done 4 cycles earlier, only 409 pixels will be displayed correctly;

I can confirm for sure that with the ULM stabilizer i could see always the trashed part on my old TV i used during the 90s.
With the high low case i could only see the black part (related to the switch to 71 Hz) with the darkest pictures because the screen tends to become smaller on a CRT on that case. With bright pictures, slightly wider on a CRT, i could not see the black part.

Paulo.

[Steven Seagal]

Any screen using the hi/lo stabilizer will alter the last pixels, you can just choose to not use that part of the line to avoid showing garbages on a real ST.

Yes now I can see on the screenshots that there's enough room for "post-stabiliser".
Shifted pixels could show until HSYNC, normally 8, and somehow HBLANK would trigger at the same time as HSYNC or there would be horrible traces on the screen.
But those pixels are beyond HBLANK position, beyond 416.

Hi !

My hint on this is that:
- with hi-lo stabilizer 413 pixels will be displayed correctly (-52 + 361(pixel equivalent time of 71 Hz update));
- with ULM stabilizer, as the change to medium resolution is done 4 cycles earlier, only 409 pixels will be displayed correctly;

I think you must substract 4 from those values for the 4 pixels lost by 'left off'. Left border in overscan is 48 instead of 52 cycles.

I can confirm for sure that with the ULM stabilizer i could see always the trashed part on my old TV i used during the 90s.
With the high low case i could only see the black part (related to the switch to 71 Hz) with the darkest pictures because the screen tends to become smaller on a CRT on that case. With bright pictures, slightly wider on a CRT, i could not see the black part.

Paulo.

The ULM one starts earlier and messes pixels at once, messed pixels are further with a HI/LO stabiliser.
The screen getting smaller with the darkest pictures: we should emulate that! Maybe SainT will do it.

[ljbk]

Hi !

My hint on this is that:
- with hi-lo stabilizer 413 pixels will be displayed correctly (-52 + 361(pixel equivalent time of 71 Hz update));
- with ULM stabilizer, as the change to medium resolution is done 4 cycles earlier, only 409 pixels will be displayed correctly;

I think you must substract 4 from those values for the 4 pixels lost by 'left off'. Left border in overscan is 48 instead of 52 cycles.

The values i indicated (-52 and +361) already consider that the "normal" part of the screen starts at pixel -4 (4 pixels to the left) for a fullscreen line so i maintain that 413 pixels should be displayed in that case.
361 corresponds to emulator cycle: 361 + 83 = 444 where the resolution register will be set to 2.
As for ULM case, the switch is done 4 cycles earlier, the messing has to start at least 4 pixels earlier so a maximum of 409 pixels are displayed correctly.
Beware that in case of a plasma screen changing only logical color 0, the ULM stabilizer will not mess up anything because either in low resolution or in medium resolution the displayed color for a null bitmap will always be the logical color 0. So in that really special case, as in a normal "border" screen, 416 or more "pixels" are displayed correctly by the ST.

Paulo.

[troed]

The values i indicated (-52 and +361) already consider that the "normal" part of the screen starts at pixel -4 (4 pixels to the left) for a fullscreen line so i maintain that 413 pixels should be displayed in that case.
361 corresponds to emulator cycle: 361 + 83 = 444 where the resolution register will be set to 2.
As for ULM case, the switch is done 4 cycles earlier, the messing has to start at least 4 pixels earlier so a maximum of 409 pixels are displayed correctly.
Beware that in case of a plasma screen changing only logical color 0, the ULM stabilizer will not mess up anything because either in low resolution or in medium resolution the displayed color for a null bitmap will always be the logical color 0. So in that really special case, as in a normal "border" screen, 416 or more "pixels" are displayed correctly by the ST.

Which wakestate are your numbers from? They're very close to the naïve calculation I did from the current state machine, where I calculated with WS1 and got 414 for the HI/LO case. I did not however correct for the extra word left in Shifter taking us to -4 starting position so my numbers should've been 26/444 instead of 30/444 and are still ~4 pixels off for some reason.

here's a new hypothesis: the #pixels should depend on wake-up, between 412 and 415 (or 413-416).
We observe 412/413 pixels in DOLB because Dio's DL is 6 (WU1). The display starts later, but it ends at the same cycle (whether because of HBLANK or the stabiliser) whatever the DL. This seems incontestable.

Yes I agree - it follows from the same logic that causes the pixel-offset seen by Dio (delta between HSYNC and actual pixels). edit: For the BLANK-case. The stabiliser is CPU-synced so that wouldn't be wakestate-dependent.