WO1992012486A1

WO1992012486A1 - Novel transaction system architecture

Info

Publication number: WO1992012486A1
Application number: PCT/US1992/000140
Authority: WO
Inventors: Gordon Paul Eckley, Jr.; Jeffrey Paul Hill
Original assignee: Verifone, Inc.
Priority date: 1991-01-09
Filing date: 1992-01-09
Publication date: 1992-07-23
Also published as: AU1203692A

Abstract

A novel transaction system (400) is provided which includes a CPU (387) and a plurality of peripherals (391-1 through 391-7). Communication between the CPU and peripherals is via a local area network, a communication port or a high speed serial bus (350) by which each peripheral is connected in common to the CPU. The CPU is also connected to various memory devices via a parallel bus which provides a higher bandwidth than the high speed serial bus. The CPU is also aware of time delays associated with operations performed by various peripheral devices and can send data to the plurality in a multiplexed fashion, thereby increasing system speed as a CPU is utilizing valuable time which would otherwise be spent waiting for a given peripheral to process an initial piece of data.

Description

NOVEL TRANSACTION SYSTEM ARCHITECTURE

CROSS-REFERENCE TO RELATED APPLICATIONS

The following co-pending applications are related to this application:

Attorney

Filing Docket

USSN Date Title Number

639,583 1/9/91 Transaction System VERI-126 Including Novel Memory Architecture & Management

639,572 1/9/91 Transaction System VERI-127 Including Novel Program Structure

640,279 1/9/91 Method and Structure VERI-129 for Determining Transaction System Hardware & Software Configurations

639,838 1/9/91 Emulator for Use with VERI-144 a Transaction System

Technical Field

This invention pertains to a transaction system, such as a point of sale transaction system, and more particularly to a novel transaction system having unique architecture including an internal bus structure for connecting the transaction system CPU with any desired selection of peripheral tiles which perform desired functions and/or interface to desired peripherals.

Description of the Prior Art

Transaction automation systems are well known in the prior art and include the familiar electronic cash registers. Such prior art transaction systems typically include a microprocessor which includes predefined code to provide operating system software and an applications system software environment. Prior art transaction systems include a fixed hardware configuration with very few opportunities for tailoring the system to specific customer needs or desires. For example, a typical prior art electronic cash register system will include a fixed hardware configuration but might allow a user to

"customize" his system solely by his choice of whether or not a particular peripheral is physically connected to the electronic cash register. However, in such prior art systems a customer must pay for hardware which may not be needed. For example, in such a fixed transaction system architecture, appropriate interface circuitry for a UPC scanner is included regardless of whether a particular user wishes to connect a UPC scanner to his particular system. While such prior art systems have become widespread due to their relative simplicity, they remain rather inflexible and expensive in that they are not readily capable of being customized for a particular user in order to maximize the features available to that user while min.imizing costs by avoiding the inclusion of unnecessary features and associated hardware.

SUMMARY In accordance with the teachings of this invention, a novel transaction system is provided. In one embodiment, this transaction system includes CPU and a plurality of intelligent peripherals each being controlled by a microcontroller. Communication between the CPU and peripheral is via a serial bus by which each peripheral is connected in common to the CPU. A plurality of decode select lines are provided such that the CPU can select a desired one of the plurality of peripherals connected to the CPU bus. One or more interrupt request lines are provided such that each peripheral is able to send an interrupt request to the microprocessor. When shared interrupt request lines are provided, the microprocessor pulls each peripheral associated with the interrupt request line on which an interrupt request is received, in order to determine which one or more peripherals provided the interrupt request.

In one embodiment of this invention, the CPU is aware of t.ime delays associated with operations performed by various peripheral devices. In this manner, the CPU will not send to a given peripheral data in excess of that which the peripheral can handle in a given amount of time. This freezes the CPU for performing other tasks while feeding information to peripherals piecemeal at a rate which the peripheral can process that data. The CPU can, in this manner, send data to a plurality of peripherals in a multiplexed fashion, thereby increasing system speed as a CPU is utilizing valuable time which would otherwise be spent waiting for a given peripheral to process an initial piece of data.

