🚀 go-pugleaf

	Hi everybody,
	Just thought I'd clear up the vro_copyform problem.

	vro_cpyform copies a rectangular bitmap from one location to another
based on bit boundaries. (vro_cpyfm is similar, so I will stick with 
vro_cpyform). The function looks like this:
	vro_cpyform(handle,wr_mode,pxyarray,psrcMFDB,pdesMFDB);

	"handle" is the VDIHANDLE previously obtained when opening the
application under GEM. (see graf_handle in documentation).

	"wr_mode" is the writing mode under which the transfer will be
performed. example direct transfer of bits, or source bits xor'd into
destination bits.

	"psrcMFDB" and "pdesMFDB" are pointers to "memory form definition
blocks". These are data structures that describe the memory areas being
transferd to or from (more later...).

	"pxyarray" is a standard GEM input array which describes the 
offsets and sizes of the rectangles within each memory area described by
the MFDB's that will be transfered.

	An MFDB is a 10 word parameter block consisting of:

(2 words) memory address of block in question. Please note that if this
          0, GEM will fill it in with the address of the current logical
	  screen.
(1 word ) block width in points.
(1 word ) block hieght in points.
(1 word ) block width in points/16 (words).
(1 word ) raster format flag. 1 indicates that the block is in a standard
 	  format suitable for transfering between, say color and b&w, or
	  even to IBM PC GEM. 0 indicates that the block is device specific
	  (0 is usually used).
(1 word ) number of planes of color. (1 for mono).
(3 words) reserved, make them 0.

	While I have never had to do memory to memory raster copies, I often
do memory to screen and the inverse, with no problem. Unless GEM is much more
brain damaged than anyone imagined, there should be no problem with memory to
memory.

						Pete Santangeli
						pete@utgpu
						     -----
						       ^
						       \__ new address!!