SHUTLDOC - Documentation file for the SHUTTLE demo for the Thinkjet printer (See Atlanta Conference Swapdisk / CHHU01). See also SHUTTLE, SHUTTLEDTA, SHUTTLEX and SHUTTLXS on SWAP11 for revised version by M. Markov, and other related files such as ROWCOL, ROWCOLS, RPTBLEX, RPTBLEXS, SIDES, SIDES2, etc. The demonstration produces an impressive view of the Space Shuttle, using an HP-71 and a Thinkjet printer. This illustrates the mostly untapped graphics capability of the thinkjet to produce pictures of three-dimensional objects on paper, by using variation of curve and shadings to give the impression of depth. A cut-away that shows details of the structural members of the space shuttle gives an excellent example of line drawings suitable for printing engineering documents, plots, etc. The most impressive part of the demo is that the HP-71 / Thinkjet combination produce the picture of the shuttle as fast as the printer can go. You can almost believe that the graphics output can be had as fast as text! Of course, this speed is possible because the HP-71 only has to read the contents of a text file that already holds all the escape sequences / control charaters / raster graphics bit patters, and PRINT them on the thinkjet. Low resolution graphics (96 pixels per inch horizontally & vertically) also helps, since the number of graphic data bytes that must be sent to the printer is half that of high density graphics (192 pixels per inch horizontaly, 96 pixels per inch vertically.) The demo package consists of the SHUTTLE program, which does the reading and printing for us, SHUTTLEDTA, a text file that contains the graphics information, and SHUTTLEX, a small LEX file used by the SHUTTLE program. At the time, a somewhat fancier shuttle demo was used by HP to demonstrate the graphics capabilities of the series 80, HP-150 and other HP computers. I assume the demo was originally developed for these other machines, and ported over to the HP-71. I think SHUTTLEX was developed to overcome the slight problem presented by the rather awesome memory requirements of text files full of raster graphics data. A full width line of low density raster graphics, not including the 6 byte escape sequence ESC*b80W or the two byte record header, takes 80 bytes. At 96 pixels (dots, or lines) per inch vertically, a one inch strip of graphics takes (80+6+2)*96 or 8448 bytes. Somehow, a way had to be found to make a half page picture (roughly 44 Kbytes) fit into the limited RAM of a bare-bones HP-71 (you could get 4K RAM modules at ridiculous prices to increase available RAM. HHP and CMT modules were not available.) Granted, you can reduce requirements by trimming any trailing null bytes. If you do that, then the resulting graphics file (including the escape sequences and other overhead) is reduced to 23876 bytes. This was still a bit too much.. SHUTTLEX took care of the problem. It provides two keywords, CPRSRG$ (ComPReSs Raster Graphics) and EXPDRG$ (EXPanD Raster Graphics). The CPRSRG$ keyword can 'shrink' an 80 byte data string to as little as 2 bytes, assuming it consists of either 00 or FF bytes. Since raster graphics data typically consists of of few pixels that are turned "on" (bit set) separated by long strings of 00 bytes (blank portion of line), "compressed" files can be reduced to as low as 20% of the size of the "expanded" file. In the case of the SHUTTLEDTA file, the "compressed" file is 17238 bytes long, or 72% of the "expanded" version. I printed a hex dump of the expanded version of SHUTTLEDTA, and I noticed that the escape sequences took a lot of space - 6 bytes, not including the 2 byte record header, to be found between every line of graphics data. If we could supply these escape sequences from the printing program, then we would save some 8*910/2 or 3640 bytes.. (the original SHUTTLEDTA has about 910 records). I tried several approaches, such as using LEN to determine the number of graphics data bytes in each record. While this worked quite well, it was relatively slow. Worse, there was no easy way to change from high density graphics to low density graphics, or vice-versa. Initially, I reserved record 0 of the text file for the ESC *r1280sA or ESC *r640sA escape sequence, thus setting the density once and for all for the given file. This, however, made it difficult to switch back and forth between modes in the same image. Eventually, I decided that every record must be either 80 bytes long, for a density of 96 pixels per inch horizontally (640 pixels per row), or 160 bytes long (1280 pixels per row) for high-density graphics. While this adds up to two two bytes to each record for the trailing 00 bytes, it eliminates the need to compute the escape sequence - you have only two choices, ESC*b80W or ESC*b160W, depending on whether the lenght is 80 bytes or 160. Using this approach, I was able to produce a revised SHUTTLEDTA file that is only 14498 bytes long, and fits comfortably in a bare-bones HP-71. If you adopt the above convention, you can think of your graphics files as bit- maps for a rectangular pixel array 640 or 1280 pixels wide and N pixels long, where N stands for the number of records in the text file. This means that you can overlay a plot on top of another by using OR$(A$,B$) for each corresponding pair of records. You can also produce inverse video with COMP$(A$), clear a space in a bit map with AND$(A$,), print the bit-map sideways (see the SIDES program on SWAP11), multiply the size of an image (see RPTBLEX and RPTBLEXS), and much more. One of the things I tried was to print the space shuttle using high density graphics. This was easy, given the revised SHUTTLEDTA and SHUTTLE files: All I had to do is modify the escape sequences in the SHUTTLE program, and double the raster graphics data strings on a bit by bit basis with the DBLW$ keyword from GRAPHLX (also available in ULIB53). The resulting image is much sharper, with a definitely improved resolution. Shadings change considerably - they are much darker - but you still get a very good impression of depth. The printing time increases a little, but not enough to be very noticeable - the limitation appears to be the speed of the printhead. (I have a 2225C with a parallel printer interface, with a built-in 1 Kbyte print buffer and a print spooler. The standard HPIL version with its 40 byte buffer may behave differently.) NOTE: The RPT$ keyword is available in STRINGLX, among many other LEX files. AND$, COMP$, EXOR$ ,OR$ and REVBIT$ are available in STRBOOLX (Software Development Handbook / GRAPHLX in the GRAPH71.) There are many LEX files that provide keywords that can help you manipulate bit-maps on both the byte and bit level. A complete list is beyond the scope of this documentation file. You should be aware that if a raster graphics data string consists of alternating 00 and FF bytes, the "compressed" version of this string will be two times longer than the original. Fortunately, this particular pattern is not likely to occur very often. For most practical applications, the "compressed" file will be between 30% and 60% of the size of the "expanded" file. The file compression factor is inversely proportional the amount of clutter to be found in the picture. The compression algorithm is both very simple and very fast: the object string is poped on the stack and scanned byte by byte. The byte is copied into the output string. Then, if it is either FF or 00, execution passes to the appropriate compression subroutine. Subsequent 00 or FF bytes are counted until you reach the end of the string, until the count reaches 255, or until you find a byte that is not equal to the 00 or FF byte(s) to be compressed. When this happens, the count is appended to the string, and processing continues with the next byte in the string. Thus, a string 1B2A6231335700000000000A becomes 1B2A6231335700040A. Note that the string of 5 consecutive 00 bytes has been converted to a two byte string. One of the not-so-obvious implications of this algorithm is that EXPDRG$(CPRSRG$(A$)&CPRSRG$(B$)) = A$&B$. This offers interesting opportunities for people who might be interested in plotting two graphs side by side. It can be assumed that the two files are originally low density graphics, and that you "squeeze" by printing the two files using high density graphics. This can also be used to append or prefix fancy borders and other stuff. NOTE: There are many ways to compress data. Several methods have been implemented on DOS machines, see for example the ARCE utility. It is somewhat surprizing that very little has been done in this area for the HP-71. The only other utility I know of is SPACKLEX, by Stefano Tendon. The packing algorithm used in SPACKLEX is most effective when the range of bytes in the strings to be packed is small - leading most significant bits are all the same, and are not required for storing information. Thus, strings consisting of uppercase text can be compressed to roughly 5/8 of the unpacked lenght, and numerical data to 50%. Since graphic data strings usually include bytes ranging from 00 to FF, all 8 bits per byte are required for information storage. In other words, SPACKLEX does not provide an effective alternative to SHUTTLEX. See the SPACKART file on the CHHU04 swapdisk for details.