System using an adapter board to couple a personal computer to a plurality of peripherals in a financial environment4787027Abstract A financial system includes a plurality of peripherals like a magnetic stripe reader, printer, and keyboard which are coupled to a personal computer by an adapter board which is inserted into an interface bus within the computer. Even though the financial application being run may be single tasking, the system is capable of running multi-tasking operations. An encryptor/decryptor processor, which is used in handling secure data, is located on the adapter board to minimize unauthorized access to the secure data. Claims What is claimed is: Description BACKGROUND OF THE INVENTION
TABLE 1
______________________________________
Code Command
______________________________________
00000 = Reset
00001 = Read Status
00010 = Open
00011 = Close
00100 = Read Tallies
00101 = Read & Clear Tallies
00110 = Read next
00111 = Write next
01010 = Echo
01011 = Delete record
01100 = Read random record
01101 = Write random record
01110 = Read device control memory
01111 = Write device control memory
10000 = Create file
10001 = Delete file
______________________________________
A message format as used herein is shown in FIG. 5 and is designated generally as 96. The message format 96 includes a device address 98, which in the embodiment described, is a byte wide and indicates the peripheral, like 18, to which the message is addressed. The command code 100 is one byte wide and includes the five binary bits shown in Table 1. The entire command code has the following eight-bit format; ofmCCCCC; wherein: 0=not used f=Message Format in which: 0=no data present 1=VLI (variable length indicator) data present. m=Message Segment Flag in which: 0=last segment 1=another segment follows C=Command, wherein the five binary bits of the code associated with a specific command are shown in Table 1. The variable length indicator (VLI) 102 (FIG. 6) is an eight bit byte which indicates the length of the particular message being sent. In the embodiment described, the data field 104 is up to 128 bytes wide. When data is sent, the VLI 102 indicates the length of the associated data field 104. As previously stated, the command messages are sent from the terminal 10 to the peripherals 18, 20, and 22, for example. One route from the application software (block 58 in FIG. 3) of the terminal 10 is through the MS DOS operating system 60, through the interface manager (block 62 in FIG. 3), and through the interface driver 68. Another route is from the application software (block 58) directly to the interface driver 68 by the path 106 shown in FIG. 3. The particular route of the two routes mentioned which is used to transmit a command message (format 96) to the interface driver 68 is determined by the financial application software (block 58). When a command message arrives at the interface driver 68 (FIG. 3), the driver 68 accepts the command message and appends a message sequence number 108 thereto so that the command message has the format 96-1 shown in FIG. 6. Also a Block Check Character (BCC) code 110 is added to the command message. The message sequence number 108 is assigned by the interface driver 68 and is used by the interface driver 68 to correlate or associate a response message with the associated command message. The BCC code 110 is derived from a conventional errorchecking technique and is used to check on the accuracy of transference of data between the interface driver 68 (FIG. 3) and the SPIA board 30. That data which is included in the bracket 112 (FIG. 6) is optional data which is dependent upon the particular command message being sent. When the command message having the format 96-1 (FIG. 6) is received by the SPIA board 30, the SPIA board 30 strips off the message seuence number 108, resulting in the message format 96-2 shown in FIG. 7. At this time, the SPIA board 30 also generates odd parity for the device address 98 and the command code 100. Assuming correct information, the command message having format 96-2 is sent across the interface bus 24 (FIG. 3) to the addressed peripheral like 18, 20, or 22 for example. To review, the command message being sent by the interface driver 68 (FIG. 3) is sent to the outbound data latch 84 (FIG. 4) as previously explained. At this time, the status latch 88 is employed to conduct handshaking activities between the interface driver 68 and the SPIA board 30. The command message shown in format 96-1 (FIG. 7) is sent one byte at a time to the SPIA board 30. The SPIP 70 (FIG. 4) has routines stored in its ROM 74 or RAM 76 to determine when the entire command message is transferred to the SPIA board 30. It should be recalled that the VLI 102 gives an indication of the length of the variable data field 104 in bytes. As the command message is transferred, byte by byte, to the SPIA board 30, the message is stored in the RAM 76 of the SPIP 70. Also, when the command message is transferred to the SPIA board 30, the message sequence number 108 (FIG. 6) is stripped from the message format 96-1 and stored in a buffer portion of the RAM 76 associated with the SPIP 70 (FIG. 4); however, this message sequence number 108 in not used by the SPIP 70. After the activities mentioned in this paragraph are performed, the command message shown in format 96-2 is ready to be sent to the peripheral, like 18, 20, or 22 which is addressed. The serial bus transceiver 92 (FIG. 4) is conventional; electrically the transceiver 92 includes an RS 422A integrated circuit which is used in an RS 485 environment. This interface communication between the transceiver 92 on the SPIA board 30 and the serial bus transceiver 52 (FIG. 2), which is located on peripheral 18, utilize a known standard which is referred to as "Intel Protocol" for microprocessor communications. At the time then the device address 98 (FIG. 7) is placed on the interface bus 24 (FIG. 2), each of the peripherals on the bus 24 will examine the address to determine whether or not that particular peripheral is being addressed. Those peripherals 20 and 22 having different addresses from peripheral 18 in the example being described would resume other activities. Peripheral 18, which is the addressed peripheral in the example described, would receive the command message from the SPIA board 30. Upon receiving the command message, the peripheral 18, through its processor 54 and circuits 56 (FIG. 2), would execute the command message. Before proceeding further, it appears appropriate to describe in further detail how the command messages 96 are handled in the system 12. As alluded to earlier herein, whe the interface driver 68 assigns the message sequence number 108, the entire message 96-1 (FIG. 6) is also placed in the RAM 34 (FIG. 2) of the terminal 10; the interface driver 68 is software which is processed by the MP 36 of the terminal 10. The interface driver 68 also places the address of the last-named message 96-1 in another portion of the RAM 34 and connects the associated message sequence number with the address of the last-named message 96-1. Notice that the device address (FIG. 5) is part of the message 96-1. As previously stated, when the interface driver 68 sends the command message to the SPIA board 30, the associated SPIP 70 removes the message sequence number 108 resulting in the message format 96-2 shown in FIG. 7. At this time, the SPIP 70 in association with routines located in the ROM 74 or RAM 76 performs a "three message exchange" to transfer the command message to the appropriate peripheral 18, 20 or 22, for example. In the "three message exchange", the SPIP 70 on the SPIA board 30 sends the "command message" having format 96-2 to a peripheral, like 20, for example, to have a line of printing effected. The peripheral 20 then sends a "reply" to the SPIP 70 indicating that it has received the command message, and thereafter, the SPIP 70 sends an "acknowledgment" back to the peripheral 20. During the time that the "three message exchange" is taking place, the data exchange is effected by a "single thread technique"; in this regard, the SPIP 70 sends a "command message", waits for a "reply" from the peripheral 20, and then sends an "acknowledgment". Even though the SPIP 70 does not send the "message sequence number" to the peripheral 20, the message sequence number is retained in the RAM 76 associated with the SPIP 70. When the "reply" response comes from the peripheral 20 in the example described, the "reply" response and the message sequence number in the RAM 76 (the current one and the only one being worked on) are coupled together by the SPIP 70 and placed in the inbound data latch 86 (FIG. 4) to indicate that the associated command message has been completed. The inbound data latch 86 on the SPIA board 30 may then be queried by the application software (block 58) via the interface driver 68 (FIG. 3). Because the interface driver 68 has stored in RAM 34 the message sequence number and the address for the .associated command message (like message format 96-1 in FIG. 6), the driver 68 can correlate the completed command message with the device address 98 for transference to the application software 58 in the terminal 10. Having described how a command message and a response thereto have been transferred between the terminal 10 and one of its peripherals, like 20, it now appears appropriate to discuss some of the advantages of the system 10. In this regard, it should be noted that the MS-DOS operating system (block 60 in FIG. 3) operates by the "single thread technique" which is another way of saying that it is "single tasking" and is not "multi-tasking". A conventional peripheral interface driver when coupled to an MS-DOS operating system operates on "single thread technique" in that the MS-DOS operating system and the associated conventional driver are "single tasking" and have to wait, for example, until a printing command to be completed on a printer peripheral is actually completed before going on to another task. It should be recalled that one of the objectives of this invention was to make the system 10 compatible with the MS-DOS operating system, but in addition, an objective was to enhance the system 10, making it adaptable for handling asynchronous or multi-tasking activities. Multitasking is defined to be multiprogramming that provides for the concurrent performance, or interleaved execution, of two or more tasks. This has been accomplished in the system 10, and these multi-tasking activities are transparent to the MS-DOS operating system, (block 60) which is a "single tasking system". The interface driver 68 looks as though it is handling the asynchronous activities, when in reality, it is the SPIA board 30 which handles the asyncnronous activities; however changes in the interface driver 68 enable the SPIA board 30 to handle asynchronous activities, and enable the keyboard manager (block 64 in FIG. 3) and the printer manager (block 66) to be handled through the interface driver 68. There are advantages of the system 10 which are brought about by the interface driver 68 and the SPIA board 30, even if the application software (block 58) is not written to take advantage of these two named elements. For example, when the application software (block 58), while operating through the MSDOS operating system (block 60), is performing a printing operation in association with the printer peripheral 20, it does so in a "single thread" or "single tasking" technique as previously explained. This means, in effect, that the application software (block 58) must wait until the printing by peripheral 20 is completed. During the time that the application software (block 58) is waiting, the keyboard manager (block 64) may be used to initiate or enter data which is to be printed also by the printer peripheral 20. The keyboard-entered data then may be transferred into the outbound latch 84 of the SPIA board 30 where it waits until the SPIP 70 on the SPIA board 30 decides to send it to the printer peripheral 20 after completion of the prior printing which was initiated by the application software (block 58). Thus, the throughput of the system 10 is increased even if the application software (block 58) is not designed to take advantage of the multi-tasking effected by interface driver 68 and the SPIA board 30. Several additional advantages of the system 10 are as follows: 1. It permits one low-cost, highly-flexible terminal 10 to control a distributed system of intelligent peripherals 18, 20, and 22, for example. 2. The timings, from terminal 10 (which is positioned on one side of SPIA board 30) are isolated from the timings on the other side of the SPIA board 30. 3. It permits all types of financial peripherals (like 18, 20, and 22) to be interfaced through a single hardware interface (SPIA board 30) instead of having a separate interface for each different peripheral (like 18, 20, and 22). 4. It permits all types of financial peripherals (like 18, 20 and 22) to be interfaced through a single software interface (interface driver 68). 5. It permits secure NBS/DES encryption without having to expose the encoded data and clear text data on the bus 24 (FIG. 1) which is typically an unprotected, in-house link. In other words all the encryption and decryption take place on the SPIA board 30. Some additional comments about the hardware used in the system 12 appear necessary. In this regard, a printing operation will be described. At start up of the system 12, the application software 58 (FIG. 3) initiates a reset signal which is passed down to the peripherals, including the printer 20. The printer 20 then relays information back to the application software 58 so that it knows what type of printer the printer 20 is, its memory size, its model number, etc. Based upon this information, the application software 58 decides whether or not there will be a problem with the printer 20. If a problem exists, the application software 58 will initiate an appropriate message to be displayed on the display 38 of the terminal 10. Assuming that everything is satisfactory in the example described, the application software 58 sends an "Open" command which is listed in Table 1; this readies the printer 20 to receive the next command. Each time these commands are sent from the application software 58, an identification code is also sent to identify the SPIA board 30 (through a hexadecimal code) as the particular board being addressed. In this regard, the peripheral address decoder 82 (FIG. 4) is a circuit which includes two decoders such as Type No. 74LS138 which is available from Texas Instruments Inc., for example. The next data coming from the application software 58 is the first portion of the command message which is sent to the outbound data latch 84 as previously described. The latch 84 includes the Type No 74LS374 latch which is manufactured by Texas Instruments, Inc., for example. Latch 86 also includes a Type No. 74LS374 latch. This latch 84 is a circuit which creates an interrupt (line 114) when data is present in the latch 84; this interrupt (line 114) is used by the SPIP 70 as an indication that data is waiting in the latch 84 for the SPIP 70 to read.. The interrupt on line 114 is also used by the SPIP 70 to update the appropriate bit of the status latch 88 to indicate to the terminal 10 that data is still present in the outbound data latch 84. When the SPIP 70 reads the data in the outbound data latch 84, the act of reading by the SPIP 70 generates an interrupt, as for example, by changing the output of a flip flop (not shown) associated with the circuitry of data latch 84; this change is also registered in status latch 88. The terminal 10 then knows that the data which it sent to the SPIP 70 has been read by it, and accordingly, the application program 58 can send the next byte of data to the outbound data latch 84 to repeat the process until the entire message is sent. In this regard, it should be recalled that the variable length indicator VLI (102 in FIG. 5) within a command message 96 gives the length of data to be sent. The SPIP 70 keeps a.record of the number of bytes of data it is to receive for the particular command message 96. When all the bytes of data are received by the SPIP 70 and stored in its associated RAM 76 (FIG. 4), the SPIP 70 is ready to transfer the data in example being described. Before proceeding further with the printing example being described, it is useful to explain one aspect of the interrupts being discussed. In this regard, the particular central processing unit (MP) 36, used in terminal 10 is an 8088 CPU which is manufactured by Intel Corp. Due to the limited number of interrupts available on the interface bus 28, the SPIP 30 was able to use only one interrupt line. As a result, it was necessary to provide a technique for handling an interrupt from the outbound data latch 84 and an interrupt from the inbound data latch 86. The technique use and was to use an interrupt enable circuit (EN. CIR.) 116. The usual interrupt line 118 coming from the outbound data latch 84 is fed into the EN. CIR. 116, and the output 120 is coupled to the interrupt line 122 which goes back to MP 36 of the terminal 10. The terminal 10 knows when it is sending data to the outbound data latch 84, and it enables the EN. CIR. 116 so that it can pass the interrupt on line 120 to the line 122 when the SPIP 70 reads the data from latch 84. When the terminal 10 is not sending data to the outbound data latch 84, the EN. CIR. 116 is disabled so that any interrupt on line 122 comes in fact from the inbound data latch 86. Assume that all the data to be printed, in the example being described, is loaded into the RAM 76 by the process described. The SPIP 70 recognizes the device address 98 in the command message 96 and prepares to send the data to the printer 20. In the embodiment described, the SPIP 70 is, in essence, a microcomputer on a chip, being Type #7041 which is manufactured by Texas Instruments, Inc. Type #7041 has a Universal Asynchronous Receiver Transmitter (UART) on the chip itself. The UART 124 associated with the SPIP 70 is shown in FIG. 4. An important point to emphasize here is that the UART 124 is on the chip itself so that communication between the UART 124 and the CPU or MP 72 is internal to the chip itself. The output of the UART 124 passes to the serial bus transceiver 92 (Type #75176 which is manufactured by Texas Instruments, Inc.) which converts the binary signals from the UART 124 to the appropriate wave shapes for serial transmission over the interface bus 24 to the printer 20. The printer 20 (FIG. 2) includes the serial bus transceiver 52-1 which is identical to transceiver 92 (FIG. 4) already discussed. In the embodiment described, the serial bus secondary and peripheral driver processor 54-1 also includes a microcomputer on a chip, being Type #7041 which is identical to that used for SPIP 70. The processor 54-1 also includes a UART (not shown) which is identical to UART 124 shown in FIG. 4 to provide for the receiving of data which is then forwarded to the peripheral dependent circuits 56-1 which perform th actual printing.
|
Same subclass Same class Consider this |
||||||||||