DISK DEPENDANT PROGRAMMING
If I had to complain about something I would gripe about the 6912 bytes of disk space that is required to SAVE a Screen File. A whole screen, when full, contains 22 X 32= 704 characters. Of course there is much more to a displayed screen than just the places reserved for characters to be printed, but 6912 bytes? A program line that constructs a screen takes up quite a lot of our precious FREE Memory. The more a software can do, the more MENUS and screen displays are needed. Usually a well designed screen will cost about 600-1000 bytes of FREE MEMORY. A software that has a lot of functions may need as many as a dozen such Menu and Information Screens. The FREE Memory used for a dozen such screens would be between 6 and 12K bytes. Look at FREE memory in another way. A full page of printed data is usually about 3000 Characters. So, 12 screens within the software programming costs us the memory capacity of about 2 to 4 full pages of data.
Is it economical to spend 6912 bytes, times 12=82944 bytes of disk space to save 12 screens and “boot the screens in when needed in a program”? You bet it is!! And, the SCREEN$ LOAD and SAVE is one of the most useful functions of a Disk Drive. The programming (SAFE) <1000 LOAD /”1″SCREEN$> (AERCO) <CAT “1.SCR”,> is all that is needed to bring aboard a screen menu that would take up 1000 bytes of FREE Memory. 12 such lines of programming costs only 132 bytes of FREE memory. We have a million K of disk space to waste, but every byte of FREE memory is like the last lick of a ice cream cone. How sweet it is! And who cares about a 6912 byte chunk of DISK Space? I rememember once testing the practicality of booting screens from Cassette. While the screen was loading in the grass on the lawn grew enough that it needed mowing! And I watched as a Cardinal built a nest, layed her eggs and the young birds learned to fly! All while that screen was loading from cassette. Well, maybe thats stretching it a bit. Anyway, <LOAD /”1″SCREEN$> pops a menu on screen in 2 and one half seconds flat! Thats FAST and efficient!
The “doing it” is too easy to talk about. You just program your screen in the normal way with PRINT AT statements in a line of programming. But now you can let it all hang out and create a real beautiful screen with color changes, full words instead of abbreviations, and put nice borders around it. When finished and the screen is really beautiful, just BREAK, and type <SAVE/”1″SCREEN$>. Next DELETE the program line, and re-enter the same line with 1000 LOAD /”1″SCREEN$. Do this as many times as you have Menus and Display screens in the software. When finished, your program will have more meaningful menus and you’ll have saved enough FREE memory to add many more functions to the program.
Now what we have just done is to create a “Disk Dependant” software. It wont work without the disk drive. You are sacrificing a good bit of disk space to conserve Computer FREE Memory. Later we will use disk space to store “Segments of the Software itself”, and MERGE these segments to the main program in memory as the program routines are needed. For example, suppose that you have a software that has a Data Base Manager, a Word Processor, a Mail Merge. You have used a lot of programming for these three comprehensive functions, and have thus sacrificed FREE memory for DATA STORAGE. While you are using the Data Base Manager, you really do not need the Word Processor nor the Mail Merge to be on board.
So, when the SAFE Merge function is implemented, we can have our cake and eat it too. Software programs can be segmented so that only the major function that we need will be in memory. The other major functions will be on stand-by in disk.