Proof of Concept 1: Double buffered smooth sinus Dots by Defence Force [web]

          Proof Of Concept #1: 
    Double buffered smooth sinus Dots
     AN ORIC ATMOS technological demo
        Release date: March 2006
 _|       |
|    _   _|
|   '-' | |___e_f_e_n_c_e
|         |
|  _______|
|   ___/______o_r_c_e

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.

To contact me:
	- dbug@defence-force.org
	- http://www.defence-force.org
	- http://www.defence-force.org/computing/oric/index.htm

	#oric on IRCnet 

oric forum:
	- http://forum.defence-force.org

Other Defence Force Oric productions:
Buggy Boy - Made for LCP Party 2004 (Sweden)
- http://www.pouet.net/prod.php?which=13000

Barbitoric - Made for Alternative Party 2003 (Finland):
- http://www.pouet.net/prod.php?which=8558

Assembly 2002 invtro - Made for Assembly 2002 (Finland):
- http://www.pouet.net/prod.php?which=6977

Quintessential - Released at the VIP4 (FRANCE) demo party in 2003:
- http://www.pouet.net/prod.php?which=6864

Oric Giga Demo - Released at the VIP3 (FRANCE) demo party in 2002:
- http://www.pouet.net/prod.php?which=3102

STNICCC C64 Revisited - Released at the STNICCC 2000 (HOLLAND) demo party in 2000:
- http://www.pouet.net/prod.php?which=3105	
Just Oric - Released at the Volcanic 4 (FRANCE) in 1997
- http://www.pouet.net/prod.php?which=3131