horizontal scrolling on ST

[ljbk]

Here is beeshft2 (only the program) that uses the LO/HI/LO unstabilizer. This will not work correctly in the normal case of WS2 (that is much more frequent) and also probably not for WS4.


Paulo.

And also not in Steem
It's easy to recognise the switch like the MED/LO one, but the shifts look different, or maybe it's another effect from the vertical scroller that works only in some state.

That statement from me was what i thought would happen but as you can read from my last posts this is not what happens.

For emulator purposes the best way should be the following:
- 0 shift case => works always;
- 4 pixel shift => works as 0 for WS1 and works correctly for WS2/3/4;
- 8 pixel shift => works always;
- 12 pixel shift => works always;
Now you already know how the LO/MED/LO unstabilizer works;
LO/HI/LO works in the same way except -4 and -12 code cases are switched;

Of course you can say that there are cases, as i described (warming, bands ...), where the real HW will not work with one or maybe both unstabilizers due to special Shifter conditions undetectable to the SW but this also happens with normal fullscreen lines if the return to low resolution for left border is not done at cycle 12 or if no stabilizer is used ...

Paulo.

[Steven Seagal]

Steem does not show the grey pixels: last 16 pixels of 2nd line (screen address + 318(decimal) = FFFF).
If you have a real ST close to you this is easy to see.

Paulo.

Yes, it's because the program writes on this address when on a real ST it has just been shifted, but in Steem it hasn't been rendered yet, so when Steem renders it sees $0000, not $FFFF.
It is a case like 36.15 Gen4 by ULM. This one displays OK in Steem since v3.4 because rendering is triggered for this particular instruction/addressing mode. There's a check in MOVE.W <EA>,(d16, An), and only there (targeted).
In your program, the same happens in MOVE.W <EA>,(An).
In a test build I put the same check there and we see your grey pixels.

[npomarede]

Steem does not show the grey pixels: last 16 pixels of 2nd line (screen address + 318(decimal) = FFFF).
If you have a real ST close to you this is easy to see.

Paulo.

Yes, it's because the program writes on this address when on a real ST it has just been shifted, but in Steem it hasn't been rendered yet, so when Steem renders it sees $0000, not $FFFF.
It is a case like 36.15 Gen4 by ULM. This one displays OK in Steem since v3.4 because rendering is triggered for this particular instruction/addressing mode. There's a check in MOVE.W <EA>,(d16, An), and only there (targeted).
In your program, the same happens in MOVE.W <EA>,(An).
In a test build I put the same check there and we see your grey pixels.

Same reason in Hatari, lines are rendered in one go at the end of each HBL. So, in this case it will use the latest 160 bytes currently in RAM at the end of HBL, without no history of a possible change of these 160 bytes during the current HBL.
Many demos often draw on the same screen at the same time it is displayed, but as long the content of the screen is not updated on the same HBL it's supposed to be displayed, it won't give any problem.
This is required for performance reason ; else it would require to either check if any write is in an interval corresponding to the current HBL data, or render each line every 4 cycles for example, which would kill performances and make emulation really sloowww (but for example, WinUAE has an optionnal "cycle exact" mode that "refreshes" each HW component every 4 cycles, as would do a real machine where the BUS would be shared between cpu, gfx, dma, ...) (updating every component each 4 cycles is also much more complex as it requires a really accurate emulation of each part, down to the cycle level).
The method consisting of forcing an intermediate video rendering when a write is detected in the correct RAM interval is certainly much easier, I might add it to Hatari some day.


Nicolas

[ljbk]

@Steven Seagal and Nicolas

Hi !

This rendering issue is not very important to me. I was testing the last possible update cycle against hipotetical MMU reading cycles and i recognized the error in the emulators. That's it.
Now in the case of Hatari, there is an additional border color changing error.
The color goes from $777 to $357 at pixel 333 (13 pixels after the normal end of the bitmap) on the 2nd line.
That occurs correctly with Steem but not with Hatari.
Can it be from the movep from $FFFF8201 ?

Code: Select all

