ljbk wrote:I think that i have found your Enchanted Land trick.
The switch to 71 has to occur latest on pixel 381 and back to 50 can only occur from pixel 385 on... This area is between the stabilizer switch 361/373 and the left border one 429/441... May be you are right and Nick made a 20 pixels/cycles mistake setting the stabilizer switch too late.
Yes, the switch must be done exactly at the point where a "normal" opened right border ends. Because this switch to mono is what prevents the deactivation of DE that happens in normal overscans. And then DE is never deactivated.
It is not a stabilization switch done too late. It is a left border removal done too early. They tried to implement a calibration routine that would adapt border removal timing to the current machine. They try different timings until detecting that the border was opened, by delaying a bit after the switch and checking if the video pointer keeps advancing. Then the main sync-scroll routines are built at run-time according to the timing obtained here.
Right border is done correctly. But the left one is done wrong. They use a wrong starting point and range. So they end making this switch thas has a similar effect (video pointer doesn't stop). The main code still works fine because they add a constant to the value obtained during the calibration. The constant was likely obtained empirically, a value that just worked.
The number of bytes that line consumes is 256 (512 cycles or pixels / 2). That is not helping at all for sync scroll purposes as it is equivalent to the 0 bytes line.
You are right. I was thinking you could get multiple new scan length depending on the right border you use in the next line. But after all, you always end adding an extra 256 bytes to what you would get if you wouldn't use this switch. So it is indeed useless, at least for this purpose.
The line is totally blanked...
Hmm, interesting you see a blanked line. I was expecting actually the opposite. I was expecting for BLANK never to be active, not even during the horizontal retrace.
This is similar for the effect i found and used in the Overscan Demos but just for a 320 pixels line and with a 60/50 switch.
But in "your" switch it is clear why this happens. Here it is not, at least not for me.
If you use the sync line as a normal one not loosing sync, you can go down as you said to 4 lines...
So theorically we can go to sync line + 4, but ...
But for the first line when used as a sync line, you can only have 160, 158, 204 ...
But again as i told you, these theorical combinations do not have all good results depending also if the screen to scroll is 320 pixels wide or fullscreen.
I'm not sure I understand what you are saying.
You are saying that your calculations don't agree with mine. And that according to your calculations the new switches don't produce all the 128 combinations for sync line + 4? If you agree that we can do 4 full lines (never loosing sync). Then we could obviously do sync+4.
Or you are saying that our calculations do match, but you don't know/not sure/fear that not all combinations are stable?
a theorical possibility sometimes turns out to be a flickering one.
Do you have a screen, code, sample, or whatever to reproduce a "theoretically good" combination that doesn't always work ok (flickering, not stable, or whatever)?
I still hope for some more comments on the prog i attached. I mean if it works only on my ST, then it is not worth to do anything more about it.
Yes, of course. Come on people. Please test Paulo's screen and let us know what you get. Tell us what machine you used.
If this happens to not work on STe, this this is of course only a minor problem. But even if it doesn't work on all pre-STe machines, then don't worry. I still have more tricks to try
