fVDI technical information

This page tries to describe how fVDI is designed and how it works internally. I know it's not very easy to follow right now but, hopefully, that will change over time.
The original design/implementation plan is also available. Among other things, that document talks about new features that have been considered for fVDI.

Note that not many things in this document have been updated since '97 or so. Significant things are missing, but I am in the process of updating the text. fVDI has been very nearly complete in its implementation of the standard VDI and GDOS for many years now.

Actual output functions supported

• Complete accelerated vro_cpyfm (normal blitting) that appears to work fine.
  There's specialized code for the most common case, D = S, and the rest are handled by calling small subroutines for every word.
• Complete accelerated vrt_cpyfm (mono expand blitting) which seems to be fine.
• Accelerated rectangle fills, but with limitations on what patterns can be used. No outlines etc are done. A strange clipping problem remains to fix.
• Normal text drawing accelerated via calls to vrt_cpyfm.
  Any GDOS bitplane font should work, but only at its standard size (no automatic doubling) and no special effects are supported.
• Accelerated line drawing (actually no support yet for unacclerated), but only single pixel, solid, replace mode (and vertical/horizontal XOR mode) lines can be drawn.

Support functions implemented

Mostly parameter set/get things necessary for the above.

Functions that a driver can currently accelerate

• Pixel get/set
  This is actually needed rather than being an acceleration option.
• Line draw
  Without this there would be no lines with the current fVDI version, but it also accelerates solid fills (if there's no accelerated fill).
• Expand
  The expansion of monochrome images to whatever screen mode is being used.
  This is the same as the vrt_cpyfm operation and is normally used for icons and such things. Under fVDI it also accelerates all text drawing.
• Fill
  The normal 'fill rectangle from monochrome pattern' operation.
  This will of course be used instead of the line drawing for solid fills if it's available.
• Blit
  Moves memory areas around while doing various operations on them.
  This is the same thing as the vro_cpyfm operation and is used for scrolling in most programs and for drawing colour icons.

fVDI internal operation

VDI initialization happens like this:

• The main engine sets up a default workstation and virtual workstation.
• C:\FVDI.SYS is read and all specified fonts and drivers are loaded.
  Right now only one driver is actually supported, though.
• When a driver has been successfully loaded and relocated, its initialization function is called, with the default virtual workstation as parameter.
  The idea is that the drivers should be able to copy most things straight off and then update what's necessary. To simplify the current v_opnvwk routine (and remove the need for a real v_opnwk), the default structures are updated instead (thus only one device driver). Apart from setting various screen parameters, the initialization sets up addresses for set_pixel, get_pixel etc. A driver could also include replacements for some higher level VDI calls.

Calls to the VDI are dealt with in the following way:

• A table is kept which translates all normal VDI handles to pointers to the structures fVDI has created instead. Naturally, this means that the underlying VDI needs to be called for example at v_opnvwk or v_clsvwk.
• All the normal VDI functions are called with a0 pointing to the correct VDI struct and a1 to the standard parameters block. Where necessary, this is converted to library calling conventions.
• The 'library' VDI functions are called with a0 as above, but with a1 pointing to something much like the stackframe of a C VDI call.
  Currently only v_gtext, vrt_cpyfm and vro_cpyfm are available in library form.
• The hardware access functions (set_pixel etc), which are normally accessed via appropriate write mode specific routines, are supplied with a pointer to the current workstation struct via a0. They use this to access all information about the screen layout.