* cycles use my scale (add 83 to emulators :) )

	bsr	lsync160	389
	lea	$8201.w,a3	397
	moveq	#0,d6		401
	movep	0(a3),d6	-95
	lsl.l	#8,d6		-71
	move.l	d6,a3		-67
	moveq	#-1,d6		-63
	move.b	d2,(a5)		-55
	move.b	d2,(a5)		-47
	moveq	#0,d5		-43
	lea	318(a3),a3	-35
	move	d6,(a3)		-27

	move.l	(a0),(a0)	-07
	move.l	(a0),(a0)	013
	move.l	(a0),(a0)	033
	move.l	(a0),(a0)	053
	move.l	(a0),(a0)	073

	move.l	(a0),(a0)	093
	move.l	(a0),(a0)	113
	move.l	(a0),(a0)	133
	move.l	(a0),(a0)	153
	move.l	(a0),(a0)	173

	move.l	(a0),(a0)	193
	move.l	(a0),(a0)	213
	move.l	(a0),(a0)	233
	move.l	(a0),(a0)	253
	move.l	(a0),(a0)	273

	nop			277
	nop			281
	nop			285
	nop			289
	nop			293	remove this not to have effect
	move	d5,(a3)		301

*					last update in video mem @ 297
*					@ 301, the update has no effect
	nop
	nop
	nop
	nop

	move	#$357,$8240.w

The $FFFF (grey pixels) is set at cycle -27+83 = 56.
The $0000 (back to white pixels) is set at cycle 301 + 83 = 384 thus having no impact in the Shifter rendering so we get the grey pixels. If it would be done at cycle 380, the pixels would appear white.
The $FFFF8240 change to $357 occurs at cycle 301+32+83 = 416 and is effective at pixel 333 (13 pixels inside the right border). This is what is not occuring with Hatari.


Paulo.

[ljbk]

Hi !

To conclude these bee shifting tests, i upload here a zip that contains:

- TOSHIFT.PRG: the original program that returns to a shifted TOS using LO/MED/LO unstabilizer;
- BEEMOVE0.PRG: allows you to move the bee around the 4 shifting positions using LO/MED/LO unstabilizer;
- BEESHFT1.PRG: bee shifting + sync scroll using LO/MED/LO unstabilizer;
- BEESHFT2.PRG: bee shifting + sync scroll using LO/HI/LO unstabilizer;
- BEESHFT3.PRG: bee shifting + sync scroll using one of unstabilizers (ESCAPE switches);
All BEE programs show the correct WS (1, 2, 3, 4).
There are sub wake up states or Shifter states that are undetectable by the SW but that have consequences for the rendering. One of them can be detected with ease as the LO/MED/LO unstabilizer use will result mainly in vertical 16 pixel bands followed by 16 pixels of border color and the LO/HI/LO unstabilizer will work correctly.
There are others like a cold or warm Shifter (remember this chip works at 32 MHz with 1980s technology and no cooler) and the Spectrum 512 funny dots for example.
If you see artifacts in a normal fullscreen picture like some lines with the vertical bands problems (16 bitmap pixels followed by 16 border pixels), then this is an indicator that your chip is not stable and this feature will certainly not work correctly as not even the stabilizer used in the fullscreen display is working correctly. These kind of effects (for fullscreen) tend disappear quite fast with the machine getting warmer (in my case, this morning, in WS2, less than 15 minutes).
In any case, the 4 bit shifting will not work correctly for WS1 as the -4 shift can not be reached unlike 0, -8 and -12 shifts.
For all other WS, with a stable Shifter, it should work with one or both unstabilizers (try the ESCAPE key in BEESHFT3). Switching between the unstabilizers costs around 200 cycles.


Paulo.

[ljbk]

@Steven Seagal

Hi !

Have you noticed that STeem 3.5.1 and 3.5.1 Boiler builds have different behaviours with the new wake up state detection mechanism ?
SSE wake up 2 (or ignore wake up) will lead to WS4 with the Boiler version but will lead to 0 (unknown) for the 3.5.1 "no-Boiler" build.

Paulo.

[npomarede]

