horizontal scrolling on ST

[Dio]

OK, thanks for the update.

I'm not entirely clear what you're describing here. On what line is the 158-byte line? And you say it does wrap around to the top of the screen?

Raises more interesting questions. If that's the case, are demos that use the 158-byte line case to open the lower border (e.g. the BIG demo) do some changes during vblank that manage to force the shifter to flush? And given what we know about the internals of the ST, how is it possible for it not to shift the screen to the left if there are held words?

(My basic point still stands: if we can develop a detailed understanding of this most simple case - simple because it involves a single frequency change, which is in a Glue register only, and has no sensitivity to wake-up state - and I think it will shed a lot of light on the whole thing).

[ljbk]

Hello !

The test line is around line 24 or 25 counting from 0.
Line 0 is used for sync.
I have then a variable nop jump to allow me to start at a desired time spot during the line, a fixed delay of about 24 normal lines (to show the results of the test) with or not exg before the sync switch.
I have then a variable delay up to the second sync switch that can end or not with exg.
Then i have the second sync switch.
Then the rest are normal lines.
When some data was kept in the Shifter, i can see that the top corner is not white and the results part bitplanes are wrong (i see duplicated results ).


Meanwhile, i upload here the updated 4bit shifting bees with the new wake up detection.

Paulo.

[Dio]

Thanks. I shall muse on this.

[npomarede]

Hello

I tried beeshft0.prg on my PAL STF.

First, I don't really understand, how is it supposed to move the picture, what is the pattern ? It seems to scroll vertically, with sometimes a random 4 pixels scroll ?

As we know from your previous forest demo that 5 line vertical hardscroll is already possible, maybe this version should do only 4 pixels horizontal ? Given the results I have, it would be easier to follow I think, as I see some plane shifting but it's hard to know which scroll position is was.

Or maybe you could use f1-f4 to change only horizontal position and keep the same vertical position when scrolling is stopped with alt ?

For the results :

