Author archives: Fred Beckhusen

Automotive Burglar Alarm

NEED

MTSI was asked to perform a technical audit of a new generation automotive burglar alarm for the Ford Taurus automobile.  The client was behind schedule after a year of development, and could not meet their customers requirements.   

The client had already promised the Ford Motor Company that the new product would be available in only sixty days.   A major contract could be lost if the product was not ready.   

The gate array that had been designed was not working, and it could not be made to work without a major re-design effort taking many months.  Also, the design was intended to fit completely within a single housing, and there was no room for all of the circuits. 

SOLUTION

MTSI proposed a redesigned automotive burglar alarm that would use a one-time programmable microcomputer instead of a gate array.   The long lead time for parts was eliminated, and the software could be easily modified after testing without waiting for new mask parts.

A high temperature plastic housing was needed to hold the electronics between the firewall and exhaust pipe.  By working closely with a local plastics prototype house,  we were able to modify the tooling drawings to allow the necessary electronics to fit.

The electronics for the relays,  horn,  vibration sensors,  battery backup, radio receiver and hand-held two-transistor key ring radio transmitter were completely redesigned.  A printed circuit card was designed to fit the new plastics housings. 

Software was developed using assemblers and simulators on our local area network.  A key ring demodulator circuit was eliminated by careful software code writing.  

RESULTS

After many hours of hard work,  the design was proven. A completely functional system was shipped to Ford for testing on the 60th day of the project.

The ProFX Laser Projection System

A 6′ tall person standing in front of a 30′ wide by 40′ tall screen shows the capabilities of the new projection system.  Yoshi is about 5’5″ so you can get some idea of the scale.

Linden Laser Systems now shows and supports the ProFX giant screen color projection television system. Intended for trade shows and rock concerts, the system has attracted a great deal of attention from major entertainment companies.

Red/Green/Blue laser beams are steered by the motor which spins at over 80,000 RPM! Paul Linden, President started this project with the vision of the best and brightest projection TV system with the capability of growth to High-Definition TV.   One year after Paul and Stan asked Mitsi to develop this product, their ideas were hardware in their hands – a laser projection system with Mitsi electronics.

A unique feature of the ProFX laser projection system is the ability to create stunning images whether the screen surfaces are flat or irregular, solid or fluid, or single or multiple. Automated pan and tilt allow you to move the image from one surface to another; from one shape to another; from one plane to another; or project an image on multi-distance planes – all in perfect focus and perfect sync with input time codes.

Fortunately, the user does not have to be concerned with the complexities of the system. After connecting electrical power, cooling water and a video source, it takes only ten buttons on a portable display to control it.

Mitsi engineers faced many challenges in designing the electronics of the system. Paul Linden of ALP, as the optical and system designer, faced even more difficult challenges in achieving the high brightness of the system.

When the system developed a shaky picture before a key client demonstration, something had to be done. A new vertical waveform board was quickly assembled by Manufacturing Supervisor Alex Lang, tested by Tommy Buie, and quickly rushed to ALP and plugged in. Within minutes, the system was ready to go again. Without the team spirit between Mitsi engineers and Paul and Stan, the demo would have failed.

The electronics system fills up two 19″ chassis with power supplies, a customized computer, analog video cards, and ECL and TTL digital cards. A total of 9 different 2, 4, and 6 layer printed circuit boards were designed for the ProFX. The ProFX multi-plane imager contains computerized variable aspect ratio to adjust which electronically adjusts to any configuration from 1:1 to 2:1.

Both built-in and customized presets allow the system to instantaneously switch between ratios – including the television standards of 4:3 and 16:9.

The system uses two Argon ion and one Red dye laser for independent modulation of Red, Green, and Blue signals. Output power is in excess of 4.5 watts, with a contrast ratio greater than 300 to 1.

 

A bit of Z80 history

If you used a Z80 chip back in the 1980’s, it almost certainly passed through this room. This photo is of the first Fairchild Sentry 610 test system at Mostek We tested every Z80 chip including Zilog branded ones in this room for many years. (photo from Mostek 1973 databook). We also tested Fairchild F-8 CPU chips, and exotic parts such as the Magnavox “Star” TV tuner chips. It was general purpose and could test RAMs, calculators, and ROMS, though we made our own custom testers for those. This room pretty much did all the heavy lifting on all the early CPU chips. Mostek had a second source license for many of the the popular CPU chips – the Fairchild F-8 series, the Z80, the Intel 8088/6, and the Motorola 68000 family. And we invented the multiplexed DRAM, too.

 

 

The machine was a beauty. Going clockwise from the upper left side is the disk drive, a 9 track tape, the Fairchild 24-bit CPU, a terminal and printer, the Sentry 610 Tester ( tall box on the right), and a pair of 64-pin test heads. The door to this temperature and humidity controlled room is on the right, in the back, down the ramp to the right.

