This area contains skeleton code for a PortaCalc
version which will operate in very small environments by
using bitmaps, etc., for storage. The WRKFIL and WRKSHT
routines are called whenever the work file was accessed
or VBLS, FVLD, or TYPE are called.
	Note that to gain space, the multiple precision
integers are reduced to 20 characters' length from 100.
NOTE: THERE IS ONE DIFFERENCE IN PROGRAM USE SYNTAX BETWEEN
THIS VERSION AND OTHER PORTACALC VERSIONS:
The command R (recalculate) in this version recalculates the
sheet, but does NOT force recalculation of constants. The command
RF recalculates and DOES FORCE recalculation of constants (and the
command RR is a synonym for RF). RF can be read as "recalculate, force".
In the OTHER versions, R forces recalculation of constants, and RAF
recalculates everything except constants. Note that RAF in this
version works as it does in others; bare R however has changed.
Otherwise this version has the capabilities of the full VAX
versions, except the *U XQTCM function is not available (and will
not be until a larger machine that permits major mods to the overlay
structure is available.)

Strategy:

	Use 3 bitmaps for FVLD to represent legal states
of FVLD bytes. Make a 3 bit number up from the 3 bits and
treat as signed in range -3 to +3.
	Use 1 bitmap for TYPE array for sheet; 0 means
type 2 (real); 1 means type 4 (integer). For accumulators
(1st 27 items), keep full integer array of types however.

	Keep 45 format entries resident, filling new areas
in as needed and reusing the last if the area overflows
(which will seldom happen in real life). Point to the
format number with a byte in the formula.

	Values and formulas are kept in separate areas by a
symbol-table type algorithm. This will treat memory areas
for each as one "page" of a file whose size is given at
runtime (and not opened if too small). Cells are 10 bytes
long for values (ID plus 8 byte number), 16 bytes long for
formulas (ID, format number, flag (for first/middle/last
cell for a formula), and 12 bytes of formula per cell with
continuations permitted.)
	On write to a cell, the page is calculated and a
hashcode used to find start address in the page to look for
space to put the cell. Linear search, in that memory page
only, is used to find free space (initially all old refs are
cleared). For formulas, cells are allocated until the entire
formula is stored. Readback reads the cells starting at the
hashcode and continuing by linear search if need be. Formula
storage and retrieval is done by linear in-memory search using
the hashcode only in computing the page to use. Unit 7 is formula
file, and 9 is value file. This permits some flaky running out
of room while the file still has empty space, but makes
search speed at least bounded. A big enough file will always
guarantee that a cell can have room found for it. Fixed cells
for formulae are used to reduce compaction problems.

	Other algorithms can be put in WSHEET and WRKFIL to
handle this differently, to tailor to random environments.
	This code works on VAX and runs in either native or
compatibility mode. It has been tried briefly on RSX and
looked OK (the build files may be deduced from the VAX compat
mode ones here) but was better tested on VMS. It IS designed
with ALL the capabilities of the VAX version except the
execution of commands from inside cells of forms like CA, CR,
etc. etc. and may be interesting for that reason.
It provides the largest PDP11 spreadsheet of any PortaCalc version
(around 16,000 cells fit; more may be possible) and should be
useful for that reason.
	Please send any versions you bring up as working back to
me in source, regardless of what machine they run on. In return
I may get you my latest mods and bug fixes.
			Glenn Everhart
			409 High St
			Mt. Holly, NJ 08060

	This version works on VAX, and may be movable to RSX11M+
systems with full functions. However, note that some displays
will appear to zero various displayed numbers. An extra V (View)
command will draw the display correctly if this happens. The CR
command is known to do this.
	The memory storage is small and backs up to disk files
during operation. The sizes are asked for at startup, and if they
overflow, (i.e., a PAGE fills), a message is given on screen. If
the sizes (in K bytes) for the files are given NEGATIVE, then a
different packing algorithm is used which requires more page
swaps, but may allow less dense use of the page file and permit
the same size disk files to handle more active cells. The trade-off
is speed.
	The sizes of memory areas are compiler parameters. The
file present is fairly conservative but may be made smaller
still. LVBF should be at least 50, and LFM at least 32, for
things to make sense.
	The files are NOT opened or used if the memory storage
sizes on file are less than the in-memory storage provided.
	This is the first version of PortaCalc which plays the
same dirty trick on you as commercial spread sheets. That is,
you have a fairly huge matrix, but can't fill in all of it
without overflow. However, by specifying a large enough file
for variables and for formulae, you can always get things
to fit.
	Variables are stored in 10-byte units (2 bytes for the
ID, 8 for the value), and formulas in 16-byte chunks, of
which 4 contain ID, format pointer, and flags, and 12 are
formula characters. A long formula will have multiple
formula nodes in the buffer. Most everything else is managed
with bitmaps, rubber bands, and chewing gum.
	Note this version is intended so that HELP can be in
a separate overlay from XQTCMD and CALC. Those must be
together to handle the new syntax of cell-controllable commands.
However, this may give enough room for any PDP11 to use the
thing by using the rest of the portacalc overlay structure
from the "standard" version. Be careful, however, to ensure
the commons in WSHEET and WRKFIL are resident in the root.
This will probably need some .PSECT statements or putting
them in the root (not a bad idea, really).
	Another help file source is here which will read a file
full of help pages and display the one desired. Experimenters may
want to use it and perhaps use the reclaimed space to enlarge the
in-memory buffers for value and formula pages.
	NOTE THAT THIS OVERLAY IS NOT FULLY DONE AND IS PROBABLY
INCORRECT IN SOME WAYS, though it runs OK.
	The overlay is just a start (though the resulting version runs)
but is complicated by the fact that CALC calls CMND which may
call USRFCT which in turn can call XQTCMD. Thus at least the
USRFCT main routine needs to be in the root so the call tree
works for that. Or the call to XQTCMD can be snipped out and
essentially the old tree structure used with WSHEET and WRKFIL
also in root. Note however that this version of XQTCMD is not
as broken up as the "standard" overlay version and the
put and get routines may need to be broken off to get things
to fit again. Try clustering or something if possible, on M.
On M+ with 11/44 or 11/70 or J-11, using I/D space and super mode
FCS should be a major win. Besides, you can overlay with I/D
space and just moving the HELP into a separate leaf ought to
buy a lot of space. HELP is only called from SPREDSHT (the main
program) so that ought to be OK.
	A second HELP subroutine, which uses a big help file
on disk and prints it, is supplied; it may allow a much smaller
help overlay and perhaps buy space. You can experiment with
virtual arrays or mapping to regions inside the WSHEET or
WRKFIL routines, since they are the ONLY ways the program
gets to its storage. For those who REALLY want a fast access,
look over the BASH11M program of a few tapes ago; you may be able
to bypass RSX almost totally and use a dedicated common partition
to run from on a Pro if in previous-kernel mode. This could reclaim
almost the entire space needed for buffers.

	The Best things in life are free!
		PORTACALC