Welcome to exHeurikon.com

If this is your first visit in a while, please check the About Page for more information on this site and the services we can provide.

If you're a Heurikon veteran and would like an account, just click the Create New Account link in the left menu.

More videos of 8310 renovation

This was from Sean via the admin contact form:

Hello, someone posted 3 Youtube videos of 8310 Excelsior Drive. The vides show the de-construction of the location. I'm not an exployee of Heurikon nor a customer. I was a college student back in the mid 1980's when I requested literature from Heurikon about their Multibus products. I learned alot from the information. You can say that it helped get me started in the computer business. I was always curious about what happened to the company.

Video One:

Video Two:

Video Three:

Excelsior building renovations

Here are photos and a video showing the changes the new owner has made to the Excelsior building:


Our Domiciles

banner.jpg Original publication date: August 1992

Heurikon Historical Highlights

A series of articles for The Horizon

by Jeffrey Mattox

Our Domiciles

Over the years, Heurikon has had seven homes.  We started out in the basement of Chris’s house, at 621 Sheldon Street.  That’s just off Monroe Street near Wingra Park.  Most of the operation, including a circuit board photo and fabrication area, was in the basement.  The business phone and answering machine were on a small desk in a hallway.  (That original desk is still in use; it is in the telephone equipment room.)  Although some business was conducted on the dining room table (which had a good view of the kitchen sink), our most important decisions were made at the Laurel Tavern on Monroe Street.

Chris and his family lived upstairs in the house, along with John Burdick (one of Heurikon’s other founders), and an attractive university coed who would occasionally walk through our dining-room office wearing only her bathrobe.  Years later, we heard from one of our vendor’s representatives that he visited us often just for the chance to see her parade around.

Another notable resident of the house was Chris’ dog, Brandy.  She would get real excited whenever a visitor came into the house, and it wasn’t uncommon for her to end up piddling on somebody’s foot.  The old story about my foot once being a target is untrue — it was John’s.  He just calmly stood there and smiled.

It was easy for our neighbors to recognize Heurikon’s visitors.  While searching for the “factory,” confused visitors would often drive up and down the street in their expensive cars before realizing the old house at 621 was the correct place.

loc_sheldon.jpg621 Sheldon Street — 1972-1974

One day in 1974, a city building inspector came around to check on the plumbing.  The inspector appeared uninterested in the business in the basement, but he reported us to the city’s zoning department.  Soon, we got a letter from the mayor’s office saying we were in violation of city ordinances and that we better get the business out of the neighborhood or else.

From One Basement to Another

After a short search around Madison, we found a low-rent office in the basement of an apartment complex at 700 West Badger Road.  The rent was low, in part because the space didn’t have any heat — most of our heat came in through the ceiling from the apartments above.  We rarely had any problems with the other tenants — expect for the time one of them plugged up their tub and let the water run over the top.  That afternoon, the ceiling above our drafting area started to sag and then it gave way with a torrent of water.  The water also ran down the ceiling support rods and dripped onto our benches and desks.

loc_badger.jpg700 West Badger Road — 1975-1979

Our original office furniture was a decrepit sofa and chair that we scavenged from the apartment’s utility room.  We built our desks from an assortment of table tops and legs we bought around town.  And, it was a big event when the telephone man installed our first two-line telephone — a simple “hold” button significantly elevated our business status.


One thing we didn’t have were private restrooms.  The “facilities” were part of the apartment’s recreation room, and to get there we had to find our access key, unlock a door and walk down a long, dark, spooky corridor.  Frequently, one of us would accidentally take the key home, thus causing hardships for a day or two.  To prevent that mistake, we attached the restroom key to a bulky toy hippopotamus, which became our mascot.  Dennis Paton still has custody of our precious hippo.

loc_basement3.jpgJohn Burdick in the shop

While at West Badger Road, we cleaned circuit boards with an old toothbrush outside in the parking lot, installed our first burglar alarm after being hit one night for our power tools, hired our first receptionist and secretary (she was also a part-time assembler — she had to put down her soldering iron to answer the telephone), and we continued an old tradition by doing important business over beers at Vitale’s Lounge.

West Badger Road suited us nicely until 1980.  By then we needed more space which we found just across the Beltline, at 3001 Latham Drive, in the rear of Vondra Engraving’s new building.  We had 3,000 square feet — and heat and restrooms and carpets, and even a hallway (luxuries absent from our Badger Road offices).

There were a few undesirable features, however.  The metal roof was not well insulated, and when it rained, it would be so noisy we’d have to shout to be heard.  On cold winter nights, condensation would freeze on the metal ceiling, which would slowly melt during the day, causing water to drip all over the benches in the shop.  The air conditioners were so loud that Deanie had to turn off the one above her desk whenever she wanted to talk on the phone.

By the end of 1982, we needed more space, so, with Vondra’s permission, we cut through an interior wall  and expanded to 4,500 square feet (a tenth of what we have now).  We had our 1982 Christmas party in the new space (the decor was “primitive unfinished warehouse”).  We grew steadily during our years at Vondra.  And, we got our first copy machine, wave solder machine, and Gen Rad tester.  The Bombay Bicycle Club was only a short walk away, so that served as our business bar.

loc_vondra.jpg3001 Latham Drive — 1980-1984

The First Digs of Our Own

By the middle of 1985, we were about to burst our walls, so we committed to the first building of our own, and moved a few blocks up the hill to 3201 Latham Drive.  Much of the move was done by simply putting our equipment and furniture on carts and rolling it up the hill.  From the air, it looked like a line of ants moving along.  New amenities included a loading dock, break area, and conference rooms.

In late-1987, to make room for our continued growth, the marketing, sales, accounting, and administration departments moved downtown to 121 East Wilson Street.  Also, for a few years, we leased two trailers and attached them to the building through the outside exit of the break room.  The trailers were home to cost accounting, customer support, and a few other people who managed to squeezed in.  The acoustics were horrible.  As you walked around in the trailers, your footsteps would resonate throughout  the space.

We had planned on staying at Latham Drive for ten or more years, but when we needed to expand again, we decided to move to a neighborhood more suitable to our business.  The Latham Drive area was an unplanned conglomeration of warehouses, stores, and factories.  There was a meat-packing plant on one side of us and a junkyard on another.  It just didn’t seem like the right locale for the long-term.

loc_latham.jpg3201 Latham Drive — 1985-1990

After we made the decision to build at Old Sauk Trails Park, our employees at the Wilson Street offices went on ahead to the First Wisconsin Bank building at 8000 Excelsior Drive.  That was in 1989.  The rest of the company moved into our current building at 8310 Excelsior Drive in August, 1990, and we finally combined all of our operations in May, 1992.

loc_excelsior.jpg8310 Excelsior Drive — 1991-present

This month marks Heurikon’s 20th anniversary.  And, we’re still looking for a good neighborhood bar....

This concludes the Heurikon Historical Highlights series.


UPDATE July 2009: In actuallity, Heurikon/Artesyn/Emerson had operations in many more locations.  My perspective was from engineering, but other departments occupied other buildings.  Here's a good list submitted by Bruce Dittmer:



Final Days and Farewell

One week to go and the building is nearly empty.  The material things such as cubicles, chairs, and people are obviously missing.  There is dead silence under the air handling system.  The sound of ringing phones, printers, rolling carts, the "chip shooter", hallway gatherings, and filled conference rooms are all but gone.   But even with the remaining skeleton crew helping to close this final phase of Artesyn/Heurikon, the sounds of camaraderie and friendship still speak loudly within. Respect, cooperation, and a strong sense of family still remain, and one can still feel that good things were housed under this roof.  Each one of us shares those feelings, which makes this chapter the hardest to finish.  Artesyn/Heurikon as a business will soon be forgotten, but all that has been shared and accomplished will forever be remembered.





NIKA Corporation

banner.jpg Original publication date: July 1992

Heurikon Historical Highlights

A series of articles for The Horizon

by Jeffrey Mattox

NIKA Corporation

One of our original investors and business advisors was Ed Gray.  He ran the NIKA Corporation, a Madison firm that contracted with the government and insurance companies to provide cost estimates for renovating or repairing damaged buildings in cities throughout the nation.  NIKA maintained a database of material and labor rates for all building trades across the country. 