*The disk* was a head-per-track unit, with a large platter rotating on its side. It was 26 inches in diameter and stored 75,000 bits. This particular disk developed flakies in 1974, so I was elected by the bosses to drape it with plastic, crawl under, and spend a shift carefully wiping the surface of it with alcohol. It worked, to my surprise. I remember that the surface looked like raw steel instead of the oxide that I expected..

*The CPU* was a Sentry 400 series CPU running “Factor”, their test language. I still have the test handbook for it. It was 24 bits wide at about 250 Khz. There were two boxes of cards, about 12″ X 18″, and 12 boards with 2-bit slices per board. You could access it by pulling the black latch on the left side, and swinging open the door. On the front of the CPU was a LED bank behind plexiglas to make das blinkenlights.

I remember this CPU had a “short” and “long” bus that was mapped to the various peripherals. One night it failed to boot, which would cost a few thousand dollars an hour. I assigned a technician in training to fix it and I went off to do something more important. An hour or so later he told me he had found it, but did not know what to do next. He toggled the switches to go to the short data bus, and after a bunch of switch flicking and looking through a file cabinet of documentation, he proved to me he was able to write the necessary data to access the disk via the long data bus and read back the disk register. Sure enough, there was a bit set, which the documents said was the “disk online” bit, and it was off.

“Oh”. I turned around, and the “Online” switch was flipped downward on the disk. “Click”. It was a great learning lesson in depth of how the CPU worked, for him and me both.

*The tester* had two doors that could swing open and had removable panels. Each door held three banks of cards of TTL and ECL logic, with a massive 5 foot tall wirewrapped backplane. I once tried to count the IC’s in the tester, and came up with around 60,000 chips. You can see the backside of it here. The black door latch for one of the doors can be on the upper left, and both the hinges are clearly visible running down the back. The center panel was filled with large rack mount (and very heavy) power supplies. At the bottom, in the black area, are three phase twist-n-lock 220V power connectors, a bank of 110V AC utility outlets, and cables running to the two test heads. The black panel running horizontally had some test BNC’s no one ever used, and a key to power it off and on.

We had to be careful about those AC utility jacks. The tester ground was at -11 volts at several hundred amps. If you clipped a scope to a ground, it would happily melt the insulation off the scope probe until it stunk up the room and pooled on the floor. We had to use a 3-prong adapter with the ground cut off.

This tester had a 100 Mhz internal clock and could test almost any type of IC at 10 Mhz speeds. The tester could DMA test patterns from the disk to the pins of the DUT at full speed, change power supply voltages at megahertz rates, and via microcode running out of ECL RAM, call test subroutines in hardware at the full clock rate. Each test vector looked like a binary 101011..001, 64 bits long, and each bit set an output high or low, or was an expected response. These bits basically were wired to the test pins. Somebody wrote a Z80 cross compiler that made “Set F 10101010101……100101” statements from assembly language, so we could test actual code on the Z80 at full speed. It was very exotic tech for us. We could only compare it to the assembly language PDP-11 testers we typically made. Mostek made all their own custom testers except for these.

*The test heads* ( one on the left has a chair in front of it) had a circular array of “Pin Electronics’ cards. PE cards had a lot of analog circuits for testing the device under test (DUT). I think this particular machine had 64 pin capacity. The DUT was plugged into a ‘top hat’ that had a “Zip Dip” socket which in turn was attached to the ‘Performance Board’ that had the loads and any special circuits for that part, which in turn plugged directly onto the circular array of PE cards. This is that square black hole in the middle of the test head. These IC-specific parts could be changed quickly, a new tape loaded by 9-track, and a new test set up in a few minutes.

These test heads were built to hold the very heavy Electroglas wafer testers, too.

*Controls* On top of the test head is a box with 4 lights and a “test start” button. There were two red and two green lamps. These are a go-no/go set for parametric failures such as continuity and leakage, and a second pair of Red/Green lamps for functional failures. I remember that a particular lot was failed by QC (this happened all the time) but I realized the same oddball part number had been failed a week before, and again before that. There was a pattern to it. A bit of investigation revealed that the new girl that ran the machine did not understand we needed the parts to have TWO green lights. It was a language and training issue. I was afraid that she would get fired when somebody realized that all her work for weeks was no good. But our shift supervisor was fantastic. After explaining to Robert what was wrong, he just told her we had a new procedure now. Two green lights goes in the good pile. Problem solved. And no one ever said another word.

