horizontal scrolling on ST

[ljbk]

Hi !

Another solution to solve these warming cases is of course to increase the number of lines for the classic sync scrolling combinations.
Including the U feature to reverse unstabilize what we did unstabilize on the previous frame, then we may need no stabilizer at all on the classic sync scrolling lines if we use no left border openning at all.
Using line lengths: 158, 160, 204, 0, 162, 206 and 56 we need 7 lines (sync + 6) to do the classic sync scroll.
Using line lengths: 158, 160, 204, 0, 162 and 206 we need 8 lines (sync + 7) to do the classic sync scroll skipping any change to the resolution register.
Only 5 of the 128 offsets need line size 56 to get it with 7 lines (sync + 6).
As we need 1 line for the unstabilization process this would mean that we would be left with 191 or 192 lines of usable bitmap if no border is openned.
This would be really the last ressource solution.

Paulo.

[ljbk]

Hi !

So here is the "NO stabilizer" version of this 4 bit hard scroll feature.
This should be the most reliable case, up to now, against any warming problems.
As with the U versions, the unstabilization done at the last control line will be undone on the next frame at line 0 (sync line).
The classic sync scrolling is obtained with 7 lines (sync line + 6) using line sizes: 0, 56, 158, 160, 160NTSClike, 162, 204 and 206. Only line size 56 makes use of changes at $FFFF8260 but that switch is more stable than the left border one. That line size was used for the minimum possible combinations ( 8 out of 128 ) to get the screen at the right shift place before the unstabilization is done. If that causes problems, we will need 1 line more to do the classic sync scrolling.
The 8th line (line 7) is used for the unstabilizer.
192 lines out of 200 are free instead of 194 but no stabilizer at all is used so one variable less to care about.
ESCAPE is still available to switch between unstabilizers.

That new set of sync line combinations can also be used for any classic sync scroll program without the use of any stabilizer.

I only tested this with a WS2 banded case and a WS2 "normal" case.
I could not test it today with a cold WS2 because as i cold reseted my machine after the WS2 banded case i got already a WS2 warmed case.


Enjoy,
Paulo.


Edit: default unstabilizer changed to LO/MED/LO.

[troed]

This should be the most reliable case, up to now, against any warming problems.

Excellent! I'm occupied over the weekend but will test this Monday and give feedback

/Troed

[ljbk]

Hi !

So here is the "NO stabilizer" version of this 4 bit hard scroll feature.
This should be the most reliable case, up to now, against any warming problems.
As with the U versions, the unstabilization done at the last control line will be undone on the next frame at line 0 (sync line).
The classic sync scrolling is obtained with 7 lines (sync line + 6) using line sizes: 0, 56, 158, 160, 160NTSClike, 162, 204 and 206. Only line size 56 makes use of changes at $FFFF8260 but that switch is more stable than the left border one. That line size was used for the minimum possible combinations ( 8 out of 128 ) to get the screen at the right shift place before the unstabilization is done. If that causes problems, we will need 1 line more to do the classic sync scrolling.
The 8th line (line 7) is used for the unstabilizer.
192 lines out of 200 are free instead of 194 but no stabilizer at all is used so one variable less to care about.
ESCAPE is still available to switch between unstabilizers.

That new set of sync line combinations can also be used for any classic sync scroll program without the use of any stabilizer.

I only tested this with a WS2 banded case and a WS2 "normal" case.
I could not test it today with a cold WS2 because as i cold reseted my machine after the WS2 banded case i got already a WS2 warmed case.


Enjoy,
Paulo.

Here are some extra results for BEESCRN4:
- WS1 "banded" does not work as expected for position -4 and that error can proceed to the next position as there is no stabilizer;
- WS4 "normal" works after ESCAPE (M unstabilizer) and does not work with with H unstabilizer;
- WS3 "banded" behaves as with WS1 "banded" above fails with all cases and fails also with all previous versions of the program: this is the first time i get this WS3 working as WS1 !!! This means that there are at least 4 sub wake up states for WS3 not counting the warming cases: WS3N (WS3 normal), WS3B (WS3 banded), WS3N1 (WS3 normal as WS1) and WS3B1 (WS3 banded as WS1 (the one i just got));

