The Sinclair QL Forum

Is there any possibility to get an info that QL is ready with redrawing of the screen so I can update the screen memory (using some cycles) without the effect of flickering?

Did you experience any flickering when you didn't?

Flickering typically occurs on concurrent access to memory (like on old IBM CGA video adapters) - This doesn't happen on the QL - The CPU always waits until the ULA has drawn the screen.

Tobias

It's also an option to turn the video display off while the screen is being redrawn, so the redraw happens during the dark spell, if that is the effect you're trying to achieve?

Dave wrote:It's also an option to turn the video display off while the screen is being redrawn, so the redraw happens during the dark spell, if that is the effect you're trying to achieve?

Yes, exactly. I know it from Amiga where you can query if the redrawing of the screen is ready, allowing making some changes within some CPU cycles (like "move" a part of screen) without flickering or similar. How can I achieve this on QL? Would it be a right idea to switch between screen#0 and screen#1?

grafvonb wrote:

Dave wrote:It's also an option to turn the video display off while the screen is being redrawn, so the redraw happens during the dark spell, if that is the effect you're trying to achieve?

Yes, exactly. I know it from Amiga where you can query if the redrawing of the screen is ready, allowing making some changes within some CPU cycles (like "move" a part of screen) without flickering or similar. How can I achieve this on QL? Would it be a right idea to switch between screen#0 and screen#1?

That's something different, then. Apparently, you want to make sure that your complete screen drawing is done in exactly one update cycle. That could be achieved by using the second screen as a back buffer, and switching back and forth between screens, making sure you never update the one currently on display. Quite some games use this method, however, some QL compatibles and emulators don't support the second screen.

Another method, which is horribly inefficient, is, synchronize your screen updates with the 50Hz interrupt (polling interrupt) - You can hook a routine to the polling interrupt, spend some cycles in a busy wait loop and then start drawing. This will make sure your access to screen memory happens during flyback - Note the original QL isn't exactly a racehorse, so the amount of update you can do there is quite small. Also, note that not all programs are executed at the same speed - If your program runs in contended memory (lower RAM shared with the video circuitry) your code will run around half the "normal" speed. In upper RAM, speed might depend on the quality of your memory expansion. Here, "speed" mainly applies to the "spend some cycles" thing mentioned above - This needs to be a timed loop based on cycle count, so must be adaptable between different makes and state of non-expanded and expanded QLs - so might be a bit tricky.

Tobias

Hi,

In the 1990s, I wrote some extensions to copy screen 0 to screen 1 or screen 1 to screen 0. Using the Minerva fast copy routine, detailed in the Minerva manual.

I never released them, as it was a fun exercise for me to do.

Of course, a section of memory could reserved to do the screen updates the same size as the screen 0 size. Not needing the second screen.

tofro wrote:
Another method, which is horribly inefficient, is, synchronize your screen updates with the 50Hz interrupt (polling interrupt)

Tobias

Wow, many thanks for your ideas. The 50Hz interrupt (7) was also my idea but this interrupt I just want to use to play "music" in background. So switching the screens might be the best solution....

Derek_Stewart wrote:Hi,
I never released them, as it was a fun exercise for me to do.

Wow, It would be great to see this code e.g. on GitHub? Please

Hi,

I remember that TURBO did some pretty nifty screen handling, via the MOVE_MEMORY routines.
These routines are easily emulated using PEEK$ and POKE$.

I used them a lot replaying screenfulls of precalculated perspective image frames, just like videos.
But you do need lots of memory to be comfortable. So I had to wait for QPC2 to get fast video replays.

My first Turbo program had just two 'screens' in 128ko, leaving very little room for programs...
So I couldn't really apply my programs until I could afford a gold card !

These days, virtual reality animation is available on most platforms.
Regards,
Steve Poole.

Maybe to state it clearly and I need your opinion if the whole story is possible.

I wrote some demos for Amiga in 90' but the QL... I'm just in love in this machine. My plan is to write a simple scroller (as I did for Amiga) but using just pure QL (68008) with 640k memory. Possible, without flickering?