horizontal scrolling on ST

[ljbk]

@Dio

Hi !

Please check the attached zip and tell me what you think about it for your tests.

Keys:
- the 13 keys between Escape and Backspace for the 13 line sizes: 0, 14, 54, 56, 80, 158, 160, 162, 184, 186, 204, 206 and 230;
- F1 to F10 for special cases: 204 + stab, 204 + stab + blank, 204 + stab + right blank, 0(7150), 0(7150) + blank, 160(start at NTSC spot (like line 162) and end like line 158), 204(71/50), noline1, noline2, sync204stb(like a RESET);
- HELP to activate or deactivate Blank for most line types;
- UNDO to activate or deactivate Right Blank for most line types;
- SPACE to quit;

The special line occurs at the end of the light blue band just before the start of the orange band. Check the 54, 56 or 80 bytes lines to locate the partial 16 pixels blank due to the switch of FFFF8260 to 2.

All the lines are stable for WS1, that seems to be a wake up state where everything is much more stable than with WS2, except 54 bytes with right blank. With WS2, you might have more problems, especially with 186 bytes and 230 bytes line since there is no stabilizer included. I did not test the program with WS3 and WS4 but there should be no problems there.
If you do tests with WS2, don't do the tests immediatly at "power on" since i have detected that in that case the Shiter tends so stabilize with time (i am not kidding) especially when changes to FFFF8260 and the 2 value (71 Hz) are involved. The response to a simple 71/50 switch at the middle of the bitmap reading will change with time. If you test it at "power on" you get one type of instability. One hour later, you might get another type. After some time it stabilizes. This does not happen with the other WS: 1, 3 and 4.

At the top you can see Wx where x is the wake up state, Fx (with x = 1,2,3,4,5,6,7,8,9,A,B,C...) to identifiy the line type, 3 digits with the expected line length and 5 digits with the MMU read bytes during the frame.

I can take the bee out

Paulo.

[Dio]

Brilliant. I got all the ST stuff out of the garage last night and I've captured a few traces tonight to make sure everything' running OK. I'll take a look at this over the weekend.

That things change over time is almost certainly some transition being very close to the point at which it's checked and so there's a setup time violation - therefore as the chips warm up and the propagation delays change slightly, the signal moves from one side of the line to the other. This happens in the Spectrum, for example, where the INT signal arrives about 40ns before a clock pulse, but the setup time window on the Z80 CPU is 80ns, and so some Z80s get the interrupt on one clock, some get it on the other clock, and a few go from one to the other as it warms up.

That's actually useful data because it lets you ID exactly where the signal test boundary is. With a can of freeze spray applied to a few different chips, you might be able to move it from one to the other with that.

[ljbk]

@ Nicolas and Steven Seagal

Hi !


The attached file contains everything you need to emulate the behaviour from my STF in PAL except the Shifter instabilities caused by resolution changes (shiftings, bands, interleaved shifting).

Together with the program i made for Dio, you have everything to adapt the emulators if you can and wish.

Nicolas, as i have your email, i will send you a test program so that you can check your STF behaviour.

Any questions, please ask.


Paulo.

[Dio]

Just to clarify, when you say 'rev C' do you mean C070523-001 Rev C? I think C070789 may have a Rev C too and possibly some others of the later boards.

My initial testing will be on a C070523 Rev D STFM (an early one). I also have a slightly later (judging by the date and a few minor component tweaks) C070523 Rev D STF which I plan to try (since it has an NTSC master clock crystal and no clock nudger) although I'm not sure how easy it will be to test that since I can only use that with a mono monitor so I will be testing blind. I have a couple of 70789s too but I don't plan to test those separately unless we see strong evidence there's different behaviour on the later borads.

[ljbk]

Just to clarify, when you say 'rev C' do you mean C070523-001 Rev C? I think C070789 may have a Rev C too and possibly some others of the later boards.

I have a C070523-001 machine like the first 1040STF you can find here:
http://www.atari-forum.com/wiki/index.p ... _revisions

[ljbk]

Hi !

Again for emulator programmers, i wish to add that the "kind-of-C" pseudo code has one flaw.
It might never happen but one has to consider the following case:

cycle 360 : FFFF8260: $00 -> $02
cycle 368 : FFFF820A: $02 -> $00
cycle 376 : FFFF820A: $00 -> $02
cycle 384 : FFFF8260: $02 -> $00

