WO1989012271A1 - Voice information system and method for telephone applications - Google Patents

Voice information system and method for telephone applications Download PDF

Info

Publication number
WO1989012271A1
WO1989012271A1 PCT/US1989/002250 US8902250W WO8912271A1 WO 1989012271 A1 WO1989012271 A1 WO 1989012271A1 US 8902250 W US8902250 W US 8902250W WO 8912271 A1 WO8912271 A1 WO 8912271A1
Authority
WO
WIPO (PCT)
Prior art keywords
signal
bus
telephone line
voice
communications interface
Prior art date
Application number
PCT/US1989/002250
Other languages
French (fr)
Inventor
James E. Millington
Jonathan R. Saunders
Randall R. Pfeiffer
Martin F. Parker
William G. Hooper
Charles A. O'donnell
Original Assignee
Genesis Electronics Corporation
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Genesis Electronics Corporation filed Critical Genesis Electronics Corporation
Publication of WO1989012271A1 publication Critical patent/WO1989012271A1/en

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04MTELEPHONIC COMMUNICATION
    • H04M3/00Automatic or semi-automatic exchanges
    • H04M3/42Systems providing special services or facilities to subscribers
    • H04M3/54Arrangements for diverting calls for one subscriber to another predetermined subscriber
    • H04M3/546Arrangements for diverting calls for one subscriber to another predetermined subscriber in private branch exchanges
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04MTELEPHONIC COMMUNICATION
    • H04M3/00Automatic or semi-automatic exchanges
    • H04M3/42Systems providing special services or facilities to subscribers
    • H04M3/50Centralised arrangements for answering calls; Centralised arrangements for recording messages for absent or busy subscribers ; Centralised arrangements for recording messages
    • H04M3/53Centralised arrangements for recording incoming messages, i.e. mailbox systems
    • H04M3/533Voice mail systems
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04MTELEPHONIC COMMUNICATION
    • H04M3/00Automatic or semi-automatic exchanges
    • H04M3/42Systems providing special services or facilities to subscribers
    • H04M3/487Arrangements for providing information services, e.g. recorded voice services or time announcements
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04QSELECTING
    • H04Q1/00Details of selecting apparatus or arrangements
    • H04Q1/18Electrical details
    • H04Q1/30Signalling arrangements; Manipulation of signalling currents
    • H04Q1/44Signalling arrangements; Manipulation of signalling currents using alternate current
    • H04Q1/444Signalling arrangements; Manipulation of signalling currents using alternate current with voice-band signalling frequencies
    • H04Q1/45Signalling arrangements; Manipulation of signalling currents using alternate current with voice-band signalling frequencies using multi-frequency signalling