As this 4 bit hard scroll feature does only work for WS3N and WS3B and not with WS3N1 and WS3B1, we can say that it only works on 50% of the cases in WS3.
As it always works with WS2 and WS4 and never works with WS1, this means that this feature only works on 62.5% of the possible wake up states of the machine even with the help of the user (ESCAPE key) and even if we solve the warming issues.

I will leave my machine running with this WS3B1 case to see if this behaviour persists with time or if it is a stable case.

@Troed
As your default WS is WS3 against WS2 for me, and you seem to have a slower warming machine, it would really be interesting to see if you have any problems with this latest program.
But unlike in the 80s/90s where each group wanted to be the first to publish the new trick, we have plenty of time now ...


Paulo.

[mc6809e]

As near as I can tell there seem to be two things happening:

1) GLUE is in one of four phases relative to the MMU's CPU/SHIFTER memory access cycles.
2) In one or two of these phases, the CPU can touch GLUE's internal registers at times that straddle some critical point when GLUE is updating internal counters.

#1 is accounted for by observing that MMU controls all memory accesses yet doesn't seem to have a way to perfectly synchronize memory cycles with GLUE's internal counters. And after reset, GLUE begins generating VSYNC/HSYNC/DE etc independently of the MMU. How can the two chips sync? There is DE, but observe the timing delays between DE, which is generated by GLU, and LOAD, which comes from the MMU. If the MMU and GLUE were always in the same phase relative to one another, MMU's LOAD would always be the same number of cycles relative to GLUE's DE, but we don't see that. Instead there are four possible delays and not coincidentally it takes four cycles for the CPU to perform a memory access.

#2 explains temperature effects. As chip temperatures change, signal rise/fall times change. If the CPU is altering the resolution mode register while GLUE is updating its internal counters, then the result depends critically on when GLUE sees the CPU's signals rise/fall.

I think on powerup GLUE immediately begins generating VSYNC/HSYNC, DE etc independently of the MMU and the MMU establishes it's interleaved CPU/SHIFTER memory cycles. DE is used by GLUE to signal the MMU during times when the display is enabled and bitplane fetches are required. When the MMU has done a bitplane fetch, it used LOAD to signal SHIFTER to take the data.

My guess is that changing GLUE's display modes at certain times changes the timing of DE which causes the MMU to continue fetching even in border areas. Since the MMU controls memory access timing, the difference in phase between the MMU and GLUE also causes a phase difference between the CPU and GLUE. This means there are four possible points in time when the CPU can update GLUE's resolution mode register relative to GLUE's updating of its own internal counters.

DE probably also turns on/off SHIFTER's shift registers. For some phase of CPU to GLUE, SHIFTER tries to access the palette just as the CPU is writing to the palette causing those annoying dots during the display of SPECTRUM 512 pictures.

I have to admit this is all just speculation, though.

[ljbk]

Hi !

This is just to confirm that after more than 10 hours of power on the WS3B1 state i got yesterday maintains the same behaviour: works as WS1 "banded" and displays "funny" Spectrum 512 dots.
No change with warming then.
After that i had a WS4 "banded" with "specdots".
All works with H unstabilizer and not with M unstabilizer as expected.
So up to now i had (M and H are unstabilizers):
WS1B => M/NO, H/NO(-4 only)
WS2N => M/OK, H/OK
WS2B => M/NO, H/OK
WS3B1=> M/NO, H/NO(-4 only)
WS4N => M/OK, H/NO
WS4B => M/NO, H/OK
The results up to now are the same as obtained with previous versions.
More WS3 tests and "temperature" situations are needed to check if it is worth to exchange the 2 extra sync lines for reliability.

Edit:
I just got a WS3 "normal" with "nospecdots" working as WS1 for all programs published.
So it is the second time i get a WS3 working as a WS1.
I rechecked all $FFFF8260 timing for this case and indeed this is a WS3 and it is different from the early $FFFF8260 timings from WS1. No error in the WS detection and no new WS. But the Shifter behaviour is identical to WS1 case.
So again, i think that the WS only identifies the MMU/Glue pairing. With each of the 4 pairings, several Shifter behaviours are possible and some of those are common to several of these pairings: spectrum dots or not, bands or not, WS1 case with -4 shift impossible.
It is strange that after so many tests, only now i get those WS3 working as WS1 cases. Was it temperature related as my machine is powered "on" for more than 10 hours ? But yesterday when i got the first, it was just powered on for a few minutes ...
So for 4 bit purposes the result is:
WS3N1=> M/NO(-4 only), H/NO(-4 only)



