horizontal scrolling on ST

[ljbk]

Isn't the NTSC 160 offset by -4 compared to the PAL 160...?

The answer is, for my machine, yes for WS2, WS3 and WS4 and no for WS1.
A 162 bytes line (start like NTSC and end like normal PAL) will be shifted 4 pixels to the left for all WS except WS1.
Now, if really show a NTSC line with the with the respective HSYNC and 508 cycles, i don't known if the screen will start earlier or not.

I'm only able to profile W1 so far, but the timing indicates that it should be visible here too. Both DE and LOAD start 4 clocks early and the line length remains 64us, 512 cycles.

Still can't upload the PNGs to prove it. Working on fixing my FTP space

Hi !

One thing is the DE signal but another will be the Shifter updating the RGB signals or not.
As we have seen even for the same WS, the Shifter can start the next line shifted early or not but the DE timings will be exactly the same i presume.
A line 158 in WS2 can do the following as far as i remember without looking at my notes:
- line started 0 shifted => next line starts 0 shifted;
- line started -4 shifted => next line starts 0 shifted;
- line started -8 shifted => next line starts -8 shifted;
- line started -12 shifted => next line starts -12 shifted;
A line 162 in WS2 can do the following as far as i remember without looking at my notes:
- line started 0 shifted => next line starts -4 shifted;
- line started -4 shifted => next line starts -4 shifted;
- line started -8 shifted => next line starts -8 shifted;
- line started -12 shifted => next line starts -12 shifted;
In both cases, i assume that the DE and LOAD will have the same timings for all 4 sub cases.

Paulo.

[ljbk]