In one embodiment of this invention, a novel power down circuit including a power down power source such that, upon power down, the system remains active for a given amount of time in order to allow processing then taking place to be completed by the CPU and/or various peripherals. When the processing is complete, the result is stored in memory or otherwise acted upon by the CPU, which then powers the system down without loss of data.

In one embodiment of this invention, the CPU includes a parallel bus to which various memory devices are connected. If desired, other than memory devices are also connected to this parallel bus which provides a higher bandwidth than the high speed serial bus.

In one embodiment of this invention, in addition to the high speed synchronous serial bus which is used to connect the CPU with various peripherals, the CPU also provides serial "com" ports for connection to peripheral devices designed to interface directly with such com ports. In one embod.iment, a local area network (LAN) is included while a transaction system to communicate with other transaction systems or with a host processor. Such embodiment action system is a stand-alone device running all software necessary for its operation. In an alternative embodiment, certain software and/or data files are provided by the host to which communication is made via the LAN. In another embodiment, a plurality of transaction systems are used in a network and one transaction system is configured to operate as a host. This host transaction system can, if desired, serve solely as a host or can also serve as a transaction terminal as well. In another embodiment, the host functions are distributed among a plurality of transaction systems connected in a network, thereby providing processing to perform the host functions.

BRIEF DESCRIPTION OF THE DRAWINGS Figure 1 is a block diagram of one embodiment of plurality of transaction systems constructed in accordance with the teachings of this invention being utilized in a multi-lane retail environment;

Figure 2 is a block diagram depicting the operation of the Motorola SPI bus; Figure 3 is a block diagram depicting one embodiment of a transaction system bus constructed in accordance with the teachings of this invention; and

Figure 4 is a block diagram depicting one embodiment of a transaction system constructed in accordance with the teachings of this invention including various peripheral devices.

DETAILED DESCRIPTION In accordance with the teachings of this invention, a low cost transaction terminal is taught which integrates automated parts of business transactions. The transaction system of this invention, if desired, operates as part of a network which provides services to the transaction system and to which the transaction system communicates.

In accordance with the teachings of this invention, memory is provided such that application programs are included which have been selected from a predetermined set of application software, such that the software included is selected to most appropriately handle the user's desired needs. Furthermore, in one embodiment of this invention, the memory architecture is organized in a manner which allows convenient downloading of modified versions of application software for additional application software modules. In one embodiment of this invention, such a memory architecture as disclosed in the above referenced U.S. patent application entitled "Transaction System Including Novel Memory Architecture & Management" is utilized.

The transaction system of this invention is designed to operate in a wide variety of system configurations. For example, the transaction system of this invention can be run as a stand-alone system, for example, in a small convenience store. Alternatively, the transaction system of this invention is capable of being networked with a large number of similar transaction systems, for example as might be found in a large supermarket or department store.

A common configuration is shown in Fig. 1, in which a plurality of transaction terminals 103-1 through 103-N are used in a network in a multilane environment, for example in a supermarket or a department store. A typical configuration includes a remote PC or mainframe 104, backroom computer 101, and a number of transaction terminals 103-1 through 103-N located throughout the store. Backroom computer 101 serves a controller for terminals 103-1 through 103-N via LAN 102. Remote computer 104 is connected to backroom computer 101, for example via a telephone line. Backroom computer 101 includes LAN controller 101-2. In one embodiment of this invention, backroom computer 101 is a standalone computer such as a PC. In another embodiment, backroom computer 101 is a transaction terminal which is similar to transaction terminals 103-1 through 103-N, but including software to allow it to function as a backroom computer. In another embodiment of this invention, backroom computer 101 comprises a transaction terminal which serves both as a backroom computer and as a transaction terminal itself. In yet another embodiment, backroom computer 101 is provided by dividing the backroom processing task among a plurality of transaction terminals which then simultaneously operate to provide a portion of the backroom computer function and as transaction terminals.

