<MDPP Image File Header> <Contour File Format> <Fixing the FFT Params> <MDPP Internal Data> <Making MENU help> <Adding an MDPP Command> <Open files in MDPP> <Tips for UNIX Users>
Varbl Offset Length Type Descriptn Name (bytes) (bytes)(ricL)T1 0 8 c Header-1 bytes 1-8 T2 8 8 c Header-1 bytes 9-16 T3 16 8 c Header-2 bytes 1-8 T4 24 4 c Header-1 bytes 17-20 IX 28 4 i Record length ION 32 4 i InCore/OnDisk switch IY 36 4 i Number of records IS 40 4 i Data type IR 44 4 i Disk buffer switch IG 48 4 i Internal format type (real:0/word:1/byte:2) KZ 52 4 c Job-step indicator JBS 56 4 i Main buffer size T5 60 2 c Header-2 bytes 9-10 ITX 62 4 i X-dimension ITY 66 4 i Y-dimension ITZ 70 4 i Z-dimension XX_SCALE74 4 r X-scale YY_SCALE78 4 r Y-scale ZZ_SCALE82 4 r Z-scale VERSYM 86 4 c Identifier for header/file format MM_LOAD 90 4 L Logical- True if ama,ami defined AMA 94 4 r Maximum of array AMI 98 4 r Minimum of array XMEAN 102 4 r Mean of array IOFX 106 4 i Array offset X IOFY 110 4 i Array offset Y IOFZ 114 4 i Array offset Z MAPTYP 118 4 c Color Map type CLRMAP 1024 1024 b 4x 256-byte color maps/256 real RMAP
The MDPP header is 2048 bytes long. The image information begins with an offset of 2048 and is written as a continuous stream of data with the X coord fastest, Y next and followed by Z.
The final step was the modification of `VERSYM' to indicate the internal format of the data within the file. Currently VERSYM can have its old value ("1 "), which means VAX G-Floating reals and normal (for the VAX) byte order for the integers. Additionally it can have the form "2mn ". Here the character "m" can be one of the following:
Summary of charcters in VERSYM: VERSYM(1)/0 Old VAX/VMS BMD format: no extended header info. 1 Extended info, VAX/VMS format 2 Extended info, multiplatform support VERSYM(2) 0 - VAX/VMS floats, 1 - IEEE floats DEC, 2 - IEEE floats SGI/SUN VERSYM(3) 0 - DEC byte-order, 1 - SGI/SUN byte order Note:: For VERSYM(1)=0 or 1 VERSYM(2,3) is assumed to be (0,0) i.e. VAX/VMS.
The file consists of three levels of contol: 1) the FILE control block, 2) the LEVEL control block, and the 3) CONTOUR control block. Each control block defines elements of the contour which may be required. All control blocks are required, even if a single contour is to be stored. Note that all numbers are REAL*4 even though many values are integers.
The format is as follows:-
FILE Control block: length=14
Variable Offset FunctionNLEV 0 Number of levels in file TCONTR 1 Total number of contours in file TPNT 2 Total number of contour points in file TLENG 3 Length of file XDIM 4 X-dimension of array YDIM 5 Y-dimension of array XSC 6 X aspect ratio YSC 7 Y aspect ratio FLAG 8 Flag (undefined) TITLE 9 Title, 5 reals
Variable Offset FunctionLEV 0 Level ID (e.g. level number) LCONTR 1 Number of contours on this level LLENG 2 Length of this level Z 3 Altitude of this level LXDIM 4 X-dimension of array LYDIM 5 Y-dimension of array LXSC 6 X aspect ratio LYSC 7 Y aspect ratio FLAG1 8 Flag (undefined) FLAG2 9 Flag (undefined) FLAG3 10 Flag (undefined) FLAG4 11 Flag (undefined)
Variable Offset FunctionFollowing each of the CONTOUR control blocks there is the contour data, consisting of NPNT coordinate-pairs defining the contour.KNT 0 Current Contour ID (e.g. contour number) CLENG 1 Length of segment NPNT 2 Number of points on contour FLAG 3 Contour type (closed 0; open 2) LENGTH 4 Perimeter length of contour AREA 5 Area of contour CID 6 Unique contour ID FLAG1 7 Flag (undefined) FLAG2 8 Flag (undefined) FLAG3 9 Flag (undefined)
The 'main' program is CMPLFT. Inside this there is a paramter called PMAX, which is the maximum factor allowed, TWOGRP which is the highest power of two it can deal with as a single factor. Inside the subroutine SRFP there is a paramter called NEST (=14). This is the hard-wired maximum depth of the factors. You can not have a dimension that has more than 14 factors. This is probably not something you need to change, and it would be difficult to do this without a significant chance that you would screw up.
The place where a change is needed is inside RPCFTK, the prime-factor FT module. There is a parameter called HIPRIME (=53). Change this parameter to match the modified value of PMAX in CMPLFT and I think you are set.
Finally, if you are using MDPP (what else) you need to change the FCTSRC entry in GENORG. Alter this to reflect the increased prime factor, or FCTSRC will block attempts to use the increased prime-factor range that you just engineered.
This should be tested to ensure that these hard-wired buffer arrays do not go out of bounds. Try a few forward and reverse FFTs to make sure that you are always within the rounding errors.
etc.....
The formats of the different blocks is:-
FILE BLOCK: Length 14 words. 1. Total No. of Levels 2. Total no. of contours 3. Total no of contoured points 4. Length of file 5-14. Reserved.
LEVEL BLOCK: Total length 12 words. 1. Level number 2. No of contours on this level. 3. Length of this level (including all the contours, obviously!) 4. Z altitude of this level. 5-12. Reserved.
CONTOUR BLOCK: Total length 10 words. 1. Contour number 2. Length of contour (L) 3. No. of points in the contour 4. Contour type. 5. Contour length 6. Contour area 7. Contour Specific identifier 8. Contour Class identifier 9-10. Reserved. Contour data for a given contour is: 11-L. Pairs of contour points.
Each file has one FILE BLOCK and at least one level. Each level has one LEVEL
BLOCK and an arbitary number of CONTOURS (including zero): each set of contour points is preceded by a CONTOUR BLOCK to identify it. (An empty level has no contours, and therefore no contour blocks).
The STORE paramters are 80,N where N is calculated as: ((Tot_leng-1)/80+1)
The trick is to make the HELP files and identify them to MDPP. The help file system uses the standard VMS help library, and the system services to read them. The file to be read is identified by the logical definition MDP_MENU_HELP: e.g.
"$DEF MDP_MENU_HELP DISK:[USER]MY_MENU.HLB"
The help library, "MY_MENU.HLB", is created by the user, and the definition of the logical is made in the LOGIN.COM file, or wherever else the other logicals are defined.
Creating the help library file is simple. The user uses the editor to create a file called MY_MENU.HLP, and then creates the library from it with the VMS command:
"$LIB/HELP/CREATE MY_MENU MY_MENU"
which creates MY_MENU.HLB from the editor-generated file MY_MENU.HLP.
The structure of the HELP file is key, of course. General background reading should be the VMS manuals on HELP librarys and their creation and maintenance.
The help library is accessed via two keys, the menu title and the menu entry number. The menu title is defined by the line in the menu definition file begining with the MENU: command. The entry number is the number found in the first column of the body of the menu.
Only the first word in the MENU definition is used, so this word must be unique for the entire menu: "The Main Menu" is a poor choice of menu defintion, particularly if a sub-menu is defined as "The Sub-Menu" (in this case there would be two key entries called "The" and the library would become confused, the program would crash, the computer would blow up, a truck would run over your dog and your aunt would leave all of her money to the milk-man: don't do it.) Pick nice action-packed words like "First", "Digitize", etc.
The .HLP file is written with a "1 " preceding the key words for the menu or sub_menu, and "2 " in front of the number defining the entry. The following is a sample file, as it would be created by the editor.
.... (more)
.... (more)
Once the menu help file is complete, you can 'compile' it into the library, set up the defintions, and with luck a help request within the program will be answered!
Note that you may have several help libraries, one for each of the menu you have. Another method, however, is to build each individual menu package out of modular blocks of pre-tested, distinct sub-menus (i.e. if you need a DIGITIZATION sub-menu, always use the same one.). If all the sub-menus are distinct, then all the menu help can be loaded into a single .HLB library, and the system routines will extract the bits they need. This simplifies maintenance for user support (e.g. when running a course, etc.)
UNIT NAME FUNCTION1 * I/O for the saved images 2 FOR002.DAT Subsidary disc buffer 3 FILE3.DAT Unit 3 disc buffer (images) 4 FILE4.DAT Unit 4 disc buffer (stacks, FFT, etc) 5 * Input of commands to MDPP 6 * Output of prompts, data, info from MDPP 7 TT: Fixed to terminal for output. 8 TT: Fixed to terminal for input. 9-17 * LOOP processor (INPT n) 18 INPUT.LOG Input logging file 19 OUTPUT.LOG Output logging file 33 * Output log file from MACRO processor (appended to 6)
Note that most files remain closed, in particular files 9-17 are nearly never used. Files 7 & 8 are used for executive control of MDP and are nearly never accessed, however, they must be open and should not be used for command control of MDP. In operation the maximum number of files actually open at once is 7 (i.e. 1,3,4,5,6,7,8).
Hope this is helpful!
Printing
Many of the files to be printed are spooled automatically as the command exits. For this to happen, FORTRAN looks for a printer called 'lp'. If it can not find one it prints the message 'lpr: can not find printer lp', or some such stuff. To fix this, go to the /etc/printcap file and make sure that there is a printer in there called 'lp', as in this example.
# @(#)printcap 3.1 (ULTRIX) 4/20/90
lp|l0|local line printer:\
:lp=:\
:rm=mcclb0:\
:rp=sys$print:\
:sd=/usr/spool/l0:
This printer is attached to the VAX and is accessed via lpr.