Please be advised that access to Atari Forum this coming Friday will be sporadic whilst the backend operating system and dependency upgrades are carried out.
horizontal scrolling on ST
Moderators: Zorro 2, Moderator Team
-
- Atari Super Hero
- Posts: 514
- Joined: Thu Feb 19, 2004 4:37 pm
- Location: Estoril, Portugal
Re: horizontal scrolling on ST
Hi !
To allow a more visible example of the 4bit shifting reducing to the minimum the impact of sync scrolling lines, i produced the program attached: beemove0.prg.
With left and right arrow keys you move the bee through the 4 positions: 0, -4, -8 and -12 with the bee displayed correctly.
3 lines are used for sync scroller using very stable line types: 158, 160, 162 and 204 with stabilizer.
The 4th line is the unstabilizer.
196 bee lines are displayed.
You can notice at the top left corner the effect of the words in the Shifter coming from the previous VBL frame.
Paulo.
To allow a more visible example of the 4bit shifting reducing to the minimum the impact of sync scrolling lines, i produced the program attached: beemove0.prg.
With left and right arrow keys you move the bee through the 4 positions: 0, -4, -8 and -12 with the bee displayed correctly.
3 lines are used for sync scroller using very stable line types: 158, 160, 162 and 204 with stabilizer.
The 4th line is the unstabilizer.
196 bee lines are displayed.
You can notice at the top left corner the effect of the words in the Shifter coming from the previous VBL frame.
Paulo.
You do not have the required permissions to view the files attached to this post.
-
- Atari God
- Posts: 1558
- Joined: Sat Dec 01, 2007 7:38 pm
- Location: France
Re: horizontal scrolling on ST
I tested it in wake up state 2 and 4 on my STF and I get a stable image for both WS and all 4 positions (but the bee doesn't have the same colors as in beeshft0.prg, background is red but eyes are grey, not black ; maybe some planes are shifted in all 4 cases ?).
So, this is good news for my STF, a stable 4 pixel scroller seems possible, but it seems the sync scroller should be limited to only using the 4 stables line you mentioned ? (I tested beeshft0.prg at the same time in the same WS conditions and it's not stable in all 4 cases)
Nicolas
So, this is good news for my STF, a stable 4 pixel scroller seems possible, but it seems the sync scroller should be limited to only using the 4 stables line you mentioned ? (I tested beeshft0.prg at the same time in the same WS conditions and it's not stable in all 4 cases)
Nicolas
-
- Atari Super Hero
- Posts: 514
- Joined: Thu Feb 19, 2004 4:37 pm
- Location: Estoril, Portugal
Re: horizontal scrolling on ST
Hi !npomarede wrote:I tested it in wake up state 2 and 4 on my STF and I get a stable image for both WS and all 4 positions (but the bee doesn't have the same colors as in beeshft0.prg, background is red but eyes are grey, not black ; maybe some planes are shifted in all 4 cases ?).
So, this is good news for my STF, a stable 4 pixel scroller seems possible, but it seems the sync scroller should be limited to only using the 4 stables line you mentioned ? (I tested beeshft0.prg at the same time in the same WS conditions and it's not stable in all 4 cases)
Nicolas
The colour issue is not a problem.
I change the colors 0 and 15 at start to allow the user to see the incoming data from the previous VBL frame (and this was derived from the Shifter test program where i do that

"
move.l zpimage(pc),a0
movem.l 2(a0),d0-d7
movem.l d0-d7,$8240.w
move #$777,$8240.w
move #$000,$825E.w
"
If you patch the last two instructions with nops, you will get proper colors.
Now regarding the sync scroll, i have already rebuilt my 1536 bytes controlling table, skipping the most unreliable line sizes: 54 and 186. I can also stabilize these but i managed to keep it all with the 5+1 lines and not use those.
So in the attached zip you will find beeshft1.prg, the image and the new sync scroll table.
That table is compatible with beeshft0.prg.
The only differences in the program are:
- the date;
- the left border 71 Hz cycle time that i moved from emulator cycle 0 (or 512) to 508;
So, you can test both cases and check if you have problems with one of the left border timings or with both.
The new sync combinations use the less possible number of times the left border openning (with 5 lines), take into account my recent tests on each line size and how they behave if they received words in the Shifter as input to get to the unstabilizer line with a stable Shifter.
Paulo.
Edit:
That does not mean it will now work always in WS2. My machine can start in WS2 but in a Shifter state where the (LO/MED/LO) unstabilizer does not work but on the contrary the (LO/HI/LO) combinations look very stable.
In that case the 4bit.prg (TOS shifting program) will result in:
1- Normal TOS with GREEN background;
2- Normal TOS with GREEN background instead of BLUE and 4 pixel shifted;
3- Vertical 16 pixel bands interleaved with 16 border color pixels and GREY background (so bitplanes are as expected);
4- Vertical 16 pixel bands interleaved with 16 border color pixels and RED background (so bitplanes are as expected);
In that state the Spectrum 512 pictures show their funny dots.
The Shifter status appears to be very stable but i will leave the machine running to see if something changes later on.
You do not have the required permissions to view the files attached to this post.
-
- Fuji Shaped Bastard
- Posts: 2018
- Joined: Sun Dec 04, 2005 9:12 am
- Location: Undisclosed
Re: horizontal scrolling on ST
As this is easier and saves a variable, we'll go with the guess: one fetched line at 60hz will reset an unstable shifter, though I don't know why.ljbk wrote: Spending a full frame at 60 Hz starting at VBL when you were at 50 Hz and returning to 50 Hz at the start of next VBL, resets the Shifter for sure with my machine.
My guess is that only 1 line, at least with the MMU reading, totally spent at 60 Hz (with the GLUE sending HSYNC signal for a NTSC line), will be enough to reset the Shifter but that is a guess and not something tested !
Paulo.
In the CIA we learned that ST ruled
Steem SSE: http://sourceforge.net/projects/steemsse
Steem SSE: http://sourceforge.net/projects/steemsse
-
- Atari God
- Posts: 1558
- Joined: Sat Dec 01, 2007 7:38 pm
- Location: France
Re: horizontal scrolling on ST
I got similar results to yours ; after around 20 tries (switch off/on between), I only got WS2 and one case with interleaved 16 pixels.ljbk wrote:npomarede wrote: Edit:
That does not mean it will now work always in WS2. My machine can start in WS2 but in a Shifter state where the (LO/MED/LO) unstabilizer does not work but on the contrary the (LO/HI/LO) combinations look very stable.
In that case the 4bit.prg (TOS shifting program) will result in:
1- Normal TOS with GREEN background;
2- Normal TOS with GREEN background instead of BLUE and 4 pixel shifted;
3- Vertical 16 pixel bands interleaved with 16 border color pixels and GREY background (so bitplanes are as expected);
4- Vertical 16 pixel bands interleaved with 16 border color pixels and RED background (so bitplanes are as expected);
In that state the Spectrum 512 pictures show their funny dots.
The Shifter status appears to be very stable but i will leave the machine running to see if something changes later on.
In WS2, both beeshft0 and beesft1 worked : correct display with all 4 horizontal scrolling. So, opening left border at cycle 508 or 512 doesn't makes a difference, the lines' combinations used in your new hardscroll table are much better.
In WS2 with interleaved column, I have with beemove0 :
- correct image on start (no scroll)
- shifted planes pressing left (-4)
- correct image pressing left (-8) but with interleaved 16 normal pixels and 16 white background
- correct image pressing left (-12) but with interleaved 16 normal pixels and 16 white background
So, except for this unstable WS2 where shifter misses 16 pixels every 32 pixels, I would say the horizonal scrolling is working good (I didn't get WS4, but as beemove0 worked in WS4, I think beeshft would work too with the new table)
Nicolas
-
- Atari Super Hero
- Posts: 514
- Joined: Thu Feb 19, 2004 4:37 pm
- Location: Estoril, Portugal
Re: horizontal scrolling on ST
Well, believe it or not, in that WS2 case i refered above, where the 4bit.prg (TOS shifting) returns bands for values 3 and 4, and where we can observ the funny dots for Spectrum 512 pictures, using a LO/HI/LO unstabilizer at the same cycles makes everything work !!!
So we are now in a case like Spectrum 512.
The SW can not detect that Shifter state, at least up to my knowledge, but the user can see the difference.
So we can draw a vertical line at the Spectrum transition pixel and we ask the user to proceed acording to what he/she sees: press 1 to use LO/MED/LO and press 2 to use LO/HI/LO...
The code change is minimum: less than 20 bytes.
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.
So we are now in a case like Spectrum 512.
The SW can not detect that Shifter state, at least up to my knowledge, but the user can see the difference.
So we can draw a vertical line at the Spectrum transition pixel and we ask the user to proceed acording to what he/she sees: press 1 to use LO/MED/LO and press 2 to use LO/HI/LO...


The code change is minimum: less than 20 bytes.
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.
You do not have the required permissions to view the files attached to this post.
-
- Atari God
- Posts: 1558
- Joined: Sat Dec 01, 2007 7:38 pm
- Location: France
Re: horizontal scrolling on ST
While testing this, I got WS1 with interleaved columns.ljbk wrote: The code change is minimum: less than 20 bytes.
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.
In that case, the results are :
- beemove0 : same results as WS2 with interleaved : 0=correct -4=shifted -8 and -12=correct with interleaved
beesfht0 and beeshft1 produced the same wrong results as with WS2 interleaved.
beesfth2 was correct for 0, -8 and -12 (no interleave) but -4 had shifted planes (the same shifting as for beemove0 with -4 pixels)
Now, after a few warm resets (holding the button a little longer seems to exit the interleaved state...), I have still WS1 but without interleaved.
In that case, beeshft0, 1 and 2 as well as beemove0 are all producing the same results : 0, -8 and -12 are correct, but -4 has shifted planes (same results as -4 for beeshft2 and beemove0 when I had the interleaved effect).
Can't get anything that WS1 at the moment

-> on my STF in WS1, -4 is not correct for any test program, whether interleaved or not.
Nicolas
-
- Atari Super Hero
- Posts: 514
- Joined: Thu Feb 19, 2004 4:37 pm
- Location: Estoril, Portugal
Re: horizontal scrolling on ST
So this is as expected: -4 shift seems to be an impossibility in WS1 !npomarede wrote:
-> on my STF in WS1, -4 is not correct for any test program, whether interleaved or not.
Reading your several posts since i published the new wake detection mechanism, i can see that you have already managed to get the 4 wake up states. That means that your machine also has at least the same amount of different timings as mine.
With my machine, if i press the warm reset button and i leave it pressed while i do the cold reset, i almost always get WS2.
To get another state, i can not press the warm reset button and i must do several switch on / switch off quite fast in order to get WS1 or WS4. WS3 is even more dificult to get. It might also depend on the temperature of the chips. If the machine is cold, i get different WS with less dificulty.
Paulo.
-
- Captain Atari
- Posts: 451
- Joined: Thu Feb 28, 2008 3:51 pm
Re: horizontal scrolling on ST
With my machine, I also find that glitching the power quickly is the most likely thing to force a change in wakeup state. It seems to pick all of them fairly randomly though, that may be because I just have the motherboard bare on the table
.

-
- Atari Super Hero
- Posts: 514
- Joined: Thu Feb 19, 2004 4:37 pm
- Location: Estoril, Portugal
Re: horizontal scrolling on ST
Hi !
During the tests i made to find the last cycle where an update can be done in time for the change to have an impact on the displayed bitmap, i found the following emulator bugs you can reproduce with the attached program in the zip.
The real HW will show line 0 in white, then line 1 in white up to pixel 332 except the last 16 bitmap pixels that are light grey. From pixel 333, color changes to $357.
The light grey update in memory is done early on line 1 and a change to white is done at cycle 384 on line 1, the first where it will have no effect on the displayed data. If it would be done at cycle 380, you would see no grey pixels.
The change to color $357 is done at cycle 416.
No updates to either $FFFF820A or $FFFF8260.
STEem and Hatari present different behaviours but none of them are correct.
Now going back to the topic, i made some tests with medium resolution to check for different timings for $FFFF820A changes or MD/HI/MD changes in $FFFF8260 in the WS2 with bands situation but i got the same results as with low resolution tests.
Also that WS2 with bands behaviour/situation did not change during the night so we can assume that it is a stable Shifter state unlike the normal WS2 that takes some (warming i assume) time to stabilize.
I have also managed to get to a WS4 with bands (different from the WS 2 bands). There beeshft1(LO/MD/LO) will not work but again beeshft2(LO/HI/LO) will work. In that state again i had the funny Spectrum 512 dots so it seems that those "band" Shifter states are related to the funny Spectrum 512 dots (WS2 and WS4).
beeshft2(LO/HI/LO) has also worked in a warmed normal WS2 without bands.
I also got normal WS1 and the behaviour was the same as before: -4 case is not reachable.
Still need to get a cold normal WS2 without bands and the almost unreachable WS3.
Update:
Just got a WS3 with LO/MD/LO leading to bands but no Spectrum 512 dots. The result is that beeshft1 does not work as expected but beeshft2 does
!!!
So i got this working on all wake up states except WS1 and beeshft2 is becoming the leading variant.
Paulo.
During the tests i made to find the last cycle where an update can be done in time for the change to have an impact on the displayed bitmap, i found the following emulator bugs you can reproduce with the attached program in the zip.
The real HW will show line 0 in white, then line 1 in white up to pixel 332 except the last 16 bitmap pixels that are light grey. From pixel 333, color changes to $357.
The light grey update in memory is done early on line 1 and a change to white is done at cycle 384 on line 1, the first where it will have no effect on the displayed data. If it would be done at cycle 380, you would see no grey pixels.
The change to color $357 is done at cycle 416.
No updates to either $FFFF820A or $FFFF8260.
STEem and Hatari present different behaviours but none of them are correct.
Now going back to the topic, i made some tests with medium resolution to check for different timings for $FFFF820A changes or MD/HI/MD changes in $FFFF8260 in the WS2 with bands situation but i got the same results as with low resolution tests.
Also that WS2 with bands behaviour/situation did not change during the night so we can assume that it is a stable Shifter state unlike the normal WS2 that takes some (warming i assume) time to stabilize.
I have also managed to get to a WS4 with bands (different from the WS 2 bands). There beeshft1(LO/MD/LO) will not work but again beeshft2(LO/HI/LO) will work. In that state again i had the funny Spectrum 512 dots so it seems that those "band" Shifter states are related to the funny Spectrum 512 dots (WS2 and WS4).
beeshft2(LO/HI/LO) has also worked in a warmed normal WS2 without bands.
I also got normal WS1 and the behaviour was the same as before: -4 case is not reachable.
Still need to get a cold normal WS2 without bands and the almost unreachable WS3.
Update:
Just got a WS3 with LO/MD/LO leading to bands but no Spectrum 512 dots. The result is that beeshft1 does not work as expected but beeshft2 does

So i got this working on all wake up states except WS1 and beeshft2 is becoming the leading variant.
Paulo.
You do not have the required permissions to view the files attached to this post.
-
- Atari God
- Posts: 1799
- Joined: Mon Apr 30, 2012 6:20 pm
- Location: Sweden
Re: horizontal scrolling on ST
edit: double posted
Last edited by troed on Tue Aug 13, 2013 3:36 pm, edited 1 time in total.
-
- Atari God
- Posts: 1799
- Joined: Mon Apr 30, 2012 6:20 pm
- Location: Sweden
Re: horizontal scrolling on ST
I saw you reached WS3 in a later post, but for reference: My STF boots by default into WS3 when cold. When warmer I can easily (short power cycling) get it into WS4 mixed with WS2 appearing also quite often. Since replacing my wakeup detector (the old cold/warm) with yours I haven't seen WS1, but since I've seen "cold wakeup" effects* different from what I see in WS3 I'm quite sure my machine reaches it sometimes as well. I'd be happy to test WS3 stuff if you don't want to wear out your PSU switch.ljbk wrote:With my machine, if i press the warm reset button and i leave it pressed while i do the cold reset, i almost always get WS2.
To get another state, i can not press the warm reset button and i must do several switch on / switch off quite fast in order to get WS1 or WS4. WS3 is even more dificult to get.
This was the method (glitching without rebooting) with which I could get the Omega fullscreen**, Death of the Left Border etc** running on an old ST I had way back in the late 80s. It also cured the stable shifter bitplane effects that appeared quite often when switching screen in our coding setup of choice - using an SM124 for Devpac and composite connected to a TV to view the results. No cable swapping needed, just exiting and entering the appropriate resolution.Dio wrote:With my machine, I also find that glitching the power quickly is the most likely thing to force a change in wakeup state. It seems to pick all of them fairly randomly though, that may be because I just have the motherboard bare on the table .
I don't dare doing it to the STF I have here now though - it would need PSU refurbishing first ..
/Troed
*) material for a future post
**) no stabilizer == only worked in .. WS2, right? Or WS4 as well?
-
- Atari Super Hero
- Posts: 514
- Joined: Thu Feb 19, 2004 4:37 pm
- Location: Estoril, Portugal
Re: horizontal scrolling on ST
@Troed
The old wake up detection mechanism i used was based on the 162 bytes and 0 bytes line using 60/50 switch.
As both cases require a 2 cycle granularity precision and there is one unique spot, in one case to return to 50 Hz and on the other case to set the 60Hz, it was easy to distinguish between 1 and 2.
But the problem is that not only you have 2 sets of $FFFF820A timings but you have on top of that 3 sets of $FFFF8260 timings.
There are two spots where you can check all of those: right border and 0 bytes line that are both possible with 60/50 and 71/50. I choosed the right border case.
So old state 1 is now divided in 1 and 3 and old state 2 is now divided in 2 and 4.
This does not mean that there are not any special effects inside the same WS that occur sometimes and sometimes not.
The 16 pixels bands and 16 pixels border pattern when doing a LO/MED/LO switch is one of them.
The instability of the destabilizer methods from a cold machine (just powered on) to a warmer one can be another especially if setting $FFFF8260 to 2.
These can not be detected by the SW.
Now, for the specific case of this 4 bit shifting (and scrolling) feature, i am convinced that it will never work with WS1 because i have not found yet one unique case of instability, even lasting only 1 frame, leading to a 4 pixel shift to the left. So you can use, -8 and 0 spots and you will need twice the video buffers as for the other WS for the same kind of scrolling.
For WS 2, 3 and 4, it seems that the beeshft2 version of the program using the LO/HI/LO destabilizer is the best candidate to work for all cases.
So any program using this will have to invite the user to reboot his/her machine if WS1 is detected and maybe the best is to leave a key (like ESCAPE perhaps) to allow the user to switch between LO/HI/LO destabilizer and LO/MED/LO destabilizer if the display is not right (very quick on the fly patching).
One thing is for sure to me now: the sync scrolling table is now very stable and will not be changed and there are not many options for destabilizers.
So the test phase is for me nearly finished: i am just letting the machine rest to get a WS2 cold next time to check beeshft2.prg.
Next, i hope to show something actually scrolling ...
Of course, you can do your own tests with WS3 or others and report if you wish:
- 4bit.prg and beemove0.prg will show you if any bands are visible;
- beeshft1.prg uses LO/MED/LO destabilizer ;
- beeshft2.prg uses LO/HI/LO destabilizer ;
Thanks for offering help.
Paulo.
The old wake up detection mechanism i used was based on the 162 bytes and 0 bytes line using 60/50 switch.
As both cases require a 2 cycle granularity precision and there is one unique spot, in one case to return to 50 Hz and on the other case to set the 60Hz, it was easy to distinguish between 1 and 2.
But the problem is that not only you have 2 sets of $FFFF820A timings but you have on top of that 3 sets of $FFFF8260 timings.
There are two spots where you can check all of those: right border and 0 bytes line that are both possible with 60/50 and 71/50. I choosed the right border case.
So old state 1 is now divided in 1 and 3 and old state 2 is now divided in 2 and 4.
This does not mean that there are not any special effects inside the same WS that occur sometimes and sometimes not.
The 16 pixels bands and 16 pixels border pattern when doing a LO/MED/LO switch is one of them.
The instability of the destabilizer methods from a cold machine (just powered on) to a warmer one can be another especially if setting $FFFF8260 to 2.
These can not be detected by the SW.
Now, for the specific case of this 4 bit shifting (and scrolling) feature, i am convinced that it will never work with WS1 because i have not found yet one unique case of instability, even lasting only 1 frame, leading to a 4 pixel shift to the left. So you can use, -8 and 0 spots and you will need twice the video buffers as for the other WS for the same kind of scrolling.
For WS 2, 3 and 4, it seems that the beeshft2 version of the program using the LO/HI/LO destabilizer is the best candidate to work for all cases.
So any program using this will have to invite the user to reboot his/her machine if WS1 is detected and maybe the best is to leave a key (like ESCAPE perhaps) to allow the user to switch between LO/HI/LO destabilizer and LO/MED/LO destabilizer if the display is not right (very quick on the fly patching).
One thing is for sure to me now: the sync scrolling table is now very stable and will not be changed and there are not many options for destabilizers.
So the test phase is for me nearly finished: i am just letting the machine rest to get a WS2 cold next time to check beeshft2.prg.
Next, i hope to show something actually scrolling ...
Of course, you can do your own tests with WS3 or others and report if you wish:
- 4bit.prg and beemove0.prg will show you if any bands are visible;
- beeshft1.prg uses LO/MED/LO destabilizer ;
- beeshft2.prg uses LO/HI/LO destabilizer ;
Thanks for offering help.
Paulo.
-
- Fuji Shaped Bastard
- Posts: 2018
- Joined: Sun Dec 04, 2005 9:12 am
- Location: Undisclosed
Re: horizontal scrolling on ST
Could it be asserted in what WU (sorry I use 'WU') - anyway, state, should Omega and Death of the Left Border run or fail? Is DoLB STF-only? Omega certainly.troed wrote: This was the method (glitching without rebooting) with which I could get the Omega fullscreen**, Death of the Left Border etc** running on an old ST I had way back in the late 80s. It also cured the stable shifter bitplane effects that appeared quite often when switching screen in our coding setup of choice - using an SM124 for Devpac and composite connected to a TV to view the results. No cable swapping needed, just exiting and entering the appropriate resolution.
I don't dare doing it to the STF I have here now though - it would need PSU refurbishing first ..
/Troed
*) material for a future post
**) no stabilizer == only worked in .. WS2, right? Or WS4 as well?
Last edited by Steven Seagal on Wed Aug 14, 2013 6:54 pm, edited 1 time in total.
In the CIA we learned that ST ruled
Steem SSE: http://sourceforge.net/projects/steemsse
Steem SSE: http://sourceforge.net/projects/steemsse
-
- Captain Atari
- Posts: 451
- Joined: Thu Feb 28, 2008 3:51 pm
Re: horizontal scrolling on ST
One thing to think about is that one or more of the ff8260 changes may be taking place at a different time in the Glue and in the Shifter, since it's two different devices mirroring the same state. In particular, the Shifter only sees the write through the bus gateway, which may (is likely to?) impose different timing than the Glue's direct connection to the CPU bus.
-
- Atari Super Hero
- Posts: 514
- Joined: Thu Feb 19, 2004 4:37 pm
- Location: Estoril, Portugal
Re: horizontal scrolling on ST
Any program where the value 2 is set in $FFFF8260 on cycle 4 to remove the left border (like Overscan Demos 1990) will be STF only. I don't know if that is the case in these two programs.Steven Seagal wrote: Could it be asserted in what WU (sorry I use 'WU') - anyway, state, shoud Omega and Death of the Left Border run or fail? Is DoLB STF-only? Omega certainly.
Now, another thing is to have or not a stabilizer at the end of line (cycles 444 and 456 (HI/LO) or cycles 440 and 456 MED/LO (ULM) or any other version).
All wake up states have variants where these lines will be displayed correctly with a bitplane correction compared to the "normal" fullscreen with stabilizer.
On my machine, WS2 is the most frequent and the one where i can observ the most variants in behaviour with some of them leading to a rubish picture for fullscreen lines without stabilizer like the Omega program i think.
WS1, 3 and 4 are in general more stable with my machine despite they are dificult to reach compared to WS2.
Paulo.
-
- Atari Super Hero
- Posts: 514
- Joined: Thu Feb 19, 2004 4:37 pm
- Location: Estoril, Portugal
Re: horizontal scrolling on ST
Yes, i already refered that in my initial 4 WS post.Dio wrote:One thing to think about is that one or more of the ff8260 changes may be taking place at a different time in the Glue and in the Shifter, since it's two different devices mirroring the same state. In particular, the Shifter only sees the write through the bus gateway, which may (is likely to?) impose different timing than the Glue's direct connection to the CPU bus.
But i made sure that the unstabilizers work on "line time areas" where GLUE will not do anything with those changes: after the MMU has started reading and before the 54 bytes zone or after the right blank zone and before the right border zone. In those zones, only the Shifter is involved and it is useless to try the odd multiples of 2 cycles: you get the same behaviour as with the next in line of the multiples of 4 cycles.
Paulo.
-
- Atari God
- Posts: 1558
- Joined: Sat Dec 01, 2007 7:38 pm
- Location: France
Re: horizontal scrolling on ST
Helloljbk wrote:Reading your several posts since i published the new wake detection mechanism, i can see that you have already managed to get the 4 wake up states. That means that your machine also has at least the same amount of different timings as mine.npomarede wrote:
-> on my STF in WS1, -4 is not correct for any test program, whether interleaved or not.
Paulo.
I didn't get WS3 recently, so I would still need to test it with beeshft0, 1 and 2 to be sure.
As for WS2 without interleaved columns (the more common one), it worked for all 4 positions with beeshft0 and beeshft1 ; but I now tested it with beeshft2 also.
Result is that it doesn't work : I get stable for 0 pixel scroll, but 1 case with planes shifted and 2 cases with what seems to be correct scrolling but interleaved column with 16 pixels background color. So for me, there's currently no version of beeshft that would work in both cases for WS2.
Nicolas
-
- Atari Super Hero
- Posts: 514
- Joined: Thu Feb 19, 2004 4:37 pm
- Location: Estoril, Portugal
Re: horizontal scrolling on ST
Thanks for the info.npomarede wrote: As for WS2 without interleaved columns (the more common one), it worked for all 4 positions with beeshft0 and beeshft1 ; but I now tested it with beeshft2 also.
Result is that it doesn't work : I get stable for 0 pixel scroll, but 1 case with planes shifted and 2 cases with what seems to be correct scrolling but interleaved column with 16 pixels background color. So for me, there's currently no version of beeshft that would work in both cases for WS2.
Nicolas
Well, this is one more reason to leave a special key for on the fly patching.
This morning i observed the effects of cold chips waking up in WS2.
This affects both beeshft1 and beeshft2 and also a normal fullscreen display (some lines appear with bands) and the effects depend if the drive contains a disquette or not. In this morning case, fullscreen (Overscan 1990 (cycle 4 for 71 Hz)) was not working correctly with the disquette in but was working if i took it out. It can happen to be exactly the opposite.
The results were not exactly the same for a fullscreen with 71 Hz at cycle 508 but still there were problems and behaviour changed if the disquette was taken out or not.
The same occured with the beeshft programs. The LO/MED/LO unstabilizer was working but together with sync scrolling sometimes it failed depending if the disquette was in or not. The same for beesfht2.
Spectrum 512 display was correct in both cases.
After something like 15 minutes, all was working correctly.
So, it seems that this warming problem affects the stabilizer that is a mandatory feature of this 4 bit shifting.
So, Nicolas, was your STF warm

Paulo.
-
- Atari God
- Posts: 1558
- Joined: Sat Dec 01, 2007 7:38 pm
- Location: France
Re: horizontal scrolling on ST
No, it was jus after powering it on (it was off for more than 24h). This is usually the state I get when powering on, I didn't see a change after 15 minutes or so.ljbk wrote: So, Nicolas, was your STF warmwhen you tested WS2 and beesfht2 ?
Paulo.
My STF seems more stable wrt WS in the sense that once it picks a WS, it's really difficult to change it, even with multtiple reboots/power off/on.
Nicoals
-
- Atari Super Hero
- Posts: 514
- Joined: Thu Feb 19, 2004 4:37 pm
- Location: Estoril, Portugal
Re: horizontal scrolling on ST
Thanks Nicolas !
So i just managed to complete the tests gettting the missing WS3N (normal / no bands).
The result is that both beeshft2 and 1 work.
So the conclusion is that beeshft2 has worked with my machine for WS2N, WS2B, WS3N, WS3B, WS4N and WS4B where B stands for "bands" and N for "normal / no "bands"" as long as the machine has warmed up in case of WS2N.
Beeshft1 only works for WS2N, WS3N and WS4N as long as the machine has warmed up in case of WS2N.
I have never seen any program work in WS1 for position -4 but i did for the other positions (-12, -8 and 0) but i did not take note at the time if it was a B case or a N case.
So any program in the future using this will invite the user to cold reboot if WS1 is detected and will prefer the beeshft2 unstabilzer (LO/HI/LO) as the default one but will leave a key to allow the user to switch with the beeshft1 unstabilzer (LO/MED/LO) and switch back at any time.
Now regarding some other visible (but not detectable by SW) differences between the wake up states, i can point the following one:
WS3B and WS4B allow fullscreen lines with stabilizer and contralable shift without going to medium resolution.
You set the value 2 at cycle 508 and then depending when you switch back to 0 you will get a variable and stable shift. It is like the Alien 4 bit case but without the transition to medium at cycle 12.
This will not work for any other case in WS2, WS3 and WS4 and at least one the cases for WS1.
All WS cases tested until now support the normal fullscreen line with the switch back to low res at cycle 12 and stabilizer, but also the same without stabilizer and a change in bitplanes and also a switch back to low res at cycle 28. The exception to these two last cases is a "cold" machine in WS2.
After that amount of tests, it has not been proved that the Spectrum 512 funny dots are related to the "bands" state as i could find WS4B cases both with and without the funny dots.
Paulo.
So i just managed to complete the tests gettting the missing WS3N (normal / no bands).
The result is that both beeshft2 and 1 work.
So the conclusion is that beeshft2 has worked with my machine for WS2N, WS2B, WS3N, WS3B, WS4N and WS4B where B stands for "bands" and N for "normal / no "bands"" as long as the machine has warmed up in case of WS2N.
Beeshft1 only works for WS2N, WS3N and WS4N as long as the machine has warmed up in case of WS2N.
I have never seen any program work in WS1 for position -4 but i did for the other positions (-12, -8 and 0) but i did not take note at the time if it was a B case or a N case.
So any program in the future using this will invite the user to cold reboot if WS1 is detected and will prefer the beeshft2 unstabilzer (LO/HI/LO) as the default one but will leave a key to allow the user to switch with the beeshft1 unstabilzer (LO/MED/LO) and switch back at any time.
Now regarding some other visible (but not detectable by SW) differences between the wake up states, i can point the following one:
WS3B and WS4B allow fullscreen lines with stabilizer and contralable shift without going to medium resolution.
You set the value 2 at cycle 508 and then depending when you switch back to 0 you will get a variable and stable shift. It is like the Alien 4 bit case but without the transition to medium at cycle 12.
This will not work for any other case in WS2, WS3 and WS4 and at least one the cases for WS1.
All WS cases tested until now support the normal fullscreen line with the switch back to low res at cycle 12 and stabilizer, but also the same without stabilizer and a change in bitplanes and also a switch back to low res at cycle 28. The exception to these two last cases is a "cold" machine in WS2.
After that amount of tests, it has not been proved that the Spectrum 512 funny dots are related to the "bands" state as i could find WS4B cases both with and without the funny dots.
Paulo.
-
- Atari Super Hero
- Posts: 514
- Joined: Thu Feb 19, 2004 4:37 pm
- Location: Estoril, Portugal
Re: horizontal scrolling on ST
Hi !
I have some complementary news.
I left my 1040STF running in W3N since this morning just to keep W3N for some extra test i might want as it is dificult to get.
I just went there to test a little thing and guess what, the fullscreen properties and beeshft properties changed compared to the morning. The cases where the fullscreen would work without stabilizer are gone and beeshft2 does not work on position -4 anymore but beeshft1 still works.
So there are also warming changes for WS3N and maybe for the remaining WS and not only for WS2N.
This implies that the "on the fly patching" key is mandatory.
Paulo.
I have some complementary news.
I left my 1040STF running in W3N since this morning just to keep W3N for some extra test i might want as it is dificult to get.
I just went there to test a little thing and guess what, the fullscreen properties and beeshft properties changed compared to the morning. The cases where the fullscreen would work without stabilizer are gone and beeshft2 does not work on position -4 anymore but beeshft1 still works.
So there are also warming changes for WS3N and maybe for the remaining WS and not only for WS2N.
This implies that the "on the fly patching" key is mandatory.
Paulo.
-
- Fuji Shaped Bastard
- Posts: 2018
- Joined: Sun Dec 04, 2005 9:12 am
- Location: Undisclosed
Re: horizontal scrolling on ST
It depends on what we call pixel 333. If we start from normal left border, then Steem should start displaying the blue line at the correct point (416-83=333).ljbk wrote: During the tests i made to find the last cycle where an update can be done in time for the change to have an impact on the displayed bitmap, i found the following emulator bugs you can reproduce with the attached program in the zip.
The real HW will show line 0 in white, then line 1 in white up to pixel 332 except the last 16 bitmap pixels that are light grey. From pixel 333, color changes to $357.
The light grey update in memory is done early on line 1 and a change to white is done at cycle 384 on line 1, the first where it will have no effect on the displayed data. If it would be done at cycle 380, you would see no grey pixels.
The change to color $357 is done at cycle 416.
No updates to either $FFFF820A or $FFFF8260.
STEem and Hatari present different behaviours but none of them are correct.
Or should Steem emulate light grey pixels?
Here's what Steem sees:
000 - 008:r0900 028:r0900 048:r0900 068:r0902 084:r090A
001 - 028:S0002 036:S0002 416:P0357
201 - 344:P0777 360:j0006 400:r0502 404:r076F 408:r0900 440:r0502 444:r076F 448:r0900
P for palette.
In the CIA we learned that ST ruled
Steem SSE: http://sourceforge.net/projects/steemsse
Steem SSE: http://sourceforge.net/projects/steemsse
-
- Fuji Shaped Bastard
- Posts: 2018
- Joined: Sun Dec 04, 2005 9:12 am
- Location: Undisclosed
Re: horizontal scrolling on ST
And also not in Steemljbk wrote: 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.

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.
In the CIA we learned that ST ruled
Steem SSE: http://sourceforge.net/projects/steemsse
Steem SSE: http://sourceforge.net/projects/steemsse
-
- Atari Super Hero
- Posts: 514
- Joined: Thu Feb 19, 2004 4:37 pm
- Location: Estoril, Portugal
Re: horizontal scrolling on ST
Steem displays the color $0357 at the correct pixel.Steven Seagal wrote: It depends on what we call pixel 333. If we start from normal left border, then Steem should start displaying the blue line at the correct point (416-83=333).
Or should Steem emulate light grey pixels?
Here's what Steem sees:
000 - 008:r0900 028:r0900 048:r0900 068:r0902 084:r090A
001 - 028:S0002 036:S0002 416:P0357
201 - 344:P0777 360:j0006 400:r0502 404:r076F 408:r0900 440:r0502 444:r076F 448:r0900
P for palette.
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.