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)