The change at cycle 368 should cause a line 158 type ending (1 word less going to the Shifter).
But in fact we get a Right Border openning due to the FFFF8260 change to $02.
So aparently, any changes to FFFF820A, will only be considered by the GLUE at the moment when FFFF8260 comes back to 0 or 1.
The same kind of timing overlaps may occur at the start of the screen for the 0 bytes line case.



Now regarding the 4 bit stuff and WS1, it seems to be an impossibility to get the -4 shift. The -12, -8 and 0 cases work fine. We can still get advantage of 0 / -8 cases .
Up to now, i could not find 1 case where the -4 shift occurs at any instability phase even for 1 VBL frame no matter what kind of destabilizer i use.
Even the 162 bytes line case and the 206 one, that cause without anything else than the early start screen start, and eventually the right border openning, a shift of the screen 4 pixels to the left in WS2, will not do that in WS1 as we get a normally placed screen.
You will say that Alien managed the 4 cases in his fullscreen (Let's do the Twist Again in PYM).
That's right but the fullscreen display does not have the same timings inside the Shifter. The screen is like 1 pixel shifted to the right. I can notice that with ease with my 40 inch LCD TV.
So i guess i am stuck with making this work as best as i can with WS2, WS4 and who knows may be the almost unreachable WS3 (with my machine).


Paulo.

[Steven Seagal]

Please confirm this or not ...



Paulo.

To confirm, the best way is to post parts of Steem's powerful shifter events report:

Disk A: Amiga Demo
Line 008 - 376:S0000 388:S0002 512:T0010

Disk A: Overscan Demos STF
Line -25 - 004:R0002 012:R0000 376:S0000 384:S0002 444:R0002 456:R0000 512:T2011

Disk A: Overscan Demos STE
boot
Line -25 - 012:R0000 376:S0000 384:S0002 444:R0002 456:R0000 508:R0002 512:T2011
menu
Line -17 - 012:R0000 376:S0000 384:S0002 444:R0002 456:R0000 512:R0002 512:T2011

Disk A: Darkside of the Spoon
Line -10 - 012:R0000 376:S0000 392:S0002 440:R0001 456:R0000 508:R0002 512:T2011

Cycles are when writes "hit". Fortunately it's the same in Steem and Hatari.

About your program and your table, gimme some time!

[Steven Seagal]

The 71/50 switch to open the right border works differently from the 60/50.
You can set $FFFF8260 to 2 at any time before a certain MMU time spot but you can not set it back to 0 before that same spot but you can set it much later.
With the 60/50 switch, you have to set the $FFFF820A to 0 a one of two time spots and then you can set it back to 2 any time after that.
For one of the 60 Hz spots, the 293, you do not need to have an EXG instuction or any instruction taking 6, 10, 14, 18, 22, ... cycles.
For the other one, either 291 in WS1 and WS3 or 295 in WS2 and WS4, you do.
You can check that some of the scan lines in the Nostalgic Demo main menu set the Right Border 60 Hz at 291 while for others it does it at 293.
For WS1 and WS3 that's fine. For WS2 and WS4, with my machine, it does not work ...
As far as i know Enchanted Land uses the 71/50 switch to open the Right Border for the sync scrolling. I do not know which time Nick selected but it works on my 1040STF Revision C.

So going back to the tests, the switchs are done at the places indicated:
-71/50 at 295/305;
-71/50 at 297/305;
-60/50 at 295/305;
and the MMU counter at $FFFF8209.w is read at the end of that line.
It can be either $CC: 204 or $A0: 160.
The combination of the three results is then tested:
WS4: CCA0CC
WS3: CCA0A0
WS2: CCCCCC Right Border is always open
WS1: A0A0A0 no case where Right Border was open

Better now ?

Paulo.

Yes knowing what to look for I could have the bees shift in WU1 and 2.
Steem doesn't handle WU3 and 4.
In fact the 71/50 switch was already in Steem, I had just disabled it...

The story is told here:
http://ataristeven.t15.org/Steem_35_com ... -up_states_

[ljbk]

Yes knowing what to look for I could have the bees shift in WU1 and 2.
Steem doesn't handle WU3 and 4.
In fact the 71/50 switch was already in Steem, I had just disabled it...

The story is told here:
http://ataristeven.t15.org/Steem_35_com ... -up_states_

Hello !

You can handle the WS you wish.
An emulator should behave like the machine itself: waking up in a WS without the user choice.
I have a few tricks to try to get the one i want but it does not always work.

Now regarding your article there is one thing wrong.
Excepting the original 4bit.prg and its small variation in June 2013 where the return to TOS is intended to be WITH shifted screen and messed up bitplanes, this will not happen in any other case.
You might notice that in most programs, especially the ones handling special Shifter conditions like fullscreens i always set the rate to 60Hz during 1 VBL before setting it back to 50 Hz on the next VBL to exit to TOS or to go to the next screen.
I was already doing this in 1990 in the Overscan Demos.
This process is the most reliable one to reset the Shifter.
With this i am sure i proceed to the next screen (or to TOS) with the screen at the right place and not bitplanes data inside the Shifter buffer registers.
That is now also done before and after the code that will detect the wake up state to make sure that the detection occurs with the Shifter reset and that the detection mechanism will not affect the following code.


Now, regarding the unstabilizer (LO->MED->LO), it will work at any cycle spot during the screen display (MMU reading) as long as the values 1 and 0 are set in FFFF8260 while the MMU is reading data for the Shifter.
If when the line starts, the resolution was already 1, it will also work but in a slight different way that is not as stable and so i will not use it.
As you probably understood the obtained shift and number of words retained in the Shifter will only depend on the cycles between the two HW updates:
8 -> 2 words -> -8
12 -> 3 words -> -12
16 -> 4 words -> 0
20 -> 5 words -> -4
The value 4 is impossible to do via SW (i think): update the same memory place with 4 cycles between both updates.
If it would be possible you would get the -4 case.
The same effect can be achieved with LO -> HI -> LO but it is much more unstable and can lead with ease to the Shifter special states: bands, interleaved shifts ...
There also, there is a slight difference between the case where the HI was already set when the line starts or if it is set during the line display.
So i only plan to use the LO-> MED -> LO case with both changes during the line display (MMU reading) but i can not say for sure that will always use the same cycles for the HW updates.


Paulo.

[troed]

2- 14 (NEW);

I had my hopes up! :/ I'm guessing you're doing a long left border 71/50? (I've always thought what happens is it reaches the 0-byte line position and the line is then turned off completely [i.e, black]). That line causes discolorization on my setup, an STF connected via SCART to an LCD-TV. I assume it messes with the color pulse timing somehow. What's strange is that the effect is like turning off the blue channel and does so for the next 32 lines (!) - but that's likely due to the internal workings of the LCD.

Picture attached from your test program which displays the same issue. It looks the same in cold/warm wakeup (which according to your new detection program is wakeup3 and wakeup4 apparently - thanks for that! ).

DSC_0256.jpg

I tried briefly separating it into one left border and one 0-byte switch to avoid color modification but no luck.

What's interesting is if this only happens on my setup All other combinations work fine.

/Troed

[ljbk]

2- 14 (NEW);

I had my hopes up! :/ I'm guessing you're doing a long left border 71/50? (I've always thought what happens is it reaches the 0-byte line position and the line is then turned off completely [i.e, black]). That line causes discolorization on my setup, an STF connected via SCART to an LCD-TV. I assume it messes with the color pulse timing somehow. What's strange is that the effect is like turning off the blue channel and does so for the next 32 lines (!) - but that's likely due to the internal workings of the LCD.

Picture attached from your test program which displays the same issue. It looks the same in cold/warm wakeup (which according to your new detection program is wakeup3 and wakeup4 apparently - thanks for that! ).

DSC_0256.jpg

I tried briefly separating it into one left border and one 0-byte switch to avoid color modification but no luck.

What's interesting is if this only happens on my setup All other combinations work fine.

/Troed

Hi !

Yes, you get a blank line always but i do not get that color problem with my 1040STF and a Sony 40 inch LCD that is about 5 years old. I will try to check with another TV.
Regarding on how it is done, you can check the XLS file i posted above:
- FFFF8260 goes to 2 as with Left Border openning;
- FFFF8260 goes back to 0 much later around 48 cycles after but before the 0 byte spot (there are many possibilities: just check the XLS);
Just by curiosity, what do you get selecting a normal 160 bytes line and pressing HELP or UNDO to allow the blank or right blank ? Do you get the same color problems ?

Paulo.

PS:
Just checked the 14 bytes line among other things with another TV (20+ years small Sony CRT).
I get a different effect from yours: i get a small distortion to the right and then the screens goes left to the correct position after a few lines. This does not happen with the LCD.
I get the same effect for the "noline2" case and for the 0 bytes + blank case (again please check the XLS file).
All the rest seems to work.
Anyway, the 14 bytes line is not very important. It would only be needed to get the sync scrolling to work with 4 lines for all 128 cases and not only 127 as it is possible since 2006.

[troed]

Regarding on how it is done, you can check the XLS file i posted above:
- FFFF8260 goes to 2 as with Left Border openning;
- FFFF8260 goes back to 0 much later around 48 cycles after but before the 0 byte spot (there are many possibilities: just check the XLS);

Heh! I was so excited for a solution to the 14 byte line I didn't even see the excel sheet (and I will have to look in my code to see how "long" the long left border line I remember was, but I'm sure you're right. The discolorization looks exactly the same)

Just by curiosity, what do you get selecting a normal 160 bytes line and pressing HELP or UNDO to allow the blank or right blank ? Do you get the same color problems ?

No, both those work out just fine. I've never seen a color issue like this one except with the 14 byte line. It would be interesting to scope the position of the generated color pulse.

(I also got into wakeup state 2 just now - it's the same)

/Troed

edit: Come to think of it, I'm using RGB SCART so whatever happens that causes the blue channel to go missing isn't a color pulse. I think. Others understand that better than I do ...

[Steven Seagal]

Hello !

You can handle the WS you wish.
An emulator should behave like the machine itself: waking up in a WS without the user choice.
I have a few tricks to try to get the one i want but it does not always work.

This could be an advanced option ("random WU") but first we need to be able to really emulate them.

Now regarding your article there is one thing wrong.
Excepting the original 4bit.prg and its small variation in June 2013 where the return to TOS is intended to be WITH shifted screen and messed up bitplanes, this will not happen in any other case.

Too bad, it was the funniest aspect.

You might notice that in most programs, especially the ones handling special Shifter conditions like fullscreens i always set the rate to 60Hz during 1 VBL before setting it back to 50 Hz on the next VBL to exit to TOS or to go to the next screen.
I was already doing this in 1990 in the Overscan Demos.
This process is the most reliable one to reset the Shifter.
With this i am sure i proceed to the next screen (or to TOS) with the screen at the right place and not bitplanes data inside the Shifter buffer registers.
That is now also done before and after the code that will detect the wake up state to make sure that the detection occurs with the Shifter reset and that the detection mechanism will not affect the following code.

No, I hadn't noticed, so you say 1 full 60hz frame + 1full 50hz frame = shifter reset?
This isn't tracked in Steem for the moment but could (should) be done.

Now, regarding the unstabilizer (LO->MED->LO), it will work at any cycle spot during the screen display (MMU reading) as long as the values 1 and 0 are set in FFFF8260 while the MMU is reading data for the Shifter.
If when the line starts, the resolution was already 1, it will also work but in a slight different way that is not as stable and so i will not use it.

As you probably understood the obtained shift and number of words retained in the Shifter will only depend on the cycles between the two HW updates:
8 -> 2 words -> -8
12 -> 3 words -> -12
16 -> 4 words -> 0
20 -> 5 words -> -4

Something like that but some shifts were wrong.

The value 4 is impossible to do via SW (i think): update the same memory place with 4 cycles between both updates.
If it would be possible you would get the -4 case.
The same effect can be achieved with LO -> HI -> LO but it is much more unstable and can lead with ease to the Shifter special states: bands, interleaved shifts ...
There also, there is a slight difference between the case where the HI was already set when the line starts or if it is set during the line display.
So i only plan to use the LO-> MED -> LO case with both changes during the line display (MMU reading) but i can not say for sure that will always use the same cycles for the HW updates.


Paulo.

For LO/MED/LO it should be alright, because the test is relative, it doesn't depend on cycle at, eg 80.
It works with both v5 and v0, where the cycles are different.

[Dio]

Realistically, anything which interferes with either the colour burst or the sync timings is illegal always; if you do want to widen the window to allow that sort of thing, then the only thing you should be testing on is a CRT with good old fashioned analogue decoding. That any antique computer works on any LCD TV or monitor is a pretty big surprise given the liberties video system engineers took with TV standards.

I haven't had time to run the program on the logic analyser, but I did do a lot of pipe cleaning at 50Hz verifying various timings. A few things observed:
Vertical timing: 3 sync, 25 blank, 38 top border, 200 screen, 45 lower border, 2 blank
the latency from the last LOAD (of a group of 4 planes) to the pixel of the read data appearing on the RGB pins is 2 clocks when the DE to load latency is 6 clocks
Horizontal timing, starting from the start of HSYNC: 5us sync, 5us blank, DE activated after 3.5us, DE active for 40us, BLANK active after 9us, HSYNC after 1.5us; in clocks, that's 40 / 40 / 28 / 320 / 72 / 12.
VSYNC starts 104 cycles after the start of the previous line's HSYNC, so that's 4 cycles before DE would be activated. It is likely that this is the point at which the H counter is reset (and V incremented) so one would expect that the horizontal period would be determined at about this point.

[ljbk]

No, I hadn't noticed, so you say 1 full 60hz frame + 1full 50hz frame = shifter reset?
This isn't tracked in Steem for the moment but could (should) be done.

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.

[ljbk]

@Troed

Hi !

I don't know if you noticed my edit above:


"
Just checked the 14 bytes line among other things with another TV (20+ years small Sony CRT).
I get a different effect from yours: i get a small distortion to the right and then the screens goes left to the correct position after a few lines. This does not happen with the LCD.
I get the same effect for the "noline2" case and for the 0 bytes + blank case (again please check the XLS file).
All the rest seems to work.
Anyway, the 14 bytes line is not very important. It would only be needed to get the sync scrolling to work with 4 lines for all 128 cases and not only 127 as it is possible since 2006.
"

Paulo.

[ljbk]

I haven't had time to run the program on the logic analyser, but I did do a lot of pipe cleaning at 50Hz verifying various timings. A few things observed:
Vertical timing: 3 sync, 25 blank, 38 top border, 200 screen, 45 lower border, 2 blank
the latency from the last LOAD (of a group of 4 planes) to the pixel of the read data appearing on the RGB pins is 2 clocks when the DE to load latency is 6 clocks
Horizontal timing, starting from the start of HSYNC: 5us sync, 5us blank, DE activated after 3.5us, DE active for 40us, BLANK active after 9us, HSYNC after 1.5us; in clocks, that's 40 / 40 / 28 / 320 / 72 / 12.
VSYNC starts 104 cycles after the start of the previous line's HSYNC, so that's 4 cycles before DE would be activated. It is likely that this is the point at which the H counter is reset (and V incremented) so one would expect that the horizontal period would be determined at about this point.

Hi !

My MMU reads 46 lines of data if i open the Lower Border.

The H period is determined at the red spot in the XLS file a few cycles before DE is normally activated.
That spot is also next to the place of the clean 0 bytes line.

Paulo.

[troed]

I don't know if you noticed my edit above:

"
Just checked the 14 bytes line among other things with another TV (20+ years small Sony CRT).
I get a different effect from yours: i get a small distortion to the right and then the screens goes left to the correct position after a few lines. This does not happen with the LCD.
I get the same effect for the "noline2" case and for the 0 bytes + blank case (again please check the XLS file).
All the rest seems to work.
Anyway, the 14 bytes line is not very important. It would only be needed to get the sync scrolling to work with 4 lines for all 128 cases and not only 127 as it is possible since 2006.
"

You're right - I missed it Actually going to 4 true lines would've been a nice accomplishment, sorry for spoiling the party It seems the sync is affected and while I never searched extensively for a possible split into two separate switches maybe you already have enough info in the table to know it can't be done. It seems my theory about it being left border + 0 was only half wrong, according to your table it's "left border + 0 & blank" instead of "left border + line 000" as I remembered.

/Troed

[ljbk]

You're right - I missed it Actually going to 4 true lines would've been a nice accomplishment, sorry for spoiling the party It seems the sync is affected and while I never searched extensively for a possible split into two separate switches maybe you already have enough info in the table to know it can't be done. It seems my theory about it being left border + 0 was only half wrong, according to your table it's "left border + 0 & blank" instead of "left border + line 000" as I remembered.

/Troed

Going to 4 lines(sync + 3) for all 128 cases is possible but i have to use the STOP pattern recognition to identify the "random" cycle after the STOP instructions before the TOP border openning.
Instead of syncing with the MMU, you get from a table you built during calibration, the "random" wait cycle the STOP will cause at that particular frame. This way you will be synched before the top border is openned thus allowing you to have all 12 valid line sizes for the first line that is normally the sync_with_MMU line.
This was discussed on this fórum in 2006 with ijor. It works on my STF but i never published the program as i do not think it is worth it because even for less than 200 fullscreen lines, you would need the STOPs that will cost you more than to use the 5th line for sync scroll.

In this 4 bit special case, as you have more shifter unstability entering at line 0, you just forget about the 4 lines and try to do the best you can with 5. Then the 6th line is the controlled unstabilizing one.

Paulo.

[ljbk]

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.

[npomarede]

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

[ljbk]

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

Hi !

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.

[Steven Seagal]

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.

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.

[npomarede]

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.

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.

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

[ljbk]

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.