The process of settling an insurance claim and doing cost estimates for government rehab projects involved a lot of paperwork.  Ed wanted a machine that would eliminate the paper and could be taken directly into the field.  Today, the perfect solution would be a portable PC, but back then there were no such things — there weren’t any personal computers, either.

We designed a 50-pound “portable” computer that included a four-slot Multibus I card rack, a 3M tape drive, a Burrows plasma display panel, three switching power supplies, and two fans.  The tape drive was for loading the program and database and for saving the results of a site visit.  The plasma panel was that era’s idea of a liquid crystal display, except it was made out of glass and required a lethal 250 volts to operate.

Chris designed a distinctive front panel and an internal support structure for the components, and somehow managed to fit everything into a metal travel case with barely any room left over.  To power the unit in the field, we built a separate Gel-Cell battery pack.  (That was another 50 pounds — it had to last for four hours!)  It was a masterpiece of design in many ways, and it really was a forerunner of today’s portable computers.  All it lacked was low-power logic, an LCD, and modern battery technology.

The Computer Drop Test...

We weren’t designing the unit from written specifications.  It was an interactve design that entailed frequent meetings with Ed to work out the details.  One day, well into the prototype construction phase, Ed announced that he was going to do a “drop test” before he’d accept the unit.  He wanted it to survive a three-foot fall off of a table.  Whoa!  “Over my dead body,” Chris said.  “Not with our plasma display, no way!”

nika.jpg  Talk about portable!  The NIKA Field Scribe came complete with it’s own tote system, including handles and wheels!  The computer weighed 50 pounds, so the wheels were very handy.  And, for use in those out-of-the-way places (i.e., buildings without AC power), we built a companion battery pack (same size, same weight).

On one of our trips to Kansas City to show Ed our progress, an airport security guard asked us to take the unit apart, presumably so he could make sure it didn’t conceal a bomb.  I had the special tools we needed with me, just in case, and we wrestled the system apart in the security check area.  Later on that trip, while waiting for a plane at O’Hare, we bumped into some of our patient Oscar Mayer associates from Madison (the hog scale people, remember?).  They looked at us, then the NIKA equipment case, thought for a second about the lateness of the project we were still working on for them, and said: “So, trying to skip town, are you?”

... And The Ultimate Crush Test

Ed was very impressed with his machine; he called it the NIKA Field Scribe.  He showed it to the heads of all the major insurance companies and demonstrated how it could total up the costs for anything from repairing a window or painting a wall to installing electrical cables or a new roof.  After a few months, however, Ed realized that the insurance industry wasn’t ready to sign onto the new technology, so he used the machine to help trumpet his other services.  It was, as they say, an idea ahead of its time.

Ed visited us a few months ago, and I asked him about his Field Scribe, hoping he’d tell me about how it was still stashed somewhere in his living room.  Well, I shouldn’t have asked.  Ed says he removed the electronics so he could temporarily use the metal case for something else, but, while laying about in his garage, the guts were run over by a truck.  I hope he got the license number.  (Makes me rethink the merits of the three-foot drop test.)

NEXT MONTH:  Domiciles of the bench and famous.

EEKK and Del-Monte Corporations


Original publication date: June 1992

Heurikon Historical Highlights

A series of articles for The Horizon

by Jeffrey Mattox

EEKK and Del-Monte Corporations

In the 1970s, washing machines were not very high-tech; they certainly didn’t have computers in them.  However, if the washing system was destined for a bean-packing plant, computers were in order.

We were asked to build such a system by the EEKK Corporation of Schaumburg, Illinois.  EEKK provided control systems and related equipment to the food processing industry, and they wanted us to build a controller for use in two Del-Monte bean-packing plants.  One of the plants was in Florida, and the other was near Stevens Point, Wisconsin (just south of the city on highway 51).

There are many different types of equipment in an automated bean-packing plant.  There are bean sorters, washers, cutters, conveyor belts, and so on, and each piece of machinery has to be cleaned and washed once each day.  However, during the short, three-month packing season each year, the plant runs 24-hour per day, and the the time it takes to clean the equipment cuts into their production time.

The general washing sequence was to rinse each food-processing machine, then apply a chemical, wait for a specified amount of time for it to work, then rinse the chemical off.  That sounds fairly simple, but there were two factors that made things more difficult.  First, the piping system only had a limited capacity, so only one set of valves could be open at a time.  Second, once the washing chemical had been applied, it had to be rinsed off within a certain time window — not too soon or too late — otherwise the chemical would not work properly.

The Del-Monte plants had been shutting down operations for four to six hours each night while six workers went through each plant with water and chemical hoses and sprayed the equipment.  Cleaning was a time consuming and labor intensive operation.

Our Infamous MLP-8080 to the Rescue

We designed a controller around our MLP-8080 board that could sequence up to 64 sets of water and chemical values.  It had eight timing programs that could specify rinse, wash, wait, and final rinse times for various types of processing equipment.  When the operator pushed the start button, the computer would examine the database and devise a sequence for operating the valves to wash all the equipment in the least amount of time.

At some points during the sequencing, the wash and rinse cycles for different sequences would overlap.  That is, the system could be rinsing a bean cutting machine, while simultaneously applying the chemical to a conveyor belt and doing a final rinse on a third machine.  Once it started a chemical application, however, the computer had already determined that it would be able to rinse off the chemical during the allowed time window.

As usual in those days, we wrote the program in machine language, and it was very complicated.  Rolls of paper tape were strewn about the shop, and the Teletype machine gave out a constant background chatter.

eekk1.jpg  Switches on the font panel of the washing control system allowed the operator to select which pieces of the plant’s bean-packing machinery should be included in the washing cycle.  The exact timings for the various washing cycles were entered via the keypad and thumb-wheel switches at the bottom.  While the system was running, the large 7-segment displays at the top of the panel showed the time remaining in each phase of the overlapping washing cycles. The bean-plant washing system was housed in a huge enclosure, which was about the size of a Foto-Mat booth.  EEKK painted it bright yellow, so it really looked peculiar.


I can easily recall one specific problem we had while building the system.  For some reason, we couldn’t buy stranded 50-conductor ribbon cable; it only came with solid wire.  I don’t think they made much stranded ribbon cable back then — and 50-conductor ribbon cable was not as widely used as it is today.  The solid wire we were able to get was very hard to flex, and the crimps at the connectors were unreliable.  Every time we attached or removed a ribbon cable, we ran the risk of causing a loose connection.

The computer-controlled system had many advantages over the old manual system that Del-Monte had been using.  After we put the new system on-line, it took only one person to start the operation and one worker to go through the plant with a hose and clean around the hard-to-get-at places.  And, because of the computer’s smarts, the whole plant could be cleaned in only two hours.

The plant manager at Stevens Point reports that our computer equipment was in operation there for nearly ten years.  They have since switched to an Allen-Bradley sequencer.  The Florida plant stopped processing beans in 1980.

NEXT MONTH:  Our 100-pound “portable” computer.

UPDATE June 2009: I called the Stevens Point plant to see if our equipement was still there.  The plant manager told me they had been using our system up until a few years ago, and it was still operational. What a nice surprise.

The MLZ-DAQ — Madison Water Utility

banner.jpgOriginal publication date: May 1992

Heurikon Historical Highlights

A series of articles for The Horizon

by Jeffrey Mattox

The MLZ-DAQ — Madison Water Utility

Some of our old products were not major stars — a few were dead ends or just plain unglamorous.  One of those not-so-glamorous products was the MLZ-DAQ.  We designed the DAQ as an inexpensive, general-purpose, data acquisition board.  It was a Multibus® I board with 32 digital I/O bits, a 32-channel analog-input multiplexer, and a 12-bit analog-to-digital converter module.  It used static RAM, so we were space-limited to including only 1,024 bytes of memory.

What does make this board notable, however, is that most of the MLZ-DAQs we sold back in 1978 are still in operation — and right here in Madison!  In fact, you are dependent on a Heurikon MLZ-DAQ to meet many of your daily needs.

Like many of our early products, The MLZ-DAQ was engineered with a particular customer in mind.  In this case, it was designed for the City of Madison Water Utility.  They wanted to install a control center that would be connected to the 26 water pumping stations around the city.  This would permit the utility to monitor water pressures, tank levels, and various status signals, and to control water pumps, all from a central location.  Their system design engineers met with us and we used their specifications to design the board.

