Msg: 4696 *Conference*
10-13-93 18:30:26
From: CARROLL LEWIS
To : ALL
Subj: SCREEN BUFFER
These are a set of programs that poke information into the PREVIOUS SCREEN BUFFER and a set of programs that read that same information. I HAVE NEVER TRIED TO "ENCLOSE" BEFORE. IF I CAN'T FIGURE IT OUT, THE PROGRAMS WILL BE A SEPERATE MSG CALLED "SCREEN PROG." In the model "T", when the command 'RUN"PROGRAMNAME"' is given, the computer clears all varibles, and unless ',R' followed the RUN command all files are closed as well. I wrote these routines so that varibles could be "passed" to another program. By using the pokes in one program and the peeks in another, the second program can continue without reentering basic info , or the flow of the second can be altered. I also use these, not only from program to program, but between banks on the XR4. The screen layout (and the pokes in these programs): adress +0 +10 +20 +30 +40 64704 AA*BBBBBBBBBBBBBBBBBBBBBBB**CC**DD**EE** 64743 64744 FFFFFFFFFFGGGGGGGGGGHHHHHHHHHHIIIIIIIIII 64783 64784 JJJJJJJJJJKKKKKKKKKKLLLLLLLLLLMMMMMMMMMM 64823 64824 NNNNNNNNNNOOOOOOOOOOPPPPPPPPPPQQQQQQQQQQ 64863 64864 RRRR********************************SSSS 64903 64904 !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! 64943 64944 !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! 64983 64984 !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! 65023 KEY: A. The LENgth of "B" B. The job name (client's last name) C. The total # of rooms. D. The # of the room "working" in part 1 of bid. E. The # of the room "working in part 2. F-O. The price of each room (figured in part 2). P. The total square feet of sheet stock used in all rooms. (from part 2) Q. The total estimated hours for all rooms. (from part 2) R. "Client" control poke. S. Control poke location for BID1, BID2, CONTract *. Spaces or not used. !. Used by the normal operation of the computer. NOT SUITABLE FOR USE! For example, I developed a program to do job bids for my cabinet shop. This program is really made up of 14 "gosubs". (all together they totaled about 17,000 bytes). Many of these are "stand alone" in nature.: CLIENT.ba (1,000 bytes) is a prompted format to create ADRS.DO records. My program BID.BA uses the SAME routine to establish the contract heading. Now with these POKE/PEEK routines "client" is only 84 bytes; the poke to the screen buffer and the RUN"BID.BA" command. BID.BA starts with PEEK and when it sees the poke from "client" runs only the client routine.(I saved about 900 bytes) With the XR4 I cut the BID program into 3 parts, each in a different bank. Happilly when the banks are switched the screen buffer is left intact so each new program can peek at the pokes and continue to run knowing the job name, number of rooms, what room is currently being worked on and finally the prices can be sent to the contract. Included is a short program MXROOM.BA that checks how many files exist. (The bid program creates 1 file for the job, and 1 file for each room.) The other programs are: 1. CTRPOK.BA: POKES the control words. 2. CTRPEK.BA: PEEKS for control words and responds accordingly. 3. NMPOKE.BA: POKES the job name. 4. NMPEEK.BA: PEEKS for the job name 5. PRCPOK.BA: POKES "prices". 6. PRCPEK.BA: PEEKS for prices and totals them up. 7. BUFCLR.BA: CLEARS the whole buffer. 8. SEEBUF.BA: BRINGS the previous screen buffer onto the display. Exit<CR> All of the above are the short "test" programs used in checking out if this stuff would really work. They really don't do much other than show one use for the SCREEN BUFFER. These have been installed into my programs (With some alterations) and do just what I hoped they would. TWO FINAL notes; There is one "DRAW-BACK, to all this: IF you use TELCOM, and enter "Term" the whole buffer is written over and all "pokes" are lost. OH WELL! I used ROBERT BENSON's "TRICKS.DO" as my first guide-line in figure'n this out. (It's in TECHNICAL REFERENCE (6) on the bbs.) THANK-YOU for "listening" -CARROLL- *Enclosed File: SCREENPRO