        This area contains 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.)

	THIS PROGRAM IS NOW THE PREFERRED PORTACALC FOR PDP11 MACHINES
AND FOR FURTHER DEVELOPMENT. The command files ending in "NAT" were
set up to build a PDP11 .TSK image for RSX under VMS with the RSX TKB
task. For RSX, edit PCCPDP.COM into a .CMD file (take out $ signs
and be sure device defaults etc. are OK) and verify that the FCS11M.ODL
reflects your F77 installation (or fix it up with the F4P flavor if
using F4P); then build. The task WILL FIT on a PDP11 if F77 is used.
If you use F4P, be SURE the FCS11M.ODL reflects the F4P OTS so addresses
won't overflow. The capacity is around 16,000 cells on RSX (edit
PVKLUGPRM.FOR to change how they are assigned in rows and cols). If you
have the ability to use virtual arrays and/or I/D space, or FCSFSL
(you M+ jocks know what that is), DO SO and reduce the complexity of
the overlay structure. It probably won't fit flat, but every simplification
speeds up the program. You can also increase the in memory array sizes
with I/D space or FCSFSL (supervisor mode FCS) if your machine allows.
Again, the parameter file controls this.

VAX USERS:
	The PCCMAKIV.COM file builds a fairly respectable VAX version
of this program which uses less virtual address space than the "standard"
one. It does use memory arrays instead of files, but uses formula memory
more efficiently. I have begun putting the hooks for a Datatrieve
interface into it, which is not fully defined yet. However, the idea
will be that a command of the form DTR command will be stripped of
the "DTR" and passed to Datatrieve (so you can ready domains and
the like), and some functions of syntactic form *U DBxxxx will
generate calls (from inside any cell) to return values or text
from Datatrieve. This will allow you to avoid the present method
of creating sequential files (possibly from DTR) and then using
the *Q class commands to extract formulas or values from them;
you'll be able to grab the formulas direct. These functions will
be isolated into a set of separate routines to make it easier to
replace the DTR interface with one of your choice should you
so desire. We need it at my site, so I expect to get it done
sometime in the next 6 months or so; depends on timing of other
things at the office... (as usual). I want to retain the ability to
expand the number of cells greatly, so I will update this version
rather than another. The "standard" VAX version uses much more space
because it uses 128 bytes per formula entry accessed. This will
quickly run out of room (even on a VAX) if the number of cells
increases by an order of magnitude or two. The version here will not
so easily run out, since it does not require memory for every cell.
Nevertheless, the parameters set up by default here (i.e., unless
you edit BVKLUGPR5.FOR) allocate memory for 4 formula nibbles
(12 characters each) per cell. 8 bytes per cell for values are
also used, but this will not cause trouble on a VAX even with much
larger sheets, and the bitmaps will cause no trouble either. You can
run out of space on this version, but only if you have an average of over 48
characters in every cell addressable. This is unlikely except in the most
extreme cases. If it happens, edit BVKLUGPR5.FOR and increase some
of the parameters to get more room. LPDM and LPDMF are the ones to
raise.
	If anyone out there is using this program, I appreciate hearing
about it. Usually I hear about troubles, but appreciate hearing that it
was used for something. I'd also like to encourage anyone who develops
templates to this spreadsheet to submit them to the VAX and RSX SIG
tapes so they can be shared by others. I get very little feedback
from DECUS about who (if anyone) is ordering the Library version of
this program, and very little from users. If you use it, let me know.
Thanks. By the way, please note the "announce.mnt" file in the main
documentation directory announcing my (extremely cheap but not free)
IBM PC or general MSDOS version of PortaCalc, called AnalytiCalc. It
is descended from this version too.
		Glenn Everhart
		409 High St.
		Mt. Holly NJ 08060

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 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

	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.
Entering a size of 1 will ensure only memory is used. Entering
a 0 will pick a default file size.
	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.
	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.
	The overlay 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
	(alias AnalytiCalc)
