horizontal scrolling on ST

[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.

[Steven Seagal]

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.

I figured DL changes when display starts, but it always ends at same cycle, whether by HBLANK or stabiliser.
So when it starts later (WS1), fewer pixels are displayed.

[troed]

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.

I figured DL changes when display starts, but it always ends at same cycle, whether by HBLANK or stabiliser.
So when it starts later (WS1), fewer pixels are displayed.

Maybe. The involved parties are:

GLUE - raises DE
GLUE - generates HSYNC and at the same time deactivates DE
GLUE - raises BLANK

MMU - receives DE from GLUE, raises LOAD

Shifter - receives LOAD from MMU
Shifter - receives DE from GLUE
Shifter - receives BLANK from GLUE
Shifter - switched to HI resolution by CPU

GLUE can be offset 0-3 cycles from CPU/MMU. Shifter runs fast and for this purpose we assume that means it isn't offset.

Screen starts when DE is raised, monitors calibrate against HSYNC. Even though DE is received by both MMU and Shifter it's MMU that decides LOAD and thus there isn't anything for Shifter to output until that has happened. This is where DE-to-LOAD happens and we get the screen pixel offset.

Screen ends at either of the following:

1. GLUE lowers DE (right border or HSYNC) where Shifter stops loading new data and outputs what it has
2. GLUE raises BLANK which immediately cancels any Shifter output
3. when Shifter is switched to HI resolution which also cancels Shifter RGB output.

In the first case, a normal amount of pixels is shown due to the finished data output by Shifter even though the line might be 0-3 pixels offset from HSYNC depending on wakestate.

In the second case, the line might be "cut off" 0-3 pixels since BLANK is GLUE-synced (as HSYNC) compared to line start which is governed by the MMU.

In the third case, the CPU (same cycle synchronisation as MMU) sets the value of the resolution register which is picked up by both GLUE (irrelevant in this case) as well as Shifter (which stops outputting RGB pixels).

So, without having tested it it seems to me the stabiliser case is synchronised to CPU/MMU cycles at both line start and end, compared to BLANK which is synchronised at line start but not line end. I'm very much open to alternative interpretations though

/Troed

[Steven Seagal]

@Troed

It makes sense. I had DOLB in mind, but it's not stabilised. For stabiliser, #pixels wouldn't depend on WS, they would just all be shifted together, if I get it right. The exact number is still to be determined. For DOLB or Omega, it would depend on WS. For plasmas, we would have 416.

[troed]

Q: What causes "banded" display? (Every other 16 pixels black)

There are several reasons for my interest in this. One is that IIRC that was what Omega's full screen and DOTLB looked like - mostly - on my old STF. Another is that when I made thousands of reboots to create the synctables for LoSTE, working in both cold and warm modes, the intermediate "warming" state was always banded. A third is how Paulo had to include a hotkey to swap between two different unstabilisers in his 4 pix scroll demos due to banded modes.

So, there's good reason to want to understand why it happens I think

I believe the interested parties to be the MMU and the Shifter. Recall it's the MMU that raises LOAD which causes Shifter to read data off the selected memory address.

The four following signals are sent towards the GST Shifter to synchronize it with the data transfer of the video RAM as well as the signals VSYNC and HSYNC which were generated by the GLUE in the STF. *DCYC (Data CYCIe) indicates to Shifter that the data are available from the RAMs (i.e. the GST MCU has just selected the RAM address of the next data to be loaded in the GST Shifter; this addressing is carried out 16000 times per image in connection with the VCOUNT counters of GST MCU (or of the MMU in a STF)

http://info-coach.fr/atari/hardware/STE-HW.php

The Shifter then loads up four words before transferring them to the "rotating registers" which will shift a group of 4 bits each cycle to the RGB output via palette lookup. Alien's description is good:

Code: Select all

Number_of_read_bitplanes = 0
REPEAT
 IF Load is active THEN IR[Number_of_read_bitplanes] = Data sent from MMU
                        Number_of_read_bitplanes = Number_of_read_bitplanes + 1
 IF Number_of_read_bitplanes == 4 AND IF DE is active
    THEN RR1 = IR1; RR2 = IR2; RR3 = IR3; RR4 = IR4
 IF Number_of_read_bitplanes == 4 THEN Number_of_read_bitplanes = 0
END_REPEAT

http://alive.atari.org/alive11/oscan2b.php

So, based in this we can start guessing what must happen to get a "banded" screen: Each and every line must fail at reading every second group of bitplane words from the MMU - or every second group of Shifter IR registers must fail being copied to the corresponding RR. It's a persistent state when it happens and continues until cancelled by some new disruption.

We also know it can be forced by sync switches, can be caused by "warming" and is also persistent per cold boot in some situations Sounds easy enough to track down.

1) It's likely not the MMU forgetting to select the right memory address. The next column is in its correct place.
2) It could be bus contention - Shifter is unable to read the memory (32MHz 4*16 bits = 16 CPU cycles) and so IR will be empty when copied into RR.
3) Bug in the Shifter (Alien's code is pseudo) and the reset after 4 bitplanes fails every second time - thus IR doesn't get copied into RR. But why?
4) The Shifter goes on a rampage and every other line believes it's in HI res*.