As used herein, the "remote functions" are those carried out by the remote computer; "controller functions", are those carried out by the backroom PC; and "terminal functions" are those carried out by the terminals. It is to be understood that the distribution of functions described now is by way of example only and the actual distribution of functions can vary widely between the various embod.iments of this invention, without detracting from the spirit of this invention.

Remote Functions

A remote computer is not local, not connected directly to the LAN. Thus it is not positioned to participate in the real time transaction activity (e.g. a point of sale activity) . Notwithstanding the above, in certain embodiments, as will be described in more detail later, diagnostic and debugging activities of one or more transaction terminals or their peripherals are conducted by the remote computer in real time. In a typical application, the remote computer serves to gather data from the local (controller-terminal) system, modify tables and parameters in the local system, initiate some changes to the software in the local system; and respond to requests initiated by the local system.

Controller Functions The processor carrying out controller functions may be a transaction terminal or backroom computer, such as a personal computer (PC) . In the embodiment in which a transaction terminal itself serves as the controller, the transaction terminal serving as a controller may also be utilized as a transaction processor, thereby minimizing hardware requirements. In yet another embodiment, the controller functions are dispersed among a plurality of transaction terminals which function as transaction terminals, thereby again minimizing hardware requirements while not unduly burdening the capabilities of a single transaction terminal. Some controller functions look like system resources to individual transaction terminals rather than control, but all the local controlling functions are always a part of this functionality. One example is a gas pump controller, which must be resident on a single .machine, but accessible from all terminals. Another example is a printer or display updated by all terminals, such as a kitchen printer or display in a restaurant. Examples of controller functions performed by the backroom PC which control the transaction terminals include calling for reports, updating terminal data and programs, setting time/date from controller, broadcast shut-down messages for store closing, and providing conduit for credit/check approval; etc.

Examples of shared resources, i.e. resources of the backroom PC which are made available to individual transaction terminals, include a master file server, and a single scanning code file used by all terminals, (such files may be quite large so sharing is efficient) . If a program or file providing controller functionality is active on one processor, then that is the only place it is active thou there may be backups in other locations. Normally controller programs and files will be found on a single machine (either a backroom PC or one of the transaction terminals), referred to as the controller.

Terminal Functions

The programs and files providing terminal functions for a given transaction terminal reside on that transaction terminal and are not used by another transaction terminal. These functions interact closely with the controller functions. Typical transaction terminal programs and files include the sales appli¬ cation programs and a local file server and its local files. Typical examples of terminal (non-sales) applications are either data-entry (time & attendance recording, accounting date entry, inventory recording) or reporting (sales, accounting, gas pump status, etc.)

Inter-Terminal Network Functionality The LAN provides for communication between the controller and the transaction terminals. If the controller is also a transaction terminal, then the - controller and terminal software will communicate with each other through the LAN. The LAN operates by means of a single LAN-master program (different versions for a transaction terminal and a PC LAN master) and a LAN slave for each transaction terminal. The LAN-master program and LAN-slave program are in direct communication on the network. The .LAN-slave programs only communicate with each other via the LAN master.

The LAN master is normally on the same processor as the controller functionality, although the LAN master and controller functionality can be placed in different pieces of hardware, if desired. When controller processes are run on a transaction terminal, the LAN treats the controller and transaction terminal processes on that transaction terminal as separate entities. Typically, on that transaction terminal, there is a LAN-master program for controller processes and a LAN-slave program for the transaction terminal processes. Thus, by providing each transaction terminal with both LAN-master and LAN-slave software, any one or more transaction terminal in a network can be easily configured to operate as a controller. In one embodiment of this invention, one such controller includes a modem shared by the transaction terminal operating as a controller, and its slaves. Thus, a network can be configured which includes less than one modem per transaction terminal, thereby reducing hardware expense and min.imizing the number of telephone lines per transaction system. In one embodiment of this invention, the application system software is written using .ANSI C standard. If desired, any functionality not provided by ANSI C is provided in an include file SYSLIB.h.

Peripheral input and output is handled by low level input/output routines provided in the include file SYSLIB.H (read, write, open, close, etc).

