Sync-tricks/fullscreen discussion

[slingshot]

More details there: https://listengine.tuxfamily.org/lists. ... 00001.html

(Loosely related: just found a demo which updates the MASK register during transfer - not sure why, maybe it should stop the transfer after some bits?)

[Gunstick]

The microwire code is from anno 1990 DSOTS we did it wrong back then, so doing it wrong today. Need to keep the spirit alive! I also removed other video initialization code which just somehow disable the full STE video out (on the STE, not on hatari).

When you get planes mashed up, this is because I do not change resolution, but the switch is Hi/Lo and not Hi/Med in case you run in medium. So switch to low and it will look nicer. Hatari usually starts in low, as nobody bothers to put a desktop.inf there.

[slingshot]

When you get planes mashed up, this is because I do not change resolution, but the switch is Hi/Lo and not Hi/Med in case you run in medium. So switch to low and it will look nicer. Hatari usually starts in low, as nobody bothers to put a desktop.inf there.

Yeah, I've realized that it's better to switch to low mode before starting the prg. But it doesn't affect the test pattern, which is indeed different what's in Hatari.

[Gunstick]

I developed the thing in hatari and then made it work on the STE. But I did not check the differences. Anyway, future changes will be to use HBL for up/down movement instead of a dbf loop. This will make it possible to have more (slow) text output with infos. And maybe also a key to "fix" a switch in place, so you could combine stuff. And of course changing the code so it's less dumb "it just works who cares".
Some of this code was set by multiple trial and error, instead of designing it correctly. That's the classic ULM coding style.

[slingshot]

I didn't say the difference between STe and Hatari is a problem. The opposite else: it's good to have something which shows the imperfections of emulation. And as I'm developing the FPGA clone, I'm really interested in these small things. Now just I wonder if my results and the original HW results are the same or not.

[Gunstick]

well you really need an STE to check which position does what and compare that to the FPGA output.
If you need specific changes to facilitate your testing, create an issue in the git repo (if you got an account) or just write here.
For now I have the idea to display the position as line and cycle, and I will try to get them the same values as most technical articles about overscan.

[Gunstick]

New version. the eclock jitter is now in the vbl, so one can also explore the lower border.
Next is to go from dbf to lines (via HBL) and position. I wonder if the jitter is same on every HBL or if I need to adjust per line.
Then add a key to freeze a switch line in place and have a new line to move around.
Also should add a feature to edit the order and arrangement of changes per line.
At the end one should be able to 'draw' a fullscreen. Well not really as after the HBL you need to wait a line. So it's only possible to open every second line.
https://github.com/gunstick/syncexplorer

[npomarede]

HI,
if you taking about the E clock jitter that delays HBL from 0 to 8 cycles, then this delay is not the same on every HBL, but it can be predicted.
Note that the E clock jitter is also added to the VBL interrupt, this is because HBL and VBL are handled as autovectored interrupt in the ST and this requires to sync with the E clock to generate HBL/VBL interrupt.
This was discussed in some threads here some long time ago and this delay is also correctly emulated in Hatari.

Nicolas

[Cyprian]

http://atari-forum.com/viewtopic.php?f=68&t=26501

[Gunstick]

I actually develop this in hatari, and the emulation is very accurate.
Just some useless features are not emulated. i.e. on a real ST if you 'open lower border' 5 lines too early, you kill DE. So you get black, not background color. looks like starting VBL early.
I will check how the jitter is for every HBL position. That should also be predicatble as HBLs are all same time apart.

I also once tried the 4 lines 60Hz fix. A CRT is not loving that at all. Independent where in the VBL you do that. You always end up with some distortion.

[npomarede]

Yes, there're a few corner cases where background color is used when it should be blank signal, this is because so far Hatari was developed with compatibility in mind with existing demos. So most existing sync tricks are supported, but on the opposite there's no "real" shifter/mmu state machine for now so it won't emulate effects you can get by changing sync at random position for example.
Now that the state machine is better known/described (see various threads in AF or other FPGA implementation), doing similar is Hatari is of course on the roadmap (but lack of time is delaying it a lot ).

Hatari also does not emulate the bending effect you sometimes get when staying in 60 Hz for too long. Even on real HW this depends on the CRT type (for example the "XXX international" demo stayed in 60 Hz until top border was opened, which distorted image a lot on my monitor, but not on some others). Those bending effects could be added later as some kind of "post processing" (for example using gpu shaders as done in some others emulators that try to replicate CRT colors/artefacts/bluriness)

