"Squawk and Talk" Sound Module. by Clive Jones, July 1996.
Preface. We're really going to tear the Squawk and Talk board apart with this article - so get ready for some heavy "tech talk". Before I start, I would like to thank fellow Englishman, pinball partner and RGP'er Pete Clare for providing the data sheets on the TMS5200, TMS6100 phrase ROM and the AY3-8912 PSG which saved me from pulling half my hair out. This has been the most challenging technical article I have yet written. The main problem being that both the MPU board game code and the Squawk and Talk code changed for every game that Bally produced. There are also a few software "mysteries" to contend with. Without actually hacking every peice of game/sound code and having access to every Squawk and Talk board ever released, it is impossible to conclusively say "this happens in every game". Therefore, I've tried to base the foundations of the article on as much reverse engineering as I could possible do. For note: Squawk and Talk never used the 6100 phrase ROM although the board design caters for it's inclusion, all speech data is encoded and held with (EP)ROM.
Quick glossary.
Introduction. The squawk and talk has 11 major IC's in it's memory map (count 12 if your board has a 6810 installed in the socket at U6). These are; These aren't the only IC's on the board, they're just the most noticable. The others we will come to later. [Note: As with Williams pinballs of the era, a Bally Sound board could be fitted with either a Motorola 6802 or a 6808 microprocessor. The 6802 contained 128 bytes of NMOS RAM that had to be selected by pulling the 'RE' (RAM Enable) line high, otherwise a 6808 was used. The RE line was grounded (via jumper "L") and a 6810 RAM IC (128 bytes) was located at U6 on the Squawk on Talk board. When a 6802 is used the RE line is strapped to the reset line of the processor (via jumper "k") which is held high during normal operation].
Memory map.
Power. The +5 volts required for the logic and the positive rail for TMS5200/6100 is generated by the LM323 5-volt regulator VR1 (lower right corner of the board, the larger of the two heatsinks). This regulators input is supplied from the 12 volt unregulated supply which also supplies the power for the test LED. The same unregulated 12 volts is filtered by the 4700uF/25v capacitor at C14 to remove unwanted AC ripple and supply DC power to the TDA2002 mono power amplifier. The 7905 (the "9" indicates negative voltage as opposed to a 7805 which is a positive 5 volt regulator) -5 volt regulator at VR2 provides the negative voltage to the split-rail TMS5200/6100 ICs. This voltage is generated from the 6.3v lamp supply and is *doubled* then *inverted* on input to provide -12.6v. The 6.3 volt lamp supply is too low an input voltage for the regulator as it requires at least -7.5 volts on it's input to output a steady -5 volts supply. The -5 volt regulator does not require a heatsink as the only devices drawing on it are the TMS5200/6100 speech ICs.
ROMs. It's always a good idea to transfer the data in those mask ROMs to EPROM and keep a binary file of the ROM image stored safely away somewhere (on your hard disk for example) if you have access to an EPROM programmer.
Speech Generation The 5200 uses a method of data compression known as pitch excited "Linear Predictive Coding" or "LPC". The 5200 can only process data compressed with this algorithm. Speech data held in the S+T EPROMs is compressed in this manner. Although the 6100 VSM was never used, I'll make reference to it's inclusion here as the board was designed with it's use in mind. This will explain the achitecture and data transfer based around the 5200 VSP and 6100 VSM. The method by which the 5200 communicates with external devices with regard to the S+T processor is the same for both the 6100 VSM and EPROM. The 6100 is connected directly to the 5200 which controls the addressing and fetching of speech data from the 6100 for internal processing after *first* receiving commands from the Squawk and Talk 680x CPU via the PIA at U7. When Squawk and Talk is required to generate speech *without* the 6100 VSM in U9, the LPC encoded speech data is held in EPROM and accessed through the PIA to the 5200 VSP. With this method of data transfer, the 5200 is instructed to operate in a mode known as "speak external". In other words the CPU says "forget about getting data yourself from the 6100 VSM ROM ('cause it's not there), - I'll give you the data directly". I'll make all references to speech generation using the 6100 VSM from this point as it's a little more complex and less boring than refering to how the CPU transfers byte-wide compressed data through a PIA to the 5200 VSP (but the 5200 processing description is the same no matter where the VSP gets it's data from). The Squawk and Talk 680x has access to the 5200's internal address pointer, which it modifies to point at new phrases in ROM. The CPU then instructs the 5200 to fetch data from that address and process it for output as speech. 6100 ROM speech data is received into the 5200 in *serial* form (one bit after another on the same line as opposed to 1 line for every bit) which undergoes serial to parallel conversion before being stored in the 5200's 16-byte internal buffer/stack. Amazingly, the 6100 is a 28 pin device but only 10 pins are used, the other 18 are *not* internally connected. The TMS5200 is a microprocessor in it's own right. It handles data and addressing of the 6100 with minimal external CPU interaction. It also provides the bus timing for for synchronous data transfer between the 6100 and itself. The TMS5200 is too slow to place directly on the 680x microprocessor bus. The 680x would be waiting for a response/acknowledgement (forcing a CPU to wait in this manner is known as inducing a "wait-state") whilst it could be off performing other tasks. Therefore, a 6821 PIA is employed at U7 which acts as a parallel interface for the 680x CPU to pass command/speech data. Because the 5200 is not directly connected to the 680x address bus, it does not occupy address space, instead, only the PIAs address space (4-bytes) are visable to the CPU as the PIA is "blocking" the path between the CPU and the 5200. When the CPU wants to talk to the 5200 it has to do it through the PIA (the same thing occurs for the 8912 PSG as we'll see later). The 680x can write parallel (8-bit) command/speech data to the 5200 through the PIA which then controls the hardware side of interfacing/handshaking with the 5200, and therefore, does not have to wait for a response. The 5200 interrupts through its pin 17, "INT" (interrupt), via the edge sensitive CB1 line of the PIA when it requires data to be transfered to its internal stack, which in turn interrupts the 680x via the IRQ line. The 5200 "excites" digitally encoded speech by using an internal digital filter to simulate the vocal tract of the human voice. The exact description of LPC encoding is not a trivial matter to put into easy to understand English if your not technically minded. The procedure (as with most speech processing) is a complex one, it goes something like this; LPC synthesizes human speech by recovering from the *original* recorded/sampled speech enough data to contruct a time-varying digital filter which attempts to model the vocal tract of the human voice. This filter is further "excited" with a digital representation of either glottal air impulses (for voiced sounds) or the rush of air (for un-voiced sounds). The filter model is then passed through the internal digital to analogue converter which outputs the final analog speech waveform. The 5200 VSP *does not* encode speech data "on-chip" (unlike the CVSD speech ICs we're used to seeing which can both encode and decode). A seperate program/hardware is required to perform the encoding by analysis of the speech samples. The LPC analysis program begins with a set of digitized speech samples, which are usually derived by passing the analogue speech through an analogue to digital converter (ADC) at a sample rate of 8 or 10KHz. Consecutive samples are grouped together to form a "frame" of samples for analyzing - anywhere between 50 and 400 samples may form 1 frame, but typically it is 200 samples. The LPC analysis program takes each frame, then calculates the pitch, energy and spectral coefficient by *pre-emphasizing* the speech samples. The frames are then stored in serial data form within the 6100 VSM for recall or as parallel encoded speech data in EPROM. This LPC method of speech encoding compresses speech data from 100,000 bits/sec (raw speech data) to about 4800 bits/sec. The analyser program reduces this figure still further - 2000 bits per second or less by cleverly taking it's own 10 bit speech parameters and compressing them to between 3 and 6-bit codes (depending on whether all the parameters were used - if the sound is voiced or un-voiced). Speech encoded data received by the 5200 is then un-packed and tested internally for validity before having the energy, pitch and spectral data associated with the sample stored in RAM for the modelling/conversion to occur. The internal 128-bit FIFO stack (First In First Out - also know as the "buffer") is arranged as sixteen 8-bit bytes to hold speech data passed to it/fetched from the 6100/S+T EPROM. As the data is pulled from the stack it is passed to the internal DAC for conversion to speech before being ouput as the final vocal phrase to the amplification circuits. If the 5200 stack decrements to 8 bytes or less (half empty), it raises an IRQ onto the squawk and talk 680x via the PIA to ask for a command to fetch more data. The 5200 also raises an interrupt when the 5200 has finished speech processing and requires more data to process from the 6100 ROM/S+T EPROM. 5200 interrupts: The 5200 asserts "INT" on three occasions but they are basically the same thing...
The three conditions above are given as flags in the 5200's internal status register which the 680x can read at anytime to establish the current condition of the chip. This means that the 5200 data transfer by the Squawk and Talk 680x is "interrupt driven". The 680x CPU upon receiving an IRQ request from the PIA at U7 knows that the 5200 has processed it's data (the interrupt is determined by examining the PIAs internal interrupt flags) and the CPU can transfer the next command or directly modify the 5200's speech phrase address pointer and therefore, indirectly, speech data to it. The conversion of speech data by the 5200 introduces an unwanted gift - "digital conversion noise", this is a common problem when performing digital to analogue conversion of audio or speech data. To overcome the high frequency noise which has been superimposed onto the speech phrase, a "Low Pass Filter" (LPF) is used which attenuates speech phrases at a rate of 12db per octave above 5KHz. One quarter of U13 (one amp) - a LM3900 Operational Transductance Amplifier is used as a second order LPF. The speech is "cleaned up" and rounded off. I think this matches the speech bandwidth that Williams had at the time using CVSD technology (Continuous Variable Slope Delta modulation) - but don't quote me on it. The speech is then fed into a "voltage controlled amplifier" (VCA) at U14 (another LM3900 op-amp), to be, erm...amplified, before being further fed into the 8 watt TDA2002 mono power amp (U18) which drives the 8 ohm speaker. The VCA's output amplitude can be directly controlled by a "control voltage" (CV) at it's input - hence it's name. The VCA control voltage is generated by the another amplifier in the LM3900 OTA at U13 which is acting as a DAC. The DACs output amplitude is controlled by "weighting" it's input with 4 resistors in series with the PIA port B output at U7 (pins PB4 through PB7 to be exact). The 4-bit code passed to the DAC from the PIA allows for 16 steps of amplification which translates to 16 different speech output levels at the VCA, and ultimately, the power amp.
Sound Generation.
Gain Control. Bally give you the option of disconnecting the local speech pot (R69) and the sound pot (R70) or the VCAs (if connected) with wire jumpers so that remote 1k pots can vary the speech/sound gain and mix. Remove jumper "m" and install jumper "n" for the remote speech pot and remove jumper "cc" and install jumper "dd" for the remote sound pot. If you so wish, you could disconnect both R69/70 *and* the remote pots in the cabinet/coin door and control the amplification/sound+speech mix by audits alone (VCA control). As with the AS2518-xx MPU boards, Squawk and Talk's PIAs are wire OR-ed together. The internal interrupt flags of both the PIA at U7 and the one at U11 need to be examined by the 680x to determine which PIA was making the request.
Other circuits. Two inverters are used in series and a tap off is made at the output of the first inverter (pin 2) and fed into the "power sequencer" circuit for the TMS5200/TMS6100 speech ICs. This circuit provides +/-5v to the 5200/6100 via three PNP transistors (Q3-Q5). The circuit does not allow power to the speech ICs until the correct reset timing has occured. The second in-series inverter is used to correct the state of the reset signal to the 680x reset pin. (The reset line is high to the 680x during normal operation but enters the speech "power sequencer" circuit *low* during normal operation to switch on the PNP transistors). Fortunately Bally got rid of the two-phase clock generator and clock buffers using multivibrators used on previous 680x based boards and replaced them with a 3.58Mhz crystal oscillator wired between pins 38 and 39 of the 6802/8. This makes fault finding the clock signals significantly easier (check the clock directly at the 680x pins). A 74LS155, - a dual 2 of 4 decoder/demultiplexer at U17 is used to generate chip select signals for all the memory mapped devices (ROMs, PIAs, DAC...) on the bus by decoding address lines A11-A15 in conjunction with the VMA (Valid Memory Address) signal ouput by the 680x (pin 5) on either a read or write cycle. The 6810 RAM at U6 ($00-$7F) also uses this address decoder. It is automatically *deselected* when A7 goes high ($xx8x) and when the address on the bus exceeds $0FFF (1st 4k-byte boundary - start of DAC address space). The 680x does not need to issue an address onto the bus when the internal RAM is selected using a 6802, therefore the address decoder has no bearing. No bus drivers are used on S+T as only one device will be active on the bus at any one time, and the 680x has adequate power to drive the one TTL load each device will represent (the other devices will be "tri-state" - in "standby").
Capacitors. Some well known US pinball repairers have capacitor replacement kits available (and I'm not sure all the caps I've listed are in the kits). In the UK, you can get these common electrolytic caps from RS components, Maplin and possibly Tandy (I get mine in work!). The 16 axial capacitors in question are...
A word of WARNING: Nearly all capacitors today have the *negative* terminal marked with a black arrow on the capacitor can. On S+T the opposite occurs. I've just looked at two boards and the old capacitors are marked showing the *positive* terminal, the board also has the positive terminal silk screened on it's surface. MAKE SURE YOU GET THE POLARITY CORRECT! If you insert a capacitor around the wrong way then apply power (give it a reverse voltage) the dielectric will be removed from the anode and a *large* current will flow as oxide builds up on the cathode. This causes a gas build up and that's what makes the cannisters EXPLODE!
Self test. For some reason better known to Bally, the ROMs do not appear to be tested - there is no provision for them in the self-test. Whether they are actually tested by checksum for validity but not displayed as part of the test, remains a mystery. In this case, it is probable a board could pass the test but output bad audio data or run corrupt operating system code! It could even run a corrupt self-test routine!
After power-up and the correct reset timing/voltage regulation, the LED briefly flickers (for approx 300 milliseconds) before; (Quick note: The 6820/1 PIA configure themselves after system reset. This configuration is incorrect for in-game operation. The S+T CPU has to reconfigure the PIA, reprogram it, to perform the necessary functions within the system. The LED flickers briefly whilst this occurs.)
*First Flash* If you have a 6802 installed in your S+T then the *internal* 128 bytes of RAM are tested and *not* U6 providing the 680x's RAM Enable line (pin 36) is strapped high (to the reset line) via jumper "k". The software doesn't care where the RAM is physically, as long as there is RAM at page zero (it's transparent to the software). The test program attempts to write a bit pattern to address $0000, starting with $00 and counting up to $FF. If the test program sucessfully manages to write and then read back (validate) the count, it then moves onto the next byte $0001, until all 128 bytes have been checked. 256x128 = 32,768 write cycles with validation. If this is sucessful, the LED flashes for the *first* time (the initial flicker is not counted as a flash). If your using a 6802 and the RAM test fails (you don't get the first flash) - you might be lucky. Move jumper "k" (the internal RAM Enable jumper) to position "L" and install a 6810 RAM IC in U6 then run the test again, else, you'll need to change the 680x (the internal architecture is damaged). An interesting point here. Pinball Lizard listed a problem in their tech tips #34 with the self test button on S+T not being debounced which sometimes causes the board to crash after attempting a test. Because the switch is not debounced, the switch contacts make and break a number of times translating to a *number* of valid NMI requests to the 680x. The stack and workspace RAM in S+T is only 128 bytes wide (page zero $0000-$007F, the exact stack length is unknown to me). The 680x has to save the contents of it's internal registers onto the stack when it encounters an NMI (or IRQ) interrupt. A number of interrupts recieved in this manner will cause "nesting" (interrupts are "queued" to be processed in last in first out [LIFO] order) and the most probable cause of the board crashing is the stack overflows, wraps around, and starts to overwrite itself wiping out the data previously saved onto the stack. The conclusion? The CPU crashes because it pulls data off the stack that didn't match the data it originally saved. Power-cycling is the only option to clear the problem (there is no reset button on S+T). The problem is further agrovated by the fact that speech data transfer requires an IRQ interrupt - further stack usage translating into IRQ and NMI data colliding caused by the over-write when the 680x "pops" (pulls data off) the stack.
*Second Flash*
*Third Flash*
*Fourth Flash*
*Fifth Flash* [Bally state: "Every time a write to the speech chip is performed, the speech chip responds with an acknowledgement."] Note that Bally's test documentation is misleading here because it is so vague. The 5200 *does not* acknowledge every byte sent to it except in the above case. That is, if the buffer contains more than 8 bytes it will not assert "INT" and therefore will not acknowledge. If the buffer is at max (16-bytes) it changes the state of it's "ready" line (pin 18) connected to the PIA effectively telling the 680x not to pass more data until the 5200 asks for it (it's "not ready"). If the test is successful the LED flashes for the fifth and final time and the PIAs are initialized to their correct configuration in readiness for game operation (waiting for a sound select interrupt from the MPU board). If the test fails then swap out the PIA for the reasons indicated in the 4th flash test above, else, swap-out the 5200 and/or check the sockets. Check the state of the 5200 supply pins (pin 4 - [+5v], pin 5 [-5v]) as the power sequencer circuit may be faulty.
End of document. * Go to the Bally Repair Guide Part 1 * Go to the Bally Repair Guide Part 2 * Go to the Bally Repair Guide Part 3 * Go to the Pin Fix-It Index * Go to Marvin's Marvelous Mechanical Museum at http://marvin3m.com |