The telemetry system was put into operation in the early 1980s and has been working fine ever since.  Even though there are about 32 processors in the city’s inventory, we haven’t been asked to make any service calls or repair any processors.  This is because the city is doing their own maintenance.  That’s probably just as well, since no one in our service department claims to remember much about this particular board.

Although we only sold a few hundred MLZ-DAQ boards, that microcomputer board stayed on our price list for years.  Every time we considered dropping it, some impoverished customer, such as AT&T or Boeing, would decide to order a few.

mwu1.jpgThis is an example of the visible part of one of the city’s deep well pumps.  The water from the well pump goes into a nearby storage tank.  From there the water is pumped into underground the water mains.

How Our Water Flows

The water supply for our building comes from the old pumping station on Mineral Point Road (near the high school) or the new station atop the hill on High Point Road.  During the winter, the city pumps 30 million gallons per day to its customers — and 45 million gallons per day during the summer.  Although most of the utility’s sites have a deep well pump and a huge water storage tank, a few locations have storage tanks only.  At night, or when the overall water demand is low, the utility allows water to flow in reverse, thus refilling those storage tanks from the water mains.  Also, since the water mains are all interconnected in a giant underground grid, numerous pumping stations can be off-line or under repair at the same time — and we won’t notice.

When you turn on your water faucet or drive past a city pumping station, remember that Heurikon computers are being used to help keep the water flowing.  The City of Madison shares the honors with Oscar Mayer Foods and Cue-Nique Micro-Logic as having the oldest Heurikon products still in use.

mwu3.jpgEach remote site has a small control box that consists of one MLZ-DAQ connected to 32 optically-isolated I/O modules.  Since there are no other boards in the system, the processor’s bus interface is not needed, so the board is simply mounted to a panel using standoff insulators.  The data is relayed to the central control center using dedicated telephone lines and 300-baud modems.  Don Lautzenhiser, shown here pointing to our MLZ-DAQ, is responsible for maintaining the city’s system.

mwu2.jpgThe control center has three large CRT screens.  Two display well data for the east and west sides of Madison, and the third is used as a console for command and data entry.  Each line on the data displays represents data from one of the city’s wells.  Normally, most data is displayed on a green background.  However, if a water pressure, flow rate, or water level goes outside of certain preset tolerances, the condition is shown in red.  Other colors are used to highlight pump status information.  That’s Dennis Erickson at the controls.

NEXT MONTH:  Spilling the beans

The General Electric Company


Original publication date: April 1992

Heurikon Historical Highlights

A series of articles for The Horizon

by Jeffrey Mattox

The General Electric Company

We worked on four interesting projects with General Electric during the early years.  Two of them were with GE’s Large Steam Turbine-Generator (LSTG) Division in Schenectady (“Bet-You-Can’t-Pronounce-It-On-Your-First-Try”), New York — a huge factory that makes steam turbines and generators for power plants.  One of their critical operations is drilling holes for coolant in the thick copper bars that form the generator rotor coils.  Due to the geometry of the generator, each layer of the rotor coil is a different size and shape, but the holes in each layer still have to line up perfectly.  GE asked us to build the equipment that would synchronize the numerical data as it was requested by the hole boring machines.

The other project with LSTG was a welding machine controller.  Most welding machines attach two pieces of metal together, but this one put down a continuous bead of chromium around critical parts of steam valves to prevent wear.

Both of those projects used our MLZ-80 processor and a CRT/keyboard controller board.  We custom-designed a heavy-duty pedestal enclosure so the equipment was protected from the dirt, metal chips, and oil that pervaded the factory.

ge_welding.jpgThink green.  This is one of the three pedestal-mounted control systems that  worked together to deliver data to a large boring machine at the GE plant.  The display controller was the same one we used for the fruit market sign control terminal, hence the special area at the top which could display extra-large characters.  GE put status messages there.  The apparatus on the top provided cooling for the unit.  It used compressed air to generate a vortex — a miniature tornado — that literally pumped the heat out of the box.

Heurikon Scores an Early Win Over Intel

Another early GE project was with their Housewares Group in Allentown, Pennsylvania.  That’s where they assembled their two-slice toasters.  Two small calibration screws on each toaster timer had to be adjusted, but the people doing the adjustment had no way to know if they were setting the screws accurately.  It could take six hours or more before the timers were actually installed in a toaster and checked, and by that time it would be too late to readjust the setscrews.  So, Ben Koltisko, an engineer at GE, having heard about our work from his colleagues in Schenectady, stopped off in Madison to see us on his way back from visiting Intel about his timer calibration problem.  After Ben described what he wanted, we offered to make the electronic controls for his timer calibration and testing machine.  We proposed a system that had features Ben hadn’t even thought of but realized he could use.  Intel, however, merely offered a basic microprocessor, and they wouldn’t do any custom work.  Because we fully understood his problem from the get-go, he gave us the order.

As with many projects, we were caught short on the schedule and had to innovate.  For example, when we couldn’t find anybody willing to give us a short turn-around on finishing our 25 small enclosures, we took the raw computer boxes across the West Beltline to an automobile-painting company — the people there were much more accustomed to repainting vehicles and doing pin stripes, but they obliged us anyway with overnight service.

ge_ttt.jpgThirty of these control boxes were arranged on a slowly-rotating ten-foot Lazy Susan.  A toaster timer would be loaded into a fixture (not shown) and the controller would cycle the timer through a complete toasting cycle as the Lazy Susan turned.  An LED indicated if the timer passed all tests, otherwise the single digit LED displayed an error code.  An infrared LED at the rear sent serial data to a host computer, once on each revolution as the controller box passed under a IR receiver.

The project was a definite success.  After installing the new equipment, Ben said their calibration and test yields rose from 73% to 93%.

The interesting part about a toaster timer is that it has to account for the residual heat inside the toaster so that the second and third toasting works as well as the first.  No small trick.  The mechanical timers were really two-cycle thermostats.  When you started toasting, a bimetal strip was heated to a set temperature by a special heating coil.  When that set temperature was reached, the thermostat clicked, the special heater went off, and the thermostat cooled down.  After it cooled sufficiently (to the second setpoint), it triggered the pop-up solenoid and stopped the toaster.  That click you may have heard when your toast was almost done was not just a warning for you to get ready with the butter knife; it was actually part of the timing operation.

A few years ago, GE’s Housewares Division was purchased by Black & Decker, and the toasters are now sold under that name and made in Taiwan.  The reassuring timer click is defunct, too — probably the result of having gone solid-state.

The Versatron Toaster-Oven

Our fourth GE project was for another toaster-like product, called the Versatron Toaster Oven.  It had a control panel with an assortment of buttons, levers, rotary switches, neon indicator lights, and audible alarms.  Our task was to build the computer controls for sequencing a pneumatic machine that would fully test all functions of the control panel, including the switches, lights, and alarm.  The operator loaded a Versatron panel into the machine and the tester grabbed hold of the switches and went through a sequence of tests, monitoring the panel’s outputs, lights, and alarm.  The unit even had a bed of nails, much like our Genrad.

The machine took about 45 seconds to test one panel, and the mechanism clicked and clanked and hissed the whole time.  Very impressive.  But alas, just when we got the unit finished, GE pulled the Versatron off the market.  They had started selling the toaster-ovens before they had put a service network in place, and the ovens were not operating as planned — too many needed service.  The ovens were being returned for repair faster than GE could fix them.  So, they paid us for our work, took the testing equipment we had built, and, for tax purposes, fed the ovens and our testers to a trash compactor (ouch!).

ge-jeff.jpgThat’s me about to close the drawer on the Versatron bed-of-nails test fixture.  The tester sequenced through a wide array of mechanical and electrical tests of GE’s toaster oven control panel.  Indicator lights blinked, levers clanked, and numbers flashed — it was captivating to watch.  We didn’t have an air compressor, so we used tanks of compressed air to run the fixture’s mechanical actuators.

NEXT MONTH:  Monitoring Madison’s H-I-J-K-L-M-N-O supply.

How Programs Were Made in the Old Days


Original publication date: March 1992

Heurikon Historical Highlights

A series of articles for The Horizon
by Jeffrey Mattox

How Programs Were Made in the Old Days