Nicolas

[frank71]

I did some test with the 4bit hard scroll technique. Here the results (50Hz fullscreen 4 plane side scrolling on ST with about 50% processing time left):
https://github.com/frankheisig71/st_side_scrl/
It wasn't as simple as it looks like. Obviously different machines behaves different, when applying short med resolution sequences on beginning of scanline. For me it was not possible to find a variant, working on all my STs - there are 2 variants.
Currently only wake state 2 is supported. This will be fixed soon.
Please test and leave a comment...

[Cyprian]

I actually develop this in hatari, and the emulation is very accurate.
Just some useless features are not emulated. i.e. on a real ST if you 'open lower border' 5 lines too early, you kill DE. So you get black, not background color. looks like starting VBL early.

What about Video counter? Was it reset as it is done in VBL?

[npomarede]

I thought about what you're asking some times years when working on Hatari and measuring at which exact video cycle video counters are reloaded and unfortunately it won't work : my idea was to toggle to 60 Hz around line 263 at the place wher we can see that video counter FF8201/03 is copied to FF8205/07, then switch back immediately to 50 Hz before a new screen starts. This way you could have hardware split screen with one video address at the top and a completely different one at the bottom. You could even code a double hardscroll.
But IIRC the point where video counter is copied is when vsync is already set, switching back to 50 Hz will be too late, the display will start from the top again.

Nicolas

[ijor]

I did some test with the 4bit hard scroll technique. Here the results (50Hz fullscreen 4 plane side scrolling on ST with about 50% processing time left):
https://github.com/frankheisig71/st_side_scrl/
It wasn't as simple as it looks like. Obviously different machines behaves different, when applying short med resolution sequences on beginning of scanline. For me it was not possible to find a variant, working on all my STs - there are 2 variants.
Currently only wake state 2 is supported. This will be fixed soon.

There are multiple versions of Shifter with slightly different behavior, although most are rare and then most computers have the same Shifter part. Perhaps more important, Shifter has its own wakestates. These wake states are unrelated and in addition to the the GLUE/MMU ones, and they can't be detected by software.

[ijor]

What about Video counter? Was it reset as it is done in VBL?

I thought about what you're asking some times years when working on Hatari and measuring at which exact video cycle video counters are reloaded and unfortunately it won't work : my idea was to toggle to 60 Hz around line 263 at the place wher we can see that video counter FF8201/03 is copied to FF8205/07, then switch back immediately to 50 Hz before a new screen starts. This way you could have hardware split screen with one video address at the top and a completely different one at the bottom. You could even code a double hardscroll.

You can't prevent the video counter being reset, not without eliminating vertical sync.

The video counter lives at MMU, not at GLUE, and MMU has no concept of refresh rate frequency. MMU restarts the video counter when the external VSYNC signal is asserted. Which means that the only way to prevent it would be to prevent VSYNC as well.

[Cyprian]

You can't prevent the video counter being reset, not without eliminating vertical sync.

The video counter lives a MMU, not at GLUE, and MMU has no concept of refresh rate frequency. MMU restarts the video counter when the external VSYNC signal is asserted. Which means that the only way to prevent it would be to prevent VSYNC as well.

If I understand correctly, there is no way to invoke a reset of the video counter in the middle of the screen, in order to split the screen.

thanks for clarification ijor

[ijor]

If I understand correctly, there is no way to invoke a reset of the video counter in the middle of the screen, in order to split the screen.

I don't see how you could do that. Again, not without somehow creating an additional VSYNC pulse, which might be doable if you don't mind and you insist.

[npomarede]

You can't prevent the video counter being reset, not without eliminating vertical sync.

The video counter lives at MMU, not at GLUE, and MMU has no concept of refresh rate frequency. MMU restarts the video counter when the external VSYNC signal is asserted. Which means that the only way to prevent it would be to prevent VSYNC as well.

Hi Ijor,

regarding vsync signal being asserted, does it set vblank too ?
I ask this because vblank is normally set roughly 2 lines before vsync signal, but it's known that on a 50 Hz screen if freq is not 50 Hz at the time where vblank should be set, then vblank iremains disabled and 2 extra lines will be displayed (in the case where bottom border was previously removed).
In that case where vblank is not set, does vsync forces vblank too to ensure nothing is displayed until next frame starts ?

Nicolas

[slingshot]