The bad news: the W numbers have been assigned on a random basis .
- W2 is 3 cycles DE to LOAD latency (wakeup 2 in ijor's program)
- W4 is 4 cycles DE to LOAD latency (wakeup 2 in ijor's program)
- W3 is 5 cycles DE to LOAD latency (wakeup 1 in ijor's program)
- W1 is 6 cycles DE to LOAD latency (wakeup 1 in ijor's program)

Not random but historical.

The $FFFF820A timings in creating line sizes of 0 bytes and 162 bytes + the Nostalgic Main Menu error on my machine lead me to discover the first two wake up states in 2006.
This was discussed on a long thread, probably still available, with ijor. I would have to dig to find it.

Edit: this thread http://www.atari-forum.com/viewtopic.ph ... m&start=25 from end September 2006.

Now in 2013, i managed to find out that first there was a division in the old WS1 and later in the old WS2, then creating WS3 and WS4 and that WS3 and WS4 have the same $FFFF8260 timings.
Your numbers just proved that since WS3 and WS4 are quite close and that WS2 and WS1 are quite far away.
About renaming the WS, for the SW programer may be that DL3/4/5/6 is not as meaningfull as a simple 1, 2, 3, 4 but i understand it is for the HW interested person.

Paulo.

[Dio]

One thing is the DE signal but another will be the Shifter updating the RGB signals or not.

I can test this (I am monitoring the RGB pins) if there is data in the first word of the 160-byte line.

However, so far I see no indication that the 4th LOAD to visible signal has a variation, certainly not one as large as 4 cycles. If that existed, then surely I wouldn't be able to (consistently) measure the DL simply by a post-it note on the screen? (It is of course possible that one only appears in this particular 160-byte case).

While I agree the DL number is more meaningful the the HW expert, it's also simply practical because it's a number that relates to something specific and real rather than something arbitrary. As I said, you can see the effects of this on the screen, so it doesn't even need the hardware to measure it. In contrast, you need a lookup table to convert the visible screen pixel shift to the WS with the current numbering system.

[ljbk]

One thing is the DE signal but another will be the Shifter updating the RGB signals or not.

I can test this (I am monitoring the RGB pins) if there is data in the first word of the 160-byte line.

May i suggest that you use BEEMOVE0.PRG with a working WS.
There you can select the left shift with the LEFT/RIGHT arrows and so you can monitor the DE and RGB signals of one of the 195 or 196 lines of 160 bytes affected by the variable shift.

Paulo.

[troed]

While I agree the DL number is more meaningful the the HW expert, it's also simply practical because it's a number that relates to something specific and real rather than something arbitrary.

- W2 is 3 cycles DE to LOAD latency (wakeup 2 in ijor's program)
- W4 is 4 cycles DE to LOAD latency (wakeup 2 in ijor's program)
- W3 is 5 cycles DE to LOAD latency (wakeup 1 in ijor's program)
- W1 is 6 cycles DE to LOAD latency (wakeup 1 in ijor's program)

Actually it does help out anyone creating synctables - in my opinion. According to my experience:

WS1 is the easiest to find a stable combination for, followed by WS3. These are the old "WU1" and I mostly treat them as one.
WS4 comes next, and WS2 is the one that I've found it most difficult to find combinations that work fine with.

So, any syncscroll combination hunting should be done in reverse Start with WS2. Whatever you find working there has a high likelyhood of working in the others as well. Basically, follow the DLx naming top down.

(This with hi/lo stabilizers, I haven't looked as much at ULM but I'm not sure it's as clear cut there)

Now if my experience holds true for others as well then I guess this is causative. There's a common factor between DLx and the reason for why some syncline combinations aren't stable (an area Paolo has expertise in, I've only ever seen the issues and found combinations that don't exhibit them)

Next up - what's the difference between WS2 cold, WS2 warming and WS2 warm?

/Troed

[Dio]

Next up - what's the difference between WS2 cold, WS2 warming and WS2 warm?

I don't think we will get any visibility on that with the analyser.

The cases are almost certainly timing dependent inside the shifter, exactly when the resolution register change takes effect and how it modifies:
- the loading of the staging registers
- the timing of the staging -> shift register transfer
- the shift register configuration or clocking
- the timing of the shift register output latch, if there is one
etc.

If we can see any 'warmup' cases which only depend on syncmode, then I can look at those. But as I understand it all the problem cases are on the resolution register only, and I suspect all those are inside the shifter. (Although the actual change in timing may not be entirely sourced there, since the timing 'problem' could be signals output by Glue or MMU shifting a few ns one way or the other and be pushing a signal across some setup or hold time boundary).

I think for better visibility on that we need at least the schematic of the Shifter. If I have time enough to plan, next time I'm going to be in Silicon Valley I'm going to see if the computing museum has it (since I heard Leonard Tramiel donated a lot of old Atari stuff to them). If not, contacting Leonard is probably the only chance to get it, unless it miraculously turns up somewhere.

[ljbk]

So, any syncscroll combination hunting should be done in reverse Start with WS2. Whatever you find working there has a high likelyhood of working in the others as well.

But we have already seen that this does not hold as i have no problems with a "cold" WS2/DL3 using the ULM stabilizer and you have one combination leading to problems and as far as i can remember from your posts you had no problems with WS4/DL4.

@Dio

Yes, i assume that any of the Shifter substates are only internal to the chip (bands, warming, disk drive effect, spectrum 512 funny dots, interleaved shifting ...) and so are not analysable from the outside except on the RGB consequences. This is also why i don't think that there is a SW solution to detect any of those.

Paulo.

[Dio]

May i suggest that you use BEEMOVE0.PRG with a working WS.
There you can select the left shift with the LEFT/RIGHT arrows and so you can monitor the DE and RGB signals of one of the 195 or 196 lines of 160 bytes affected by the variable shift.

Doesn't BEEMOVE0 do it by syncscrolling and leaving words in the shifter, rather than the 160-NTSC case?

[troed]

Interesting to see you can have a WS3 cold where all works and a WS3 cold that behaves like WS1 ....
Did you see any difference with BEEMOVE (bands / no bands) ?

Here we go! The following test suite is sequential. There are _many_ WS3 boots that I didn't document, but almost all of the other ones are as they happened (I think I skipped a few WS2 as well). The tests were done inside of ~30 minutes and most of them are probably "cold" although I stopped claiming so when I wasn't sure anymore. There are at least three tries from every WS.

Terminology: First line is the BEESCRLT4 test, ESC means I switched unstabilizer to get a "good picture". Second line is BEEMOVE0, where bitplan fail indicates -4 failure and banded means normal picture but with every other 16 pixel column black.

Code: Select all

BEESCRLT: WS3 cold: -4 fail (ESC)
BEEMOVE: WS3 cold: normal, bitplane fail, normal, normal (0,-4,-8,-12)

WS1 cold: -4 fail (ESC)
WS1 cold: normal, bitplane fail, normal, normal

WS2 cold: all ok (ESC)
WS2 cold: normal, normal, normal, normal

and the very next boot:
WS2 cold: all ok (default stabilizer)
WS2 cold: normal, bitplane fail, banded, banded

WS3 cold: -4 fail (ESC)
WS3 cold: normal, bitplane fail, normal, normal

WS3 cold: all ok (default)
WS3 cold: normal, bitplane fail, banded, banded

WS2 cold?: all ok (default stabilizer)
WS2 cold?: normal, normal, normal, normal

WS4: all ok (ESC)
WS4: normal, normal, normal, normal

WS1: -4 fail (default)
WS1: normal, bitplane fail, banded, banded

WS2: all ok (default stabilizer)
WS2: normal, bitplane fail, banded, banded

WS3: all ok (default)
WS3: normal, bitplane fail, banded, banded

WS4: all ok (default)
WS4: normal, bitplane fail, banded, banded
(and here I remembered about the unstable sync combination - none found in any direction)

WS2: all ok (default stabilizer)
WS2: normal, normal, normal, normal
(no unstable combination in beescrt)

WS4: all ok (default)
WS4: normal, bitplane fail, banded, banded

WS2: all ok (default stabilizer)
WS2: normal, bitplane fail, banded, banded

WS1: -4 fail (ESC)
WS1: normal, bitplane fail, normal, normal

What I think stands out is that there's seemingly no relation between which unstabilizer worked in BEESCRLT and whether things looked ok or fail/banded in BEEMOVE0 - and the same WS with consecutive boots can have either combination.

Actually just as I wrote this I realized there's no WS3 -4 fail with banded -8/-12 in the test - so I tried a few more times but still couldn't produce one. What I did get was a WS3 with a few problematic sync combinations. Assuming I'm in "warming":

MH32 66 26 62 00 44
Flashes briefly then stabilizes but with every other line shifted a single pixel (not the normal "striped" which is 16)
Only when coming from 62 62 62 02 64
Flashes briefly as MU32 as well but then there's no every other line shift, but still needs to come from the same direction.
(TAB works to switch between the "every other pixel" on and off)

The combination between MU32 64 26 26 26 26 and MU30 66 26 46 02 44
Bitplane shift + banded

With the above WS3 I also got the first "normal, normal, normal, normal" result in BEEMOVE0.

(And now I unfortunately need to end this evening's testing)

/Troed

[ljbk]

May i suggest that you use BEEMOVE0.PRG with a working WS.
There you can select the left shift with the LEFT/RIGHT arrows and so you can monitor the DE and RGB signals of one of the 195 or 196 lines of 160 bytes affected by the variable shift.

Doesn't BEEMOVE0 do it by syncscrolling and leaving words in the shifter, rather than the 160-NTSC case?

Yes, but i tought you wanted to see a variable delay between the DE starting and the RGB signals moving from "border color".
I am sure that then the logic analyser will allow you to see a different time with all the 4 shifts.
If by any chance you get WS1/DL6 then you will notice that the -4 shift does not work and you get the 0 ("normal") case unlike the other WS not leading to bands with that program.
Finally you may have the chance also to observ a "banded" line with different starts like it occurs for the WS2 banded case where the -8 and -12 case lead to bands at different shift positions with my machine.
You can also use TOSHIFT available in the full shift package some pages ago that is equal to BEEMOVE except you return to TOS like that and so you can test any line you like.

Also the simple 162 bytes line with any WS different from WS1/DL6 will start the bitmap 4 pixels earlier so you might also analyse that.

But may be i misunderstood what you want.


Paulo.

[mc6809e]

If we can see any 'warmup' cases which only depend on syncmode, then I can look at those. But as I understand it all the problem cases are on the resolution register only, and I suspect all those are inside the shifter. (Although the actual change in timing may not be entirely sourced there, since the timing 'problem' could be signals output by Glue or MMU shifting a few ns one way or the other and be pushing a signal across some setup or hold time boundary).

Nice work, Dio. Really enjoy reading these discussions.

Looking at the schematics I see SHIFTER takes it's internal timing from the 32MHz clock and is responsible for giving the MMU its 16 MHz clock which then gives GLUE its 8 MHz clock.

If on power up SHIFTER's internal logic begins on a 32MHz clock boundary, then it must be in one of four possible states relative to GLUE's clock since 32MHz/8MHz = 4 and in one of two possible states with respect to MMU's clock. Perhaps these are the four wakeup states.

Sound about right?

It's too bad there isn't a reset pin on SHIFTER to force its internals to be in phase with MMU and GLUE or a spare couple of XORs on the board to selectively invert the 16MHz and 8MHz clocks.

[ljbk]

Interesting to see you can have a WS3 cold where all works and a WS3 cold that behaves like WS1 ....
Did you see any difference with BEEMOVE (bands / no bands) ?

Here we go! The following test suite is sequential. There are _many_ WS3 boots that I didn't document, but almost all of the other ones are as they happened (I think I skipped a few WS2 as well). The tests were done inside of ~30 minutes and most of them are probably "cold" although I stopped claiming so when I wasn't sure anymore. There are at least three tries from every WS.

Terminology: First line is the BEESCRLT4 test, ESC means I switched unstabilizer to get a "good picture". Second line is BEEMOVE0, where bitplan fail indicates -4 failure and banded means normal picture but with every other 16 pixel column black.

Code: Select all

BEESCRLT: WS3 cold: -4 fail (ESC)
BEEMOVE: WS3 cold: normal, bitplane fail, normal, normal (0,-4,-8,-12)

WS1 cold: -4 fail (ESC)
WS1 cold: normal, bitplane fail, normal, normal

WS2 cold: all ok (ESC)
WS2 cold: normal, normal, normal, normal

and the very next boot:
WS2 cold: all ok (default stabilizer)
WS2 cold: normal, bitplane fail, banded, banded

WS3 cold: -4 fail (ESC)
WS3 cold: normal, bitplane fail, normal, normal

WS3 cold: all ok (default)
WS3 cold: normal, bitplane fail, banded, banded

WS2 cold?: all ok (default stabilizer)
WS2 cold?: normal, normal, normal, normal

WS4: all ok (ESC)
WS4: normal, normal, normal, normal

WS1: -4 fail (default)
WS1: normal, bitplane fail, banded, banded

WS2: all ok (default stabilizer)
WS2: normal, bitplane fail, banded, banded

WS3: all ok (default)
WS3: normal, bitplane fail, banded, banded

WS4: all ok (default)
WS4: normal, bitplane fail, banded, banded
(and here I remembered about the unstable sync combination - none found in any direction)

WS2: all ok (default stabilizer)
WS2: normal, normal, normal, normal
(no unstable combination in beescrt)

WS4: all ok (default)
WS4: normal, bitplane fail, banded, banded

WS2: all ok (default stabilizer)
WS2: normal, bitplane fail, banded, banded

WS1: -4 fail (ESC)
WS1: normal, bitplane fail, normal, normal

What I think stands out is that there's seemingly no relation between which unstabilizer worked in BEESCRLT and whether things looked ok or fail/banded in BEEMOVE0 - and the same WS with consecutive boots can have either combination.

Actually just as I wrote this I realized there's no WS3 -4 fail with banded -8/-12 in the test - so I tried a few more times but still couldn't produce one. What I did get was a WS3 with a few problematic sync combinations. Assuming I'm in "warming":

MH32 66 26 62 00 44
Flashes briefly then stabilizes but with every other line shifted a single pixel (not the normal "striped" which is 16)
Only when coming from 62 62 62 02 64
Flashes briefly as MU32 as well but then there's no every other line shift, but still needs to come from the same direction.
(TAB works to switch between the "every other pixel" on and off)

The combination between MU32 64 26 26 26 26 and MU30 66 26 46 02 44
Bitplane shift + banded

With the above WS3 I also got the first "normal, normal, normal, normal" result in BEEMOVE0.

(And now I unfortunately need to end this evening's testing)

/Troed

Hi !

First of all many thanks for your tests.
From what i can read and comment below, your results are identical to mine except you can have a WS3 case behaving as WS1. This i could not reproduce because it is terribly dificult to get WS3 with my machine. I only managed the WS3 normal and the WS3 banded case.
Using the ULM stabilizer aparently does not change that.

Code: Select all

BEESCRLT: WS3 cold: -4 fail (ESC)
BEEMOVE: WS3 cold: normal, bitplane fail, normal, normal (0,-4,-8,-12)

=> This is WS3 behaving as WS1


WS1 cold: -4 fail (ESC)
WS1 cold: normal, bitplane fail, normal, normal

=> WS1 as with my STF


WS2 cold: all ok (ESC)
WS2 cold: normal, normal, normal, normal

=> WS2 normal / may need ESC to use the LO/MED/LO


and the very next boot:
WS2 cold: all ok (default stabilizer)
WS2 cold: normal, bitplane fail, banded, banded

=> WS2 banded case (not only you have bitplane fail but also shift fail)


WS3 cold: -4 fail (ESC)
WS3 cold: normal, bitplane fail, normal, normal

=> Again, this is WS3 behaving as WS1


WS3 cold: all ok (default)
WS3 cold: normal, bitplane fail, banded, banded

=> WS3 banded case (not only you have bitplane fail but also shift fail)


WS2 cold?: all ok (default stabilizer)
WS2 cold?: normal, normal, normal, normal

=> WS2 normal / may need ESC to use the LO/MED/LO


WS4: all ok (ESC)
WS4: normal, normal, normal, normal

=> WS4 normal / may need ESC to use the LO/MED/LO


WS1: -4 fail (default)
WS1: normal, bitplane fail, banded, banded

=> WS1 as with my STF


WS2: all ok (default stabilizer)
WS2: normal, bitplane fail, banded, banded

=> WS2 banded case (not only you have bitplane fail but also shift fail)


WS3: all ok (default)
WS3: normal, bitplane fail, banded, banded

=> WS3 banded case (not only you have bitplane fail but also shift fail)


WS4: all ok (default)
WS4: normal, bitplane fail, banded, banded
(and here I remembered about the unstable sync combination - none found in any direction)

=> WS4 banded case (not only you have bitplane fail but also shift fail)


WS2: all ok (default stabilizer)
WS2: normal, normal, normal, normal
(no unstable combination in beescrt)

=> WS2 normal / may need ESC to use the LO/MED/LO


WS4: all ok (default)
WS4: normal, bitplane fail, banded, banded

=> WS4 banded case (not only you have bitplane fail but also shift fail)


WS2: all ok (default stabilizer)
WS2: normal, bitplane fail, banded, banded

=> WS2 banded case (not only you have bitplane fail but also shift fail)


WS1: -4 fail (ESC)
WS1: normal, bitplane fail, normal, normal

=> WS1 as with my STF

Any banded state (BEEMOVE0: normal(0 shift), bitplane fail(0 shift), banded, banded) will work with the default unstabilizer LO/HI/LO.
"Normal" state (BEEMOVE0: normal, normal, normal, normal) may work with the default unstabilizer but works for sure using ESCAPE => LO/MD/LO unstabilizer.
Non working cases (BEEMOVE0: normal, bitplane fail, normal, normal) will not work like WS1.

So excepting the WS3 as WS1 case, and some sporadic sync unstable combinations, we have 3 STF machines, from 3 different HW revisions, with the same behaviour.
That is good.


You also have some unstable sync scrolling combinations and even if it might be related to warming, this is something that we might be able to improve especially if we can isolate them.
Also it is obvious that the ULM stabilizer did not solve all your warming problems if any.
I will try to produce something to help in getting info about those combinations or try to solve these cases.



Thanks again,
Paulo.

[Dio]

If on power up SHIFTER's internal logic begins on a 32MHz clock boundary, then it must be in one of four possible states relative to GLUE's clock since 32MHz/8MHz = 4 and in one of two possible states with respect to MMU's clock. Perhaps these are the four wakeup states.

There could be any number, depending on how complex the state machine inside the Shifter is, and they'd be multiplicative with the Glue-MMU phase discrepancies.

My suspicion, and it's no more than that, is that most of the timing in the Shifter is actually driven by /LOAD and /CS - so, from outside, rather than in - and only the shift registers are using the 32MHz clock. That's hinted at by the way the Shifter is timing sensitive (from all the cold/warm stuff) and that there doesn't appear to be a huge multiplication in states - the Spectrum 512 black dots issue is the only one which may seem likely to be a fixed problem, and even that could be a marginal timing or warmup issue.

It's too bad there isn't a reset pin on SHIFTER to force its internals to be in phase with MMU and GLUE or a spare couple of XORs on the board to selectively invert the 16MHz and 8MHz clocks.

I do wonder if the Shifter can be reset by some combination of external signals. The VHDL implementations do some of that at boot time. One thing I am very tempted to do if I can decide which of my STs I am prepared to mangle is to cut the DE pin and see what's then different. I don't quite see what purpose it serves.

[troed]

But we have already seen that this does not hold as i have no problems with a "cold" WS2/DL3 using the ULM stabilizer and you have one combination leading to problems and as far as i can remember from your posts you had no problems with WS4/DL4.

Well, sort of. The synctable I have for hi/lo (which is very stable - it's tested working in WS1/WS2/WS3/WS4 cold & warm) didn't need changes for WS1/WS3 ULM but did need quite a few for WS2/WS4 ULM (which then cascaded back into WS3). With my usage, but we use stabilizers differently, it seems I need to go through more combinations to find stable ones with ULM. My block list (i.e, combinations that I've tested to not be stable and are thus disallowed by my synctable brute forcer) includes everything from 0 to 20+ combinations for different offsets.

I actually did give up temporarily on one ULM combination after having almost exhausted all possibilites* - however, my block list still included the hi/lo cases which of course it shouldn't so when/if I decide to use ULM instead of hi/lo for my synctable I'm sure I will find a combination that works (even if it means changing which lines I stabilize, split up the synctable for WS1/WS3 vs WS2/WS4 etc).

You also have some unstable sync scrolling combinations and even if it might be related to warming, this is something that we might be able to improve especially if we can isolate them.
Also it is obvious that the ULM stabilizer did not solve all your warming problems if any.

Slightly confusing, yes, but again we don't stabilize the same way. My synctable is stable in cold and warm for all wakestates, but in WS2 and WS4 there's a long phase of "warming" where it's not. With the ULM code I've only seen the combinations unstable for the very very short timeframe just as "warming" became "warm".

I'm currently under the impression that my code would gain compatibility if I switched to using ULM stabilizers instead of hi/lo - something I would've never thought of if you hadn't suggested it

So excepting the WS3 as WS1 case, and some sporadic sync unstable combinations, we have 3 STF machines, from 3 different HW revisions, with the same behaviour.

... and that's what makes this fun

/Troed

*) The ULM block list for that one offset, still in progress, contains at the moment three combinations not working in WS3, four not working in WS4 and 30 (!) not working in WS2.

[Dio]

May i suggest that you use BEEMOVE0.PRG with a working WS.
There you can select the left shift with the LEFT/RIGHT arrows and so you can monitor the DE and RGB signals of one of the 195 or 196 lines of 160 bytes affected by the variable shift.

Doesn't BEEMOVE0 do it by syncscrolling and leaving words in the shifter, rather than the 160-NTSC case?

Yes, but i tought you wanted to see a variable delay between the DE starting and the RGB signals moving from "border color".

Until we understand the very simplest things there's no point in trying to look at the complicated ones.

If -4 doesn't work in WS1, we can analyse a very case where it should, and where I can clearly see all the signals apparently behaving like it should, the 160-NTSC-on-PAL case. No messing about with resolution registers and word tweaks necessary - this is just all determined by one register in Glue.

[ljbk]

What I did get was a WS3 with a few problematic sync combinations. Assuming I'm in "warming":

MH32 66 26 62 00 44
Flashes briefly then stabilizes but with every other line shifted a single pixel (not the normal "striped" which is 16)
Only when coming from 62 62 62 02 64
Flashes briefly as MU32 as well but then there's no every other line shift, but still needs to come from the same direction.
(TAB works to switch between the "every other pixel" on and off)

The combination between MU32 64 26 26 26 26 and MU30 66 26 46 02 44
Bitplane shift + banded

1st case:

66 26 62 00 44 is not a newcomer but this time you say that it is only from one direction (62 62 62 02 64):

MH32 66 26 62 00 44
160 0 158 80 206 = 604 $5C

MH33 62 62 62 02 64
158 158 158 184 204 = 862 $5E

So again we have the line type 80 handling 3 words or a -12 shift and the result is nok.
The 3 words or a -12 shift is the worst case to handle as only a normally working stabilizer can control it. The 206 line should have solved it.

Second case:

MU32 64 26 26 26 26
204 0 0 0 0 = 204 $CC

MU31 66 26 46 46 04
160 0 162 162 230 $CA

MU30 66 26 46 02 44
160 0 162 184 206 $C8

Did this happen when coming from $C8 to $CA or from $CC to $CA or in both cases ?
Anyway, this is one of the few cases (2) where the final stabilizer is on a 230 bytes line.

The other case you refered on the other post (66 66 62 00 64) did not appear this time which means that this does not always happen or is related to the use of ULM stabilizer.


Paulo.

[ljbk]

That's hinted at by the way the Shifter is timing sensitive (from all the cold/warm stuff) and that there doesn't appear to be a huge multiplication in states - the Spectrum 512 black dots issue is the only one which may seem likely to be a fixed problem, and even that could be a marginal timing or warmup issue.

Experience shows that the Spectrum problems do no go with warming. They can present also a warming phase: flashing dots. But the warmed phase will correspond to fixed wrongly coloured dots no matter which WSx/DLy is involved.

Paulo.

[ljbk]

What I did get was a WS3 with a few problematic sync combinations. Assuming I'm in "warming":

MH32 66 26 62 00 44
Flashes briefly then stabilizes but with every other line shifted a single pixel (not the normal "striped" which is 16)
Only when coming from 62 62 62 02 64
Flashes briefly as MU32 as well but then there's no every other line shift, but still needs to come from the same direction.
(TAB works to switch between the "every other pixel" on and off)

The combination between MU32 64 26 26 26 26 and MU30 66 26 46 02 44
Bitplane shift + banded

1st case:

66 26 62 00 44 is not a newcomer but this time you say that it is only from one direction (62 62 62 02 64):

MH32 66 26 62 00 44
160 0 158 80 206 = 604 $5C

MH33 62 62 62 02 64
158 158 158 184 204 = 862 $5E

So again we have the line type 80 handling 3 words or a -12 shift and the result is nok.
The 3 words or a -12 shift is the worst case to handle as only a normally working stabilizer can control it. The 206 line should have solved it.

Second case:

MU32 64 26 26 26 26
204 0 0 0 0 = 204 $CC

MU31 66 26 46 46 04
160 0 162 162 230 $CA

MU30 66 26 46 02 44
160 0 162 184 206 $C8

Did this happen when coming from $C8 to $CA or from $CC to $CA or in both cases ?
Anyway, this is one of the few cases (2) where the final stabilizer is on a 230 bytes line.

The other case you refered on the other post (66 66 62 00 64) did not appear this time which means that this does not always happen or is related to the use of ULM stabilizer.


Paulo.

Hi !

Here is a possible work around for failing combinations: beescrs4.prg

It is not fully tested yet but the idea is to add an extra stabilizer on any open left border.

I tested it with a "banded" WS2/DL3 and i got:
1- nothing working with ESCAPE as expected;
2- everything working with HH (default unstab and stab);
3- one combination failing with HU (default unstab and ULM stab);

The failing combination, in both directions, is exactly the one you had for the 2nd case (above):

HU20 66 26 46 02 44
HU21 66 26 46 46 04 <= FAILING
HU22 64 26 26 26 26

So in that case the ULM stabilizer is not helping at all.

I also got a WS2/DL3 "normal" case in a warmed situation i assume as the fullscreen display was working correctly.
All 4 cases HH HU MH and MU work for all combinations.

I have to do some more tests with some more WS to get a better idea.
You can do those as well if you wish.

Paulo.

Edit:
Today i could only manage 3 different WS cases:
WS1/DL6 "banded" case => no sync combination problems with HH or HU but -4 does not work, Mx(ESCAPE) "nothing" works;
WS2/DL3 "normal" case => as above works for all cases;
WS2/DL3 "banded" case => as above except i don't have that non working combination anymore => probably the system has warmed;
And the problem is that for this byte offset combination, there is no other line combination than 160,0,162,162,230 with a 2xx line as the stabilizer one with 5 lines ...

[troed]

If -4 doesn't work in WS1, we can analyse a very case where it should, and where I can clearly see all the signals apparently behaving like it should, the 160-NTSC-on-PAL case. No messing about with resolution registers and word tweaks necessary - this is just all determined by one register in Glue.

Well. As I've understood it synclin0 contains a regular 160 and an early start + short right which is the NTSC position 160 - right? I cannot see a sideways movement with synclin0 at least when switching between those - no matter if I'm in WS1, WS3 or WS4 (which I think are the ones I tested). Maybe I'm misunderstanding something.

I have to do some more tests with some more WS to get a better idea.
You can do those as well if you wish.

Sorry for not having tested yet - it's now on an image I will test other things on as well tomorrow.

I've rewritten my own syncscroll to have separate tables for STE/ST wk1/ST wk2. I'm hoping not having to divide the two wakeups into four wakestates - the substates are mostly similar. I have also moved to ULM stabilizers and will verify for real whether I consider them to give better results.

Thus I'll need to test all wakestates and all temperature phases over the next few days anyway ..

[ljbk]

I have to do some more tests with some more WS to get a better idea.
You can do those as well if you wish.

Sorry for not having tested yet - it's now on an image I will test other things on as well tomorrow.

I've rewritten my own syncscroll to have separate tables for STE/ST wk1/ST wk2. I'm hoping not having to divide the two wakeups into four wakestates - the substates are mostly similar. I have also moved to ULM stabilizers and will verify for real whether I consider them to give better results.

Thus I'll need to test all wakestates and all temperature phases over the next few days anyway ..

No problem.
I have been far from this anyway.
I don't think this will be "the" solution.
Two other workarounds are in my mind.
Hope to bring them in soon.


Paulo.

[troed]

Alright, reporting in after having moved over my syncscroll to ULM MID/LO stabilizers, dividing up my synctable for three different cases (WK1**, WK2**, STE - dividing it up into five will be done if need arises) and then clearing (!) my syncline combo blacklist* and recreating it from scratch for ULM instead of regular HI/LO ...

It works. Whereas my previous code worked fine for all wakestates (WS1-4) and both cold and warm there was an intermediate phase, "warming", where two wakestates (WS2/4) were extremely irregular and the syncline combos produced unstable results. Since that "warming" phase appeared after ~30 minutes and persisted for another ~30 minutes it was simply unsatisfactory for usage.

Result:

The ULM version, while I'm still doing some final tests, now works for all wakestates (WS1-4) and both cold and warm. Additionally, there doesn't seem to be a long "warming" phase for WS2 and WS4 which is why I did this - and it seems to have been a success. There is an extremely short (1-2 minutes) phase after about an hour where one combination is temporarily unstable but 1-2 minutes compared to 30 is well worth the work.

Additional findings:

In WS2 (which is by far the most complicated WS to find stable combinations for***) one of my synclines isn't even working correctly in some combinations - the switch seems to fail. I will investigate why this happened when changed stabilizers (it's not a stabilized line) and how later. Can leftover words in the Shifter push the needed timing? [edit: Actually, after counting nops I might not switch where I thought I was, don't read too much into this]

In WS1 several combinations lead to the _next_ line, a normal line, being shifted -4. However, the state doesn't persist. I now understand what Paolo means - WS1 simply doesn't like to become unstable, the Shifter is able to clear itself without the need for a stabilizer at all.

Speculation:

So why am I getting a different result with MID/LO compared to HI/LO? I'm working with the assumption that stabilizers "clear" leftover words in the Shifter so as to make things easy for the following line. A HI/LO stabilizer is better (clears more incoming words?) than a MID/LO stabilizer, however, it's also more sensitive and will clear a different amount (?) of words depending on temperature. The same applies to MID/LO, but since it didn't clear as many from the beginning there are fewer ways for it to be different due to temperature.

Conceptual model - most definitely not reality: A HI/LO stabilizer can take care of 1,2,3 incoming words - but only 1 when cold, 1,2 when warming and 1,2,3 when warm. A MID/LO can take care of 1,2 incoming words, 1 when cold and 1,2 when warm.

The above would lead to exactly what I see - it's much harder to find stable syncline combos when working with MID/LO stabilizers, but once they're found they're more stable throughout the cold->warming->warm phases.

(It also makes me wonder if even better results would be gotten if no stabilizers are used at all for synclines used in a sync scroller. More difficult to make it stable, less things that can change .. )

Very often a combination that leads to a stable bitplane error in WS2 cold (as an example) leads to a striped (every other line) error or cycling (different words every VBL) in WS2 warm. This is partly what makes me think of "the number of incoming words" in the conceptual model. I'm actually hoping it's possible for the number of incoming words in the Shifter to "push" timings needed for a syncline switch since that would open up the possibility to detect whether it's cold or warm ...


Caveat, as always: This is all based on tests on one single STF.

/Troed

*) My synctable finder does not have the knowledge Paolo has on what words will stay in the Shifter depending on what words came in on a line. It thus simply brute forces all combinations leading to the desired offset and the "blacklist" is a list of all combinations that do not lead to a stable result.

**) I use WKx to denominate the previous known wakeup states, also sometimes called "cold" and "warm" (Ijor's program). Thanks to Paolo's work we now know WK1 to be WS1/WS3 and WK2 to be WS2/4 and shouldn't be referred to as temperature

***) My WS1/WS3 blacklist contains 30 combinations. The list for WS2/WS4 contains 137. [The actual numbers are not interesting, the relation between them is]

[Dio]

In WS1 several combinations lead to the _next_ line, a normal line, being shifted -4. However, the state doesn't persist. I now understand what Paolo means - WS1 simply doesn't like to become unstable, the Shifter is able to clear itself without the need for a stabilizer at all.

That maybe fits in with one theory I have: one guess is that some reset or synchronisation condition for the Shifter is DE with no following LOAD, or LOAD seen with no recent DE. WS1 is DL6, the one with the longest gap between DE and LOAD (6 cycles) and there will always be two clear LOADs after DE is deasserted...

[troed]

That maybe fits in with one theory I have: one guess is that some reset or synchronisation condition for the Shifter is DE with no following LOAD, or LOAD seen with no recent DE. WS1 is DL6, the one with the longest gap between DE and LOAD (6 cycles) and there will always be two clear LOADs after DE is deasserted...

It also fits with my experience from which wakestates are the most "unstable" -> WS2, WS4, WS3, WS1 which maps directly to your measurements of DL3, DL4, DL5 and DL6.

One thing that have always intrigued me is how, who and why (well .. ) someone came up with the stabilizer for fullscreen lines. I did an investigation here on the forum a few years ago, from memory: TNT Crew made the first left border removal, unstabilized. They were followed by the first fullscreen, by Omega, also unstabilized. Two weeks later TCB released their "TV snow" screen in the Swedish New Year Demo 1 where they had removed the left border (and upper, and right) - with stabilizer.

However, that was just a week before the release of the Union Demo, and Level 16's first stable fullscreen. I've compared the fullscreen code in the TCB screen and Level 16's code from the Union Demo and it's identical. Since TCB obviously knew how to remove the lower border it's my opinion that they got the code from Level 16, being members of the Union, and purposely didn't make the SNYD1 screen a fullscreen since it was Level 16's stuff to release.

So, I'm assuming the idea and implementation of the first stabilizer came from Ilja/L16. I would love to know the answer to how. Was it pure random luck when playing with border removal? A mistake with code for two left border removals on one scanline? Or was knowledge about the workings of the Shifter (from Atari?) involved?

[ljbk]

Hi !

The file i attach replaces the 22th of August version of BEESCRS4.PRG .
The difference between the two files is that now the extra stabilizer is not introduced for 230 bytes lines and so it affects only 80 bytes, 184 bytes and 186 bytes lines.
As 186 bytes lines are not used, only the 80 bytes and 184 bytes will have an extra stabilizer when compared to BEESCRT4.PRG .
This should avoid the problem i had with WS2 "banded" case.

I tested this program with a cold WS2 where the fullscreen display was failing with and without the disquette inside the disk drive (in one case (with it) less than in the other).
In the case where the fullscreen display was failing the most not even the use of the ULM stabilizer would solve all cases. The new BEESCRS4.PRG seems a little more stable than BEESCRT4.PRG but not by a big margin and the M U (medium unstabilizer / ULM stabilizer) case is the best one.
After a while as the warming progresses, the case with the diquette in shows no more errors.
After another while we have no more errors either with or without the disquette in the disk drive, with either stabilizer/unstabilizer combination and with any of the two programs.
This again confirms that these line combinations failures are only caused by the warming procress that in my case also causes the fullscreen display to fail and are not related directly to the 4 bit scroll feature.


Paulo.

[ljbk]

Hi again !

So this is my latest attempt and probably the last one to try to fight these "warming" cases and to improve the reliability of this 4 bit scroll feature.
The idea with this new set of programs is to reverse-unstabilize on the first line of the next frame the unstabilization we made on the 6th line of the current frame. This should ensure that when we get to the classic sync scrolling line combinations, the Shifter has its buffers empty and so we are working as if we handled a classic sync scrolling.
Two versions are available:
- BEESCSU4.PRG version with extra stabilizer for 80 bytes lines and 184 bytes lines;
- BEESCTU4.PRG normal version as T plus this extra feature;

These U versions should behave better than the others as they remove the effects of the 4 bit shift to the sync scrolling line combinations. But if the problem is with the stabilizer (any of the two) during the warming fases, affecting the fullscreen display then this should not solve it.


Paulo.