Re: [MiNT] WCOWORK implementation : conclusions.

[Johan Klockars <johan@klockars.net>]

> integration, but it will be fast, esp. with FastRam - fVDI already 
> does such things IIRC (if FastRam avialible, there is whole-screen 
> buffer in fastram, all operations are done on it, and modified parts 
> are copied to st-ram (with simple move it is fast)).

Actually, that's exactly what the SDL driver for fVDI under ARAnyM does.

The fVDI Atari mode drivers are a bit different. They do indeed have a 
whole-screen buffer in FastRAM (if you tell them to), but they never 
copy from that to the Atari screen. Rather, they draw to the buffer and 
the real screen concurrently, while reads are only done from the FastRAM 
buffer.
There is a number of "free" clock cycles available between every write 
to the Atari screen, so it's better to make use of them than to just 
wait as you would if you copied the data afterwards (you could also use 
those free cycles to do free 8 bit chunky to planar conversion while 
copying, but I've never gotten around to writing a driver that does that).

Another thing that the Atari mode drivers were supposed to do, but still 
don't because I got side-tracked with the Eclipse/RageII driver, was to 
only write to the Atari screen if the data actually changed. Very often 
an operation doesn't actually change everything and it could be useful 
to compare the new data with the old in the FastRAM buffer and only 
write to the Atari screen when needed.
When scrolling a normal text window, for example, you could likely often 
avoid half or more of the Atari screen writes since a lot of the screen 
would stay at the background colour.

Speeding up the screen on my AB040 Falcon this way was actually the main 
reason why I began working on fVDI nearly a decade ago. There was no 
documentation to be had on how to write an NVDI screen driver, so...   ;-)

--
| Why are these | johan@klockars.net
|  .signatures  |
| so hard to do | http://www.klockars.net
|     well?     | (fVDI, MGIFv5, QLem)