Calculator Having Merged Key Codes

Electronic calculators are currently available for producing a wide variety of mathematical and manipulative operations formerly performed only by larger computers. The development of these calculators has been due in large part to the development of large-scale integrated circuits which have enabled calculator designers to implement a large number of computing circuits into very small packages. With this reduction in size of calculator components, many hand-held electronic calculators that perform sophisticated mathematical functions have become available. The number of functions that can be performed by hand-held calculators is usually limited by the number of keys that can be conveniently placed on the keyboard, rather than the number of the functions that can be performed by the circuitry inside the calculator, since a keyboard must be sufficiently large for a human operator to conveniently actuate the keys. Some calculator designers have alleviated this problem by providing a shift or prefix key that enables one or more of the other keys on the keyboard to initiate more than one calculator function. Examples of such calculators are the Hewlett-Packard Models 45 and 80.

A number of electronic calculators available today not only have the ability to perform sophisticated mathematical operations but they are programmable as well, enabling the calculator user to store a program of manipulative operations for later utilization. Programmable calculators often store such programs as a sequence of coded instructions usually called words or key codes. The storage memory usually has a given number of fixed-length positions in which these key codes can be stored, and the complexity of the programs the calculator can execute is often limited by the length of the program storage memory.

The stored program in a hand-held, programmable, electronic calculator usually comprises a series of key codes in a memory that correspond to the sequence keys a user would depress if he were performing the program manually. If some of the steps in the program comprise functions that are accessed from the calculator keyboard by first using a prefix key, then the program will have to store the prefix instruction as well as the instruction for the mathematical operation. If the program includes a significant number of such functions requiring the use of the prefix key, then a significant amount of the program storage space may be used up with the prefix instructions.

It is an object of this invention to reduce the amount of storage space required in a programmable, electronic calculator by multi-key instructions.

In accordance with the preferred embodiment of the present invention means are provided for generating a single key code, herein called a merged code, for each of several functions requiring a prefix key and a function key to initiate the function. A portable, programmable, electronic calculator may have, for example, 35 keys on its keyboard. A unique key code in the form of a binary number is usually assigned to each key and thus a calculator having 35 keys requires a six-digit binary code to uniquely represent each key. However, six binary digits can represent up to 64 unique combinations and a calculator having only 35 keys thus has 29 spare or unused key codes. Some or all of these spare key codes can be used to represent those functions that are accessible from the keyboard only by first actuating a prefix key. When the calculator is being programmed, each key code is entered into the program memory after the corresponding key is depressed. When a prefix key is depressed, a flag is also set in a status register in the calculator. If the following key is one that may be both validly prefixed by and merged with the preceding key, the flag in the status register causes the calculator to replace the previously stored prefix key code by a merged key code representing both the prefix and the subsequently depressed key. The merged key codes thus save program memory space by storing only a single code representative of the desired operation.

FIG. 1 shows a block diagram of a calculator according to the preferred embodiment.

FIGS. 2 and 3 show a flow chart of the operation of the preferred embodiment.

FIG. 1 is a block diagram of a programmable, electronic calculator 10 having a keyboard 12 with keys for entering numbers and initiating the performance of various mathematical and manipulative operations. Keyboard 12 is connected to a keyboard encoder 14 which generates a binary code for each key that is depressed. Since keyboard 12 has 35 keys, a six-digit binary number is used to represent each of the keys. Illustrative examples of key codes, expressed in octal form, are shown in Table I. The keyboard and encoder may be implemented, for example, with an array of single-pole, single-throw switches, each switch being actuated by a key and being connected to a common diode encoding matrix or other well-known encoding structure. A keyboard buffer 16, connected to keyboard encoder 14, is a six binary digit (bit) shift register that stores the most recently generated key code. Key codes are subsequently transferred from the keyboard buffer to other elements in the calculator. A read-only memory (ROM) 22 contains instructions in binary form for the performance of the various calculator functions and these instructions are addressed or initiated by the binary key codes. Central processing unit (CPU) 20 performs the mathematical and control operations programmed in ROM 22. Results of keyboard entries as well as the manipulative operations performed by CPU 20 are displayed in a display 26 connected to CPU 20 by display decoder 28. The operation of such a ROM and CPU along with a keyboard display and associated components is described in detail in a patent application by France Rode, et al., entitled "Improved Business Calculator," Ser. No. 302,371, now U.S. Pat. No. 3,863,060 filed Oct. 30, 1972 and assigned to the assignee of the instant application, and also in the Hewlett-Packard Journal, June 1, 1972, pages 1 through 9.