@mc6809e

Thanks for your explain attempt.
I think the number of "sub wake up state" cases detected is quite high already:
- funny Spectrum "dots" or not;
- vertical bands with MED/LOW unstabilizer for -8 / -12;
- cold, warming, warmed machine;
- WS3 working like WS1 for shift -4;
We could think that some of these sub cases would only occur in patterns but at least with the 3 first lines i have already detected all possible combinations that are reduced to 4 with a warmed machine (dots/bands, dots/no_bands, no_dots/bands and no_dots/no_bands). That will remain until next cold reset and so is a stable situation.
These are too many cases to be explained by "signal rise/fall times".
I would bet instead on internal Shifter wake up states.
With my machine, if i press the cold reset button with the warm reset button pressed, i never get any other WS than the WS2 "normal".
On the other hand, if i press the cold reset button without the warm reset button pressed, i can get either WS2 "normal" or WS2 "banded". To get other WS, i have to repeat the same but with a very short power off cycle.
This means probably that the power "on" burst will send a RESET at slightly different times for each individual chip.
As the Shifter works at 32 MHz, it is even more sensitive to these different starts and can then have 4 different phases compared to a 8 MHz chip.
If i am pressing the warm reset button, it seems that i am forcing a similar reset time for all.

This is of course only a guess, nothing more.


Paulo.

[Dio]

I think it's much simpler than that for the most basic case.

The entire ST is synchronised to a 4-cycle state machine by which MMU allocates DRAM bus cycles to video/refresh or CPU. The MMU contains a counter which determines which cycle of the state machine it's on. This is not set to 0 at reset (MMU doesn't see the /RESET signal, and although it could probably be synthesised between Glue and MMU if required, it isn't done).

Similarly, the Glue contains a horizontal counter. The lowest 2 bits of this are probably just a dumb divider for cheapness - there's no need for them to have reset functionality, they might not even be synchronous.

So the implementation for both of these 4-clock counters are almost certainly just flip-flops, to keep the silicon area small - adding a reset line would add more gates. Therefore, both of them start in a semirandom state, which for a given baking of the chip will tend to be constant. I would guess it's most likely to be all 0s or all 1s, which may explain why DL3 and DL6 are the two most common states seen.

A reset doesn't affect this counter in the slightest. A power interruption might; it depends on when Glue and MMU start getting enough power for the flip-flops to start counting. Since we observe that a longer power interruption tends not to affect it, but a short power interruption does, my guess would be that on a longer power interruption, powerup across the board is more synchronised, probably determined by the big ripple caps in the PSU, while with a short power interruption, powerup across the board is more local which gives a chance for one of the counters to register a valid clock before the other (probably the MMU, since it generates clock for Glue after all!)

In my experiments, the most likely result of a brief power interruption is same state or incrementing the DL latency by a single clock, which fits this pattern.

My expectation is that any case which changes with warming is setup / hold time related and that only cases that don't are related to wakeup state.

[troed]

I would guess it's most likely to be all 0s or all 1s, which may explain why DL3 and DL6 are the two most common states seen.

My expectation is that any case which changes with warming is setup / hold time related and that only cases that don't are related to wakeup state.

Adding my observations from the STF I'm currently doing all tests with (this is based on several hundreds of cold boots during the last few weeks) just for information:

When cold, the first boot is always (no exceptions) WS3. If only powered on for a short while, no more than a few minutes, I can always (95%) get into WS2 with a two second power cycling. Predictably so - I use this to quickly be able to test something in the old WK1 and then the old WK2 (since for my current use cases if something works in WS2 it's likely to work in WS4, and the same for WS3 and WS1).

(For the next paragraph, remember that my "cold" phase is ~30 minutes, the "warming" phase then follows for another ~30, and then it's into "warm")

After 15 minutes or so, power cycling will still often result in WS3, followed by WS2, but I can get into WS4 and WS1 as well.

When we get into the latter part of "warming", WS3 becomes less easy to reach, and WS1 appears more and more often. WS4 also starts appearing slightly more often compared to WS2.

When warm, WS1 becomes completely dominant. After a while it actually becomes difficult to get away from. This is also when I start trying short power glitches and short power cycling. All other tests above are with at least 1-2 second long power cycles.

/Troed

edit: For reference, Dio's excellent WS<->DL table. I think it captures my opinion on WS2 being the more difficult "WK2"-state compared to WS4, and WS3 the same compared to WS1.

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

[Dio]

I've much less data, but mine seems to prefer DL6 whether warm or cold, and I can fairly reliably move it to 3, 4, 5 in turn if I turn it back on pretty much instantly the screen goes black.

[mc6809e]

This means probably that the power "on" burst will send a RESET at slightly different times for each individual chip.
As the Shifter works at 32 MHz, it is even more sensitive to these different starts and can then have 4 different phases compared to a 8 MHz chip.
If i am pressing the warm reset button, it seems that i am forcing a similar reset time for all.

This is of course only a guess, nothing more.

Paulo.

The trouble is the RESET circuit only resets the CPU and GLUE. There is no RESET line going to the MMU or the SHIFTER.

[ljbk]

The trouble is the RESET circuit only resets the CPU and GLUE. There is no RESET line going to the MMU or the SHIFTER.

That's right but there is still the power "on" reset for those.
So probably when pressing the warm reset button while powering on, i am forcing some kind of stability.


Ok, now let's move to another interesting subject: the Spectrum funny dots.
I tried to add to my beemove0.prg a feature to allow the user to see if the machine is displaying Spectrum funny dots.
I checked that the machine was in that state.
I produced the code and guess what: i got a normal display for my error scenario.
I checked all the synchro code timings and everything was correct.
So i went to Spectrum 512, loaded a picture and there i have the funny dots ...
So tried to isolate one of the faulty lines and the 3 palettes for that line, imported them to my program (spec.blk file), included a 48 color per line change and now i had the funny dot ...
And the strange thing was that the color displayed for that funny dot (light green) was not part of the 3 palettes ...
So i spent the last hours reducing those 256 bytes (160 bitmap + 96 colors) to almost only zeros trying to keep the funny dot.
So here is what i am left with:
- the dot is at pixel 80 (0-319) while logical color 8 ($FFFF8250) is updated at emulator cycle 164;
- the previous logical 8 color is $333 (grey);
- the next logical 8 color is $777 (white);
- the displayed color is a light green;
- i can zero all bitmap words except the 4 leading to define that pixel as using logical color 8 and the 1st word next after those 4;
- the color displayed is somehow RGB related and not bitmap related to the contents of that "next" word in the bitmap as all other logical colors are set to $000 (black);
- the funny dot appearing depends on the previous color, on the next color and on that next word and will not always happen;

Any explanation for this ?
Conflicting data inside the Shifter ?

You can test BEEMOVE1.PRG, i attach.


Paulo.

[Dio]

The trouble is the RESET circuit only resets the CPU and GLUE. There is no RESET line going to the MMU or the SHIFTER.

It is possible that it could be synthesised from other signals. Even in the Glue, there's also no guarantee that RESET is actually seen by every flip-flop. A resettable flip-flop is larger and more expensive.

[Dio]

Any explanation for this ?
Conflicting data inside the Shifter ?

If the colour isn't either the original or the new colour, but something else, one possibility is that it's an intermediate output seen just on the cusp as a register write changes the value of the register. That implies that the shift register output indexes the palette always, and the palette read output is latched onto the RGB output pins. That might be extraordinarily timing dependent though, maybe too much so to not be affected by warmup.

Another possibility is that there's a state machine that is supposed to accurately mediate palette writes and reads - perhaps so the palette can be a single-port device - run from the 32MHz clock, which can sometimes be in the wrong state and so a palette write and colour read collide. One thing that might indicate that is if the frequency of the 'wrong' dots goes up in medium resolution (when the dot clock is doubled).

if we had the Shifter schematic it would probably be fairly obvious.

[ljbk]

That might be extraordinarily timing dependent though, maybe too much so to not be affected by warmup.

If you test the program i atatched above, you will see a vertcal line of 199 dots with that color.
The general behaviour of showing that color or not is not warming dependent. It will not change until next cold reset.
But if you look at the 199 dots, you will see that some of them, sometimes, flash especially, in my case, depending if the disquette is inside the drive or not.
The number of flashing dots is very variable. It can be 0 (completely stable) or i can have half of them flashing in a non continuous way (not the top ones or the bottom ones).
Again, the shown color is not a direct intermediate value between the previous and next color: it depends mainly on the next bitmap word. I managed to change the color, changing that word but i have not understood yet the logic involved between:
- previous color addressed by shifting data;
- next color coming from MMU to color registers;
- next bitmap word coming with LOAD signal from MMU;
If this case that next bitmap word is $FA6A. At RGB level this means $565 (light green).
The previous color is $333 and the next one is $777;
If i change $FA6A to $0000, $006A or $FA00, no funny pixel is displayed;
If i change $FA6A to $FA56 (if i remember right), i get light blue instead of light green;
I think i tried to get light red but either i made a mistake or not, i did not manage to get it.


Paulo.

[mc6809e]

Again, the shown color is not a direct intermediate value between the previous and next color: it depends mainly on the next bitmap word.

That's a interesting find.

It could be that while the MMU is controlling some of SHIFTER's control lines for a CPU write to the palette registers, it also has bitmap data from the DRAMS on the data bus. That's a problem since it means the data lines into SHIFTER are being driven both by the DRAMs and a pair of latches used to hold CPU data for a palette register write.

This simultaneous driving of inputs to SHIFTER by multiple devices would explain why seemingly unrelated devices, like the disk, can have an effect on the dots since any current draws by other devices are going to affect which of the competing devices "wins" control of the data lines. It also would explain the inconsistency you found when trying to relate bitmap data to displayed color. Sometimes the latch output wins a particular data line and at other times a DRAM wins.

This sort of thing should never happen in a design, though. Only one device should ever be in control of a bus.

If other devices can affect the colors displayed, you might try turning on a sound channel and changing the volume control slowly to see if there's any effect on the dots. Make sure you have an actual load (speaker) to be driven.

You might also try turning the disk motor on and off.

[ljbk]

The logic, if there is any, seems really complex to understand.
But here are some cases for the "bitmap" word:
$1234 -> very light blue
$4321 -> very ligh yellow
$1432 -> very light rose
$0140 -> normal light green
$0040 -> almost full grey with some pixels flashing light green
It looks like at least some kind of OR or merge happens between the previous color and the "bitmap" data.
All these cases with previous color $0333 and next color $0777.


Taking the disquette from the disk drive and putting it back has a temporary (half a second) influence on the display.
That influence is bigger than the difference in flashing that sometimes exists between having the disquette inside the disk drive or not.


Paulo.

[Dio]

This simultaneous driving of inputs to SHIFTER by multiple devices would explain why seemingly unrelated devices, like the disk, can have an effect on the dots since any current draws by other devices are going to affect which of the competing devices "wins" control of the data lines. It also would explain the inconsistency you found when trying to relate bitmap data to displayed color. Sometimes the latch output wins a particular data line and at other times a DRAM wins.

This sort of thing should never happen in a design, though. Only one device should ever be in control of a bus.

I didn't see any of that while I was monitoring the bus gateway WDAT, which is what allows CPU data onto the video bus. It's only activated on CPU phases, and the DRAM video RAS is only active on the video phases. The gap between the two is at least one full 8MHz cycle, well over 100ns.

I haven't tapped the Shifter signals that signal what a palette register write is though, only the CPU and DRAM signature.

If there's a state machine in there, it's possible that any write to the Shifter goes into the first staging register, whether video or palette, and is then transferred out (at a safe edge of the 32MHz clock) across an internal bus to to either the correct palette register, to the correct next staging register or to the shift register, and it's this that can cause a specific palette register to read a ropy value.

I still think it's more likely that it's a setup / hold time violation, which can easily show a dependence on a voltage sag.

... Here's a thought. Dots are never seen on writes to colour 0 (which demos go wild on all the time). Does that imply that the 'corruption' is on the pixel data channel, rather than the palette channel?

[Dio]

Taking the disquette from the disk drive and putting it back has a temporary (half a second) influence on the display.

The disk motor is most heavily loaded when the motor is spinning but the locking nut hasn't locked into the disk, so there will be more voltage sag in that case.

I did a quick test with my machine. I measure 5.08V with the machine idling on the desktop, 5.10V during reset, and 5.05V while the disk motor is spinning with a disk inserted (5.07V with it spinning with no disk). My meter doesn't react fast enough to detect the lock-on time, but using my finger to slow down the drive flywheel to nearly stationary I was able to measure it at 5.02V.

[Dio]

It looks like at least some kind of OR or merge happens between the previous color and the "bitmap" data.
All these cases with previous color $0333 and next color $0777.

A thought: are you on RGB or composite? The colours you mention all seem a bit close to the sorts of effects you can get with the sudden change in Y amplitude causing an apparent signal in the QAM colour channels, unless the Y amplitude change happens to correspond with the zero point in the colour carrier.

The results would be Y between 50 and 100% and a brief, semirandom U and V - it's what causes different colour fringing along edges. Just want to rule out that possibility, if you're on RGB that would do so, if not you might want to check for that one...

[ljbk]

... Here's a thought. Dots are never seen on writes to colour 0 (which demos go wild on all the time). Does that imply that the 'corruption' is on the pixel data channel, rather than the palette channel?

In that case (plasma like), the following "bitmap" word, after the 4 bitplanes related to the changing pixel, will probably be $0000.
This i have learnt today will not allow any "funny" dots.
A test can be made with a change to color 0 in a group of 16 pixels and with the next 16 pixels with no zero data to check if we have the problem.


Paulo.

[ljbk]

It looks like at least some kind of OR or merge happens between the previous color and the "bitmap" data.
All these cases with previous color $0333 and next color $0777.

A thought: are you on RGB or composite? The colours you mention all seem a bit close to the sorts of effects you can get with phase discontinuities on the QAM colour signals (Y between 50 and 100% and a semirandom U and V). Just want to rule out that possibility, if you're on RGB that would do so, if not you might want to check for that one...

I am on RGB via SCART to one AV port of my LCD.

Paulo.

[Dio]

Aha, as I think about it now you're also on an STF, so there's no composite anyway . Good to rule that one out at least.

[ljbk]

Hello !

So finally i got a WS2/DL3 "cold", with the fullscreen display unstability i reported in a previous post, today both with a without a disquette in the drive.
BEESCR4N behave very well with both unstabilizers.
So no warming problems for me anymore.

I changed the default unstabilizer to LO/MED/LO because i got one WS2 warmed case yesterday where the then default unstabilizer (LO/HI/LO) would leave the Shifter unstabilized in a way that the ESCAPE key could not immediatly put the scroll to work. Only after quite some time (probably after some specific sync scroll combination was reached) the whole thing would stabilize.
The file was updated on the post above.

Paulo.

[ljbk]

Hi !

Here is more evidence about Spectrum 512 funny dots.
The atatched updated BEEMOVE2 test includes now 199*20 = 3980 spots where Spectrum 512 funny dots can appear: 20 times 199 lines.
The pixels involved in this case are always the first of every group of 16. The 4 bitmap words point to logical color 8: word 0 with bit 15 at 0, word 1 with bit 15 at 0, word 2 with bit 15 at 0 and word 3 with bit 15 at 1. All words 1, words 2 and words 3 for the 199 lines contain the same values: $0000, $0000, $8000. Only the first bitplane changes for each group of 16 pixels: $1000, $1001, $1002 ..., $1F8B but as you see bit 15 is always set to 0.
All 16 colors registers contain $000 and only $FFFF8250 ( logical color 8 ) is changed every 8 pixels 40 times per line.
Start color is $000, then $777, then $000, then $777 ...
If no funny dots are active we get a complete black screen as expected since the change for color 8 is only active at the second pixel of the 16.
If funny dots are active we get this:

SPECDOTS.PNG

Please notice the last of the 20 vertical lines to the right with a stable color: for the last 16 pixels there is no "next bitmap word" to be loaded because there is no DE anymore.


Paulo.

[Dio]

Excellent test. Seems to prove that there's a collision between the colour and pixel data. I will queue this one for investigation with the analyser (when I can find time).