horizontal scrolling on ST

[ljbk]

Hi !

Thanks for reporting !
I will be far from my STF until tuesday so nothing new to be expected until then.

Paulo.

[troed]

Thanks for reporting !

But of course. I couldn't stay away - SYNC (heh) technology has always been one of my favourite playthings on the ST

So, I just rewrote a syncscroller that showed the "cold,warming,warm" issue in WS2 I described earlier to use the ULM stabilizer instead. I had to change a few combinations that became unstable in WS4 compared to HI/LO (but in WS1/WS3 no changes would've been needed. [edit: a few more needed changes in WS2 also]). Of course, the machine is now very warm having been on the whole day.

I will thus try to get into "WS2 cold" tomorrow morning and see whether the ULM version is stable, and if so whether it's stable throughout the "warming" phase as well. (The combinations I used to use were stable in cold and warm but not in between)

With regards to your bee scroller and my WS3 tests - that might be something positive. It could indicate the -4 issue not being strictly due to WS1 but yet another thing - and that other thing might be detectable and handled once understood I must confess the multitude of different test programs posted in the thread sometimes gets confusing so if there's something specific you'd like me to try then just let me know.

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

Of course, you're right. I just picked up on the shifter and I have no idea whether that's really the case. I'm already worried about killing my STF with all the power cycling and will not try artificial cooling of the chips though

[troed]

I'm no longer sure about providing reliable input already tomorrow Or maybe I already have.

As I wrote above, when going from hi/lo stabilizers to ULM I needed no changes to my existing synctable for WS1 and WS3. I did need to make changes for WS4, which I did. Once I then got into WS2 (assumed to be "warm" although the computer had been off for between 30-60 minutes) I realized I needed yet a few more changes to the synctable combinations. I then got back to WS3 and saw that two of those changes had now affected it - and once those were done and I was back yet again to WS2 I needed to fix those same combinations and ...

Uh. I'm used to (hi/lo stabilizer) fixing WS1/WS3 (old "cold" wakeup) and once that's done I can fix WS2/WS4 (old "warm" wakeup) and so far I've never had to go back and re-fix WS1/WS3 again. So - ULM stabilizers seem more complicated compared to hi/lo for syncscroll purposes.

HOWEVER - and that's the input I maybe already have - between fixing WS2 the first time and then going back to it one combination that I didn't need fixing the first time was suddenly unstable. It's possible the machine was at the end of "warming" first time around and is now "warm". If so, ULM stabilizers didn't help - at least not in my case. They might of course do the trick for Paolo's 4-bit scrolling purposes.

(For hi/lo stabilizers I have a single synctable for all wakestates. I'm leaning towards being forced to have [at least] two if I want to use ULM stabilizers - one for WS1/WS3 and one for WS2/WS4. I think)

[troed]

Alright, my last update on ULM stabilizers and sync scrolling Let's await Paolo getting back to his computer and those findings.

What happened here was that I kept trying finding combinations that worked in the different wakestates, but after having gotten all but one working again in WS2 just now I power cycled into WS1, where everything worked, and immediately back into WS2 again. No time for any cooling off etc - and now three combinations didn't work (and the one that was in common with last WS2 boot failed differently).

So, my conclusion would be that on my machine and for syncscroll combos ULM stabilizers are not stable enough

[troed]

Alright, my last update on ULM stabilizers and sync scrolling

I lied! But I think this post will be worth it

Caveat: All findings, except where noted, are based on _one_ boot from WS2 cold, to warming, to warm. On one STF.

edit: Update with WS4, WS3 and WS1 at the bottom.

This morning I booted my STF into WS3 as usual. Tested my hi/lo synscroll, all working. Power cycled into WS2 after two tries*, proceeded to test first hi/lo - all working - and then the work I had done with ULM stabilizers yesterday where one position out of the 20 (side scroller, 320 pix) had an error. I noted the type of error (bitplane shift) being different from yesterday's "striped" (every other line shifted) but besides that all combinations worked. I will call this "all stable" for ULM below.

Note: This was the state during all my work yesterday except after having booted into WS1 and back into WS2 where two other combinations suddenly failed and I declared ULM stabilizers "too unstable". That caveat still holds - I think they're affected by yet another sub state!

Test time log:

0 minutes: Cold. WS3, WS2 hi/lo and WS2 ULM are all stable.
20 minutes: Cold. WS2 hi/lo and ULM are all stable.
30 minutes: Cold. WS2 hi/lo and ULM are all stable.
35 minutes: Warming. WS2 hi/lo combinations "flicker" between stable and striped+banded.
35 minutes: Warming. WS2 ULM are all stable.
45 minutes: Warming. WS2 hi/lo combination unstable - and perfectly predictable. One position out of the 20 is striped+banded, the combination after is banded - likely aftereffect.
45 minutes: Warming. WS2 ULM are all stable.
55 minutes: Warming. WS2 ULM are all stable. Oh wait, one position actually showed a hint of flickering.
56 minutes: Warming. WS2 ULM one combination now does flicker between stable and unstable.
60 minutes: Warming. WS2 ULM now has several combinations unstable and/or flickering.
61 minutes: Warm. WS2 ULM screen exited and restarted - all combinations stable and the unstable combination from yesterday is now unstable as it was yesterday when warm (striped) compared to when it was cold today (bitplane shift)
63-67 minutes: Warm. WS2 hi/lo all stable.
68-85 minutes: Warm. WS2 ULM all stable.
85-now minutes: Warm. WS2 hi/lo all stable.

My conclusions follow:

1) ULM is stable during the warming phase - as Paolo thought! However, for a very short time period when going from warming to warm it's not.

2) "cold", "warming" and "warm" might be three discrete states, at least for hi/lo. Already yesterday I noted the coincidence with hi/low during warming when it seemed the instability "moved" position to position [note - the post has been edited. It's actually only one combination, and always the same]. Next time I boot into WS2 cold I will wait until "warming" and see if I can find a combination that work in all three phases.

I will try to do tests with these three phases for other wakestates as well, where I assume since I needed to fix my combinations for WS2 cold vs WS2 warm (hi/lo) I will need to do the same for WS4 as well - although that might be difficult*. WS1 and WS3 are in my experience not as sensitive. ULM, however, gives me a headache. I find it much harder to find stable combinations when using those stabilizers.

/Troed

*) My STF likes to boot into WS3 and WS2 when cold. WS1 and WS4, with the others more rare, when warm.