Calculator 10 includes a read-write memory 24 that can store key codes from the keyboard, enabling the calculator to be programmed to perform mathematical and manipulative functions by storing key codes in the memory and initiating the recall of those stored key codes from the memory. Keyboard buffer 16 is connected to a read-write memory buffer 18, as well as CPU 20, and ROM 22, and the read-write memory buffer 18 is connected to read-write memory 24. The memory buffer 18 may also comprise a six-bit shift register, similar to keyboard buffer 16. Memory buffer 18 stores information which is to be transferred into or out of read-write memory 24. Calculator 10 is provided with a PROG/RUN switch 30 connected to CPU 20 by line 31 which enables the read-write memory to either store information from the keyboard or read out stored information to the CPU and ROM. When switch 30 is in the PROG or program position, execution of instructions corresponding to depressed keys is inhibited and the key codes are entered into the memory buffer 18 from keyboard buffer 16 and then into read-write memory 24. When switch 30 is placed in the RUN position, functions corresponding to the various keys will be executed when those keys are depressed. Programs stored in read-write memory 24 may be executed in Run mode by depressing a program initiation key.

In the illustrated embodiment, programs may be stored in the read-write memory and later initiated by actuating a Run/Stop key, R/S, or any one of the keys labeled A through E. The A-E keys facilitate the storage and recall of several different programs and subroutines in a single read-write memory. To store a program that will be recalled by depressing key A, the user switches PROG/RUN switch 30 to PROG, depresses the LBL key and then the A key. Next, the user actuates various keys on the keyboard in the order the functions are to be performed in the program. The last key in the program is RTN, which causes the calculator to return to the manual mode after the program has been executed and functions much as an END statement in a computer program. Further description of the components and operation of a programmable calculator, as described above, may be found in a U.S. Patent application by Thomas E. Osborne, et al., entitled "Calculator Having Pre-Programmed User Definable Functions," Ser. No. 419,153, filed Nov. 26, 1973, now U.S. Pat. No. 4,037,092 and assigned to the assignee of the instant application and in a U.S. Patent application by Robert E. Watson, entitled "Improved Programmable Calculator," Ser. No. 153,437, filed June 15, 1971, now U.S. Pat. No. 3,859,635 also assigned to the assignee of the instant application.

As previously mentioned, some of the functions performed by calculator 10 require the depression of a prefix key before the function can be initiated or programmed. For example, to take the logarithm (log) of a number, the "f" key must first be depressed and then the "8" key. These two key strokes will instruct the calculator to take the natural logarithm of a number already entered into the calculator. If only the "8" key were depressed, the number eight would be entered into the calculator rather than initiating the logarithm function. Similarly, to take the antilog of a number, the "f.sup.-1 " key is first depressed and then the "8" key is depressed. Similarly, the absolute value of a number may be determined by first depressing the "g" key followed by the "6" key. Two other prefix keys are also shown, STO and RCL, which are used for storing and recalling numerical constants. A number may be stored in any one of nine registers by entering the number and then pressing the STO key followed by one of the digits 1 through 9 to designate one of the nine storage registers. That same number may be recalled by depressing RCL followed by the digit key indicating the register in which the number is stored.

When a program is stored using any of the foregoing operations, two key codes must be stored: the prefix key code and the function key code. Thus, two positions in read-write memory 24 are used to store the instructions for a single operation. If a number of these functions are used in a program, a substantial amount of limited storage space will be used up with the prefix key codes. The amount of space used up by prefix key codes may be reduced by assigning some of the unused key codes (i.e., the key codes not assigned to the 35 keys on the keyboard) to a combination of a prefix key and a function key so that only a single position in read-write memory 24 is used to store the merged code for an instruction requiring two key strokes. These merged codes can be generated by checking each key code to see whether a prefix key has previously been depressed and, if it has, whether that key is one for which a merged code exists. If a merged code does exist, that code will be generated in response to an instruction from ROM 22 and will be inserted into memory 24 via CPU 20 in place of the prefix and function key codes. By way of example, Table I lists the functions, their key codes and corresponding merged codes (in octal form) used in the illustrated embodiment.

