SAVZVMEM Beta Version 1.1 (Copyright 5/7/90 Ron Rock, Chicago Il.) This program may be copied and distributed if no compensation is sought. All other rights are retained. No warrantee of any kind is made or implied by the provision of this program. Enjoy. Enhansement of Beta test V/ZDESAV.COM by same author. SAVZVMEM is a small utility to preserve the memory image of a VDE/VDM/ZDE text file after a unexpected hang-up which requires a reset of your CP/M computer. SAVZVMEM.COM will not help if you have had a power failure. Save to disk as often as you can. In my case I sometimes "hang" my computer by trying to write to a non- exitent drive. (I have 5 drives at my office but only 3 at home and at 3 a.m. ... Well, you know what I mean!) Eric Meyer's VDE and it's progeny have a built-in simple text squeezer to enable a somewhat larger file to be retained in memory. He has combined a space character with the preceeding character by setting the eighth bit of that character thus reducing the average line by about ten bytes or 12%. Further, lines are terminated in memory with only a linefeed rather than the usual carriage return/linefeed couplet. SAVZVMEM restores the "missing" spaces and carriage return. Eric Pement was the first to mention this compaction procedure that I am aware of. The general CP/M procedure of "save everything after a reset, entering the CP/M command "SAVE 255 filename.ext" does preserve the entire memory image in a 64k file. However, there remains the task of finding and translating the text image. SAVZVMEM skips the need to "save" the memory image and directly reads the image and writes the translated text to an output file, a one step procedure. However, you are provided the option of T>ranslating a file containing the "saved" mamory image. End of file (^Z) bytes are not acted upon nor saved to the output file. The expanded recovered text is scrolled on-screen, if you wish. After each 1024 bytes (4 blocks) recovered, you may exit the program by pressing any key, otherwise SAVZVMEM will save the translated memory image until the top of the TPA (as represented by bytes 006 & 007h in page 0 of memory) is reached. Unless you have seen the critical text on-screen it is best to continue until the full save is completed. Depending on the size of the "Lost" file and what has preceeded it into memory, you may see random characters at various times on-screen and in the output file. These are printable characters translated into the ASCII set between 20h and 7Eh. As printable ASCII characters they are no longer in "system command" form and will not hang your system. On-screen, as the text is scrolling and depending on your character ROM, you may note an occasional "odd" character( a solid block on my KayPro '84). These are tabs (09h) which may not be expanded on-screen but are retained in the output file. SAVZVMEM resides up to byte 31FFh in memory and thus will overwrite any memory image to that point. If you are translating the CP/M saved memory image file, this limitation does not apply. Of course, at some point you are merely "translating" the command code. The default starting point as distributed is 3200h. I usually run with a start of 3CE3h which corresponds to the first text buffer byte of VDE265.COM which I happen to be using. A version of ZDE (13 I believe) , which I also use, has a starting buffer address of 3F70h. To find the address of the VDE/VDM/ZDE buffer you are using simply write a text file with only a string of characrers, say "ZZZZZZZZ"; do a CP/M save of a sufficently large segment of the memory image, i.e. "SAVE 100 TEST.DMP"; and utilize PATCH, EDFILE or any other disk utility which will both search for a string in a file and provide the address within the file. Note: the search string "ZZZZZZZZ" can only be found if 7 of the 8 characters are sought. The final character may have its 8th bit set to the character plus 7Fh. Do NOT use SAVZVMEM to create the memory image. SAVZVMEM excludes almost all non-printable ASCII characters from it's output file to make it more likely that that file can be "read" within the available memory when VDE/ZDE is invoked to "edit" the file. In general later versions of VDE/ZDE tend to have higher buffer addresses as additional "features" are added. All this means is that the beginning of the on-screen and output file will contain random characters which must later be deleted and may prevent you form using VDE/ZDE to edit the output file without "chopping" the file into two files (i.e. C/AVDE3.COM, CHOP18.COM SPLIT.COM, etc.) If you wish to patch another value, bytes 244Ch to 244Fh contain "3200" the ACSII character representation of 3200h. Enter the ASCII characters you wish (i.e. "3CE3" OR "3CF3", etc.) for the starting address of the direct memory save. Carson Wilson (ZDE updates) has cautioned that SAVZVMEM will not work because of the text buffering scheme is related to the cursor position and the possible overwrite by the CCP on re-boot. However, I have been unable to "lose" any significant portion of the text. If you are running an alternate or enhansed CP/M system, you may maximize recovery of "lost" text by booting on reset with a system that provides a larger TPA. I normally run XCCP.COM, a CP/M enhansement. If I do not invoke it after a "disaster" the result seems to be the same with respect to recovered text. I find that, if I move to the end of the output file and scroll upwards towards the beginning, I will find the complete and ordered text. SAVZVMEM.COM is written in CP/M TurboPascal and no installation should be necessary as no special screen codes are utilized. Since SAVZVMEM.COM is necessary only "in extremius" it might be worth a few minutes of "playing around" with it BEFORE disaster strikes and copying it to a "Disaster Disk" with a CP/M sysgen'd system available for re-booting. You may also find SAVZVMEM useful to recover other memory resident text images (an unsavable Turbo Pascal program, for example...).