in STF(2) :
I get planes shifted in what seems to be 2 horizontal scrolling cases (maybe 8 and 12, can't really say, hard to see on my tv)

in STF(3) :
scroll 0, 8 and 12 seem to be stable. scroll 4 gives plane shifting (head of the bee is yellow), but it sometimes gives plane shifting + interlacing effect : even lines and odd lines are shifted in what seem to be 8 pixels on each line : all even lines are shifted 8 pixels to the right, relative to odd lines. For a few VBL, this interlacing effect seem to change, as if even lines were 8 pixels to the right, or odd lines were 8 pixels to the right. After a short while, it gets "stable", but the interlacing effect remains (as if 4 bytes remained at the end of each line, creating a scrolling only every 2 lines)

So far, I wasn't able to get STF(1) or (4), neither any result where all 4 horizontal scrolling position were good.

I wonder if some of the plane shifting I see are not due to the overscan combinations also used at the same time to scroll vertically ?
Maybe we could have a version where f1-f4 means no vertical scrolling at the same time to be sure 2 unstability causes are not combined ?

Nicolas

[ljbk]

Experience also shows that it is possible to force that buffered data out at least with some wake up states by means of the stabilizer (wake up 2 at least), forcing the Shifter to wait for new fresh 4 words from the MMU before displaying the bitmap.

There must be a simpler way the buffered data is cleared than just the stabiliser. Consider the 158-byte line case - that always flushes the Shifter's buffer, not reading the last word and generating no last 16 pixels on the line but otherwise starting the next line normally, no 4-pixel shift. This is the one I've been trying to understand, because it's a simple and predictable case and it always works. If that one can be worked out I think it should shine a lot of insight on exactly how the Shifter buffer clear works.

First i must correct my original statement that is not correct.
The buffered data can not be forced out.
What the most used stabilizer does it that no matter the number of words in buffer, the next line will start unshifted.
Line 158 case causes 1 word to remain in buffer but the next line to start unshifted IF when arriving to that line 158 the number of words in buffer was 0 and the line started unshifted and the Shifter was not drawing black columns and we are in wake up state 2.
IF in wake up state 2, with the Shifter not drawing black columns, we get to line 158 with a variable number of words in buffer and a variable screen shift then after line 158 we will not get always the same situation. This is why line 158 is not a stabilizer one.

[Dio]

I'm not so concerned about its use as a stabiliser, just the case where it's used to remove the lower border with (as I thought) no sideeffects. I'm looking for the very simplest cases to investigate here .

[ljbk]

I'm not so concerned about its use as a stabiliser, just the case where it's used to remove the lower border with (as I thought) no sideeffects. I'm looking for the very simplest cases to investigate here .

Ok, but the situation is the same.
At line 199, in a normal line with a normal Shifter status (no shift and no black columns), you switch to 60 Hz before the right border spot and 4 things probably happen:

1- The GLUE detects 60 Hz at the end of the timing of the NTSC screen, and disables the DE signal 4 CPU cycles early;
2- The Shifter is expecting a 4th word from the MMU to build the last 16 pixels of the line but that word does not arrive because the MMU does not get the DE signal active it needs from the GLUE to allow the memory reading and so the set of 4 words remains incomplete. The internal Shifter shifting registers are probably not loaded and we get border color instead of 16 bitmap pixels;
3- The GLUE detects 60 Hz at the end of the normal PAL screen and is lured to think it is in NTSC and opens the lower border proceeding with new DE signal on the next line;
4- The Shifter starts the next line with some words in the buffer but with an internal status of "no shift" and so the line starts at the normal place and the 3 words in buffer are not displayed otherwise we would get a -12 shift;

Paulo.

[ljbk]

I tried beeshft0.prg on my PAL STF.

First, I don't really understand, how is it supposed to move the picture, what is the pattern ? It seems to scroll vertically, with sometimes a random 4 pixels scroll ?

The movement should be vertical (up/down) and from time to time shifting: -12, -8, -4, 0, 0, -4, -8, -12
You can watch it here:
http://www.youtube.com/watch?v=ThA6iCyKfqU

As we know from your previous forest demo that 5 line vertical hardscroll is already possible, maybe this version should do only 4 pixels horizontal ? Given the results I have, it would be easier to follow I think, as I see some plane shifting but it's hard to know which scroll position is was.

Or maybe you could use f1-f4 to change only horizontal position and keep the same vertical position when scrolling is stopped with alt ?

As far as i know, 4 bit shifting displaying correcly the picture (without bitplanes switched) is not possible without sync scrolling because you need to treat the extra words in the Shifter that come from one VBL frame to the next VBL frame.
If you don't want the sync scrolling then you should use the TOS shifting program and check the wake up state with WAKE_UP.TOS or i can update that TOS shift program with the new wake up detection.

4BIT.PRG will give the following results:
-1 => no shift => GREEN TOS DESK;
-2 => 4 pixels shift => BLUE TOS DESK;
-3 => 8 pixels shift => GREY TOS DESK;
-4 => 12 pixels shift => RED TOS DESK;

If you see black columns, interlaced shifting or do not see the refered TOS DESK background colours when starting from original TOS colours in Low Resolution then that shift is not working for your machine and wake up state at that time.

For the results :

in STF(2) :
I get planes shifted in what seems to be 2 horizontal scrolling cases (maybe 8 and 12, can't really say, hard to see on my tv)

in STF(3) :
scroll 0, 8 and 12 seem to be stable. scroll 4 gives plane shifting (head of the bee is yellow), but it sometimes gives plane shifting + interlacing effect : even lines and odd lines are shifted in what seem to be 8 pixels on each line : all even lines are shifted 8 pixels to the right, relative to odd lines. For a few VBL, this interlacing effect seem to change, as if even lines were 8 pixels to the right, or odd lines were 8 pixels to the right. After a short while, it gets "stable", but the interlacing effect remains (as if 4 bytes remained at the end of each line, creating a scrolling only every 2 lines)

So far, I wasn't able to get STF(1) or (4), neither any result where all 4 horizontal scrolling position were good.

I wonder if some of the plane shifting I see are not due to the overscan combinations also used at the same time to scroll vertically ?
Maybe we could have a version where f1-f4 means no vertical scrolling at the same time to be sure 2 unstability causes are not combined ?

Ok, first i wonder why i did not get wake up state 1.
I know that your STF is from another revision than mine.
I hope that there are not 820A and 8260 different timings for the same HW conditions (unsync between chips) with your machine compared to mine.

Second, i wrote that it worked on my machine most of the times in wake up state 2 not always as until now in wake up state 4.

Third, results with wake up state 3 are as mine.

But let's talk a bit more about the Shifter.
Experience shows that there are several visible effects on screen possible out of Shifter unstability when displaying a normal 160 bytes line in PAL:
1- black 16 pixels columns appeared interlaced with 16 bitmap pixels;
2- screen shifting occurs at -12, -8, -4 due to having 3, 2 or 1 word in the buffers when starting the line;
3- interlaced screen shifting occurs (one line at a position a the new line at another position);
4- no screen shifting occurs despite having words in the buffer at the end of the display of the previous line (158 and 204 lines case): either the 1 and 2 words respectively have been thrown away at the end of the line or a "no shift" condition is present leaving the words to be scrapped and the screen to be started at the normal position;
We can define that as Shifter_draw_status(draw_columns, shift_status, words in buffer).

Normal case is of course (false, no_shift or shift, 0).

What we need are cases:
- (false, no_shift or shift, 0) : position 0;
- (false, shift, 1) : position -4;
- (false, shift, 2) : position -8;
- (false, shift, 3) : position -12;

Those 4 cases but be self sustained if only 160 lines are drawn. That is why i showed that TOS can sustain this.

What is needed for a correct 4bit normal screen scrolling:

1- An unstabilizer method that can provide the 4 cases described above starting from a normal situation, for all wake up states, without having to do sync switches at every line otherwise we use Alien 4bit method;

2- A sync scroller set of lines that provides, for all wake up states, a way to control the low byte from the screen offset and enters the unstabilizer drescribed above with a normal Shifter condition (false, no_shift or shift, 0);

There are many unstabilizer methods. We can say that almost any sync switch provides some kind of unstability.
The TOS shifting and Bee shifting programs use similar methods but not exactly identical based on a switch from low to medium followed from a switch from medium to low while the MMU is reading the data and the Shifter is displaying it.
The distance in clocks between the two switches defines the number of words in buffer an so the following screen shift.

The most common stabilizer has proved to work as required, at least in wake up state 2, as long as the Shifter is displaying data at the time. So if the right border is open and we do the 71/50 switch corresponding to the stabilizer then the following 160 bytes line will start unshifted from the normal place:

Shifter status at the end of the line:
- (false, no_shift or shift, 0) : position 0;
- (false, shift, 1) : position -4;
- (false, shift, 2) : position -8;
- (false, shift, 3) : position -12;

will be:
- (false, no_shift, X) : position 0;

when starting the next one.

So, the TOS shift program only consists of:
- a 204 bytes line with stabilizer;
- a 160 bytes line with a LOW/MED/LOW unstabilizer during screen display;

The Bee shift program consists of:
- 5 variable lines to control the byte offset where the last unstabilizing line has a stabilizer;
- a 160 bytes line with a LOW/MED/LOW unstabilizer during screen display at a slight different position;


What are the results ?

Sometimes, we get columns for some positions especially in wake up state 1, 3 and less often in 2.
Sometimes, we get interlaced shifted lines for some positions.
Sometimes, it works !

As there are many unstabilizer methods and also several possible stabilizer methods and 4 wake up states, some giving different results probably depending on SW undetectable Shifter wake up states for the same main wake up state, and as each different byte lengh line provides its own unstabilizing effect, this is a work in progress that can be resumed like a set of the possible following functions:
Input_Shifter_Status -> [820A switch or 8260 switch at a MMU timing for one of 4 wake up states] -> Output_Shifter_Status

Describing these functions depending on each possible input case is required to get this feature to work better.
Considering that there are now 13 (yes, i found a new one) different lines with different byte sizes and 4 wake up states and several possibilities for each of those 13 lines and sync switches, the amount of work expected is quite important.

By the way, one thing i detected is that the disk drive effects and the Spectrum 512 flickering pixels tend to stabilize after some time of the machine running (you either get stable funny pixels ot normal pixels) in wake up state 2. May be it has to do with the Shifter internal clock status reaching a stable point.


Paulo.

[Dio]

1- The GLUE detects 60 Hz at the end of the timing of the NTSC screen, and disables the DE signal 4 CPU cycles early;

I assume this is the case; I can show this one on the logic analyser.

2- The Shifter is expecting a 4th word from the MMU to build the last 16 pixels of the line but that word does not arrive because the MMU does not get the DE signal active it needs from the GLUE to allow the memory reading and so the set of 4 words remains incomplete. The internal Shifter shifting registers are probably not loaded and we get border color instead of 16 bitmap pixels;

They're definitely not loaded; the last 16 pixels are lost and border colour.

4- The Shifter starts the next line with some words in the buffer but with an internal status of "no shift" and so the line starts at the normal place and the 3 words in buffer are not displayed otherwise we would get a -12 shift;

Right, the 'words to read before transfer to shift regs' counter must be set to 0 somewhere between the end of the previous line and the start of the next. But this (probably?) isn't caused by any register write because it (probably?) doesn't snoop FF820A. So the condition that causes it must be deducible from the external signals presented to the Shifter (and there aren't many; the only control logic is CS, R/W, LOAD and DE). My suspicion is that it is something to do with DE, since I can't actually understand why the Shifter needs to see DE. I have quite a few STs in the spares box now, and I'm probably going to do some experiments cutting the DE pin and seeing what happens.

The VHDL for the Suska project implies some of this:

Code: Select all

	-- This process is responsible to synchronise the load cycle during
	-- the horizontal sync pulse and to control the cycle during video
	-- data transfer from the MMU to the SHIFTER (DE = 1).
	variable LOCK: boolean;
    begin
    	wait until CLK = '1' and CLK' event;
		if DE = '0' and SHFT_STRB = '1' then
            LOAD_CYCLE <= C4;
         ...

My VHDL isn't quite up to understanding the SHIFT_STRB logic well - the implication is that it's set once per 4 clock cycles in low res, which given the code above doesn't seem to fit the observable behaviour - and it is further confused by the additional resolutions that the VHDL supports.

[npomarede]

The VHDL for the Suska project implies some of this:

Although it's always interesting to look how other projects are trying t emulate the ST in HW instead of SW, last time I looked at the VHDL code, my feeling was that it was a very basic implementation of the shifter, not emulating all known effects used in demos. My guess is that they're adapting their VHDL code to run as many demos as possible, but I don't think they do it using informations we don't know yet.

Nicolas

[Dio]

I know some of the people working on VHDL have done it by side-by-side-ing with an existing chip and verifying the exact same signals come out of the FPGA as the original chip when presented with the same inputs.

But I agree that even if that's the R&D technique there's no guarantee that all the internal cases have been covered; in addition, it's unclear exactly what ST the results are being compared with. I've been using it to guide research rather than taking it as gospel.

[npomarede]

I know some of the people working on VHDL have done it by side-by-side-ing with an existing chip and verifying the exact same signals come out of the FPGA as the original chip when presented with the same inputs.

But I agree that even if that's the R&D technique there's no guarantee that all the internal cases have been covered; in addition, it's unclear exactly what ST the results are being compared with. I've been using it to guide research rather than taking it as gospel.

In the end, having different projects and different research directions is interesting and can help shed some new light, but regarding the YM and the FDC emulation for example, even if they got the same results as the original chip in their comparisons, some cases were missing last time I checked (15 volume table instead of 31 for example, some fdc timings, ...). It's hard to design some tests that cover all the known and not-so-known behaviours to do a side by side comparison, but studying these from the HW point of view with signal analyzer and SW point of view with some repeatable tests can certainly help understanding the inner work.

[ljbk]

Hi !


Just something to think about.

As i explained before there are two sets of $FFFF820A timings the early_820A (wake ups 1 and 3) and the late_820A (wake ups 2 and 4) with the main difference a delay of 2 cycles in the MMU in the first case compared to the GLUE as we see the "normal" screen shifted by 2 pixels to the right.
This means that for one of the two cases the GLUE will create transitions in the DE signal while the MMU is feeding the Shifter with bitmap data. That is especially the case at the spots for the 158 bytes line and 4 CPU cycles later for the right border openning.
Now imagine what can be the different behaviours of the DE slave chips (MMU and Shifter) if while doing a word copy the DE changes. May be everything is taken care (maybe with other signals by the GLUE) and the word copy always happens before or after a possible change in the DE.

Another interesting thing to be observed with a logic analyser is the 0 bytes lines.
Is the DE started at all by the GLUE or only for 2 CPU cycles not giving time to the MMU to transfer any word to the Shifter ?


Paulo.

[Dio]

Wake-up states aren't relevant to the 158-byte case though - it just works on all STs (even the STE I think).

The one thing I do know is that the minimum DE to LOAD latency is 3 CPU clock cycles (since the four wake up states have latencies of 3, 4, 5 and 6 between DE and the first LOAD). I measured that on the logic analysed last year. My presumption is that the MMU samples DE in order to decide if the next MMU phase is a video or refresh phase probably 2.5 CPU clocks before the LOAD occurs (other options include 3 or 2, if the logic relies on setup time, or maybe even 2.25 or 2.75 if the MMU is using both edges of the 16MHz clock as a timing reference).

When it comes to zero-byte lines, that predicts that:
- if there is no DE at all, a zero byte line can be generated in all wakeup states.
- otherwise to generate a 0 byte line the DE pulse must last 2 clocks, and it will only work in two of the wakeup states (where the DE to load latency is 5 or 6 cycles)
- in the other two wakeup states (3 and 4 cycle DE to load latency), or if the DE pulse lasts 4 clocks, it should generate a two-byte line instead

Last time I had the analyser on I didn't have the software to hand to generate the various special cases on demand. As you say, it's worth checking what DE actually occurs.

[ljbk]

Hi !

0 bytes lines with border color instead of bitmap are possible for all 4 wake up states i defined with my machine.
You can get them with a 71/50 switch or with a 60/50 switch aproximatly at the same MMU time spot:
- 3 different time spots for 71/50: early (W1), middle (W3 and W4) and late (W2);
- 2 different time spots for 60/50: early (W1 and W3) and late (W2 and W4);

I have never managed a 2 bytes line.

At the moment, i can have for all 4 wake up states the following line lengths for which i can later on provide SW for you to test:
1- 0;
2- 14 (NEW);
3- 54;
4- 56;
5- 80;
6- 158;
7- 160A(normal) and 160B(start and end like NTSC but in PAL);
8- 162;
9- 184;
10- 186;
11- 204;
12- 206;
13- 230;


Paulo.

[Dio]

If someone else has written the software, I'll gladly not do it myself .

I was wrong to think a 2-byte line is possible. It's the 162-byte line I was thinking of. I'll look at defining a set of 16 signals that I can capture for each of these cases which will provide us with useful data to consider; I will also try to work out a setup for measuring when hsync starts with each of these cases (trickier to capture, it can't just be intercepted on the leg of a DIP IC).

Something else worth considering measuring (which can be measured in software, or I can extract it from DE on the analyser) is the horizontal period in each of these cases.

[AtariZoll]

I think I have to give up this project since it seems to be to difficult. I have only used Easyrider and it needs a file to dissamble.

Well, there is another way to make some not to extensive changes in games: instead disassembling, what needs really lot of time, study code and find relevant parts, then add new code for movement, with scroll, in free RAM (there is always little free space in 512K. Or above 512K if no other way), and just put jumps, jsr from game code to new routine(s) .
Of course, this is not easy too, but surely much less time needed.

[nativ]

rip all data then make a new one!! probably easier!

[Dio]

At the moment, i can have for all 4 wake up states the following line lengths for which i can later on provide SW for you to test:

One thing worth doing is during the test make sure the colour output conveys some useful information: if I capture one bit each of RGB then there's 8 different states that can be communicated. Something like border red, screen green would be nice and clear (and allow easy distinguishing of any rogue 0's output). Albeit hard on the eyes .

I reckon the signals list is DE, LOAD, CS, RW, R2/G2/B2 at shifter, HBLANK at the monitor port or the clock nudger, BLANK will have to be on one of the diodes, RAS/CAS off the DRAM to help label which phase the MMU is on and DTACK, CLK and A23 (to allow the writes to the sync reg to be spotted) at the CPU. Two free if we can think of anything else.

[ljbk]

At the moment, i can have for all 4 wake up states the following line lengths for which i can later on provide SW for you to test:

One thing worth doing is during the test make sure the colour output conveys some useful information: if I capture one bit each of RGB then there's 8 different states that can be communicated. Something like border red, screen green would be nice and clear (and allow easy distinguishing of any rogue 0's output). Albeit hard on the eyes .

That can be arranged .

I reckon the signals list is DE, LOAD, CS, RW, R2/G2/B2 at shifter, HBLANK at the monitor port or the clock nudger, BLANK will have to be on one of the diodes, RAS/CAS off the DRAM to help label which phase the MMU is on and DTACK, CLK and A23 (to allow the writes to the sync reg to be spotted) at the CPU. Two free if we can think of anything else.

Considering the effects that can be triggered by the SW, i would advice to check carefully the BLANK signal and the HSYNC signal as you can have:
- BLANK with any line length with MMU reading;
- BLANK on the right side of the screen only;
- BLANK with 0 bytes line and MMU not reading;
- BLANK and screen scrolled one line down (no line at all);

Please tell me when you need those PRGs, including the number of "special lines" you need per screen (199, 10, 1 ...), or send me a PM when the time is right for you.

Paulo.

[Dio]

Whenever it's done is fine, my interest is currently piqued and I've tidied the office enough to get all the bits out of the garage .

One line per frame, with the shifter reset at VSYNC, is ideal. Doesn't really matter what line it's on. I just need an easy triggering condition. I was going to look for writes with A23 set, so keeping the count of those down (I imagine a few to reset the shifter and then the test) will be good.

[Steven Seagal]

@ljbk
Just to mention it, there's kind of preliminary support for beeshift in Steem SSE 3.5.2 if you choose "wake-up state 2".
It works with the previous version "5", but with the latest version "0", the program doesn't detect "WU state 2", it does state 1, but then it's garbage because Steem emulates the shifts only in "WU state 2" for now.

[ljbk]

@ljbk
Just to mention it, there's kind of preliminary support for beeshift in Steem SSE 3.5.2 if you choose "wake-up state 2".
It works with the previous version "5", but with the latest version "0", the program doesn't detect "WU state 2", it does state 1, but then it's garbage because Steem emulates the shifts only in "WU state 2" for now.

Hi !

The wake up detection in beeshft0.prg and in wkae_up.tos is the new one that can detect 4 wake up states based on:
- 60/50 timings of Right Border switch;
- 71/50 timings of Right Border switch;
2 tests with 71/50 are done and one test with 60/50 is done.
As i explained before, there are with my machine, 3 sets of 71/50 timings and 2 sets of 60/50 timings.
Considering cycle that i identify as 293 the spot where the instruction updating the $FFFF820A to 60 Hz ends to open the right border for all wake up states (the only spot), the several sets of timings are as follows:

60/50:
Early timing: W1 and W3: 291/301 and 293/301
Late timing: W2 and W4: 293/301 and 295/305

71/50:
Early timing: W1: last possible 71 at 293 / first possible 50 at 295
Middle timing: W3 and W4: last possible 71 at 295 / first possible 50 at 297
Late timing: W2: last possible 71 at 297 / first possible 50 at 299

291, 295, 299 are mutiple of 6 instruction preceed spots
293, 297, 301 and 305 are "normal" spots

Based on this the new wake up state detection tests:

bsr q_7150_295_305
lea z_offset_res1(pc),a0
move.b d0,(a0)
bsr q_7150_297_305
lea z_offset_res2(pc),a0
move.b d0,(a0)
bsr q_6050_295_305
lea z_offset_res3(pc),a0
move.b d0,(a0)

and checks:

move.l z_offset_res0(pc),d0
cmp.l #$00CCA0CC,d0
bne.s l_chk_wakeup3
moveq #4,d1
bra.s l_set_wakeup
l_chk_wakeup3
cmp.l #$00CCA0A0,d0
bne.s l_chk_wakeup2
moveq #3,d1
bra.s l_set_wakeup
l_chk_wakeup2
cmp.l #$00CCCCCC,d0
bne.s l_chk_wakeup1
moveq #2,d1
bra.s l_set_wakeup
l_chk_wakeup1
cmp.l #$00A0A0A0,d0
bne.s l_no_wakeup
moveq #1,d1
bra.s l_set_wakeup

l_no_wakeup
bra lmainprog_0
l_set_wakeup
lea zwakeup(pc),a0
move d1,(a0)

I hope i have been clear enough.

Paulo.

[ljbk]

@Dio

Hello again !

I have a question for you.
You said you would prefer that the SW uses a less as possible the A23 which means as less changes to $FFFF820A/60 as possible.
Some of the lines sizes available are not stable with the minimum sync/resol switches: if you use them once it might work but if you repeat their use, like 2, 3, 4, ... the Shifter goes to one of the funny states : interleaved shifted lines at different positions or vertical bands of border with also different shifts ...
This can be avoided for most cases with a stabilizer and that means most of the times two extra accesses to $FFFF8260.
For your HW tests, do you prefer the unstable versions with less HW access or the more stable ones (at least with my machine and WS2)

Paulo.

[Steven Seagal]

I hope i have been clear enough.
Paulo.

You kidding, right?
Seriously, there's no 71/50 check at line cycle 376 ("position 293") in Steem for now, that could be the problem.
By the way, despite working on Steem I don't really understand ST assembly .