[This post has been edited due to stupidity: http://en.wikipedia.org/wiki/Off-by-one_error]




edit: I've now done WS4 cold,warming,warm as well. In short:

1) ULM stable throughout - cold,warming & warm.

2) hi/lo (my combinations) stable in cold & warm, but not warming. However, the warming state is not discrete as I perceived it to be in WS2. Depending on when (and whether I had quit to test ULM and back! Interesting) different combinations were flickering back'n'forth or unstable.

edit2: And here's the same for WS3:

1) ULM stable throughout - cold, warming & warm
2) hi/lo stable throughout - cold, warming & warm

However, since I couldn't see any instability at any point with any combination this could also mean that there are no such states for WS3. I will have troubles replicating this for WS1 since I've so far only reached that state with an already warm machine.

edit3: And for completion, WS1:

1) ULM stable throughout - [cold], warming & warm
2) hi/lo stable throughout - [cold], warming & warm

I would assume from the above that the temperature sub state doesn't exist for WS1/WS3. At least not the same as I can readily see with WS2 and WS4. I believe I got into WS1 with the machine "cold" - it has taken it almost 30 minutes to go from cold to warming before and this time it had only been on for 14 minutes. But in theory maybe it was close to "warming". I don't think it changes the conclusion though.

[Steven Seagal]

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


Nicolas