The $FFFF (grey pixels) is set at cycle -27+83 = 56.
The $0000 (back to white pixels) is set at cycle 301 + 83 = 384 thus having no impact in the Shifter rendering so we get the grey pixels. If it would be done at cycle 380, the pixels would appear white.
The $FFFF8240 change to $357 occurs at cycle 301+32+83 = 416 and is effective at pixel 333 (13 pixels inside the right border). This is what is not occuring with Hatari.
Paulo.

Hello
this is what I get in Hatari 1.7 ; change seems to be occurring at the correct place.

grab0001.png

Can you check in your hatari.cfg, section [screen] that you have "nSpec512Threshold = 1" ?

Nicolas

[Steven Seagal]

LO/HI/LO works in the same way except -4 and -12 code cases are switched;

Of course you can say that there are cases, as i described (warming, bands ...), where the real HW will not work with one or maybe both unstabilizers due to special Shifter conditions undetectable to the SW but this also happens with normal fullscreen lines if the return to low resolution for left border is not done at cycle 12 or if no stabilizer is used ...

Paulo.

Thx. I must say, although by switching those values it does work, I don't quite understand why. But fine, let's just be practical.

[Steven Seagal]

@Steven Seagal

Hi !

Have you noticed that STeem 3.5.1 and 3.5.1 Boiler builds have different behaviours with the new wake up state detection mechanism ?
SSE wake up 2 (or ignore wake up) will lead to WS4 with the Boiler version but will lead to 0 (unknown) for the 3.5.1 "no-Boiler" build.

Paulo.

Yes I noticed it not long ago. It's probably because I disabled the 71/50 "right off" test, but due to some #define not in the debug build.
With the current development versions, WU 1 and 2 are recognised and 'ignore' returns (4).
We don't emulate yet WU1 being trouble as is apparently the case.
But we emulate something that you'll appreciate...

[ljbk]

Hello
this is what I get in Hatari 1.7 ; change seems to be occurring at the correct place.

grab0001.png

Can you check in your hatari.cfg, section [screen] that you have "nSpec512Threshold = 1" ?

Nicolas

Hi !

Well, i get this:

grab0001.png

I checked both Atari screen and Hatari screen under the F12 menu and i could not see the option you refer.
Anyway, if i can not see it this means i have the default value since Hatari 1.7 installation.

Paulo.

[ljbk]

LO/HI/LO works in the same way except -4 and -12 code cases are switched;

Of course you can say that there are cases, as i described (warming, bands ...), where the real HW will not work with one or maybe both unstabilizers due to special Shifter conditions undetectable to the SW but this also happens with normal fullscreen lines if the return to low resolution for left border is not done at cycle 12 or if no stabilizer is used ...

Paulo.

Thx. I must say, although by switching those values it does work, I don't quite understand why. But fine, let's just be practical.

Hi !

The reason is the way the Shifter works.
The distance between the HW changes does not cause the same effects with a LO/HI/LO switch and a LO/MED/LO switch for 2 of the 4 cases. The the two others it works the same way.

Paulo.

[ljbk]

Hi !

Time to scroll now ...
This example is the default use of this 4 bit sync scrolling: scrolling speed is 4 pixels, the shifted screen parts are hidden to the viewer and the ESCAPE key toggles the unstabilizer.
Only about 100 KB of memory are used (and 32KB are wasted with the original Degas image).
Hiding the shifted parts, feeding the side data, the 6 control lines and other controls cost a maximum of 17% CPU. But it can be nearly half of that as it depends on what you have to do.

Still this is possible with classic sync scrolling on 512KB STF but it will cost much more memory but less CPU.
Now a 1 pixel version of this using classic sync scrolling on a 512KB STF is impossible.
Let's see if i can do it .

Enjoy,
Paulo.

Edit:
File replaced due to minor bug ...

[npomarede]

I checked both Atari screen and Hatari screen under the F12 menu and i could not see the option you refer.
Anyway, if i can not see it this means i have the default value since Hatari 1.7 installation.
Paulo.

