Release Notes for AnalytiCalc/Amiga Second major release, 8/31/1987 AnalytiCalc now uses only 2 windows (using a kludge workaround of the Fortran problems) for its input, sized for interlace windows. It also (finally) uses a RAW: window for the main spreadsheet and knows how to parse escape sequences. Thus the arrow keys work, and the help key does also. Also keys F1 to F10 become the commands @dk:AKA.CMD to @DK:AKJ.CMD. To use this, assign somewhere as DK: before running and place command files in as desired. The keymap file supplied will still work, but is not necessary (and in a multitasking system, not especially desirable). You can use commands S followed by suitable DB commands to size the sheet area to fit the window you want to use. A last note: The program executable supplied was obtained by concatenating all sources and compiling THAT followed by linking in the Fortran runtime pieces. Separate compilations are not working as well for some reason. This is being investigated. If you rebuild, I suggest that technique for the time being. If you strip out all comment lines, the resulting program fits on a floppy with the compiled output easily enough. I compile and link in ram: however. Note that the subroutines in AnalyO.Ftn can be overlaid against each other. I intend to try this to see if a 512K version of AnalytiCalc can be devised. I am not very optimistic however. I suspect you'll just need a meg to run AnalytiCalc (more memory is OK too), but will try for a shrink job. Anyone who beats me to it and can get AnalytiCalc running in 512K please let me know. The lower window is for line-oriented commands and you WILL see prompts in it when input is needed there. Sorry, but you'll have to click in it until I figure out if there's any way to automagically activate the window though (there may be some escape sequence; I just haven't looked at it yet.) Subroutine VWRT writes the prompts and would be where such an escape sequence should be written. Initial Version (6-Oct-1987) This version of AnalytiCalc uses 3 windows (due to some problems encountered trying to get Fortran to talk to one or two). The main window occupies the top half of the (interlaced) screen and is the place the main spreadsheet activities take place. It permits both input and output. The next lower window is for prompts and only gets typed to by the program. You should NEVER input to it, and need never select it. The bottom window is for inputs to answers to prompted questions (which are prompted for in the second window). Nothing is typed by the program to this window; YOU type in it. But you only type in it when prompted by a query in the second window. The rest of the time your input is in the main window. AnalytiCalc is set up to run on an interlaced screen and it can have its spreadsheet window expanded to fill as much of such a screen as you like. You need to use the S command to get questions to tell it how many rows to allocate, and then when back in the spreadsheet window use the DB ncol,nrow command to set up more rows (and columns if desired) on the sheet. AnalytiCalc may not fit in 512K; I don't know. (Someone please tell me!) It should have NO problems in a meg or more; it was developed on my 1.5 meg A1000. AnalytiCalc is REAL slow closing saved spreadsheet files for some reason. WAIT; it'll finish eventually and the saved file WILL be OK. You'll need to issue a SETMAP function to get function and arrow keys to generate commands AnalytiCalc can use. The necessary keymap file will be found in with the executable file. Basically all keys will generate commands of form @AK:F01.CMD or the like, where F01, F02, F03,... represent function keys. These files will have to be somewhere assigned to the logical name AK:, or the keymap file will have to be altered. For now, the help file will be the same as the MS-DOS file, which shows 10 function keys, but in the IBM PC layout. The definition files will be arranged however so they'll work OK on Amiga. I regret (to some extent) a user interface like this. The program does essentially all output control via the UVT100 and SWRT subroutines, and does main window input via GETTTL, so a better standardized interface is possible. But to get something working, a CON: window was fast and easy, and unfortunately replacing it with a full menu-ized system in Fortran is not easy. Absoft has helped by releasing V2.3 of their compiler with a lot of examples, but for now, I hope the program is useful as is. Glenn Everhart 25 Sleigh Ride Rd. Glen Mills, PA 19342 Further tips: AnalytiCalc uses a software paged virtual memory system for its' formulae and values, with two pages in memory. These are fairly large, enough for 800 or so formulas, but it's not too hard to put AnalytiCalc into a thrashing mode. If your default directory when you run it is on floppy, that can GREATLY slow the program down. I suggest that for most problems you try telling AnalytiCalc to make the formula and value files each 1K long, which will make it use memory buffers only (they're bigger than 1K, and will all be used). If you run out of room, a message will flash on screen that the value or formula file ran out of room. Your action then is to go to cell A1, save the sheet, and rerun AnalytiCalc and specify a larger file. DON'T make the files hugely larger than they need to be; that generates thrashing. Also be aware that the storage is by rows, so that cells on the same row get stored close to each other. A long column can however easily fill some of each of the pages of disk file. Most times the memory buffers are sufficient for anything reasonable you'll want to do. The virtual memory is to let you do those really huge jobs if they can't be linked... Virtual memory files are allocated on the default device. If you do a "cd ram:" before running Analy, you'll then have these files on the ram: disk and the virtual memory system will work a lot faster. AnalytiCalc does NOT grab buffers dynamically in any other way than as disk files (it's not so easy to do that in Fortran...) AnalytiCalc will be set up with a custom keymap. You'll need to use the AmigaDos 1.2 SETMAP command to use that keymap before running AnalytiCalc. I may include two keymaps, since the keymap is used for all tasks. The keymaps will all affect F keys, but my current thinking is that only one should change the arrow keys. The other should use some of the auxiliary keypad keys as pseudo arrow keys, leaving the "real" arrow keys alone. In this way the arrow keys remain useful in any editors you may fire up. A later version will switch to using the raw: device rather than the con: device, and will learn to parse the escape sequences. Much of the code for this exists now but not quite enough to use. If you don't use a keymap, you must use the 1,2,3,4 commands to move... they are in the order 1 2 3 4 up down left right ^ v < > (which happens to match the order of arrows on a VT100 keyboard).