RL> Well, if you're going to request direct access through 
 RL> the hardware via the API's...  But if you're using the 
 RL> API's anyway why not USE them?  If you had to do a pair 

Because the APIs that are built in are extremely limiting.  Switching to PM
or DIVE would be preferable, but for FS graphics the Vio API is not enough
on its own.

 RL> of bios calls every time you wanted to do direct screen 
 RL> writes, what'd be the point?  (other than porting 
 RL> existing code?)

Using VioSavRedrawWait you only have to call them during session switches -
in the case of a good addictive game that might be once for each API per
run.  This is used in order to get notifications to save your session's
graphics 
screen (if you want to) and to restore your session's graphics screen
(either from your saved image or through redrawing it using existing code).
Using VioScr(Un)Lock instead of VioSavRedrawWait can be used nicely to do
basic functions like changing the palette, perhaps messing with the current
video registers, or doing direct writes in batches (perhaps once per video
page).  Obviously you don't want to do it once per pixel or in some other
loop that needs to be fast.  You also wouldn't want to constantly have the
screen locked since that interfeeres with session switches and may result
in your app being suspended like a DOS program.  If your application
absolutely must randomly (in time) write pixels and has no possibility of
batching them up for efficient use of VioScrLock then you should be using
VioSavRedrawWait.

The scenario in code goes something like this : 
      1 - set up a new thread (2) that blocks on VioSavRedrawWait
      2 - have your thread (1) go ahead with performing your updates
directly to the screen
      3 - a session switch occurs unblocking VioSavRedrawWait on thread 2
      4 - thread 2 notifies thread 1 to stop updating the video system
(probably a mutex semaphore)
      5 - thread 2 saves the screen to your own local video buffer which
will be dependant on your own SVGA code, which of course depends on which
video card you are using (one driver per chipset - yuck).
      6 - thread 2 toggles an indicator so that thread 1 will now perform
all updates directly to the lvb
      7 - thread 2 notifies thread 1 to continue processing
      8 - thread 2 blocks on VioSavRedrawWait again

I'm sure you can see how to achieve a session switch back again.

I have had another request for code to demonstrate this, so if there is
interest I could put something together for direct writes for the Tseng
4000.  If someone has the info for other cards required for detection, bank
switching, mode switching, or even a few accelerator primitives, then I
could try to include those as well.

--- Maximus/2 2.02