I looked at this cycle-exact option in WinUAE, maybe I don't understand it well but I think it's "cycle-accurate" in the same way that we try and have MFP and blitter cycle-accurate in ST emu. I doubt CPU emu is stopped every 4 cycles. Imagine in how many times instructions like MUL or DIV would complete? And how to come back at the exact same point of the instruction?

As for rendering every 4 cycles, Steem actually does it without trouble but using more CPU in some demos like plazmas or Spectrum pics, it's the way it works: render at every palette change! But it renders in a buffer, of course.

In current build I put a general test when the CPU is writing at the suspicious place, and I see no performance hit.
But there are many "false alerts": even in GEM. It's because the test must be quick (or there's a silly bug...)

[Dio]

It's fine for HW reg writes, I assume that everyone does it that way.

It's as soon as you have to apply it to system memory it's a problem. You have to snoop every memory write and compare with the screen location before deciding if you need to render afterwards. That said, at 8MHz on anything resembling a modern PC it's hardly going to be a really serious drag.

[LaurentS]

That s probably right except perharps for falcon emulation which already needs a fast cpu

Regards

Laurent/Thadoss

[ljbk]

Hi !

Here is a ULM stabilizer version of the 4 bit sysncroller (4 pixel case / program only).


@Troed

Thanks for your tests.
I will need some time to read carefully your posts.
But anyway, the complexity about this feature is that it needs 3 things:
1- perfect stabilizer for all WS and for all their substate variants including cold, warming and wamed phases;
2- a sync scrolling set of combinations that does not introduce unstabilization that can not be solved by the used stabilizer;
3- perfect unstabilizer for all WS and for all their substate variants including cold, warming and wamed phases;

We have seen that (3) seems impossible and so we leave the ESCAPE key for the user to solve this case.
Case (1) seems possible for all warmed cases and it has to be seen if the ULM stabilizer solves the other substates or all.
Case (2) was already improved by removing the 186 and 54 bytes lines and if necessary can be improved by removing other line types, adding some stabilizers to some of them, and possibly increasing the number of sync lines.

Classic sync scroller does not need such a good stabilizer because the Shifter starts the VBL frame "normally" with no shift and 0 words in its buffers and of course it does not need any unstabilizer.

As for the tests programs, the best one to detect the current WS and one of the sub wake up states is BEEMOVE0. It uses the LO/MED/LO unstabilizer which fails in one of the sub wakeup states i called "band".
That "band" substate existing for all WS is aparently imune to cold/warming/warmed phases.
If no "bands" appear, then you are most probably is a "normal" substate condition and there you have cold/warming/warmed phases.
Also as BEEMOVE0 only uses lines 158, 160, 162 and 204, any flickering will not be caused by the syncscroll combinations but by something else.



Paulo.

[Dio]

OK, I ran all Paulo's line lengths (but not the funny modes yet) on my ST in WS1 (which is 6 cycles DE to LOAD latency and the one my machine seems to be very nearly stuck in at the moment) and captured some traces.

I've dozens of PNGs that I won't post yet, but a few interesting things are revealed:
- There are no glitches visible in DE with any mode. It just comes on and goes off as expected for the given line length. It always appears to be on a 4-clock boundary.
- Almost all the traces have no effect on HSYNC or BLANK timing.
- 014 is an exception, see below

The 014 trace is very odd. The first register write hits the shifter resolution register 4 clocks after the end of the (normal) HSYNC. 12 clocks later DE goes high. LOAD starts as normal after 6 clocks. 12 clocks later, BLANK is disabled. So far this is pretty much normal for starting a MONO screen. But 12 clocks after that, HSYNC starts again, which causes DE (and BLANK) to go off 3.5 clocks later. 8 clocks after that point, the second resolution register write hits the shifter. The HSYNC pulse then stays enabled for the rest of the frame and is not disabled until the end of the next 'normal' hsync pulse. The point at which the early HSYNC starts looks to about the place where BLANK is disabled in 50Hz (which also correlates with the timings on your spreadsheet).

