• Hardware trick
    • Fabrice
  • Code and Graphics
    • Dbug


doublebuffer Oric demo

doublebuffer Oric demo



Proof Of Concept #1: Double buffered smooth sinus Dots (2006)

AN ORIC ATMOS technological demo
Release date: March 2006

About this demo

Well, first this is not really a demo.

There is no music, no scroll text, no particularly interesting things to see, and even worse: this is interactive !

The only interesting thing in this demo is that for the very first time (I guess at least), it shows an hardware accelerated (kind of: I just consider that since it is not software deaccelerated in some ways it could be considered as hardware acceleration) double buffering, associated to a perfect vertical synchronisation running at a flawless 50hz.

The gory details

The fact is the Oric does not have such thing as a VSync interrupt.
You can set a 50hz timer, sure, but you never know where the electron beam is at a particular moment, so you have no chance to be sure that what you are currently drawing is before or after the electron beam, resulting in some nightmarish animation and flickering sprites.

The solution to the VSync was found by Fabrice Frances -of Euphoric fame-, that got the idea to experiment with a simple wire connecting the SYNC pin of the RGB video output to the INPUT pin of the TAPE connector...

...the awesome thing is that this works perfectly, despite the fact that the SYNC pin transmit the vertical synchronisation as well as the horizontal one. Fortunately the filters in the ADC flatten out the horizontal sync parasites, and all that remains is a perfectly neat impulse every vertical blank.

This being this, everything is not perfect.

Ok it is now possible to draw things on screen knowin where the beam is, but it is quite hard to make a display routine efficient enough (in 6502 that's it) so it can draw everything from left to right and top to bottom so it never get passed over by the electron beam.

We need double buffering for doing that nicely.

And well, on the oric there is no such thing as double buffering, for a very simple reason: you cannot change the start adress of the video memory.

Whatever you do the high resolution video mode starts in $A000 and the text video mode starts in $BB80.

Yes !!! That's it ! The solution is clear:
Instead of "double buffering" using different adresses for a same video mode, let's just switch between the two different video modes alternatively at each new frame :)

And this work, as you can see in this simple demo.

Of course the implementation is horrible:
  • Two differents display routines to code
  • Two differents erasing routines to code
  • Two differents levels of CPU time occupation due to the asymetry of this scheme.
But well, it works, and I'm quite happy of this.

For the record, the first experiments were done in 2004 in the Crau'04 Party.

And here is a video of the demo in action: