DESCRIPTION

Technical Field

The present invention relates to devices of the type used for compressing data that is stored or transmitted and thereafter for restoring the data to its original form.

The program listing in the attached Appendix is hereby incorporated herein by reference.

Background s£ _r__ invention

Devices for compression and corresponding expansion of data are known in the art.

It is known in a data transfer terminal to compress the transmittal data by providing a fixed library of commonly used phrases at the receiver, and upon the occurrence of one of the phrases, transmitting only the address of that phrase. Such a device is shown in U.S.

Patent No. 4,107,457 issued August 15, 1978 for an invention of Thomas M. Hajduk. It is also known to check directly, consecutive repetitions of a character and transmit only the character code and repetition count, as shown in the device of U.S.

Patent 4,192,966 issued March 11, 1980 for an invention of

Mark Mayer.

PiS _C lQSV-re <2f Invention

A preferred embodiment of the invention provides a system for the dynamic encoding of a stream of characters. In a preferred embodiment, the system includes an input for receiving a stream of characters, and an output for providing encoded data. The system also includes a provision for storing, accessing, and updating a table

HEET

(what I call a "followset" table) for each of a plurality of characters, listing candidates for the character which may follow, in the stream, the character with which the table is associated. The system also includes a provision for furnishing at the output, for a given character in the stream at the input, a signal indicative of the position, occupied by the given character, in the followset character which immediately precedes the given character in the stream at the input. A preferred embodiment of the invention also provides a system for decoding the encoded data, wherein the decoder utilizes a followset table.

Srisi Description s£. i Drawings

These and other features of the invention will be more readily understood by the following detailed description taken with the accompanying drawings, in which:

Figs. 1, 2A, 2B, and 3 show tables stored in a simplified embodiment of an encoding device in accordance with the present invention;

Fig. 4 shows a hardware implementation of a preferred embodiment of the present invention;

Fig. 5 is a block diagram illustrating the basic logical processes utilized in the embodiment of Fig. 4;

Fig. 6 illustrates the FONT.TABLES and FONT.ADDRESS.TABLE, which are the two most important tables used in the embodiment of Fig. 4 in both encoding and decoding of data;

Fig. 7 presents the ENCODING. ABLE, which is used in the embodiment of Fig. 4 to generate binary numbers indicative of the position of a character in a "font" or "followset" as defined below;

Fig. 8 shows the tables used by the embodiment of Fig. 4 for encoding or decoding of new characters following transmission or receipt of transmission of the position occupied by the new character symbol;

Fig. 9 shows the ENCODER. C.ENCODING.TABLE also used by the embodiment of Fig. 4 for new character encoding.

Description oj= Specific Embodiments

The invention relies on dynamically created tables in both an encoding device and a decoding device. A series of characters in a data stream is encoded in accordance with dynamically created tables in the encoding device. The decoding device is constructed in a manner to create corresponding tables for decoding of the encoded data, relying on the structure of the encoded data to create the decoding tables dynamically.

The compression scheme utilized in the invention relies on the assumption that the data being compressed is not random. In a preferred embodiment, the encoding device operates on binary encoded data occurring in serial form, wherein each character is represented by a fixed number of binary bits. The encoding device relies on the further assumption that a given character in a data stream has a more than random chance of being followed by one of a host of probable candidates for the next successive character.

(It should be noted, however, that when this is not the case, although compression may not take place efficiently, data will not be lost.) In fact, in one embodiment, the encoding device effectively creates a table in which, for a given character, there is presented a list of candidates, in approximate order of local frequency of occurrence, for the next successive character that would occur in the data stream. Therefore, when the given character does occur in the data stream, followed by a character in the table, the encoding device sends a binary code to represent the latter character based on the character's ordinal position in the table. The code is shortest for the most frequently occurring candidates, and although longer for those candidates that are less frequently occurring, it is in such an embodiment never longer than the number of bits in the original character encoding, thereby permitting compression in situations where patterns of characters are present. Since the table is created based on the local frequency of occurrence of a character after a given

SU33TΪTUTE SHEET

character, the table is changed dynamically as the local frequency of occurrence changes.

A simplified data encoding device in accordance with the present invention would contain a table for each possible character of data, indicating, for such character, what candidates are most likely to follow such character in the data stream. The candidates most likely to follow are listed in the table in order of frequency of occurrence, with the most frequently occurring characters at the top of the table and those characters occurring less frequently at the bottom of the table. An example of some of the tables stored in this simplified embodiment is presented in Fig. 1, where items 13, 14, and 15 identify tables for the characters A, B, and C respectively. Thus, in table 13 of Fig. 1, N is the character occurring most frequently after the letter A, and B is the next most frequently occurring letter after A. The symbol NC stands for "new character", which refers to a situation wherein, in this example, a character other than one listed in table 13 would follow the letter A. The use of this symbol will be more apparent in further discussion. Column 11 identifies the position, in usual base 10 numbers, of entries in the table, and column 12 identifies the binary coding used to identify each position in the table. (It should be noted that normal binary ordinals are not used for the coding; a special set of binary numbers is used to facilitate unambiguous transmission of the position in the table.) Table 14 indicates that in the case of character B, the most likely candidate for the next character after B in the data stream is one other than in the list of table 14; the next most likely candidate for the character after the letter B is the letter A, and so forth.

As discussed, the tables 13 and following of Fig. 1 are not static, but are changed dynamically. The manner in which these tables are changed and utilized will now be described in connection with a data stream of characters as follows:

T

A B A D A B A B A D . . .

Let us consider the table in column 1 of Fig. 2. At the beginning of a message, a table may be considered as ₅ having only a single entry, namely NC, the new character symbol. The initial state of such a table is indicated in the first column of Fig. 2A, wherein the new character symbol occupies position 1 of the table and the positions 2 through 7 of the table are blank. That is, the encoding _Q device expects that the most likely character to follow an A in the data stream will be a new character not present in the table.

Row 21 of Fig. 2A shows serially each character in the data stream that is an input to the encoding device. Row ₅ 22 of Fig. 2A shows serially the output generated by the data encoding device of this example for each character in row 21. (For purposes of illustration, however, consideration of the output generated for characters in columns 1, 3, 5, 7, and 9 will be deferred' to a later part 0 of this description.) It will be observed that characters in columns 2, 4, 6, 8, and 10 each follow the character A in the data stream. These characters will be coded for the output shown in row 22 by reference to the table for characters which follow the A character. Successive states 5 of this table are shown in row 23 of Fig. 2. The letter B, occurring in column 2 of row 21, is not found in the table of column 1, so B will be identified in the output of the encoder as a new character. The encoder therefore provides at its output a symbol showing that a new character is 0 going to follow, and then provides an output of the new character itself. Since the new character symbol occupies position (1) of the table in column 1, the output based on this table is binary 10 followed by the letter B.

At this point, however, there is more information

- ₅ available as to characters locally occurring after the letter A, so that the A table must be updated. The resulting updated table is shown in column 2 of Fig. 2A. Here the letter B has been identified as the character that follows letter A and is given binary code 11 in the table.

^{• !}

Similarly, after transmission of the output for the character in column 3, there is presented for transmission the output for the letter D in column 4. The letter D follows the letter A, so recourse must be had again to the A table. Reference to the A table in its last state, as shown in column 2, does not reveal a D, so that the new character symbol, identified as binary code 10, is given as an output, followed by the letter D. Concurrently, the table must again be updated, and the letter D is made to occupy the position coded in binary as 000 of the table, as indicated in column 4.

Similarly, after transmission of an output for the character A in column 5, the next candidate for transmission is the output corresponding to the character B in column 6 of row 21. At this point, it can be seen that the current state of the A table (which is shown in column 4) includes a B in position coded in binary as 11. Consequently, the output for the input in column 6 is simply binary 11. That is, the position of B in the A table rather than B itself is what is given as the encoder's output.

In addition to providing the encoded output for this character, the encoder must also update the A table. Since the letter B previously occurred in the table, this letter is moved to a position one higher than it previously occupied, by interchanging its position with that of the character immediately above it. The effect of interchanging positions in this manner is to cause the table to list characters in the approximate order of their local frequency of occurrence after the letter A. In this case, therefore, the B changes places with the symbol for a new character. Consequently, when B is next to be coded in the encoder's output, in column 8, its output code is by reference to the A table in the state as indicated by column 6, namely, binary 10. In column 6, the letter B is already the most frequent character, so there is no further change made in this instance to update the A table. The state of the table shown in column 8 after transmission of

the code for the character B in column 8 is therefore the same as the state of the table shown in column 6. However, after reaching the character D in column 10 for coding, the encoder causes an output of binary 000 and an interchange of the positions of D with the character above it, the new character symbol being treated as simply an additional character. The then updated state of the A table is shown in column 10.

At this juncture, it is useful to introduce some terminology. The set of characters listed in the A table in the above example I refer to as the A "followset" or the A "font". Thus I call the table 13 of Fig. 1 the A followset or A font; table 14, the B followset or B font; and table 15, the C followset or C font. It is now possible to complete the description of operation of the simplified data encoding device discussed above. Let us consider the encoder output for the character in column 3 of row 21 in Fig. 2B. The immediately preceding output of the encoder identified the character B, so the encoder knows that the next character to be transmitted will be a member of the B followset. Since the character B was never encountered in the data stream previously, the B followset would have the appearance of table 31 in Fig. 3. That is, no characters are present in the B followset except the new character symbol, which occupies the position coded as binary 10. As indicated in Fig. 2B, the encoder output in column 3 of row 22 identifies the new character symbol by binary 10, followed by the identity of the new character, namely, A. The B followset 31 of Fig. 3 must then be updated to have the appearance of the table in column 3 of row 23 in Fig. 2B; the character A was added after the last entry in the table. When A next follows B, it occurs in column 7 of row 21. Again, in such instance, the character must be identified by reference to the B followset. The last state of the B followset is identified in column 3 of row 23; the character A may therefore be identified simply by the binary 11, and this number is given as the output of column

< ~~ ^ι . — --------- !»?•»"-

7 row 22. The second occurrence of A in the B followset causes the A to have a higher position in that followset, so A switches positions with the character immediately ^• above it in the followset. The new state of the B followset is shown in column 7 of row 23.

The character A next appears after B in column 9 of row 31. Again the encoder makes reference to the B followset, the last state of which is as shown in column 7, and the character A is identified by binary code 10, which is given as the output in column 9 of row 22.

The A of column 5 in row 21 must be encoded as a member of the D followset. The initial state of the D followset is shown as table 32 in Fig. 3, so that there is provided as an output, in column 5 of row 22, the binary identifier 10 of the new character, followed by the letter A.

There remains to be discussed the output for the very first character in the data stream. The first character does not follow any given character, so the encoder device and decoding device both arbitrarily assume that the first character is a member of the followset of the character "null". The initial state of the null followset is shown as item 33 in Fig. 3. The output for the character A in column 1 of row 21 in Fig. 2B would therefore be the new character symbol, identified by binary code 10, followed by the character A. The null followset is then updated to have the form indicated in row 23 of column 1 in Fig. 2B.

The decoding device in accordance with this embodiment of the invention operates in a fashion analogous to the encoding device described above. It also maintains followset tables. Since, by definition, the pertinent followset table to be used in decoding a current encoded character is identified by the last character that has been decoded, the decoding device can correctly identify the pertinent followset table without receiving any information other than the encoded data stream. Moreover, the invention permits the encoded data stream to update and maintain synchronously the tables used in the decoding

device, so that the tables in the decoding device and the encoding device are in constant correspondence with one another. The decoder thus updates its followset tables in the same manner as the encoder. Whereas the encoder - utilizes the followset to derive a binary encoding from a given input character, the decoder utilizes an identical followset to convert the binary encoding into the original character.

The foregoing explanation of operation is simplified

-- - in a number of respects from a typical preferred embodiment of an encoder in accordance with the present invention. First, when a new character symbol is identified, and thereafter an output of a character is provided (as in the case, for example, of columns 2 and 4 of row 22) the

¹⁵ character, is identified by a specific binary code. There is a table that generates a code for such circumstances, and encodes the new character based on its position in a frequency table. (Simplified embodiments _, may avoid the use of a frequency table and transmit the equivalent of

²⁰ straight ASCII or EBCDIC representation for the new character.)

Second, each followset includes positions not for six characters plus the new character symbol, but for 15 characters plus the new character symbol. (Any other ⁵ number could be used, but I have found that satisfactory results in many cases may be obtained with 15.) When a followset has been filled in accordance with the procedure described, any time a new character is encountered in the data stream, the encoder causes the new character to be

™ substituted for the character occupying the bottom position of the followset, so that "stale" characters in the followset get removed.

Third, by the term "character" I mean not simply a letter but actually any type of information capable of being encoded in binary code according to a specified format; thus using the ASCII or EBCDIC standards, a comma or space is a character just as much as an upper case A or the number 9. (As explained in further detail below, the

SUBSTITUTE SHEET

principles applied here to ASCII or EBCDIC may be applied to any fixed-length coding character set.)

Fourth, the position in a followset table is identified not simply (as explained below in connection with Fig. 7) by the given set of binary numbers shown in Figs. 1 through 3B, but rather by a dynamically allocated set of binary numbers depending on the number of active characters (or positions) being used in that followset. With each followset is stored the number of active characters, so that a particular set of binary numbers can be used.

Fifth, the new character symbol is not physically stored in the followset. Instead with each followset is also stored a number that represents the theoretical position occupied by the new character symbol. This number is used in determining what binary code is sent to identify the new character symbol.

Sixth, when the encoder is using a new followset—one in which the only candidate is the new character symbol—the encoder's output can be shortened by avoiding altogether any transmission of the position of the new character symbol. That is, both the encoder and decoder know that in a new followset the only candidate is the new character symbol, and hence its position is already known. In such cases, the encoder simply provides an output directly of the new character encoding without being prefixed by the coding for the position of the new character symbol. Thus, for example, in col. 2 of Fig. 2A, the encoder is in the followset of A, a new followset, and in columns 1, 3, and 5 of Fig. 2B, the encoder is in the followset of null, B, and D, respectively, and each are new followsets at those points. Consequently the encoder and decoder may be designed so that the binary 10 in row 22 of those columns can be eliminted. Lastly, a followset is not necessarily identified with a given single character. I have found in a preferred embodiment that a followset may be advantageously described by a character group of a particular sort. The character

group that is employed in one preferred embodiment of the invention depends on classifying characters into five "Types" as follows:

- Type I: the 26 capital letters A-Z;

- Type II: the 26 lower case letters a-z;

- Type III: the 10 decimal numbers 0-9;

- Type IV: punctuation and symbols such as [,], [:], [;], [%], [$], [(], and [)]; ~ Type V: data communication signals, such as control, backspace, null, line feed, and the like.

In a preferred embodiment, I identify a followset by a three element set, the last element of which is a given one of the 128 ASCII characters. The first two elements of this set are the Types of the two characters immediately preceding the given character in the data stream. As an example, the character D in column 4 of row 21 follows the character A. The letter A in column 3 in turn follows characters that are both of Type I. D would thus be identified as a member of the followset [Type I] [Type I] [A] . As used in the claims which follow, the term "Type" shall mean any classification of characters into groups, such as presented above, according to some system, permitting the association of a character with one of such groups. As used in this description and the claims following, the term "followset" is used in conjunction with any character or character group that is examined in accordance with the present invention to create a table, for such character or character group, of candidates for the position following such character or character group. Owing to the nature of ASCII and EBCDIC coding, I have found it convenient to use four rather than five Types. In ASCII, for example, the four possibilities for the two highest order bits of its binary coding may be directly used to identify each of four Types. These four Types correspond generally to the five Types described above, but with Types III and IV merged.

" GTITUTE SHEET

The approach described in the preceding paragraph results in there being created 4 x 4 x 128 = 2048 total followsets. One could actually maintain all 2048 followsets in the memory of the encoding device, but I have found that this approach is not generally necessary. One could rank the followsets in order of recurrence and discard the ones that are least used; nevertheless, I have found that there is little loss in compression if one simply discards followsets on a cyclical basis, maintaining in memory an appropriate number of followsets most recently used. In order to accomplish this, it is useful to maintain in memory of the encoding device a list of all possible followsets to determine which of those have actually been created and maintained in memory. If a given followset is not in memory and is needed, it may be created and the followset that has been maintained in memory the longest is then discarded.

In the case where the data compressed is in EBCDIC, there are 256 characters. Because the present embodiment is designed for 128 characters, I have found that it may, with relatively little loss of compression, use a single set of fonts for two different characters. As an example, the same font may be invoked for [Type I] [Type I] [SOH (Start Of Heading character) ] as for [Type I] [Type I] [a]. In establishing fonts for EBCDIC characters, the embodiment described in futher detail below sets the highest order bit in the pertinent character to zero, so that two characters produce the same set of fonts. (This procedure, however is not applied to transmission of a representation of a new character or to storage of a character in a font.) In this manner, the same number of fonts may be used regardless whether the data is ASCII or EBCDIC. Because the decoding and encoding devices always select the same font (even if the font may happen to be selected more often than otherwise, owing to the merger of sets of fonts for characters represented by common bits after the highest order bit) , there is no ambiguity in the data transmitted or received.

" —

Figure 4 shows a hardware implementation of a preferred embodiment of the present invention. The invention includes a modem port 410 and a terminal port 411 for connection to a modem and terminal respectively. The invention both (i) processes encoded data received through the modem port 410, the decoded output of which appears at the terminal port 411, and (ii) processes the data stream received through the terminal port 411, the encoded output of which appears at the modem port 410. The central process is performed by a Z80A CPU, item 401, which receives clock, and power signals from unit 415 and a reset signal from unit 415 on suitable operation of the keyboard 405. In a manner known in the art, the CPU 401 is in communication with an EPROM, item 402, typically type 2764, and a RAM, item 403, typically type 4164 in a 64k version of the device or type 4116 in a 16k version of the same, which is subject to parity checking by item 404, typically type LS280. The modem interface 408 and the terminal interface 412 are typically Types 1488 and 1489. The Z80A SIO and CTC circuit, item 413, controls the relation of each interface to its respective port in a manner well known in the art.

Data interchange throughout the hardware is controlled by an FPLA, item 406, typically 82S153, and item 407, typically 8255. These chips manage output to the lamps and digits, item 414, and receive input from the keyboard, item 405. Pertinent device control information is preserved after AC power off in a battery backup circuit 409, typically type 4006. Turning now to Figure 5, there is shown a block diagram which illustrates the basic logical processes implemented by a preferred embodiment of the present invention. Eight basic processes are performed; three relate specifically to encoding, three relate specifically to decoding and two additional ones, relating to operation of indicator lamps, item 54, and operation of the keyboard, item 55, perform management functions for the invention. These basic processes are supervised by a process scheduler

59 that operates in a fashion analogous to an operating system. The encoding process involves receiving input data from the terminal and loading it into a buffer identified as TREN, according to step 51; then taking data stored in the buffer TREN, encoding it, and loading the information into buffer ENMX, according to step 52; and finally, taking the data stored in buffer ENMX and outputing the information through the modem output in accordance with step 53. Analogously the decoder process involves receiving data from the modem and loading it into buffer MRDE, in accordance with item 56; then taking the data in buffer MRDE, decoding it and loading the decoded data into buffer DETX, in accordance with item 57; and finally, taking the data in buffer DETX and delivering it to the output for the terminal in accordance with item 58. The process scheduler 59 causes these functions generally to be handled cyclically as part of ordinary synchronous processing; however, functions identified by a check mark above the box are scheduled by an interrupt which permits processing to pass to those functions on a priority basis. The data delivered to the modem output is in the form generally of an X25 protocol, in a manner well known in the art. The protocol involves transmission of the data in frames indicated by appropriate flags, the end of the frame being followed by a cyclical redundancy check (CRC) . This technique can permit the devices to detect and correct errors between modem ports owing to transmission interference.

The processing steps of the present invention can best be understood by recourse to Figure 6, which illustrates the two most important tables used internally in both encoding and in decoding data. (Both the encoder portion of this embodiment and the decoder have a pair of these tables. In the Appendix, the encoder's or decoder's tables are separately labeled.) Item 61 is the FONT.TABLES, which are allocations of storage for a desired number of fonts to be preserved in active use in accordance with the invention. In the embodiment shown, each font has 15

SUBSTITUTE SHEET

positions for character storage, plus an additional position for the new character symbol. Each character can be identified by one byte of information, as well as the position of the new character symbol. An additional byte for a given font is used to store the number of active characters in the font. Finally, two bytes of information are used to store the address of that particular font in another table, namely the FONT.ADDRESS.TABLE, item 62, which will be discussed below. Thus in the present embodiment, 19 bytes of information are stored for each font in the FONT.TABLES. In a 64k version of the invention, there are stored 1,000 active fonts, each font occupying 19 bytes as described. In Fig. 6, the FONT.TABLES is shown beginning at memory location Y in memory.

The FONT.ADDRESS. ABLE is a table of two-byte pointers, wherein each pointer is used to identify the address of the first memory location of an assigned font in the FONT. ABLES. There is one pointer for each possible ' one of the fonts, including the fonts which are currently active in the FONT.TABLES and those which are currently inactive. Thus in a system using four Types and 128 characters, there would be a total of 4 x 4 x 128 which equals 2048 pointers. A value of zero assigned to a pointer in the FONT.ADDRESS.TABLE means that there is no currently active font in the FONT.TABLES for the pertinent font.

The memory location for the pointer of a particular font is determined in accordance with an alogrithm using values for the elements comprising the font in accordance with a calculation as follows: [(T.2 x 4) + T.l] x 2 + LC x 32, where LC is the binary value of the last character, T.2 is the Type value (ranging from 0 to 3 in binary) of the next to last character, and T.l is the Type value of the character preceding T.2. To the result of the foregoing calculation is added the base memory location for this table to arrive at the final address value.

As an example, consider the font [Type II] [Type III]

[A] . The character A is represented by the binary equivalent of decimal 65, so that application of the formula would yield [(2 x 4) + 1] x 2 + (65 x 32) which equals 2098. Assuming that the FONT.ADDRESS.TABLE begins ⁵ at memory location X, this particular font has its pointer at location X + 2098. This pointer is in fact a two-byte binary number, but let it be assumed that this number equals Y + 190. The pointer is shown as item 63 in Fig. 6. This pointer, it will be recalled, identifies the

-- - memory location of the first position in the assigned font in the FONT.TABLES. Since the FONT.TABLES begins at memory location Y, the position Y + 190 is shown at item 64 in Fig. 6. The first two bytes of this particular font include the address of its pointer in the

¹⁵ FONT.ADDRESS.TABLE, namely X + 2098.

The invention in a preferred embodiment also uses a number of other tables. One is the ENCODING.TABLE, illustrated in Fig. 7. It was mentioned above that the position of a character in a font is not indicated by a

²⁰ simple set of binary numbers. Thus, for example, if the font has only three entries as indicated by the bit indicating the number of active characters in the particular font, then the encoding table uses the binary system shown in Fig. 7B to identify the successive

²⁵ positions in the font. Similarly, if the font shows seven active characters, the positions in the font are identified by the binary number shown in Fig. 7F. It should be noted that the use of numbers in accordance with this scheme permits, first of all, efficient coding of positions high

³⁰ in a particular font and, second of all, an unambiguous system for the decoding device to determine when the last bit necessary to identify a position in a font has been received. A corresponding decoding table is used in decoding the binary numbers received to indicate their 5 position in the pertinent font table. The decoding table is called DE.FONT.TABLE. This table is used in connection with DE.FONT.TABLE.INDEX. When the binary information is transmitted to identify the position occupied by the new

SHEET

character symbol in a given font table, there is transmitted thereafter a representation of the new character based on its position in a frequency table. It will be recalled that the first difference set forth above between the simplified explanation and a preferred embodiment is that the particular new character transmitted is not actually transmitted in an unencoded form, and that there is a table that generates a code for such circumstances. Figure 8 shows the tables used to derive the encoding for transmission of new characters following transmission of the position occupied by the new character symbol. There is provided a table which I call ENCODER.NC.CHAR.FREQ. This table identifies, in ascending order, in accordance with the pertinent ASCII and EBCDIC coding, a value indicative of such character's approximate local frequency of occurence in the material being encoded. For example if A is represented by the binary equivalent of 65, the position corresponding to such value in the table will store the binary equivalent of 12 if this character occurs with a frequency just below that of 12 other characters (the most frequent character being identified with a frequency number of 0).

A second table used in encoding is identified as item 82, namely ENCODER. C.CHAR.VALUE, which stores in order of approximate local frequency of occurrence the appropriate

ASCII or EBCDIC coding for such character. Thus the binary equivalent of 65 would be stored in numbered position 12 to indicate the letter A in the previous example. These two tables are updated by having the character being transmitted exchange positions with the character just above it in table 82 and causing corresponding changes in table 81. Thus if A is being encoded and the character P occupies the position immediately above A in table 82, A and P would change places in table 82, and position 65 in table 81 would be changed to contain the binary equivalent of 11 and position 80 in the same table would be changed to contain the binary for 12. The character A is itself transmitted at this time by transmitting in accordance with

---. _* - ^E. -

a heretofore undiscussed table, namely ENCODER. C.ENCODING. ABLE. This table transmits an appropriate binary number to indicate the decimal number 12 and therefore the new character "A". On receipt of this binary information by the corresponding decoding embodiment of the present invention, two tables, namely DE.ZONE.TABLE and DE.DIGIT.TABLE, are used to produce the binary number indicative of a position in the DECODER.NC.CHAR. ALUE table 83, in this case the binary number corresponding to decimal 12. On the receipt by the decoder of this information, it knows to update table 83 by interchanging the position occupied by the ASCII or EBCDIC coding for "A" with that of its predecessor, and does so. In this fashion, because characters are identified by their position in a table indicating approximate local relative frequency of occurrence, the more frequently occurring characters may be encoded using fewer than the usual 7 bits required for identification. This method of compression generally averages approximately 6 bits per character. The structure of ENCODER.NC.ENCODING.TABLE is important to the effectiveness of the approach used here. As shown in Fig. 9, I have found that it is effective to divide the 128 characters (shown as ordinal numerals 0 through 127) into binary zones, which I identify as 0, 10, HO, and 111. In zone 0, I use 16 4-bit binary digits to differentiate the 16 most frequently occurring characters in accordance with table 82 and 83. In zone 10 the same 16 4-bit digits identify the next 16 most frequently occurring characters according to the foregoing tables, and similarly 5-bit digits are used in zone 110 to identify 32 more characters thereafter the next most frequently occurring, and in zone 111, 6-bit digits are used to identify the remaining 64 characters.

I have found it convenient to use relative position (ordinal numeral) 31 in the ENCODER.NC.CHAR.VALUE and

DECODER.NC.CHAR.VALUE tables to indicate alternatively the presence of a device command, which is not a character per se. The presence of a command is indicated by transmitting

a binary "1" after the binary encoding for position 31. Following a binary "1", there is transmitted a string of variable length containing the actual device command. If a binary "0" is transmitted, then no command is present, and normal new character encoding is understood. Device commands can be used in a manner well known in the art to operate indicator lamps, to cause the reset of the devices, to initiate loop back procedures, and to cause other desired control operations. Referring now to the Appendix, there is a detailed listing of the important processing steps used for encoding and decoding in accordance with a preferred embodiment of the present invention such as illustrated in Figure 5. (Exhibits 1 and 2 are written in standard Z80 macro assembly language, except that variables and other names in the listing have been expanded for purposes of clarity.) The first portion of the Appendix, lines 00100-10600, identifies variables to be used in the process of encoding and decoding and establishes the tables previously discussed. ^* Beginning at line 10750, tables 81, 82, and 83 of Fig. 8 are initialized by entering in them consecutively binary numbers corresponding to decimal 0-127. This process is completed at line 11300. Lines 11350-11700 provide initial values to certain variables that are used in connection with operation of the embodiment. At lines 11750-12300 the address of the variable FONT.ADDRESS.DUMMY is stored in the two-byte address portion of the FONT.TABLES for each font stored in the FONT. ABLES.

The encoder routine begins at line 12500. A character is fetched from the buffer TREN (where process 51 in accordance with Fig. 5 has loaded input data) , in accordance with subroutine ENCODER.FETCH.FIFO.TREN in a manner well known in the art. Lines 12600-14550 involve testing for repeat encoding. The basic concept is that if the input data involved the repetition of a character, the character is encoded a second time and the second encoded character is sent, but a repeat counter is incremented to keep track of the number of repetitions. On the second and

subsequent repetitions, the counter is incremented to a maximum of nine, whereupon a code is sent. A code is also sent earlier if the repetition stops before nine times. The code is as follows: after the transmission of the normal encoding for the first repetition, a 0 is sent to indicate no further repetitions, but if there are repetitions a 1 is transmitted followed by a 3-place binary number which has the total number of repetitions less 2; thus in the case of a character that occurs three consecutive times the coding would be a 1 followed by binary 000.

Following the treatment of the repetition coding, program control at line 14650 deals with the macro called FONT.PARAMETERS. The substance of this macro is in the listing beginning at line 32050 and ending at line 33750. This macro calculates the location of the applicable font in the FONT.ADDRESS.TABLE 62, discussed above in connection with Fig. 6. Assuming that a 0 value is found for the pointer in the calculated location in FONT.ADDRESS.TABLE, there will be no currently active font in the FONT.TABLES, and the font must therefore be made active. Thus the program control will void the jump at 14750 and move on to 14800, which is a routine ending at 15150. The program calls a macro entitled FONT.PARAMS.NEW, which begins in full at line 33950 and continues through line 35650. The FONT.PARAMS.NEW is used to update the ENCODER.FONT.TABLE and the ENCODER.FONT.ADDRESS.TABLE. The variable NEXT.FONT.ADDRESS identifies the address of the next font table in the ENCODER.FONT.TABLES that is available to be assigned or reassigned. This address is stored in the appropriate location in the FONT.ADDRESS. ABLE. However, in the case of reassignment of a font table in the FONT.TABLES, there must be identified the old font to which it related; this is done by using the prior two-byte pointer still stored in the font table to identify the pertinent address in the FONT.ADDRESS.TABLE. The memory at the pertinent location in the FONT.ADDRESS.TABLE is then set to 0 to indicate that the old font is no longer

r CΞTlTUTE SHEET

active. Next, the pointer in the newly active font table in the FONT.TABLES is changed to identify the location in the FONT. DDRESS.TABLE for the newly active font. Finally, the entries in this font table identifying the number of active characters and the position of new character are reset to 0 (indicating the first position) , and the variable NEXT.FONT. DDRESS is incremented by 19 bytes (modulo the maximum number of bytes in the table) to identify the next available table. Control then jumps to a point in the program identified as ENCODER. EW.FONT, the body of which begins at line 19250.

In the event that an active font is already present, control goes to line 15200. There the program causes an examination of the pertinent font table to determine whether the character to be encoded is already present in the table. If the character is present, then the program identifies heuristically the position in the table occupied by the character (taking into account the heuristic position of the new character symbol)-, and causes selection from the appropriate part of the ENCODING. ABLE of the binary coding to identify such position. Also, the position of the selected character in the font table is interchanged with that of the immediately preceding character in the table, and the heuristic position of the new character symbol is appropriately updated if necessary. Finally, the binary coding resulting from the selection in the ENCODER.TABLE is given as an output.

In the event that a character is not present in the pertinent font table, then control passes to line 18700 identified as ENCODER. EW.CHARACTER. At this point, the heuristic position of the new character symbol is given as an output. Also, the binary coding for the particular character is given as an output in accordance with the table called ENCODER. C.CHAR.VALUE discussed above in connection with Fig. 8; this table is itself then updated in the manner discussed in connection with Fig. 8. Thereafter, the font table is updated in precisely the manner as in the case of a new font. In particular,

- TITUTE SHEET

control passes to ENCODER.NEW.FONT, mentioned above. If the number of active characters is less than the maximum, then it is incremented by 1, and in that indicated position is stored the binary code indicative of the character being encoded. If the number of active characters is already at the maximum, in the last position in the font table for this font there is inserted the binary code for the pertinent character, and the old number stored therein is simply overwritten. After any of the processing steps described above, control passes to ENCODER.RESET.FONT at line 17450, where variables are reset to establish the next font to be processed. In particular, the Types of the three characters most recently processed are updated and the last character is updated. Additional lines of code are included for the special case of EBCDIC, because the use of EBCDIC will affect the determination of the Type code.

In the present embodiment I have also found it desirable to transmit a pattern of 4 zero-bits after 256 iterations of ENCODER. ESET.FONT; if the -decoder does not similarly identify these 4 zero-bits after the 256 the iteration of its DECODER. ESET.FONT, then an error condition exists, owing probably to a data communications failure, and this condition is flagged, and processing of data stops. The 4-bit string of zeros is added at lines 18550-18650.

The operation of the decoder follows closely that of the encoder. Refering to line 20650, the decoder utilizes the macro FONT.PARAMETERS, discussed above, to determine whether a currently active font is present or whether there is a new font condition. In the event of a new font, control at line 21150 jumps to

DECODER.PROCESS.NEW.CHARACTER at line 21450. For character processing in the event of an existing active font, control passes to line 21200. After running the macro

FONT.PARAM.OLD (which sets the address of the current font), control goes to line 24750,

DECODER.PROCESS.OLD.CHARACTER. Here the program uses the

. τ _. τuτε SHEET

macro DECODE.FONT to decode the binary string indicative of a position in the current font. If the position is indicative of the new character symbol, control jumps back to DECODER.PROCESS.NEW.CHARACTER for new character processing, which will be discussed below. Otherwise, since a character appearing in a given font has occurred, the pertinent font table must be updated (which occurs at lines 25050-26450) , and goes into end processing indicated by the routine DECODER.RESET.FONT, at line 26500. in the case of either a new font or a new character within an existing font, the routine

DECODER.PROCESS. EW.CHARACTER uses the macro DECODE.CHAR to decode the frequency-encoded new character in accordance with the table DECODER.NC.CHAR.VALUE, as identified in each case by the encoding table shown as Fig. 9, discussed above. If ordinal numeral 31 is indicated by the binary coding shown in Fig. 9, further processing is necessary to determine whether a device command is present. In a case where a binary 1 follows the coding for position 31, program control goes to the routine identified as

DECODER.COMMAND.EXTRACT, at line 21750, where the pertinent device command is interpreted. Otherwise, if the coding for ordinal numeral 31 is followed by a binary zero, control passes, as in the normal case, to the routine identified as DECODER.NEW.CHARACTER, at line 23100. Here, the program's activity is similar to that in the case of a new font in the encoder; if the number of active characters is less than the maximum, the count for that font is incremented by 1, and in that indicated position is stored the binary code indicative of the character being decoded. If the number of active characters is already at maximum, then into the last position in the font table for this font, there is inserted the binary code for the pertinent character, and the old number stored therein is simply overwritten. Control then passes to the routine identified as DECODER.RESET.FONT. The routine DECODER.RESET.FONT cause the pertinent ASCII or EBCIDIC representation of the given character to be decoded as an output at line 26550,

' _i _w H«Uι!- w_»i-— '

and then begins processing analogous to that of the encoder at line 17450, wherein variables are reset to establish the next font to be processed. The Types of the three characters most recently processed are updated, and the ⁵ last character is updated. Additional lines of code are included for the special case of EBCIDIC, insofar as it will affect the determination of the TYPE code.

Next there is programming to detect, after 256 iterations of DECODER.RESET.FONT, a string of four zero

--- bits, as described above. If the four bit string of zeros is not detected, an error condition exists, and processing of data is halted.

Thereafter, at line 27800, the program tests to determine whether the newly decoded character is the same

^ ^•5 as the previously decoded character; in the event that the character is different, control returns to the beginning of the decoder routine. Otherwise, there is logic to handle the encoding of repeated characters. This logic is identified as DECODER.REPEAT.LOGIC, running from lines

²⁰ 27950 to 28900. In essence, if a zero bit follows the character just decoded, there are no repetitions, and if a 1 follows, there will follow thereafter three bits indicative of the number of repetitions in the manner discussed above. The number of repetitions is then used to

² ^ cause the writing of the pertinent number of identical characters to the output.

Referring now to the command routine at line 29400, there is shown the coding that permits the insertion of a device command at any point in the encoded stream, so that

³⁰ the decoder can be given pertinent commands at any time; the device commands are decoded in the manner described above. The macros which follow beginning at line 31950 perform detailed housekeeping functions that have been generally described above in connection with the encoder

³⁵ and decoder.

Although the foregoing is a description of specific embodiments of the invention, it will be appreciated that the invention may be embodied in a variety of forms diverse

~ ~~~~~~ - ' ^' ~- ~-~

from those shown and described without departing from the spirit and scope of the invention as defined by the following claims.