In 1986, a contact in Mexico's electronics industry called me with a question engineers can't say no to.

He was heading to a major trade show in Mexico City. Every competitor would be there, all selling the same thing: AC voltage regulators. His ask was simple —

"Can we make ours talk to the user when something goes wrong?"

I said yes before thinking it through. That's usually how the best projects start.

The Hardware Problem

The core component was the SPO256 from General Instruments — an allophone-based speech synthesizer with phoneme data stored in internal ROM. The interface was parallel: feed it an address, get a sound.

The catch: all phonemes were designed for English. Our market was Spanish-speaking. Building intelligible Spanish words from English allophones meant mapping plosive and approximant sounds across two phonetic systems — entirely through listening, iteration, and a lot of patience.

For the microcontroller, I used an Intel MC8748 — a windowed UV-erasable EPROM version, right for a prototype that would need multiple flashing cycles.

The Firmware Structure

Simple by design:

• Monitor digital trigger inputs from the regulator's protection circuits
• On trigger, look up the corresponding phrase in a table
• Reproduce the allophone sequence with precise inter-phoneme timing

The table used a 7-bit allophone index. The MSB was a flag: if set, the remaining 7 bits encoded a delay before the next allophone — not a phoneme, just timing. End of sequence: 0xFF, the natural erased state of EEPROM.

First byte of each phrase = sequence length. No separate length table needed.

The Tool That Accelerated Everything

Before finalizing the phoneme tables, I built a small utility: a Pascal program that sent ASCII codes through a Centronix parallel port to the prototype board. One code = one allophone, instantly. No reflashing.

It let us iterate in real time — send a code, hear the result, adjust. That compressed weeks of calibration into days.

This pattern still holds: the best embedded teams build their own development tools. The upfront investment pays back on every iteration cycle.

The Result

Wire-wrapped prototype. Fit inside the large-chassis regulator. Demo at the trade show.

A trade publication covering the computing industry ran a piece on it. The competition wasn't mentioned. That was the point.

That project became my first product venture — and the clearest early proof that good embedded engineering isn't just about making hardware work. It's about understanding what a product needs to accomplish, and building exactly that.

The fundamentals haven't changed in nearly 40 years.