In one embodiment, the software was developed, compiled and tested under MSDOS (version 4.01). The MSDOS environment was chosen because it is simple, well know-n and widely used and because it provides upward compatibility with OS/2. The software was cross compiled onto the Motorola 68302 microprocessor using the Lattice C Development System, ES68K, for DOS and OS/2. For development under DOS/OS2/UNIX/etc. , any compiler that is ANSI compatible may be used for initial compilation. The code that is to be resident and execute on the terminal is compiled using, for example, the Lattice cross compiler, and processed via a linker and loader specific to the system being implemented.

Transaction System Peripheral Support Network Configuration

In accordance with the teachings of this invention, a plurality of transaction terminals may be connected together with one or more networks. In one embodiment, the SPI bus available in Motorola products such as the Motorola 68302 microprocessor and Motorola 6805 microcontrollers is utilized in a novel fashion to provide network interconnections. Figure 2 is a diagram depicting a typical SPI configuration. Microprocessor 200, such as the Motorola 68302 microprocessor, serves as a master device, and microcontroller 201, such as the Motorola 6805 microcontroller, serves as the slave device. The Motorola family of devices which include SPI BUS interfaces are designed as low-cost devices capable of providing high speed synchronous serial communication between two such low-cost devices. Thus, Master 200 provides a master-out/slave-in (MOSI) serial bit stream on serial data line 203. Conversely, slave 201 provides its serial data on master-in/slave- out (MISO) line 202. Master 200 provides a system clock SCLK on SCLK lead 204, thereby allowing Slave 201 to be synchronized with Master 200. MISO lead 202, MOSI lead 203, and SCLK lead 204 form cable 205.

Figure 3 depicts the interconnection between a master processor 300 and a slave microcontroller 301 in one embodiment of this invention. In contrast to what was intended by its designers, in the teachings of this invention, the low cost SPI bus is used in conjunction with additional hardware and control software in order to connect a master microprocessor to a plurality of slave microcontrollers. As shown in Figure 3, master microprocessor 300 provides MOSI data on lead 303. Saimilarly, master microprocessor 300 provides SCLK on SCLK lead 304. Furthermore, slave microcontroller 301 provides its transmitted data to master microprocessor 300 on microprocessor input lead 302 such that microprocessor 300 receives MISO data as described in Figure 2. However, there ends the similarity between the bus st.ructure of the present invention and the prior art SPI bus. As shown in Figure 3, master microprocessor circuit 390 includes a plurality of buffers and ESD/EMI protection networks, as well as additional logic elements. Similarly, microcontroller circuit 391 includes a plurality of buffers and ESD/EMI protection networks. Perhaps more significantly, master microprocessor 300 is configured utilizing firmware to provide a plurality of its I/O leads as slave select lines slave SELO through slave SELN. This allows master microprocessor 300 to provide select signals (via the appropriate one of the select lines)to enable a desired one of a plurality of N slave microcontrollers, such as slave 0 microcontroller 301. In addition, the master processor 300 software is configured to provide a reset signal on one I/O lead which serves as a master reset signal to reset all slave microcontrollers. An additional I/O lead of master microprocessor 300 is configured via firmware as an interrupt input lead INT. An additional I/O lead of master microcontroller 300 is configured as a gate output lead, which serves to provide a gate signal to selectively enable the interrupt input lead of master microprocessor 300.