This results in gammy colours on my LCD monitor.

This confirms that 014 isn't usable in 'real' code (it might at the outside be dangerous to a CRT, although I'm not enough of a TV expert to know for sure). Useful data though, I think it may enable me to work out the correlation between the counter values in mono and colour modes (which doesn't make too much sense, from just measuring the 70/60/50 timings).

[ljbk]

Thanks Dio.

@ All interested

I captured some fotos of the fullscreen display instability caused by a "cold" WS2 and classic (LO/HI/LO) stabilizer.
This time i had problems without the disquette in the drive and all was ok if the disquette was inside the drive.
It can be vice versa and the black lines/pixels are not frozen as they can move form time to time.
With ULM stabilizer, there are no problems during this phase.
Again, less than 15 minutes after that i had no problems at all.
May be the reason form this fast warming is because we have been having 27ºC inside.



Paulo.

No problem situation:

allok.png

problem with Left Border at cycle 508:

notok_508.png

problem with Left Border at cycle 512:

notok_512.png

problem with Left Border at cycle 004:

notok_004.png

[troed]

Here is a ULM stabilizer version of the 4 bit sysncroller (4 pixel case / program only).

Testing results follow:

0 minutes: WS2 cold, default unstabilizer banded, fixed with ESC. Scroll works with one single syncscroll combination resulting in bitplane shift. (I'm actually surprised you went from hi/lo stabilizers to ULM without affecting more combinations after my own tests .. )
0 minutes: WS3 cold, default banded, fixed with ESC. Every fourth scroll position resulted in shifted bitplans. I assume this is lack of -4
(the above repeated two consecutive boots)
7 minutes: WS3 cold, default unstabilizer ok, scroll ok.
(followed by default banded and scroll fail - i.e, missing -4)
10 minutes: WS3 cold, default banded, scroll ok
11 minutes: WS3 cold, default ok, scroll ok
12 minutes: WS3 cold, default banded, scroll fail
14 minutes: WS1 cold. Uhm. I've been looking for that - over to my own syncscroll tests
[...] back from WS1 test:
64 minutes: WS3 warm, default banded, scroll fail
65 minutes: WS3 warm, default ok, scroll ok

My conclusions from the above:
WS3 can also lack the -4 position with the current code, unrelated to "cold,..."*. It's also not correlated with which unstabilizer works.

*) My syncscroll "cold,warm,warming" tests also indicate that there's no such temperature sub state for WS1 and WS3. With the caveat about the "band" substate you mention below - I have not seen that or at least haven't had a way to detect it.

Thanks for your tests.
I will need some time to read carefully your posts.

I will update the post above with WS1 as well after this post. No temperature instability for hi/lo or ULM.

As for the tests programs, the best one to detect the current WS and one of the sub wake up states is BEEMOVE0. It uses the LO/MED/LO unstabilizer which fails in one of the sub wakeup states i called "band".
That "band" substate existing for all WS is aparently imune to cold/warming/warmed phases.
If no "bands" appear, then you are most probably is a "normal" substate condition and there you have cold/warming/warmed phases.

Alright - I'll put that onto an image on the HxC as well and have it prepared for next time

(Wow - interesting pictures with regards to WS2 cold you just posted. My own sync lines open the left border at 512 and I've seen the "striped+banded" fail many times when testing combinations. I'm unable to have an opinion on the differences with a disk in the drive though since I'm using an HxC SD Floppy Emu when testing)

/Troed

[ljbk]

Thanks for your tests.

I will try to post a better test version later of that scroll program to:
- allow you to test WS1 if you wish;
- find that sync combination or line type causing problems;
- display some usefull info on screen;
- allow to switch stabilizer on the fly;

Hope to have it ready in the next days.

Paulo.

Edit:

@ Troed

Just as a curiosity, what CPU speed does the program posted here (http://www.atari-forum.com/viewtopic.php?f=15&t=24862) returns for your machine ?
This would help in locating your machine in the several HW revisions. Later STs have 8.021247 MHz CPUs. Nicolas STF has a 8.010 MHz CPU. Mine has a 8.0071 MHz CPU. May be some HW revisions are more prone in waking up in WS2 and some more in WS3 and so on ...

[ljbk]

Hi !

Ok, this was faster than i expected.
Here the Test version of this beescroll4.
New things:
- WS1 allows to proceed if you wish;
- TAB switches stabilizer;
- LEFT and RIGHT arrows force scroll direction;
- info displayed on screen:

1st line: unstabilizer(H,M) / stabilizer(H,U) / wake up state(1,2,3,4) / shift(0,1,2,3)
H: high / M: medium / U: ULM
shift 0->0 / 1->-4 / 2->-8 / 3->-12

2nd line: 5 groups of 2 numbers with each pair of numbers meaning a line type for the "classic" sync scrolling combinations and that looks like a tennis 5 set result

So if there is a line combination that does not work with the 4 stabilizer/unstabilizer combinations you can provide me these 10 numbers and i will identify it.
If the bitplanes are in such a mess that you can't read these numbers then please provide the previous and next combination that works using ALT to step and the arrows to select the scroll direction.


Thanks again,
Paulo.

[troed]

Just as a curiosity, what CPU speed does the program posted here (http://www.atari-forum.com/viewtopic.php?f=15&t=24862) returns for your machine ?
This would help in locating your machine in the several HW revisions. Later STs have 8.021247 MHz CPUs. Nicolas STF has a 8.010 MHz CPU. Mine has a 8.0071 MHz CPU. May be some HW revisions are more prone in waking up in WS2 and some more in WS3 and so on ...

I did some quick tests just now. I'll just dump the info here since you can make a lot more sense of it than I

In sequence, during the first few minutes after the first boot of the day:

HWTEST4:
WS3 cold:
VBL Cycles: 160256 (160256@8MHz)
MFP_VBL CLOCK: 8020978 (IF CPU @ 8MHz)
MFPCALC CLOCK: 8020978
TIME_LP CLOCK: 8021204

WS2 cold:
TIME_LP CLOCK: 8021180
(repeated twice, the other values the same)

WS3 cold:
MFP_VBL: 8021101
MFPCALC: 8021101
TIME_LP: 8021180

WS3 cold:
VBL Cycles: 160256 (160256@8MHz)
MFP_VBL CLOCK: 8020978 (IF CPU @ 8MHz)
MFPCALC CLOCK: 8020978
TIME_LP CLOCK: 8021204
(i.e same as the first)

For all of these tests I also ran BEEMOVE0 at each boot:

WS3 cold: -4 fail (all boots)
WS2 cold: 0 works, -4 fail, -8 and -12 banded (both boots)

(where "fail" indicates a bitplane shift and no difference in position)

I hope it offers any insight. I will continue to run these programs whenever I do other tests and document the values and see if there are any differences.

edit: And now I saw your post above. Great! I'll hopefully be able to run more tests later during the day

/Troed

[ljbk]

I did some quick tests just now. I'll just dump the info here since you can make a lot more sense of it than I

In sequence, during the first few minutes after the first boot of the day:

HWTEST4:
WS3 cold:
VBL Cycles: 160256 (160256@8MHz)
MFP_VBL CLOCK: 8020978 (IF CPU @ 8MHz)
MFPCALC CLOCK: 8020978
TIME_LP CLOCK: 8021204

WS2 cold:
TIME_LP CLOCK: 8021180
(repeated twice, the other values the same)

WS3 cold:
MFP_VBL: 8021101
MFPCALC: 8021101
TIME_LP: 8021180

WS3 cold:
VBL Cycles: 160256 (160256@8MHz)
MFP_VBL CLOCK: 8020978 (IF CPU @ 8MHz)
MFPCALC CLOCK: 8020978
TIME_LP CLOCK: 8021204
(i.e same as the first)

Don't bother repeating that for all WS.
This is enough to see that you have a 8.021247 MHz CPU and a 32.084988 MHz crystal next to your Shifter and so a more recent STF.
The small differences are precision problems depending on each case.

For all of these tests I also ran BEEMOVE0 at each boot:

WS3 cold: -4 fail (all boots)
WS2 cold: 0 works, -4 fail, -8 and -12 banded (both boots)

(where "fail" indicates a bitplane shift and no difference in position)

It seems that your WS3 cold is behaving like a WS1 ... This i never got but as it is very dificult for me to get WS3 may be the machine was always warm enough when i got it.
Your WS2 cold is a banded WS2 like i can get but there the LO/HI/LO unstabilizer works correctly and no change seems to occur with warming.


Thanks again,
Paulo.

[troed]

It seems that your WS3 cold is behaving like a WS1 ... This i never got but as it is very dificult for me to get WS3 may be the machine was always warm enough when i got it.

Caveat: Previous testing (yesterday, see above) got me both working and non-working -4 shifts while both in WS3 cold and WS3 warm. They could happen on successive boots right after each other.

(My hope is to see the same in WS1 and that there's a detectable state that causes it of course)

/Troed

[Dio]

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

[troed]

- WS1 allows to proceed if you wish;
- TAB switches stabilizer;
- LEFT and RIGHT arrows force scroll direction;
- info displayed on screen:

1st line: unstabilizer(H,M) / stabilizer(H,U) / wake up state(1,2,3,4) / shift(0,1,2,3)
H: high / M: medium / U: ULM
shift 0->0 / 1->-4 / 2->-8 / 3->-12

2nd line: 5 groups of 2 numbers with each pair of numbers meaning a line type for the "classic" sync scrolling combinations and that looks like a tennis 5 set result

So if there is a line combination that does not work with the 4 stabilizer/unstabilizer combinations you can provide me these 10 numbers and i will identify it.

BEESCRT:
WS3 cold: -4 fails. Nothing makes a difference.

WS3 cold: all works. Switching stabilizer (TAB) doesn't change anything (unstabilizer, ESC, does)

WS2 cold: One sync combo fails - striped. 66 26 62 00 44 (TAB/ESC doesn't fix it)

WS2 cold: One sync combination "flashes" briefly before stabilizing: 66 66 62 00 64
But only if it comes after 64 64 64 64 64 - and not after having switched stabilizer with TAB. I.e, only happens in one scroll direction and with the default stabilizer.

(All tests were done within minutes and I'm confident the mode was "cold" throughout)

/Troed

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

Paulo.

[ljbk]

BEESCRT:
WS3 cold: -4 fails. Nothing makes a difference.

WS3 cold: all works. Switching stabilizer (TAB) doesn't change anything (unstabilizer, ESC, does)

WS2 cold: One sync combo fails - striped. 66 26 62 00 44 (TAB/ESC doesn't fix it)

WS2 cold: One sync combination "flashes" briefly before stabilizing: 66 66 62 00 64
But only if it comes after 64 64 64 64 64 - and not after having switched stabilizer with TAB. I.e, only happens in one scroll direction and with the default stabilizer.

(All tests were done within minutes and I'm confident the mode was "cold" throughout)

/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) ?


66 26 62 00 44
=> 160, 000, 158, 080, 206 = 604 => offset $05C

66 66 62 00 64
=> 160, 160, 158, 080, 204 = 762 => offset $0FA
64 64 64 64 64
=> 204, 204, 204, 204, 204 = 1020 => offset $0FC

The only common stuff between the two cases is the presence of line type 080 that uses the left border.
The rest of the line types should bring no harm.
Lines 0 and 160 are transparent. Line 204 is fundamental. Line 158 and 206 should also be fine.
The curious thing is that you say it fails only if we had the $FC offset before which means a -8 shift and 2 words in the Shifter before.
In the other direction we have $F8 offset and 0 shift and 0 words in the Shifter.
So when reaching line 80 type, we arrive with a shift of -8 and 2 words inisde and that line type transforms it into something the line 204 with stabilizer can not handle correctly at that time.

In the other case, we can come from offset $5E (-12 shift) or $5A (-4 shift). In WS2, the line 158 would transform the -4 into 0 and would leave the -12 unchanged. The line 080 might not like the -12 but should accept the 0. Are you sure the first WS2 cold happens in both scrolling directions ?



Paulo.

[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) ?

My bad - I didn't test BEEMOVE this time around when I got the working/not working WS3s. I will do so next time.

Are you sure the first WS2 cold happens in both scrolling directions ?

Yes - it was actually when making sure of that I noticed the other one. Do note though, the "striped" one was completely unstable. The other one that only flashed (for one VBL I assume) stabilized immediately.

As I've written earlier I had to make quite a few changes to my synctable for WS2 and WS4 (but not WS1 and WS3!) when I went from hi/lo to ULM stabilizers. I assume there's a predictable cause as to which cases differ - although I never researched it but just went hunting for stable combinations. (And where there are much fewer ones for the ULM case - so few that I might need to split my synctable up into one for WS1/3 and one WS2/4)

I also only stabilize lines where the left border has been removed (so, not 54) - which is purely due to historical reasons and "knowledge" we had in 1989 that is most likely completely irrelevant today. But, "don't change stuff that [seems to] work" ..

/Troed

[ljbk]

Are you sure the first WS2 cold happens in both scrolling directions ?

Yes - it was actually when making sure of that I noticed the other one. Do note though, the "striped" one was completely unstable. The other one that only flashed (for one VBL I assume) stabilized immediately.

I also only stabilize lines where the left border has been removed (so, not 54) - which is purely due to historical reasons and "knowledge" we had in 1989 that is most likely completely irrelevant today. But, "don't change stuff that [seems to] work" ..

/Troed

In fact i only "stabilize" lines at the normal spots when the right border is open (204, 206 and 230).
All other lines types used: 000, 056, 080, 158, 160, 162 and 184 are not stabilized as it does not work or bring problems.
Out of these only 056, 080 and 184 use a resolution switch and only 080 and 184 use the left border.
I have stabilizers for all these cases outside the "normal" spots but i did not include them as it resulted to be not necessary for my machine. It seems i have to rethink this.

Thinking again on your previous post here is what i had edited to the previous post when i saw your new one:

There are 26 sync scroll offsets using line type 080 and only 1 fails. That's odd ...
Anyway, if you wish you can go to hwscrl4b.blk to offset 12*(sync_offset/2) and try to change the order of the lines.
Format is every 12 bytes:
- .w offset to correct $FFFF8201/03;
- array 5 times left line type / right line type;
As long as you keep the first 4 bytes and the last 2 bytes of the 12 bytes structure, you can change the order of the other 3 pairs of bytes with an Hex editor.

66 26 62 00 44 at offset 554 / $22A
can become
66 62 00 26 44 or 66 62 26 00 44 or 66 26 00 62 44 or 66 26 62 00 44 or 66 00 26 62 44 or 66 00 62 26 44

Let's see if in any extra tests you might do you will get exactly the same positions failing.


Paulo.

[Dio]

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

[Dio]

Managed to kick it into other wakeup states with rapid power cycling.

Looking only at normal 50Hz lines, I can't see any changes in timing apart from the DE to LOAD latency. HSYNC to DE, for example, is the same.

This implies that the different wait states have different visible screen positions due to the different DE to LOAD, one pixel different in each wakeup state. I've confirmed that this is visible on the monitor by aligning a couple of post-it notes along the edge of the desktop in 3-cycle and 6-cycle cases. This may be particularly useful for people like me who are doing tests from a floppy where it's useful to be able to see the wakeup state on the desktop rather than having to load a program to get it.

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)

I suggest that we change the programs to report DLx where x is the number of cycles between DE and LOAD, now it's been measured, instead of the W numbers.