Sync-tricks/fullscreen discussion

GFA, ASM, STOS, ...

Moderators: simonsunnyboy, Mug UK, Zorro 2, Moderator Team

slingshot
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2745
Joined: Mon Aug 06, 2018 3:05 pm

Re: Sync-tricks/fullscreen discussion

Post by slingshot »

(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
Captain Atari
Captain Atari
Posts: 301
Joined: Thu Jun 20, 2002 6:49 pm
Location: Luxembourg
Contact:

Re: Sync-tricks/fullscreen discussion

Post by 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! :lol: 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
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2745
Joined: Mon Aug 06, 2018 3:05 pm

Re: Sync-tricks/fullscreen discussion

Post by slingshot »

Gunstick wrote: 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
Captain Atari
Captain Atari
Posts: 301
Joined: Thu Jun 20, 2002 6:49 pm
Location: Luxembourg
Contact:

Re: Sync-tricks/fullscreen discussion

Post by 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
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2745
Joined: Mon Aug 06, 2018 3:05 pm

Re: Sync-tricks/fullscreen discussion

Post by 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
Captain Atari
Captain Atari
Posts: 301
Joined: Thu Jun 20, 2002 6:49 pm
Location: Luxembourg
Contact:

Re: Sync-tricks/fullscreen discussion

Post by 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
Captain Atari
Captain Atari
Posts: 301
Joined: Thu Jun 20, 2002 6:49 pm
Location: Luxembourg
Contact:

Re: Sync-tricks/fullscreen discussion

Post by 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
Last edited by Gunstick on Sat Feb 01, 2020 9:57 pm, edited 1 time in total.
User avatar
npomarede
Atari God
Atari God
Posts: 1441
Joined: Sat Dec 01, 2007 7:38 pm
Location: France

Re: Sync-tricks/fullscreen discussion

Post by 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
User avatar
Cyprian
10 GOTO 10
10 GOTO 10
Posts: 2721
Joined: Fri Oct 04, 2002 11:23 am
Location: Warsaw, Poland

Re: Sync-tricks/fullscreen discussion

Post by Cyprian »

Lynx I / Mega ST 1 / 7800 / Portfolio / Lynx II / Jaguar / TT030 / Mega STe / 800 XL / 1040 STe / Falcon030 / 65 XE / 520 STm / SM124 / SC1435
DDD HDD / AT Speed C16 / TF536 / SDrive / PAK68/3 / Lynx Multi Card / LDW Super 2000 / XCA12 / SkunkBoard / CosmosEx / SatanDisk / UltraSatan / USB Floppy Drive Emulator / Eiffel / SIO2PC / Crazy Dots / PAM Net
Hatari / Steem SSE / Aranym / Saint
http://260ste.atari.org
Gunstick
Captain Atari
Captain Atari
Posts: 301
Joined: Thu Jun 20, 2002 6:49 pm
Location: Luxembourg
Contact:

Re: Sync-tricks/fullscreen discussion

Post by 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.
User avatar
npomarede
Atari God
Atari God
Posts: 1441
Joined: Sat Dec 01, 2007 7:38 pm
Location: France

Re: Sync-tricks/fullscreen discussion

Post by 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
Atari User
Atari User
Posts: 37
Joined: Sun Jan 22, 2017 12:10 pm

Re: Sync-tricks/fullscreen discussion

Post by 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...
User avatar
Cyprian
10 GOTO 10
10 GOTO 10
Posts: 2721
Joined: Fri Oct 04, 2002 11:23 am
Location: Warsaw, Poland

Re: Sync-tricks/fullscreen discussion

Post by Cyprian »

Gunstick wrote: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?
Lynx I / Mega ST 1 / 7800 / Portfolio / Lynx II / Jaguar / TT030 / Mega STe / 800 XL / 1040 STe / Falcon030 / 65 XE / 520 STm / SM124 / SC1435
DDD HDD / AT Speed C16 / TF536 / SDrive / PAK68/3 / Lynx Multi Card / LDW Super 2000 / XCA12 / SkunkBoard / CosmosEx / SatanDisk / UltraSatan / USB Floppy Drive Emulator / Eiffel / SIO2PC / Crazy Dots / PAM Net
Hatari / Steem SSE / Aranym / Saint
http://260ste.atari.org
User avatar
npomarede
Atari God
Atari God
Posts: 1441
Joined: Sat Dec 01, 2007 7:38 pm
Location: France

Re: Sync-tricks/fullscreen discussion

Post by 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
Hardware Guru
Hardware Guru
Posts: 4346
Joined: Sat May 29, 2004 7:52 pm
Contact:

Re: Sync-tricks/fullscreen discussion

Post by ijor »

frank71 wrote: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.
Fx Cast: Atari St cycle accurate fpga core
ijor
Hardware Guru
Hardware Guru
Posts: 4346
Joined: Sat May 29, 2004 7:52 pm
Contact:

Re: Sync-tricks/fullscreen discussion

Post by ijor »

Cyprian wrote:What about Video counter? Was it reset as it is done in VBL?
npomarede wrote: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.
Fx Cast: Atari St cycle accurate fpga core
User avatar
Cyprian
10 GOTO 10
10 GOTO 10
Posts: 2721
Joined: Fri Oct 04, 2002 11:23 am
Location: Warsaw, Poland

Re: Sync-tricks/fullscreen discussion

Post by Cyprian »

ijor wrote: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
Lynx I / Mega ST 1 / 7800 / Portfolio / Lynx II / Jaguar / TT030 / Mega STe / 800 XL / 1040 STe / Falcon030 / 65 XE / 520 STm / SM124 / SC1435
DDD HDD / AT Speed C16 / TF536 / SDrive / PAK68/3 / Lynx Multi Card / LDW Super 2000 / XCA12 / SkunkBoard / CosmosEx / SatanDisk / UltraSatan / USB Floppy Drive Emulator / Eiffel / SIO2PC / Crazy Dots / PAM Net
Hatari / Steem SSE / Aranym / Saint
http://260ste.atari.org
ijor
Hardware Guru
Hardware Guru
Posts: 4346
Joined: Sat May 29, 2004 7:52 pm
Contact:

Re: Sync-tricks/fullscreen discussion

Post by ijor »

Cyprian wrote: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.
Fx Cast: Atari St cycle accurate fpga core
User avatar
npomarede
Atari God
Atari God
Posts: 1441
Joined: Sat Dec 01, 2007 7:38 pm
Location: France

Re: Sync-tricks/fullscreen discussion

Post by npomarede »

ijor wrote: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
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2745
Joined: Mon Aug 06, 2018 3:05 pm

Re: Sync-tricks/fullscreen discussion

Post by slingshot »

npomarede wrote: Fri May 08, 2020 9:00 pm
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
Hardware Guru
Hardware Guru
Posts: 4346
Joined: Sat May 29, 2004 7:52 pm
Contact:

Re: Sync-tricks/fullscreen discussion

Post by ijor »

npomarede wrote: Fri May 08, 2020 9:00 pm 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.
Fx Cast: Atari St cycle accurate fpga core
User avatar
troed
Atari God
Atari God
Posts: 1635
Joined: Mon Apr 30, 2012 6:20 pm
Location: Sweden

Re: Sync-tricks/fullscreen discussion

Post by 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.
ijor wrote: Sat Dec 09, 2017 4:56 am 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
Obsessive compulsive Atari behavior
Obsessive compulsive Atari behavior
Posts: 135
Joined: Mon Jul 23, 2012 7:59 am
Contact:

Re: RGB2HDMI for ST

Post by 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.
Last edited by tin on Sun Aug 14, 2022 6:57 pm, edited 1 time in total.
User avatar
troed
Atari God
Atari God
Posts: 1635
Joined: Mon Apr 30, 2012 6:20 pm
Location: Sweden

Re: Sync-tricks/fullscreen discussion

Post by troed »

tin wrote: Sun Aug 14, 2022 5:24 pm 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
Obsessive compulsive Atari behavior
Obsessive compulsive Atari behavior
Posts: 135
Joined: Mon Jul 23, 2012 7:59 am
Contact:

Re: RGB2HDMI for ST

Post by tin »

troed wrote: Sun Aug 14, 2022 6:34 pm 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.
Post Reply

Return to “Coding”