FIGS. 2 and 3 show a flow chart of the ROM program used to check for key codes to be merged and to generate the merged codes. Until a key is depressed, the calculator remains in an idle status, 50, and the keyboard is cleared. When a key is depressed, the key code is entered into the keyboard buffer 16 and the read-write memory buffer 18 and that key code is used to establish an address in ROM 22. That address location in ROM 22 initiates the program starting at decision block 52 in FIG. 2. If the calculator is not in the Program mode, that is, if it is in the Run mode, the calculator checks to see whether the key is one that can be prefixed. If the key cannot be prefixed, the calculator, then checks at block 56, to see if the key is a prefix. If it is not a prefix, the instruction corresponding to that key code is executed and the calculator then returns to the idle status. If the key is a prefix, then a prefix status is established in a status register 32 connected to CPU 20, overwriting any previously established prefix status. The status register may be, for example, a five-bit shift register with one bit for each of the prefix keys. After the status is set, the calculator returns to the idle status awaiting the depression of another key.

If the key depressed can be validly prefixed, the calculator checks to see if the key is prefixed, at block 58. If this key has not been prefixed, then the instruction corresponding to the depressed key is executed. If the key has been prefixed, the merged code routine, described below, is initiated.

The previous paragraph discussed the operation of the calculator in the Run mode; if the calculator is in the program mode, the calculator then checks whether the depressed key can be prefixed, at decision block 60. If the key cannot be prefixed, the calculator checks, at decision block 62, whether the depressed key is a prefix. If the key is a prefix, prefix status is set in status register 32. The key code in the memory buffer is inserted into the read-write memory and calculator returns to the idle status. If the key was not a prefix, then the instruction corresponding to that key is executed. If the key can be prefixed, decision block 58 interrogates whether the key is prefixed. If not prefixed, the key instruction is executed; if the key is prefixed, the calculator then checks for which prefix was assigned, as shown at decision blocks 64, 70, 72 and 74. The dashed lines in the figures indicate that any number of prefix keys could be checked for in the manner described below.

A "yes" answer from any of the decision blocks 64, 70, 72 or 74 initiates a branch to the flow chart in FIG. 3. For example, decision block 64 is a check for the "g" prefix. If the preceding key was a "g" prefix key, the calculator checks at block 66 to see if this prefix "g" is valid for the key which has just been depressed, since not all prefixes will necessarily apply to all keys. If the prefix is not valid for this key, the prefix status will be cleared and the key code corresponding to the key depressed will be entered into the read-write memory. If the prefix is valid for this key, the calculator will check, at decision block 68, whether this is one of the key codes which should be merged with the prefix. If it is not, prefix status will be cleared and the key code will be entered into the read-write memory. If merger should take place, then the calculator once again checks for the Program mode. If the calculator is in the Program mode, the prefix key code is deleted from the read-write memory and then the merged code address is established in the read-write memory instead, overwriting any previous information. The merged code may be generated by the use of a look-up table in ROM 22 or through a numerical subroutine which generates a unique number in response to the prefix and function key codes being merged. If the calculator is not in the Program mode, the step deleting the prefix code from the read-write memory is skipped. The merged code is then transferred to ROM 22. If the calculator is not in the Program mode, the instruction corresponding to the key code will be executed. If the calculator is in the Program mode, the merged code is inserted into the read-write memory.

If the prefix that was previously established was not the "g" prefix, decision blocks 70, 72, 74, etc. will check for the other prefixes and will then perform the same checks of validity of the prefix and validity of merging for the particular combination of instruction and prefix.

As illustrated in FIG. 1 taken together with Table I, not all of the instructions requiring a prefix will necessarily generate merged codes, and those selected for merging are those that may be used more frequently in programming. The foregoing flow chart can be implemented in a read-only memory as shown in the program below in Table II as well as in equivalent hardware logic employing well-known techniques of logic design with gates and flip-flops. To assist the reader in understanding the operations of the program in Table II, the instructions used to generate a merged code for "x>y", requiring the depression of the "g" and "RTN" keys, are underlined. In addition, the corresponding decision blocks have been indicated by reference designator in the extreme right-hand column of the Table. The starting points of the ROM programs for the other keys are indicated by the key labels in the extreme right-hand column of the ROM 02 Object Program. ##SPC1## ##SPC2## ##SPC3## ##SPC4##