*Failure modes* It was a beautiful machine, I loved it, and it broke every day. 100Mhz ECL chips got hot and failed often. But it was usually a Pin Electronic card (or 3 or 4) would just die. I would load a tape called ‘TVFY6’ and spot the problem in a few minutes. I eventually realized that a lot of bad PE cards happened just before or after lunch. It was caused by people sorting change on top of the machines, which would drop inside and Zzzzzzzt things. Thankfully, our warranty for this tester got us PE card repair for free. But one day Fairchild refused to send us any more. They claimed we had hundreds of them that were unaccounted for, and had never returned them for repair. We eventually found out that our boss had been hoarding them in his filing cabinet. He got fired that very same day. So me and my techs got to work a lot overtime to repair them. I ended up making more money as an hourly tech than a lot of engineers from all that overtime. I loved that machine, for lots of reasons.

*Circuit Breakers tripping* As was the group leader in the repair department from 1974 until 1979, I had to watch over everything about this machine. There had been mysterious catastrophic power supply circuit breaker trips on multiple weekends. One night, around 11 PM, I heard the (very loud) alarms go off. I headed up the ramp in the rear, and passed a janitor running down that ramp while dragging a floor buffer behind him. I finally realized he was plugging it into the tester utility AC outlet in that black area where cables come out and was tripping the circuit breakers. That incident got people’s attention. Facilities finally made us very nice laminated plywood custom covers for that bottom area and covered that problematic area around the DUT, too.

*I loved this machine* Mostek sent me out for factory training to repair them in September of 1975. I still have the certificates on my wall. It was quite thrilling to be on a company expense account (for an entire month!) in San Jose, the heart of Silicon Valley when I was just 21 years old. I had already worked on them for two years, so the class was a breeze and I had every afternoon off.

tl;dr This Fairchild Sentry 610 tester was a kick-ass Z80 tester.

Raspberry Pi in Embedded Systems Design

The Raspberry Pi is difficult to use in an embedded application because the unneeded connectors get in the way. The Compute Module was made to solve that problem. The Arm processor is a 200 pin DDR2 SO-DIMM module, aka, a “Sodium” CPU. It has a Broadcom BCM2835 ARM1176 CPU with 512 MB of RAM, a 4 GB eMMC device, USB, high speed video ports, GPIO, PWM, UART, PCM/PDM Audio In and Out, multiple 32-bit timers, and two SPI ports, which makes it an ideal controller for many embedded applications.

(image CC BY-SA 4.0 by Raspberry Pi Foundation)(Dimensions are 67.6x30mm )

In this embedded app we made a small motherboard with integrated Ethernet, +12 VDC power, and dual HDMI connectors

 

 

 

The HP 35 Bluebird Tester

I worked on the HP-35 tester, way back in the early 1970’s. Here is a PDF of those times and a writeup below.

The HP-35 calculator was a huge sales success in 1972, the year I graduated from high school. There is a lot of information online today about this marvelous machine, but very little about how it was manufactured, or how it was tested. I wish I had know back then what I know today, because I worked on the HP-35 for a long time, without even knowing about it. So here it is, 40 years later, and I am writing about the HP-35 chip set and architecture, and the Bluebird tester we tested them with.

 

The above photo from the 1973 Mostek data book shows our first computerized IC tester. We called it the “Bluebird” tester. It also shows the PDP-11 computer. The Bluebird was painted primary blue. This horrible color eventually was put on every piece of gear we had.

The Bluebird was originally designed to test the HP-35 “West Coast” calculator chips. The “West Coast” was because HP was on the west coast, while we were in Carrollton, near Dallas. The first machine went live in February 1972.

There are many interesting things about this tester and the IC’s which made up the HP-35 which I’ll go over in more detail. The Bluebird was used for all of the HP family of HP-35, HP-45 and other calculator parts, and for “random logic chips”, which at Mostek meant “not RAM”. RAM chips required much more extensive tests. Bluebirds were made to be general-purpose and tested almost all ICs (except RAMS) at Mostek for many years. About 20 of these were built during my stay there.

This custom test system was the first computer-controlled IC test system at Mostek. All other testers before then were digital state machines we called ‘dedicated testers’. which were controlled by logic gates, counters, and in the case of some calculators, by an endless loop paper tape reader. We made small DRAMS, too, and tested them with dedicated testers with rows of potentiometers to set up the critical time. None of the earlier dedicated testers had a CPU.

The original reason we built the Bluebird was to test a chip set we designed for Hewlett Packard, for the HP-35 calculator . I’ll explain more about the HP-35 chipset next, as you need to know about the chips and what needs testing to understand this early IC tester.

The HP-35 was the first hand-held, battery powered scientific calculator. It was a huge success. HP originally thought that 50,000 units could be sold, but they all were sold in just the first two months. G.E. bought 20,000 units just for internal use!

The HP-35 sold for $395.00 in 1972, the year I graduated from high school. Over 300,000 HP-35s were sold by 1975. I remember reading about it in a magazine around 1972, and was awestruck by how powerful it was. I had no idea as a young kid still in high school that just a few years later I would be working on them at an intimate level at the very company that designed and made the IC’s.

