[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [MiNT] WCOWORK implementation : conclusions.




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)