Default value is 16, it means line won't be updated immediatly with precise color positions until we have 16 changes in the color regs during the same HBL.
It's useful for slow machines, as it will avoid rendering lines too soon by deferring the changes to the next HBL (the assumption is that if a palette is changed during the line, it's likely to be only random changes, unless a "high" number of color are changed and we need to go to "plasma" mode).
For some calibration programs I wrote, I have the same problem, I need to display the change immediatly, even if there's only one change per line.
You can set nSpec512Threshold=1 in hatari.cfg, it's a more advanced parameter, so there's no UI to set it yet. It doesn't seem to impact performance that much, so maybe default value should be changed.

Nicolas

[ljbk]

You can set nSpec512Threshold=1 in hatari.cfg, it's a more advanced parameter, so there's no UI to set it yet. It doesn't seem to impact performance that much, so maybe default value should be changed.

Nicolas

Hi !

I confirm that doing that change the display result is correct.

Thanks,
Paulo.

Edit:
As you might noticed the beescrl4 has a little bug at the bottom of screen.
Well, i have not seen that at first because i have to use NTSC3.58 color system to work with my 40 inch LCD. And in that case i do not see the last 7/8 lines of a normal 200 lines screen.
Using with PAL will lead to an unstable picture from time to time. As you know the ST video signal does not respect strictly the PAL system.
So when i ran the program under Steem and i saw some little things at the bottom i rechecked in PAL with the real ST and i could see the small bug.
Anyway, this is probably some small stuff and the program as it is gives a very good idea of what can be achieved.
Of course i wil try to kill that beast !

Edit2:
Bug solved and zip replaced on the other post.

[npomarede]

Hi !

Time to scroll now ...
This example is the default use of this 4 bit sync scrolling: scrolling speed is 4 pixels, the shifted screen parts are hidden to the viewer and the ESCAPE key toggles the unstabilizer.
Only about 100 KB of memory are used (and 32KB are wasted with the original Degas image).
Hiding the shifted parts, feeding the side data, the 6 control lines and other controls cost a maximum of 17% CPU. But it can be nearly half of that as it depends on what you have to do.

Still this is possible with classic sync scrolling on 512KB STF but it will cost much more memory but less CPU.
Now a 1 pixel version of this using classic sync scrolling on a 512KB STF is impossible.
Let's see if i can do it .

Enjoy,
Paulo.

Edit:
File replaced due to minor bug ...

Hello
I'm testing it on my STF.
About the minor bug, is it that last line was not correctly masked on left/right part ?