For the second case I'd pose the possibility that the Shifter (32MHz) and MMU (16Mhz) could be offset in a way making this happen - and that the offset can change with warming. I'm not the best at understanding that here though - Dio can probably weigh in.

So, thoughts anyone?

/Troed

*) In my old 1989 setup, common in SYNC, we ran an SM124 off the monitor port and a TV through RF. It allowed us to code in hi res and when the demo started it would automagically switch to the color screen (and back, when exiting). I have a very very very faint memory of how I could see sync effects on the mono monitor as short white lines when HI/LO switches were made. Such a setup should spot #4 - although I consider ut unlikely.

[Dio]

It's not just the shift register becoming empty due to a failed transfer from the staging regs - it wouldn't give black, you'd see the border colour.

I think the most likely possibilities are:
- flipping to and from Mono mode for some reason
- Glue flipping BLANK on and off
- Problem reading the palette register inside Shifter
- The RGB output inhibitor kicking in without activating Mono
- Possible colour output latches not latching inside Shifter.

The first two would be visible on the Shifter bus signals. If it's not either of those, it's some failure inside the Shifter. Knowing what the problem is won't help with the cause except to narrow down what unit it's in, but maybe something would be visible from the timing.

I'm utterly snowed under with work at the moment though, will be some weeks or months before I have time to get back to this I'm afraid.

[troed]

It's not just the shift register becoming empty due to a failed transfer from the staging regs - it wouldn't give black, you'd see the border colour.

Ah, sorry about that and thanks for jogging my memory As can be seen in the Omega fullscreen - http://ataristeven.t15.org/Steem_demos2 ... can_(STF2) - it's indeed the border colour that gets displayed every other 16 pixels where the graphics is missing. That means we can just invert the theories and exclude;

- flipping to and from Mono mode for some reason
- Glue flipping BLANK on and off
- Problem reading the palette register inside Shifter
- The RGB output inhibitor kicking in without activating Mono
- Possible colour output latches not latching inside Shifter.

... and we're left with (non-exhaustive):

1) Shifter unable to access memory for a complete IR-renewal period (16 cycles). The IR registers will thus be empty at the next copy to RR.
2) Failure when copying IR to RR
3) Bug in the Shifter code where in addition to the mono, medium and low res behaviour of the RR registers an "undefined" state can be selected where it shifts the RR-registers for twice as long as it should.

I'm utterly snowed under with work at the moment though, will be some weeks or months before I have time to get back to this I'm afraid.

No worries - I just find it to be a very interesting bug since it's so "stable". It can be caused at not only the start of a line and stay the same throughout (I've never seen it start or stop in the middle of a line) - it can also be caused at the top of the screen and stay for all subsequent lines (non-fullscreen). I also _think_ it doesn't exist on STE, and that it doesn't survive for more than a single line in STF WS1 (but I'm basing that on incomplete notes) - so even if this is a Shifter state unrelated to the known GLUE wakestates it's possible that the speculated "Shifter reset" happening when there's no GLUE-CPU/MMU offset is able to clear it as well.

At least option #1 above might be possible to see when looking at memory access traces.

[Steven Seagal]

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.

You should know.
Attentively looking at the screenshot of Level 16 (http://dhs.nu/specialfeature/overscan/o ... _union.png),
it seems to me it's wrong not to display the first 4 pixels in emulation (we start displaying at "0", not "-4").
In a test build of Steem (it's a mess right now!) I get a closer left border with those extra pixels shown.
There's still a shift of 4 pixels, but we would have 52 (26x2), not 48 pixels in the left border as I thought.
That way all your demos (Forest, Overscan) show better in emulation.

[npomarede]

Hello

It's the same problem as with the stabilizer at the end of the line : the hi/lo switch to open the left border will alter the 1st pixels of the line and those pixels will be altered during the time RGB is switched off.
Some demos with "static" image like level 16 will most of the time use the full line width to put pixels when the image was drawn under neochrome, degas elite or whatever ; but once the image is displayed with the hi/lo switch on each line, the pixels will be altered.

In some case, if you display these pixels you will get the feeling everything was not completely displayed before as you suggest ; but in other cases, where the demo coder is really short on cpu cycles, he might choose to not "compute" these leftmost pixels at all, sometimes putting black pixels instead, but sometimes leaving whatever buffer's content was previously there (because the coder knew this part would be altered and not visible anyway). If you display a larger left border in this case, you will see some bad pixels, which might give a worse result than today.

Nicolas

[Steven Seagal]

My theory is that the "RGB off" of the R2/R0 switch isn't visible because of shifter latency. The pixels fetched when DE starts will be displayed only 28 cycles later, so all are visible. Maybe there's some further distortion on a CRT screen, I don't know.
What counts here is what you see with your eyes. Paolo's pixel figures come from what he saw, and up to now they proved faithful.

The screenshot I posted is from real ST.
Now here's one from Steem with all pixels:

level16_354.png

It seems pretty close for the left border.

[Steven Seagal]

Here's another screenshot, where we display 412 pixels instead of 416:

level16_354_412.png

It's closer still to the original but we miss one pixel on the right now. Argh!