We wrote our first lengthy microcomputer programs using the computer at the University of Wisconsin’s Computer Science Department.  We purchased the computer time, paying by the minute of CPU usage.  We started by reprogramming their mainframe’s macro assembler so it would understand Intel 8080 instructions.  When we had an 8080 program to assemble, we punched a deck of about 2,000 cards, fed the cards in via a card reader, and went to a Teletype machine where we punched a long paper tape of the resultant 8080 object code.  To be more accurate, we “submitted” the deck at the computer room window, waited overnight while the job was run (the night-time rates were cheaper), and then we made the object tape.  If one of the cards had a typo, it took us another day to fix it and rerun the job.  That type of interaction with a computer was called “batch” mode, and it was frustratingly slow.

We brought the paper tape back to our office and read it in on our ASR-33 Teletype machine.  The data went into RAM, and then we made a ROM copy.  Sometimes the tape would break or the teletypewriter would skip a sprocket and the program wouldn’t work — it was a very unreliable system.

Patchwork Quilts

After we tested the program, if we needed to change even a single line of the source code, we had to edit the card deck and repeat the whole process.  To avoid doing that for simple changes, we would frequently just “patch” the ROM version of the program by manually changing certain memory locations in a RAM copy of the program.  Manual changes to 8080 and Zilog Z80 programs were easy to do because the eight-bit machine-code formats used by those chips were simple to memorize.  After making many patches, however, our programs would become impossible to maintain, so we ultimately had to go back to the punch cards and clean things up.

Since we were writing machine-language programs (not BASIC, FORTRAN or C) and had only a limited amount of space in the small ROMs, we’d frequently hand-assemble the source code modifications we were planning and figure out on paper if the total number of bytes we were adding (less those we were removing) would overflow the ROMs.  If we had too many bytes, we went on a search-and-destroy mission, looking for parts of the program that could be streamlined or eliminated.  This resulted in some very interesting, but highly convoluted and hard-to-maintain code.

The Teletype machine ran at only 10 characters per second, so a lengthy dump was very time-consuming.  The first thing we wrote was a monitor program for the 8080 that allowed us to type commands to the Teletype so we could read and write memory locations.  We called it “RAID” for Real-time Assembler and Interactive Debugger — it was supposed to kill-bugs-dead.  Later, when we modified the monitor to work with Zilog’s Z80 chip, we renamed the program “ZRAID.”  (That monitor served us until the 68000 came along — then we wrote Hbug.)

Instead of having an RS232 voltage-level interface, teletypewriters used a 20-milliampere current loop, so our early microcomputer boards had a current loop I/O circuit.  Most microcomputer manuals explained how to rewire and connect a Teletype machine, and many early CRT terminals had a current loop option.

Teletype Mechanics

If the Teletype would act up, we would have to stop our work, get out our tools, and try to fix it.  Pete Berbee and I once spent a whole day just trying to adjust a greasy camshaft in the damn machine so it wouldn’t print gobbledegook — and we never did get around to doing any useful work that day.

shopThis is an example of our development environment. The Teletype machine (right) was connected to the processor board in our main computer system (center), which was temporarily wired to the equipment we were designing (left). We used the switches and lights on the development system to enter the initial programs, loaded a paper tape program through the Teletype machine, and then typed commands on the Teletype to test portions of the program.  When the program was finished, we programmed ROMs and installed them in the customer’s equipment.

Through the surplus market, we came across an old seven-track magnetic tape machine.  Using trial and error on a I/O connector, we figured out how to start and stop the tape motion.  We wrote a short bootstrap program to control the tape machine.  (The bootstrap had to be read into memory from paper tape).  This allowed us to save large programs and quickly reload them a day or two later.  The tape machine roared like an industrial vacuum cleaner when it was running.

By the end of the 1970s, Digital Research had produced the CP/M operating system, which we quickly ported to our MLZ-80 board.  CP/M gave us our first in-house capability to edit and assemble programs for our hardware.  The glory days of the Teletype were ending, and we cautiously invested in our first CRT terminal.  Our MLZ-80 had 4,096 bytes of RAM, which was just enough to load the operating system, and was the first Multibus I card in our market to include a floppy disk controller.  A separate 32-kilobyte RAM card was needed, however, to run any programs!

NEXT MONTH:  Toaster-master General.

Syndicate content