In WS2 normal with no bands : I need to press 'esc' (that's not expected), but I get 2 after unstable cases during the whole scrolling :
- 1 with shifted plans (I press 'esc' than 101 times 'alt')
- 1stable image, but with odd/even lines shifted by one pixels ; I can't say what scroll it's supposed to be, but lines have an extra pixels shifting that add 0,1,0,1,0,1 ... pixels on each line (I press 'esc' than 46 times 'alt')
I don't see why I need to press 'esc' in that case, because if I run beemove0, it's stable for all 4 scroll positions ?
If I don't press 'esc', I get bands, as if the unstabilizer was the opposite of the one in beemove0.

If I run beeshft1, it's also stable (no bands), like beemove0, but I noticed sthg I never saw before : when using alt to step into scrolling positions, some positions are sometimes not stable : the image is shifting completely with what seems to be an extra pixel (but all lines are shifted, not just the odd or even ones as in beescrl4 above). Sometimes, the image seems to oscillate like this for less than a sec, and then if finally gets stable.
Have you ever seen this effect ? (for one of the vertical position in beesfht1, the oscillation lasted for 5 sec, but finally it went stable)

Now, after a reboot, my STF is in WS2 with bands :
- beemove0 and beesfth1 are not stable, we have the 16 pixels bands
- beeshft2 is stable, there's not even the 1 pixel oscillation in the other WS2 state above.
- beescrl4 is stable too for all positions, the 2 problems above at alt nbr 46 and alt nbr 101 are not visible anymore.

Note that I think I made my tests with the first version you uploaded, I don't know if that matters ?

Nicolas

[ljbk]

Hello
I'm testing it on my STF.
About the minor bug, is it that last line was not correctly masked on left/right part ?

Yes , this was the problem.
There is still another smaller one i only recognized while doing the 1 pixel scroll.

In WS2 normal with no bands : I need to press 'esc' (that's not expected), but I get 2 after unstable cases during the whole scrolling :
- 1 with shifted plans (I press 'esc' than 101 times 'alt')
- 1stable image, but with odd/even lines shifted by one pixels ; I can't say what scroll it's supposed to be, but lines have an extra pixels shifting that add 0,1,0,1,0,1 ... pixels on each line (I press 'esc' than 46 times 'alt')
I don't see why I need to press 'esc' in that case, because if I run beemove0, it's stable for all 4 scroll positions ?
If I don't press 'esc', I get bands, as if the unstabilizer was the opposite of the one in beemove0.

If I run beeshft1, it's also stable (no bands), like beemove0, but I noticed sthg I never saw before : when using alt to step into scrolling positions, some positions are sometimes not stable : the image is shifting completely with what seems to be an extra pixel (but all lines are shifted, not just the odd or even ones as in beescrl4 above). Sometimes, the image seems to oscillate like this for less than a sec, and then if finally gets stable.
Have you ever seen this effect ? (for one of the vertical position in beesfht1, the oscillation lasted for 5 sec, but finally it went stable)

These are effects of a "cold" Shifter.
The classic stabilizer used by the fullscreen lines does not work correctly then.
If you check a "normal" fullscreen display, you will see that, in that "cold" case, some lines (not always the same ones) will display bands and some others will not. With my machine, it can then have an effect to have a disquete in the drive or not.
The only solution is to wait that the Shifter warms and that "normal" fullscreen display starts working correctly or to cold reboot. This will happen no matter at what cycle you use to open the left border (508, 512 or 4).
I have to check if it improves to use the ULM LO/MED/LO stabilizer at cycles 440 and 456 in that case but i don't think it will.
After the warming time, normally less than 15 minutes with my machine, both ESCAPE unstabilizers will work.

Now, after a reboot, my STF is in WS2 with bands :
- beemove0 and beesfth1 are not stable, we have the 16 pixels bands
- beeshft2 is stable, there's not even the 1 pixel oscillation in the other WS2 state above.
- beescrl4 is stable too for all positions, the 2 problems above at alt nbr 46 and alt nbr 101 are not visible anymore.

Yes, the "band" Shifter states are much more stable and aparently imune to warming time.
I had that state for most of the day yesterday and nothing changed during the day.

Note that I think I made my tests with the first version you uploaded, I don't know if that matters ?

Nicolas

No, it is the same. The old bug was only data related.

Thanks,
Paulo.

[ljbk]

Hi !


@Nicolas

This morning when i powered on my STF i got exactly the WS2 "cold" situation you described.
I checked the fullscreen display and i had the problems i refered: somes lines, not all, showing bands and some others not. Taking the disquette out of the drive resulted in less lines with the problem.
Starting the left border on cycle 508, 512 or 4 did not change anything.
I tried to check as fast as i could the same fullscreen displays with the ULM stabilizer, and the image looked always good. I don't know if the machine had warmed up already or not so i will have to check again next time.
Running the 4 bit programs after that, around 12 minutes of power on, already showed a correct display except for some little cases if i took the disquette out of the drive so maybe the warming process was still not complete.
If the ULM stabilizer solves this then i will have no problem in changing the sync lines to include that or leave another on-the-fly update key to toggle the stabilizer.
I attach here a package of fullscreen viewers (based on my 1990 code so i hope it works on your machine), so you can also test this yourself:
- MIRA79.PRG (cycle 4 / normal stabilizer);
- MIRA83.PRG (cycle 512 / normal stabilizer);
- MIRA87.PRG (cycle 508 / normal stabilizer);
- MIRA79SM.PRG (cycle 4 / ULM stabilizer);
- MIRA83SM.PRG (cycle 512 / ULM stabilizer);
- MIRA87SM.PRG (cycle 508 / ULM stabilizer);


@All interested


Anyway, here is now a new scrolling package:
- BEESCRL4 scrolls 8 bees at 200 pixels per second;
- BEESCRL2 scrolls 8 bees at 100 pixels per second;
- BEESCRL1 scrolls 8 bees at 50 pixels per second;
- BEESCRLH scrolls 8 bees at 25 pixels per second (the typical shoot-them-up (R-Type like) rate);

- BEESCRL4 is the corrected version of yesterday;
- BEESCRLH/1/2 are derived from the same 1 pixel scrolling source;

- BEESCRL1 should be nearly impossible on a 512KB STF even with classic sync scrolling as only the 16 video buffers would take 501760 bytes (490 KB). So you have 22 KB left to store the code, the tables, ...
- BEESCRLH is possible on a normal STF without classic sync scrolling with the ROXL scrolling, but it would take 80% CPU while with this program you have more than 90% CPU free ...

All the 50fps programs (all except H version) leave more than 83% free CPU.
In case vertical scroll is also involved (multi directional scroll) and speeds of 2 or 1 are used, a bit more CPU is required to update all of the video buffers at each VBL when moving up ou down.
In case of multi-speed scrolling or odd speeds (like 3, 5, 7, ...) also more CPU is needed because it is necessary to update several video buffers at each movement.
But all this also happens for "classic" sync scrolling when possible.


Enjoy,
Paulo.

[bullis1]

Impressive

I really hope these techniques are adopted by other coders Paulo.

[troed]

This morning when i powered on my STF i got exactly the WS2 "cold" situation you described.

Solar influence? Cosmic rays? Because this morning my first overnight cold boot resulted in WS3 (as it always does) followed by WS2 after a short power cycle the minute after. The WS2 I reached had visible problems with synclin0 (which was on the default image in my HxC at the moment):

Line 162: Bitplane error
Line 186: Cycling through bitplanes per VBL
Line 230: "Skewed lines" (every other line shifted slightly)

Unfortunately while the mode was persistent for over an hour, verified several times, I had more important things to do (tending to my baby) and once I had managed to put your ULM stabilizer programs on an image and prepared to move it over to the HxC the issue had corrected itself (i.e, the Shifter had warmed up).

Next time I'll make sure to have the programs on an image already prepared. The whole point of the HxC is to always have everything available with the press of a button ...

[ljbk]

Line 162: Bitplane error
Line 186: Cycling through bitplanes per VBL
Line 230: "Skewed lines" (every other line shifted slightly)

Unfortunately while the mode was persistent for over an hour, verified several times, I had more important things to do (tending to my baby) and once I had managed to put your ULM stabilizer programs on an image and prepared to move it over to the HxC the issue had corrected itself (i.e, the Shifter had warmed up).

Hi !

Please don't forget that the program for Dio generates lines sizes without any stabilizer at his request.
So the results you might get will depend on the status the line before left the Shifter with.
Lines 54, 186 and 230 are the best to destabilize the Shifter.
If on the last frame they left X words in the Shifter buffers, these X words will be served as input for the next line type (the one you just pressed the corresponding key).

Here are some examples for WS2:

Words as input / Line type / Output result:
0(0 pixel shift) / Line 158 / 0(0 pixel shift)
1(-4 pixel shift) / Line 158 / 0(0 pixel shift)
2(-8 pixel shift) / Line 158 / 2(-8 pixel shift)
3(-12 pixel shift) / Line 158 / 3(-12 pixel shift)
0(0 pixel shift) / Line 162 / 1(-4 pixel shift)
1(-4 pixel shift) / Line 162 / 1(-4 pixel shift)
2(-8 pixel shift) / Line 162 / 2(-8 pixel shift)
3(-12 pixel shift) / Line 162 / 3(-12 pixel shift)

So your result of Line 162 can be explained by the previous situation left by previous line type.
The Line 186 result is normal.
The Line 230 result is explained by the absence of a stabilizer. The consequences here will depend on the warming of the chip.


Paulo.

[Steven Seagal]

This morning when i powered on my STF i got exactly the WS2 "cold" situation you described.

I love the smell of the shifter in the morning.

[ljbk]

Hi !

I confirm that in a "cold" WS2, the ULM stabilizer(MED 440 LOW 456) works correctly while the classic(HIGH 444 LOW 456) does not until the Shifter chip has warmed.
So i plan to produce new versions of these programs with the ULM stabilizer in the sync scrolling control lines to check if then any problems are found with any other WS, with or without bands, "cold" or "warm", with one or the other unstabilizer.

Paulo.

[troed]

Please don't forget that the program for Dio generates lines sizes without any stabilizer at his request.
So the results you might get will depend on the status the line before left the Shifter with.

So your result of Line 162 can be explained by the previous situation left by previous line type.
The Line 186 result is normal.
The Line 230 result is explained by the absence of a stabilizer. The consequences here will depend on the warming of the chip.

Of course. I hadn't run it in WS2 before, only WS3 where all lines are stable even without the stabilizer it seems.

It seems I can quite easily reach "WS2 cold". My STF always boots into WS3 when left overnight (it's its preferred wakeup state) and a ~2 sec power cycling will most often get it into WS2 directly. I've thus observed the difference a cold vs warming vs warm Shifter makes for stable syncscroll combinations. Basically making "cold" and "warm" work is just a matter of hunting them down via trial and error, I think, but "warming" is extremely unpredictable and can cause almost any combination to be temporarily unstable [edit: at least in WS2, I seldom see WS4. WS1 and WS3 are much more stable]. Is that your view of it as well?

(It seems my Shifter is a slow warmer - it's "cold" for at least half an hour and then spends another half hour warming gradually)

I've observed no difference in the fullview-package (ULM stabilizers or not) in "WS2 cold" vs "WS2 warm". They all work - so my "WS2 cold" mode doesn't affect regular fullscreens.

Currently my STF is warm and in WS3 - and I'm running your latest beescrol-package. Unfortunately there are issues

1) 10 minutes ago, with the default stabilizer I had bands for a lot of the combinations - but switching stabilizer removed them completely so that's fine.
2) Right now, I have no bands no matter which stabilizer I use. Or rather, on one combination the image flickers between bands and no bands and switching stabilizer works. My Shifter might be the world's slowest warmer? (The computer has now been on for 2.5 hours)

However, quite a few combinations suffer from shifted bitplanes. The bitplane errors seem stable unlike the bands.

Power cycling now gave me WS1 - unfortunately the programs just tell me they shouldn't work and don't allow me to see if the lack of -4 would look something like what I just saw in WS3

... which I suspect it would. Another power cycle and I'm back to WS3 - this time with no bitplane errors and a smooth scrolling bee (with the default stabilizer - the other one gives banding and bitplane errors).

(And just for completeness: Another power cycle into WS2 where the bee scrolled nicely with the default stabilizer. The other one gave banding and bitplane errors. [edit: Now also tested WS4 which is fine])

It seems I was able to get into a mode detected as WS3 which I _guess_ also lacked -4 due to the amount of bitplane errors I got when the bee scrolled. If you make a version that runs even though it detects WS1 I'll happily try to get into that mode again [edit: I've now repeated it so it's reproducible] and see if it at least looks the same.

(PS: Your work with sync scrolling is amazing)

[troed]

I confirm that in a "cold" WS2, the ULM stabilizer(MED 440 LOW 456) works correctly while the classic(HIGH 444 LOW 456) does not until the Shifter chip has warmed.
So i plan to produce new versions of these programs with the ULM stabilizer in the sync scrolling control lines to check if then any problems are found with any other WS, with or without bands, "cold" or "warm", with one or the other unstabilizer.

I took too long in writing my post above - didn't see yours until now. That sounds really exciting!

[Dio]

(It seems my Shifter is a slow warmer

Is there research to demonstrate that it's specifically the shifter (e.g. by freeze spray)? If not, we should use 'system' instead of 'shifter' to avoid introducing imperfect terminology. I think Paolo has already shown some evidence there are multiple warming curves in play with his results that start in one state then move through multiple other states.