To put this in perspective, a $395 calculator was the equivalent of $2,777.00 in US dollars as of 2016 – equivalent to $840,000,000.00 in today’s dollars in just three years. And that is just for one model! The chip sets and derivatives of them were used by the HP company for many years. The HP contract was the largest contract Mostek received for many years. It was not exceeded until we developed the multiplexed DRAM, which took over the world.

The Mostek contract required the custom design of three PMOS IC’s, each with roughly 6,000 transistors1 . These were the MK6022, MK6023, MK6024 ROMs which differed only in the pattern loaded in them, a MK6021 Timing and Control IC, and a MK6020 Arithmetic and Register chip2 . Together with the 1820-0853 anode driver and system clock chip, three 1820- 0854 LED drivers, three LED 5-digit LED chips, and a 1820-0855 clock generator, they made a small ROM- programmed computer. The HP-35 used 3 ROM chips, with 768 10-bit instructions each. Each chip handled a ‘page’ of memory, and pages were organized in banks of four, called ‘quads’. So the HP-35 had 3/4 quad. Later HP calculators such as the HP-80 used as many as seven chips, and the chips were quadrupled in size to hold more data. The chip set could address 8 ROMs, but never used more than 5, because the chips were quadrupled up in size, thus leaving only a single spare memory bank of 256 instructions.

Each chip had features that were about 10 microns (0.0004 inch) on a side, enormous compared with modern versions, about 2000 of which would fit inside each one

HP series of calculators and memory sizes:

 

I knew of several engineers at Mostek who unsoldered their HP-35 ROMS and replaced them with HP-45 chips as an upgrade. This was possible because the HP-35 had two Quad chips, and the only other difference was some extra keys were added. As a technician who knew how to solder, I got to take one designer’s precious calculator apart, desolder the ROMS, and solder new ones in. This was quite a thrill for a 20 year old!

 

Bob Crawford and L.J. Sevin.

This test data that came from the CPU obviously needed to vary from part to part. Eventually we made 24 different parts for 13 different HP calculators. For example, the HP-35 and HP-45 differed only in the mask patterns in the ROMS and in a extra row of keys.

It was obvious from the start that a programmable tester was needed that could be rapidly updated to test different ROMS. There were unusual requirements compared to the way microcomputers and microprocessors work today. In order to keep power dissipation low, the HP-35 ran at only 200Khz, and was a serial computer, not parallel like today’s chips. The digitserial, bit-serial organization reduced package size, cost and also increased reliability. This set a requirement that the new tester had to run at 200 KHz speeds and be p rogrammable. As a result., one of the very first PDP-11 systems was chosen. 200 kHz was easily within the range of a DMA cycle over the PDP-11’s Unibus system. Unibus could run at megahertz speeds .

Because the HP family was well thought out in advance, and Mostek needed better testers, a general purpose re-programmable tester was designed – the Bluebird. This programmability was accomplished by hand-keying in a bootstrap loader in the PDP-11’s switch register, loading an “absolute loader’ tape with the bootstrap, which loaded the test program tape. That PDP-11/20 system in the photo was one of the very first PDP-11’s. They came with 4K of core memory. We needed more speed and more RAM, so Mostek designed our own RAM memory board. And every time we had a power failure, the other technicians and I would run around as fast as we could, re-keyed in the bootstrap loader and loaded all the tapes again. This seemed to happen far to often very early on Sunday mornings.

I keyed in that bootstrap so often, I still remember the beginning of the bootstrap, 42 years later.

012737 move.w #1, #164162 // Put 1 in the Bluebird Online register
000001
164162
000002 Wait for Interrupt…

At this time the Bluebird would signal an interrupt over the Unibus cable.