regarding vsync signal being asserted, does it set vblank too ?
I ask this because vblank is normally set roughly 2 lines before vsync signal, but it's known that on a 50 Hz screen if freq is not 50 Hz at the time where vblank should be set, then vblank iremains disabled and 2 extra lines will be displayed (in the case where bottom border was previously removed).
In that case where vblank is not set, does vsync forces vblank too to ensure nothing is displayed until next frame starts ?

Nicolas

On STe, vblank is set (and hblank with hsync).

[ijor]

regarding vsync signal being asserted, does it set vblank too ?

Yes, VSYNC sets VBLANK and also clears VDE.

In that case where vblank is not set, does vsync forces vblank too to ensure nothing is displayed until next frame starts ?

I'm not sure that was the original purpose. Although I have no way to know for sure the original intention, I suspect it was related to ensure correct behavior when using external SYNC.

[troed]

Yesterday at Silly Venture 2022 Summer Edition, while not possible to understand from our release I think, I released a "new" update to what's possible and not possible using Shifter tricks. The origin for the idea is twofold: 1) Paulo Simoes' "bee-scroll" using a non-fullscreen 4 pixel sync scroll, by causing the Shifter to keep one ore more words extra across scanlines, and 2) An offhand comment from Ijor in 2017 regarding what he saw happen in the Shifter clock generation in a specific ("unused") video mode.

Note that the clock mux doesn't output ANYTHING AT ALL if both bits of the rez registers are set. No clock would be generated and almost all Shifter processes would freeze until setting a valid resolution.

From this I got the idea to simply recreate Paulo's scroll, but not by going between hi and medium/low res (which is famous for causing Shifter instability) but simply by setting resolution #3 for the appropriate amount of cycles.

This works, and from testing on one (1) Mega ST and one (1) STE it might be a bit more compatible than what was possible with hi-low, that is, I seem to be able to find locations where the "black bars" don't happen. However, the documented reason for why the Shifter _will not_ successfully keep one word extra in wakestate 1 (and half the time in wakestate 3) still applies - and thus this method requires the user to visually confirm that scrolling works, otherwise power cycle.

The release is a game engine making use of the fact that Shifter scrolling keeps content at 4, 8 and 12 pixels offset still at word boundary alignment - allowing for quicker graphics drawing. The point was to highlight the fact that the Atari engineers - by chance - were very close to creating a capable horisontal scrolling system that would've given us many fun arcade ports over the years

Emulators currently don't support this trick, but the explanation above is complete in that - as you would expect - 4 cycles of rez #3 indeed delays Shifter output by 4 pixels in low res.

(No, you cannot poke that register with higher granularity than 4 cycles, sadly enough ... )

Release will happen here within the next two weeks, I have some cleanup to do: https://demozoo.org/productions/312271/

/Troed

[tin]

Very nice finding. looking forward to the final version! FWIW: I talked to ijor in 2016 about sth along that line (albeit just for "normal" sync scroll) based on my external sync hardscroll I did in '90/'91 - I hoped when recrating that (in 2016) to kinda stop the internal clock there, too, but ultimately failed (as in: I couldn't get the scroll running as it did bitd). We concluded it would be sync altering anyway and I just had "luck" with my setup back then.

[troed]

based on my external sync hardscroll I did in '90/'91 - I hoped when recrating that (in 2016) to kinda stop the internal clock there, too, but ultimately failed (as in: I couln't get the scroll running as it did bitd). We concluded it would be sync altering anyway and I just had "luck" with my setup back then.

I _think_ you could do a one line sync scroll using external sync (and yes, it would be difficult to avoid sync alternation) but it would require you to have a plug in the monitor port (or the right monitor) so that the signal doesn't float.

It's theory - I have noted it but not tested.

[tin]

I _think_ you could do a one line sync scroll using external sync (and yes, it would be difficult to avoid sync alternation) but it would require you to have a plug in the monitor port (or the right monitor) so that the signal doesn't float.

It's theory - I have noted it but not tested.

That‘s exactly what happened - I sent my working one line syncscroller to my peers back in ´90, proud as can be - and the feedback was „well, did not work here“. I _suspected_ the cable (resp. the others’ connection to float), but as we weren‘t in the „special hw requirements needed for this effect“ business, plus it was hard to test over distance, I dropped the whole endeavor.

My retest had a defined low resp. high ofc but I ran into sync altering problems and basically stopped for the same reasons as 30+ years before.