Definitions

  • the invention relates to voice processing systems for receiving telephoned voice signals, digitizing the voice signals, and processing the digitized signals.
  • the invention is a system and method for performing a variety of voice processing operations, including voice mail and automated call forwarding operations, and processing both digitized voice data and other digital data.
  • Conventional voice processing systems include circuitry for digitizing voice signals, circuitry for generating analog audio signals from stored digital signals, and one or more computers for processing both digitized voice signals and high-frequency encoded telephone keypad command signals. Such telephone keypad command signals will be referred to herein as "dual tone multiple frequency" or "DTMF" signals.
  • a voice mail system is one type of conventional voice processing system.
  • a conventional voice mail system is described in U.S. Patent 4,371,752, issued February 1, 1983 to Matthews, et al., and U.S. Patent 4,652,700, issued March 24, 1987 to Matthews, et al.
  • This voice mail system allows users at remote telephone locations to record voice messages for designated addressees, and to play back and edit the recorded messages by transmitting preassigned DTMF codes over telephone lines.
  • a user may also access the system by telephone, enter a preassigned DTMF identification code, and receive any messages that have been recorded on the system for the user. Once a message has been recorded on the system, the system is capable of automatically dialing the message addressee to deliver the recorded message.
  • the system digitizes received analog audio signals before it digitally processes them, and is capable of generating analog audio output signals from stored digital signals.
  • the system of U.S. 4,371,752 includes CPU 70 (a component of call processor subsystem 62A) and CPU 100 (a component of administrative subsystem 60).
  • Each CPU is connected by a multibus to a number of identical "Universal Control Boards" ("UCBs"), including communication port interface 74, disk adapters 76 and 78, and block transfer interface bus unit 80 (for CPU 70), and disk adapters 114 and 116, and block transfer interface bus unit 118 (for CPU 100).
  • Each UCB includes an Intel 8085 microprocessor which is preprogrammed to establish a definite function for the UCB.
  • Communication port digital data bus 88 connects communication port interface 74 with a number of communication port drivers 92.
  • a CODEC 96 is connected between each driver 92 and a user telephone 18.
  • Communication port interface 74 accepts digitized audio signals from each CODEC and supplies them on the multibus to the other system components for processing.
  • Interface 74 also supplies digital signals received on the multibus from the other system components to the CODECs for conversion into analog audio format for transmission to the appropriate user telephones.
  • the system disclosed in U.S. 4,371,752 has a severely limited range of applications.
  • the system is capable of functioning only as a voice mail system, with an extremely limited menu of user- selected operations, and with each individual port driver 92 performing a fixed, identical function.
  • the port drivers are not independently programmable to perform programmed functions, and there is no capability for the system users to program a system CPU to process both digitized voice messages and other digital data stored in a common file structure in the system, for example to generate customized output signals, such as voice reports.
  • U.S. Patent 4,625,081 Another conventional voice mail system is disclosed in U.S. Patent 4,625,081, issued November 25, 1986 to Lotito, et al.
  • the system of U.S. 4,625,081 includes an information processing system 250 which in turn includes one or more general purpose processors (942 and 944) said to be capable of executing application programs.
  • the system also includes a number of real-time subsystems (230 through 238) for receiving voice and control signals from telephone room subsystems 206, 214, and 216, providing switching connections between channels, and communicating with processing system 250 to facilitate storage and retrieval of voice messages.
  • the disclosed applications of the system are limited to use as a voice mail system with an extremely limited menu of user-selected operations. There is no suggestion that the system be used to process both digitized voice messages and other digital data stored in common file structure in the system, for example to generate customized output signals, such as voice reports.
  • U.S. Patent 4,549,047 issued October 22, 1985 to Brian, et al.
  • the U.S. 4,549,047 system includes a number of digital computers 22 each communicating with a telephone signal conversion subsystem 40 via a digital data bus 24.
  • Subsystem 40 receives Touch-Tone telephone signals and analog signals on telephone lines 94, digitizes the analog voice signals received on lines 94, and forwards the received telephone signals in digital form to one of computers 22.
  • computer 22 may store or retrieve a digital voice message.
  • 4,549,047 does not disclose applications other than a limited menu of voice mail applications, and in particular, fails to disclose the operation of processing both digitized voice messages and other digital data stored in a common file structure in the system, for example to generate customized output signals, such as voice reports. Further, U.S. 4,549,047 teaches that computer 22 should preferably be a Digital Equipment PDP-11 computer. Such a conventional, general-purpose computer is not specially adapted for streamlined voice processing applications.
  • the system of U.S. 4,716,583 detects incoming telephone calls from users, initiates telephone calls to users, decodes DTMF commands from users, and translates ACSII text into analog voice signals for transmission on telephone lines to users (for example, in response to DTMF commands from the users).
  • the system includes a central CPU 12 which is connected by a data bus to a number of host computers 23 and to a text-to-speech processing unit 25 for each host computer.
  • a telephone line 27 is connected to each processing unit 25.
  • CPU 12 may forward ASCII data from a host computer 23 to one of the processing units 25 for conversion into an analog voice signal.
  • Unit 25 may then forward the analog voice signal to a user over one of the telephone lines 27.
  • DTMF command signals may flow from each telephone line 27 to CPU 12.
  • CPU may execute an application program, such as an electronic mail program.
  • the system of U.S. 4,716,583, however, is not capable of accepting analog voice messages on telephone lines 27, digitizing such voice messages, and storing them (for later transmission in digital form to one of the host computers or reconversion to analog form for retransmission in analog form on phone lines 27).
  • the system of U.S. 4,716,583 capable of processing digitized telephone voice messages together with other digital data.
  • the computer programs employed by each CPU 31 in the U.S. 4,716,583 system reside in a read-only-memory 35, so that each text-to-speech processing unit 25 has a preassigned function which may not be changed, for example, by downloading new software from central CPU 12.
  • the invention is voice processing system and method for performing a variety of operations, including voice mail processing, in response to digital signals, including digitized voice signals and DTMF telephone keypad signals.
  • a preferred embodiment of the inventive system includes a CPU, a number of programmable communications interface (“PCI") units, and a bus connecting the CPU with the PCI units.
  • PCI programmable communications interface
  • Each PCI unit interfaces with one or more telephone lines, and includes means for digitizing analog signals received on each telephone line and for converting digital signals from the bus into analog form for transmission on selected ones of the telephone lines.
  • the CPU is specially designed to communicate extremely rapidly with devices coupled with the CPU on an SCSI bus.
  • the CPU and the PCI units are controlled by a software operating system in which both digitized voice signals and other digital data may coexist, for efficient processing in a single file structure.
  • the operating system employs novel data constructs known as "pseudo-files" and files known as "tagged messages".
  • tagged messages One important type of tagged message is a file which includes not only a voice message, but also instructions to the operating system for causing playback of voice prompts inviting the voice message recipient to send either a voice mail reply or to execute a customized application program.
  • pseudo-files the inventive system facilitates rapid file creation, which advantageously minimizes the perceptible delay to a system user desiring to record a voice message as an operating system file.
  • the operating system of the invention also allows a user to customize a voice menu of options to be vocally presented to persons calling one of the PCI units. Examples of such options include execution of a voice mail application program, or another, custom designed application program, by sending DTMF and vocal signals over a telephone line.
  • each PCI may be independently defined by software downloaded from the CPU.
  • the invention comprises improved methods, preferably implemented in software, for automated monitoring and transferring of incoming telephone calls.
  • Figure 1 is a block diagram of a preferred embodiment of the inventive system.
  • Figure 2 is a schematic diagram of the VME slave interface and interrupter of PCI unit 3 of the Fig. 1 embodiment.
  • Figure 3 is a schematic diagram of the random access memory components of PCI unit 3 of the Fig. 1 embodiment.
  • Figure 4 is a schematic diagram of the port processor and digital signal processor components of PCI unit 3 of the Fig. 1 embodiment.
  • Figure 5 is a schematic diagram of the CODEC, DTMF transceiver, and telephone line interface components of PCI unit 3 of the Fig. 1 embodiment.
  • Figure 6 is a schematic diagram of a first portion of CPU 1 of the Fig. 1 embodiment.
  • Figure 7 is a schematic diagram of the remaining portion of CPU 1 of the Fig. 1 embodiment.
  • Figure 8 is a flow chart of a preferred embodiment of the manner in which the inventive system processes an incoming telephone call.
  • Figure 9 is a flow chart of a preferred embodiment of an inventive method for automated monitoring of the progress of a telephone call.
  • Figure 10 is a flow chart of a preferred embodiment of a portion of the Figure 9 method.
  • Figure 11 is a flow chart of a preferred embodiment of a portion of the Figure 10 method.
  • Figure 12 is a flow chart of a preferred embodiment of a portion of the Figure 11 method.
  • Figure 13 is a flow chart of a preferred embodiment of a portion of the Figure 9 method.
  • Figure 14 is a flow chart of a preferred embodiment of an inventive method for automated call transfering.
  • FIG. 1 is a block diagram of a preferred embodiment of the invention.
  • Central processing unit CPU
  • PCI unit 3 and memory unit 5 each interface with bus 7.
  • bus 7 is a conventional VME bus and memory unit 5 is selected from those commercially available which are campatible with the selected embodiment of bus 7.
  • memory unit 5 is selected from those commercially available which are campatible with the selected embodiment of bus 7.
  • the inventive system may include more than one identical PCI units, each connected in the same manner to bus 7 as is unit 3 in Figure 1.
  • Each PCI unit 3 includes an interface circuit 114 for receiving signals from, and transmitting signals to, telephone line 115.
  • Interface circuit 114 includes a CODEC for digitizing incoming voice signals, a telephone line interface, and a DTMF detector for receiving incoming DTMF signals.
  • Each PCI unit 3 also includes a digital signal processor 110, which performs speech compression and reconstruction; a port processor 106 (preferably a 2MHz Motorola 6809 integrated circuit), which performs all port processing operations other than speech compression and reconstruction, including data transfers, telephone line interface operations, and call progress detection operations; a random access memory (“RAM") unit 112; a RAM arbiter 108; a VME bus slave interface unit 102; a VME bus interrupter unit 104; and a backplane interface logic unit 100 for interfacing between VME bus 7 and units 102 and 104.
  • a digital signal processor 110 which performs speech compression and reconstruction
  • a port processor 106 preferably a 2MHz Motorola 6809 integrated circuit
  • RAM random access memory
  • RAM random access memory
  • RAM arbiter 108 a RAM arbiter 108
  • VME bus slave interface unit 102 a VME bus interrupter unit 104
  • backplane interface logic unit 100 for interfacing between VME bus 7 and units 102 and 104.
  • each PCI unit 3 also includes a second interface circuit 214 for transferring signals to and from telephone line 215, a second port processor 206, a second digital signal processor 210, an second RAM unit 212, and a second RAM arbiter 208.
  • Each of units 206, 208, 210, 212, and 214 is identical to the corresponding one of units 106, 108, 110, 112, and 114, and units 206, 208, 210, 212, and 214 are connected to each other and to units 102 and 104 in the same manner as are corresponding units 106, 108, 110, 112, and 114.
  • CPU 1 performs all system processing for the inventive voice processing system.
  • CPU 1 includes a microprocessor 35 (which is preferably a Motorola MC68010 integrated circuit), a memory management unit 31 (which is preferably a Motorola MC68451 integrated circuit), and logic for supporting system input/output and VME bus supervisory functions.
  • the circuitry supporting the VME bus supervisory functions includes system clock driver 15, bus arbiter 17, IACK daisy chain driver 19, and bus timer 21.
  • Each PCI unit 3 must be compatible with bus 7.
  • bus 7 is a conventional VME bus
  • unit 102 is a VME bus slave interface unit which appears to bus 7 as a slave with 16 bit and 8 bit data transfer capability, block transfer capability, and 24 bit addressing capability. A preferred embodiment of unit 102 will be discussed below with reference to Figure 2.
  • Port processor 106 (or port processor 206) of PCI unit 3 may interrupt system processor 35 of CPU 1 via VME bus interrupter unit 104.
  • a preferred embodiment of unit 104 will be described below with reference to Figure 2.
  • Interface logic unit 100 comprises conventional VME backplane interface circuitry for connecting units 102 and 104 with VME bus 7.
  • FIG. 2 is a schematic diagram of a preferred embodiment of VME bus slave interface unit 102 (comprising programmable logic devices U16, U21, and U35, and integrated circuit U73), VME bus interrupter unit 104 (comprising programmable logic devices U42 and U49, and registers U3 and U4), and interface logic unit 100 (comprising buffer circuits U17, U28, U29, U6, U11, U43, U50, and U78).
  • the circuits comprising interface logic unit 100 are connected between VME bus 7 and units 102 and 104.
  • Programmable logic devices U21 and U35 of slave unit 102 decode the buffered VME bus address signals (VA01-VA23) and address modifier signals (AM0-AM5) .
  • Device U35 compares signals VA01-VA23 with the slot identification signals SID0-SID3 received from VME bus 7 for identifying the slot in which the PCI unit 3 is installed (typically, a number of PCI units 3 will be installed in different slots on a motherboard connecting all components of the system of the invention). If the address signals match the slot identification number, the VALIDID line goes high.
  • Device 35 also decodes the address modifiers AM0-AM5, and causes line VALIDAM* to go low, for example, if any of the address modifiers indicates a standard non- privileged data, program, or block transfer access, or a supervisory data, program, or block transfer access.
  • Device U21 decodes address signals VA21-23 and VA14-16. If the address falls within the PCI address space, and VIACK is low and VALIDID is high, the PCI is selected. If the PCI is selected with an invalid address modifier (i.e., VALIDID is low), BADXFER* will go low, indicating that an illegal transfer is being attempted. This will cause the "DTACK and BERR generator" (circuit U16) to generate a VME bus error signal.
  • Device U21 also generates the following signals: AVRAMSEL* (for selecting RAM unit 112) , BVRAMSEL* (for selecting RAM unit 212), CLATCHSEL* (which is active when the VME bus master, CPU 1, selects port control latch circuit U79) , and LATCHRD* (the VME interrupt vector register select signal, which is active when the VME bus master addresses the VME bus interrupt vector register of circuit 104) .
  • AVRAMSEL* for selecting RAM unit 112
  • BVRAMSEL* for selecting RAM unit 212
  • CLATCHSEL* which is active when the VME bus master, CPU 1, selects port control latch circuit U79
  • LATCHRD* the VME interrupt vector register select signal
  • Table 1 specifies the logical relationships between the input and output signals of device U21
  • Table 2 specifies the logical relationships between the input and output signals of device U35.
  • the symbol "! represents “inverse” (so that signal !A is the inverse of signal A)
  • the symbol "&” represents “and”
  • the symbol "#” represents "or”.
  • VA15 & VA14 & !VIACK & VLWORD & VAS & !VALIDAM; ! BVRAMSEL VA23 & VA22 & !VA21 & VALIDID & VA16 &
  • VA15 & VA14 & !VIACK & VLWORD & VAS & !VALIDAM; ! BADXFER (VA23 & VA22 & !VA21 & VALIDID & VAS &
  • VRAMSEL VA23 & VA22 & !VA21 & VALIDID & VA15 & VA14 & !VIACK & VLWORD & VAS & !VALIDAM
  • !LATCHRD VA23 & VA22 & !VA21 & VALIDID & !VA15 & VA14 & !VIACK & VLWORD & VAS & !VALIDAM & VDSO & !VWRITE;
  • !VALIDID ((((((((VA20 & !SID3
  • VALIDAM ! (AMO & AM3 & AM4 & AM5 # AM1 & AM3 & AM4 & AM5)
  • VME bus 7 is asynchronous, so that all transfers require a handshaking between the VME bus master (CPU 1) and each VME bus slave (each of PCI units 3).
  • the handshaking signals employed in a data transfer are: AS* (address strobe), DS0* and DS1* (data strobe signals), DTACK* (a data transfer acknowledgement signal, the inverse of DTACK), and BERR* (a bus error signal).
  • Device U16 of PCI unit 3 generates the following signals: DTACK (which occurs when VDTACK is active, or when the control latch is selected, or during an interrupt acknowledge, and remains active until both VDS0 and VDS1 are inactive); BERR (the inverse of BERR*, which has the same timing as DTACK, and which becomes active when an illegal access is attempted, as described above); LATCHCK and DLCLK (state variables of a simple state machine.
  • DLCLK goes low for one clock cycle when the control latch is accessed, and LATCHCK goes low during the next clock cycle);
  • VDBEN an asynchronous signal which goes active whenever any component of the PCI is accessed and remains low until both VDS0 and VDSl are high);
  • VALD and VACLK state variable signals of an asynchronous state machine.
  • VACLK clocks the VME bus address into the address counters when VALD is low, or increments the counters when VALD is high).
  • Table 3 is the state transition table for signals VALD and VACLK:
  • Each entry in Table 3 represents the next state of the asynchronous state machine given the current inputs and the current outputs.
  • a state is "stable” if the next state is identical to that state.
  • the address counters will load whenever
  • VAS goes active, and will increment on every odd byte access as long as VAS remains active.
  • Table 4 specifies the logical relationships between the input and output signals of device U16: Table 4
  • System processor 35 of CPU may control operation of PCI 3 via port control latch U79.
  • Device U79 is preferably a Texas Instruments Inc. 74LS259B addressable latch. When signal CLATCHSEL*, emerging from device U79 goes low, signal VDOO is latched at the output addressed by the three select input signals VA16, VA01, and VA02 (of which VA16 is the most significant select input).
  • VA16 separates the eight possible inputs into two groups of four, addressed 64K bytes apart. Each of these two groups controls one of ports A and B.
  • the control outputs of device U79 are: AOFFH (BOFFH), which is supplied to device U89 of the port A interface 114 shown in Figure 5 (or the corresponding circuit of port B interface 214), for forcing the signalling relays of interface 114 (214) to an "off hook" condition when high, provided that signal A6809 (B6809) is low; A6809 (B6809), which gives port processor 106 (206) control over the signalling relays of interface 114 (214) when high; AMRST (BMRST), which resets port processor 106 (206) when low; and AMINT (BMINT), which generates an interrupt to port processor 106 (206) when pulsed.
  • AOFFH BOFFH
  • A6809 which gives port processor 106 (206) control over the signalling relays of interface 114 (214) when high
  • AMRST BMRST
  • AMINT BMINT
  • PCI unit 3 may interrupt system processor 35 of CPU 1, by sending interrupt request signals from interrupt unit 104 on VME bus 7.
  • Unit 104 comprises programmable logic devices U42 and U49 (for timing and control), and registers U3 and U4 (for providing the interrupt vectors). Registers U3 and U4 are preferably Texas Instruments Inc. 74LS374 integrated circuits.
  • Interrupt unit 104 is a "release on acknowledge” (ROAK) interrupter in the sense that it will release its interrupt request only when the interrupt has been acknowledged.
  • ROAK release on acknowledge
  • each PCI unit 3 includes: generating an interrupt request on line IRQ, providing an interrupt vector on lines D00-D07 when the interrupt request is being acknowledged, releasing its interrupt request during the acknowledge cycle, passing the IACKIN signal (the incoming interrupt acknowledge daisy chain signal) to the next PCI unit 3 (typically mounted in the next slot on a motherboard) if no interrupt is pending, or if the interrupt being acknowledged is at a different level, and providing the DTACK* signal to end the interrupt acknowledge cycle.
  • interrupt unit 104 will treat ports A and B (hence port processors 106 and 206) as separate "level 3" interrupters, with port A having priority.
  • Devices U42 and U49 implement timing and control for interrupter 104.
  • Device U49 generates the following four combinatorial outputs from the input signals received from port processors 106 and 206: LOADA (LOADB), whose rising edge will load data from the port A (port B) data bus into interrupt vector register U4 (U3); and SETA* (SETB*), which, if low, will set an interrupt request for port A (port B).
  • LOADA LOADB
  • SETA* SETB*
  • Signals Q2A and Q2B (represented by terminals 18 and 20 of device 49, respectively, but used internally only within device 49) will go low during an interrupt acknowledge cycle, but not when system processor 35 is reading the contents of the interrupt register (U3 or U4) during testing. At that time, RSTA* (RSTB*) will go low for two clock cycles, resetting the interrupt request. This ensures that the interrupt request remains valid for the entire interrupt acknowledge cycle, but that an interrupt request is not reset by reading the interrupt vector register under software control.
  • Table 6 specifies the logical relationships between the input and output signals of device U49: Table 6 Original Equations:
  • Device U42 generates the following signals: INTACK*, which goes low when either of interrupt vector registers U3 and U4 is enabled, which will occur during an interrupt acknowledge cycle or when the registers are read by system processor 35 for testing purposes; IRQ, which is inverted and then supplied as the interrupt request to the VME bus 7 (signal IRQ is high whenever an interrupt request is pending from either port A or port B); IACKOUT*, the VME bus interrupt acknowledge signal which is output to the next slot in the IACK daisy chain (signal IACKOUT* will go low if VIACKIN is high, and either the current interrupt acknowledge cycle is for an interrupt level other than three, or there is no interrupt request from either port, which latter condition is indicated by DNOIRQ* going low); ENA* and ENB*, which enable their respective interrupt registers, U4 and U3, onto the internal data bus within PCI 3; IRQA* and
  • IRQA (SETA & IRQA # !RSTA)
  • IRQB (SETB & IRQB # !RSTB)
  • DNOIRQ ((VAS & !DNOIRQ # IRQA & IRQB) # VAS &
  • RAM unit 112 may be addressed by either port processor 106 or by CPU 1, with arbitration transparent to both.
  • RAM unit 212 may be addressed by either port processor 206 or by CPU 1, with arbitration transparent to both.
  • FIG 3 is a schematic diagram of the elements shown as blocks 108, 112, 208, and 212 in Figure 1.
  • Each of RAM units 112 and 212 is a shared RAM unit in the sense that both CPU 1 (via VME bus 7) and one of the port processors (unit 106 or 206) may access each of RAM units 112 and 112.
  • RAM unit 112 includes 16K bytes of shared RAM (provided by 8K x 8 static RAM unit U61 and 8K x 8 static RAM unit U63) .
  • RAM unit 212 includes 16K bytes of shared RAM (provided by 8K x 8 static RAM unit U33 and 8K x 8 static RAM unit U47).
  • VME bus address and the port processor address for RAM unit 112 are multiplexed by data selector/multiplexer circuits U62, U68, U74, and U55, each of which is preferably a Texas Instruments Inc.
  • VME bus address and the port processor address for RAM unit 212 are multiplexed by data selector/multiplexer circuits U34, U41, U48, and U55, each of which is preferably a Texas Instruments Inc. 74LS157 integrated circuit.
  • the VME bus 7 interfaces with the "Port A” RAM unit (comprising devices U61 and U73) via bidirectional octal buffers U9 and U15 and octal registers U5 and U10, and with the "Port B" RAM (comprising devices U33 and U47) via bidirectional octal buffers U8 and U14 and octal registers U5 and U10. Control signals for the interfaces are supplied by the timing and control logic described below.
  • Port processor 106 interfaces with "Port A” RAM unit 112 (comprising devices U61 and U73) via bidirectional octal buffers U20 and U27, and port processor 206 interfaces with "Port B” RAM 212 (comprising devices U33 and U47) via bidirectional octal buffers U19 and U26. All accesses by the port processors are byte wide synchronous accesses, to be described below.
  • Buffers U8, U9, U14, U15, U19, U20, U26, and U27 are preferably Texas Instruments Inc. 74LS245 integrated circuits, and registers U5 and U10 are preferably Texas Instruments Inc. 74LS374 integrated circuits.
  • Programmable logic devices U36, U56, and U57 generate timing and control signals for accessing the RAMs, and "E" and "Q” clock signals for port processors 106 and 206.
  • Identical devices U56 and U57 serve as memory control line decoders, with device U56 associated with "Port A” RAM 112 and device U57 associated with "Port B” RAM 212.
  • Device U36 implements a state machine which runs off the 16KHZ VME system clock ("VSYSCLK"). The state variables and state machine operation are described in Table 9:
  • the state variables have the following functions:
  • Signal E* is the inverse of the E clock required by port processors 106 and 206, and signal E* is employed fay devices U56 and U57 to generate the RAM control signals and to multiplex the addresses from port processors 106 and 206 and VME bus 7;
  • Signal Q is the Q clock required by port processors 106 and 206;
  • Signal SO is employed (with signals E* and Q) to generate the system clocks in a manner to be discussed below, and is also employed as a clock signal for the CODEC control logic (which comprises programmable logic devices U82 and U83) ;
  • Signals SI and S2 become active during a memory access, and signal S2 is also used by the memory control line decoders U56 and U57 to generate RAM control signals and to clock RAM data into the VME data registers;
  • Signal VDTACK* becomes active immediately following a RAM access to inform the "DTACK" (data transfer acknowledge) signal generator described above that the data transfer is complete;
  • Signal VRESET is a buffered VME bus reset signal;
  • Signal VRAMSEL* (which denotes either signal
  • AVRAMSEL* or signal BVRAMSEL* is active whenever CPU 1 addresses RAM 112 or 212, and is employed to initiate a load of the address counters and to enable the VME bus data buffers; and
  • Signal VDS denotes either signal VDSl (VME data strobe “1") or signal VDSO (VME data strobe "0").
  • Rows 2 through 8 E*, Q, and SO form a "divide by eight" Gray code counter, and E* and Q provide the overlapping 2MHz clocks required by port processors 106 and 206;
  • Rows 9 and 10 state machine U36 checks for a request for a RAM access from VME bus 7. If no request is pending, signals S1 and S2 remain inactive, so that any access by the VME master is deferred until the RAM is unused by the relevant port processor;
  • Rows 11 through 14 if a VME access is requested, S1 will go low for four cycles and S2 will go low for two cycles;
  • VDTACK* will remain low until VDS is inactive.
  • State machine U36 also generates control signals AREN* and BREN*, which enable data buffers U8, U9, U14, and U15 between RAM units U61, U73, U33, and U47 and the VME bus. Signals AREN* and BREN* will go low during a RAM access for two clock cycles during a read operation (coincident with S2) , or three cycles during a write operation. Table 10 specifies the logical relationships between the input and output signals of device U36:
  • Control signals include the following:
  • ARDIR and BRDIR which determine the direction of transfer, with a low level indicating a write and a high level indicating a read (Each of these signals is determined either by the write line of the port processor ("AMRW” or “BMRW”) or the VME bus write signal "VWRITE”) . Which source is used depends on the state of signal E*. When signal E* is low, the port processor has access to the RAM, and AMRW (or BMRW) determines the direction. On alternate cycles, VWRITE determines the direction);
  • VLEN* which enables the VME data latches U5 and U10, and is active following a read by the VME bus master;
  • AENML*, AENMH*, BENML*, and BENMH* which enable data buffers U20, U27, U19, and U26, respectively, between the RAMs and the port processors, with AENML* (BENML*) enabling the low byte when RAM is selected by the port processor, E* is low, and AMAO (BMAO) is low, and AENMH* (BENMH*) enabling the high byte when AMAO (BMAO) is high;
  • AROE* which is the output enable for the RAM, and is gated by E*, just as is ARDIR (BRDIR) , but has opposite sense;
  • ARWRL* and ARWRH* (BRWRL* and BRWRH*) , which enable the operation of writing one byte of data to RAM 112 (212).
  • a port processor write operation (when E is low, and MRW is low) , a two cycle write pulse is generated for either the high byte or low byte, depending on AMAO (BMAO) .
  • AMAO AMAO
  • VME write operation either the high or the low byte, or both, may be written, depending on the state of VDSl and VDSO.
  • Table 11 specifies the logical relationships between the input and output signals of both device U56 and identical device U57:
  • a RAM access by one of the port processors is straightforward. During the half cycle of E* in which the port processor has access, one port data buffer
  • U20, U27, U19, or U26 is enabled, and one byte, even or odd, is either written or read, depending on the states of AMAO (BMAO) and AMRW (BMRW) .
  • the port processor is never delayed in accessing the RAM.
  • the VME bus master (CPU 1) may be delayed for as much as one cycle of E* while accessing one of the RAMs.
  • the RAM data is enabled onto lines VD00- VD15 and latched by units U5 and U10. After the data is latched, U8 and U14 are disabled, U5 and U10 are enabled, and VDTACK* goes low, signalling that data is available to the VME bus.
  • the data is simply written to the RAM in the same manner as during a port processor write. Data is latched during a read operation because the VME bus is asynchronous, so that data must be held until the VME bus master (CPU 1) signals that the data is no longer needed.
  • FIG 4 is a schematic diagram of port processor 106 and digital signal processor 110 of Figure 1. Because processors 106 and 110 are identical to processors 206 and 210, respectively, and are interconnected with interface 114, RAM unit 112, RAM arbiter 108, slave unit 102, and interrupter unit 104 in the same manner as processors 206 and 210 are interconnected with interface 214, RAM unit 212, RAM arbiter 208, slave unit 102, and interrupter unit 104, no separate diagram of processors 206 and 210 is provided.
  • Port processor 106 includes processor U87 (which preferably is a 2MHz Motorola 6809 integrated circuit) for performing all port processing operations other than speech compression and reconstruction, including data transfers, telephone line interface operations, and call progress detection operations. Processor has access to the resources described below with reference to devices U72, U77, and U85 of Fig. 4.
  • the port processor address (AMA4-AMA15) is decoded by programmable logic device U72 (which is preferably a PAL12L10 integrated circuit).
  • VIA U77 is preferably a Rockwell International A6522A integrated circuit, which performs timing and interrupt functions as well as I/O for the telephone line interface unit 114 (to be discussed below with reference to Figure 5). VIA U77 also functions as the central component of the interrupt structure of port processor 106.
  • Input signals AMINT and ATINT to VIA U77 are, respectively, the interrupt signals from digital signal processor 110 and the VME bus master (CPU 1). The active edge of these interrupts may be programmed by device U87. When either of these interrupts occurs, the AMIRQA output signal of VIA U77 becomes active.
  • the CODEC timing (to be discussed below with reference to Fig. 5) also asserts a fast interrupt once every 125 microseconds on input line AFIRQ* to device U87, indicating that the CODEC requires service.
  • ASD0 Port A
  • Port B Port B
  • Slot ID numbers 0 through 3 identifying the slot into which the PCI unit 3 is installed
  • phone interface switch bits ASW1 through AS3 representing the state of the three telephone interface switches S1-S3 shown in Figure 5 (these bits are compared with the requirements of the software installed in U87).
  • Digital signal processor 110 includes processor U1 (sometimes referred to as "DSP" U1), which preferably is a TMS32010 integrated circuit.
  • U1 accepts data from port processor U87 via a buffer to be described below.
  • the DSP address (ATA0, ATA1, ATA7, ATA8, ATA9,
  • ATA10 ATA10
  • ATA11 programmable logic device U13 (which preferably is a PAL 16L8 integrated circuit).
  • Signal ATBUFSEL* is active when DSP U1 addresses the DSP buffer
  • signal ATINT is the port processor interrupt (DSP U1 may interrupt port processor U87 by asserting this line, and DSP U1 may set and reset signal ATINT)
  • signal ATRAMSEL* is active when DSP U1 addresses its program RAM units (U54 and U67)
  • signal ATROMSEL* is active when DSP 1 addresses its boot ROM units (U7 and U67).
  • DSP U1 has access to RAM units TJ54 and U67, each. RAM unit having capacity to store 8K eight-bit words.
  • DSP U1 has a memory address space with only 4K capacity. Accordingly, DSP U1 has access to two banks of RAM, which are selectable by port processor U87. Programs are loaded into RAM units U54 and U67 by DSP U1 under the control of port processor U87.
  • DSP U1 also has access to ROM units U2 and U7, each of which is preferably a PROM with capacity to store 512 eight-bit words.
  • ROM units U2 and U7 preferably contain boot code to test DSP subsystem 110, to download code from port processor U87 and upload code to port processor U87, and to execute code in program RAM.
  • Port processor U87 communicates with DSP U1 through a 256 byte data buffer, comprising 2K x eight-byte RAM unit U80, programmable logic unit U39, an eight-bit counter including devices U75 and U81, data buffers U46 and U66, and data register U53.
  • Unit U39 provides timing and control for unit U80 and all control signals for the data buffer between port processor U87 and DSP U1, and is addressed as a single location in the address space of both processors U87 and U1.
  • the address for buffer RAM U80 is provided by an eight bit counter, preferably comprising two synchronous four-bit counters U75 and U81 (which may be Texas Instruments Inc. SN74S163 integrated circuits) connected as shown in
  • the buffer comprising devices U80, TJ39, U75, U81, U46, U66, and U53 provides a purely simplex communications path between processors U87 and U1. Only one of processors U87 and U1 may access the buffer at a time. Typically, one processor will fill the buffer, signal the other processor, and then wait for a signal before accessing the buffer again.
  • Circuit U39 generates the following signals: ACNTLD*, the load signal to the buffer address counters U75 and U81 (processor U87 may load an address into the counters by writing to the buffer address space with AMA2 high); ACNTCLK, the clock signal to address counters U75 and U81 (A rising edge will occur at the end of every access by either processor U87 or U1, incrementing the counter.
  • the counter will also be clocked during a load operation); ATBRD*, when low, will enable data buffer U46 to DSP U1; ATBWR*, when low, will enable register U53 during a DSP write to the buffer (the buffer is loaded from the data bus connecting DSP U1 with U46 and U53, on every rising edge of signal ATCLK); AMBEN*, which enables data buffer U66 to port processor U87 (the direction of this buffer is controlled by signal AMRW) ; ARAMWR*, the write signal to RAM U80 (which is active whenever processor U87 or U1 writes to RAM U80) ; and ARAMEN*, which enables RAM U80 outputs, and will be active whenever DSP U1 or port processor U87 reads from RAM U80.
  • Device U39 is designed to maintain a strict precedence relation among several pairs of signals, in order to guarantee hold times when required. In the following pairs of signals, a rising edge on the first will always precede a rising edge on the second: ARAMWR*, ATBWR*; ATBWR*, ACNTCLK; ARAMWR*, AMBEN*; AMBEN*, ACNTCLK; and ACNTCLK, ACNTLD*.
  • Figure 5 is a schematic diagram of interface unit 114 of PCI unit 3.
  • Unit 214 is identical to unit 114, and is interconnected with units 206, 208, 210, 212, 102, and 104 in the same manner as unit 114 is interconnected with units 106, 108, 110, 112, 102, and 104. Accordingly, a separate diagram of unit 214 would duplicate Figure 5, and is not provided.
  • Interface unit 114 includes CODEC U104, which preferably is a Model TP3051 parallel access mu-Law CODEC (available from National Semiconductor) capable of digitizing incoming analog signals at the rate of 8000 eight-bit samples per second. All timing and control for interface unit 114 is generated by counter U82 and programmable logic device U83 (shown in Figure 3). In the Fig. 3 embodiment, the control signals output by device U83 not only serve to control CODEC U104 of interface 114, but the corresponding identical CODEC of interface 214.
  • Counter U82 is preferably a Texas Instruments Inc. SN74393 integrated circuit, and device U83 is preferably a PAL16R6 integrated circuit.
  • the output signals generated by device U83 are: CDCLK and S2, two state variables output by a "divide by four" counter (the clock for device U83 has frequency 4MHz, so that signals CDCLK and S2 have frequency 1MHz), with signal CDCLK used by CODEC U104 to drive its switched capacitor filters, and by device U82 to create a 125 microsecond sampling period; CDXFER*, which indicates to CODEC 104 that a read or write transfer is about to take place (two pulses of signal CDXFER* occur every 125 microsecond); LATCHOUT, which clocks data from CODEC 104 into register U95 (shown in Figure 5) once every 125 microsecond during the data transfer process; LATCHIN*, which enables data from register U91 (shown in Fig.
  • Table 16 specifies the logical relationships between the input and output signals of device U83:
  • Port processor U87 writes to CODEC 104 by loading CODEC input register U91 with PCM or control data following the 8KHz interrupt (signal FIRQ). At the next 8KHz interrupt, this data is then loaded into CODEC 104. At the same time, data may be transferred from CODEC output buffer U95. Data in buffer U95 may be read at any time by port processor U87.
  • the analog input stage of CODEC 104 (in its Model TP3051 embodiment) is configured as an inverting amplifier.
  • Inputs VFXI+ and VFXI- are the non-inverting and inverting inputs, respectively, to an op-amp within of CODEC 104.
  • Signal GSX is the feedback output of the op-amp.
  • the analog output from CODEC 104 is signal VFRO. This output is capable of driving a 600 ohm load to (+/-)2.5 V.
  • Line VFRO is capacitively coupled to hybrid circuit 200 (to be discussed below) via a 0.1 microfarad capacitor C94.
  • Hybrid circuit 200 includes two op-amps U103 and passive components as shown in Fig. 5. The purpose of circuit 200 is to merge the transmitted signal from CODEC U104 onto the two wire telephone pair and to extract the received signal (to be forwarded to CODEC U104) from the two wire telephone pair. In order to approximately match the full range of typical telephone line impedances, hybrid circuit 200 shown in Fig. 5 is designed to offer greater than 20dB of transhybrid loss over the spectrum of typical telephone lines.
  • Received signals from the telephone interface are present at the secondary of isolation telephone interface transformer T1.
  • the transmitted voice signal from CODEC U104 is fed to a gain stage comprising the upper op-amp U103 in Fig. 4, resistor R85, capacitor
  • the received signal at the secondary of transformer T1 is fed to the gain stage comprising the lower op-amp 103 in Fig. 5, resistors R78 and R79, capacitor C86, and resistor R82.
  • Received voice signals are transmitted through capacitor C91 to CODEC U104, and received DTMF signals are transmitted through capacitor C78 to DTMF detection device U102 to be discussed below.
  • Interface 114 is capable of interfacing with Loop, Reverse Loop, and E&M telephone lines.
  • the following components of interface 114 should be selected from those commercially available which meet such dielectric strength standard: transformer T1, optoisolators U107, U100, U106, U105, U02 , U96, and U108, relays K3 and K4, and switches S1, S2, and S3.
  • V130LA5 Metal Oxide Varistors RV3 and RV4 are provided between ground and the Ring and Tip lines, respectively, to ensure that interface 114 meets the FCC surge and lightning protection requirements. For the same reason, V68ZA2 Metal Oxide Varistors RV1 and RV2 are provided between ground and the EAR and MOUTH lines, respectively.
  • the audio path is always connected to the Tip and Ring lines, through transformer T1 and capacitor C100.
  • the DC path can be switched between Tip/Ring and Ear/Mouth by means of switch S3.
  • Relays K3 and K4 can be operated independently to control On-Hook and Off-Hook conditions.
  • the termination block comprises switches S1 and S2, termination impedances, and battery, ground, and current sensors. Each current sensor includes an optoisolator.
  • Capacitor C102 and resistor R90 are connected in series with optoisolator U108.
  • transformer T1 in series with capacitor C100.
  • Resistor R90 and capacitor C102 provided a desired amount of current through optoisolator U108 during ringing.
  • the current through U108 is converted to a voltage for ring signal detection.
  • resistor R93 pulls terminal 5 of device U108 high.
  • U108 will begin conducting between terminals 4 and 5. Since pin 4 of U108 is grounded, the voltage at terminal 5 of U108 is pulled low.
  • pin 5 of buffer U93 (line ARI) goes low.
  • the signal on line ARI is supplied to VIA U77 (shown in Figure 4).
  • PCI unit 3 is designed to meet the requirements of the Loop Start, Ground Start, DID, and E&M telephone signalling standards, and may be connected to either end of a telephone line (the station or office end).
  • Switches S1, S2, and S3 are controllable to provide the necessary hardware interface for any of the configurations mentioned in the preceding sentence, as shown in Table 17:
  • Octal port U85 receives switch status signals ASW1-ASW3 from switches S1, S2, and S3, respectively.
  • Signalling relays K3 and K4 are driven by transistor drivers Q4 and Q3, respectively. Relays K3 and K4 are controlled by programmable logic device U89. During normal operation, signal A6809 is high, giving control of the relays to port processor U87 via signals ARLY1 and ARLY2. When signal A6809 is low, control of the relays is given to the VME bus master (CPU 1). The VME bus master may set the relays to a desired state determined by the state of signal AOFFH and the state of switches SI, S2, and S3.
  • Table 19 specifies the logical relationships between the input and output signals of device U89: Table 19
  • the loop current through the telephone line must be accurately determined to facilitate distant end Off-hook detection. This detection operation must occur over a range of central office (CO) battery voltages and a range of loop resistances.
  • the loop current is monitored by VIA U77 (shown in Figure 4), by monitoring the state of signals AFLOOP and ARLOOP, which are sent from optocouplers U105 and U106 to VIA U77.
  • Interface unit 114 of PCI unit 3 includes a dedicated dual tone multi-frequency (DTMF) detector, comprising a bandsplit filter U102 (preferably an AMI 3525 bandsplit filter) for separating the two tone groups used for DTMF signalling, and a DTMF decoder U101 (preferably a Mostek 5103 DTMF decoder).
  • Crystal clock Y3 supplies a 3.58 MHz clock signal to oscillator terminals 16 and 17 of U102, for internal use within U102 and for generating the CKOUT clock signal which emerges form terminal 18 of U102.
  • a counterpart to clock Y3 need not be included in such second port.
  • signal CKOUT may be supplied to the oscillator terminals of such second port's counterpart to device U102.
  • DTMF decoder U101 generates an interrupt to port processor U87 whenever a valid DTMF digit is detected, and this interrupt is transmitted to device U87 on line ADTMF.
  • Port processor U87 may read the output data by addressing output buffer U65 (which preferably is a Texas Instruments SN74S299 register). It is possible to connect the audio path from one port to the other using audio loopback relay K5 and the associated passive circuitry (shown in Figure 3) .
  • Relay K5 is preferably a DPST relay connecting both audio paths to the passive network comprising transistor Q5, which provides about 30 dB attenuation from one port to the other.
  • Relay K5 may be controlled by port processor U87.
  • FIGS 2-5 include references to "Sheets 1-6".
  • Sheet 1 corresponds to Figure 2
  • sheet 2 corresponds to Figure 3
  • sheet 4 corresponds to a counterpart to Figure 4 (which counterpart would be identical to Figure 4 except that it would show port processor 206 and DSP 210 of Port B, rather than port processor 106 and DSP 110 of Port A)
  • sheet 5 corresponds to Figure 5
  • sheet 6 corresponds to a counterpart to Figure 5 (which counterpart would be identical to Figure 5 except that it would show interface 214 of Port B, rather than identical interface 114 Port A).
  • a preferred embodiment of CPU 1 will next be described with reference to Figures 6 and 7.
  • CPU 1 performs all system processing for the inventive voice processing system.
  • CPU 1 appears to VME bus 7 as a master with 16 bit and 8 bit data transfer capability and 24 bit addressing capability.
  • the circuitry supporting the VME bus supervisory functions includes system clock driver 15, bus arbiter 17, IACK daisy chain driver 19, and bus timer 21.
  • Address decoding is implemented with to programmable logic devices U107 and U300.
  • Device 107 generates the following signals: VM*, which is active when accessing a device on VME bus 7; SHORT*, which is active when addressing the short address space of VME bus 7 this signal is used to change the VME address modifier to indicate that the current access uses only
  • ROM* which is active when accessing ROM units U302 and U502
  • MMU* which is the chip select for memory management unit 31
  • DuART which is the chip select for DUART U207
  • PARA which is the chip select for parallel interface and timer unit U206
  • SCSI* which is the chip select for the SCSI subsystem
  • UART* which is active when accessing any of several devices configured as "VPA" devices, including the modem, the real time clock, the floppy disk subsystem reset, and the VME bus release.
  • Table 20 specifies the logical relationships between the input and output signals of device U107:
  • PA22 & PA23 & ! PAS PA22 & PA23 & ! PAS
  • Device U300 generates device select signals for all the eight bit peripherals ("VPA" devices) which are accessed in the same manner as 6800 peripherals (i.e., synchronous with the E clock) .
  • VPA peripherals
  • Each such acces cycle is initiated when VPA* is asserted to system processor U201 (which is preferably a Motorola MC68010 integrated circuit) in response to a valid address.
  • system processor U201 which is preferably a Motorola MC68010 integrated circuit
  • Processor U201 will then assert signal VMA in response.
  • Each transfer to or from the peripheral must be synchronous with clock E.
  • Device U300 generates the following device select signals: MODEM*, which is the chip select for modem controller U303; RTC*, which is the chip select for real time clock U604; MRST*, which is the reset for the floppy disk subsystem controller (this is one output of a latch which preferably may be set or reset under software control); and MRLS*, which releases VME bus 7 under software control (this is also an output of a latch which preferably may be set or reset under software control.
  • Table 21 specifies the logidal relationships between the input and output signals of device U107 :
  • MRST ! ( ! ( 1UART & !A6 & A7 & A1) & NMRST & RST) ;
  • NMRST ! ( ! ( !UART & !A6 & A7 & !A1) & MRST # !RST) ;
  • MRIS ! ( ! ( 1UART & A6 & A7 & Al) & NMRIS & RST) ;
  • NMRIS ! ( ! ( !UART & A6 & A7 & !A1) & MRIS # !RST) ;
  • Control signals are generated by programmable logic device U301 and logic devices 201, 202, and 203.
  • Device U301 generates the following signals: VME*, which is active whenever a VME bus access is requested by system processor U201 or when a VME bus interrupt request is being acknowledged; PAS*, which is a physical access strobe signal, and is active when address strobe AS* from processor U201 and address strobe MAS* from memory management unit U202 (which is preferably a Motorola MC68451 integrated circuit) are both active; DSI, which is active when either the upper or the lower data strobe is active; RIN, which is used to qualify the data strobes to create the physical data strobes, and is active when RW* is low (indicating a write cycle) and WIN* (the write inhibit from U202) is low (indicating an attempt to write to a protected segment); and b ERRST, which resets the bus error timer (the timer begins counting when a bus cycle begins, indicated by AS*,
  • Table 22 specifies the logical relationships between the input and output signals of device U301:
  • VME ! (VIACK # !VM) ;
  • Logic devices 201, 202, and 203 generate the following signals: address strobe MAS*, which is generated by open collector driver 201 coupled to line MALL emerging form U203 (when signal MAS* is driven low, device U202 is prevented from performing an address translation. This occurs during an interrupt acknowledge); ALL, which is also generated by open collector driver 201 (signal ALL is driven low during an interrupt acknowledge to prevent U202 from interpreting
  • PLDS* which is generated by circuit 202 coupled to the control bus of VME bus 7, and prevents a write to protected memory
  • PLDS* consists of data strobe LDS* qualified by signal RIN
  • PUDS* which is also generated by circuit 202
  • VPA* which is generated by circuit 203, and is a valid peripheral address signal indicating to processor U201 that the current cycle is either an access to a 6800 type peripheral, or an autovectored interrupt (in the first case, the data transfer is synchronous to clock E and requires no DTACK* in response; in the second case, processor U201 does not require an externally generated interrupt vector and instead processor U201 uses a dedicated vector for the current interrupt level).
  • VME bus 7 is asynchronous, so that all transfers require handshaking between the VME bus master (CPU 1) and a slave (each PCI unit 3).
  • the handshaking signals employed in a data transfer are: AS* (address strobe), DS0* and DS1* (data strobe signals), DTACK* (a data transfer acknowledgement signal, the inverse of DTACK), and BERR* (a bus error signal).
  • AS* address strobe
  • DS0* and DS1* data strobe signals
  • DTACK* a data transfer acknowledgement signal, the inverse of DTACK
  • BERR* a bus error signal
  • CPU 1 drives AS*, DS0*, and DS1*.
  • All bus control signals are generated by VME bus controller U103 (which preferably is a Model 68172 integrated circuit). Circuit U103 is configured for single master operation, and performs the following functions: 1.
  • VME bus 7 It requests access to VME bus 7 when processor U201 addresses the VME bus address space.
  • the onboard processor signals this by bringing VME* and MAS* low. If the bus master does not own bus 7, circuit U103 signals its request by driving BR* low.
  • the bus arbiter (U006) grants this request by driving BGIN* low. U103 then responds by driving BBSY* low and then releasing BR*.
  • CPU 1 nay then access bus 7 normally, If CPU 1 already has ownership of bus 7, bus 7 may be accessed immediately; 2. It releases bus 7 on request. If another bus master requests access to bus 7, bus arbiter U006 will issue a clear command by driving BCLR* low. This line will interrupt CPU 1, which may schedule a time to release bus 7.
  • MRLS* is driven low to signal a bus release to arbiter U006.
  • Arbiter U006 drives RELSE high, signalling U103 to release the bus.
  • U103 does so by releasing BBSY*; 3. It initiates and completes a data transfer by driving VME* and PAS* low.
  • U103 generates the VME bus data strobe (VAS*) and waits for VDTACK* or VBERR* from the VME bus slave.
  • U103 also generates the control signals for the VME bus buffers (to be described below). Responses from the VME bus are regenerated onboard by U103 as LDTACK* and LBERR*.
  • U103 In addition to controlling and monitoring the VME bus handshake signals directly, U103 generates the following control signals for the VME bus interface: DEN*, which is a data enable for enabling the VME bus buffers (this signal goes low when the VME bus is selected (i.e., VME* and PAS* are low) and DSi is high); DSEN*, which is a data strobe enable, which when low, passes the data strobes to bus 7 (this line will be active when DSI, VDTACK*, and BERR* are high, and VAS* is low); VMEEN*, which is a buffer tri-state control signal which enables the address lines and address modifiers onto the VME bus (it is low whenever CPU 1 owns bus 7); and D D IR, which is a data direction signal which determines the direction of the VME bus data buffers, as specified by signal R/W*.
  • DEN* is a data enable for enabling the VME bus buffers (this signal goes low when the VME bus is selected
  • Bus arbitration is on a fixed priority basis, with level three highest and level zero lowest. Arbitration is accomplished by two state machines implemented by programmable logic device U006: one to grant the bus in response to a bus request ; the other to release the bus in response to a request form CPU 1 to release the bus .
  • the functions of the two state machines are described in Table 23 : TABLE 23
  • State_Diagram grant_bus State IDIE if (!BBSY # !RST) then IDIE else if !BR3 then GRANT3 else if !BR2 then GRANT2 else if !ER1 then GRANT1 else if !ER0 then GRANT0 else IDIE;
  • bus 7 is under the control of a bus master, indicated by an active level on
  • CPU 1 it will continue to hold bus 7 until it releases it under software control by bringing MRLS* low. RELSE will go active, causing the VME bus interface to release the bus by bringing BBSY* high.
  • the "grant bus” state machine remains in an idle state until a bus request is received. When simultaneous requests are received, bus 7 is granted to the highest priority request. Bus 7 remains under control of the grantee until released by bringing BBSY* high.
  • BCLR* is active whenever a bus request is active, and at that time generates a level six interrupt request to CPU 1.
  • CPU 1 may respond to the bus request at any time after the request is made.
  • CPU may be configured at any of four priority levels by setting jumpers JP1, JP6, and JP7.
  • Circuit U006 also functions as the VME bus IACK daisy chain driver.
  • Signal IACKOUT* is active when an interrupt acknowledge cycle is underway, as indicated by an active IACKIN* signal.
  • IACKOUT* is qualified with DS0* and VAS*, and is delayed by the system clock SYSCLK, to meet the VME bus specification requiring a 40ns delay from the falling edge of DS0* to the falling edge of IACKOUT*.
  • Table 24 specifies the logical relationships between the input and output signals of device U006:
  • BG2OUT: ! (BBSY & BG0OUT & BG1OUT & !BG2OUT & BG3OUT & RST # BBSY & BG0OUT & BG1OUT & BG3OUT & !BR2 & BR3 & RST) ;
  • BG1OUT: ! (BBSY & BG0OUT & IBG1OUT & BG2OUT & BG3OUT & RST # BBSY & BG0OUT & BG2OUT & BG3OUT & !BR1 & BR2 & BR3 & RST) ;
  • BCXR: ! (!ER0 # !ER1 # ER2 # !ER3) .
  • CPU 1 includes system clock unit 204 , including two crystal oscillators , each implemented with two gates of
  • the frequency of oscillation is twice the required value, and D flip-flop U701 divides each oscillator ' s output frequency by two to ensure a fifty percent duty cycle.
  • the first oscillator has a 20MHz frequency, divided down to 10MHz, and serves as the system clock SYSCLK (used by circuits U201, U202, U103, U206, and U208).
  • the second oscillator has a 32MHz frequency, divided down to 16MHz, and serves as the VME bus clock, which drives all PCI units 3 coupled to bus 7. Either or both of the oscillators may be disabled (to facilitate automated testing) by driving the pulled up inputs to NAND gates U601 low.
  • Dual four-bit counters U603 and U708 (which are cascaded to form a 16-bit counter, and are preferably Texas Instruments Inc. 74LS393 integrated circuits) serve as a timer for monitoring bus activity.
  • Counters U603 and U708 are driven by the 1 MHz E clock from processor U201. If signal AS*, UDS*, or LDS* goes low, BERRST goes low, allowing the counters to start counting. The counter will continue to count until all of these signals go high. A bus error occurs if the most significant bit goes high.
  • the VME reset circuit 206 comprising timer U703 and external timing components (resistors R13 and R20, capacitors C19 and C21, and a pair of inverters U602) will cause a system-wide reset on power-up, or when the operator actuates a reset switch SW1. Following power-up, C21 will discharge, holding the trigger and threshold inputs of timer circuit U703 at ground, and forcing circuit U703*s output high. The output of U703 is inverted by one inverter U602, which holds RST* low. The entire system is reset by line RST*, via VME bus reset driver U500. C21 will discharge through R13, preferably with time constant 470 ms.
  • timer U703 When the voltage on C21 exceeds the threshold of timer U703 (typically 516 ms), timer U703 will reset, releasing RST*. Both RST* and HALT* are held low at power-up as required by processor U201 for a complete reset. The operator may halt processor U201 by actuating hal t switch SW2.
  • System processor U201 is preferably a Motorola 68010 integrated circuit
  • memory management unit U202 is preferably a Motorola 68451 integrated circuit.
  • a Motorola 68010 integrated circui ⁇ t is a 32 bit processor with a 16 bit external data hus, D0-D15, and a 24 bit address bus , A1-A23 , plus LDS* and UDS*, and may access individual bytes by asserting both UDS* and UDS* , or 16 bit words by asserting either LDS* or UDS*.
  • Lower order bytes , addressed by LDS* are at add log ical addresses
  • higher order bytes, addressed by UDS* are at even addresses .
  • Words are at even addresses .
  • Processor U201 in an embodiment in wh ich it is a Motorola 68010 integrated circuit, is an asynchronous processor, so that every memory or peripheral access (with the exception of a VPA access, (described elsewhere herein) requires a response on line DTACK* .
  • DTACK* may be generated by the addressed device (such ass U202 , U206 , DUART U207 , or the VME bus slave) , or by external circuitry (as in the case of the SCSI controller subsystem including U208 ) , or by t he RDM. The remaining devices assert VPA when addressed.
  • U201 If U201 receives a bus error, indicated by BERR* low, instead of DTACK*, U201 will enter an exception processing routine to resolve the error, in which U201 halts execution and drives HALT* low. Processor U201 must be reset to exit this state.
  • Every access by U201 includes a function code, FC0-FC2 , which defines the type of access.
  • FC0-FC2 which defines the type of access.
  • the function codes is also passed on to the VME bus in the form of an address modifier. These codes are set forth in Table 25 : TABLE 25
  • the multiple master capability of the 68010 integrated circuit (using lines BR*, BG*, and BGACK*) is not utilized in the preferred embodiment described with reference to Figs. 6 and 7. These lines are preferably unconnected or pulled to an inactive state.
  • memory management unit U202 The purpose of memory management unit U202 is to translate the logical addresses form U201 to physical addresses used by the system. This allows U201 to share code, while maintaining separate data spaces.
  • the FC3 input to U202 is not used, and is tied to ground.
  • All registers in memory management unit U202 are programmed by U201 following power-up.
  • U201 and U202 communicate via a bidirectional, dual purpose bus AD0-AD15.
  • the gating signal is HAD*, generated by U202.
  • AD0-AD15 is used as a data bus.
  • Circuit U202 supports seven prioritized interrupt levels. Interrupt requests are encoded on IPL2* through IPL0*, and INTIRQ*, by programmable logic device U009. Device U009 generates the interrupt acknoledge signals for all system interrupts. These fall into three categories: external vectored interrupts (VIACK); internal vectored interrupts (MIACK*, TIACK*, PIACK*, and DIACK*); and internal autovectored interrupts (AUTO*). Internal interrupts are indicated by INTIRQ* being active (low). Each autovectored interrupt is separately decoded. All other interrupts are assumed to be external VME bus interrupts. The priority rules are: First, higher numbered requests have higher priority; and Second, external (VME bus) requests have higher priority.
  • Table 26 specifies the logical relationships between the input and output signals of device U009: TABLE 26
  • TPL2 !(!ACEAIL # IR7
  • Interrupt acknowledge signals are generated by programmable logic device U203. Each such signal informs the interrupting source that the current cycle is an interrupt acknowledge which requires an interrupt vector on D0-D7 (except in the case of an autovectored interrupt, when U203 asserts AUTO*, which in turn asserts VPA* during the interrupt cycle, causing U201 to fetch the autovectored interrupt service routine address for that level). Signal AUTO* is latched for the duration of the interrupt acknowledge cycle, to ensure that VPA* meets its required hold time from AS*. All other interrupt acknowledge signals are locked out during an autovectored interrupt acknowledge.
  • Device U203 also generates the signal MALL, which is high during an interrupt acknowledge cycle. MALL prevents any of the device select signals from becoming active during an interrupt acknowledge, and it prevents U202 from attempting to translate the address during an interrupt acknowledge by forcing MAS* low. At the same time, signal ALL (generated in circuit 201, as described above) is forced low to prevent U202 from interpreting the failure to translate the address as a fault. Table 27 specifies the logical relationships between the input and output signals of device U203:
  • MIACK ! (A1 & !A2 & A3 & !AS & AUTO & FC0 & FC1 & FC2 & !INTIQR) ;
  • TTACK ! (!A1 & !A2 & A3 & !AS & AUTO & FC0 & PCI & PC2 & !INTIQR) ;
  • DIACK ! (!A1 & A2 & !A3 & !AS & AUTO & FC0 & FC1 & FC2 & !INTIQR) ;
  • VIACK (!AS & AUTO & FC0 & FC1 & FC2 & INTIQR) ;
  • CPU 1 includes two ROM units U302 and U502, preferably having 128K bytes total capacity.
  • units U302 and U502 are 27256 ROM units, although other types of ROM units (including 2764/27128 and 27512 ROM units) may be substituted for such 27256 ROM units by configuring jumpers JP3. Since processor U201's data bus (D0-D15) has sixteen bits, ROM U502 contains the odd bits and ROM 302 contains the even bits. All reads from ROM will enable both ROM units U302 and U502.
  • DTACK* for a ROM access is generated by two flip-flops U705 in circuit 208 (shown in Figure 6). When signal ROM* is inactive (high), these flip-flops are set asynchronously. When ROM* goes low, a low level is clocked through these flip-flops in sequence. The DTACK* is thus delayed for a minimum of 100 ns from the falling edge of ROM*. DTACK* will be sampled on the next falling edge of the 10MHz clock, and data will be sampled on the next falling edge after that. Thus, there will be a 250 ns period from the time the ROM's are enabled to the clock edge at which data is sampled.
  • Parallel interface and timer U206 (which preferably is a MC68230 integrated circuit) has the following features: a parallel port (Port A) for communicating with a printer interface; a parallel port (Port B) for communicating with a microdiskette driye controller subsystem; and a 24 bit programmable timer.
  • U206 automatically generates signal PDTACK* in response to an access from processor U201. Interrupts from device U201 may be from the timer on line IR4* or from the parallel ports on IR1*. A timer interrupt is serviced by driving TIACK* low during an interrupt acknowledge cycle. U206 will place the contents of its internal timer interrupt vector register TIVR on lines D0-D7, A port interrupt is serviced by driving PIACK* low during an interrupt acknowledge cycle. U206 responds with the contents of its internal port interrupt vector register. The last two bits of this register indicate the source of the interrupt. Such an interrupt can occur as a result of an event on any of the handshake lines H1 through H4.
  • PA0-PA7 which are the outgoing data lines, and are buffered by buffer U015 to generate DATA1-DATA8 to the printer (Port A is configured as output only, and U015 is always enabled); PC4 (or "PAPER"), which goes high if the paper is out of paper; PC2 (or “BUSY IN”), which goes low when the printer is ready to accept data (the input from the printer is buffered by buffer U16) and may be read by processor U201 through Port C of U206; PC1 (or "SEL IN”), which goes high when the printer is on line (the input from the printer is buffered by buffer U16) and may be read by processor U201 through Port C of U206; PC0 (or “FAULT*), which goes low when the printer has experienced a fault condition (the input from the printer is buffered by buffer U16) and may be read by processor U201 through Port C of U206; H2 (or DSTB*), which goes low to indicate DATA
  • MDC microdiskette drive controller
  • PB0-PB7 a bidirectional data bus, which is buffered by buffer U205 (preferably a 74LS245 integrated circuit), which buffer is controlled by the MDC subsystem
  • H4 which is a handshaking signal for data transfers, and may be monitored by the MDC subsystem processor (typically, H4 is programmed to go high when a data byte is received or sent by U201. When this is sensed by MDC processor U403, the MDC processor will respond by accessing the data port, generating a pulse on line FW*. This completes the handshaking sequence, generating an interrupt to U201.); and H3 (FW*), which is the above-mentioned handshaking signal for data transfers.
  • MDC subsystem processor typically, H4 is programmed to go high when a data byte is received or sent by U201.
  • U206 also includes a 24 bit programmable timer, and may optionally be clocked by a five bit prescaler.
  • the timer operates as a down counter which is loaded from a preload register programmed by U201.
  • CPU 1 preferably includes an eight position dip switch for configuration, such as switch U102 shown coupled with octal buffer U101 in Fig. 6.
  • the state of the switches is enabled onto D8-D15 whenever U206 is accessed.
  • the MDC subsystem comprises processor U403 (preferably a 6809E integrated circuit running at 2MHz), 8k x 8 RAM unit U404, 8k x 8 ROM unit U405, 765A floppy disk controller U406, and circuitry for clock generation, address decoding, and interfacing to the microdiskette drive. All communication between the MDC subsystem and processor U201 is through circuit U206.
  • processor U403 preferably a 6809E integrated circuit running at 2MHz
  • 8k x 8 RAM unit U404 8k x 8 ROM unit U405, 765A floppy disk controller U406, and circuitry for clock generation, address decoding, and interfacing to the microdiskette drive. All communication between the MDC subsystem and processor U201 is through circuit U206.
  • the E and Q clocks for processor U403 are generated by circuit 220, which includes two flip-flops U607 driven by an 8 MHz clock derived form the 16 MHz system clock using flip-flop U606.
  • FDCRD* which is the FDC read strobe (and is simply FRW qualified by FE)
  • FDCWR* which is the FDC write strobe (and is qualified by both E and Q to increase data setup times)
  • FW* which is the MDC subsystem strobe, and goes active whenever the data port to parallel interface U206 is accessed to generate an interrupt to processor U201
  • CSEN* which is the chip select enable, and is used to separate two areas of the MDC subsystem memory map into two sections, based on FA13 (in each of these two areas, CSEN* will always be active when FA15 is high), and to enable decoder U407;
  • TC which is the terminal count, and is set high by U403 to signal the end of a data transfer
  • MOTORON* which goes low to actuate the microdiskette drive motor
  • EJECT* which causes the diskette to be ejected when low.
  • TC and MOTORON* are implemented as latches, whose operation is explained by the state transition tables set forth as Table 28:
  • Table 29 specifies the logical relationships between the input and output signals of device U506: TABLE 29
  • the floppy disk controller (FDC) circuit U406 (preferably a 765A integrated circuit) provides control functions and data formatting for the microdiskette drive.
  • Interface circuit U505 (preferably a 9229T integrated circuit) is coupled to U406, and provides data separation and write precompensation.
  • the control lines to the microdiskette are buffered by open-collector devices U012, U304, and U110. Received lines are pulled to VCC with 2.7K resistors.
  • U406 interfaces to the following control lines: WPROT*, which senses a write protected disk; TRK 0*, which senses track 0 in the seek mode, and in read/write mode (indicated by a low on RW*/SEEK) is forced low to prevent U406 from detecting a fault condition; RDY*, which indicates the microdiskette is ready to receive dat; IDX*, which is the index to the beginning of a disk track; SIDE SEL*, which selects one side of a two-sided diskette; WRITE GATE* , which enables write data to the diskette; DIR*, which sets the seek direction; and STEP*, which is forced high when the FDC is in its read/write mode.
  • WPROT* which senses a write protected disk
  • TRK 0* which senses track 0 in the seek mode, and in read/write mode (indicated by a low on RW*/SEEK) is forced low to prevent U406 from detecting a fault condition
  • RDATA* which is the raw data read from the diskette drive
  • WDATA* which is the MFM encoded data to the diskette drive
  • DS3*, DS1*, and DS0* which are drive selects
  • DEJECT* which when low, causes the drive to eject the diskette
  • DMOTON* which is allows U403 to turn off the drive motor.
  • interface circuit U505 preferably a 9229T integrated circuit.
  • U505 also provides clock signals for U406.
  • Clock signal CLKOUT (the write clock to U406) has frequency 1 MHz
  • clock signal HLT/CLK (the master clock to U406) has frequency 8 MHz.
  • FDCSEL and MINI are pulled up, and MFM driven high to configure the microdiskette controller and interface for double density MFM.
  • Write compensation may be set to any value from 0 to 625 ns in 125 ns increments by configuring JP5.
  • CPU 1 includes an initiator for a Small Computer System Interface (SCSI).
  • SCSI is a standard interface designed to facilitate integration of systems and peripherals, such as disk drives, from many manufacturers.
  • CPU 1's SCSI interface includes SCSI controller U208 (preferably an NCR 5386 SCSI controller chip), which supports arbitration and reselection, and handles all low level protocol and timing.
  • An initiator establishes a connection with a target to exchange data. Once the connection is established, through an arbitration and selection process, the target controls the entire transaction, requesting commands and data, and returning status in the form of messages. The target may also disconnect from the initiator, and reconnect at a later time.
  • Table 30 lists the registers of U208 (in an embodiment in which is an NCR 5386 circuit):
  • U011 which is preferably a PLS 153A integrated circuit
  • U208 where DMA denotes a conventional direct memory access technique.
  • the DMA-like access technique of the invention is implemented in an asynchronous state machine described by the state transition diagram shown in Table 31: TABIE 31
  • the SCSI controller (U208) drives DREQ high to request DMA service.
  • Two state variables, DLYREQ1 and DLYREQ2 delay the DMA acknowledge signal (DACK*) until the system processor (U201) accesses the virtual port, VPORT.
  • DACK* the DMA acknowledge signal
  • U208 then brings DREQ low in response to DACK*, and at the same time, U011 generates SDTACK* (the SCSI data transfer acknowledge signal) which informs the system processor (U201) that the transfer is complete.
  • VPORT* goes high, DACK* and SDTACK* go inactive.
  • Signal SDTACK* is generated as a result of DMA acknowledge signal DACK* from U208. If for any reason, DACK* is not asserted after processor U201 attempts to access virtual port VPORT, SDTACK* will remain inactive, and processor U201 will halt execution until the bus times out, generating a bus error.
  • Processor U201 in an embodiment in which U201 is a 68010 integrated circuit, has an internal cache from which such loops may be executed without accessing main memory.
  • CPU 1 can maintain an extremely high data transfer rate in excess of 500,000 bytes per second. Such data transfer rate is greatly in excess of the data rate achievable using a conventional DMA technique.
  • Signal SCSI* goes low to access either U208 or the virtual port VPORT.
  • Signal A5 determines which is selected (SCSI controller U208 is selected if A5 is "zero”; virtual port VPORT is selected if A5 is "one”).
  • SDTACK* goes low when either of these devices is accessed.
  • Table 32 specifies the logical relationships between the input and output signals of device U011:
  • the SCSI bus is terminated with the open collector devices shown connected to the output terminals of U208, including Hex Schmitt-trigger inverter U018, Texas Instruments 74LS642-1 circuit U017, inverter U702, and buffer circuits U114, U115, and U304.
  • the SCSI bus comprises the following signals: SB0-SB7, the data bus which transmits all data, status, and messages (and which is also used during arbitration by the initiator to identify itself, and during selection to identify the initiator and the target devices); SBP, which indicates parity (when the parity option is enabled, this line implements odd parity over SB0-SB7); BSY, which is asserted by the target to indicate that the SCSI bus is being used (during arbitration, the initiator must also assert BSY to indicate to the other devices on the SCSI bus that arbitration is occurring); SEL, which is driven low by the initiator to select a target (since SCSI allows a target to reselect an initiator following disconnection, the initiator must also monitor this line; C/D, which is driven low by the target to indicate that the bus contains control information instead of data; I/O, which is driven low by the target to indicate data input to the initiator, and is also used to distinguish between selection and reselection phases; MSG, which is driven low by the target
  • the first term in each equation represents an access of the controller (U208) itself, while the second term represents an access through the virtual port VPORT.
  • the SCSI controller (U208) may interrupt U201 by asserting SCSIIRQ. This request passes through a NAND circuit, gated by SCSIENB. Processor U201 may disable the SCSI interrupt by resetting SCSIENB, but at the same time, processor U201 may monitor SCSIIRQ via DUART 207.
  • CPU 1 includes dual universal asynchronous receiver/transmitter (DUART) U207 (preferably a 68681 integrated circuit), for serial communication. U207 provides two RS-232C serial ports (Ports A and B) for system console and integration, respectively.
  • the clock for U207 is derived form the clock output of SC11004 single chip modem U707.
  • the clock output of U707 has frequency equal to 7.3728 MHz, which is divided by two (by circuit U600) to generate the 3.6864 MHz clock required by U207.
  • RS-232C standard drivers U014 and U011, and receivers U013 and U109, provide the interface U207 between and the serial lines.
  • General purpose I/O lines in U207 are exploited for other purposes, including: SCRST* (SCSI reset); SCSIENB (SCSI interrupt enable);
  • SCSIIRQ SCSI interrupt request
  • DREQ* SCSI controller DMA request
  • PRST* parallel printer reset
  • Modem U707 which preferably is a Sierra Semiconductor SC11004 single chip modem
  • modem controller U303 which preferably is a Sierra Semiconductor SC11007 parallel interface modem controller
  • a data access arrangement comprising a ring detector, isolation transformer, line seizure relay, and protection circuitry.
  • external parallel resonant crystal Y4 (having 20 pF load), is coupled to modem U707, with a 27 pF capacitor between XTAL1 and ground and a 47 pF capacitor between XTAL2 and ground.
  • the interface to U303 is preferably identical to an 8259 UART.
  • CPU 1 includes real time clock U604 (preferably an Intersil 7170 circuit) for system timekeeping, including date and time, and periodic interrupts.
  • Clock U604 interrupts U201 every 10ms with an autovectored, level four interrupt. The operating system for U201 may use this interrupt to update the time and date variables and to provide context switching.
  • Clock U604 requires a 32.768 kHz crystal, Y3, whose frequency may be adjusted with variable capacitor C17. Since system time is kept from this device, and since U201's operating system will typically depend on accurate time for many of its operations, the frequency of clock U604 must be accurately adjusted (by programming U604 for one second interrupts, and adjusting C17 until the period is exactly one second).
  • U604 is a VPA device requiring special read and write strobes, RTWR* and RTRD*, which are generated by U011.
  • CPU 1 and PCI units 3 are controlled by a software operating system, so that the function of each PCI unit 3 may be independently defined by software downloaded from CPU 1. It is contemplated that the operating system may support a variety of voice and data processing application programs, including a voice mail application program. The operating system will control all input/output operations for the system, as well as the telephone interfacing operations performed by the PCI units 3.
  • system processor U201 of CPU 1 is programmed to operate under an operating system which performs most (or all) of the functions of conventional operating systems (for example, the conventional VMS operating system available from Digital Equipment Corporation), but which also performs the inventive functions to be described below.
  • the inventive system allows processing of digitized voice information together with other digital data.
  • digitized voice and other data coexist in a single file structure.
  • the file records may consist of fields containing numeric data information as well as fields containing recorded, digitized, voice information.
  • the inventive system stores digitized voice information in data records for playback in analog form (such as for transmission over a telephone line to a voice mail user).
  • the inventive system also stores digitized voice information, together with DTMF data and other digital data, in data records for a wide variety of processing operations (such as compilation into customized voice or printed reports).
  • the inventive system is capable of exchanging such data records with a mainframe computer for updating files or retrieval of data base information needed for a variety of voice information processing applications.
  • the inventive operating system performs many of the functions of the above-mentioned VMS operating system, including creation and maintenance of files, display or printing of file contents, configuration and maintenance of software applications, monitoring and control of system processes, and performance of basic system diagnostics.
  • Conventional software algorithms may be used to perform such operations, with the exception of file creation (to be discussed below).
  • an ordinarily skilled computer programmer given the description provided in this Specification, will be able readily to modify a conventional operating system so that the modified operating system may be used to record vocal phrases to be manipulated by a variety of applications programs. Because the inventive system is designed to be particularly useful for supporting voice processing applications, it is important that the system open files as rapidly as possible.
  • the user will record voice information in response to a system-generated vocal prompt. If the system requires a long time to open a file for receiving the user-supplied voice message, users will experience an annoying delay between their response to the prompt, and an indication by the system that the system is ready to accept their message.
  • the operating system of a preferred embodiment of the invention allows rapid file creation by using a novel data construct known as a "pseudo-file", to defer many of the disk access steps required for file creation until after the user commences, to supply file contents (for example, voice information) to the system.
  • file contents for example, voice information
  • step (c) will also include the final operation of making the file id invalid.
  • conventional operating systems create a file in the following manner: (a) search for an empty directory entry and fill with the new filename, allocate disk space for file information, and write to the disk the directory entry and file information; then (b) open the file by searching for a directory entry that matches the filename, and read the file information into a disk cache; then (c) write the data buffer onto the disk using information in the disk cache; and then (d) at the close of the file, write the updated file information from the disk cache to the disk.
  • step (b) of the inventive method corresponds to "write” step (c) of the conventional method.
  • the inventive method defers several disk accesses to its final step (step (c), which follows the inventive "write” step), which disk accesses occur during steps (a) and (b) of the conventional method (i.e., before the "write” step of the conventional method).
  • the operating system of a preferred embodiment of the invention includes a "telephone command processor” algorithm (TCP) which allows a system user to modify the menu presented (vocally) to persons initiating telephone contact with one of the PCI units 3.
  • TCP telephone command processor
  • TCP is a systemwide application access and menu manager, which generates "top level" vocal menus, each of which menus may offer callers the option to access either a submenu or an application program (such as voice mail).
  • a preferred embodiment of TCP will be described with reference to the flow diagram of Figure 8.
  • Each port of each PCI unit 3 may be assigned a default port program that will automatically be executed when a caller telephones the port.
  • the default port program may be a dedicated program which terminates a call, or allows the caller to enter the TCP "log on" sequence, or executes a default application program.
  • TCP will preferably prompt the caller to enter a user ID and password if no other default port program is assigned.
  • TCP will check whether the caller's account is assigned an application. If so, TCP will execute such application program and hang up upon completion of the application program.
  • a voice mail application program is a typical example (in which case, the voice mail application program will typically prompt the caller for a mailbox number and either record a message from the caller or allow the caller to hear recorded messages in the caller's mailbox). If no application is assigned for the caller's account, TCP will cause the PCI unit to present (orally) a TCP menu to the caller.
  • a typical TCP menu might include the following oral phrases: "To enter voice mail, press [1]. For additional options, press [8]. To end this call, press [9]." If the caller responds by pressing key [8] (thereby sending the PCI unit a recognizable DTMF signal), TCP might orally present a submenu such as the following to the caller: "For time and date, press [1]. To change your password, press [2]. To play [a voice game], press [3]. To exit this menu, press [9].” In this example, processor U201 would be programmed to execute a voice game application program in response to entry of the DTMF command "[3]".
  • processor U201's operating system will offer a user the option of revising the TCP menus and submenus presented to callers.
  • the operating system allows the user to define TCP menu key assignments, to record new oral TCP menu phrases and create a voice file for each user-recorded menu phrase (which voice file contains a digitized version of the recorded menu phrase), and to copy such voice files to the operating system directory so that TCP can access each such voice file.
  • Such an application program might prompt a salesman caller to enter the amount and date of each sale made in the last week (by entering DTMF tones).
  • the program might then process the tones entered by a group of salesmen to compile a voice report listing cumulative sales data.
  • voice report might consist of concatenated digitized voice phrases, some of which represent the result of mathematical processing of a set of numerical signals entered by the salesmen (i.e., the program might translate all DTMF "sales price" signals into numbers, and then add the numbers, and then translate the number representing the sum into a voice file containing a prerecorded digitized vocal representation of the sum).
  • the application program might also prompt callers to exercise their option to hear the most recently updated version of such voice report.
  • the user might modify the TCP submenu set forth above to add to it a fifth phrase as follows: "To execute Sales Administrator, press [4]."
  • the user would need to record the indicated phrase, and store it in a voice file that may be accessed by TCP.
  • the operating system of a preferred embodiment of the invention also includes an algorithm allowing users to create files known as "tagged messages".
  • Each tagged message may include: (a) data (such as numerical data, or a digitized voice signal, or both), (b) a field identifying the file as a "tagged message", (c) a field specifying the file name of another file (which other file contains a digitized vocal prompt message), and (d) a field specifying an application program to be executed in response to a command (i.e., a DTMF command supplied by the recipient of the prompt identified in field (c) above).
  • a command i.e., a DTMF command supplied by the recipient of the prompt identified in field (c) above.
  • the voice content of the tagged message (the contents of field (a)) might set forth a meeting agenda, and the prompt identified in field (c) of the tagged message might ask the recipient to press key [2] to initiate a "Meeting Scheduler" application program.
  • Such "Meeting Scheduler" application program might allow the recipient to specify his or her availability for attending a meeting.
  • the recipient Upon completion of execution of the "Meeting Scheduler" application, the recipient would return to the voice mail application (so that he or she could continue to review messages in his or her mail box).
  • the invention also comprises improved methods for automated processing of incoming and outgoing telephone calls. These methods (to be discussed below with reference to Figures 9-14) will preferably be implemented in software. Such software will preferably be downloaded from processor U201 to port processor U87 for controlling a port of PCI unit 3 in operation of the system of Figs 1-7. However, the inventors specifically contemplate that the methods may be embodied in other voice processing hardware/software systems.
  • FIG. 9 A preferred embodiment of one inventive call processing method will next be described with reference to Figs. 9-13.
  • the Fig. 9 flow chart contemplates that a caller has completed a call to a port of PCI unit 3, that an automatic call distribution application program has commenced execution or that an outdial application has commenced execution.
  • Fig. 9 further contemplates that the automatic call distribution application program has accepted from the caller a particular telephone number to be dialed, and has dialed that telephone number (in preparation for transferring the caller to the requested line) or that the outdial application program has dialed the target telephone number (in preparation for delivery of a message to the target party).
  • PCI unit 3 will disable the voice sampling algorithm until the first positive edge (a transition from an energy line state to a no energy line state) thus reducing the chance of preconnect line noise being interpreted as voice and triggering a premature voice detect response.
  • PCI unit 3 will then monitor the status of the distant end of the dialed line for rising or falling edges (indicative, for example, of "ringing" or "busy” conditions). If no positive edge is detected on the dialed line after 15 seconds have elapsed, PCI unit 3 will reconnect with the caller, and send CPU 1 a message indicating that the desired line is dead (or send the caller a voice message indicating that the desired line is dead). If a positive edge is detected within 15 seconds after the Fig. 9 algorithm has commenced, the PCI unit will determine whether the edge detected was more than 600 ms after the Fig. 9 algorithm commenced. If so, the PCI unit will perform the "Wait for answer" operation described by the Fig. 13 flow chart.
  • Fig. 13 indicates that the PCI unit will report to CPU 1 that the called party has answered, if no additional edge (i.e., no second edge in addition to the first edge already detected) is detected within 4.3 seconds. If a second edge is detected within such 4.3 second period, but the overall RNA timer (which started at the beginning of the call progress algorithm) has expired, then the PCI unit will generate a report for CPU 1 (or a voice report for the caller) indicating that the called party's line did ring, but that the called party did not answer (i.e., that a "RNA", or "ring, but no answer” condition exists).
  • PCI unit 3 will determine if a second edge is detected within an additional 575 msec period. If not, the PCI unit will return to position "C" in the Figure 9 flow chart, and continue to monitor the distant end for a signal edge. If so, the PCI unit will determine whether it should report a "busy” condition, a "reorder” condition, or should return to position "C" of the Fig. 9 flow chart.
  • PCI unit 3 will report a busy condition if the indicated conditions are met for progress from position J of Fig. 9, through positions I, L, and M, to position N.
  • PCI unit 3 will report a "reorder" condition if the indicated conditions are met for progress from position J of Fig. 9, through positions I, L, M, 0, and P, to position Q. Otherwise, PCI unit 3 will return to position C on the Fig. 9 flow chart.
  • the edge waiting algorithm shown in Fig. 10 will be performed at each of positions B, F, H, I, and K of Fig. 9.
  • PCI unit 3 At position Wl of the Fig. 10 algorithm, PCI unit 3 will perform the Fig. 11 algorithm to get a 20 ms sample representing the status of distant end.
  • the first step (Y1) of the Fig. 11 algorithm is described in Figure 12.
  • a source code listing (in Assembly language), of the preferred implementation of the call progress method described above with reference to Figs. 9-13, is set forth in this Specification below as Table 33.
  • FIG. 14 A preferred embodiment of another invennive incoming call processing method, for accomplishing a call transfer, will next be described with reference to Fig. 14.
  • the inventive call transfer method contemplates that a caller has completed a call to a port of PCI unit 3 , that an automatic call distribution application program has commenced execution.
  • the automatic call distribution application program first plays a recorded voice message to the caller, which prompts the caller to enter DTMF signals indicating a desired telephone number.
  • the example of the inventive method shown in Figure 14 contemplates that the inventive system is coupled to a conventional PBX system, and that the "desired number" a multi-digit extension number (XXX) on the PBX network.
  • XXX multi-digit extension number
  • the next step in the inventive call transfer method is for PCI unit 3 to execute a "hook flash" ("HF"), or PBX soft hold operation, to place the caller on hold.
  • PCI unit 3 then connects with the PBX to dial the desired number and hangs up ("drops the line", as indicated in Fig. 14), connecting the caller with the desired called party's line.
  • PCI unit 3 is said to have executed a "blind transfer”. The caller will hear the called party's phone ringing at this stage (after execution of the blind transfer), if the called party's line is idle.
  • the next steps of the Fig. 14 method rely on the feature of most conventional PBX systems which automatically reconnects a master station (PCI unit 3, in the present case) to a caller station when the master station goes off hook after the master station executes a blind transfer to a third station (a "called party" station) on the PBX network, if the called station's called party's line is busy or in error (and the caller station does not itself hang up).
  • PCI unit 3 master station
  • Fig. 14 In the Fig. 14 method, after PCI unit 3 drops the line, it goes off hook and listens for a call progress tone. If no dial tone is detected after a user-defined period of time (which may be a fraction of a second, or as long as 2000 ms) then it is assumed that the called party's line was busy and the PBX has reconnected the PCI unit with the caller station. In this case, branch Z3 of the Fig. 14 method is executed, and the PCI unit plays a recorded message to the caller indicating that the called party's line is busy, or unavailable. Such recorded message may offer the caller other menu options, such as the option to hold (in which case the PCI unit will redial the called party's line after waiting for a predetermined period).
  • PCI unit 3 After PCI unit 3 drops the line, goes off hook and detects a dial tone, PCI unit 3 will wait for a user-defined period of time (for example, up to seven seconds) after detecting the dial tone in order to verify the dial tone identification. If a line break occurs during this period, and the dial tone is not verified, branch Z3 of the Figure 14 method is executed. If the dial tone is verified, branch Z1 or branch Z2 of the Fig. 14 method will be executed. Either of three conditions will give rise to detection of a dial tone under these circumstances: either the calling party is connected with the called party (their conversation is in progress); or the called party's line is still ringing; or the calling party decided to abandon the call attempt, and had hung up his or her phone.
  • a user-defined period of time for example, up to seven seconds
  • the PCI unit When the PCI unit detects a verified dial tone under the described circtumstances, it will stay off-hook to keep the line/station busy for a selected period (preferably 20 seconds) so that the PBX will not force any additional calls in. At the end of this period, the PCI will execute a hook flash and attempt to answer the called party's line using the PBX's directed call pick up feature. If a "reorder" tone or "error" tone is heard following such directed call pickup attempt, the PCI unit goes on hook (under branch Z1 of the Fig. 14 method), as it is assumed that either the called party answered the line before the directed call pick up attempt, or that the calling party has hung up (although there are other possibilities).
  • An important advantage of the inventive method described with reference to Figure 14 is that the called party is immediately and directly connected with the calling party when the called party goes off hook to service the call.
  • conventional call transfer systems of this class there is a delay in connecting the calling and called parties, when performing transfers with ring-no-answer supervision, which may lead to the called party's initial greeting being completely lost in the transmission.
  • Such a delay may cause the called party to become confused, since he picked up his phone, expressed a greeting, and did not receive a reply.
  • the caller may also become confused at this point, when employing such a conventional system, since he will not hear the called party's initial greeting.
  • Fig. 14 Among the other advantages of the Fig. 14 method is that if the called party's line rings upon the blind transfer, the calling party will continue to hear a ringing line until the PCI unit intercepts the calling party's line. During the ringing period, the calling party is less likely to become discouraged and hang up than in the case that no ringing tone is audible (as is the case in conventional automated call transfer systems, such as conventional systems operating "behind" a PBX (not on the CO or a trunk side) that operate, electronically, like a single-line 2500-type telephone).
  • Another advantage of the Fig. 14 method is that if the called party does answer the line, the calling and called party will be completely unaware that the PCI unit attempts a directed call pick up during their conversation.
  • DF1E 86 may be reorder DF1E 86 83 2675 LDAA #$83 Show busy DF20 39 2676 RTS DF21 81 0D 2677 3$ CMPA #13 See if in the realm of reorder DF23 23 07 2678 BLS 4$ Not really, unknown signal DF25 81 16 2679 CMPA #22 DF27 22 03 2680 BHI 4$ Far too frequent for even reorder to be DF29 86 84 2681 LDAA #$84 Reorder DF2B 39 2682 RTS DF2C 7E DE2D 2683 4$ JMP WATNRG Return on false detection
  • DFA5 BD E741 2752 CKLINE JSR GSAMP Get a sample DFA8 270F 2753 BEQ 30$ Voice not detected DFAA 7C D02C 2754 INC DTEKT Voice detected, increment the count DFAD B6 D02C 2755 LDAA DTEKT DFBO B1 D034 2756 CMPA VOCWRK At the voice detection threshold? DFB3 23 07 2757 BLS 50$ No, voice not detected DFB5 86 FF 2758 LDAA #$FF Flag that voice detected! (ANSWER!!) DFB7 20 11 2759 BRA 90$ DFB9 7F D02C 2760 30$ CLR DTEKT Voice not detected, reset detection count 2761 *
  • E741 7D D030 3952 GSAMP TST SAMFLG Take a sample? E744 26 03 3953 BNE 10$ Yes, maybe E746 7E E7DE 3954 JMP GSAM10 No, indicate voice not detected E749 96 A0 3955 10$ LDAA DTMFCP Load call progress E74B 84 01 3956 ANDA #$01 Isolate bit for energy E74D 26 03 3957 BNE 40$ Energy present, take a sample E74F 7E E7DE 3958 JMP GASM10 Indicate voice not detected 3959 * 3960 * Note: don't trash A, since we pass it along for later 3961 *
  • Terminator (COMRAM byte $00) sigiifies end of extension
  • Terminator (COMRAM byte 10) coverts to $0F; end of ext.
  • DBB2 B6 D032 2144 LDAA VOCDET Get iser defined detection threshold DBB5 B7 D034 2145 STAA VOCWRK Set initial voice detect threshold DBB8 8603 2146 LDAA #5 Set initial edge detect to 60-80 ms.
  • DBBA B7 D02D 2147 STAA EDGDET DBBD 8D 1A 2148 BSR RSULTC Do the call progress detection DBBF 7E D402 2149 2149 JMP ONLINO and return status code to CINDI
  • DC02 FE D05F 2218 LDX RNATMO Get the RNA timer and delay for that long DC05 SD BB 2219 BSR CPDLAY DC07 802F 2220 BSR DDSHF Do a short hookflash 2221 * note - if you change this timing, you must also change the 2222 * calculations of RNATMO in UNTTST.
  • DCPSEQ is a string of up to 13. bytes, coded as follows:
  • Terminator (COMRAM byte $00) signifies end of extension
  • Terminator (COMRAM byte $10) converts to $0F ; end of ext.
  • DC92 4A 2319 DECA Remove COHRAH offset DC93 84 0F 2320 ANDA #$0F Strip off upper nibble (just in case) DC95 81 0F 2321 CMPA #$0F Is this a COMRAM terminator? DC97 27 06 2322 BEQ 6$ Yes DC99 16 2323 TAB Pass the char in B to DCPDIL DC9A 8D 17 2324 BSR DCPDIL Dial the digit, and fall into 8$ DC9C 08 2325 INX Burp to next digit in the extension DC9D 20 EF 2326 BRA 5$ Keep looping until COMRAM terminator encountered
  • DCA4 81 8B 2330 7$ CMPA #$8B Is this a digit [0] - [9] , [*] , [#] ?
  • DCA8 81 80 2332 CMPA #$80 Is this a digit [0] - [9], [*], [#] ?
  • DCB2 39 2338 9$ RTS 2339 * 2340 * Dial the digit passed in B 2341 * B contains $x0 thru $x9 for digits zero thru nine, 2342 * and B contains $xA for [*] , and B contains $xB for [#] 2343 * Note that DTMTON does not care about the upper nibble. 2344 * Be sure to preserve X throughout this routine. 2345 *
  • DD5F 26 03 2447 BNE 2$ DD61 7E DD27 2448 JMP NR2$ Can't be error tone DD64 7C D028 2449 2$ INC EDGCNT Count up an edge DD67 CE 02EE 2450 LDX #750 DD6A BD DF2F 2451 JSR GETEDG DD6D 2B D8 2452 BMI CPM1S ANSWER detected!
  • DD6F 27 D6 2453 BEQ CPH1$ Ne edge detected, assume ANSWER DD71 7F D030 2454 CLR SAMFLG Set the no samples flag DD74 7C D02E 2455 INC ERRFLG Indicate into error checking DD77 FE D01F 2456 LDX TMR_C2 Timed out DD7A 26 E8 2457 BNE 2$ No timeout, keep counting DD7C 7C D028 2458 INC EDGCNT One more edge DD7F BD DDD6 2459 JSR STOPT1 Disable T1 and flag "end of call progress" DD82 B6 D028 2460 LDAA EDGCNT How many edges?
  • DDB2 B7 D02D 2487 STAA EDGDET DDB5 FE D017 2488 LDX PADDLI Get the pre-answer-detect delay DDB8 27 13 2489 BEQ 2$ Not need for delay DDBA FF D01D 2490 STX THR_C1 DDBD 8601 2491 LDAA #1 Signal that the timer is going DDBF B7 D03E 2492 STAA CPENBL DDC2 86 C0 2493 LDAA #$C0 DDC4 97 AE 2494 STAA CPENBL DDC6 FE D01D 2495 1$ LDX TMR_C1 Wait for delay to end DDC9 26 FB 2496 BNE 1$ DDCB 8D 09 2497 BSR STOPT1 Stop the timer DDCD 32 2498 2$ PULA DDCE
  • DDD6 C640 2507 STOPT1 LDAB #$40 Disable T1 timer
  • DDD8 D7 AE 2508 STAB IRWENB
  • DDDA 5F 2509 CLRB.
  • DDDB F7 D03E 2510 STAB CPENBL Flag that we are not longer doing call progress
  • DDDE F7 D01B 2511 STAB TMR_OH
  • F7 D01C 2512 STAB THR_OH+1

Abstract

A voice processing system and method for performing a variety of operations, including voice mail processing, in response to digital signals, including digitized voice signals and DTMF signals. A preferred embodiment of the invention includes a CPU (1), a number of programmable communications interface units (3), and a VME bus (7) connecting the CPU with the programmable communication interface (PCI) units. Each PCI unit interfaces with one or more telephone lines. The CPU and the PCI units are controlled by a software operating system in which both digitized voice signals and other digital data may coexist, for efficient processing in a single file structure.

Description

VOICE INFORMATION SYSTEM AND METHOD FOR TELEPHONE APPLICATIONS
Field of the Invention
The invention relates to voice processing systems for receiving telephoned voice signals, digitizing the voice signals, and processing the digitized signals.
More particularly, the invention is a system and method for performing a variety of voice processing operations, including voice mail and automated call forwarding operations, and processing both digitized voice data and other digital data.
Background of the Invention
Conventional voice processing systems include circuitry for digitizing voice signals, circuitry for generating analog audio signals from stored digital signals, and one or more computers for processing both digitized voice signals and high-frequency encoded telephone keypad command signals. Such telephone keypad command signals will be referred to herein as "dual tone multiple frequency" or "DTMF" signals. A voice mail system is one type of conventional voice processing system.
A conventional voice mail system is described in U.S. Patent 4,371,752, issued February 1, 1983 to Matthews, et al., and U.S. Patent 4,652,700, issued March 24, 1987 to Matthews, et al. This voice mail system allows users at remote telephone locations to record voice messages for designated addressees, and to play back and edit the recorded messages by transmitting preassigned DTMF codes over telephone lines. A user may also access the system by telephone, enter a preassigned DTMF identification code, and receive any messages that have been recorded on the system for the user. Once a message has been recorded on the system, the system is capable of automatically dialing the message addressee to deliver the recorded message. The system digitizes received analog audio signals before it digitally processes them, and is capable of generating analog audio output signals from stored digital signals.
The system of U.S. 4,371,752 (and 4,652,700) includes CPU 70 (a component of call processor subsystem 62A) and CPU 100 (a component of administrative subsystem 60). Each CPU is connected by a multibus to a number of identical "Universal Control Boards" ("UCBs"), including communication port interface 74, disk adapters 76 and 78, and block transfer interface bus unit 80 (for CPU 70), and disk adapters 114 and 116, and block transfer interface bus unit 118 (for CPU 100). Each UCB includes an Intel 8085 microprocessor which is preprogrammed to establish a definite function for the UCB.
Communication port digital data bus 88 connects communication port interface 74 with a number of communication port drivers 92. A CODEC 96 is connected between each driver 92 and a user telephone 18. Communication port interface 74 accepts digitized audio signals from each CODEC and supplies them on the multibus to the other system components for processing. Interface 74 also supplies digital signals received on the multibus from the other system components to the CODECs for conversion into analog audio format for transmission to the appropriate user telephones.
The system disclosed in U.S. 4,371,752, however, has a severely limited range of applications. The system is capable of functioning only as a voice mail system, with an extremely limited menu of user- selected operations, and with each individual port driver 92 performing a fixed, identical function. The port drivers are not independently programmable to perform programmed functions, and there is no capability for the system users to program a system CPU to process both digitized voice messages and other digital data stored in a common file structure in the system, for example to generate customized output signals, such as voice reports.
Another conventional voice mail system is disclosed in U.S. Patent 4,625,081, issued November 25, 1986 to Lotito, et al. The system of U.S. 4,625,081 includes an information processing system 250 which in turn includes one or more general purpose processors (942 and 944) said to be capable of executing application programs. The system also includes a number of real-time subsystems (230 through 238) for receiving voice and control signals from telephone room subsystems 206, 214, and 216, providing switching connections between channels, and communicating with processing system 250 to facilitate storage and retrieval of voice messages. However, the disclosed applications of the system are limited to use as a voice mail system with an extremely limited menu of user-selected operations. There is no suggestion that the system be used to process both digitized voice messages and other digital data stored in common file structure in the system, for example to generate customized output signals, such as voice reports.
Yet another conventional voice mail system is disclosed in U.S. Patent 4,549,047, issued October 22, 1985 to Brian, et al. The U.S. 4,549,047 system includes a number of digital computers 22 each communicating with a telephone signal conversion subsystem 40 via a digital data bus 24. Subsystem 40 receives Touch-Tone telephone signals and analog signals on telephone lines 94, digitizes the analog voice signals received on lines 94, and forwards the received telephone signals in digital form to one of computers 22. In response to such signals, computer 22 may store or retrieve a digital voice message. However, U.S. 4,549,047 does not disclose applications other than a limited menu of voice mail applications, and in particular, fails to disclose the operation of processing both digitized voice messages and other digital data stored in a common file structure in the system, for example to generate customized output signals, such as voice reports. Further, U.S. 4,549,047 teaches that computer 22 should preferably be a Digital Equipment PDP-11 computer. Such a conventional, general-purpose computer is not specially adapted for streamlined voice processing applications.
Another type of conventional voice processing system is disclosed in U.S. Patent 4,716,583, issued
December 29, 1987 to Groner, et al. The system of U.S. 4,716,583 detects incoming telephone calls from users, initiates telephone calls to users, decodes DTMF commands from users, and translates ACSII text into analog voice signals for transmission on telephone lines to users (for example, in response to DTMF commands from the users). The system includes a central CPU 12 which is connected by a data bus to a number of host computers 23 and to a text-to-speech processing unit 25 for each host computer. A telephone line 27 is connected to each processing unit 25. CPU 12 may forward ASCII data from a host computer 23 to one of the processing units 25 for conversion into an analog voice signal. Unit 25 may then forward the analog voice signal to a user over one of the telephone lines 27. DTMF command signals may flow from each telephone line 27 to CPU 12. In response to the DTMF command signals, CPU may execute an application program, such as an electronic mail program. The system of U.S. 4,716,583, however, is not capable of accepting analog voice messages on telephone lines 27, digitizing such voice messages, and storing them (for later transmission in digital form to one of the host computers or reconversion to analog form for retransmission in analog form on phone lines 27). Nor is the system of U.S. 4,716,583 capable of processing digitized telephone voice messages together with other digital data. Furthermore, the computer programs employed by each CPU 31 in the U.S. 4,716,583 system reside in a read-only-memory 35, so that each text-to-speech processing unit 25 has a preassigned function which may not be changed, for example, by downloading new software from central CPU 12.
It has not been known until the present invention how to design a voice processing system which avoids the limitations described above, and which is capable of functioning not only as a voice mail system, but also as a general purpose data processing system for processing both digitized voice signals and other digital data (to generate, for example, customized voice reports), and storing both digitized voice signals and other digital data together in a single record.
Summary of the Invention The invention is voice processing system and method for performing a variety of operations, including voice mail processing, in response to digital signals, including digitized voice signals and DTMF telephone keypad signals. A preferred embodiment of the inventive system includes a CPU, a number of programmable communications interface ("PCI") units, and a bus connecting the CPU with the PCI units. Each PCI unit interfaces with one or more telephone lines, and includes means for digitizing analog signals received on each telephone line and for converting digital signals from the bus into analog form for transmission on selected ones of the telephone lines.
The CPU is specially designed to communicate extremely rapidly with devices coupled with the CPU on an SCSI bus.
The CPU and the PCI units are controlled by a software operating system in which both digitized voice signals and other digital data may coexist, for efficient processing in a single file structure. The operating system employs novel data constructs known as "pseudo-files" and files known as "tagged messages". One important type of tagged message is a file which includes not only a voice message, but also instructions to the operating system for causing playback of voice prompts inviting the voice message recipient to send either a voice mail reply or to execute a customized application program. By using pseudo-files, the inventive system facilitates rapid file creation, which advantageously minimizes the perceptible delay to a system user desiring to record a voice message as an operating system file.
The operating system of the invention also allows a user to customize a voice menu of options to be vocally presented to persons calling one of the PCI units. Examples of such options include execution of a voice mail application program, or another, custom designed application program, by sending DTMF and vocal signals over a telephone line.
The function of each PCI may be independently defined by software downloaded from the CPU. The invention comprises improved methods, preferably implemented in software, for automated monitoring and transferring of incoming telephone calls.
Brief Description of the Drawings
Figure 1 is a block diagram of a preferred embodiment of the inventive system.
Figure 2 is a schematic diagram of the VME slave interface and interrupter of PCI unit 3 of the Fig. 1 embodiment.
Figure 3 is a schematic diagram of the random access memory components of PCI unit 3 of the Fig. 1 embodiment.
Figure 4 is a schematic diagram of the port processor and digital signal processor components of PCI unit 3 of the Fig. 1 embodiment.
Figure 5 is a schematic diagram of the CODEC, DTMF transceiver, and telephone line interface components of PCI unit 3 of the Fig. 1 embodiment. Figure 6 is a schematic diagram of a first portion of CPU 1 of the Fig. 1 embodiment.
Figure 7 is a schematic diagram of the remaining portion of CPU 1 of the Fig. 1 embodiment.
Figure 8 is a flow chart of a preferred embodiment of the manner in which the inventive system processes an incoming telephone call.
Figure 9 is a flow chart of a preferred embodiment of an inventive method for automated monitoring of the progress of a telephone call. Figure 10 is a flow chart of a preferred embodiment of a portion of the Figure 9 method.
Figure 11 is a flow chart of a preferred embodiment of a portion of the Figure 10 method. Figure 12 is a flow chart of a preferred embodiment of a portion of the Figure 11 method. Figure 13 is a flow chart of a preferred embodiment of a portion of the Figure 9 method.
Figure 14 is a flow chart of a preferred embodiment of an inventive method for automated call transfering.
Detailed Description of the Preferred Embodiments
Figure 1 is a block diagram of a preferred embodiment of the invention. Central processing unit ("CPU") 1, programmable communications interface
("PCI") unit 3, and memory unit 5 each interface with bus 7. In a preferred embodiment, bus 7 is a conventional VME bus and memory unit 5 is selected from those commercially available which are campatible with the selected embodiment of bus 7. Although one PCI unit 3 is shown, the inventive system may include more than one identical PCI units, each connected in the same manner to bus 7 as is unit 3 in Figure 1.
Each PCI unit 3 includes an interface circuit 114 for receiving signals from, and transmitting signals to, telephone line 115. Interface circuit 114 includes a CODEC for digitizing incoming voice signals, a telephone line interface, and a DTMF detector for receiving incoming DTMF signals. Each PCI unit 3 also includes a digital signal processor 110, which performs speech compression and reconstruction; a port processor 106 (preferably a 2MHz Motorola 6809 integrated circuit), which performs all port processing operations other than speech compression and reconstruction, including data transfers, telephone line interface operations, and call progress detection operations; a random access memory ("RAM") unit 112; a RAM arbiter 108; a VME bus slave interface unit 102; a VME bus interrupter unit 104; and a backplane interface logic unit 100 for interfacing between VME bus 7 and units 102 and 104.
In the preferred embodiment shown in Figure 1, each PCI unit 3 also includes a second interface circuit 214 for transferring signals to and from telephone line 215, a second port processor 206, a second digital signal processor 210, an second RAM unit 212, and a second RAM arbiter 208. Each of units 206, 208, 210, 212, and 214 is identical to the corresponding one of units 106, 108, 110, 112, and 114, and units 206, 208, 210, 212, and 214 are connected to each other and to units 102 and 104 in the same manner as are corresponding units 106, 108, 110, 112, and 114.
CPU 1 performs all system processing for the inventive voice processing system. In a preferred embodiment, CPU 1 includes a microprocessor 35 (which is preferably a Motorola MC68010 integrated circuit), a memory management unit 31 (which is preferably a Motorola MC68451 integrated circuit), and logic for supporting system input/output and VME bus supervisory functions. The circuitry supporting the VME bus supervisory functions includes system clock driver 15, bus arbiter 17, IACK daisy chain driver 19, and bus timer 21. Each PCI unit 3 must be compatible with bus 7. In a preferred embodiment in which bus 7 is a conventional VME bus, unit 102 is a VME bus slave interface unit which appears to bus 7 as a slave with 16 bit and 8 bit data transfer capability, block transfer capability, and 24 bit addressing capability. A preferred embodiment of unit 102 will be discussed below with reference to Figure 2.
Port processor 106 (or port processor 206) of PCI unit 3 may interrupt system processor 35 of CPU 1 via VME bus interrupter unit 104. A preferred embodiment of unit 104 will be described below with reference to Figure 2.
Interface logic unit 100 comprises conventional VME backplane interface circuitry for connecting units 102 and 104 with VME bus 7.
Figure 2 is a schematic diagram of a preferred embodiment of VME bus slave interface unit 102 (comprising programmable logic devices U16, U21, and U35, and integrated circuit U73), VME bus interrupter unit 104 (comprising programmable logic devices U42 and U49, and registers U3 and U4), and interface logic unit 100 (comprising buffer circuits U17, U28, U29, U6, U11, U43, U50, and U78). The circuits comprising interface logic unit 100 are connected between VME bus 7 and units 102 and 104.
Programmable logic devices U21 and U35 of slave unit 102 decode the buffered VME bus address signals (VA01-VA23) and address modifier signals (AM0-AM5) . Device U35 compares signals VA01-VA23 with the slot identification signals SID0-SID3 received from VME bus 7 for identifying the slot in which the PCI unit 3 is installed (typically, a number of PCI units 3 will be installed in different slots on a motherboard connecting all components of the system of the invention). If the address signals match the slot identification number, the VALIDID line goes high. Device 35 also decodes the address modifiers AM0-AM5, and causes line VALIDAM* to go low, for example, if any of the address modifiers indicates a standard non- privileged data, program, or block transfer access, or a supervisory data, program, or block transfer access. Device U21 decodes address signals VA21-23 and VA14-16. If the address falls within the PCI address space, and VIACK is low and VALIDID is high, the PCI is selected. If the PCI is selected with an invalid address modifier (i.e., VALIDID is low), BADXFER* will go low, indicating that an illegal transfer is being attempted. This will cause the "DTACK and BERR generator" (circuit U16) to generate a VME bus error signal. Device U21 also generates the following signals: AVRAMSEL* (for selecting RAM unit 112) , BVRAMSEL* (for selecting RAM unit 212), CLATCHSEL* (which is active when the VME bus master, CPU 1, selects port control latch circuit U79) , and LATCHRD* (the VME interrupt vector register select signal, which is active when the VME bus master addresses the VME bus interrupt vector register of circuit 104) .
Table 1 specifies the logical relationships between the input and output signals of device U21, and Table 2 specifies the logical relationships between the input and output signals of device U35. In Tables 1 and 2 (and the other Tables set forth below), the symbol "!" represents "inverse" (so that signal !A is the inverse of signal A), the symbol "&" represents "and", and the symbol "#" represents "or".
Table 1 !AVRAMSEL = VA23 & VA22 # !VA21 & VALIDID & !VA16 &
VA15 & VA14 & !VIACK & VLWORD & VAS & !VALIDAM; ! BVRAMSEL = VA23 & VA22 & !VA21 & VALIDID & VA16 &
VA15 & VA14 & !VIACK & VLWORD & VAS & !VALIDAM; ! BADXFER = (VA23 & VA22 & !VA21 & VALIDID & VAS &
!VIACK & !VLWORD # VA23 & VA22 & !VA21 & VALIDID & VAS & !VIACK & VALIDAM);
! LATCHSEL = VA23 & VA22 & !VA21 & VALIDID & !VA15 &
!VA14 & & !VIACK & VLWORD & VAS & !VALIDAM & VDSO & VWRITE;
! VRAMSEL = VA23 & VA22 & !VA21 & VALIDID & VA15 & VA14 & !VIACK & VLWORD & VAS & !VALIDAM; !LATCHRD = VA23 & VA22 & !VA21 & VALIDID & !VA15 & VA14 & !VIACK & VLWORD & VAS & !VALIDAM & VDSO & !VWRITE;
Table 2
!VALIDID = (((((((VA20 & !SID3
# !VA20 & SID3)
# VA19 & !SID2)
# !VA19 & SID2) # VA18 & !SID1)
# !VA18 & SID1)
# VA17 & !SIDO)
# !VA17 & SIDO); VALIDAM = ! (AMO & AM3 & AM4 & AM5 # AM1 & AM3 & AM4 & AM5)
VME bus 7 is asynchronous, so that all transfers require a handshaking between the VME bus master (CPU 1) and each VME bus slave (each of PCI units 3). The handshaking signals employed in a data transfer are: AS* (address strobe), DS0* and DS1* (data strobe signals), DTACK* (a data transfer acknowledgement signal, the inverse of DTACK), and BERR* (a bus error signal).
Device U16 of PCI unit 3 generates the following signals: DTACK (which occurs when VDTACK is active, or when the control latch is selected, or during an interrupt acknowledge, and remains active until both VDS0 and VDS1 are inactive); BERR (the inverse of BERR*, which has the same timing as DTACK, and which becomes active when an illegal access is attempted, as described above); LATCHCK and DLCLK (state variables of a simple state machine. DLCLK goes low for one clock cycle when the control latch is accessed, and LATCHCK goes low during the next clock cycle); VDBEN (an asynchronous signal which goes active whenever any component of the PCI is accessed and remains low until both VDS0 and VDSl are high); and VALD and VACLK (state variable signals of an asynchronous state machine. VACLK clocks the VME bus address into the address counters when VALD is low, or increments the counters when VALD is high).
Table 3 is the state transition table for signals VALD and VACLK:
Table 3
Inputs (VAS,VDS0,DTACK)
000 001 011 010 110 111 101 100
00 | 00* | 00* | 00* | 00* | 01 | 01 | 01 | 01 |
Outputs
(VALD,VACLK) 01 | 00 | 00 | 00 | 00 | 11 | 11 | 11 | 11 | 11 | 00 | 00 | 00 | 00 | 10 | 11* | 10 | 10 |
10 | 00 | 00 | 00 | 00 | 10* | 11 | 10* | 10* |
* = Stable state
Each entry in Table 3 represents the next state of the asynchronous state machine given the current inputs and the current outputs. A state is "stable" if the next state is identical to that state. As is apparent from Table 3, the address counters will load whenever
VAS goes active, and will increment on every odd byte access as long as VAS remains active.
Table 4 specifies the logical relationships between the input and output signals of device U16: Table 4
Original Equations:
!VALD = (!VAS # !VACLK & !VALD) ;
!VACLK = (((!VAS # VALD & ! VDSO) # VALD & !DTACK) # VALD & VRAMSEL) ; !VDBEN = (((((VDSl & !VRAMSEL # VDSO & !VRAMSEL)
# VDSO & !LATCHSEL)
# !ONTACK)
# !VDBEN & VDSl) # !VDBEN & VDSO) ;
! BERR = ((!BERR & BADXFER # BERR & !VDSO & !VDSl) #
VRESET) ; !DTACK = (((!DTACK & VDTACK & INTACK & LATCHCK
# DTACK & !VDSO & !VDSl) # !DTACK & !INTACK & DLCLK)
# VRESET) ;
!LATCHCK = !DLCLK & !LATCHSEL & !VRESET; !DLCLK = (VDS0 & !LATCHSEL & DLCLK & LATCHCK & !DTACK & !VRESET # DLCLK & !INTACK & !DTACK & !VRESET); System processor 35 of CPU may control operation of PCI 3 via port control latch U79. Device U79 is preferably a Texas Instruments Inc. 74LS259B addressable latch. When signal CLATCHSEL*, emerging from device U79 goes low, signal VDOO is latched at the output addressed by the three select input signals VA16, VA01, and VA02 (of which VA16 is the most significant select input). VA16 separates the eight possible inputs into two groups of four, addressed 64K bytes apart. Each of these two groups controls one of ports A and B. The control outputs of device U79 are: AOFFH (BOFFH), which is supplied to device U89 of the port A interface 114 shown in Figure 5 (or the corresponding circuit of port B interface 214), for forcing the signalling relays of interface 114 (214) to an "off hook" condition when high, provided that signal A6809 (B6809) is low; A6809 (B6809), which gives port processor 106 (206) control over the signalling relays of interface 114 (214) when high; AMRST (BMRST), which resets port processor 106 (206) when low; and AMINT (BMINT), which generates an interrupt to port processor 106 (206) when pulsed. When the system powers up, all control bits are cleared, thus resetting port processors 106 and 206 and forcing the signalling relays of interfaces 114 and 214 to their "power up" state, corresponding to a "zero" value of signal AOFFH and BOFFH.
PCI unit 3 may interrupt system processor 35 of CPU 1, by sending interrupt request signals from interrupt unit 104 on VME bus 7. Unit 104 comprises programmable logic devices U42 and U49 (for timing and control), and registers U3 and U4 (for providing the interrupt vectors). Registers U3 and U4 are preferably Texas Instruments Inc. 74LS374 integrated circuits. Interrupt unit 104 is a "release on acknowledge" (ROAK) interrupter in the sense that it will release its interrupt request only when the interrupt has been acknowledged. More specifically, the functions of unit 104 in each PCI unit 3 include: generating an interrupt request on line IRQ, providing an interrupt vector on lines D00-D07 when the interrupt request is being acknowledged, releasing its interrupt request during the acknowledge cycle, passing the IACKIN signal (the incoming interrupt acknowledge daisy chain signal) to the next PCI unit 3 (typically mounted in the next slot on a motherboard) if no interrupt is pending, or if the interrupt being acknowledged is at a different level, and providing the DTACK* signal to end the interrupt acknowledge cycle. In the Figure 2 embodiment, interrupt unit 104 will treat ports A and B (hence port processors 106 and 206) as separate "level 3" interrupters, with port A having priority.
Devices U42 and U49 implement timing and control for interrupter 104. Device U49 generates the following four combinatorial outputs from the input signals received from port processors 106 and 206: LOADA (LOADB), whose rising edge will load data from the port A (port B) data bus into interrupt vector register U4 (U3); and SETA* (SETB*), which, if low, will set an interrupt request for port A (port B). Device U49 also generates four registered signals, from two state machines, one for each port, according to the state transition table set forth as Table 5:
Table 5
CURRENT STATE NEXT STATE
VRESET LATCHRD EN* Q2 RST* Q2' RST*' - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
| 1 | X | X | X | X | | 1 | 0 | - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
| 0 | X | 1 | 1 | 1 | | 1 | 1 | - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
| 0 | 0 | X | 1 | 1 | | 1 | 1 | - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
| 0 | 1 | 0 | 1 | 1 | | 0 | 1 | - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - | 0 | 1 | 0 | 0 | 1 | | 0 | 1 | - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - | 0 | X | 1 | 0 | 1 | | 0 | 0 | - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - | 0 | X | 1 | 0 | 0 1 | 1 | 0 | - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - | 0 | X | 1 | 1 | 0 | | 1 | 1 | - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Signals Q2A and Q2B (represented by terminals 18 and 20 of device 49, respectively, but used internally only within device 49) will go low during an interrupt acknowledge cycle, but not when system processor 35 is reading the contents of the interrupt register (U3 or U4) during testing. At that time, RSTA* (RSTB*) will go low for two clock cycles, resetting the interrupt request. This ensures that the interrupt request remains valid for the entire interrupt acknowledge cycle, but that an interrupt request is not reset by reading the interrupt vector register under software control.
Table 6 specifies the logical relationships between the input and output signals of device U49: Table 6 Original Equations:
!LOADA = !AMIVSEL & !AMRW & !AMAO & E;
!LOADB = !BMIVSEL & !BMRW & !BMA0 & E; ! SETA = !AMIVSEL & !AMRW & AMAO & E; !SETB = !BMIVSEL & !BMRW & BMAO & E; !RSTA = (!Q2A & ENA # VRESET); !RSTB = (!Q2B & ENB # VRESET); !Q2A = (RSTA & ! ENA & LATCHRD & !VRESET # !Q2A & RSTA & !VRESET) ; !Q2B = (RSTB & ! ENB & LATCHRD & !VRESET # !Q2B & RSTB & !VRESET) ; Device U42 generates the following signals: INTACK*, which goes low when either of interrupt vector registers U3 and U4 is enabled, which will occur during an interrupt acknowledge cycle or when the registers are read by system processor 35 for testing purposes; IRQ, which is inverted and then supplied as the interrupt request to the VME bus 7 (signal IRQ is high whenever an interrupt request is pending from either port A or port B); IACKOUT*, the VME bus interrupt acknowledge signal which is output to the next slot in the IACK daisy chain (signal IACKOUT* will go low if VIACKIN is high, and either the current interrupt acknowledge cycle is for an interrupt level other than three, or there is no interrupt request from either port, which latter condition is indicated by DNOIRQ* going low); ENA* and ENB*, which enable their respective interrupt registers, U4 and U3, onto the internal data bus within PCI 3; IRQA* and IRQB*, which are used internally within device U42; DNOIRQ*, which is used internally within device U42 to prevent interrupt circuit 104 from attempting to respond to an interrupt acknowledge cycle if an interrupt request occurs after the cycle has begun (if IRQA* and IRQB* are both inactive when VAS goes active, DNOIRQ will go low, and DNOIRQ will remain low until VAS goes inactive) and Y1 and Y2, which are state variables of an asynchronous state machine, and are used internally within device U42 (Y2 is employed to qualify several signals, ensuring that they will be delayed for at least one half clock cycle to ensure that IACKOUT* will be delayed until the onboard logic can determine if an onboard interrupt request is pending).
The state transition table for signals Y1 and Y2 is shown below as Table 7:
Table 7 CLK, VIACKIN 00 01 11 10 - - - - - - - - - - - - - - - - - - - - - - - - -
11 | 11* | 11* | 01 | 11* | - - - - - - - - - - - - - - - - - - - - - - - - -
01 | 11 | 00 | 01* | 11 |
Y1, Y2 - - - - - - - - - - - - - - - - - - - - - - - - -
00 | 11 | 00* | 00* | 11 | - - - - - - - - - - - - - - - - - - - - - - - - -
10 | 11 | 10* | 00 | 11 | - - - - - - - - - - - - - - - - - - - - - - - - -
* = Stable state Table 8 specifies the logical relationships between the input and output signals of device U42:
Table 8 !INTACK (! ENA # ! ENB); !IRQ IRQA & IRQB; !IACKOUT = ((!Y2 & !DNOIRQ & VAS # !Y2 & VAS & !VA2)
# !Y2 & VAS & !VA1) ; ! ENA = ((!Y2 & !IRQA & VDSO & VAS & !VA3 & VA2 & VA1 & ENB & DNOIRQ
# !LATCHRD & VDSO & VA1 & ENB)
# ! ENA & VDSO & ENB) ; ! ENB ((!Y2 & !IRQB & IRQA & VAS & !VA3 & VA2 &
VA1 & VDSO & ENA & DNOIRQ
# iLATCHRD & VDSO & VA1 & ENA)
# ! ENB & VDSO & ENA); IRQA = (SETA & IRQA # !RSTA) ; IRQB = (SETB & IRQB # !RSTB) ; ! DNOIRQ = ((VAS & !DNOIRQ # IRQA & IRQB) # VAS &
VA3 & !Y2 & VDSO) ; Y1 = (!CLK & Yl # !VIACKIN) ;
Y2 = ((Yl & Y2 # CLK & Y2) # !VIACKIN); RAM unit 112 may be addressed by either port processor 106 or by CPU 1, with arbitration transparent to both. Similarly, RAM unit 212 may be addressed by either port processor 206 or by CPU 1, with arbitration transparent to both.
Figure 3 is a schematic diagram of the elements shown as blocks 108, 112, 208, and 212 in Figure 1. Each of RAM units 112 and 212 is a shared RAM unit in the sense that both CPU 1 (via VME bus 7) and one of the port processors (unit 106 or 206) may access each of RAM units 112 and 112. RAM unit 112 includes 16K bytes of shared RAM (provided by 8K x 8 static RAM unit U61 and 8K x 8 static RAM unit U63) . Similarly, RAM unit 212 includes 16K bytes of shared RAM (provided by 8K x 8 static RAM unit U33 and 8K x 8 static RAM unit U47).
The VME bus address and the port processor address for RAM unit 112 are multiplexed by data selector/multiplexer circuits U62, U68, U74, and U55, each of which is preferably a Texas Instruments Inc.
74LS157 integrated circuit. The VME bus address and the port processor address for RAM unit 212 are multiplexed by data selector/multiplexer circuits U34, U41, U48, and U55, each of which is preferably a Texas Instruments Inc. 74LS157 integrated circuit.
The VME bus 7 interfaces with the "Port A" RAM unit (comprising devices U61 and U73) via bidirectional octal buffers U9 and U15 and octal registers U5 and U10, and with the "Port B" RAM (comprising devices U33 and U47) via bidirectional octal buffers U8 and U14 and octal registers U5 and U10. Control signals for the interfaces are supplied by the timing and control logic described below.
Port processor 106 interfaces with "Port A" RAM unit 112 (comprising devices U61 and U73) via bidirectional octal buffers U20 and U27, and port processor 206 interfaces with "Port B" RAM 212 (comprising devices U33 and U47) via bidirectional octal buffers U19 and U26. All accesses by the port processors are byte wide synchronous accesses, to be described below.
Buffers U8, U9, U14, U15, U19, U20, U26, and U27 are preferably Texas Instruments Inc. 74LS245 integrated circuits, and registers U5 and U10 are preferably Texas Instruments Inc. 74LS374 integrated circuits.
Programmable logic devices U36, U56, and U57 generate timing and control signals for accessing the RAMs, and "E" and "Q" clock signals for port processors 106 and 206. Identical devices U56 and U57 serve as memory control line decoders, with device U56 associated with "Port A" RAM 112 and device U57 associated with "Port B" RAM 212. Device U36 implements a state machine which runs off the 16KHZ VME system clock ("VSYSCLK"). The state variables and state machine operation are described in Table 9:
Table 9
CURRENT STATE NEXT STATE
V
R V V
V A D D
R M T T
E S A A
S E V C C
E L D E S S S K E S S S K
T * S * Q 0 1 2 * * Q 0 1 2 *
1 | 1 | X | X | X | X | X | X | X | X | | 1 | 0 | 0 | 1 | 1 | 1 |
2 | 0 | X | X | 1 | 0 | 0 | 1 | 1 | 1 | | 1 | 0 | 1 | 1 | 1 | 1 |
3 | 0 | X | X | 1 | 0 | 1 | 1 | 1 | 1 | | 1 | 1 | 1 | 1 | 1 | 1 |
4 | 0 | X | X | 1 | 1 | 1 | 1 | 1 | 1 | | 1 | 1 | 0 | 1 | 1 | 1 |
5 | 0 | X | X | 1 | 1 | 0 | 1 | 1 | 1 | | 0 | 1 | 0 | 1 | 1 | 1 |
6 | 0 | X | X | 0 | 1 | 0 | 1 | 1 | 1 | | 0 | 1 | 1 | 1 | 1 | 1 |
7 | 0 | X | X | 0 | 1 | 1 | 1 | 1 | 1 | | 0 | 0 | 1 | 1 | 1 | 1 |
8 | 0 | X | X | 0 | 0 | 1 | 1 | 1 | 1 | | 0 | 0 | 0 | 1 | 1 | 1 |
9 | 0 | 1 | X | 0 | 0 | 0 | 1 | 1 | 1 | | 1 | 0 | 0 | 1 | 1 | 1 |
10 | 0 | X | 0 | 0 | 0 | 0 | 1 | 1 | 1 | | 1 | 0 | 0 | 1 | 1 | 1 |
11 | 0 | 0 | 1 | 0 | 0 | 0 | 1 | 1 | 1 | | 1 | 0 | 0 | 0 | 1 | 1 |
12 | 0 | X | X | 1 | 0 | 0 | 0 | 1 | 1 | | 1 | 0 | 1 | 0 | 0 | 1 |
13 | 0 | X | X | 1 | 0 | 1 | 0 | 0 | 1 | | 1 | 1 | 1 | 0 | 0 | 1 |
14 | 0 | X | X | 1 | 1 | 1 | 0 | 0 | 1 | | 1 | 1 | 1 | 0 | 1 | 1 |
15 | 0 | X | X | 1 | 1 | 0 | 0 | 1 | 1 | | 1 | 1 | 0 | 1 | 1 | 0 |
16 | 0 | X | 1 | X | X | X | X | X | 0 | | X | X | X | X | X | 0 |
17 | 0 | X | 0 | X | X | X | X | X | 0 | | X | X | X | X | X | 1 |
The state variables have the following functions:
Signal E* is the inverse of the E clock required by port processors 106 and 206, and signal E* is employed fay devices U56 and U57 to generate the RAM control signals and to multiplex the addresses from port processors 106 and 206 and VME bus 7;
Signal Q is the Q clock required by port processors 106 and 206; Signal SO is employed (with signals E* and Q) to generate the system clocks in a manner to be discussed below, and is also employed as a clock signal for the CODEC control logic (which comprises programmable logic devices U82 and U83) ; Signals SI and S2 become active during a memory access, and signal S2 is also used by the memory control line decoders U56 and U57 to generate RAM control signals and to clock RAM data into the VME data registers; Signal VDTACK* becomes active immediately following a RAM access to inform the "DTACK" (data transfer acknowledge) signal generator described above that the data transfer is complete;
Signal VRESET is a buffered VME bus reset signal; Signal VRAMSEL* (which denotes either signal
AVRAMSEL* or signal BVRAMSEL*) is active whenever CPU 1 addresses RAM 112 or 212, and is employed to initiate a load of the address counters and to enable the VME bus data buffers; and Signal VDS denotes either signal VDSl (VME data strobe "1") or signal VDSO (VME data strobe "0").
The operation of state machine U36 will next be more fully described with reference to row numbers of Table 9: Row 1: when VRESET is high, all state variables are set to the indicated values;
Rows 2 through 8 : E*, Q, and SO form a "divide by eight" Gray code counter, and E* and Q provide the overlapping 2MHz clocks required by port processors 106 and 206; Rows 9 and 10: state machine U36 checks for a request for a RAM access from VME bus 7. If no request is pending, signals S1 and S2 remain inactive, so that any access by the VME master is deferred until the RAM is unused by the relevant port processor;
Rows 11 through 14: if a VME access is requested, S1 will go low for four cycles and S2 will go low for two cycles;
Row 15: following the RAM access, VDTACK* will go low; and
Rows 16 and 17: VDTACK* will remain low until VDS is inactive.
State machine U36 also generates control signals AREN* and BREN*, which enable data buffers U8, U9, U14, and U15 between RAM units U61, U73, U33, and U47 and the VME bus. Signals AREN* and BREN* will go low during a RAM access for two clock cycles during a read operation (coincident with S2) , or three cycles during a write operation. Table 10 specifies the logical relationships between the input and output signals of device U36:
Table 10 !E = (!E & SO & !VRESET # Q & !SO & !VRESET); !Q = ((!Q & !SO # !E & SO) # VRESET); !SO = ((E & Q # !E & !Q) # VRESET); !S1 = (((((!E & !Q & !SO & !AVRAMSEL & !VRESET & VDSO & VDTACK
# !E & !Q & !SO & !AVRAMSEL & !VRESET & VDSl & VDTACK) # !E & !Q & !SO & !BVRAMSEL & !VRESET & VDSO &
VDTACK)
# !E & !Q & !SO & !BVRAMSEL & !VRESET & VDSl & VDTACK)
# !S1 & !S2 & !VRESET) # !S1 & !Q & !VRESET); !S2 = !S1 & !Q & !VRESET; !VDTACK = ((!S1 & S2 & Q & !VRESET
# !VDTACK & VDSO & !VRESET)
# !VDTACK & VDSl & !VRESET) !AREN = (!S2 & !AVRAMSEL # Q & iSl & !AVRAMSEL &
VWRITE); !BREN = (!S2 & !BVRAMSEL # Q & !Sl & !BVRAMSEL &
VWRITE); Devices U56 and U57 decode the state variables from device U36 to generate all the control signals for access to the "Port A" RAM comprising U61 and U73, and to the "Port B" RAM comprising U33 and U47. These control signals include the following:
ARDIR and BRDIR, which determine the direction of transfer, with a low level indicating a write and a high level indicating a read (Each of these signals is determined either by the write line of the port processor ("AMRW" or "BMRW") or the VME bus write signal "VWRITE") . Which source is used depends on the state of signal E*. When signal E* is low, the port processor has access to the RAM, and AMRW (or BMRW) determines the direction. On alternate cycles, VWRITE determines the direction);
VLEN*, which enables the VME data latches U5 and U10, and is active following a read by the VME bus master;
AENML*, AENMH*, BENML*, and BENMH*, which enable data buffers U20, U27, U19, and U26, respectively, between the RAMs and the port processors, with AENML* (BENML*) enabling the low byte when RAM is selected by the port processor, E* is low, and AMAO (BMAO) is low, and AENMH* (BENMH*) enabling the high byte when AMAO (BMAO) is high;
AROE* (BROE*) which is the output enable for the RAM, and is gated by E*, just as is ARDIR (BRDIR) , but has opposite sense; and
ARWRL* and ARWRH* (BRWRL* and BRWRH*) , which enable the operation of writing one byte of data to RAM 112 (212). During a port processor write operation (when E is low, and MRW is low) , a two cycle write pulse is generated for either the high byte or low byte, depending on AMAO (BMAO) . During a VME write operation, either the high or the low byte, or both, may be written, depending on the state of VDSl and VDSO. Table 11 specifies the logical relationships between the input and output signals of both device U56 and identical device U57:
Table 11 !RDIR = (!E & !MRW # E & VWRITE); !VLEN = !VDTACK & !VWRITE; !ENML = !E & MAO & !MRAMSEL; !ENMH = !E & !MAO & !MRAMSEL; !RWRL = (!E & SO & !MRAMSEL & MAO & !MRW # !S2 & VDSO & VWRITE & !VRAMSEL) ; !RWRH = (!E & SO & !MRAMSEL & !MA0 & !MRW # !S2 &
VDS1 & VWRITE & !VRAMSEL) ; !ROE = (!E & MRW # E & !VWRITE) ;
A RAM access by one of the port processors is straightforward. During the half cycle of E* in which the port processor has access, one port data buffer
(U20, U27, U19, or U26) is enabled, and one byte, even or odd, is either written or read, depending on the states of AMAO (BMAO) and AMRW (BMRW) . The port processor is never delayed in accessing the RAM.
The VME bus master (CPU 1) may be delayed for as much as one cycle of E* while accessing one of the RAMs.
During a read, the RAM data is enabled onto lines VD00- VD15 and latched by units U5 and U10. After the data is latched, U8 and U14 are disabled, U5 and U10 are enabled, and VDTACK* goes low, signalling that data is available to the VME bus. During a write, the data is simply written to the RAM in the same manner as during a port processor write. Data is latched during a read operation because the VME bus is asynchronous, so that data must be held until the VME bus master (CPU 1) signals that the data is no longer needed.
Figure 4 is a schematic diagram of port processor 106 and digital signal processor 110 of Figure 1. Because processors 106 and 110 are identical to processors 206 and 210, respectively, and are interconnected with interface 114, RAM unit 112, RAM arbiter 108, slave unit 102, and interrupter unit 104 in the same manner as processors 206 and 210 are interconnected with interface 214, RAM unit 212, RAM arbiter 208, slave unit 102, and interrupter unit 104, no separate diagram of processors 206 and 210 is provided.
Port processor 106 includes processor U87 (which preferably is a 2MHz Motorola 6809 integrated circuit) for performing all port processing operations other than speech compression and reconstruction, including data transfers, telephone line interface operations, and call progress detection operations. Processor has access to the resources described below with reference to devices U72, U77, and U85 of Fig. 4.
The port processor address (AMA4-AMA15) is decoded by programmable logic device U72 (which is preferably a PAL12L10 integrated circuit). Table 12 specifies the logical relationships between the input and output signals of device U72: Table 12 !AMIVSEL = AMA15 & !AMA14 & !AMA13 & !AMA12 & !AMA7
& !AMA6 & !AMA5 & AMA4; !AMTIRQ = AMA15 & !AMA14 & !AMA13 & !AMA12 & E & AMA7 & !AMA6 & !AMA5 & !AMA4 & !AMRW; !AMBUFSEL = AMA15 & !AMA14 & !AMA13 & !AMA12 & !AMA7
& !AMA6 & AMA5 & AMA4 ; !AMSWCS = AMA15 & !AMA14 & !AMA13 & !AMA12 & !AMA7
& !AMA6 & AMA5 & !AMA4 & AMRW; !AMVIACS = AMA15 & !AMA14 & !AMA13 & !AMA12 & !AMA7
& !AMA6 & !AMA5 & !AMA4; !ADTMFIN = AMA15 & !AMA14 & !AMA13 & !AMA12 & !AMA7
& AMA6 & AMA5 & AMA4 & AMRW; !AMCODRD = AMA15 & !AMA14 & !AMA13 & !AMA12 & !AMA7 & AMA6 & !AMA5 & !AMA4 & AMRW;
!AMCODWR = AMA15 & !AMA14 & !AMA13 & !AMA12 & E & !AMA7 & AMA6 & !AMA5 & !AMA4 & !AMRW; !AMRAMSEL = AMA15 & AMA14 ;
"Versatile interface adapter" ("VIA") U77 is preferably a Rockwell International A6522A integrated circuit, which performs timing and interrupt functions as well as I/O for the telephone line interface unit 114 (to be discussed below with reference to Figure 5). VIA U77 also functions as the central component of the interrupt structure of port processor 106.
Input signals AMINT and ATINT to VIA U77 are, respectively, the interrupt signals from digital signal processor 110 and the VME bus master (CPU 1). The active edge of these interrupts may be programmed by device U87. When either of these interrupts occurs, the AMIRQA output signal of VIA U77 becomes active. The CODEC timing (to be discussed below with reference to Fig. 5) also asserts a fast interrupt once every 125 microseconds on input line AFIRQ* to device U87, indicating that the CODEC requires service. Port processor U87 has access to eight status bits (AMD0-AMD7) via octal port U85, indicating respectively: the port ID number (0= Port A, 1= Port B) allowing the port to identify itself as "Port A" or "Port B", Slot ID numbers 0 through 3 identifying the slot into which the PCI unit 3 is installed, and phone interface switch bits ASW1 through AS3 representing the state of the three telephone interface switches S1-S3 shown in Figure 5 (these bits are compared with the requirements of the software installed in U87).
Digital signal processor 110 includes processor U1 (sometimes referred to as "DSP" U1), which preferably is a TMS32010 integrated circuit. U1 accepts data from port processor U87 via a buffer to be described below. The DSP address (ATA0, ATA1, ATA7, ATA8, ATA9,
ATA10, and ATA11) is decoded by programmable logic device U13 (which preferably is a PAL 16L8 integrated circuit). Table 13 specifies the logical relationships between the input and output signals of device U13: Table 13 !ATBUFSEL = !ATA11 & !ATA10 & !ATA9 & !ATA8 & !ATA7 &
ATA1 & !ATAO; !ATINT = (!ATA11 & !ATA10 & !ATA9 & !ATA8 & !ATA7
& !ATA1 & !ATA0 & !ATWEN # ATNINT); !ATNINT = (!ATA11 & !ATA10 & !ATA9 & !ATA8 & !ATA7
& !ATA1 & ATA0 & !ATWEN # ATINT); !ATROMSEL = !ATA11 & !ATA10 & !ATA9 & !ATA8 & !ATA7 & !ATMEN; !ATRAMSEL = ((((ATA11 # ATA10) #ATA9) #ATA8) #ATA7); enable NC = 0;
Signal ATBUFSEL* is active when DSP U1 addresses the DSP buffer, signal ATINT is the port processor interrupt (DSP U1 may interrupt port processor U87 by asserting this line, and DSP U1 may set and reset signal ATINT), signal ATRAMSEL* is active when DSP U1 addresses its program RAM units (U54 and U67), and signal ATROMSEL* is active when DSP 1 addresses its boot ROM units (U7 and U67).
DSP U1 has access to RAM units TJ54 and U67, each. RAM unit having capacity to store 8K eight-bit words. In the Fig. 4 embodiment, DSP U1 has a memory address space with only 4K capacity. Accordingly, DSP U1 has access to two banks of RAM, which are selectable by port processor U87. Programs are loaded into RAM units U54 and U67 by DSP U1 under the control of port processor U87.
DSP U1 also has access to ROM units U2 and U7, each of which is preferably a PROM with capacity to store 512 eight-bit words. ROM units U2 and U7 preferably contain boot code to test DSP subsystem 110, to download code from port processor U87 and upload code to port processor U87, and to execute code in program RAM.
Port processor U87 communicates with DSP U1 through a 256 byte data buffer, comprising 2K x eight-byte RAM unit U80, programmable logic unit U39, an eight-bit counter including devices U75 and U81, data buffers U46 and U66, and data register U53. Unit U39 provides timing and control for unit U80 and all control signals for the data buffer between port processor U87 and DSP U1, and is addressed as a single location in the address space of both processors U87 and U1. The address for buffer RAM U80 is provided by an eight bit counter, preferably comprising two synchronous four-bit counters U75 and U81 (which may be Texas Instruments Inc. SN74S163 integrated circuits) connected as shown in
Figure 4. This counter may be explicitly loaded by port processor U87, and will increment with every buffer access. A series of reads from the same location (by either processor U87 or U1) will read a series of sequential data bytes in buffer RAM U80. Port processor U87 may also read up to four sequential locations, starting with [AMA2, AMA1, AMA0] = [0, 0, 0], to retrieve four sequential bytes from buffer RAM U80.
The buffer comprising devices U80, TJ39, U75, U81, U46, U66, and U53 provides a purely simplex communications path between processors U87 and U1. Only one of processors U87 and U1 may access the buffer at a time. Typically, one processor will fill the buffer, signal the other processor, and then wait for a signal before accessing the buffer again.
Circuit U39 generates the following signals: ACNTLD*, the load signal to the buffer address counters U75 and U81 (processor U87 may load an address into the counters by writing to the buffer address space with AMA2 high); ACNTCLK, the clock signal to address counters U75 and U81 (A rising edge will occur at the end of every access by either processor U87 or U1, incrementing the counter. The counter will also be clocked during a load operation); ATBRD*, when low, will enable data buffer U46 to DSP U1; ATBWR*, when low, will enable register U53 during a DSP write to the buffer (the buffer is loaded from the data bus connecting DSP U1 with U46 and U53, on every rising edge of signal ATCLK); AMBEN*, which enables data buffer U66 to port processor U87 (the direction of this buffer is controlled by signal AMRW) ; ARAMWR*, the write signal to RAM U80 (which is active whenever processor U87 or U1 writes to RAM U80) ; and ARAMEN*, which enables RAM U80 outputs, and will be active whenever DSP U1 or port processor U87 reads from RAM U80.
Table 14 specifies the logical relationships between the input and output signals of device U39: Table 14 !CNTLD !AXCNTLD; !ACNTCLK = (((E & !AMBUFSEL # !AMBFN) # !ATBWR) # !ATDEN & !ATBUFSEL); !ATBRD !ATDEN & !ATBUFSEL; !AXCNTLD = (E & !AMBUFSEL & AMA2 & !AMRW #AXCNTLD & !ACNTCLK); !ATBWR (!ATBUFSEL & !ATWEN # !ARAMWR & !ATBWR); !AMBEN (E & !AMBUFSEL & !AMA2 # !ARAMWR & !AMBEN) ; !ARAMWR (E & !AMBUFSEL & !AMA2 & !AMRW # !ATBUFSEL & !ATWEN) ; !ARAMEN (E & !AMBUFSEL & !AMA2 & AMRW # !ATBUFSEL
& !ATDEN) ; Device U39 is designed to maintain a strict precedence relation among several pairs of signals, in order to guarantee hold times when required. In the following pairs of signals, a rising edge on the first will always precede a rising edge on the second: ARAMWR*, ATBWR*; ATBWR*, ACNTCLK; ARAMWR*, AMBEN*; AMBEN*, ACNTCLK; and ACNTCLK, ACNTLD*.
Figure 5 is a schematic diagram of interface unit 114 of PCI unit 3. Unit 214 is identical to unit 114, and is interconnected with units 206, 208, 210, 212, 102, and 104 in the same manner as unit 114 is interconnected with units 106, 108, 110, 112, 102, and 104. Accordingly, a separate diagram of unit 214 would duplicate Figure 5, and is not provided.
Interface unit 114 includes CODEC U104, which preferably is a Model TP3051 parallel access mu-Law CODEC (available from National Semiconductor) capable of digitizing incoming analog signals at the rate of 8000 eight-bit samples per second. All timing and control for interface unit 114 is generated by counter U82 and programmable logic device U83 (shown in Figure 3). In the Fig. 3 embodiment, the control signals output by device U83 not only serve to control CODEC U104 of interface 114, but the corresponding identical CODEC of interface 214. Counter U82 is preferably a Texas Instruments Inc. SN74393 integrated circuit, and device U83 is preferably a PAL16R6 integrated circuit.
The output signals generated by device U83 are: CDCLK and S2, two state variables output by a "divide by four" counter (the clock for device U83 has frequency 4MHz, so that signals CDCLK and S2 have frequency 1MHz), with signal CDCLK used by CODEC U104 to drive its switched capacitor filters, and by device U82 to create a 125 microsecond sampling period; CDXFER*, which indicates to CODEC 104 that a read or write transfer is about to take place (two pulses of signal CDXFER* occur every 125 microsecond); LATCHOUT, which clocks data from CODEC 104 into register U95 (shown in Figure 5) once every 125 microsecond during the data transfer process; LATCHIN*, which enables data from register U91 (shown in Fig. 5) onto the CODEC data bus (port processor U87 loads the data into register U91, and the data enabled onto the CODEC data bus is loaded onto CODEC U104); FIRQ*, which sets an RS latch which issues a fast interrupt request to port processor U87 (FIRQ* goes low every 125 microseconds); and CNTRST, the inverse of FIRQ*, which is used to asynchronously reset the external counter.
Signals CDXFER*, LATCHOUT, LATCHIN*, FIRQ*, and CNTRST are outputs of a state machine described by the state transition table shown in Table 15: Table 15
PRESENT STATE NEXT STATE
L L L L
C A A C A A
V D T T C D T T C R b X C C F N X C C F N C E e F H H I T F H H I T D S g E O I R R E O I R R C E i R u N Q S R U N Q S L S T n * T * T * T * * T K 2
1 | 1 | X | X | X | X | X | X | | 1 | 1 | 1 | 1 | 0 | | X | X |
2 | 0 | 0 | 1 | 1 | 1 | 1 | 0 | | 1 | 1 | 1 | 1 | 0 | | X | X |
3 | 0 | 1 | 1 | 1 | 1 | 1 | 0 | | 0 | 1 | 1 | 0 | 1 | | 0 | 0 |
4 | 0 | X | 0 | 1 | 1 | 0 | 1 | | 0 | 1 | 1 | 0 | 1 | | 1 | 0 |
5 | 0 | X | 0 | 1 | 1 | 0 | 1 | | 1 | 1 | 0 | 0 | 1 | | 1 | 1 |
6 | 0 | X | 1 | 1 | 0 | 0 | 1 | | 1 | 1 | 0 | 0 | 1 | | 0 | 1 |
7 | 0 | X | 1 | 1 | 0 | 0 | 1 | | 1 | 1 | 1 | 0 | 1 | | 0 | 0 |
8 | 0 | X | 1 | 1 | 1 | 0 | 1 | | 1 | 1 | 1 | 0 | 1 | | 1 | 0 |
9 | 0 | X | 1 | 1 | 1 | 0 | 1 | | 0 | 1 | 1 | 0 | 1 | | 1 | 1 |
10 | 0 | X | 0 | 1 | 1 | 0 | 1 | | 0 | 0 | 1 | 0 | 1 | | 0 | 1 |
11 | 0 | X | 0 | 0 | 1 | 0 | 1 | | 1 | 0 | 1 | 0 | 1 | | 0 | 0 |
12 | 0 | X | 1 | 0 | 1 | 0 | 1 | | 1 | 1 | 1 | 1 | 0 | | 1 | 0 |
Table 16 specifies the logical relationships between the input and output signals of device U83:
Table 16 !CDCLK = (S2 # VRESET); !S2 = (! CDCLK # VRESET); ! CDXFER = ( ( ( ! CNT7 & CNT6 & CNT5 & CNT4 & CNT3 & ! CNT2 & CNT1 & CNT0 & !VRESET # ! CDCLK & !S2 & ! CDXFER & LATCHOUT & LATCHIN & !FIRQ & !VRESET) # ! CDCLK & ! S2 & CDXFER & LATCHOUT & LATCHIN & ! FIRQ & !VRESET) # CDCLK & S2 & ! CDXFER & LATCHOUT & LATCHIN & !FIRQ & !VRESET); !LATCHOUT = (CDCLK & S2 & ! CDXFER & LATCHOUT & LATCHIN & !FIRQ & !VRESET # ! CDCLK & S2 & ! CDXFER & iLATCHOUT & LATCHIN & !FIRQ & !VRESET); !LATCHIN = (CDCLK & !S2 & ! CDXFER & LATCHOUT & LATCHIN & !FIRQ & !VRESET # CDCLK & S2 & CDXFER & LATCHOUT & !LATCHIN & !FIRQ & !VRESET); !FIRQ = ((((!CNT7 & CNT6 & CNT5 & CNT4 & CNT3 & ! CNT2 & CNT1 & CNTO & !VRESET # !S2 & LATCHOUT & LATCHIN
& !FIRQ & !VRESET) # S2 & CDXFER & LATCHOUT &
!LATCHIN & !FIRQ & !VRESET) # CDCLK & S2 & ! CDXFER & LATCHOUT & LATCHIN & !FIRQ & !VRESET); ! CDCLK & S2 S ! CDXFER & ! LATCHOUT & LATCHIN & !FIRQ & !VRESET); ! CNTRST = FIRQ.
Port processor U87 writes to CODEC 104 by loading CODEC input register U91 with PCM or control data following the 8KHz interrupt (signal FIRQ). At the next 8KHz interrupt, this data is then loaded into CODEC 104. At the same time, data may be transferred from CODEC output buffer U95. Data in buffer U95 may be read at any time by port processor U87.
The analog input stage of CODEC 104 (in its Model TP3051 embodiment) is configured as an inverting amplifier. Inputs VFXI+ and VFXI- are the non-inverting and inverting inputs, respectively, to an op-amp within of CODEC 104. Signal GSX is the feedback output of the op-amp. VFXI+ is grounded, and 22,100 Ohm feedback resistor R89 and 22,100 Ohm input resistor R88, set the input gain to equal -(R89)/R88 = -(1). With such input gain, the maximum signal level allowed at the input of the inverting amplifier configuration, measured at R88, is (+/-)2.5 V. The analog output from CODEC 104 is signal VFRO. This output is capable of driving a 600 ohm load to (+/-)2.5 V. Line VFRO is capacitively coupled to hybrid circuit 200 (to be discussed below) via a 0.1 microfarad capacitor C94.
Hybrid circuit 200 includes two op-amps U103 and passive components as shown in Fig. 5. The purpose of circuit 200 is to merge the transmitted signal from CODEC U104 onto the two wire telephone pair and to extract the received signal (to be forwarded to CODEC U104) from the two wire telephone pair. In order to approximately match the full range of typical telephone line impedances, hybrid circuit 200 shown in Fig. 5 is designed to offer greater than 20dB of transhybrid loss over the spectrum of typical telephone lines.
Received signals from the telephone interface are present at the secondary of isolation telephone interface transformer T1. The transmitted voice signal from CODEC U104 is fed to a gain stage comprising the upper op-amp U103 in Fig. 4, resistor R85, capacitor
C90, and resistor R83. The output of this gain stage drives resistor R77 and telephone interface transformer T1.
The received signal at the secondary of transformer T1 is fed to the gain stage comprising the lower op-amp 103 in Fig. 5, resistors R78 and R79, capacitor C86, and resistor R82. Received voice signals are transmitted through capacitor C91 to CODEC U104, and received DTMF signals are transmitted through capacitor C78 to DTMF detection device U102 to be discussed below.
Interface 114 is capable of interfacing with Loop, Reverse Loop, and E&M telephone lines. In order for the telephone interface to satisfy the FCC dielectric strength requirement that less than 10mA flow to ground when 1000 or 1500 VAC is applied across any and all conductive points external to the system, the following components of interface 114 should be selected from those commercially available which meet such dielectric strength standard: transformer T1, optoisolators U107, U100, U106, U105, U02 , U96, and U108, relays K3 and K4, and switches S1, S2, and S3.
V130LA5 Metal Oxide Varistors RV3 and RV4 are provided between ground and the Ring and Tip lines, respectively, to ensure that interface 114 meets the FCC surge and lightning protection requirements. For the same reason, V68ZA2 Metal Oxide Varistors RV1 and RV2 are provided between ground and the EAR and MOUTH lines, respectively.
The audio path is always connected to the Tip and Ring lines, through transformer T1 and capacitor C100. The DC path can be switched between Tip/Ring and Ear/Mouth by means of switch S3. Relays K3 and K4 can be operated independently to control On-Hook and Off-Hook conditions. The termination block comprises switches S1 and S2, termination impedances, and battery, ground, and current sensors. Each current sensor includes an optoisolator.
Capacitor C102 and resistor R90 are connected in series with optoisolator U108. In parallel with this circuit is transformer T1 in series with capacitor C100. Resistor R90 and capacitor C102 provided a desired amount of current through optoisolator U108 during ringing. The current through U108 is converted to a voltage for ring signal detection. When current is not flowing through U108, resistor R93 pulls terminal 5 of device U108 high. When a correct ring voltage is being detected, U108 will begin conducting between terminals 4 and 5. Since pin 4 of U108 is grounded, the voltage at terminal 5 of U108 is pulled low. When the voltage at terminal 5 of U108 reaches a TTL logic low, pin 5 of buffer U93 (line ARI) goes low. The signal on line ARI is supplied to VIA U77 (shown in Figure 4).
PCI unit 3 is designed to meet the requirements of the Loop Start, Ground Start, DID, and E&M telephone signalling standards, and may be connected to either end of a telephone line (the station or office end). Switches S1, S2, and S3 are controllable to provide the necessary hardware interface for any of the configurations mentioned in the preceding sentence, as shown in Table 17:
Table 17
Switch Positions S1 S2 S3
Loop Start
Station End A A A
Office End
(Battery Interrupt) B A A
(Battery Reversal) B B A
Ground Start
Station End A B A
Office End B A A
DID
Station End B B A
Office End A A A
E&M Type I
(Side A) B B B
(Side B) B A B
Octal port U85 (discussed above with reference to Figure 4) receives switch status signals ASW1-ASW3 from switches S1, S2, and S3, respectively.
Signalling relays K3 and K4 are driven by transistor drivers Q4 and Q3, respectively. Relays K3 and K4 are controlled by programmable logic device U89. During normal operation, signal A6809 is high, giving control of the relays to port processor U87 via signals ARLY1 and ARLY2. When signal A6809 is low, control of the relays is given to the VME bus master (CPU 1). The VME bus master may set the relays to a desired state determined by the state of signal AOFFH and the state of switches SI, S2, and S3.
As an example, operation of the phone line interface will be described for the case that the positions of switches SI, S2, and S3 have been set in positions A, A, and A, respectively, for Loop Start
(Station End) operation. In this configuration, when "On hook", both relays K3 and K4 are deenergized (in their "zero" position), and when PCI unit 3 initiates a call (i.e., goes "Off-hook") relays K3 and K4 are energized (in their "one" position). Optoisolatprs U106 and U105 are employed to determine distant end status. When the distant end is On-hook, and if Tip and Ring are connected correctly, line AFLOOP (connected to terminal 5 of device U105) will be conducting (On), and line ARLOOP (connected to terminal 5 of device U106) will not be conducting (Off). Table 18 indicates the status of lines ARLOOP and AFLOOP under various distant end conditions when the local end (PCI unit 3) is Off-hook:
Table 18
Tip and Ring Tip and Ring
Reversed Normal
ARLOOP AFLOOP ARLOOP AFLOOP
Off-hook 0 1 1 0
Battery Reversal CO 1 0 0 1
On-hook
Battery Interruption
CO On-hook 1 1 1 1
Normal CO
On-hook 0 1 1 0 In Table 18, the abbreviation "CO" refers to the central office.
Table 19 specifies the logical relationships between the input and output signals of device U89: Table 19
ARCTL1 = ! (A6809 & !ARLY1 # !A6809 & !AOFF & !ASW2 & !ASW3 # !A6809 & !AOFF & ASW1 & ASW3 # !A6809 & ASW1 & !ASW2 & ASW3 # !A6809 & AOFF & ASW1 & ASW2 & !ASW3);
ARCTL2 - ! (A6809 & !ARLY2 # !A6809 & iAOFF & !ASW1 & !ASW3 # !A6809 & !AOFF & !ASW2 & !ASW3 # !A6809 & !AOFF & ASW1 & ASW3 # !A6809 & AOFF & ASW1 & ASW2).
The loop current through the telephone line must be accurately determined to facilitate distant end Off-hook detection. This detection operation must occur over a range of central office (CO) battery voltages and a range of loop resistances. The loop current is monitored by VIA U77 (shown in Figure 4), by monitoring the state of signals AFLOOP and ARLOOP, which are sent from optocouplers U105 and U106 to VIA U77.
Interface unit 114 of PCI unit 3 includes a dedicated dual tone multi-frequency (DTMF) detector, comprising a bandsplit filter U102 (preferably an AMI 3525 bandsplit filter) for separating the two tone groups used for DTMF signalling, and a DTMF decoder U101 (preferably a Mostek 5103 DTMF decoder). Crystal clock Y3 supplies a 3.58 MHz clock signal to oscillator terminals 16 and 17 of U102, for internal use within U102 and for generating the CKOUT clock signal which emerges form terminal 18 of U102. In an embodiment including a second port (Port B), a counterpart to clock Y3 need not be included in such second port. Rather, signal CKOUT may be supplied to the oscillator terminals of such second port's counterpart to device U102. DTMF decoder U101 generates an interrupt to port processor U87 whenever a valid DTMF digit is detected, and this interrupt is transmitted to device U87 on line ADTMF. When a valid digit is detected, the data is latched into output buffer U65, and does not change until the next valid digit is detected. Port processor U87 may read the output data by addressing output buffer U65 (which preferably is a Texas Instruments SN74S299 register). It is possible to connect the audio path from one port to the other using audio loopback relay K5 and the associated passive circuitry (shown in Figure 3) . Relay K5 is preferably a DPST relay connecting both audio paths to the passive network comprising transistor Q5, which provides about 30 dB attenuation from one port to the other. Relay K5 may be controlled by port processor U87.
Figures 2-5 include references to "Sheets 1-6". Sheet 1 corresponds to Figure 2, sheet 2 corresponds to Figure 3, sheet 3 corresponds to Figure 4, sheet 4 corresponds to a counterpart to Figure 4 (which counterpart would be identical to Figure 4 except that it would show port processor 206 and DSP 210 of Port B, rather than port processor 106 and DSP 110 of Port A), sheet 5 corresponds to Figure 5, and sheet 6 corresponds to a counterpart to Figure 5 (which counterpart would be identical to Figure 5 except that it would show interface 214 of Port B, rather than identical interface 114 Port A). A preferred embodiment of CPU 1 will next be described with reference to Figures 6 and 7. CPU 1 performs all system processing for the inventive voice processing system. CPU 1 appears to VME bus 7 as a master with 16 bit and 8 bit data transfer capability and 24 bit addressing capability. The circuitry supporting the VME bus supervisory functions includes system clock driver 15, bus arbiter 17, IACK daisy chain driver 19, and bus timer 21.
Address decoding is implemented with to programmable logic devices U107 and U300. Device 107 generates the following signals: VM*, which is active when accessing a device on VME bus 7; SHORT*, which is active when addressing the short address space of VME bus 7 this signal is used to change the VME address modifier to indicate that the current access uses only
16 bits of address; ROM*, which is active when accessing ROM units U302 and U502; MMU*, which is the chip select for memory management unit 31; DuART, which is the chip select for DUART U207; PARA, which is the chip select for parallel interface and timer unit U206; SCSI*, which is the chip select for the SCSI subsystem; and UART*, which is active when accessing any of several devices configured as "VPA" devices, including the modem, the real time clock, the floppy disk subsystem reset, and the VME bus release. Table 20 specifies the logical relationships between the input and output signals of device U107:
TABIE 20
UART = ! (!MALL & !PA12 & !PA13 & PA14 & PA15 & PA16 & PA17 & PA18 & PA19 & PA20 & PA21 & PA22 & PA23 & !PAS);
SCSI = ! (!MALL & PA12 & PA13 & !PA14 & PA15 & PA16 & PA17 & PA18 PA19 & PA20 & PA21 & PA22 & PA23 & !PAS);
PARA - ! (!MALL & !PA12 & PA13 & !PA14 & PA15 & PA16 & PA17 & PA18 & PA19 & PA20 & PA21 & PA22 & PA23 & !PAS); DUART = ! (!MALL & PA12 & !PA13 & !PA14 & PA15 & PA16 & PA17 & PA18
& PA19 & PA20 & PA21 & PA22 & PA23 & !PAS);
MMU = ! (!MALL & !PA12 & !PA13 & !PA14 & PA15 & PA16 & PA17 & PA1 & PA19 & PA20 & PA21 & PA22 & PA23 & !PAS); RCM = ! (!MALL & !PA17 & !PA18 & !PA19 & !PA20 & !PA21 & IPA22 &
!PA23 & !PAS) ;
SHORT = ! (!MALL & !PA15 & PA16 & PA17 & PA18 & PA19 & PA20 & PA21 &
PA22 & PA23 & ! PAS) ;
VM = ! ( !PA22 & PA23 & ! PAS
# PA22 & !PA23 & !PAS
# !PA21 & PA23 & ! PAS # PA21 & !PA23 & ! PAS
# !PA20 & PA23 & !PAS
# PA20 & !PA23 & !PAS
# !PA19 & PA23 & !PAS
# PA19 & !PA23 & !PAS # !PA18 & PA23 & !PAS
# PA18 & !PA23 & !PAS
# !PA17 & PA23 & !PAS
# PA17 & !PA23 & !PAS
# !PA16 & PA23 & !PAS # !PA15 & PA23 & !PAS)
Device U300 generates device select signals for all the eight bit peripherals ("VPA" devices) which are accessed in the same manner as 6800 peripherals (i.e., synchronous with the E clock) . Each such acces cycle is initiated when VPA* is asserted to system processor U201 (which is preferably a Motorola MC68010 integrated circuit) in response to a valid address. Processor U201 will then assert signal VMA in response. Each transfer to or from the peripheral must be synchronous with clock E.
Device U300 generates the following device select signals: MODEM*, which is the chip select for modem controller U303; RTC*, which is the chip select for real time clock U604; MRST*, which is the reset for the floppy disk subsystem controller (this is one output of a latch which preferably may be set or reset under software control); and MRLS*, which releases VME bus 7 under software control (this is also an output of a latch which preferably may be set or reset under software control. Table 21 specifies the logidal relationships between the input and output signals of device U107 :
TABLE 21
MODEM = ! ( !UART & !A6 & !A7) ;
ETC = ! ( !VMA & A6 & !A7) ;
MRST = ! ( ! ( 1UART & !A6 & A7 & A1) & NMRST & RST) ;
NMRST = ! ( ! ( !UART & !A6 & A7 & !A1) & MRST # !RST) ;
MRIS = ! ( ! ( 1UART & A6 & A7 & Al) & NMRIS & RST) ;
NMRIS = ! ( ! ( !UART & A6 & A7 & !A1) & MRIS # !RST) ;
EMRST = !NMRST;
Control signals are generated by programmable logic device U301 and logic devices 201, 202, and 203. Device U301 generates the following signals: VME*, which is active whenever a VME bus access is requested by system processor U201 or when a VME bus interrupt request is being acknowledged; PAS*, which is a physical access strobe signal, and is active when address strobe AS* from processor U201 and address strobe MAS* from memory management unit U202 (which is preferably a Motorola MC68451 integrated circuit) are both active; DSI, which is active when either the upper or the lower data strobe is active; RIN, which is used to qualify the data strobes to create the physical data strobes, and is active when RW* is low (indicating a write cycle) and WIN* (the write inhibit from U202) is low (indicating an attempt to write to a protected segment); and bERRST, which resets the bus error timer (the timer begins counting when a bus cycle begins, indicated by AS*,
DS0*, or DS1* going low, and is reset when all of these signals go high). Table 22 specifies the logical relationships between the input and output signals of device U301:
TABLE 22
VME = ! (VIACK # !VM) ;
PAS = !(!AS & !MAS);
DSI = (!IDS # !UDS); RIN = (!RW & !WIN);
BERRST = ! (!AS & RST # !DS0 & RST # !DS1 & RST);
Logic devices 201, 202, and 203 generate the following signals: address strobe MAS*, which is generated by open collector driver 201 coupled to line MALL emerging form U203 (when signal MAS* is driven low, device U202 is prevented from performing an address translation. This occurs during an interrupt acknowledge); ALL, which is also generated by open collector driver 201 (signal ALL is driven low during an interrupt acknowledge to prevent U202 from interpreting
the failure to translate the address as a fault); PLDS*, which is generated by circuit 202 coupled to the control bus of VME bus 7, and prevents a write to protected memory (PLDS* consists of data strobe LDS* qualified by signal RIN); PUDS*, which is also generated by circuit 202; and VPA*, which is generated by circuit 203, and is a valid peripheral address signal indicating to processor U201 that the current cycle is either an access to a 6800 type peripheral, or an autovectored interrupt (in the first case, the data transfer is synchronous to clock E and requires no DTACK* in response; in the second case, processor U201 does not require an externally generated interrupt vector and instead processor U201 uses a dedicated vector for the current interrupt level).
VME bus 7 is asynchronous, so that all transfers require handshaking between the VME bus master (CPU 1) and a slave (each PCI unit 3). The handshaking signals employed in a data transfer are: AS* (address strobe), DS0* and DS1* (data strobe signals), DTACK* (a data transfer acknowledgement signal, the inverse of DTACK), and BERR* (a bus error signal). During a data transfer or interrupt acknowledge, CPU 1 drives AS*, DS0*, and DS1*. All bus control signals are generated by VME bus controller U103 (which preferably is a Model 68172 integrated circuit). Circuit U103 is configured for single master operation, and performs the following functions: 1. It requests access to VME bus 7 when processor U201 addresses the VME bus address space. The onboard processor signals this by bringing VME* and MAS* low. If the bus master does not own bus 7, circuit U103 signals its request by driving BR* low. The bus arbiter (U006) grants this request by driving BGIN* low. U103 then responds by driving BBSY* low and then releasing BR*. CPU 1 nay then access bus 7 normally, If CPU 1 already has ownership of bus 7, bus 7 may be accessed immediately; 2. It releases bus 7 on request. If another bus master requests access to bus 7, bus arbiter U006 will issue a clear command by driving BCLR* low. This line will interrupt CPU 1, which may schedule a time to release bus 7. MRLS* is driven low to signal a bus release to arbiter U006. Arbiter U006 drives RELSE high, signalling U103 to release the bus. U103 does so by releasing BBSY*; 3. It initiates and completes a data transfer by driving VME* and PAS* low. U103 generates the VME bus data strobe (VAS*) and waits for VDTACK* or VBERR* from the VME bus slave. U103 also generates the control signals for the VME bus buffers (to be described below). Responses from the VME bus are regenerated onboard by U103 as LDTACK* and LBERR*.
In addition to controlling and monitoring the VME bus handshake signals directly, U103 generates the following control signals for the VME bus interface: DEN*, which is a data enable for enabling the VME bus buffers (this signal goes low when the VME bus is selected (i.e., VME* and PAS* are low) and DSi is high); DSEN*, which is a data strobe enable, which when low, passes the data strobes to bus 7 (this line will be active when DSI, VDTACK*, and BERR* are high, and VAS* is low); VMEEN*, which is a buffer tri-state control signal which enables the address lines and address modifiers onto the VME bus (it is low whenever CPU 1 owns bus 7); and DDIR, which is a data direction signal which determines the direction of the VME bus data buffers, as specified by signal R/W*.
Bus arbitration is on a fixed priority basis, with level three highest and level zero lowest. Arbitration is accomplished by two state machines implemented by programmable logic device U006: one to grant the bus in response to a bus request ; the other to release the bus in response to a request form CPU 1 to release the bus . The functions of the two state machines are described in Table 23 : TABLE 23
State_Diagram release_bus
State HOLD_BUS: if 1RST then HOLD_BUS else if ! MRIS then RELSE_BUS else HOLD_BUS;
State RELSE_BUS: if ! RST then HOLD_BUS else if BBSY then HOLD_BUS else RELSE_BUS;
State_Diagram grant_bus State IDIE: if (!BBSY # !RST) then IDIE else if !BR3 then GRANT3 else if !BR2 then GRANT2 else if !ER1 then GRANT1 else if !ER0 then GRANT0 else IDIE;
State GRANT3: if (BBSY & RST) then GRANT3 else IDIE;
State GRANT2: if (BBSY & RST) then GRANT2 else IDIE;
State GRANT1: if (BBSY & RST) then GRANT1 else IDIE;
State GRANT0: if (BBSY & RST) then GRANT0 else IDIE.
With reference to Table 23, if bus 7 is under the control of a bus master, indicated by an active level on
BBSY*, RELSE is inactive. If the current bus master is
CPU 1, it will continue to hold bus 7 until it releases it under software control by bringing MRLS* low. RELSE will go active, causing the VME bus interface to release the bus by bringing BBSY* high. The "grant bus" state machine remains in an idle state until a bus request is received. When simultaneous requests are received, bus 7 is granted to the highest priority request. Bus 7 remains under control of the grantee until released by bringing BBSY* high. BCLR* is active whenever a bus request is active, and at that time generates a level six interrupt request to CPU 1. CPU 1 may respond to the bus request at any time after the request is made. CPU may be configured at any of four priority levels by setting jumpers JP1, JP6, and JP7.
Circuit U006 also functions as the VME bus IACK daisy chain driver. Signal IACKOUT* is active when an interrupt acknowledge cycle is underway, as indicated by an active IACKIN* signal. IACKOUT* is qualified with DS0* and VAS*, and is delayed by the system clock SYSCLK, to meet the VME bus specification requiring a 40ns delay from the falling edge of DS0* to the falling edge of IACKOUT*.
Table 24 specifies the logical relationships between the input and output signals of device U006:
TABLE 24
RELSE: = ! (!RST # BBSY & RELSE # MRIS & IRELSE) ;
BG3OOT:= ! (BBSY & BG0OUT & BG1OUT & BG2OUT & !BG3OUT & RST # BBSY & BG0OUT & BG1OUT & BG2OUT & !BR3 & RST) ;
BG2OUT:= ! (BBSY & BG0OUT & BG1OUT & !BG2OUT & BG3OUT & RST # BBSY & BG0OUT & BG1OUT & BG3OUT & !BR2 & BR3 & RST) ;
BG1OUT:= ! (BBSY & BG0OUT & IBG1OUT & BG2OUT & BG3OUT & RST # BBSY & BG0OUT & BG2OUT & BG3OUT & !BR1 & BR2 & BR3 & RST) ;
BG0OUT:= ! (BBSY & !BG0OUT & BG1OUT & BG2OUT & BG3OUT & RST # BBSY & BG1OUT & BG2OUT & BG3OUT & !BR0 & BR1 & BR2 & ER3 & RST) ; IACROUT:= ! (!DS0 & !IACKIN & !VAS) ;
BCXR: = ! (!ER0 # !ER1 # ER2 # !ER3) .
CPU 1 includes system clock unit 204 , including two crystal oscillators , each implemented with two gates of
U601. The frequency of oscillation is twice the required value, and D flip-flop U701 divides each oscillator ' s output frequency by two to ensure a fifty percent duty cycle. The first oscillator has a 20MHz frequency, divided down to 10MHz, and serves as the system clock SYSCLK (used by circuits U201, U202, U103, U206, and U208). The second oscillator has a 32MHz frequency, divided down to 16MHz, and serves as the VME bus clock, which drives all PCI units 3 coupled to bus 7. Either or both of the oscillators may be disabled (to facilitate automated testing) by driving the pulled up inputs to NAND gates U601 low.
Dual four-bit counters U603 and U708 (which are cascaded to form a 16-bit counter, and are preferably Texas Instruments Inc. 74LS393 integrated circuits) serve as a timer for monitoring bus activity. Counters U603 and U708 are driven by the 1 MHz E clock from processor U201. If signal AS*, UDS*, or LDS* goes low, BERRST goes low, allowing the counters to start counting. The counter will continue to count until all of these signals go high. A bus error occurs if the most significant bit goes high.
The VME reset circuit 206 comprising timer U703 and external timing components (resistors R13 and R20, capacitors C19 and C21, and a pair of inverters U602) will cause a system-wide reset on power-up, or when the operator actuates a reset switch SW1. Following power-up, C21 will discharge, holding the trigger and threshold inputs of timer circuit U703 at ground, and forcing circuit U703*s output high. The output of U703 is inverted by one inverter U602, which holds RST* low. The entire system is reset by line RST*, via VME bus reset driver U500. C21 will discharge through R13, preferably with time constant 470 ms. When the voltage on C21 exceeds the threshold of timer U703 (typically 516 ms), timer U703 will reset, releasing RST*. Both RST* and HALT* are held low at power-up as required by processor U201 for a complete reset. The operator may halt processor U201 by actuating hal t switch SW2.
System processor U201 is preferably a Motorola 68010 integrated circuit, and memory management unit U202 is preferably a Motorola 68451 integrated circuit.
A Motorola 68010 integrated circuiϊt is a 32 bit processor with a 16 bit external data hus, D0-D15, and a 24 bit address bus , A1-A23 , plus LDS* and UDS*, and may access individual bytes by asserting both UDS* and UDS* , or 16 bit words by asserting either LDS* or UDS*. Lower order bytes , addressed by LDS* are at add log ical addresses , while higher order bytes, addressed by UDS* , are at even addresses . Words are at even addresses .
Processor U201, in an embodiment in wh ich it is a Motorola 68010 integrated circuit,, is an asynchronous processor, so that every memory or peripheral access (with the exception of a VPA access, (described elsewhere herein) requires a response on line DTACK* . DTACK* may be generated by the addressed device (such ass U202 , U206 , DUART U207 , or the VME bus slave) , or by external circuitry (as in the case of the SCSI controller subsystem including U208 ) , or by t he RDM. The remaining devices assert VPA when addressed.
If U201 receives a bus error, indicated by BERR* low, instead of DTACK*, U201 will enter an exception processing routine to resolve the error, in which U201 halts execution and drives HALT* low. Processor U201 must be reset to exit this state.
Every access by U201 includes a function code, FC0-FC2 , which defines the type of access. The function codes is also passed on to the VME bus in the form of an address modifier. These codes are set forth in Table 25 : TABLE 25
FC[2:0] SHORT AM[5:0] Definition
000 0 $28 Undefined
001 0 $29 Short address user data
010 0 $2A Undefined
011 0 $2B Undefined
100 0 $2C Undefined
101 0 $2D Short address supervisor data
110 0 $2E Undefined
111 0 $2F Reserved (Interrupt acknowledge)
000 1 $38 Undefined, reserved
001 1 $39 Standard address user data
010 1 $3A Standard address user program
011 1 $3B Undefined, reserved
100 1 $3C Undefined, reserved
101 1 $3D Standard address supervisor data
110 1 $3E Standard address supervisor program
111 1 $3F Reserved (Interrupt acknowledge)
The multiple master capability of the 68010 integrated circuit (using lines BR*, BG*, and BGACK*) is not utilized in the preferred embodiment described with reference to Figs. 6 and 7. These lines are preferably unconnected or pulled to an inactive state.
The purpose of memory management unit U202 is to translate the logical addresses form U201 to physical addresses used by the system. This allows U201 to share code, while maintaining separate data spaces.
All memory references in programs executed by U202 will be logical addresses, which appear on lines A1-A23 from U201. Based on function code FC0-FC2, U202 translates the logical address to a physical address in any of four different memory spaces: User data (corresponding to [FC0, FC1, FC2]=001), User program (corresponding to [FC0, FC1, FC2]=010), Supervisor data (corresponding to [FC0, FC1, FC2]=101), and Supervisor program (corresponding to [FC0, FC1, FC2]=110). The signal [FC0, FC1, FC2]=111 indicates and interrupt acknowledge. The FC3 input to U202 is not used, and is tied to ground.
All registers in memory management unit U202 are programmed by U201 following power-up. U201 and U202 communicate via a bidirectional, dual purpose bus AD0-AD15. During normal translation, the physical address appears on this bus, latched by octal D-latches U104 and U105. The gating signal is HAD*, generated by U202. When U201 accesses U202 as a peripheral, AD0-AD15 is used as a data bus. Two bidirectional buffers, U401 and U501, isolate AD0-AD15 and D0-D15> Buffers U401 and U501 are enabled by ED*, generated by U202. The direction of the buffers is controlled by R/W*.
Circuit U202 supports seven prioritized interrupt levels. Interrupt requests are encoded on IPL2* through IPL0*, and INTIRQ*, by programmable logic device U009. Device U009 generates the interrupt acknoledge signals for all system interrupts. These fall into three categories: external vectored interrupts (VIACK); internal vectored interrupts (MIACK*, TIACK*, PIACK*, and DIACK*); and internal autovectored interrupts (AUTO*). Internal interrupts are indicated by INTIRQ* being active (low). Each autovectored interrupt is separately decoded. All other interrupts are assumed to be external VME bus interrupts. The priority rules are: First, higher numbered requests have higher priority; and Second, external (VME bus) requests have higher priority.
Table 26 specifies the logical relationships between the input and output signals of device U009: TABLE 26
TPL2 = !(!ACEAIL # IR7
# ! IRQ7 # ! BCLR # !IRQ6 # ! IR5 # ! IRQ5 # ! IR4 # ! IRQ4);
IPUL = !(!ACEAIL
# IR7
# !IRQ7
# !BCLR
# !IRQ6
# !IR3 & IR4 & IR5 & IRQ4 & IRQ5
# IR4 & IR5 & !IRQ3 & IRQ4 & IRQ5
# !IR2 & IR4 & IR5 & IRQ4 & IRQ5
# IR4 & IR5 !IRQ2 & IRQ4 & IRQ5);
IPLO = !(!ACFAIL
# IR7
# !IRQ7
# BCLR & !IR5 & IRQ6
# BCIR & !IRQ5 & IRQ6 # BCIR & !IR3 & IR4 & IRQ4 & IRQ6
# BCIR & IR4 & !IRQ3 & IRQ4 & IRQ6
# BCIR & !IR1 & IR2 & IR4 & IRQ2 & IRQ4 & IRQ6
# BCIR & IR2 & IR4 & !IRQ1 & IRQ2 & IRQ4 & IRQ6);
INTIRQ = !(!A1 & !A2 & A3 & IRQ4
# !A1 & A2 & !A3 & IRQ2
# !A1 & A2 & A3 & IRQ6
# A1 & !A2 & !A3 & IRQ1
# A1 & !A2 & A3 & IRQ5
# A1 & A2 & !A3 & IRQ3
# A1 & A2 & A3 & IRQ7).
Interrupt acknowledge signals are generated by programmable logic device U203. Each such signal informs the interrupting source that the current cycle is an interrupt acknowledge which requires an interrupt vector on D0-D7 (except in the case of an autovectored interrupt, when U203 asserts AUTO*, which in turn asserts VPA* during the interrupt cycle, causing U201 to fetch the autovectored interrupt service routine address for that level). Signal AUTO* is latched for the duration of the interrupt acknowledge cycle, to ensure that VPA* meets its required hold time from AS*. All other interrupt acknowledge signals are locked out during an autovectored interrupt acknowledge.
Device U203 also generates the signal MALL, which is high during an interrupt acknowledge cycle. MALL prevents any of the device select signals from becoming active during an interrupt acknowledge, and it prevents U202 from attempting to translate the address during an interrupt acknowledge by forcing MAS* low. At the same time, signal ALL (generated in circuit 201, as described above) is forced low to prevent U202 from interpreting the failure to translate the address as a fault. Table 27 specifies the logical relationships between the input and output signals of device U203:
TABIE 27
MALL = (!AS & FC0 & FC1 & FC2);
MIACK = ! (A1 & !A2 & A3 & !AS & AUTO & FC0 & FC1 & FC2 & !INTIQR) ; TTACK = ! (!A1 & !A2 & A3 & !AS & AUTO & FC0 & PCI & PC2 & !INTIQR) ;
DIACK = ! (!A1 & A2 & !A3 & !AS & AUTO & FC0 & FC1 & FC2 & !INTIQR) ;
PIACK = ! (A1 & !A2 & !A3 & !AS & AUTO & FC0 & FC1 & FC2 & !INTIQR) ;
VIACK = (!AS & AUTO & FC0 & FC1 & FC2 & INTIQR) ;
AUTO = ! (!AS & AUTO
# A2 & A3 & !AS & FC0 & PC1 & FC2 & !INTIRQ #A1 &A2 & !AS & PC0 & PC1 & FC2 & !INTIRQ
# !A1 &A3 & !AS & FC0 & FC1 & FC2 & !INTIRQ & !RTCAV # A2 & !AS & FC0 & FC1 & FC2 & !INTIRQ & !SERAV) .
CPU 1 includes two ROM units U302 and U502, preferably having 128K bytes total capacity. In Figure 6, units U302 and U502 are 27256 ROM units, although other types of ROM units (including 2764/27128 and 27512 ROM units) may be substituted for such 27256 ROM units by configuring jumpers JP3. Since processor U201's data bus (D0-D15) has sixteen bits, ROM U502 contains the odd bits and ROM 302 contains the even bits. All reads from ROM will enable both ROM units U302 and U502.
DTACK* for a ROM access is generated by two flip-flops U705 in circuit 208 (shown in Figure 6). When signal ROM* is inactive (high), these flip-flops are set asynchronously. When ROM* goes low, a low level is clocked through these flip-flops in sequence. The DTACK* is thus delayed for a minimum of 100 ns from the falling edge of ROM*. DTACK* will be sampled on the next falling edge of the 10MHz clock, and data will be sampled on the next falling edge after that. Thus, there will be a 250 ns period from the time the ROM's are enabled to the clock edge at which data is sampled. Since a 10 ns setup time is required, the ROM's must have an access time from CS* of less than 240 ns. CPU 1 preferably includes the I/O devices to be described next, with reference to Figure 7. Parallel interface and timer U206 (which preferably is a MC68230 integrated circuit) has the following features: a parallel port (Port A) for communicating with a printer interface; a parallel port (Port B) for communicating with a microdiskette driye controller subsystem; and a 24 bit programmable timer.
U206 automatically generates signal PDTACK* in response to an access from processor U201. Interrupts from device U201 may be from the timer on line IR4* or from the parallel ports on IR1*. A timer interrupt is serviced by driving TIACK* low during an interrupt acknowledge cycle. U206 will place the contents of its internal timer interrupt vector register TIVR on lines D0-D7, A port interrupt is serviced by driving PIACK* low during an interrupt acknowledge cycle. U206 responds with the contents of its internal port interrupt vector register. The last two bits of this register indicate the source of the interrupt. Such an interrupt can occur as a result of an event on any of the handshake lines H1 through H4.
The following lines from U206 are used to implement the parallel printer interface: PA0-PA7, which are the outgoing data lines, and are buffered by buffer U015 to generate DATA1-DATA8 to the printer (Port A is configured as output only, and U015 is always enabled); PC4 (or "PAPER"), which goes high if the paper is out of paper; PC2 (or "BUSY IN"), which goes low when the printer is ready to accept data (the input from the printer is buffered by buffer U16) and may be read by processor U201 through Port C of U206; PC1 (or "SEL IN"), which goes high when the printer is on line (the input from the printer is buffered by buffer U16) and may be read by processor U201 through Port C of U206; PC0 (or "FAULT*), which goes low when the printer has experienced a fault condition (the input from the printer is buffered by buffer U16) and may be read by processor U201 through Port C of U206; H2 (or DSTB*), which goes low to indicate DATA1-DATA8 is valid (typically, U206 will be programmed to configure H2 as an output, and H2 is generated explicitly under program control); and H1 (or "ACK*"), which goes low to indicate that the printer has received data, and may be read through U206's internal storage register. Buffers U15, U16 are preferably 74LS244 integrated circuits. The printer reset, PRST*, may be set via DUART 68681.
The following lines from U206 are used to implement the interface to the microdiskette drive controller ("MDC") subsystem: PB0-PB7, a bidirectional data bus, which is buffered by buffer U205 (preferably a 74LS245 integrated circuit), which buffer is controlled by the MDC subsystem; H4, which is a handshaking signal for data transfers, and may be monitored by the MDC subsystem processor (typically, H4 is programmed to go high when a data byte is received or sent by U201. When this is sensed by MDC processor U403, the MDC processor will respond by accessing the data port, generating a pulse on line FW*. This completes the handshaking sequence, generating an interrupt to U201.); and H3 (FW*), which is the above-mentioned handshaking signal for data transfers.
U206 also includes a 24 bit programmable timer, and may optionally be clocked by a five bit prescaler. The timer operates as a down counter which is loaded from a preload register programmed by U201.
CPU 1 preferably includes an eight position dip switch for configuration, such as switch U102 shown coupled with octal buffer U101 in Fig. 6. The state of the switches is enabled onto D8-D15 whenever U206 is accessed.
The MDC subsystem comprises processor U403 (preferably a 6809E integrated circuit running at 2MHz), 8k x 8 RAM unit U404, 8k x 8 ROM unit U405, 765A floppy disk controller U406, and circuitry for clock generation, address decoding, and interfacing to the microdiskette drive. All communication between the MDC subsystem and processor U201 is through circuit U206.
The E and Q clocks for processor U403 are generated by circuit 220, which includes two flip-flops U607 driven by an 8 MHz clock derived form the 16 MHz system clock using flip-flop U606.
Address decoding and control signal generation are implemented by programmable logic device U506 and decoder U407. Device U506 generates the following signals for the MDC subsystem: FDCRD*, which is the FDC read strobe (and is simply FRW qualified by FE); FDCWR*, which is the FDC write strobe (and is qualified by both E and Q to increase data setup times); FW*, which is the MDC subsystem strobe, and goes active whenever the data port to parallel interface U206 is accessed to generate an interrupt to processor U201; CSEN*, which is the chip select enable, and is used to separate two areas of the MDC subsystem memory map into two sections, based on FA13 (in each of these two areas, CSEN* will always be active when FA15 is high), and to enable decoder U407;
TC, which is the terminal count, and is set high by U403 to signal the end of a data transfer; MOTORON*, which goes low to actuate the microdiskette drive motor; and EJECT*, which causes the diskette to be ejected when low. TC and MOTORON* are implemented as latches, whose operation is explained by the state transition tables set forth as Table 28:
TABIE 28
(FDCU*, FA1, FA0) 000 001 011 010 110 111 101 100
TC 0 | 0* | 0* | 1* | 0* | 0* | 0* | 0* | 0* |
1 | 1* | 1* | 1* | 0 | 1* | 1* | 1* | 1* |
(FDCU*, FA2, FA0)
000 001 011 010 110 111 101 100 MOTORON* 0 | 0* | 0* | 1 | 0* | 0* | 0* | 0* | 0* |
1 | 1* | 1* I 1* | 0 | 1* | 1* | 1* | 1* |
* = Stable Statement
Table 29 specifies the logical relationships between the input and output signals of device U506: TABLE 29
FRAR = ! (F3 & FR_W) ;
FRAW = ! (FE & FQ & !FR_W) ;
FW = ! ( !FQ13 & !FA14 & !EA15 & FE & FQ) ; CSEN = ! ( !FA13 & FE # FA15 & FE) ;
FDCU = ! (FA13 & FA14 & ! FA15 & FE & PQ) ; enable FD7 = (FA13 & !FA14 & !FA15 & FE & FR_W) ;
FD7 = ! ( !H4) ;
TC = ! (!FA1 & !TC # !FA0 & FA1 & !FDCU # FDCU & !TC) ; M-3T0RQN = ! (!FA2 & !MOTORON # !FAO & FA2 & !FDCU # FDCU & !MOTORON);
EJECT = ! (MOTORON & TC) .
The floppy disk controller (FDC) circuit U406 (preferably a 765A integrated circuit) provides control functions and data formatting for the microdiskette drive. Interface circuit U505 (preferably a 9229T integrated circuit) is coupled to U406, and provides data separation and write precompensation. The control lines to the microdiskette are buffered by open-collector devices U012, U304, and U110. Received lines are pulled to VCC with 2.7K resistors.
U406 interfaces to the following control lines: WPROT*, which senses a write protected disk; TRK 0*, which senses track 0 in the seek mode, and in read/write mode (indicated by a low on RW*/SEEK) is forced low to prevent U406 from detecting a fault condition; RDY*, which indicates the microdiskette is ready to receive dat; IDX*, which is the index to the beginning of a disk track; SIDE SEL*, which selects one side of a two-sided diskette; WRITE GATE* , which enables write data to the diskette; DIR*, which sets the seek direction; and STEP*, which is forced high when the FDC is in its read/write mode. In addition to these lines, the following lines (coupled to buffer U012 or U110) are included in the microdiskette interface: RDATA*, which is the raw data read from the diskette drive; WDATA*, which is the MFM encoded data to the diskette drive; DS3*, DS1*, and DS0*, which are drive selects; DEJECT*, which when low, causes the drive to eject the diskette; and DMOTON*, which is allows U403 to turn off the drive motor.
Data separation and write precompensation are performed by interface circuit U505 (preferably a 9229T integrated circuit). U505 also provides clock signals for U406. Clock signal CLKOUT (the write clock to U406) has frequency 1 MHz, and clock signal HLT/CLK (the master clock to U406) has frequency 8 MHz.
FDCSEL and MINI are pulled up, and MFM driven high to configure the microdiskette controller and interface for double density MFM. Write compensation may be set to any value from 0 to 625 ns in 125 ns increments by configuring JP5.
CPU 1 includes an initiator for a Small Computer System Interface (SCSI). SCSI is a standard interface designed to facilitate integration of systems and peripherals, such as disk drives, from many manufacturers. CPU 1's SCSI interface includes SCSI controller U208 (preferably an NCR 5386 SCSI controller chip), which supports arbitration and reselection, and handles all low level protocol and timing. In CPU 1, circuit U208 is configured as an initiator with ID = 7. An initiator establishes a connection with a target to exchange data. Once the connection is established, through an arbitration and selection process, the target controls the entire transaction, requesting commands and data, and returning status in the form of messages. The target may also disconnect from the initiator, and reconnect at a later time. Table 30 lists the registers of U208 (in an embodiment in which is an NCR 5386 circuit):
TABLE 30
Address Register Type Register description
$FFB000 R/W Data Register $FFB002 R/W Command Register $FFB004 R/W Control Register $FFB006 R/W Destination ID
$FFB008 R Auxiliary Status $FFB00A R ID Register $FFB00C R Interrupt Register $FFB00E R Source ID
$FFB012 R Diagnostic Status $FFB018 R/W Transfer Counter (MSB) $FFB01A R/W Transfer Counter (2nd byte) $FFB01C R/W Transfer Counter (LSB)
$FFB01E R/W Reserved
$FFB020 R/W Virtual Port
Access to the SCSI interface is controlled by programmable logic device U011. The main function of U011 (which is preferably a PLS 153A integrated circuit) is as a controller for "DMA-like" access to U208 (where DMA denotes a conventional direct memory access technique). The DMA-like access technique of the invention is implemented in an asynchronous state machine described by the state transition diagram shown in Table 31: TABIE 31
(VPORT*, DREQ)
10 11 01 00
000 | 111 | 101 | 001 | 011 |
001 | 101 | 101 | 001* | 001* |
(DACK*, 011 | 100 | 100 | 100 | 100 | DLYREQ1, 010 | 110 100 | 100 | 110 | DLYREQ2) 110 | 110* 100 | 100 | 110* |
111 | 100 100 | 100 | 100 |
101 | 100 100 | 000 | 000 |
100 | 110 100* | 000 | 010 |
* = Stable State. VPORT* = !SCSI & A5
With reference to Table 31, the SCSI controller (U208) drives DREQ high to request DMA service. Two state variables, DLYREQ1 and DLYREQ2, delay the DMA acknowledge signal (DACK*) until the system processor (U201) accesses the virtual port, VPORT. This signals U208 that. the. transfer is underway. U208 then brings DREQ low in response to DACK*, and at the same time, U011 generates SDTACK* (the SCSI data transfer acknowledge signal) which informs the system processor (U201) that the transfer is complete. When VPORT* goes high, DACK* and SDTACK* go inactive. Signal SDTACK* is generated as a result of DMA acknowledge signal DACK* from U208. If for any reason, DACK* is not asserted after processor U201 attempts to access virtual port VPORT, SDTACK* will remain inactive, and processor U201 will halt execution until the bus times out, generating a bus error.
It is possible to transfer blocks of data through the virtual port using a tight loop of only two instructions. Processor U201 (in an embodiment in which U201 is a 68010 integrated circuit) has an internal cache from which such loops may be executed without accessing main memory. We have recognized that when data transfers are implemented in this way, CPU 1 can maintain an extremely high data transfer rate in excess of 500,000 bytes per second. Such data transfer rate is greatly in excess of the data rate achievable using a conventional DMA technique.
Signal SCSI* goes low to access either U208 or the virtual port VPORT. Signal A5 determines which is selected (SCSI controller U208 is selected if A5 is "zero"; virtual port VPORT is selected if A5 is "one"). SDTACK* goes low when either of these devices is accessed.
Table 32 specifies the logical relationships between the input and output signals of device U011:
TABIE 32
SCS (!A5 & !SCSI);
DIST = (E & EW & !VMA) ; RIWR = (E & !RW) ; RTRD = (E & RW) ; DIYREQ1 = (DIYREQ2 # EREQ) ; DLYREQ2 = (DACK # DIYREQ1) ; SDTACK = (!DACK & !IUDS # !A5 & !IUDS & !SCSI); DACK = (A5 & !DIRREQ1 & !SCSI) ;
The SCSI bus is terminated with the open collector devices shown connected to the output terminals of U208, including Hex Schmitt-trigger inverter U018, Texas Instruments 74LS642-1 circuit U017, inverter U702, and buffer circuits U114, U115, and U304. The SCSI bus comprises the following signals: SB0-SB7, the data bus which transmits all data, status, and messages (and which is also used during arbitration by the initiator to identify itself, and during selection to identify the initiator and the target devices); SBP, which indicates parity (when the parity option is enabled, this line implements odd parity over SB0-SB7); BSY, which is asserted by the target to indicate that the SCSI bus is being used (during arbitration, the initiator must also assert BSY to indicate to the other devices on the SCSI bus that arbitration is occurring); SEL, which is driven low by the initiator to select a target (since SCSI allows a target to reselect an initiator following disconnection, the initiator must also monitor this line; C/D, which is driven low by the target to indicate that the bus contains control information instead of data; I/O, which is driven low by the target to indicate data input to the initiator, and is also used to distinguish between selection and reselection phases; MSG, which is driven low by the target during the message phase; REQ, which is driven low by the target to request a data transfer (the initiator responds by driving ACK low); ACK, which is driven low by the initiator to acknowledge a data transfer initiated by REQ; ATN, which is driven low by the initiator to indicate an ATTENTION condition; and RST, which is driven low by U201 to reset devices on the SCSI bus.
Read and write strobes for the SCSI controller are generated by random logic according to the following equations: !WR* = (!SCS* # !PUDS* # !R/W*) & (!DACK* # !PUDS* # !R/W*); !RD* = (!SCS* # !PUDS* # iR/w) & (!DACK* # !PUDS* # !R/W).
The first term in each equation represents an access of the controller (U208) itself, while the second term represents an access through the virtual port VPORT. The SCSI controller (U208) may interrupt U201 by asserting SCSIIRQ. This request passes through a NAND circuit, gated by SCSIENB. Processor U201 may disable the SCSI interrupt by resetting SCSIENB, but at the same time, processor U201 may monitor SCSIIRQ via DUART 207. CPU 1 includes dual universal asynchronous receiver/transmitter (DUART) U207 (preferably a 68681 integrated circuit), for serial communication. U207 provides two RS-232C serial ports (Ports A and B) for system console and integration, respectively. The clock for U207 is derived form the clock output of SC11004 single chip modem U707. The clock output of U707 has frequency equal to 7.3728 MHz, which is divided by two (by circuit U600) to generate the 3.6864 MHz clock required by U207.
RS-232C standard drivers, U014 and U011, and receivers U013 and U109, provide the interface U207 between and the serial lines. General purpose I/O lines in U207 are exploited for other purposes, including: SCRST* (SCSI reset); SCSIENB (SCSI interrupt enable);
SCSIIRQ (SCSI interrupt request); DREQ* (SCSI controller DMA request); and PRST* (parallel printer reset).
Modem U707, which preferably is a Sierra Semiconductor SC11004 single chip modem, and modem controller U303, which preferably is a Sierra Semiconductor SC11007 parallel interface modem controller, are provided for facilitating remote diagnostics. Connected to U707 and U303 is a data access arrangement comprising a ring detector, isolation transformer, line seizure relay, and protection circuitry.
For accurate operation, external parallel resonant crystal Y4 (having 20 pF load), is coupled to modem U707, with a 27 pF capacitor between XTAL1 and ground and a 47 pF capacitor between XTAL2 and ground. The interface to U303 is preferably identical to an 8259 UART.
CPU 1 includes real time clock U604 (preferably an Intersil 7170 circuit) for system timekeeping, including date and time, and periodic interrupts. Clock U604 interrupts U201 every 10ms with an autovectored, level four interrupt. The operating system for U201 may use this interrupt to update the time and date variables and to provide context switching. Clock U604 requires a 32.768 kHz crystal, Y3, whose frequency may be adjusted with variable capacitor C17. Since system time is kept from this device, and since U201's operating system will typically depend on accurate time for many of its operations, the frequency of clock U604 must be accurately adjusted (by programming U604 for one second interrupts, and adjusting C17 until the period is exactly one second).
U604 is a VPA device requiring special read and write strobes, RTWR* and RTRD*, which are generated by U011.
CPU 1 and PCI units 3 are controlled by a software operating system, so that the function of each PCI unit 3 may be independently defined by software downloaded from CPU 1. It is contemplated that the operating system may support a variety of voice and data processing application programs, including a voice mail application program. The operating system will control all input/output operations for the system, as well as the telephone interfacing operations performed by the PCI units 3. In a preferred embodiment, system processor U201 of CPU 1 is programmed to operate under an operating system which performs most (or all) of the functions of conventional operating systems (for example, the conventional VMS operating system available from Digital Equipment Corporation), but which also performs the inventive functions to be described below. An important advantage of the inventive system is that its hardware architecture (described above), together with its operating system, allows processing of digitized voice information together with other digital data. In the inventive hardware/software system, digitized voice and other data coexist in a single file structure. The file records may consist of fields containing numeric data information as well as fields containing recorded, digitized, voice information.
The inventive system stores digitized voice information in data records for playback in analog form (such as for transmission over a telephone line to a voice mail user). The inventive system also stores digitized voice information, together with DTMF data and other digital data, in data records for a wide variety of processing operations (such as compilation into customized voice or printed reports). The inventive system is capable of exchanging such data records with a mainframe computer for updating files or retrieval of data base information needed for a variety of voice information processing applications.
In a preferred embodiment, the inventive operating system performs many of the functions of the above-mentioned VMS operating system, including creation and maintenance of files, display or printing of file contents, configuration and maintenance of software applications, monitoring and control of system processes, and performance of basic system diagnostics. Conventional software algorithms may be used to perform such operations, with the exception of file creation (to be discussed below). Additionally, it is contemplated that an ordinarily skilled computer programmer, given the description provided in this Specification, will be able readily to modify a conventional operating system so that the modified operating system may be used to record vocal phrases to be manipulated by a variety of applications programs. Because the inventive system is designed to be particularly useful for supporting voice processing applications, it is important that the system open files as rapidly as possible. For example, in many applications (such as voice mail), the user will record voice information in response to a system-generated vocal prompt. If the system requires a long time to open a file for receiving the user-supplied voice message, users will experience an annoying delay between their response to the prompt, and an indication by the system that the system is ready to accept their message.
The operating system of a preferred embodiment of the invention allows rapid file creation by using a novel data construct known as a "pseudo-file", to defer many of the disk access steps required for file creation until after the user commences, to supply file contents (for example, voice information) to the system. To create a new file, the inventive operating system will perform the following operations: (a) create a pseudo-file in cache memory (i.e., allocate an unused disk cache for file information, and write the file header into the cache memory); then (b) write the data buffer (the file data) onto the disk using file information in the cache memory; and then (c) at the close of the file, search for an empty directory entry and fill with the new filename, allocate disk space for file information, write to the disk the directory entry and the file information (including the file header) which had been kept in the cache memory. Preferably, step (c) will also include the final operation of making the file id invalid. In contrast, conventional operating systems create a file in the following manner: (a) search for an empty directory entry and fill with the new filename, allocate disk space for file information, and write to the disk the directory entry and file information; then (b) open the file by searching for a directory entry that matches the filename, and read the file information into a disk cache; then (c) write the data buffer onto the disk using information in the disk cache; and then (d) at the close of the file, write the updated file information from the disk cache to the disk.
It will be appreciated that "write" step (b) of the inventive method corresponds to "write" step (c) of the conventional method. The inventive method defers several disk accesses to its final step (step (c), which follows the inventive "write" step), which disk accesses occur during steps (a) and (b) of the conventional method (i.e., before the "write" step of the conventional method). The operating system of a preferred embodiment of the invention includes a "telephone command processor" algorithm (TCP) which allows a system user to modify the menu presented (vocally) to persons initiating telephone contact with one of the PCI units 3. TCP is a systemwide application access and menu manager, which generates "top level" vocal menus, each of which menus may offer callers the option to access either a submenu or an application program (such as voice mail). A preferred embodiment of TCP will be described with reference to the flow diagram of Figure 8.
Each port of each PCI unit 3 may be assigned a default port program that will automatically be executed when a caller telephones the port. The default port program may be a dedicated program which terminates a call, or allows the caller to enter the TCP "log on" sequence, or executes a default application program. TCP will preferably prompt the caller to enter a user ID and password if no other default port program is assigned. When a caller successfully logs on, TCP will check whether the caller's account is assigned an application. If so, TCP will execute such application program and hang up upon completion of the application program. A voice mail application program is a typical example (in which case, the voice mail application program will typically prompt the caller for a mailbox number and either record a message from the caller or allow the caller to hear recorded messages in the caller's mailbox). If no application is assigned for the caller's account, TCP will cause the PCI unit to present (orally) a TCP menu to the caller.
A typical TCP menu might include the following oral phrases: "To enter voice mail, press [1]. For additional options, press [8]. To end this call, press [9]." If the caller responds by pressing key [8] (thereby sending the PCI unit a recognizable DTMF signal), TCP might orally present a submenu such as the following to the caller: "For time and date, press [1]. To change your password, press [2]. To play [a voice game], press [3]. To exit this menu, press [9]." In this example, processor U201 would be programmed to execute a voice game application program in response to entry of the DTMF command "[3]".
It is contemplated that processor U201's operating system will offer a user the option of revising the TCP menus and submenus presented to callers. Preferably, the operating system allows the user to define TCP menu key assignments, to record new oral TCP menu phrases and create a voice file for each user-recorded menu phrase (which voice file contains a digitized version of the recorded menu phrase), and to copy such voice files to the operating system directory so that TCP can access each such voice file.
For example, suppose the user wishes to offer a caller the option of executing a customized application program known as "Sales Administrator". Such an application program might prompt a salesman caller to enter the amount and date of each sale made in the last week (by entering DTMF tones). The program might then process the tones entered by a group of salesmen to compile a voice report listing cumulative sales data. Such voice report might consist of concatenated digitized voice phrases, some of which represent the result of mathematical processing of a set of numerical signals entered by the salesmen (i.e., the program might translate all DTMF "sales price" signals into numbers, and then add the numbers, and then translate the number representing the sum into a voice file containing a prerecorded digitized vocal representation of the sum). The application program might also prompt callers to exercise their option to hear the most recently updated version of such voice report.
Assuming such an application program has been coded, and entered as an executable application program that may be executed by the operating system of the invention, the user might modify the TCP submenu set forth above to add to it a fifth phrase as follows: "To execute Sales Administrator, press [4]." In order to so modify the submenu, the user would need to record the indicated phrase, and store it in a voice file that may be accessed by TCP.
The operating system of a preferred embodiment of the invention also includes an algorithm allowing users to create files known as "tagged messages". Each tagged message may include: (a) data (such as numerical data, or a digitized voice signal, or both), (b) a field identifying the file as a "tagged message", (c) a field specifying the file name of another file (which other file contains a digitized vocal prompt message), and (d) a field specifying an application program to be executed in response to a command (i.e., a DTMF command supplied by the recipient of the prompt identified in field (c) above).
An important example of the utility of tagged messages will be described with reference to a voice mail application program. When a voice mail recipient encounters a tagged message in reviewing the voice messages in his or her mail box, the inventive system will play back the digitized voice content of the tagged message just as it would play back an untagged message. However, after the tagged message as been played, and the voice mail program is prompting the recipient for the usual optional actions to be taken in response to the message (i.e., the options of listening to the message again, deleting it, storing it, and so on), an additional prompt will be presented. This additional prompt is the one identified in field (c) of the tagged message. If the recipient then presses the telephone key indicated by the additional prompt, the application program identified in field (d) of the tagged message will be executed (as a sub-process of the on-going voice mail operation).
For example, the voice content of the tagged message (the contents of field (a)) might set forth a meeting agenda, and the prompt identified in field (c) of the tagged message might ask the recipient to press key [2] to initiate a "Meeting Scheduler" application program. Such "Meeting Scheduler" application program might allow the recipient to specify his or her availability for attending a meeting. Upon completion of execution of the "Meeting Scheduler" application, the recipient would return to the voice mail application (so that he or she could continue to review messages in his or her mail box).
The "pseudo-file", "tagged messages" and TCP data constructs and methods described above will preferably be embodied in an operating system for the system described above with reference to Figures 1-7. However, the inventors specifically contemplate that such data constructs and methods may be embodied in other voice processing systems.
The invention also comprises improved methods for automated processing of incoming and outgoing telephone calls. These methods (to be discussed below with reference to Figures 9-14) will preferably be implemented in software. Such software will preferably be downloaded from processor U201 to port processor U87 for controlling a port of PCI unit 3 in operation of the system of Figs 1-7. However, the inventors specifically contemplate that the methods may be embodied in other voice processing hardware/software systems.
A preferred embodiment of one inventive call processing method will next be described with reference to Figs. 9-13. The Fig. 9 flow chart contemplates that a caller has completed a call to a port of PCI unit 3, that an automatic call distribution application program has commenced execution or that an outdial application has commenced execution. Fig. 9 further contemplates that the automatic call distribution application program has accepted from the caller a particular telephone number to be dialed, and has dialed that telephone number (in preparation for transferring the caller to the requested line) or that the outdial application program has dialed the target telephone number (in preparation for delivery of a message to the target party). The first block in the Fig. 9 flow chart indicates that, at this point, PCI unit 3 will disable the voice sampling algorithm until the first positive edge (a transition from an energy line state to a no energy line state) thus reducing the chance of preconnect line noise being interpreted as voice and triggering a premature voice detect response. PCI unit 3 will then monitor the status of the distant end of the dialed line for rising or falling edges (indicative, for example, of "ringing" or "busy" conditions). If no positive edge is detected on the dialed line after 15 seconds have elapsed, PCI unit 3 will reconnect with the caller, and send CPU 1 a message indicating that the desired line is dead (or send the caller a voice message indicating that the desired line is dead). If a positive edge is detected within 15 seconds after the Fig. 9 algorithm has commenced, the PCI unit will determine whether the edge detected was more than 600 ms after the Fig. 9 algorithm commenced. If so, the PCI unit will perform the "Wait for answer" operation described by the Fig. 13 flow chart.
Fig. 13 indicates that the PCI unit will report to CPU 1 that the called party has answered, if no additional edge (i.e., no second edge in addition to the first edge already detected) is detected within 4.3 seconds. If a second edge is detected within such 4.3 second period, but the overall RNA timer (which started at the beginning of the call progress algorithm) has expired, then the PCI unit will generate a report for CPU 1 (or a voice report for the caller) indicating that the called party's line did ring, but that the called party did not answer (i.e., that a "RNA", or "ring, but no answer" condition exists). If a second edge is detected within the 4.3 second period, and no third edge is detected within a 2.3 second period, the PCI unit will report to CPU 1 that the called party has answered. PCI unit 3 continues monitoring the line for edge pairs until either an individual edge timeout occurs, the overall RNA timeout occurs, or voice detect occurs. Returning to Figure 9, if the first edge was detected within a 600 ms period after the Fig. 9 algorithm commenced, PCI unit 3 will determine if a second edge is detected within an additional 575 msec period. If not, the PCI unit will return to position "C" in the Figure 9 flow chart, and continue to monitor the distant end for a signal edge. If so, the PCI unit will determine whether it should report a "busy" condition, a "reorder" condition, or should return to position "C" of the Fig. 9 flow chart.
PCI unit 3 will report a busy condition if the indicated conditions are met for progress from position J of Fig. 9, through positions I, L, and M, to position N. PCI unit 3 will report a "reorder" condition if the indicated conditions are met for progress from position J of Fig. 9, through positions I, L, M, 0, and P, to position Q. Otherwise, PCI unit 3 will return to position C on the Fig. 9 flow chart.
The edge waiting algorithm shown in Fig. 10 will be performed at each of positions B, F, H, I, and K of Fig. 9. At position Wl of the Fig. 10 algorithm, PCI unit 3 will perform the Fig. 11 algorithm to get a 20 ms sample representing the status of distant end. The first step (Y1) of the Fig. 11 algorithm is described in Figure 12.
A source code listing (in Assembly language), of the preferred implementation of the call progress method described above with reference to Figs. 9-13, is set forth in this Specification below as Table 33.
A preferred embodiment of another invennive incoming call processing method, for accomplishing a call transfer, will next be described with reference to Fig. 14. The inventive call transfer method contemplates that a caller has completed a call to a port of PCI unit 3 , that an automatic call distribution application program has commenced execution. The automatic call distribution application program first plays a recorded voice message to the caller, which prompts the caller to enter DTMF signals indicating a desired telephone number. The example of the inventive method shown in Figure 14 contemplates that the inventive system is coupled to a conventional PBX system, and that the "desired number" a multi-digit extension number (XXX) on the PBX network.
The next step in the inventive call transfer method is for PCI unit 3 to execute a "hook flash" ("HF"), or PBX soft hold operation, to place the caller on hold. PCI unit 3 then connects with the PBX to dial the desired number and hangs up ("drops the line", as indicated in Fig. 14), connecting the caller with the desired called party's line. By performing this operation, PCI unit 3 is said to have executed a "blind transfer". The caller will hear the called party's phone ringing at this stage (after execution of the blind transfer), if the called party's line is idle.
The next steps of the Fig. 14 method rely on the feature of most conventional PBX systems which automatically reconnects a master station (PCI unit 3, in the present case) to a caller station when the master station goes off hook after the master station executes a blind transfer to a third station (a "called party" station) on the PBX network, if the called station's called party's line is busy or in error (and the caller station does not itself hang up).
In the Fig. 14 method, after PCI unit 3 drops the line, it goes off hook and listens for a call progress tone. If no dial tone is detected after a user-defined period of time (which may be a fraction of a second, or as long as 2000 ms) then it is assumed that the called party's line was busy and the PBX has reconnected the PCI unit with the caller station. In this case, branch Z3 of the Fig. 14 method is executed, and the PCI unit plays a recorded message to the caller indicating that the called party's line is busy, or unavailable. Such recorded message may offer the caller other menu options, such as the option to hold (in which case the PCI unit will redial the called party's line after waiting for a predetermined period).
After PCI unit 3 drops the line, goes off hook and detects a dial tone, PCI unit 3 will wait for a user-defined period of time (for example, up to seven seconds) after detecting the dial tone in order to verify the dial tone identification. If a line break occurs during this period, and the dial tone is not verified, branch Z3 of the Figure 14 method is executed. If the dial tone is verified, branch Z1 or branch Z2 of the Fig. 14 method will be executed. Either of three conditions will give rise to detection of a dial tone under these circumstances: either the calling party is connected with the called party (their conversation is in progress); or the called party's line is still ringing; or the calling party decided to abandon the call attempt, and had hung up his or her phone. When the PCI unit detects a verified dial tone under the described circtumstances, it will stay off-hook to keep the line/station busy for a selected period (preferably 20 seconds) so that the PBX will not force any additional calls in. At the end of this period, the PCI will execute a hook flash and attempt to answer the called party's line using the PBX's directed call pick up feature. If a "reorder" tone or "error" tone is heard following such directed call pickup attempt, the PCI unit goes on hook (under branch Z1 of the Fig. 14 method), as it is assumed that either the called party answered the line before the directed call pick up attempt, or that the calling party has hung up (although there are other possibilities). If no reorder or error tone is heard following such directed call pickup attempt, it is assumed that the directed call pick up was successful, and that the PCI unit has been reconnected with calling party. In this event, branch Z2 of the Fig. 14 method is executed, and the PCI unit plays a recorded message to the caller indicating that the called party is unavailable. Such recorded message may offer the caller other menu options, such as the option to dial another extension.
An important advantage of the inventive method described with reference to Figure 14 is that the called party is immediately and directly connected with the calling party when the called party goes off hook to service the call. In conventional call transfer systems of this class, there is a delay in connecting the calling and called parties, when performing transfers with ring-no-answer supervision, which may lead to the called party's initial greeting being completely lost in the transmission. Such a delay may cause the called party to become confused, since he picked up his phone, expressed a greeting, and did not receive a reply. The caller may also become confused at this point, when employing such a conventional system, since he will not hear the called party's initial greeting.
Among the other advantages of the Fig. 14 method is that if the called party's line rings upon the blind transfer, the calling party will continue to hear a ringing line until the PCI unit intercepts the calling party's line. During the ringing period, the calling party is less likely to become discouraged and hang up than in the case that no ringing tone is audible (as is the case in conventional automated call transfer systems, such as conventional systems operating "behind" a PBX (not on the CO or a trunk side) that operate, electronically, like a single-line 2500-type telephone). Another advantage of the Fig. 14 method is that if the called party does answer the line, the calling and called party will be completely unaware that the PCI unit attempts a directed call pick up during their conversation. In contrast, in conventional automated call transfer systems in which the master station does not execute a blind transfer (and instead remains off-hook during the transfer process), when the called party answers its line, the called party will be aware that the master station is off-hook and connected with the called party (due to noise or intentional signals introduced on the line by the master station). Finally, in the event that the called party's line is busy, the PCI unit of the invention is immediately available to assist the calling party. A source code listing (in Assembly language), of the preferred implementation of the call transfer method described above with reference to Figure 14, is set forth below in this Specification as Table 34.
The above description is merely illustrative and explanatory of the present invention. Various changes in details of methods and apparatus described may be within the scope of the appended claims without departing from the spirit of the invention. TASLE 35
Error
Address Code Sequence Source Statement
2514 * 2515 * CALL PROGRESS DETECTION 2516 * Returns: 2517 * A = $01 : ring answered 2518 * A = S82 : silence 2519 * A = $83 : busy 2520 * A = $84 : reorder tone 2521 * A = $85 : ring no answer 2522 * A = $86 : answer detected and message required 2523 * 2524 * 2525 * 2526 * If R passed in A,monitor for ringback only-if A,also monitor for 2527 * answer. Timeout for call progCEXTTMO or INTTMO) passed in in X.
DDE5 7D 0036 2528 RESULT TST HUNGUP Have we already had a hangup interrupt?
DDE8 27 03 2529 BEQ 1$ No, then we can proceed with call progress
DDEA 86 01 2530 LDAA #$01 Yes, then fake an answer
DDEC 39 2531 RTS
DDED C6 01 2532 1$ LDAB #1 Flag that we are doing call progress
DDEF F7 D03E 2533 STAB CPENBL
DDF2 C6 CO 2534 LDAB #$C0 Set bit 6 of IRQENB to enable T1
DDF4 D7 AE 2535 STAB IRQENB
DDF6 B7 D024 2536 STAA HTRTYP Save progrss detection type
DDF9 FF D01D 2537 STX THR_C1
DDFC 7F D025 2538 CLR ENERGY Reset call progress
DDFF 7F D026 2539 CLR LSTPCK
DE02 7F D027 2540 CLR NRGCNT
DE05 7F 004A 2541 CLR EDGFLG Start with no edge detected yet
DE08 7F D02C 2542 CLR DTEKT Clear the voice detection counter DE08 86 14 2543 LDAA #20 Initialize 20 msec timer
DE0D B7 D023 2544 STAA TMR_CA
DE10 96 38 2545 JSR DODSI Disable silent interrupts
DE13 96 38 2546 LDAA VIARA
DE15 8A 02 2547 DRAA #$02 Force zero/APT high (ready for speech)
DEI7 84 FB 2548 ANDA #$FB CVSD direction = input
DE19 97 38 2549 STAA VIARA
DE1B 97 A1 2550 STAA CVSDIO
DE1D 86 FF 2551 LDAA #$FF Set clamp for recording
DE1F 87 1000 2552 STAA VOLUME
DE22 86 05 2553 LDAA #5 Set unknown state voice detect sensitivity
DE24 87 D033 2554 STAA VOCSEN 2555 *
DE27 CE 3200 2556 LDX #COMRAM Start of debug data
+$200
DE2A FF D029 2557 STX DEBUG 2558 * TABLE 33
Error Address Code Sequence Source Statement
2559 * Wait for energy to begin, then time the energy to determine if
2560 * ringback, busy, or reorder. If >750 msec, assutie ringback.
2561 * Otherwise check for noise or errors.
DE2D 7F D02E 2562 WATNRG CLR ERRFLG Indicate not in error checking DE30 7F D030 2563 CLR SAMFLG Set the no samples flag DE33 FE D01D 2564 WATNR2 LDX TMR_C1 DE36 26 11 2565 BNE 5$ Branch if not timed out DE38 86 85 2566 LDAA $85 Timed out with no answer DE3A 20 0A 2567 BRA 4$ DE3C 86 82 2568 1$ LDAA #82 Dead line DE3E 7D 004A 2569 TST EDGFLG DE41 27 03 2570 BE0 4$ If edge flag clear, report dead line DE43 7E DEBE 2571 JMP CPM1XT Report answer detected DE46 7E DEC9 2572 4$ JMP CPMRXT DE49 7D 004A 2573 5$ TST EDGFLG If clear then 1st pass DE4C 270F 2574 BEQ 2$ Allow 15 sec for timeout DE4E CE 1130 2575 LDX #4400 Otherwise timeout according to best knowledge DE51 BD DF2F 2576 JSR GETEDG DE54 2A 03 2577 BPL 14$ No answer detected DE56 7E DEBE 2578 JMP CPM1XT ANSWER detected! ! DE59 27 E1 2579 14$ BEQ 1$ WiII assume answer DE5B 20 21 2580 BRA 6$ Branch around code with 15 sec timeout DE5D CE 1130 2581 2$ LDX #4400 first pass through, check first for ring DE60 BD DF2F 2582 JSR GETEDG DE63 2A 03 2583 BPL 18$ No answer detected DE65 7E DEBE 2584 JMP CPM1XT ANSWER detected! ! DE68 26 14 2585 18$ BNE 6$ An edge was received DE6A 7D D025 2586 TST ENERGY Was what we were timing silence? DE6D 27 05 2587 BEQ 7$ Yes . . . allow more time DE6F 7C 004A 2588 INC EDGFLG Force assumed answer DE72 20 C8 2589 BRA 1$ DE74 CE 32C8 2590 7$ LDX #13000 Allow 13 seconds total for edge DE77 BD DF2F 2591 JSR GETEDG DE7A 2B 42 2592 BMI CPM2XT ANSWER detected! ! DE7C 27 BE 2593 BEQ 1$ No edge in 13 seconds total . . . dead line DE7E 7D D025 2594 6$ TST ENERGY See if new state is silence DE81 26 BO 2595 BNE WATNR2 If not go time energy in progress DE83 86 02 2596 LDAA #$02 DE85 C6 58 2597 LDAB #88 DE87 BD DFDE 2598 JSR CMXAB Compare X to 600 msecs DE8A 26 03 2599 BNE 3$ Branch X>600 DE8C 7E DECD 2600 JMP CKERR <=600 msecs, so check for busy or reorder
2601 * If MTRTYP set do answer detect-otherwise return success code
DE8F B6 D024 2602 3$ LDAA MTRTYP Get the progress detection type DE92 81 52 2603 CHPA #'R Is it ring only? DE94 27 28 2604 BEQ CPM1XT Yes - exit with success now DE96 B6 D032 2605 LDAA VOCDET Get user defined detection threshold TABLE 33
Error Address Code Sequence Source Statement
DE99 B7 D034 26(V STAA VOCWRK Set working threshold DE9C 8605 2607 LDAA #5 Set known state voice detect sensitivity DE9E B7 D033 2608 STAA VOCSEN
2609 *
DEAt CE 10CC 2610 ANSWER LDX $4300 Maximum silence time DEA4 BD DF3F 2611 JSR GETEDG DEA7 2B 15 2612 BMI CPM1XT Voice detected! DEA9 2713 2613 BEQ CPM1XT No edge, assune connected DEAB FE D01D 2614 LDX TMR_C1 Has the no answer monitor timer expired? DEAE 2604 2615 BNE 1 No . . . proceed with check DEBO 8685 2616 LDAA #85 monitor timeout, no answer DEB2 2015 2617 BRA CPMRXT Return DEB4 CE 08FC 2618 1$ LDX #2300 Maximum energy time DEB7 BD DF2F 2619 JSR GETEDG DEBA 2B 02 2620 BMI CPM1XT Voice detected! DEBC 26 E3 2621 BNE ANSWER Go validate the new 'ring'
2622 *
2623 * ANSWER DETECTED OR ASSUMED
2624 *
DEBE 8601 2625 CPM1XT LDAA #1 Assume answer with no message DECO F6 D024 2626 LDAB MTRTYP Get progress detection type DEC3 Cl 4E 2627 CMPB #<N Check if message required DEC5 2602 2628 BNE CPMRXT No DEC7 8686 2629 LDAA #$86 Answer with message required
2630
2631 End Call Progress Monitoring with status in A reg.
2632
DEC9 BD DDD6 2633 CPMRXT JSR ST0PT1 Disable T1 and flag "end of call progress" DECC 39 2634 RTS
2635 *
2636 * Ringback was not detected, but some other cadence or
2637 * noise was. Try to identify the cadence ... if it's noise
2638 * go back and re-monitor. Otherwise, identify the cadence
2639 * and return the proper error code. Cadence is determined
2640 * over the next four seconds. If eny edge doesn't happen
2641 * within a second, skip the probable noise and look for
2642 * ringback again.
2643 *
DECD 8601 2644 CKERR LDAA #$01 DECF C62C 2645 LDAB #S2C DED1 BD DFDE 2646 JSR CMXAB Compare X to 300 msecs DED4 2706 2647 BEQ 10$ X<=300 DED6 B6 D032 2648 LDAA VOCDET X>300; DED9 B7 D034 2649 STAA VOCWRK Set user defined voice detect threshold DEDC CD OFAO 2650 10$ LDX #4000 Check edges for 4 sees DEDF FF D01F 2651 STX TMR_C2 DEE2 7F D028 2652 CLR EDGCNT Clear edge count TABLE 33
Error Address Code Sequence Source Statement
DEE5 CE 023F 2653 LDX #575 DEE8 BD DF2F 2654 JSR GETEDG DEEB 2B D1 2655 BMI CPM1XT ANSWER detected! DEED 26 03 2656 BNE 2$ DEEF 7E DE33 2657 JMP WATNR2 Can't be error tone DEF2 7C D028 2658 2$ INC EDGCNT Count up an ege DEF5 CE 02EE 2659 LDX #750 DEF8 BD DF2F 2660 JSR GETEDG DEFB 2B C1 2661 BMI CPM1XT ANSWER detected! DEFD 27 BF 2662 BEQ CPM1XT No ege detected, assume ANSWER DEFF 7F D030 2663 CLR SAMFLG Set the no samples flag DF02 7C D02E 2664 INC ERRFLG Indicate into error checking DF05 FE D01F 2665 LDX TMR_C2 Timed out DF08 26 E8 2666 BNE 2$ No timeout, keep counting DFOA 7C D028 2667 INC EDGCNT One more edge DFOD BD DDD6 2668 JSR ST0PT1 Disable T1 and flag "end of call progress" DF10 B6 D028 2669 LDAA EDGCNT How many edges? DF13 7F D028 2670 CLR EDGCNT Clear the edge counter for WATNRG DF16 81 05 2671 CMPA #5 Check to see if it is busy DF18 23 12 2672 BLS 4$ Not likely to be a busy tone if less frequent DF1A 81 0A 2673 CMPA #10 Is it in this realm? DF1C 22 03 2674 BHI 3$ No ... may be reorder DF1E 86 83 2675 LDAA #$83 Show busy DF20 39 2676 RTS DF21 81 0D 2677 3$ CMPA #13 See if in the realm of reorder DF23 23 07 2678 BLS 4$ Not really, unknown signal DF25 81 16 2679 CMPA #22 DF27 22 03 2680 BHI 4$ Far too frequent for even reorder to be DF29 86 84 2681 LDAA #$84 Reorder DF2B 39 2682 RTS DF2C 7E DE2D 2683 4$ JMP WATNRG Return on false detection
2684 * Use EDGE to find the next edge in X msces. Return the
2685 * number of msecs actually used in X
DF2F FF D021 2686 GETEDG STX TMR_C3 Use edge detection timer DF32 7F 004B 2687 CLR SAVEDX Indicate no edge DF35 FF D035 2688 STX XTEMP Save original value of X DF38 FE D021 2689 1$ LDX TMR_C3 Hvae we timed out? DF3B 27 OC 2690 BEQ 2$ Yes DF3D 8D 1A 2691 BSR EDGE See if this was an edge DF3F 2B 17 2692 BMI 30$ ANSWER may be detected! DF41 27 F5 2693 BEQ 1$ No edge found yet DF43 7C 004B 2694 INC SAVEDX Indicate edge received DF46 7C 004A 2695 INC EDGFLG Set flag indicating edge has been seen DF49 B6 0035 2696 2$ LDAA XTEMP Get original timer count DF4C F6 D036 2697 LDAB XTEMP+1 DF4F FE D021 2698 LDX TMR_C3 Determine number of msecs used DF52 BD DFCB 2699 JSR SUB2 TABLE 33
Error Address Code Sequence Source Statement
DF55 7D 004B 2700 TST SAVEDX Get edge flag DF58 39 2701 305 RTS
2702 * Debounce the line's energy state. If it switches to
2703 * a new energy level, return the new energy status
2704 * in ENERGY and the edge condition, NE. If no edge
2705 * is detected, return EQ with ENERGY set appropriately
DF59 8D 4A 2706 EDGE BSR CKLINE Check to see if it is energy DF5B 2B 47 2707 BMI 30$ ANSWER detected!
2708 *
2709 * LDX DEBUG
2710 * CPX #COMRAM+7FF
2711 * BEQ 1$
2712 * STAA X
2713 * INX
2714 * STX DEBUG
2715 *
DF5D 16 2716 1$ TAB Save current value DF5E B8 D026 2717 EORA LSTPOC HI:changed since last packet DF61 974C 2718 STAA SAVEDX Calling routine needs XTEMP,SAVEDX
+1
DF63 F7 D026 2719 STAB LSTPCIC Set up for next pass DF66 F8 D025 2720 EORB ENERGY HI:changed from debounced value DF69 17 2721 TBA DF6A D44C 2722 ANDB SAVEDX HI:could be start of new state X1
DF6C 43 2723 COMA HI:not changed from debounce DF6D 94 4C 2724 ANDA SAVEDX HI:gone back to valid state
X1
DF6F 27 05 2725 BEQ 2$ No
DF71 7F 0027 2726 CLR NRGCNT Yes, clear counter
DF74 20 20 2727 BRA 20$
DF76 5D 2728 2$ TSTB Has the line condition gone to new state?
DF77 27 08 2729 BEQ 3$ No
DF79 B6 D02D 2730 LDAA EDGDET Debounce time (data 6 gives 7 packets)
DF7C B7 D027 2731 STAA NRGCNT Set debounce timer
DF7F 20 22 2732 BRA 20$
DF81 B6 D027 2733 3$ LDAA NRGCNT Get current timer
DF84 27 1D 2734 BEQ 20$ Nothing timing
DF86 7A D027 2735 DEC NRGCNT Decrement timer
DF89 26 18 2736 BNE 10$ No timeout here
DF8B 7D D02E 2737 TST ERRFLG Are we into error checking?
DF8E 26 05 2738 BNE 10$ Yes, skip sample f lag tests
DF90 86 FF 2739 LDAA #$FF New state is energy, allow satples (11 windows)
DF92 B7 D030 2740 STAA SAMFLG
DF95 86 03 2741 10$ LDAA #3 Set next edge to 60-80 ms.
DF97 B7 D02D 2742 STAA EDGDET
DF9A B6 D026 2743 LDAA LSTPCK Get (current) packet TABLE 33
Error Address Code Sequence Source Statement
DF9D B7 D025 2744 STAA ENERGY Save new energy state DFAO 86 01 2745 LDAA #1 Return NE, edge detected DFA2 39 2746 RTS DFA3 4F 2747 20$ CLRA No edge DFA4 39 2748 30$ RTS 2749 * 2750 * Check for energy detection 2751 *
DFA5 BD E741 2752 CKLINE JSR GSAMP Get a sample DFA8 270F 2753 BEQ 30$ Voice not detected DFAA 7C D02C 2754 INC DTEKT Voice detected, increment the count DFAD B6 D02C 2755 LDAA DTEKT DFBO B1 D034 2756 CMPA VOCWRK At the voice detection threshold? DFB3 23 07 2757 BLS 50$ No, voice not detected DFB5 86 FF 2758 LDAA #$FF Flag that voice detected! (ANSWER!!) DFB7 20 11 2759 BRA 90$ DFB9 7F D02C 2760 30$ CLR DTEKT Voice not detected, reset detection count 2761 *
DFBC B6 D023 2762 50$ LDAA TMR_C4 Be sure to wait the 20 ms minimum DFBF 26 E4 2763 BNE CKLINE Has not elapsed, try another sample DFC1 86 14 2764 LDAA #20 Reset the 20 ms counter DFC3 B7 D023 2765 STAA TMR_C4 DFC6 96 AO 2766 LDAA DTMFCP Load cal l progress DFC8 84 01 2767 ANDA #$01 Isolate bi t for energy DFCA 39 2768 90$ RTS 2769 *
3951 * GSAMP - Gets a voice data sample and returns sample type
E741 7D D030 3952 GSAMP TST SAMFLG Take a sample? E744 26 03 3953 BNE 10$ Yes, maybe E746 7E E7DE 3954 JMP GSAM10 No, indicate voice not detected E749 96 A0 3955 10$ LDAA DTMFCP Load call progress E74B 84 01 3956 ANDA #$01 Isolate bit for energy E74D 26 03 3957 BNE 40$ Energy present, take a sample E74F 7E E7DE 3958 JMP GASM10 Indicate voice not detected 3959 * 3960 * Note: don't trash A, since we pass it along for later 3961 *
E752 CE 3100 3962 40$ LDX #COMRAM Place samples at $100 to $140 (65 samples)
+$100
E755 96 38 3963 LDAA VIARA E757 8A 02 3964 ORAA #$02 Force zero/APT high (ready for speech) E759 84 FB 3965 ANDA #$FB CVSD direction = input E75B 88 08 3966 EORA #$08 (+2/16) E75D 97 A1 3967 STAA CLOCK (+4/20) 3968 * TABLE 33
Error
Address Code Sequence Source Statement 3?69 * Peceive sample data bytes
3970 *
E75F 96 A1 3971 50$ LDAA CVSDIO (-3/ 3)
E761 84 01 3972 ANDA #$01 Mask in data bit (-2/ 5)
E763 A7 00 3973 STAA X Save this value (-6/11)
E765 96 A1 3974 LDAA CLOCK Clock CVSD (-3/14)
E767 8808 3975 EORA #8 C-2/16)
E769 97 A1 3976 STAA CLOCK (-4/20) 3977 *
E76B 08 3978 INX Bump the buffer pointer (+4/ 4)
E76C 8C 313D 3979 CPX #C0MRAM Terminate loop? (+3/ 7)
+S13D
E76F 27 08 3980 BEQ 60S Yes (+4/11)
E771 96 A1 3981 LDAA CLOCK No, clock CVSD (+3/14)
E773 88 08 3982 EORA #8 (+2/16)
E775 97 A1 3983 STAA CLOCK (+4/20)
E777 20 E6 3984 BRA 50$ (+4/24) 3985 *
E779 96 A0 3986 60$ LDAA DTMFCP Load call progress
E77B 84 01 3987 ANDA #$01 Isolate bit for energy
E77D 27 5F 3988 BEQ GSAM10 If currently no energy, then no voice!
E77F CE 30FF 3989 LDX #COMRAM Index Samples
+$FF
E782 C6 FF 3990 LDAB #$FF Set B register to -1
E784 08 3991 70$ INX Bump buffer pointer
E785 8C 313D 3992 CPX #COMRAM Terminate loop?
+S13D
E788 27 08 3993 BEQ 80$ Yes
E78A A6 00 3994 LDAA X Get next delta
E78C 26 F6 3995 BNE 70$ Leave 1's alone
E78E E7 00 3996 STAB X Convert 0's to -1
E790 20 F2 3997 BRA 70$ 3998 *
E792 CE 30FF 3999 80$ LDX #COMRAM Index samples at S2100 to S2140 (65 samples)
+SFF
E795 5F 4000 CLRB Start at relative 0 point
E796 7F D02F 4001 CLR MINMAX Indicate no critical points encountered
E799 7F D02B 4002 CLR DSTATE Start at delta state 0; undertermined
E79C 08 4003 82$ INX Bump buffer pointer
E79D 8C 313D 4004 CPX #COMRAM Terminate loop?
+S13D
E7A0 27 34 4005 BEQ 100$ Yes
E7A2 EB 00 4006 ADDB X Add next delta
E7A4 2B 19 4007 BMI 90$ Into negative delta
E7A6 C1 01 4008 WPS *1 Have we moved up 2 yet?
E78A 23 F2 4009 BLS 82$ No
E7AA 7D D02B 4010 TST DSTATE What state are we in? TABLE 33
Error
Address Code Sequence Source Statement
E7AD 2B 05 4011 BMI 84$ We are neg and detected pos delta
E7AF 27 03 4012 BEQ 84$ Undertermined, bump critical count
E7B1 5F 4013 CLRB Reset to relative zero point;
E7B2 20 E8 4014 BRA 82$ we are pos and detected pos delta
E7B4 7C D02F 4015 84$ INC MINMAX Burp critical count
E7B7 5F 4016 CLRB Reset to relative zero point
E7B8 86 01 4017 LDAA #1
E7BA B7 D02B 4018 STAA DDSSTTAATTEE Now in pos delta state
E7BD 20 0D 4019 BRA 82$ 4020 *
E7BF C1 FE 4021 90$ CMPB #-2 Have we moved down 2 yet?
E7C1 2E D9 4022 BGT 82$ No
E7C3 7D D02B 4023 TST DSTATE What state are we in?
E7C6 2C 03 4024 BGE 94$
4025 * BEQ 94$ Undetermined, bump critical count
4026 * BPL 94$ We are neg and detected pos delta
E7C8 5F 4027 CLRB Reset to relative zero point;
E7C9 20 D1 4028 BRA 82$ we are pos and detected pos delta
E7CB 7C D02F 4029 94$ INC MINMAX Bump critical count
E7CE 5F 4030 CLRB Reset to relative zero point
E7CF 86 FF 4031 LDAA #-1
E7D1 87 D02B 4032 STAA DSTATE Now in neg delta state
E7D4 20 C6 4033 BRA 82$ 4034 *
E7D6 B6 D02F 4035 100$ LDAA MINMAX Get critical areas detected
E7D9 B1 D033 4036 CMPA VOCSEN More than 5 (or 6) reversals detected?
E7DC 2E 02 4037 BGT GSAM20 Yes, must be voice data
E7DE 4F 4038 GSAM10 CLRA No, indicate voice not detected
E7DF 39 4039 RTS 4040 *
E7E0 8601 4041 GSAM20 LDAA #1 Indicate voice detected
E7E2 39 4042 RTS 4043 END
TABLE 34
Error Address Code Sequence Source Statement 2120 *
2121 * Set up for and invoke POISE call progress detection
2122 * This routing requires the dialed ("transfer-to")
2123 * extension number ("X" in the transfer sequence) to be
2124 * passed in the COMRAM.
2125 * Returns:
2126 * A = $01 : ring answered (successful transfer)
2127 * A = $83 : busy or reorder tone
2128 * A = $85 : ring no answer
2129 * The following digits will be passed in COMRAM:
2130 * Terminator (COMRAM byte $00) sigiifies end of extension
2131 * Zero (COMRAM byte $01) converts to $00 for DTMTON
2132 * One (COMRAM byte $02) converts to $01 for DTMTON
2133 * etc. etc.
2134 * Nine (COHRAH byte $0A) converts to $09 for DTHTON
2135 * [*] (COMRAM byte $0B) converts to $0A for DTMTON
2136 * [*] (COMRAM byte $0C) converts to $0B for DTMTON
2137 * Terminator (COMRAM byte 10) coverts to $0F; end of ext.
2138 *
DBAA 9604 2139 POISED LDAA COMSEL Get the COMRAM which CINDI just set up DBAC 8802 2140 EORA #$02 DBAE 9704 2141 STAA COMSEL DBB0 97 AC 2142 STAA CA2CB2 Extension number to dial is now in COMRAM
2143 * Note that RSULTC and DOOCP will require this bank of COMRAM
DBB2 B6 D032 2144 LDAA VOCDET Get iser defined detection threshold DBB5 B7 D034 2145 STAA VOCWRK Set initial voice detect threshold DBB8 8603 2146 LDAA #5 Set initial edge detect to 60-80 ms. DBBA B7 D02D 2147 STAA EDGDET DBBD 8D 1A 2148 BSR RSULTC Do the call progress detection DBBF 7E D402 2149 2149 JMP ONLINO and return status code to CINDI
2150 *
2151 * Delay for X milliseconds
2152 * Inputs: CC = tests the contents of X
2153 * X = contains delay in msec
2154 *
DBC2 2714 2155 CPDLAY BEQ 2$ No need for delay DBC4 FF D01D 2156 STX TMR_C1 DBC7 8601 2157 LDAA #1 Signal that the timer is going DBC9 B7 D03E 2158 STAA CPENBL DBCC 86 CO 2159 LDAA #$C0 DBCE 97 AE 2160 STAA IRQENB DBD0 FE D01D 2161 1$ LDX TMR_C1 Wait for delay to end DBD3 26 FB 2162 BNE 1$ DBD5 BD DDD6 2163 JSR STOPT1 Stop the timer DB08 39 2)64 2$ RTS
2165 * TABLE 34
Error Address Code Sequence Source Statement
2166 *Positive Offhook Indication (POISE) Call Progress Detection
2167 * Inputs: this routine requires the extension to be in COMRAM
2168 * (so don't switch the COMRAM banks once POISED has set them up)
2169 * Returns:
2170 * A = $01 ring answered (successful transfer)
2171 * : (directed call pickup received reorder/busy)
2172 * A = $83 : busy or reorder tone
2173 * (dial tone not received)
2174 * A = $85 : ring no answer
2175 * (dir. call pickup did not get reorder/busy)
2176 * The status returns seem confusing, but are correct as written.
2177 * Remember that we are performing call progress in response to
2178 * a directed call pickup; based on what it returns we will
2179 * modify the status that we return to the original caller.
2180 * Note that for standard call progress we can use a simple
2181 * timer (INTTM0) to obtain the desired RNA interval;
2182 * for POISE call progress the RNA calculation is rather complex.
2183 * To obtain an RNA interval for POISE that matches INTTMO, we
2184 * must calculate the time between going onhook to drop the line
2185 * and the end of reorder detection. The reorder detect will
2186 * detect an answer and so should terminate essentially instantly.
2187 * But we will have the following components making up the RNA:
2188 * PBXDTD, 7 second fixed dial tone detect, RNATMO, SHFDUR,
2189 * 1 second delay after hookflash, and the time needed to dial
2190 * the Directed Call Pickup sequence (including 200 msec per
2191 * dialed digit, and any W or H eπbedded in the sequence). UNTTST
2192 * will calculate a value for RNATMO that will cause all the
2193 * above components to add up to INTTMO.
2194 *
DBD9 7D 0036 2195 RSULTC TST HUNGUP Have we already had a hangup interrupt? DBDC 2637 2196 BNE 3$ Yes, then fake a successful transfer
2197 * ensure MUX irqs are disabled before going onhook
DBDE BD D1B4 2198 JSR DDDMI Disable HUX irqs (don't allow a ring irq) DBE1 BD D17C 2199 JSR DDDNH Go onhook DBE4 FE D05B 2200 LDX PBXDIS Delay so that the PBX sees this as a disconnect DBE7 80 D9 2201 BSR CPDLAY DBE9 BD D18C 2202 JSR DOOFH Go offhook
2203 * note - may need to check for hangups here ( l ike HOOKIT does)
DBEC FE D05D 2204 LDX PBXDTD Delay before checking for dial tone DBEF 8D D1 2205 BSR CPDLAY
2206 * note - if you change the timing of this loop, you must also
2207 * change the calculations of RNATMO in UNTTST.SRC
DBF1 C646 2208 LDAB #70 Test for 7 seconds of dial tone DBF3 CE 16FA 2209 1$ LDX #5882 The following loop provides 1/10th second DBF6 96 A0 22t0 2$ LDAA DTMFCP Is there noise? DBF8 8401 2211 ANDA #$01 DBFA 2721 2212 BEQ 5$ No the noise was interrupted TABLE 34
Error Address Code Sequence Source Statement
DBFC 09 2213 DEX Count down 1/10th second timer
DBFD 26 F7 2214 BNE 2$
DBFF 5A 2215 DECB Count down main timer
DC00 26 F1 2216 BNE 1$ (be sure to restart X timer) 2217 * uninterrupted noise detected, indicating dial tone
DC02 FE D05F 2218 LDX RNATMO Get the RNA timer and delay for that long DC05 SD BB 2219 BSR CPDLAY DC07 802F 2220 BSR DDSHF Do a short hookflash 2221 * note - if you change this timing, you must also change the 2222 * calculations of RNATMO in UNTTST. SRC
DC09 860A 2223 LDAA #10 Delay for 1 second after the flash
DC0B BD D85C 2224 JSR DELAY
DC0E 80 58 2225 BSR DODCP Perform a directed call pickup
DC10 BD DCDF 2226 JSR CK4ROT Check for re-order/busy tone
DC13 26 04 2227 BNE 4$ ROT absent 2228 * dir. call pickup got reorder/busy; call must have been transferred ok
DC15 86 01 2229 3$ LDAA #S01 Flag that successful transfer occurred DC17 20 1E 2230 BRA 9$ and jam 2231 * dir. call pickup did not get reorder/busy tone; RNA must have occurred
DC19 86 85 2232 4$ LDAA #$85 Flag that RNA occurred DC1B 201A 2233 BRA 9$ and jam 2234 * dial tone not detected, indicating that busy or reorder tone occurred
DC1D 0F 2235 5$ SEI Disable irqs while we see if caller hungup DC1E 96 A0 2236 LDAA DTHFCP Clear any spurious DTMF/silence interrupts DC20 86 08 2237 LDAA #$08 Clear any spurious MUX interrupts DC22 97 AD 2238 STAA IRQFLG DC24 BD D201 2239 JSR LOPBRK Is there loop current ? (also reereble HD irqs) DC27 260B 2240 BNE 6$ Loop current present
2241 * Far-end hangup has occurred; deal with it
2242 * (i.e. go onhook, disable silent/DTMF irqs, enable MUX irqs,
2243 * set any flags needed, and put HANGUP key in keys buffer)
DC29 7C 0036 2244 INC HUNGUP Count another hangup IRQ DC2C BD D4F5 2245 JSR GRNDIT Go onhook; select "ring interrupt" as MUX IRQ DC2F 8612 2246 LDAA #HANGUP Put hangup key in buffer
2247 * be sure an SEI cαnmand is in effect before doing the JSR INKEY
DC31 BD E70F 2248 JSR INKEY Put the key in A into keys buffer
DC34 0E 2249 6$ CLI Allow interrupts again
DC35 86 83 2250 LDAA #$83 Flag that Busy or reorder tone occurred
DC37 39 2251 $ RTS
2252 *
2253 * Do a short hookflash
2254 *
DC38 F6 D007 2255 DOSHF LDAB SHFDUR Get the duration of the short hookflash DC3B 0F 2256 sεr TABLE 34
Error Address Code Sequence Source Statement
DC3C 7D 0036 2257 TST HUNGUP Have we already had a hangup interrupt? DC3F 26 25 2258 BNE 1$ Yes - then avoid doing any hookflash DC41 BD D17C 2259 JSR DOONH Put phone onhook DC44 17 2260 TBA Place the duration in A (n x 1/10 seconds) DC45 BD DB5C 2261 JSR DELAY DC48 BD D17C 2262 JSR DOOFH Take phone offhook again DC4B 86 01 2263 LDAA #1 Give mechanical parts time to work DC4D BD DB5C 2264 JSR DELAY DC50 96 A0 2265 LDAA DTMFCP Clear any DTHF/silence interrupts DC52 86 08 2266 LDAA #$08 Clear any MUX interrupts DC54 97 AD 2267 STAA IRQFLG DC56 BD D201 2268 JSR LOPBRK See if there was a break in loop current DC59 26 0B 2269 BNE 1$ Loop current present
2270 * Far-end hangup has occurred; deal with it
2271 * (i.e. go onhook, disable silent/DTMF irqs, enable MUX irqs,
2272 * set any flags needed, and put hangup key in keys buffer)
DC5B 7C 0036 2273 INC HUNGUP Count another hangup IRQ DC5E BD D4F5 2274 JSR GRNDIT Go onhook; select "ring interrupt" as MUX IRQ DC61 86 12 2275 LDAA #HANGUP Put hangup key in buffer
2276 * be sure an SEI command is in effect before doing the JSR INKEY
DC63 BD E70F 2277 JSR INKEY Put the key in A into keys buffer DC66 0E 2278 1$ CLI Allow interrupts again DC67 39 2279 RTS
2280 *
2281 * Dial the directed call pickup sequence
2282 * Inputs: this routing requires the extension to be in COMRAM
2283 * (so don't switch the COMRAM banks once POISED has set them up)
2284 * DCPSEQ is a string of up to 13. bytes, coded as follows:
2285 * H,W,X = IFPSHF, $57, $58 respectively
2286 * digits [0] thru [9] = $80 thru $89
2287 * digits [*],[#] = $8A, $8B respectively
2288 * terminator = FF (so up to 12. bytes are useful)
2289 * The extension will be passed in COMRAM as follows:
2290 * Terminator (COMRAM byte $00) signifies end of extension
2291 * Zero (COMRAM byte $01) converts to $00 for DTHTON
2292 * One (COMRAM byte $02) converts to $01 for DTMTON
2293 * etc. etc.
2294 * Nine (COMRAM byte $0A) converts to $09 for DTMTON
2295 * [*] (COMRAM byte $0B) converts to $0A for DTMTON
2296 * [#] (COMRAM byte S0C) converts to $0B for DTMTON
2297 * Terminator (COMRAM byte $10) converts to $0F ; end of ext.
2298 *
DC68 CE D04E 2299 DODCP LDX KCCPSEQ Index to the directed call pickup sequence
DC6B A600 2300 1$ LDAA 0,X Get next char in sequence
DC60 81 FF 2301 CMPA #$FF DCP Sequence terminator ?
DC6F 2741 2302 BEQ 9$ Yes - so jam
DC71 91 28 2303 CMPA IFPSHF Is this a hookflash request ? TABLE 34
Error Address Code Sequence Source Statement
DC73 2604 2304 BNE 2$ No DC75 80 C1 2305 BSR DOSHF Do a short hookflash DC77 20 36 2306 BRA 8$ Go on to the next char DC79 81 57 2307 2$ CHPA #$57 Is this "W" (1 second wait) ? DC7B 26 07 2308 BNE 3$ No DC7D 86 0A 2309 LDAA #10 Delay 1 second DC7F BD DB5C 2310 JSR DELAY DC82 20 2B 2311 BRA 8$ Go to the next char DC84 81 58 2312 3$ CMPA #$58 Is this "X" (dial the extension) ? DC86 26 1C 2313 BNE 7$ No 2314 *********** dial the extension in COMRAM
DC88 FF D035 2315 STX XTEMP Save our index DC8B CE 3000 2316 LDX #COMRAM Index the first digit in COMRAM DC8E A6 00 2317 5$ LDAA 0,X Get the next digit DC90 27 0D 2318 BEQ 6$ COHRAH terminator; we are done dialing extension
DC92 4A 2319 DECA Remove COHRAH offset DC93 84 0F 2320 ANDA #$0F Strip off upper nibble (just in case) DC95 81 0F 2321 CMPA #$0F Is this a COMRAM terminator? DC97 27 06 2322 BEQ 6$ Yes DC99 16 2323 TAB Pass the char in B to DCPDIL DC9A 8D 17 2324 BSR DCPDIL Dial the digit, and fall into 8$ DC9C 08 2325 INX Burp to next digit in the extension DC9D 20 EF 2326 BRA 5$ Keep looping until COMRAM terminator encountered
DC9F FE D035 2327 6$ LDX XTEMP Recover our index DCA2 200B 2328 BRA 8$ and process the next char 2329 ***********
DCA4 81 8B 2330 7$ CMPA #$8B Is this a digit [0] - [9] , [*] , [#] ? DCA6 22 07 2331 BHI 8$ No ; ignore out-of-range characters DCA8 81 80 2332 CMPA #$80 Is this a digit [0] - [9], [*], [#] ? DCAA 25 03 2333 BCS 8$ No; ignore out-of-range characters DCAC 16 2334 TAB Pass the char in B to DCPDIL DCAD 80 04 2335 BSR DCPDIL Dial the digit, and fall into 8$ DCAF 08 2336 8$ INX Bump to next char in sequence DCB0 20 B9 2337 BRA 1$ Keep looping until DCPSEQ terminator encountered
DCB2 39 2338 9$ RTS 2339 * 2340 * Dial the digit passed in B 2341 * B contains $x0 thru $x9 for digits zero thru nine, 2342 * and B contains $xA for [*] , and B contains $xB for [#] 2343 * Note that DTMTON does not care about the upper nibble. 2344 * Be sure to preserve X throughout this routine. 2345 *
DCB3 96 AE 2346 DCPDIL LDAA IRQENB Save interrupt enable byte DCB5 97 02 2347 STAA XADD2 TABLE 34
Error
Address Code Sequence Source Statement
DCB7 963B 2348 LDAA TONSIL Save tone/silent enable byte
DCB9 B7 D031 2349 STAA TMPSIL
DCBC 96 04 2350 LDAA VIAPC Save transition settings of MUX and CB1 IRQs
DCBE 97 03 2351 STAA XADD2+1
DCC0 BD D1D4 2352 JSR D00TI Disable tone interrupts
DCC3 BD D1E1 2353 JSR DODSI Disable silent interrupts
DCC6 BD D1B4 2354 JSR DOOMI Disable MUX IRQs
DCC9 17 2355 TBA Get the tone to issue
DCCA BD DAAA 2356 JSR DTMTON Issue the DTMF tone
DCCD D6 A0 2357 LDAB DTMFCP Clear any tone interrupts generated above
DCCF D6 03 2358 LDAB XADD2+1 Restore CB1 and MUX IRQs to former value
DCD1 D7 04 2359 STAB VIAPC
DCD3 D7 AC 2360 STAB CA2CB2
DCD5 F6 D031 2361 LDAB TMPSIL Restore TONSIL byte to former value
DCD8 D7 3B 2362 STAB TONSIL
DCDA D6 02 2363 LDAB XADD2 Restore IRQ enable byte to former value
DCDC D7 AE 2364 STAB IRQENB
DCDE 39 2365 2366 * 2367 * Check for reorder/busy tone within a 1 second window 2368 * Returns: 2369 * EQ = reorder or busy tone (A = $00) 2370 * NE = not reorder tone, specifically: 2371 * A = $01 : answer/voice detected, hangup occurred 2372 * A = $82 : silence 2373 * Note that we do not set up MTRTYP here because we assume this is 'R 2374 * type of call progress. We also do not bother with TMR_C1 (INTTMO and 2375 * EXTTMO) since the RNA timer interval is too long for our purposes here.
2376
DCDF 7D 0036 2377 CK4RDT TST HUNGUP Have we already had a hangup interrupt?
DCE2 27 03 2378 BEQ 1$ No, then we can proceed with call progress
DCE4 86 01 2379 LDAA #$01 Yes; at any rate, it is not reorder tone
DCE6 39 2380 RTS
DCE7 C6 01 2381 1$ LDAB #1 Flag that we are doing call progress
DCE9 F7 D03E 2382 STAB CPENBL
DCEC C6 C0 2383 LDAB #$C0 Set bit 6 of IRQENB to enable T1
DCEE D7 AE 2384 STAB IRQENB
DCF0 7F D025 2385 CLR ENERGY Reset call progress
DCF3 7F D026 2386 CLR LSTPCK
DCF6 7F D027 2387 CLR NRGCNT
DCF9 7F 004A 2388 CLR EDGFLG Start with no edge detected yet
DCFC 7F D02C 2389 CLR DTEKT Clear the voice detection counter
DCFF 86 14 2390 LDAA #20 Initialize 20 msec timer
DD01 B7 D023 2391 STAA TMR_C4
DD04 B0 D1E1 2392 JSR DODSI Disable silent interrupts
DD07 96 38 2393 LDAA VIARA TABLE 34
Error
Address Code Sequence Source Statement
DD09 8A 02 2394 ORAA #$02 Force zero/APT high (ready for speech)
DD0B 84 FB 2395 ANDA #SFB CVSD direction = input
DD0D 9738 2396 STAA VIARA
DD0F 97 AT 2397 STAA CVSD10
DD11 86 FF 2398 LDAA #$FF Set clamp for recording
DD13 B7 1000 2399 STAA VOLUME
DD16 86 05 2400 LDAA #5 Set unknown state voice detect sensitivity
DD18 B7 D033 2401 STAA VOCSEN 2402 *
DD1B CE 3200 2403 LDX #COMRAM Start of debug data
+$200
DD1E FF D029 2404 STX DEBUG
2405 *
2406 * Wait for energy to begin, then time the energy to determine if ringback,
2407 * busy, or reorder. If >750 msec, assune ringback. Otherwise check for
2408 * noise or errors
DD21 7F D02E 2409 NRG$ CLR ERRFLG Indicate not in error checking DD24 7F D030 2410 CLR SAMFLG Set the no samples flag DD27 CE 03E8 2411 NR2$ LDX #1000 Allow 1 second total for edge DD2A BD DF2F 2412 JSR GETEDG DD2D 2B 18 2413 BMI CPM1$ ANSWER (voice) was detected!! DD2F 26 05 2414 BNE 6$ Some edges occurred DD31 86 82 2415 LDAA #S82 No edge in 1 second dead line DD33 7E DD49 2416 JMP CPMR$ DD36 7D D025 2417 6$ TST ENERGY See if new state is silence DD39 26 EC 2418 BNE NR2$ If not go time energy in progress DD38 86 02 2419 LDAA #$02 DD3D C6 58 2420 LDAB #88 DD3F BD DFDE 2421 JSR CMXAB Compare X to 600 msecs DD42 26 03 2422 BNE CPH1$ Branch if X>600 DD44 7E DD4E 2423 JMP CCKERS <=500 msecs,so check for busy or reorder
2424 *
2425 * ANSWER DETECTED OR ASSUMED
2426 *
DD47 86 01 2427 CPM1$ LDAA #1 Assune answer with to message
2428 *
2429 * End Call Progress Monitoring with status in A reg.
2430 *
0D49 BD DDD6 2431 CPMR$ JSR STOPT1 Disable T1 and flag "end of call progress" DD4C 4D 2432 TSTA Set the EC/NE status appropriately DD4D 39 2433 RTS
2434 *
2435 * Ringback was not detected, but some other cadence or
2436 * noise was. try to identify the cadence . . . it it's noise
2437 * go back and re-monitor. Otherwise, identify the cadence TABLE 34
Error Address Code Sequence Source Statement
2438 * and return the proper error code. Cadence is determined
2439 * within a 4 second window.
2440 *
DD4E CE OFAO 2441 CCKER$ LDX #4000 Check edges within a 4 second window DD51 FF D01F 2442 STX THR_C2 DD54 7F D028 2443 CLR EDGCNT Clear edge count DD57 CE 023F 2444 LDX #575 DD5A BD DF2F 2445 JSR GETEDG DD5D 2B E8 2446 BMI CPM1$ ANSWER detected! DD5F 26 03 2447 BNE 2$ DD61 7E DD27 2448 JMP NR2$ Can't be error tone DD64 7C D028 2449 2$ INC EDGCNT Count up an edge DD67 CE 02EE 2450 LDX #750 DD6A BD DF2F 2451 JSR GETEDG DD6D 2B D8 2452 BMI CPM1S ANSWER detected! DD6F 27 D6 2453 BEQ CPH1$ Ne edge detected, assume ANSWER DD71 7F D030 2454 CLR SAMFLG Set the no samples flag DD74 7C D02E 2455 INC ERRFLG Indicate into error checking DD77 FE D01F 2456 LDX TMR_C2 Timed out DD7A 26 E8 2457 BNE 2$ No timeout, keep counting DD7C 7C D028 2458 INC EDGCNT One more edge DD7F BD DDD6 2459 JSR STOPT1 Disable T1 and flag "end of call progress" DD82 B6 D028 2460 LDAA EDGCNT How many edges? DD85 7F S028 2461 CLR EDGCNT Clear the edge counter for NRG$ DD88 81 05 2462 CMPA #5 Check to see if it is busy DD8A 23 10 2463 BLS 4$ Not likely to be a busy tone if less frequent DD8C 81 0A 2464 CMPA #5 Check to see if it is busy DD8E 22 02 2465 BHI 3$ No . . . may be reorde DD90 4F 2466 CLRA Busy signal received, so flag success DD91 39 2467 RTS DD92 91 CD 2468 3$ CMPA #13 See if in the realm of reorder DD94 23 06 2469 BLS 4$ Not really, unknown signal DD96 81 16 2470 CMPA #22 DD98 22 02 2471 BHI 4$ Far too frequent for even reorder to be DD9A 4F 2472 CLRA Reorder tone was present, so flag success DD9B 39 2473 RTS DD9C 7E DD21 2474 4$ JMP NRG$ Return on false detection
2475 *
2476 * Wait for ringback
2477 *
DD9F 864E 2478 WT4ANS LDAA #'N Wait for answer, notify after answer detect DDA1 2006 2479 BRA WT4RB1 DDA3 8641 2480 WT4ANS LDAA #'A Wait for answer, internal call DDA5 2002 2481 BRA WT4RB1 DDA7 8552 2482 WT4RBK LDAA #'R Don't wait for answer, connect on ring DDA9 36 2483 WT4RB1 PSHA DDAA B6 D032 2484 LDAA VOCOET Get user defined detection threshold TABLE 34
Error Address Code Sequence Source Statement
DDAD B7 D034 2485 STAA VOCWRK Set initial voice detect threshold DDB0 86 03 2486 LDAA #3 Set initial edge detect to 60-80 ms. DDB2 B7 D02D 2487 STAA EDGDET DDB5 FE D017 2488 LDX PADDLI Get the pre-answer-detect delay DDB8 27 13 2489 BEQ 2$ Not need for delay DDBA FF D01D 2490 STX THR_C1 DDBD 8601 2491 LDAA #1 Signal that the timer is going DDBF B7 D03E 2492 STAA CPENBL DDC2 86 C0 2493 LDAA #$C0 DDC4 97 AE 2494 STAA CPENBL DDC6 FE D01D 2495 1$ LDX TMR_C1 Wait for delay to end DDC9 26 FB 2496 BNE 1$ DDCB 8D 09 2497 BSR STOPT1 Stop the timer DDCD 32 2498 2$ PULA DDCE FE D009 2499 LDX INTTM0 Timeout for call prog-internal-pass in X DDD1 80 12 2500 BSR RESULT Perform call progress detection DDD3 7E D402 2501 JMP ONLIN0 and return call progress status code to CINDI 2502 * 2503 * Disable the T1 timer because call progress finished. 2504 * Be careful never to trash A register in here. 2505 * Trashess B register 2506 *
DDD6 C640 2507 STOPT1 LDAB #$40 Disable T1 timer DDD8 D7 AE 2508 STAB IRWENB DDDA 5F 2509 CLRB. DDDB F7 D03E 2510 STAB CPENBL Flag that we are not longer doing call progress DDDE F7 D01B 2511 STAB TMR_OH DDE1 F7 D01C 2512 STAB THR_OH+1
Clear the on-hook timer also
DDE4 39 2513 RTS 2514 *

Claims

What is claimed is:
1. A voice processing system, including: a digital bus; a communications interface unit coupled to the bus and adapted to be connected to a telephone line, the communications interface unit including a means for digitizing voice signals received on the telephone line and transferring the digitized voice signals to the bus; and a general purpose central processing unit coupled to the bus, and including a means for receiving the digitized voice signals from the bus, and a means for processing digital signals, including the digitized voice signals received from the bus.
2. The system of claim 1, wherein the central processing unit is capable of processing both digitized voice signals and other digital signals in a single record.
3. The system of claim 1, wherein the central processing unit is capable of controlling the operation of the communications interface unit by transmitting digital instructions to the communications interface unit over the digital bus.
4. The system of claim 1, wherein the communications interface unit includes means for converting a digitized voice signal into an analog voice signal, and wherein the central processing unit is capable of transmitting a first digitized voice signal and a set of digital instructions to the communications interface unit over the digital bus, to cause the communications interface unit to convert the first digitized voice signal to a first analog voice signal and transmit the first analog voice signal over the telephone line.
5. The system of claim 1, wherein the digital bus is a VME bus.
6. The system of claim 1, wherein the central processing unit includes an initiator for establishing communication between the central processing unit and a target device coupled to the central processing unit by a Small Computer System Interface.
7.The system of claim 6, also including means for facilitating a virtual port access of the target device.
8. A voice processing system, including: a digital bus; a communications interface unit coupled to the bus and adapted to be connected to a telephone line, the communications interface unit including a means for digitizing voice signals received on the telephone line and transferring the digitized voice signals to the bus; and a general purpose central processing unit coupled to the bus, and including a memory unit and a means for receiving the digitized voice signals from the bus, wherein the central processing unit is programmed to create files for storing the digitized voice signals in the memory unit.
9. The system of claim 8, wherein the central processing unit is programmed to include a cache memory, and to create a pseudo-file in the cache memory for each digitized voice signal received from the bus, and is programmed to write each said digitized voice signal received from the bus into the memory unit using information in said pseudo-file, and then to write the information in the pseudo-file into the memory unit.
10. The system of claim 8, wherein the central processing unit is capable of generating a digitized voice menu signal, wherein the communications interface unit includes means for converting the digitized voice menu signal into an analog voice menu signal, and wherein the central processing unit is capable of transmitting the digitized voice menu signal and a set of digital instructions to the communications interface unit over the digital bus, to cause the communications interface unit to convert the digitized voice menu signal into the analog voice menu signal and transmit the analog voice menu signal over the telephone line.
11. The system of claim 10, wherein the central processing unit is capable of modifying the digitized voice menu signal and transmitting the modified digitized voice menu signal and a second set of digital instructions to the communications interface unit over the digital bus, to cause the communications interface unit to convert the modified digitized voice menu signal into a second analog voice menu signal and to transmit the second analog voice menu signal over the telephone line.
12. The system of claim 10, wherein the digital voice menu signal includes digitized voice phrases.
13. The system of claim 10, wherein the analog voice menu signal prompts a listener on the telephone line to instruct the central processing unit to execute an application program, wherein the communications interface unit is capable of receiving a digital command signal on the telephone line from the listener and forwarding the digital command signal to the central processing unit over the bus, and wherein the central processing unit is programmed to execute the application program in response to the digital command signal.
14. The system of claim 13, wherein the central processing unit is programmed to cause the communications interface unit to transmit interrogating voice signals to the listener during execution of the application program, which interrogating voice signals prompt the listener to transmit an answer signal over the telephone line.
15. The system of claim 14, wherein the communications interface unit is capable of capable of receiving the answer signal from the telephone line and forwarding the answer signal to the central processing unit over the bus, and wherein the central processing unit is programmed to generate a digital report signal in response to the answer signal.
16. The system of claim 8, wherein the central processing unit is capable of generating a tagged message signal and transmitting the tagged message signal to the communications interface unit over the bus.
17. The system of claim 16, wherein the tagged message signal includes a data signal and a prompt signal for instructing the communications interface unit to transmit a prompting message over the telephone line.
18. The system of claim 17, wherein the data signal includes a digitized voice message, wherein the communications interface unit is capable of converting the digitized voice message into an analog voice signal and transmitting said analog voice signal over the telephone line in response to receipt of the tagged message, and wherein the communications interface unit is capable of transmitting said prompting message over the telephone line in response to receipt of the tagged message.
19. The system of claim 18, wherein the tagged message includes an execute prompt signal for instructing the communications interface unit to transmit an execute prompt message over the telephone line, and wherein the communications interface unit is capable of converting the execute prompt signal into an analog execute prompt message and transmitting said analog execute prompt message over the telephone line in response to receipt of the tagged message.
20. The system of claim 19, wherein said analog execute prompt message prompts a listener on the telephone line to instruct the central processing unit to execute an application program.
21. The system of claim 8, wherein the communications interface unit is programmed to initiate a telephone call in response to a telephone station request signal transmitted by a caller over the telephone line, and to monitor the progress of the telephone call.
22. The system of claim 8, wherein the communications interface unit is programmed to execute a blind telephone call transfer in response to a transfer request signal transmitted from a caller station by a caller over the telephone line, and to go off hook and then detect the status of the remote end of the telephone line promptly after executing the blind transfer.
23. The system of claim 22, wherein the communications interface unit is programmed to transmit a first voice message over the telephone line upon determining that there is no dial tone being generated by the remote end of the telephone line.
24. The system of claim 22, wherein the communications interface unit is programmed to wait for a predetermined period of time upon determining that a dial tone is being generated by the remote end of the telephone line, and then executing a directed call pickup operation at the end of said predetermined period of time.
25. The system of claim 24, wherein the communications interface unit is programmed to transmit a second voice message over the telephone line if it detects no reorder or error tone following execution of said directed call pickup operation.
26. The system of claim 1, wherein the communications interface unit is adapted to be connected to a pair of telephone lines.
27. The system of claim 1, also including a second communications interface unit coupled to the bus and adapted to be connected to a second telephone line, the second communications interface unit including a means for digitizing voice signals received on the second telephone line and transferring the digitized voice signals to the bus.
28. A voice processing method, including the steps of: digitizing voice signals received on a telephone line and transmitting the digitized voice signals to a digital bus; receiving the digitized voice signals from the bus, and supplying them to a central processing unit; and processing both the digitized voice signals and other digital signals in a single record in the central processing unit.
29. The method of claim 28, also including the steps of: transmitting a first digitized voice signal and a set of digital instructions to a communications interface unit over the bus; converting the first digitized voice signal to a first analog voice signal; and transmitting the first analog voice signal over the telephone line.
30. The method of claim 28, also including the steps of:
storing the digitized voice signals in files in a memory unit.
31. The method of claim 30, also including the steps of:
creating a pseudo-file in a cache memory for each digitized voice signal received from the bus; writing each said digitized voice signal received from the bus into a memory unit using information in said pseudo-file; and thereafter, writing the information in the pseudo-file into the memory unit.
32. The method of claim 29, also including the steps of: generating a digitized voice menu signal; converting the digitized voice menu signal into an analog voice menu signal; transmitting the digitized voice menu signal and a set of digital instructions to the communications interface unit over the digital bus; and converting the digitized voice menu signal into the analog voice menu signal and transmitting the analog voice menu signal over the telephone line.
33. The method of claim 32, also including the steps of: modifying the digitized voice menu signal and transmitting the modified digitized voice menu signal and a second set of digital instructions to the communications interface unit over the digital bus; and converting the modified digitized voice menu signal into a second analog voice menu signal and transmitting the second analog voice menu signal over the telephone line.
34. The method of claim 32, wherein the analog voice menu signal prompts a listener on the telephone line to command the central processing unit to execute an application program, and including the steps of: receiving a digital command signal on the telephone line from the listener and forwarding the digital command signal to the central processing unit over the bus; and executing the application program in response to the digital command signal.
35. The method of claim 34, also including the steps of: transmitting interrogating voice signals to the listener during execution of the application program. which interrogating voice signals prompt the listener to transmit an answer signal over the telephone line.
36. The method of claim 35, also including the steps of: receiving the answer signal from the telephone line and forwarding the answer signal to the central processing unit over the bus; and generating a digital report signal in response to the answer signal.
37. The method of claim 29, also including the steps of: generating a tagged message signal and transmitting the tagged message signal to the communications interface unit over the bus.
38. The method of claim 36, wherein the tagged message signal includes a data signal and a prompt signal for instructing the communications interface unit to transmit a prompting message over the telephone line.
39. The method of claim 38, wherein the data signal includes a digitized voice message, and also including the steps of: converting the digitized voice message into an analog voice signal and transmitting said analog voice signal over the telephone line in response to receipt of the tagged message; and transmitting said prompting message over the telephone line in response to receipt of the tagged message.
40. The method of claim 39, wherein the tagged message includes an execute prompt signal for instructing the communications interface unit to transmit an execute prompt message over the telephone line, and also including the steps of: converting the execute prompt signal into an analog execute prompt message and transmitting said analog execute prompt message over the telephone line in response to receipt of the tagged message.
41. The method of claim 40, wherein said analog execute prompt message prompts a listener on the telephone line to instruct the central processing unit to execute an application program.
42. The method of claim 29, also including the steps of:
initiating a telephone call in response to a telephone station request signal transmitted by a caller over the telephone line; and monitoring the progress of the telephone call.
43. The method of claim 29, also including the steps of:
executing a blind telephone call transfer in response to a transfer request signal transmitted from a caller station by a caller over the telephone line; and then detecting the status of the remote end of the telephone line promptly after executing the blind transfer.
44. The method of claim 43, also including the steps of:
transmitting a first voice message over the telephone line upon determining that there is no dial tone being generated by the remote end of the telephone line.
45. The method of claim 44, also including the steps of:
waiting for a predetermined period of time upon determining that a dial tone is being generated by the remote end of the telephone line, and then executing a directed call pickup operation at the end of said predetermined period of time.
46. The method of claim 45, also including the step of: transmitting a second voice message over the telephone line upon failing to detect a reorder or error tone after executing said directed call pickup operation.
PCT/US1989/002250 1988-05-26 1989-05-24 Voice information system and method for telephone applications WO1989012271A1 (en)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US19898188A 1988-05-26 1988-05-26
US198,981 1988-05-26

Publications (1)

Publication Number Publication Date
WO1989012271A1 true WO1989012271A1 (en) 1989-12-14

Family

ID=22735714

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US1989/002250 WO1989012271A1 (en) 1988-05-26 1989-05-24 Voice information system and method for telephone applications

Country Status (2)

Country Link
AU (1) AU3761889A (en)
WO (1) WO1989012271A1 (en)

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0472386A2 (en) * 1990-08-20 1992-02-26 Texas Instruments Incorporated Digital signal processing control method and apparatus
EP0474436A2 (en) * 1990-08-31 1992-03-11 Texas Instruments Incorporated Method for communications between processors of a multi-processor system
WO1993006680A1 (en) * 1991-09-24 1993-04-01 Active Voice Corporation Configurable telephone interface for electronic devices
US5530883A (en) * 1990-03-27 1996-06-25 International Business Machines Corporation Database engine
EP1130893A2 (en) * 2000-02-29 2001-09-05 Lucent Technologies Inc. Intelligent-networked system with service for notifying and hearing selected e-mails via a public switched telephone network

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4071888A (en) * 1977-02-16 1978-01-31 Bell Telephone Laboratories, Incorporated Telephone multiline automatic voice answer system
US4375083A (en) * 1980-01-31 1983-02-22 Bell Telephone Laboratories, Incorporated Signal sequence editing method and apparatus with automatic time fitting of edited segments
US4549047A (en) * 1982-07-22 1985-10-22 Voicemail International, Inc. Digitized voice message storage system
US4554418A (en) * 1983-05-16 1985-11-19 Toy Frank C Information monitoring and notification method and apparatus
US4755932A (en) * 1985-10-15 1988-07-05 International Business Machines Corporation Interpreter program for providing commands to a computer application program

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4071888A (en) * 1977-02-16 1978-01-31 Bell Telephone Laboratories, Incorporated Telephone multiline automatic voice answer system
US4375083A (en) * 1980-01-31 1983-02-22 Bell Telephone Laboratories, Incorporated Signal sequence editing method and apparatus with automatic time fitting of edited segments
US4549047A (en) * 1982-07-22 1985-10-22 Voicemail International, Inc. Digitized voice message storage system
US4554418A (en) * 1983-05-16 1985-11-19 Toy Frank C Information monitoring and notification method and apparatus
US4755932A (en) * 1985-10-15 1988-07-05 International Business Machines Corporation Interpreter program for providing commands to a computer application program

Cited By (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5530883A (en) * 1990-03-27 1996-06-25 International Business Machines Corporation Database engine
EP0472386A2 (en) * 1990-08-20 1992-02-26 Texas Instruments Incorporated Digital signal processing control method and apparatus
EP0472386A3 (en) * 1990-08-20 1992-12-02 Texas Instruments Incorporated Digital signal processing control method and apparatus
EP0474436A2 (en) * 1990-08-31 1992-03-11 Texas Instruments Incorporated Method for communications between processors of a multi-processor system
EP0474436A3 (en) * 1990-08-31 1992-12-02 Texas Instruments Incorporated Method for communications between processors of a multi-processor system
WO1993006680A1 (en) * 1991-09-24 1993-04-01 Active Voice Corporation Configurable telephone interface for electronic devices
EP1130893A2 (en) * 2000-02-29 2001-09-05 Lucent Technologies Inc. Intelligent-networked system with service for notifying and hearing selected e-mails via a public switched telephone network
EP1130893A3 (en) * 2000-02-29 2003-08-13 Lucent Technologies Inc. Intelligent-networked system with service for notifying and hearing selected e-mails via a public switched telephone network
US6862342B1 (en) 2000-02-29 2005-03-01 Lucent Technologies Inc. Intelligent-networked system with service for notifying and hearing selected E-mails via a public switched telephone network

Also Published As

Publication number Publication date
AU3761889A (en) 1990-01-05

Similar Documents

Publication Publication Date Title
US6542584B1 (en) Digital telephone system with automatic voice mail redirection
AU670263B2 (en) Automated attendant for any combination of PBX, CENTREX and single-line telephones
JP3101768B2 (en) Voice Call Notification and Message Control by Data Path
AU758840B2 (en) Automatic call distribution system with signal generator and method
US5835572A (en) Customized, billing controlled call bridging system
JP3201765B2 (en) Digital computer platform to support telephone network applications.
US5259024A (en) Telephone answering service with integrated voice and textual message storage
CA1207874A (en) Call interceptor
EP0255325B1 (en) Call transfer between a message service system and a telephone switching system
EP0588101A2 (en) Message storage and retrieval systems employing selective caller processing
JP2004500738A5 (en)
WO1990003700A1 (en) Telephone answering service with integrated voice and textual message storage
JPS61500089A (en) Method and apparatus for transmitting data messages to selected telephones during silent periods between ringing signals
JPH06510402A (en) voice service equipment
JPS61500094A (en) Method and apparatus for providing call tracing services
US5063592A (en) Control of non-locally switched telecommunication services
EP0774196B1 (en) Service node for a telephony network
WO1989012271A1 (en) Voice information system and method for telephone applications
US4646342A (en) Test trunk access controller
JPH0322659A (en) Voice message transmission system
Perdue et al. AT&T voice processing system architectures
US7539289B2 (en) Selective deactivation of a voicemail system
KR920002207B1 (en) Voice mailing system
KR100273631B1 (en) Method for rejection informming of incomming call to subscriver in priviate exchange
JP2855026B2 (en) Proxy response method

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): AU DK NO

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): BE DE FR GB IT NL SE