Each slave microcontroller is configured to provide one of its I/O leads as an interrupt output lead, which allows each slave microcontroller to provide an interrupt signal to master microprocessor 300. In this embodiment, these interrupt signals are logically combined by AND gate 331 and fed to one input lead of gating AND gate 333, which is enabled or disabled in response to the gate signal from microprocessor 300. Thus, when microprocessor 300 enables its interrupt input lead, microprocessor 300 is able to detect when any one or more of the slave microcontrollers has issued an interrupt request to microprocessor 300. Microprocessor 300 is then able to select each slave microcontroller in any predefined or random order, in order to ascertain with certainty which one or more slave microcontrollers issued the interrupt request to microprocessor 300. Once known, microprocessor 300 may initiate direct communication with the slave microprocessor which had issued the interrupt request. During this communication, master microprocessor 300 provides serial data on its MOSI lead to all slave microcontrollers and selects (via the appropriate one of the select lines) a single slave microcontroller to receive such serial data. The selected slave microcontroller provides its response to AND gate 332, which in turn provides MISO data to microprocessor 300. In one embodiment of this invention, master microprocessor MOSI data is echoed by a receiving slave microcontroller back to master microprocessor as master microprocessor MISO data in order to insure the data is properly received by the slave microcontroller. In one embodiment, when a slave microcontroller is selected and is providing serial data to master microprocessor 300, master microprocessor 300 echoes this data back to the selected slave microprocessor in order to verify that the data has been properly received from slave microprocessor. In one embodiment of this invention, the echoing is done in an inverted fashion.

Transaction System Description Figure 4 is a block diagram depicting one embodiment of a transaction system constructed in accordance with teachings of this invention. Transaction system 400 includes master microprocessor system 400, and a plurality of microcontroller systems 391-1 through 391-7. As shown in Figure 4, CPU module 387 includes a microprocessor such as the 68302 microprocessor available from Motorola. In addition, CPU module 387 includes devices well known to those of ordinary skill in the art in microprocessor design, such as EPROM, SRAM, SRAM battery, serial I/O (SIO) ports, CPU bus for interconnecting the microprocessor and memories, and the like. As shown in Figure 4, transaction system 400 includes bus means 350, as previously described in regard to Figure 3, for interconnecting CPU subsystem 390 with peripheral devices 391-1 through 391-7. As shown in Figure 4, peripheral devices are generally located external to the CPU system 390 printed circuit board, although this is not necessary. As shown in the embodiment of Figure 4, at least one peripheral device 391-7 is physically mounted on the CPU 390 printed circuit board , and yet is connected to CPU module 387 via bus 350.

A wide variety of peripheral devices may be utilized in accordance with the teachings of this invention. More importantly, the type of peripheral devices and their interface circuity may be selected so as to custom tailor the transaction system and indeed the transaction system network to a user's specific needs.

In the embodiment shown in Figure 4, transaction system 400 includes display module 391-1 which serves to drive, for example, a two-line by 20 character per line display 3911-1. In a preferred embodiment, display module 391-1 is located within the housing of the transaction system and is connected to the CPU module via bus 350. Display module 391-1 includes microcontroller 3911-3 (for example a Motorola 6805C4 device) which includes appropriate firmware which allows display module 391-1 to operate as a separate, intelligent device distinct from CPU module 387. Thus, transaction system 400 is a distributed processing in that CPU module 387 is performing certain functions while simultaneously display module 391-1 is acting in an intelligent manner in order to communicate with CPU module 387 and drive display 3911-1. Display module 391-1 also includes high voltage drivers 3911-2 which receives signals from microcontroller 3911-3 and provide appropriate voltage signals to display 3911-1 in order to create a desired display. Display 3911-1 is located in any convenient location and is connected to display module 391-1 via suitable wiring. The firmware of microcontroller 391-3, the design of high voltage drivers 3911-2, and the interconnection to display 3911- 1 are all conventional and thus will not be described in detail.

Display module 391-2 serves to drive an additional display 3912-1 which, in this embodiment, comprises a one-line, 16 character per line display. In this embodiment, display 3912-1 is positioned for easy viewing by the customer.

Keyboard module 391-3 serves to intelligently control keyboard 3913-1 via microcontroller 3913-2. By utilizing microcontroller 3913-2 (which comprises for example a Motorola 6805C4 microcontroller), keyboard module 391-3 is able to intelligently control keyboard 3913-1 and effectively operate as a distributed processing system with CPU module 387. Furthermore, a desired keyboard module may be selected and inserted into a given transaction system, such that various style keyboards can be selected and utilized.