The Unibus was an 120 ohm impedance-controlled flat cable that memory mapped the Bluebird into the PDP-11’s 32K word address space (http://html.alldatasheet.com/html-pdf/92680/NSC/DS8640N/46/1/DS8640N.html) . The Unibus was much like any computer bus of today. It ran through the PDP-11, but also was extendable by a long, flat impedance controlled cable to external devices. The closest analogy I know to the Unibus architecture is the MK68000 chipset, which is not a surprise as the 68K was largely inspired by the PDP-11. The Unibus had an 18-bit address and 16 bits of data, plus two parity bits, one for each byte. More importantly, there was a Master Sync that would clock the addresses, much like the 68K Address Strobe pin, and going the other way was Slave Sync, just like DTACK on the 68K. This let Mostek designers create registers inside the Bluebird. It also had a Non Processor Request (DMA) pin for requesting and a NPG ( Bus Grant) pin for granting a DMA cycle, and 4 interrupts. The Bluebird used these signals and the Unibus to DMA signals to and from the HP35 ICs as part of the test.

The Bluebird tester had two drawers of digital logic. The bottom drawer held the circuits for interfacing to the Unibus, and via it, access to the PDP-11 memory. The data for stimulating the parts came from the PDP-11 memory via DMA over the Unibus.

I had worked mostly on dedicated testers in my first few months at Mostek. On a dedicated tester, you triggered an oscilloscope probe with the “fail lamp” driver and used a second probe to look at the IC under test pins, the level translators, comparators, and so on until you traced your way back to the test inputs to try to find the problem. It could be a pin loose in a socket, or a blown circuit in a level translator. The triggered scope would show you the exact instant the test failed.

Photo credit Wikimedia Commons, the free media repository Creative Commons Attribution-Share Alike 3.0 Unported

So when I started working on Bluebirds, I was in for a surprise. The first time I tried this “trigger on the fail lamp” technique on the Bluebird, I connected the scope to the latch, and traced my way backwards. I ended up in the lower digital drawer, and realized I was tracing a signal all the way back to the Unibus, chasing after the Master Sync signal that indicated the program had just executed a move opcode to write a data bit into a register in the Bluebird that toggled the fail lamp on! Imagine looking at something like this circuit from the Dec Unibus manual, and realizing this was not the right direction to find out what was wrong with the chip in the test socket!

I realized that night that learning the programming of the CPU was needed to figure out what was wrong. This led later to my career as a designer of and programmer for Unix systems and many microprocessors. Unix originally ran on Dec PDP hardware, and also was used back then on the 68000 microcomputer that Mostek also made.

AMI was also selected as a vendor and designed a similar set of three IC’s. Here is a comparison of the size and power dissipation of the chips from Mostek versus AMI. The goal was 250 mw power dissipation. As you can see the Mostek IC was considerably lower in power. This mean the batteries could easily run several times the 4 hour requirement.

 

The CPU instruction word was 10 bits, but to save on chip size, the parts were based on serial data. The 10 bits were clocked out, one at a time, and all calculations were done by a half-adder inside the Arithmetic and Register chip. This feature of the chip required a word select line from the Control and Timing chip to signal to the A&R chip when the appropriate digit was available. There was also a SYNC pin that signaled the beginning of a instruction word. This signal went to a special card in the Bluebird tester, that we called the “West Coast Sync” board . (http://www.hpmuseum.org/cgi-sys/cgiwrap/hpmuseum/articles.cgi?read=385)

 

Only a few people at Mostek had any idea these chips were for a HP calculator. It was a carefully kept secret for a long time. The code name was used whenever they could use it – even in the schematics for this tester. I have a vivid memory of working on a Bluebird that was failing a test, all day long. I was stuck deep inside the digital logic on the “WC Sync” board inside the bottom drawer of logic, getting nowhere. I asked several engineers what it was about, and they told me to just fix it. I finally found a sympathetic engineer who realized I had a “need to know”, so he told me the chips were for the HP-35, and how the “West Coast Sync” worked. Needless to say, I was a bit shocked. The HP-35 was already very famous!

 

Photo src: http://www.hpmuseum.org/cgi-sys/cgiwrap/hpmuseum/articles.cgi?read=385

From the calculators perspective, a timing circuit on each ROM is synchronized to the trailing edge of the SYNC signal issued by the Control & Timing chip when the calculator is turned on. This circuit then keeps the ROM chip running synchronously with the rest of the system. The Sync signal is found in this timing diagram from the HP-45, which was the same as the HP-35 except for extra keys and different, 4X the size ROMS.

To do a good test, we needed to be able to test all 6,000 transistors and all the logic paths. Every single transistor in each part had to be tested and verified it operated to specification. In addition, the patterns programmed into the ROMS had to be checked and verified against a simulation written by Jim Duley of HP Laboratories7 . This simulation generated the test pattern Mostek needed to test the final IC’s. After a simulation was running correctly, a pattern for each input and out on each IC was recorded. This pattern was stored in the PDP-11 memory. The tester would compare that simulation, which came from paper tape, via DMA from the PDP-11 memory which stimulated the Device-Under-Test (DUT).

Just like inside the calculator, the CPU and the DUT needed to be in phase with each other so that the bit patterns would match. The West Coast Sync board would stop the DMA until the Sync and Word Select pins were at a known state on the DUT. The clocks would then be in sync. Now each output can be compared to the PDP-11 registers expected output with a LM311 comparator IC.

You can also see that SYNC signal on this block diagram of the calculator :(src: http://pmonta.com/calculators/us-patent-4001569.pdf)

 

The comparator IC was also strobed by the Bluebird clock to compare the two chips at the correct time. That IC failed on one of the test boards, and always produced an ‘OK” signal. No one detected the problem, and we shipped a large batch of defective parts to HP. It caused a huge ruckus, and everybody was upset.

All parts from then onward had to be hand tested in a hacked HP-35 calculator that did a simple ‘reset’ test and a 1+2 test. It worked something like this: First the display showed 2, then a 3, and the chip would reset. It then showed 1, 2 and then a 3. If the final 3 happened, the test passed. I found out many years later that Mostek had put in special mask ‘cheats’ to prevent people from copying our chip. Our chief designer, Robert Proebstein (https://www.cs.utexas.edu/~hunt/class/2016-spring/cs350c/documents/Robert-Proebsting.pdf) , had found out a way to put a pad on top of a silicon hill, but without connecting it to the obvious trace below. A copier would not be able to see this hill that served as an insulator unless they used a side-viewing microscope, which was rarely used. Copying was always done with a top-illuminated microscope. The copier would think it was just an ordinary via, and connect the trace to the layer below. This chip had a circuit to signal the very specific 2+3 operation, and this would then be connected by the wrongly copied pad to the reset pin of the chip.

The test set would just press 2, Enter ( It was a reverse polish calculator) , a 3, and then +. This would reset the chip. It then pressed 1, Enter, 2, and +, displaying a 3. If the chip was from AMI, or a bad chip, a different pattern would appear.

We also hired more QC people. They tested every lot of parts before and after a test was set up. I actually met my future wife because of that incident – she was one of the new QC personnel they had to hire for the increased workload for this production area. And she was cute. It took a few years, but eventually I got her to agree to marry a geek, and we have been together for 36 years as of this writing in 2016.

All these tests and logic circuits in the Bluebird in turn had to be tested. so a special test program and circuit was created just to test the Bluebird. You can see this in the photo. The lid is raised up to access the test board which held various circuits specific to each IC. There is a hole in the lid, just to the upper left, where the Device Under Test (DUT) would be placed into a test jig on top of the test board.

There were two drawers of logic in the Bluebird. The bottom held three rows of logic to interface to the PDP-11. The top drawer held analog circuits, such as level shifters and D/A converters. The very expensive sets of 12 bit D/A converters (from 1970, when the system was first designed) were plugged into card slots in the top rack.

Bluebirds also ran our wafer-level probe tests on the raw wafers. A Electroglas wafer prober would be set on top of this lid, and a cable ran through the hole to the test point card in the Electroglas. The tests for leakage and speed would be reduced when testing bare die by the PDP-11.

The Bluebird had 24 output bits that could be changed on-the fly by setting memory in the PDP-11 with 1’s and 0’s/ This was done by writing a 15-bit start address and length into a Bluebird register, writing a test destination address into another register, and then enabling the tester. The logic circuits would automatically request a 16-bit memory address, write the data to a temporary register, read the next 8-bit byte, and write the resulting 24 bits to the DUT when the timing generator indicated it was time to do so. We referred to this as ‘cycle stealing’ from the PDP-11. These bits would travel through level translators to be at the correct PMOS levels. Other TTL compatible chips could be tested by reprogramming the DACs that drove the level shifter.

We didn’t just drive the signals from rail to rail either. We had to drive them between the Min and Max, and at the correct rise and fall times. Every data sheet value and waveforms, such as the signals in the diagram in Figure 5 had to be tested.

For a TTL part, these input levels would be typically set at 0.8 volts to +2.4 volts with Vcc set to Max of +5.5 V. The parts had to always see a worst-case input. We also measured the input capacitance, which is very difficult to do at the end of a long cable. Leakage current was tested, and we also back-biased the inputs to check that the anti-static protection diodes were working. All the level shifters and analog circuits had to be custom designed for this purpose. We used standardized wire-wrap cards with small plastic headers to hold the discrete transistors and resistors that made up a level translator or a comparator.

Another requirement is that the HP chips had to meet worst-case output levels. If the part was supposed to drive an output to 0.4 volts at -4 ma, and 2.4 volts high to +3 ma, we had to test for exactly that. This required a bank of comparators (the Bluebird had 16) and suitable voltage sources and test loads, like the circuit at the right, to compare against. These comparators can be seen in first photo just behind the test board. The timing generators would strobe the comparator banks, and write the result data to the PDP-11 memory using a third DMA cycle.

 

You can see a wafer being tested by a Bluebird in the above photo. I cannot guarantee it, but it is almost certainly an HP-35 chip, just like the one to the right, but it is very likely that the only chips qualified to run at that time were the HP chips.

A 3″ wafer would be loaded into an Electroglas and aligned under a microscope. The test person would press start, and the Electroglas would step across the chip and press a set of microscopic probes attached to the PCB (above, has a circular hole in it). The blurry part that looks like a pencil was an ordinary medical syringe, filled with ink. It had a plastic fishing line running through it.The fishing line can be seen in the photo just above the IC. A solenoid was attached to the fishing line and the line was cut off just below the tip of the syringe needle.

 

If the part failed the test, the Bluebird would enable the solenoid, which would push the fishing line, and jot a blob of ink onto the part. The wafer would be sent to the dicing department which scored and broke the wafer into individual parts and discarded the inked bits. The rest would go to the bonding and packaging department, and get routed back to another Bluebird line for testing in the DIP package. In some cases, the parts would go through a heat or chill cycle in a large oven attached to another row of Bluebirds.

This cheap and effective method of marking bad die sometimes led to interesting patterns on the wafer. I was once asked to check out a Bluebird that seemed to be passing almost every part on a wafer. This was usually a nightmare – it was never broken in a way that was easily fixable. You can’t fix what ain’t broke. In this case, it was easy to see that only the parts at the edges of the round wafers that were cut by the round edge were failing the test. This was either continuity or leakage test, and not the functional test which usually mean that there as a problem in the logic of the tester that tested the functions of the circuits.

I eventually noticed that one wafer had a line of dots running across it that was a great clue. The tester was correctly failing functionally bad parts. Looking at that wafer under a special microscope showed a microscopic grain boundary in the silicon – and transistors do not work across a grain boundary! They require a single crystal of silicon. The Product Engineer for the part later told me it was a final run for very old part, a MK1002 dual 128 bit shift register. These parts were now being built in a new class 100 clean room using modern equipment and methods, and so the yield was now close to 100%.

Oh, about that horrible blue ‘Bluebird” color. We painted everything bright blue. All test equipment had to be that way. Rows and rows and rows of testers. Room after room. A technician named Mike Chambers got permission to design and build a board-level tester for our test lab based on the Z80 chip we were making at the time. And since we were in charge, he ordered a very pretty burnt-orange and beige rack for our new “Puma” – short for “Programmable Universal Maintenance Aid”. We figured we could get away with it as it was a test lab, not a production department, and we had a different set of bosses.

Eventually the tester rolled out and went online in our lab. Shortly after we got word that the Vice President who was in charge of color was upset and wanted us to take it apart and paint it all horrid blue. We ignored it. A few weeks later, we got an actual memo. We ignored it. We figured no one would take a very expensive machine like that apart. We were right, too.

We came in on Monday morning, and the room was painted burnt orange and beige.

The Bluebird was a workhorse of a tester. It lasted for many years and tested almost every IC Mostek made except for RAM and the microcomputers. RAMs were tested on the Master and MiniMaster product lines (Gray cabinets) and CPU chips were tested on Fairchild Sentry 600 and 700 series machines (Beige cabinets). Bluebirds received several upgrades over the next 5 years – the wire wrap boards were retired, printed circuit boards were hand-taped, and wire wrap was used only for the two backplanes. The tape readers in the PDP-11’s were replaced with serial RS-232 lines running to a VAX-11-780. We designed and laid out a diode ROM board for the PDP-11’s so keying in the bootstrap was no longer required.

After five years of this type of work, I got a lateral transfer to the microcomputer department and helped the engineers design STD Bus, Euro card, and VME bus systems. After 8 years I left Mostek and started a Unix microcomputer company based on STD Bus systems and the 68000 microprocessor. I still work with Rex Brown at Micro Technology Services, (www.mitsi.com). Rex was employee #13 at Mostek, one of their best test equipment designers, and the person who hired me into the microcomputer department so many years ago. We worked on STD and VME busses together for several years, and have hired each other back-and-forth at different companies for almost 40 years now.

Fred Beckhusen

For further reading:
https://web.archive.org/web/20040203113550/http://www.vcalc.net/hp-35.htm
https://en.wikipedia.org/wiki/Unibus
http://textfiles.com/bitsavers/pdf/dec/unibus/UnibusSpec1979.pdf
http://www.hpmuseum.org/hp-35.htm
http://www.datamath.org/Mostek_IC.htm
http://www.hpmuseum.org/cgi-sys/cgiwrap/hpmuseum/articles.cgi?read=385
http://www.hpl.hp.com/hpjournal/pdfs/IssuePDFs/1972-06.pdf
https://www.cs.utexas.edu/~hunt/class/2016-spring/cs350c/documents/Robert-Proebsting.pdf
http://pmonta.com/calculators/hp-35/
http://pmonta.com/calculators/us-patent-4001569.pdf
https://people.rit.edu/lffeee/PMOS150.pdf

Database Applications

Database Applications

We develop in Microsoft SQL server, Microsoft Access, Oracle, Sun,  and Progressive SQL server system with ODBC, perl, VB C++, c# and ASAPI application languages

NEED

Our client had identified a market within the floral industry for automatic, computer generated reminder messages. The industry needed a fast, low-cost software package that could generate post cards automatically to remind customers of upcoming events.

The software had to be capable of tracking thousands of clients nationwide. In addition, it had to handle a wide variety of clients, special occasions for reminders, and automatically order and bill selected clients for services.

SOLUTION

Mitsi developed a Dbase-compatible database system using a PC-based compiler. The software had many menus for prompting the florist for information about the potential client, their relatives, secretaries, and others. Special data entry screens were developed with pop-up windows that prompted for necessary information.

Many custom reports were written to print the post cards automatically. In addition, reports were made to order merchandise, bill clients, and bill major credit cards. Software was written to handle specific customer referrals. Wire transfers also created unique billing problems that were handled in software.

SCSI Controller for EISA Bus

SCSI Controller for EISA Bus

NEED

A new Extended Industry Standard Architecture (EISA) bus computer market was defined by Compaq, Olivetti, AST, Hewlett Packard and others.  These computers were to be used for high speed file servers and workstations, and required new high speed disk, tape, and printer controllers.  Companies that built all new controllers would miss the market window.  

With the new controller, the new EISA computer was expected to handle 256 users instead of the original 45.

 

SOLUTION

Our client had an asynchronous VME bus design already in production that had similar functions required by EISA.  A UNIX software driver and on-board firmware also existed.   The client required that any changes in the card allow it to use existing software as much as possible.

The client also required that the product be ready in time for an important trade show.  There was not enough time in the schedule to build a wire-wrap prototype.  Also, the target computer, which was based on the 80486 chip from Intel, would not be available until the very end of the project. 

The existing schematics were compiled on a Computer Aided Engineering (CAE) workstation, digital simulation was used, wave forms were plotted and analyzed, and corrections were made.   After modifications were made to the bus interface, a new synchronous state machine was implemented using programmable logic devices (PLD).  

A new section of 80486 code was added to the 68020 firmware, allowing the system to boot  from disk.

The final design was a 10-layer surface-mount and through-hole PCB design.   Dozens of circuit cards were manufactured and assembled, and preliminary testing was done while the anxious wait for the new EISA computer continued.

Automatic Testing

Automatic Testing

Need 

Cable TV system operators purchase and maintain a large quantity of sophisticated addressable converters for installation into their subscriber’s homes.    There is a premium placed on verifying that a unit has been received from the manufacturer in working condition before placing it at a subscriber’s location. 

In addition, units that fail in service can be diagnosed and possibly repaired by the operator, rather than being returned to the factory for repair.

Solution

We designed and constructed a computer-controlled automatic tester for the TOCOM 55 Plus Addressable Converter for use at the manufacturer’s production facility.  By adding some test signal generation equipment, this test station can be used by any cable TV operator for the 55 Plus Converter.

The test operator does not directly handle any of the equipment in the test station; rather, all control is managed through the computer keyboard and the converter keyboard. Test results are displayed in both English and Spanish, and the operator is prompted through the test sequence, thereby simplifying the training process.

Results

A complete functional test is performed in less than five minutes, including all installed options such as remote control and two-cable operation.  Operator training is minimized, allowing a lower skill-level operator to perform inspection tests, freeing higher skill-level operators for trouble-shooting and repair.   The cable system operator also experiences lower inventory requirements and fewer units returned for factory repair, thus reducing inventory.

Three sets of  nine different testers (27 total) were developed for this program.  

Reverse Engineering

Reverse Engineering

NEED

Due to the deregulation of the telephone industry, our client had successfully reverse engineered many of the cards originally produced by Western Electric for a SLC-96 T1 telephone system.  However, several cards were extremely difficult to reverse engineer as they had many full-custom IC’s, including a microprocessor, EPROM memory, and a pair of gate arrays with over 10,000 gates each.

Additional requirements existed, including extreme temperature range, reduced power,  high reliability, and low cost of manufacturing.   Four different cards were required.   The client required that no custom IC’s be used in the resulting design, and all components had to be second sourced.

SOLUTION

MTSI first developed a disassembler for the processor code.  By using a split screen editor, over 6,000 bytes of code were translated into the target 68000 computer language. 

During this development, a design flaw in the CMOS  68000 microprocessor was found and reported to the manufacturer.   Mask changes had to be made by Hitachi to eliminate the problem.  The hardware was examined using logic analyzers, a computer aided engineering workstation, and other tools.  Simulated circuits were tested against the known good circuits and modifications made.  Seventeen full-custom IC’s were reverse engineered in this way.  

A SLC-96 emulator was also developed.   Controlled by a PC, this emulator allowed worst case timing changes to be incorporated in the design, and it reduced the need for the expensive and often unavailable pair of SLC-96 systems. A gate array emulator was developed and prototyped using wire-wrap technology.  After testing of the original card,  four gate array emulators were built and tested.   The design was then extensively simulated and a gate array produced that matched the functions required.

Altogether, 23 emulators were built and tested individually and together.    By using PLD technology,  power was reduced,  the need for full-custom circuit was eliminated, and the design was rapidly developed and tested.

RESULTS

All four cards are now in volume production.  the gate array was found to be 100% correct after the first pass.  All of the projects came in under budget and on time.