MSR/BCR module 391-4 serves to read magnetic stripes and/or bank card stripes, for example, from credit cards. MSR/BCR module 391-4 includes read-head 3914-1, as is well known in the art, and microcontroller 3914-3 (in this embodiment, a Motorola 68HC11 microcontroller) . MSR/BCR module 391-4 also includes random access memory 3914-2 which serves to store signals received by read-head 3914-1 as a credit card, or the like, is passed over read-head 3914-1. This data is then decoded by microcontroller 3914-3 in order to provide output data to 350 indicating the data stored on the magnetic stripe being read. Once again, the use of microcontroller 3914-3 allows MSR/BCR module to operate in an intelligent fashion without detracting from the capabilities of CPU module 387.

Printer module 391-5 serves to control printer 3915-3 and, if desired, paper re-roll mechanism 3915-4. Module 391-5 includes microcontroller 3915-2 (in this embodiment a Motorola 68HC05CH microcontroller) and random access memory 3915-1.

Additional peripherals such as peripheral 391-6 are capable of being added to bus 350 in order to make a desired transaction system including whatever peripherals are desired. Additional peripherals include, for example, other types of display modules, including those not requiring high voltage drivers, local area networks, wireless local area networks, additional printer modules, other types of displays, including, for example, CRTs, other types of input devices such as a mouse, a UPC scanner, a signature capture tablet, or a key pad operated by a customer for entering their personal identification number (PIN) when that customer utilizes his ATM card as payment. Communication devices such as modems are also capable of being added to bus 350.

As shown in Figure 4, additional peripherals can include various types of storage modules, including hard disk drives, or floppy disk drives, which are interfaced to bus 350. System 400 also includes power module 491 which receives power, for example, through a 24 volt transformer with rectifier 492 which in turn receives its power from an AC main. In one embodiment of this invention, power module 491 with rectifier 492 can be formed as a single unit located external to CPU system 390 such that only the system supplies are provided as input power to CPU system 390 for use within CPU system 390 and routing to various peripherals.

Also, as shown in Figure 4, CPU module 387 includes a parallel CPU bus which is used, for example, to connect to memory devices that can be read and written to in a parallel fashion. Examples of such devices which are connected to the CPU bus are the EPROM and SRAM memory contained within CPU module 387, and external memory devices such as additional SRAM and a JEIDA card. Other devices are, if desired, connected to CPU module 387 via a CPU bus. For example, modem/telephone module 398 is one such device, which comprises, for example, a 1200 or 2400 baud modem. In one embodiment of this invention, modem/telephone connection module 398 is replaced by a TRANZ 330 device, or variant thereof, available from Verifone, Inc., which serves as a magnetic strip reader and modem.

If desired, an additional I/O bus 493 is used, for example, running at standard TTL levels, for controlling other types of devices which may be conveniently used as currently manufactured, and do not necessarily require interfacing to bus 350. An example is cash drawer with tray insert 494, which is readily available on the market and operates at TTL levels and which, by its very nature, is a very simplistic device which does not require any significant amount of processing time to control. Thus, cash drawer with tray insert 494 is conveniently connected to CPU module 387 via the I/O bus 493 without the need for additional interfacing. Other types of devices suitable for connection to I/O bus 493 include telephone connection 495, and various devices available for interfacing via RS-232 interfaces, labelled for convenience as devices 496-1 through 496-N. In alternative embodiments of this invention, various devices shown in Figure 4 connected to I/O bus 493 are configured to be connected to bus 350. Therefore, great flexibility is provided in interfacing peripherals and external devices to either internal bus 350 or I/O bus 493. Other types of devices suitable for connection to

I/O bus 493 include various devices available for interfacing via other types of interfaces, such as the IEEE-485 interface. These devices are shown in Fig. 4, labeled as devices 497-1 through 497-N. As shown in Figure 4, CPU module 387 includes power-down battery 399. Power-down battery 399 serves to maintain power to CPU module 387 in the event of a power-down for a sufficient period of time to allow CPU module 387 to complete the task it is currently performing. This allows the transaction system to complete any distributed processing tasks in process at the time of such power-down. Thus, for example, if a credit card is being read by MSR/PR module 391-4 during a power supply anomaly, sufficient time is provided to allow this task to be completed and data provided to CPU module 387 prior to power-down. In one embodiment of this invention, power-down battery 399 supplies sufficient power to the system, including peripherals, for approximately 10 seconds in the event of power-down. In one embodiment of this invention, power-down battery 399 is selected to allow for such power-downs to occur within an 8-hour period while still providing ample power-down battery capabilities.

In one embodiment of this invention, CPU module 387 is programmed to be aware of the time delay it will experience when communicating with peripheral devices connected into a transaction system. For example, when the CPU sends instructions to a peripheral printer, a certain amount of t.ime is required. for the printer to respond. When the CPU is programmed in accordance with the teachings of this invention, the CPU will only send information to that peripheral device at a speed which the peripheral is able to respond. By knowing this information, CPU is able to multiplex its communications to various peripherals, thereby effectively communicating with a plurality of peripherals simultaneously, thereby providing high system performance even though each peripheral has associated delays in processing.

All publications and patent applications are herein incorporated by reference to the same extent as if each individual publication or patent application was specifically and individually indicated to be incorporated by reference.

The invention now being fully described, it will be apparent to one of ordinary skill in the art that many changes and modifications can be made thereto without departing from the spirit or scope of the appended claims.

Claims

WHAT IS CLAI.MED IS:

1. A transaction terminal comprising:

a CPU; a parallel CPU bus; one or more memory devices connected to said parallel CPU bus; a high speed synchronous serial bus for connecting said CPU with a plurality of peripheral devices; and a plurality of select lines, each associated with an associated one of said peripheral devices, such that said CPU can select a desired one of said peripheral devices via said select line associated therewith.

2. A system as in claim 1 which further comprises an interrupt line connecting a plurality of said peripheral devices with said CPU, such that any one of said peripheral devices connected to said interrupt line may issue an interrupt request to said CPU.

3. A system as in claim 2 wherein said CPU further comprises means for polling said peripheral devices connected to said interrupt line in response to the receipt by said CPU of an interrupt request in order to determine which one or more of said peripheral devices issued an interrupt request.

4. A system as in claim 1 which further comprises a plurality of peripheral devices connected to said CPU via said high speed synchronous serial bus, wherein each of said peripheral devices include an identification code associated therewith, and wherein said CPU includes means for polling each peripheral connected to said CPU to determine its identification code.

5. A system as in claim 4 wherein said polling is performed upon power up of said system.

6. A system as in claim 4 wherein said CPU exercises software in a fashion related to the presence of said peripherals.

7. A system as in claim 1 wherein said CPU furhter comprises a power down means for maintaining power to said system and peripheral devices upon a loss of power for a predetermined period of time.

8. A system as in claim 1 wherein said CPU furhter comprises a power down means for maintaining power to said system and peripheral devices upon a loss of power until such time as said CPU determines that specific processing operations have been completed.

9. A system as in claim 1 wherein said CPU communicates with said peripherals by sending a plurality of serial data streams, each of said plurality of serial data streams being sent after a specified period of time after a previous one of said data streams has been sent, said sizes and specified period of time being selected based upon the type of peripheral device to which it is sent, and the type of operation to be performed by said peripheral device.

10. A system as in claim 9 wherein said CPU communicates with a plurality of peripheral devices via . said high speed synchronous serial bus in a multiplexed fashion.

11. A system as in claim 1 which furhter comprises one or more serial com ports for connection to peripheral devices.

12. A system as in claim 1 in which additional peripheral devices are connected to said CPU via said parallel CPU bus.

13. A system as in claim 1 which further comprises a LAN interface for communication with other transaction terminals.

14. A system as in claim 1 which furhter comprises means for connection to a host computer.

15. A system as in claim 13 which furhter comprises means for serving as a host computer to other transaction terminals via said LAN.

16. A system as in claim 13 which further comprises means to serve as a portion of a distributed processing host to other transaction terminals, via said LAN.