Full Width 
Shortcuts 
Sign Up 
Log In 
Articles 
Reading List More from Ken Shirriff's blog
Spacelab was a reusable laboratory that could be carried in the Space Shuttle's cargo bay, providing lab space for astronauts and experiments.1 Because Spacelab was a European project, it used a French-built minicomputer, the Mitra 125 MS,2 rather than the Shuttle's main computers, IBM-built AP-101 systems. For storage, the Spacelab computer contained 128 kilobytes of RAM. Rather than silicon memory, the computer used magnetic core memory, with each bit stored in a tiny ferrite ring. In this article, I take a close look at this computer's core memory system. The core stack from the Spacelab computer. I removed the top board to show the core planes. The illustration below shows how Spacelab fit inside the Shuttle's cargo bay. The pressurized laboratory is the cylindrical module in the front of the cargo bay, connected to the Shuttle by a tunnel. Experiments were mounted on pallets behind the laboratory. The laboratory held three identical Mitra computers.3 One computer managed Spacelab itself, while the second computer managed the experiments. The third computer provided a backup in case of failures. Spacelab was a pressurized cylinder in the Shuttle's cargo bay, connected to the Shuttle by a tunnel. It provided a laboratory for researchers to perform experiments. This illustration of Spacelab is from NASA, C-1976-4380. The photo below shows the core memory stack, removed from the computer. The core memory stack takes up roughly a third of the computer. The entire side panel of the computer detaches, and the core memory unit slides out. Since the computer is cooled by conduction, firmly attaching the core memory stack to the side panel kept it cool. The core memory stack consists of seven boards: a driver board, four core plane boards, a second driver board, and an interface board. Each board has two 160-pin connectors that plug into a large daughter board on each side, providing extensive connectivity between the boards. The daughter board on the right has another 160-pin connector that links the memory stack to the rest of the computer. (These connectors are the long blue connectors in the photo.) The core memory stack in front of the Mitra computer. The circuit boards have been removed from the far side of the computer. How core memory works One of the hardest problems for early computers was storage. Computers of the late 1940s and early 1950s stored data through techniques such as sound waves in mercury, spots on a CRT screen, or spinning magnetic drums, but these all had limitations. What computers needed was dense, inexpensive storage that was fast, reliable, and could be accessed randomly. During World War II, Germany developed special magnetic alloys that could "flip" from one magnetic state to another. After the war, American researchers realized that these materials could be used for storing binary data: "It was completely obvious that you could make a memory with this material," in the words of Jan Rajchman. Different aspects of core memory were patented by various inventors (including independent inventor Frederick Viehe, An Wang at Harvard, Jan Rajchman at RCA, and Jay Forrester at MIT), leading to expensive patent battles. (IBM ended up paying $400,000 to Wang—who used the money to build the computer company Wang Laboratories—and $13,000,000 to MIT.) I view Jay Forester as the most important inventor, developing the design of practical core memory, researching magnetic materials, and building the first core memory in 1953 for the groundbreaking Whirlwind computer. Core memory is based around a tiny toroidal magnetic core, one per bit.4 A core can be magnetized clockwise or counterclockwise to store a bit. The core can be magnetized by threading a wire through the core: running a current through the wire produces a magnetic field that magnetizes the core, while running a current in the opposite direction produces the opposite magnetization. A key problem with core memory was how to wire the cores without an absurd number of wires: if each core had a separate wire, just 16 KB of storage would require over 100,000 wires. The solution was called "coincident current addressing". The cores are arranged in a grid, with horizontal and vertical wires, as shown below. By running a current through one horizontal wire and one vertical wire, the single core at the intersection was selected. But wouldn't that magnetize all the cores along the horizontal and vertical wires? The key was that the cores were constructed from special magnetic materials with a property called hysteresis: a small current leaves the core completely unchanged, while a larger current flips the core's magnetic state. The currents through the horizontal and vertical wires were carefully selected so each wire had half the current necessary to flip the core; where the wires intersected, the two currents provided sufficient magnetic field to flip the core. Energizing an X drive wire and a Y drive wire selects one core, highlighted in yellow. Diagram adapted from iDigital Computer Components and Circuits, R. K. Richards, p355 The next step was reading the core. A sense wire was threaded through all the cores in the two-dimensional plane. To read a core, the X and Y select wires were driven to flip the desired core to the 0 state. If the core was already in the 0 state, nothing happened. But if the core was originally in the 1 state, the magnetic field changed as the core changed state. This induced a small current in the sense line, indicating that the core held a 1. Note that reading the value of a bit destroys that value. Thus, a core needs to be rewritten after reading, to restore the original data. To access a word of memory at a time, core planes were combined into a three-dimensional stack (below). Since each plane held one bit of the word, a 16-bit word would have a stack of 16 planes. All the planes shared the signals to drive the X and Y lines, so a one-word column through the stack was accessed in parallel. Each plane had a separate sense line to read out the bit. The core stack from the Saturn V LVDC (Launch Vehicle Digital Computer) consists of 14 core planes. This stack is at the US Space & Rocket Center. Photo from NCAR EOL. I retouched the photo to reduce distortion from the plastic case. But how do you write different values to the different bits? The trick was to put an "inhibit" line through all the cores in a plane, running the inhibit line in the opposite direction to the X lines. Putting a current through the inhibit line would cancel out the current through the X line, preventing the core in that plane from being modified. To summarize, a read-write cycle consisted of first energizing a pair of X and Y lines to select a word and write a 0 to the column of cores in that word. The sense lines provided a readout of the bit values. Next, the X and Y lines were energized in the opposite direction to write a 1 to the cores. At the same time, the inhibit lines were energized for each plane with a 0 bit. Thus, the cores either flipped back to 1 or stayed at 0, as required. Many core memories, such as the one below, used a shared wire for sense and inhibit, so there were three wires through each core. Closeup of an IBM 360 Model 50 core plane. The cores in this computer were called 19-32 because their inner diameter was 19 mils and their outer diameter was 32 mils (0.8 mm). The final ingredient to make core memory practical was the diode matrix. The X and Y lines require driver circuits that can produce fast, bidirectional high-current (e.g. 600 mA) pulses. A core memory plane can have hundreds of these lines. Providing a separate driver for each wire would be very expensive, especially in the vacuum tube era. The solution was to put separate drivers at each end of the wire, with each driver supporting multiple wires. For a trivial example, suppose you have 9 vertical lines. Put three drivers (A, B, and C) on the top, each connected to three wires, and three drivers on the bottom (1, 2, and 3), each connected to three wires. By energizing a driver at the top and a driver at the bottom (e.g. B and 1), the corresponding wire will be energized. Now, N drivers on each side control N2 wires, supporting N4 cores in total. Illustration of how "top" and "bottom" drivers work together to select a single line (red) through the core matrix. However, current can take alternate paths, such as the pink path. Unfortunately, it's not quite that easy. Current can take "sneak paths" through the cores, such as the path in pink above. The solution is to add diodes to ensure that current can't take the wrong path. Since a wire needs to be driven with currents in both directions (to flip cores both ways), two diodes are required on each wire, as shown below, one in each direction. Each matrix input (A, B, etc.) is replaced with two inputs, one to drive each direction. (The horizontal wires also require diodes, not shown.) Adding diodes ensures that current only takes the desired path. Since each wire requires two diodes, core memories used many diodes. Fortunately, diodes were small and inexpensive, so a large quantity of diodes was manageable. The photo below shows the diode stack for the computer used in the Saturn V rocket, the Launch Vehicle Digital Computer. Closeup of the diode matrix in the Saturn V LVDC. Diodes are mounted vertically using cordwood construction between two printed circuit boards. Originally, core memories were tediously constructed by hand. For the Whirlwind computer, it took a full 40 hours to wire a 64×64 core plane. Companies such as IBM soon developed automated techniques to manufacture core memory, and the price dropped by a factor of two every two years, similar to Moore's Law.5 Core memories became fast, inexpensive, and reliable, and were the most popular form of main-memory storage until semiconductor memory took over in the 1970s. The Spacelab computer's core memory The Spacelab computer's memory was manufactured in 1980, a late date for core memory, so it is advanced and high density. The photo below shows one of the four core plane boards from the computer. Each board holds 16K of 18-bit words (32 KB), so the computer has 128 KB of RAM in total. The computer is a 16-bit computer, but each word also has a parity bit and a "storage protect" bit, bringing the total to 18 bits. (The storage protect bit provided write protection on a word-by-word basis, preventing programs from being accidentally overwritten. Because core memory is nonvolatile, a program could be loaded into memory once and would be immediately available every time the computer was powered on.) One of the core memory boards from the Spacelab computer. The core memory board is arranged with 1024 vertical (Y) wires and 288 horizontal (X) wires, supporting 294,912 lithium ferrite cores. These very thin wires are soldered to tiny pads on the printed-circuit board. The board supports 18 bits, which is visible as 18 alternating stripes of green and copper because alternating sense lines have different colors. The board has 36 sense lines: the left and right halves of the board have independent sense lines to reduce noise, so the board has 36 sense lines for 18 bits. The sense wires pass through four holes in the board (green arrows) and are soldered on the back of the board. The photo below shows a close-up of the cores. Each core is approximately 32 mils (0.8mm) in diameter, the same as the IBM System/360 cores shown earlier. However, the cores are stacked much closer, with only a small gap between cores. The X and Y select lines are copper-colored, while the sense lines are green. (The wires are all enameled to prevent short circuits.) The sense wires loop around at the left, forming a single circuit through each bit section. Half the Y lines form loops at the bottom; the other half form loops at the top. Thus, each Y line passes through the plane twice in a U-shaped path, which will turn out to be important. A close-up of the cores. I think that some rows tilt left and some tilt right to ensure that the sense lines keep the same polarity when they switch direction. Photo courtesy of CuriousMarc. The other side of each circuit board holds the sense amplifiers and the diode matrix for the core plane. The diode chips are the square black packages, each containing 16 diodes for 8 core lines.6 In the red-outlined regions, one end of each vertical U-loop is connected to a diode chip; the lines of diagonal holes are the vias that pass each signal through the board. The other end of each vertical U-loop is connected to one of the blue board connectors on the side; these vias are in the blue-outlined regions. The horizontal lines use the diode chips and vias in the green regions. One end of each line is connected to a diode chip, while the other end is connected to a board connector through traces on the other side. Note that some vertical lines connect to the diode chips at the top of the board, while others connect at the bottom. Similarly, some horizontal lines connect at the left while others connect at the right. The back side of the core plane board holds the diode matrices and sense amplifiers. The central region (yellow) holds 18 sense amplifier chips, the black DIP integrated circuits, each containing two amplifiers.7 The white packages are resistor packages, holding multiple resistors to bias and terminate the sense amplifier lines. The wires from the sense amplifiers are connected as twisted pairs that are soldered to the board right next to the corresponding sense amplifier chips. Using twisted pairs for the whole distance prevents the wires from picking up electrical noise, which could overwhelm the tiny signals in the sense wires. The sense wires pass from one side of the board to the other through four holes in the board (yellow arrows), and then are glued down as they traverse a significant distance on the board. (It must have been difficult to manufacture the board without breaking the tiny, fragile wires.) Each sense wire loop forms a twisted pair that is fed to the other side through a hole in the circuit board. Above the hole, you can see a gray blob where sense wires were spliced for some reason. Also note how alternating vertical wires are soldered to the circuit board, with circular vias connected to the other side. The other vertical wires form loops. are soldered to the circuit board Detecting signals on the sense lines is tricky because the pulses are very small, a few millivolts. Because the sense lines run next to the X drive lines, they can easily pick up noise from the high-current pulses on the X lines. To minimize this noise, the sense lines cross each other between two plane sections, forming a "bow tie", as shown below. The result is that an X line runs next to the positive sense line for half the length and the negative sense line for the other half. Thus, the induced noise cancels out. A close-up of the sense lines. The 16 sense lines in the middle are green, while the sense lines above and below (as well as the X lines) are copper. Note that the sense lines cross, while the X lines continue horizontally. The large circles are vias through the board. The core memory in the Spacelab computer used a different architecture from a typical core memory, improving performance by eliminating the inhibit line. This architecture was called a 2½D memory.8 If you're familiar with core memory, the lack of inhibit lines may seem puzzling: how do you write 1 to some bits and 0 to other bits? The trick is to have separate X driver circuitry for each bit.9 When writing data, the X lines are only energized for bits that receive a 1; the other lines are left unenergized, so the bits remain at 0. The disadvantage is that instead of one set of X driver circuits, you now need one set for each bit, a factor of 18 more for an 18-bit word. However, with the development of core drivers on integrated circuits, the cost of the additional driver circuitry became less significant. The memory system used an technique called phase reversal to cut the number of vertical drivers in half. Recall that pairs of vertical wires are joined by a U-connection. By driving the wire in a particular direction, the left side or the right side of the pair can be selected. For example, the drawing below shows how the two wires select the left core, but not the right core. In the left core, both currents go through the core in the same direction, inducing a magnetic field in the toroid.10 But in the right core, the two currents cancel out, so there is no magnetic field created. But if the current in the vertical loop is reversed, the right core will be selected, rather than the left core. The point is that instead of using two drivers for the vertical wires, one driver is used, reversing the current to select the left or right core. Connecting pairs of vertical wires into a U-shaped loop lets each driver control twice as many cores. The diagram below shows the complex wiring for X drive wires. Each band of 16 wires corresponds to one bit in the 18-bit word, and has a separate sense wire. The top band of 16 X lines is connected to four contacts on the board connector; each contact is connected to four X lines through the curving PCB traces. The bottom band of 16 X lines is wired to diode modules on the other side of the board, connected through the round vias. (Each wire has the opposite connections—diode module or board connector—on the other end.)11 One group of four X wires is energized through the connector, while four wires are energized through the diode matrix, selecting one of the 16 X wires in the group. The PCB wiring for the X lines. Other boards in the memory stack The memory stack has seven boards in total, arranged as a driver board, the four core planes, a second driver board, and an interface board. I haven't examined these boards in detail, but I'll give some preliminary information. The photo below shows one of the two driver boards. It provides the high-current pulses for the X and Y select lines. The board is crammed with specialized core memory driver chips12, along with a few logic chips to control the drivers. It has separate drivers for the two ends of the select lines, allowing the matrix selection described earlier. One of the two memory driver boards. Click this image (or any other) for a larger version. Since there are two driver boards and four core memory boards, at first I thought that each driver board controlled two core memory boards. The configuration turns out to be more complicated, with one more layer of matrix selections to cut the number of drivers in half. To simplify slightly, consider the X lines on a core board to have left ends and right ends, both of which must be energized to activate a line. For the left ends, the first driver board powers core boards 1 and 2, while the second driver board powers core boards 3 and 4. The right ends are shuffled: the first driver board powers core boards 1 and 3, while the second driver board powers core boards 2 and 4. Now, if the first driver board powers the left and right ends, core board 1 is the only one with both ends active. If the first driver board powers the left ends while the second board powers the right ends, core board 2 is activated. Similarly, core board 3 or 4 can be activated. The point is that since each set of drivers is connected to two core boards, two sets of drivers are required instead of four. The final board is the interface to the rest of the computer. It has many transistor arrays in DIP packages, along with many resistors. It seems that the board uses discrete transistors to drive the bus, rather than using interface chips, which is unexpected. The board has some wire-wrapped jumpers in the lower center region, presumably for configuration. The interface board has some unused space in the lower left. Conclusions Core memory had a long life, surviving even as computers migrated from vacuum tubes to transistors and then integrated circuits, but eventually semiconductor memory made it obsolete.13 Core memories lasted even longer in aerospace applications since it had two key advantages over semiconductor memory: it retained data even without power, and it was resistant to radiation. The Spacelab computer, manufactured in 1980, was near the end of core memory's reign, so it is more advanced than a typical core memory system, with higher density, extensive use of integrated circuits, and the 2½D architecture. But eventually the high density, low cost, and low power consumption of semiconductor memory won out. In 1991, the Space Shuttle flew with upgraded main computers, the IBM AP-101S that used semiconductor memory instead of magnetic core. Spacelab's Mitra computers were also replaced, using the AP-101SL, which was based on the AP-101S but modified to support the instruction set and peripherals of the original Spacelab computer.14 Although core memory is now firmly in the past, it still lives on in the expression "core dump". I plan to investigate the Spacelab computer some more. For updates, follow me on Bluesky (@righto.com), Mastodon (@[email protected]), or RSS. Credits: Thanks to Steve Jurvetson for providing the Spacelab computer. Thanks to CuriousMarc for photography and help disassembling the computer. AI statement: Despite the presence of the em dash, no AI was used in the writing of this article (details). Notes and references It seems that 16 Shuttle flights used the Spacelab pressurized module, while 6 or 9 flights just used the unpressurized Spacelab pallets. (Why do sources never agree?) Originally, Spacelab was expected to be used for 30 flights every year (Status Of The Spacelab Program, 1974). ↩ The Spacelab 125 MS computer was built by a French company called CIMSA, using the Mitra architecture created by CII. I explained the complex history of these companies in my previous Spacelab computer article, so I won't go into it here. On the ground, the Spacelab project used Mitra 125 S computers that were functionally identical to the Mitra 125 MS (details) computers that were used in space. A core memory board from a Mitra 125 S ground computer was described on EEVblog (video, video). The computers had identical architectures, but the 125 MS was militarized and designed for "severe environmental conditions" (details). The EEVblog memory board was manufactured by Ampex and has a different design from the board that I examined. The Mitra 125 S memory board, built by Ampex. Screenshot from EEVblog #668. ↩ Spacelab was modular, so it could be be flown in different configurations. The habitable module could be flown in two different sizes, with experiment pallets mounted outside the module. Spacelab could also be flown without the habitable module, with experiments controlled from inside the Shuttle. In this case, the computers and other equipment were mounted in a smaller pressurized cylider called the "igloo". ↩ I'm describing "standard" core memory, but there were many esoteric designs for core memory. One approach used two cores per bit. Another approach used cores with multiple holes, such as cubical BIAX cores, transfluxors with a large hole and a small hole, or IBM's three-hole design. Many of these approaches could read a core without erasing it (non-destructive readout), but almost all cores used standard toroids. ↩ Later, companies discovered that it was cheaper to have core memories hand-manufactured in Asia and moved away from automated production. (See Memories that Shaped an Industry, p. 251. If you're interested in the history of core memory, this is the book to read.) ↩ The diode array chip is marked FSA2977 and contains 16 diodes, 8 common-cathode and 8-common anode. Pins 2 through 9 are connected to eight core wires. Pin 1 is driven high, or pin 10 is driven low, depending on the desired current direction. I couldn't find a datasheet for this part, but it appears to be similar to the Motorola MAD1103 Core-Driver Diode Array or the Silicon General SG5772F. ↩ A schematic matching the diode array, from the Motorola MC1103P datasheet. The sense amplifiers are National Semiconductor DS5534 chips. Each IC contains two differential amplifiers, converting the tiny sense signals into logic signals. The strobe signals indicate when the amp should read a bit; the strobes come from the IC on the left side of the board, a 54150 dual 4-input NAND gate, 50Ω line driver. Diagram of the sense amplifier, from the National Interface Integrated Circuits Databook. ↩ The 2½D memory architecture is described in detail in 2 1/2 D High Speed Memory Systems—Past, Present, and Future. Due to complicated factors and tradeoffs, the 2½D approach was attractive for systems of 16 Kword storage and above. In particular, eliminating the inhibit line boosted performance. IBM's Large Capacity Storage system used a 2½D architecture with just two wires per core to provide a megabyte of storage at a comparatively low cost, sharing the X line with the sense line. However, this approach turned out to be slow, so using three wires per core (as in the Spacelab computer) was more common. ↩ Note that the 2½D architecture requires separate per-bit drivers along one axis, not both. Since cores require two currents to flip, inactivating one axis is enough to prevent the corresponding cores from flipping. ↩ The direction of the magnetic field is given by the "right-hand rule": if you point the thumb of your right hand in the direction of the current, the magnetic field curves around the wire in the direction of your fingers. It may not be obvious how the currents add or cancel when the wires are in different directions. You can imagine moving the two wires until they are parallel, and then see if the currents are in the same direction or opposite. (This follows from Ampère's law, which states that the magnetic field around a curve (e.g. the core) is proportional to the net current through the corresponding surface.) ↩ For reference, this footnote describes the details of the core plane wiring, probably in more detail than anyone wants. For the Y lines, there are 1024 vertical lines, forming 512 U-shaped loops. Half of these are connected at the top, and half at the bottom. One end of each loop is wired directly to a connector on the side, while the other end connects to a diode matrix. The connectors provide 32 lines that can act as a source or a sink. Each of the 32 lines is connected to 16 vertical wires, for 512 vertical wires in total. Each quadrant of the board has 8 of the 32 lines, connected to a group of 8 vertical wires, a second group of 8 vertical wires, and so forth for 16 groups. For the diode connections, the connectors provide 16 source lines and 16 sink lines. Each diode chip has one source line and one sink line, feeding 8 vertical wires. Each source and sink line is connected to four diode chips, one in each quadrant in a mirrored pattern. Thus, the 16 source lines and 16 sink lines are connected to 64 diode chips, feeding 512 vertical loops. (Since each quadrant of the board has unique direct connections and the diode connections within a quadrant are unique, a unique core is selected. Specifically, 32 direct connections times 16 diode connections gives 512 combinations to select a vertical loop. The polarity selects which half of the loop is active, uniquely selecting one of 1024 vertical wires.) For the horizontal wiring, the 288 wires are grouped into 18 bands (one for each bit), with 16 wires per band. Each band has four direct signals from the connector. Each one is connected to four horizontal lines, 16 in total. (The visible PCB traces (shown earlier) connect the 16 wires to four connector pins (A,B,C,D) in the pattern AABBCCDDDDCCBBAA.) For the horizontal diode connections, the connector provides 4 source wires and 4 sink wires, which feed the 16 horizontal wires in a pattern 1234123412341234. By energizing the appropriate direct and diode wires on either side, one of the 16 lines is selected. One complication is that each diode chip has 8 outputs, but each source/sink goes to 4 wires. The solution is that each bit group uses half of four diode chips (4 outputs from each). Thus, the four source and sink wires are shared across two bit groups. This is not a problem for selection because the direct connections control whether the bit is active or not. The horizontal diodes are arranged asymmetrically. The left side has 8 diode chips at the top and 8 at the bottom, supporting 8 groups of 16 wires. The right side has 20 diode chips (4 additional in the middle), supporting 10 groups of 16 wires. Thus, all 18 bit groups are supported, with some asymmetry in the board layout. The left and right sides of the core plane have separate sense lines, so there are 36 sense lines in total. These go to the 18 dual sense amplifiers. Each sense amplifier has two outputs connected, a wired-OR to combine the left-hand data with the right-hand data, providing 18 bits of output to the connector. A diagram showing the topology of a core board. Click this image (or any other) for a larger version.) The diagram above summarizes the structure, showing one of the 18 bits. It omits the details of which connections are at the top, bottom, left, or right. ↩ Each driver board has 53 core driver chips of type SN55325. The SN55325 core driver chip, from the databook. Each chip has two 600 mA "sources" and two 600 mA "sinks" connected to two outputs. By energizing a source on one end of a line and a sink on the other end, the line can be driven in the desired direction. The driver board also has 39 driver chips of type SN55327. These chips are similar, except they can be used as either four sources or two sinks. These chips are used for the diode matrix inputs, where an input is either a source or a sink. ↩ I wrote about the Spacelab computer's CPU earlier. I've written about other core memory systems including the IBM 1401 core memory, IBM 360 core memory, Saturn V LVDC, and Apollo Guidance Computer. ↩ The Space Shuttle's replacement AP-101S computer used semiconductor memory, so it needed to deal with volatility and radiation. The new computer used battery backup to preserve memory contents when powered off, a feature that core memory had provided automatically. To avoid data corruption from radiation, the new computer had six extra storage bits for each word to implement an error-correcting code. The computer constantly scanned for bit errors and corrected them. Radiation wasn't just a theoretical risk: a single Shuttle flight could encounter over 100 bit flips due to radiation (details). For more information on the AP-101S computer, see my previous article, The rise and fall of IBM's 4 Pi aerospace computers. I wrote about Spacelab's original computer and the upgraded AP-101SL computer in Reverse engineering circuitry in a Spacelab computer from 1980. ↩
In 1948, IBM introduced the 604 Electronic Calculating Punch. This machine was a programmable calculator, about the size of a double refrigerator. It was not quite a computer, but was programmed by plugging wires into a plugboard. This machine read numbers from a punch card, performed up to 60 calculations on these numbers, and then recorded the results by punching holes in the card.1 It processed 100 cards per minute—over one card per second—and IBM advertised it as the equivalent of 150 engineers. The machine rented for $550 a month, making it very popular, with over 5600 units produced.2 The IBM 604 Electronic Calculating Punch. Photo from Ed Thelen's IBM 604 page. The IBM 604 came out just after the transistor was invented, too early to use transistors. At the time, calculators and computers were moving from slow electromechanical components to fast vacuum tubes. One of the innovations of the 604 was to combine a vacuum tube and its associated circuitry into a pluggable module. Along the left side of the photo above, you can see rows of these modules with the handles sticking out, making it easy to replace a faulty module. More modules are behind the silver metal covers. In total, the IBM 604 used about 1300 vacuum tubes. The photo below shows a pluggable tube module, with a vacuum tube underneath the insulated handle. The nine pins at the bottom of the module plugged into a socket in the 604, with the sockets connected by backplane wiring. The vacuum tube was also socketed, so a bad tube could be quickly replaced. At the left, the resistors and capacitors are mounted on insulating wafers. Modules provided a dense way to implement circuits, packing components into three dimensions. The TR-3 trigger module from the IBM 604 Electronic Calculating Punch. Each pluggable tube module implemented a specific function, such as an inverter, amplifier, or power driver. The module above is a "trigger" module, type TR-3. A trigger is a circuit with two states—on and off—and can be switched from one state to the other, providing one bit of temporary storage. (In modern terminology, this is called a flip-flop.) Triggers were important building blocks in the 604, generating timing signals and storing pulses. Arithmetic in the IBM 604 was implemented with decimal counters, built from TR3 triggers. In this article, I describe the circuitry of the TR-3 trigger module. (I recently wrote about a thyratron module in the 604; this is a different module.) After reverse-engineering the module, I powered it up. The video above shows the module in operation. By pressing buttons, I switch the trigger from one state to the other. Glowing orange neon bulbs show the state of the trigger module. The fundamental feature of the trigger is that it stays in a state until I push the other button. This might appear trivial, but the ability to store information is vitally important for computation. How a vacuum tube works The trigger module uses a common type of vacuum tube called a triode, which amplifies a weak signal to control a stronger signal. The diagram below shows the construction of a triode vacuum tube. The heater is a filament, similar to an incandescent light bulb, that heats the cathode to roughly 750 ºC. At this high temperature, the cathode emits electrons. If a large positive voltage (say, 150 volts) is put on the plate, the negatively charged electrons are attracted to the plate. The stream of electrons from the cathode to the plate causes a current to flow through the tube. Since air would block the electrons, the fragile glass envelope holds a vacuum, giving the vacuum tube its name. The current is controlled by the grid: if a small negative voltage is placed on the grid, it repels the negative electrons, preventing them from reaching the plate and blocking the current through the tube.3 Thus, a small signal on the grid controls the large current through the tube. The components of a triode vacuum tube. From IBM 604 Customer Engineering manual. The advantage of vacuum tubes was that they could switch on and off millions of times per second, phenomenally faster than electromechanical devices such as relays. The clock speed of the IBM 604 was 50 kilohertz, much below what a tube could handle, but three orders of magnitude faster than the 50 hertz pulses in an electromechanical accounting machine like the contemporaneous IBM 407. The tube that I used in the module is called a 2033.6 This tube is a dual triode, combining two triodes into one physical glass tube. Dual triodes were very popular because they doubled the density of the circuitry. In the photo below, the two vertical black structures are the plates of the two triodes; the other structures are not visible as they are inside the plates. The 2033 dual-triode vacuum tube. This tube is a "miniature" vacuum tube, about 5 cm long including the seven pins at the bottom of the glass envelope.4 Since a single triode has five connections, you might wonder how a dual triode manages with seven pins instead of 10. The trick is that both triodes share the cathode and heater connections, which limits the tube to applications that don't require separate cathodes. One disadvantage of vacuum tubes is that the heater uses considerable power. This tube's heater requires 6.3 volts at 300 milliamps—almost 2 watts per tube. Using 6.3 volts may seem a bit random, but many vacuum tubes used this voltage for historical reasons: this was the typical voltage provided by a 6-volt automobile battery.5 In the photo below, you can see the orange glow from the two heaters, mostly hidden by the plates but visible at the top and bottom. The tube powered up, showing the glowing filaments. Inverters and the trigger circuit The trigger circuit is based on two inverters, so I'll start by explaining the tube inverter circuit.7 The idea of an inverter is to amplify and invert the input signal: a "low" input results in a "high" output and vice versa. First, consider a low input: if a negative voltage is applied to the grid, the flow of electrons is blocked, turning off the tube. In this case, the resistor pulls the output high with 150 volts. However, if a positive voltage is applied to the grid, the tube turns on and conducts current. This current pulls the output down, due to the voltage drop across the resistor, producing a low output of 50 volts. Thus, a low input causes a high (150 V) output, while a high input causes a low (50 V) output, providing the desired inverter action. Note that the input signal has a swing of over 50 volts, very large compared to a transistor circuit. Moreover, the output voltages are much higher than the input voltages, which is somewhat inconvenient when connecting circuits. An inverter circuit. Adapted from IBM 604 CE Manual. A trigger is constructed from two inverters connected in a loop. The output of the first inverter is fed into the second inverter, and the output of the second inverter is looped back to the first inverter. If the first inverter has a high output, the second inverter has a low output, which is fed back to the first, maintaining the high output from the first inverter. The situation is similar but opposite if the first inverter has a low output. Thus, this circuit has two stable states, with one inverter on and the other off.8 Once the circuit is placed into a state, it will remain in that state until forced into the other state. Two inverters in a loop can store a 0 or a 1. I reverse-engineered the TR-3 module, creating the schematic below.9 It's a bit tricky to see the loop of inverters because the two inverters share one tube and are wired in a cross-coupled arrangement. In brief, one inverter uses the left half of the tube and the other uses the right half. The plate output from one side is wired to the grid input on the other side, through 200K and 1K resistors. The two module outputs (pins 7 and 8) are taken from the plates, but output 8 has a resistor between it and the plate. As a result, the two outputs provide different voltage levels, making the module more flexible to use.10 The two inputs force the trigger into one state or the other. The inputs are connected through 40 pF capacitors, providing AC coupling so the inputs can use different voltage levels from the outputs. Reverse-engineered schematic of the TR-3 trigger module. Note that the pin numbers for the module are different from the pin numbers for the tube. One tricky part is the connection between one inverter's output and the other inverter's input. The problem is that the output voltage is 50 to 150 volts, but the input grid voltage must be close to zero (a bit positive or a bit negative). The solution is to use a large negative voltage (-100 volts) and a resistor divider as a level shifter. With a large positive voltage from the plate and a large negative bias voltage, the resulting grid voltage ends up being moderately positive or moderately negative. As a result, the circuit requires both a high positive voltage (for the plate) and a high negative voltage (for the bias), complicating the power supply requirements. The inputs are fed into the grid through capacitors, allowing a pulse to pass through the capacitor to the grid. You might expect that a positive pulse would turn on the triode, but the module was used in the opposite way, with a negative pulse to turn off the triode. (This direction is more sensitive, because a tube has more gain when it is on.) Thus, a negative pulse on the left input will turn off the left side. The plate output of the left side goes high, pulling the gate of the right side high, turning the right side on. The plate output from the right side goes low, pulling the gate of the left side low, keeping the left tube off. Similarly, a negative pulse on the right input turns off the right side, causing the left side to turn on. Multiple pulses have no effect; that side remains off. Positive pulses also have no effect; the circuit is designed so a positive pulse is not sufficient to turn a triode on.11 I found the trigger circuit to be somewhat temperamental: the trigger needs to be stable enough to stay in one state or the other, while also unstable enough that an input pulse will reliably flip it to the other state. The circuit depends on carefully balancing the grid voltages and the input voltages. I experimented with different supply voltages and found that in some cases the trigger would oscillate, while in other cases, the trigger would get stuck in one state. Interestingly, the later IBM 650 computer abandoned this type of trigger circuit, instead using diode logic (AND and OR gates) to set and reset a loop of two inverters. With this type of trigger, the state is determined by reliable Boolean logic, rather than analog interactions of changing voltages. Conclusion The development of the trigger is an under-appreciated step in the history of digital computers. Because the trigger holds information—state—it can be used to create a state machine. This allows a computer to perform operations step by step, rather than a jumble of actions all happening at the same time. The trigger circuit dates back to 1918, when two British physicists, William Eccles and Frank Jordan, invented a circuit that used two cross-coupled triodes to create a circuit with two stable states. They viewed this circuit as a type of relay, triggered by a small signal and retaining its state until it was reset. They patented the circuit (Improvements in ionic relays) and wrote about it: A Trigger Relay Utilising Three-Electrode Thermionic Vacuum Tubes. (The Eccles-Jordan trigger circuit below is conceptually similar to the TR-3 trigger module, using cross-coupled triodes. One difference is that the input is coupled with a transformer.) A diagram of the Eccles-Jordan trigger relay, from their 1919 paper. The Eccles-Jordan trigger eventually led to digital counters. In 1939, the journal Electronics published an article Trigger Circuits, describing how trigger circuits could be combined to construct high-speed counters. One problem was that triggers can be easily combined to count in binary, but in the 1940s, calculating and accounting machines generally used decimal numbers, not binary. In the groundbreaking ENIAC computer (1945), bulky counters were constructed by putting ten triggers in a ring to count each decimal digit. IBM engineers invented a more efficient decimal counter that used four triggers instead of ten, coming up with binary-coded decimal (BCD) and obtaining a 1946 patent: Electronic Counting Circuit. IBM used this counting circuit in the 603 Electronic Multiplier (1946), followed by the 604 Electronic Calculating Punch (1948). Modern computers use triggers—albeit under the modern name "flip-flops"—by the millions, but now they are microscopic transistor circuits instead of vacuum-tube modules. For updates, follow me on Bluesky (@righto.com), Mastodon (@[email protected]), or RSS. Thanks to Robert Garner for providing the module and to CuriousMarc for hardware support. AI statement: Despite the presence of the em dash, no AI was used in the writing of this article (details). A 1951 advertisement for the IBM 604, describing how the system was like having 150 extra engineers. Slide rules were the common calculating tool at the time. Notice that diversity amongst engineers was limited to hairstyle. From Fortune, December 1951 via Wikimedia, scanned by Michael Holley. Notes and references The punch cards were read and punched by a separate unit, the IBM 521 Card Reader/Punch, which was connected to the IBM 604 through a thick cable. The 521 had a card magazine on the upper left to hold cards to be read. After cards were processed, they were collected in the hopper in the middle of the 521. Note the plugboard control panels in both the 604 and the 521. The IBM 521 Card Reader/Punch to the right of the IBM 604 Electronic Calculating Punch. Photo from Customer Engineering Manual of Instruction. The punch cards were standard IBM 80-column cards, introduced back in 1928. The position of a hole in a column indicated the digit value for that column. For a particular task, the 80 columns would be divided into fields to hold various numbers. The 604 only supported numbers, not other alphanumeric symbols. A negative number was indicated by punching an additional hole over the units digit, using the second row from the top. (This was called an "X-punch", unrelated to the letter X.) Punch card code, from IBM 29 Card Punch Reference Manual. This code is somewhat later, with a variety of special characters. ↩ An interesting video showing the manufacturing and operation of the IBM 604 is here. For information on the IBM 604, see the Operating Manual. The Customer Engineering Manual of Instruction explains the 604 in detail, showing a TR-3 tube module on page 20. See IBM's Early Computers for information on the development of the 604. ↩ You can think of a triode as analogous to an NPN transistor, with the grid as the base, the plate as the collector, and the cathode as the emitter. ↩ The IBM 604 also used dual-triode vacuum tubes with nine pins, rather than seven, such as the type 5965. (Seven and nine pins were standard sizes for tubes.) The nine-pin tubes had separate connections for each cathode; this allowed the tubes to be used in circuits such as "cathode followers". The two filaments were in series, sharing a common "middle" pin, which is why the tube used nine pins instead of 10. ↩ For a discussion of filament voltages, see Valves, 1939. This article discusses how car radios motivated the use of 6.3 volt filaments in the United States, where 6-volt car batteries were common. ↩ The 2033 tube is very similar to the popular 6J6 tube, but optimized for computer circuits. The IBM 1684 tube is also very similar. The tube module that I examined was missing its tube, so I can't guarantee that the 2033 is the correct tube. ↩ The standardized tube modules weren't as standardized as one might expect. For instance, the 604 used 27 different types of inverter modules in total. For a detailed discussion of the tube inverter, see IBM 604 CE Manual, pages 26-41. ↩ A trigger circuit is symmetrical, so how do you define whether a trigger circuit is on or off? IBM's convention was that if the left triode was conducting, the trigger was on, while if the right triode was conducting, the trigger was off. See IBM 604 CE Manual, page 54. ↩ The 604 manual includes a schematic of the TR-3 module (and other modules). Inconveniently, I didn't find this schematic until I had reverse-engineered the module; I made minor adjustments to my schematic based on this. This schematic is a bit tricky to interpret. All the resistances are in thousands of ohms (e.g. 1 is 1 KΩ), and capacitances are in "micromicrofarads" (i.e. pF). The circled numbers indicate pins of the module, while numbers in square boxes indicate voltages according to an obscure standard: 2 is +150V, and 5 is -100 V. "2-110" and "300638" are IBM part numbers. "6J" indicates that the tube is in the 6J family, where 6 indicates the heater voltage and J indicates a triode. The 604 documentation used cryptic boxes as symbols for the modules, with the arrows indicating the inputs and outputs; note that output 7 is at a lower position than output 8, indicating a lower voltage level. Schematic from the CE Manual of Instruction, page 260. ↩ The two outputs from the trigger module are at different voltage levels. The idea is that a circuit could use either output, depending on which voltage level was more convenient. The asymmetrical outputs caused me great trouble, however, since I wanted to attach neon bulb indicators to show the state of both outputs. I had to carefully adjust the voltages so that the bulbs had enough voltage in the "on" state to turn on, but also a sufficiently low voltage in the "off" state to turn off. (When a neon bulb turns on, the neon gas ionizes, so it requires a significantly lower voltage to turn the bulb off.) The IBM 604 used neon bulbs to show the state of various circuits, both in the front panel and internally. However, unlike me, IBM used a single bulb for each trigger, either on or off, so the inconsistent voltage levels didn't cause problems. ↩ The 604 used 12 different types of trigger modules, from TR-1 through TR-42. The different trigger circuits were similar, but had different component values to tune the characteristics, as well as different resistors for the output levels. A few types used resistive inputs instead of capacitively coupled inputs. The trigger modules were used in a variety of different ways. Briefly removing the negative bias from one side would turn that side on; this was used for reset circuits. Second, a plate could be pulled low, turning off the tube on the other side. Third, the input could be connected directly to the input, rather than going through a capacitor, with a negative voltage turning the triode off and a positive voltage turning the triode on. Other triggers used a capacitor between the plate and grid on each side to filter out noise and contact bounce. Some triggers used capacitor inputs (as in the module I described), but fed the same negative input pulse to both sides. The pulse is ignored by the triode that is on, but flips the triode that is off. The result is that the trigger switches state on each pulse—analogous to a toggle flip-flop—and divides the input pulses by two. ↩
1948 was an interesting time for computing. For decades, businesses had used punch card equipment that added and sorted electromechanically. Now these electromechanical relays and counting wheels were being used to build room-filling general-purpose computers such as Harvard Mark I (1944) and IBM's SSEC (1948). But slow electromechanical mechanisms were already becoming obsolete. World War II had fostered the development of electronics and vacuum tubes for radio, radar, and navigation. Electronic technology was being used in massive electronic computers, such as Colossus (1943) and ENIAC (1946). The first stored-program computer, the Manchester Baby, was built in 1948. The IBM 604 Electronic Calculating Punch behind a Type 521 Card Reader/Punch. Photo from IBM. Note the panels in the side of the 604 and in the front of the 521 to hold plugboards. In the midst of these technological advances, IBM introduced the Electronic Calculating Punch, type 604.1 This system may seem like a step backward: it wasn't a computer, but a programmable calculator that performed a fixed set of operations.2 However, it was much smaller3 than a computer—about the size of a double refrigerator—and much cheaper: renting for $550 a month, it was affordable by businesses and universities. Since it used vacuum tubes, it was much more powerful than electromechanical equipment; it could do 60 operations in under a second, including multiplication and division. As a result, the IBM 604 became very popular, with over 5600 units produced. Moreover, IBM's experience with electronics in the 604 led to the success of its vacuum-tube computers in the 1950s. One of the innovations of the 604 was the pluggable module, which combined a tube and its associated circuitry as shown below. The insulated handle was used to remove and install modules in the calculator. The nine pins at the bottom of the module plugged into a socket in the 604, with the sockets connected with backplane wiring. The tube was also socketed, so a bad tube could be quickly replaced. At the right, the resistors and capacitors are mounted on insulating wafers in the module.4 A thyratron tube module from the IBM 604 Electronic Calculating Punch. The 604 used several different types of modules. This module has a thyratron tube, a special type of tube that acts as a high-current switch. I put this module in a circuit and powered it up. The video below shows the module controlling a light bulb. The first button sends a small signal to the module (center), turning it on and illuminating the bulb. As I'll explain below, a thyratron tube stays on until its power is cut off, which I did with the second button. Pluggable modules may seem trivial, but they were an important innovation. Previously, vacuum tube equipment was typically built from a metal chassis with tubes mounted on the top and the other components, such as resistors and capacitors, mounted underneath. IBM developed a different approach: pluggable modules, where each module held a vacuum tube along with its associated components. These patented modules were dense, since they packed components in three dimensions. Moreover, by using a small set of standardized modules, the modules could be mass-produced and the computers assembled on a production line. Maintenance and repair were simplified; modules could be swapped to find the bad module, which was replaced with a spare. These modules were so important that IBM featured them in ads for the 604. IBM used tube modules in later vacuum tube computers, using larger eight-tube modules in the high-end 700-series computers. An ad for the IBM 604, highlighting the pluggable modules. From Time magazine, March 31, 1952, page 65. Click this image (or any other) for a larger version. Vacuum tubes and the thyratron The IBM 604 used about 1250 vacuum tubes. While vacuum tubes come in many different types, a typical type is the triode. A triode is analogous to a transistor: a small input signal is amplified to control a much larger current. In a transistor, the control signal is applied to the gate, controlling the current between the source and drain. In a triode tube, the control signal is applied to the grid, controlling the current between the cathode and the plate. The components of a triode vacuum tube. From IBM 604 Customer Engineering manual. The diagram above shows the construction of a vacuum tube. The heater is a filament, very similar to an incandescent light bulb, that heats up the cathode to roughly 750 ºC. At this high temperature, the cathode emits electrons. When a large positive voltage (say, 100 volts) is put on the plate, the negatively-charged electrons are attracted. The stream of electrons from the cathode to the plate causes a current to flow through the tube. The current is controlled by the grid: if a small negative voltage is placed on the grid, it repels the negative electrons, preventing them from reaching the plate and blocking the current through the tube. A thyratron tube is similar to a vacuum tube, except it has a tiny bit of xenon gas inside, allowing it to handle higher current.7 Like a triode, the thyratron is controlled by the grid. However, when current starts to flow through the thyratron, the xenon ionizes and the xenon plasma carries current. Unlike a vacuum tube, the grid cannot stop the flow of current. Once the gas is ionized, a thyratron tube stays on until you remove its power5 and the gas deionizes in microseconds.6 You can see this behavior in the video. When I pushed the first button, a small control signal ionized the gas, turning the tube on. The large current through the ionized gas illuminated the light bulb. The light stayed on until I briefly cut the power with the second button; the gas deionized, turning off the tube. The thyratron tube, type 2D21. The photo above shows the thyratron tube, type 2D21, a miniature 7-pin tube.8 The plate is visible inside the tube, with the other components hidden by the plate. The dark stain at the top of the tube is the "getter", a reactive substance such as barium that absorbs impurities inside the tube. In the 604, thyratron tubes drove relay coils and powered the electromagnets that punched holes in cards. Other IBM systems also used these thyratron tubes. For instance, the IBM 83 Card Sorter used thyratron tubes as short-term storage to keep track of which holes had been detected in a card. Conclusion The IBM 604 occupies an interesting position between electromechanical accounting machines and electronic computers. Although it has the speed of an electronic computer, it was still a calculator, lacking computer features such as loops, memory, and stored programs. Despite these limitations, the 604 was highly successful and led to other important IBM products. IBM extended the 604 in 1949 so it could be programmed by punch cards in combination with plugboards; this was called the Card-Programmed Electronic Calculator. This system was still not quite a computer, but was very useful for scientific calculation at places such as Los Alamos National Labs (link). In 1953, IBM announced the successor to the 604, the IBM 650. Unlike the 604, the 650 was a programmable, general-purpose computer; it became the most popular computer of the 1950s. Eric Schlaepfer (TubeTime) has a box of IBM 650 modules, which we hope to power up soon. For updates, follow me on Bluesky (@righto.com), Mastodon (@[email protected]), or RSS. Thanks to CuriousMarc for extensive milling work to build the socket and colorful breakout box to hold the module. AI statement: Despite the presence of the em dash, no AI was used in the writing of this article (details). Notes and references For information on the IBM 604, see the Operating Manual. The Customer Engineering Manual of Instruction explains the circuitry. See IBM's Early Computers for information on the development of the 604. For a detailed description of an application, see this petroleum engineering article, using the 604 to predict the profitability of an oil property. ↩ The IBM 604 operated by reading numbers from a punch card, performing up to 60 operations, and punching the result onto the punch card. This was repeated for each card, processing 100 cards per minute. The IBM 604 was not a stored-program computer, so it didn't have code. Instead, the IBM 604 was programmed by plugging wires into plugboards. The plugboard below was inserted into the 604, while a second plugboard, twice as large, went in the card punch unit to control which columns of the 80-column punch card were read and punched. An IBM 604 plugboard. Photo from National Museum of American History, CI.328576. (Click for a larger image.) Looking at the plugboard above, the column on the left with the heading "PROGRAM" had a row for each programming step. A wire from that row was connected to the function to be performed on that step. The system supported conditionals: the operation that was performed on a step could be changed or skipped with the calculator selectors ("CALC. SEL.") on the right. (A selector was a relay that could send a signal along one of two paths (Normal or Transfer) based on a Control input.) For more information on the plugboards, see the Operator's Manual. ↩ The IBM 604 weighed 1310 pounds, while the attached 521 Card Reader/Punch weighed 670 pounds. The system used 5.5 KW of power. (Vacuum tubes are power-hungry; the module that I used required 3.75 watts for the heater alone.) ↩ I reverse-engineered the MD7A thyratron module to create the schematic below. Black pin numbers are module pins (1-9), while red pin numbers are tube pins (1-7). Schematic of the IBM MD7A module, reverse-engineered. For my experiment, I powered the module with about 100 volts on the plate (pin 5). I used pin 3 of the module for the input, using about 8 volts to trigger the thyratron. Pin 4 is the output, pulled high when the thyratron fires. I connected the light bulb between pin 4 and ground (pin 6). I ignored pins 7, 8, and 9. ↩ One disadvantage of a thyratron is that you need to remove its power to turn it off. In the 604, a mechanical cam in the card reader/punch activated a microswitch to turn off the power (details. Since the card reader/punch used cams on a rotating shaft for its timings, one more cam wasn't an inconvenience. ↩ The behavior of a thyratron is very similar to the silicon-controlled rectifier (SCR). This semiconductor device is also called a thyristor, short for thyratron transistor. ↩ The xenon pressure in the thyratron tube is very small, just .05 Torr, less than 1/10,000 of atmospheric pressure (source). Vacuum tubes, in comparison, have a vacuum that is orders of magnitude higher, around 10-6 Torr. Some high-power thyratron tubes use mercury vapor, such as the ones inside a 1940s power supply that we examined. These tubes give off a blue glow when active. The xenon tube, in comparison, didn't emit any light that I could see, apart from the orange glow from the filament. ↩ The pinout for the 2D21 thyratron tube is shown below, and the datasheet is here. Thyratrons use the same symbols as vacuum tubes, except the large black dot indicates the presence of gas in the tube. Symbol for the 2D21 thyratron tube. From IBM 604 Customer Engineering manual. As the symbol shows, the 2D21 tube has two grids, so it is technically a tetrode (four active elements). The second grid improves performance by screening the control grid from the cathode and the plate, reducing capacitance. (See Thyratrons for modern industry.) For my experiment, I ignored the screen grid. (The 604 also used some pentagrid tubes with a whopping five grids: two control grids, two screen grids, and a suppressor grid.) ↩
Spacelab was a reusable laboratory that could be carried in the cargo bay of the Space Shuttle, providing lab space for astronauts and experiments. Spacelab was controlled by a French-built minicomputer, called the Mitra 125 MS. Unlike modern computers, this computer didn't contain a microprocessor chip. Instead, its 16-bit processor was constructed from several boards of chips. In this article, I reverse-engineer one of the processor boards, shown below, part of the computer's Arithmetic/Logic Unit (ALU). The Mitra 125 MS computer, built by CIMSA, with one of the ALU/register cards shown. Spacelab consisted of a pressurized cylindrical laboratory that held experiments, computers, and work areas for researchers. A tunnel connected the laboratory to the Shuttle, allowing researchers to move between the Shuttle and Spacelab. Spacelab also supported up to five unpressurized "pallets" that were exposed to space, holding experiments such as telescopes and sensors. The illustration below shows the tunnel, the Spacelab laboratory, and a pallet installed in the Shuttle's cargo bay.1 Illustration of the Spacelab-3 mission. From NASA. Because Spacelab was a European project, it used a European computer, the Mitra 125 MS. The Mitra line started in 1971 when a French company called CII introduced the Mitra 15 minicomputer, a 16-bit computer that used magnetic core memory. Mitra is a French acronym2 that translates as "Mini-machine for Real-Time and Automatic Computing." As the name suggests, Mitra was both small and designed for real-time computing, making it suitable for controlling experiments. The Mitra 15 was a popular computer, with almost 8000 units sold. In 1975, CII produced a successor called the Mitra 125. The Mitra 125 improved on the Mitra 15 by adding memory management, I/O processors, higher performance, and additional instructions. Spacelab used the Mitra 125 MS minicomputer,3 a militarized variant of the Mitra 125 that was produced by a company called CIMSA. A Spacelab mission had three of these computers: the Subsystem Computer controlled and managed Spacelab itself, while the Experiment Computer handled the experiments. A Backup Computer could take over if either computer failed.1 These computers were part of Spacelab's Command and Data Management Subsystem, which controlled experiments and collected data.4 The three computers were normally mounted in the Spacelab laboratory underneath the Work Bench Rack (details). The computers were controlled through a keyboard and a color CRT display, called the Data Display System (DDS). The computer installation and a DDS are visible in the photo below. This photo shows astronauts inside Spacelab (but not in space). The Spacelab computers were mounted under the Work Bench (right arrow). The Data Display System (left arrow) provided the interface to the computers. Photo is STS-51B Crew Portrait, 1984. For some Spacelab missions, the laboratory was omitted entirely, providing more room for experiment pallets. In this case, the computers were mounted in a small pressurized cylinder called the igloo. The researchers remained in the Shuttle, controlling experiments through two Data Display Systems that were mounted in the Shuttle's rear flight deck (photo). The 74181 ALU chip The Spacelab computer didn't use a microprocessor chip. Instead, like most minicomputers at the time, it was built from simple integrated circuits that were combined to implement the computer's circuitry. Unlike modern CMOS integrated circuits, these chips contained bipolar transistors, which were fast, but large and power-hungry, a technology known as TTL (transistor-transistor logic). Electronics hobbyists of a certain age will recall the popular 7400 series of TTL chips. The Spacelab computer was built from the military grade of these chips, the 5400 series. The most complex chip in the computer was probably the '181 Arithmetic/Logic Unit (ALU) chip, containing about 170 transistors. The arithmetic/logic unit is the heart of a computer, performing arithmetic operations as well as Boolean logic operations. In 1970, Texas Instruments put a complete 4-bit arithmetic/logic unit on a single chip, called the 74181. Since the chip was fast, compact, and inexpensive, it was widely used, providing the ALU in computers from the popular PDP-11 and Xerox Alto to the powerful VAX-11/780 "superminicomputer". The 74181 provides a full set of binary logical operations, including AND, OR, XOR, and complement. For arithmetic, it includes addition, subtraction, incrementing, and decrementing.5 Inconveniently, the 74181 doesn't support shifting right. Moreover, multiplication and division were much too complicated to be included in the 74181. Instead, a processor implemented multiplication and division through repeated addition or subtraction, combined with shifting. Likewise, floating-point operations were way beyond the capability of the 74181, but a processor could use the 74181 when performing the steps of a floating-point operation. Although the 74181 only handled four bits, multiple 74181 chips could be combined to handle larger words, such as 16 bits or 32 bits. To handle carries, the chips could be chained together, with the carry-out from one chip fed into the carry-in of the next chip. This approach was simple but slow, since the carry had to "ripple" through all the chips before the answer could be obtained. The carry process could be sped up by using a carry-lookahead chip called the 74182, which speeds up addition by computing the carries from four 74181 chips (i.e., 16 bits) in parallel. The Mitra's ALU/register boards The Spacelab computer used eight '181 ALU chips to implement a 32-bit adder.6 (Specifically, these chips are the 54S181, a variant of the 74181: "54" indicates that the chips handle the military temperature range, and "S" indicates that the chip is built from high-speed Schottky logic.) However, the ALU boards required numerous additional chips. Depending on the instruction, eight different inputs could be selected for the ALU. Chips called multiplexers selected the desired value, requiring 32 multiplexer chips. Three 32-bit registers provided storage for ALU inputs and outputs, requiring 24 chips. Two 54S182 carry-lookahead chips provided fast carry computation. Finally, some simple logic chips (inverters and NAND gates) tied things together. Due to the number of chips required, the ALU/register circuitry was spread across three boards, as shown below. (I reverse-engineered the board on the right.7) The '181 chips are immediately visible as they are much larger than the other chips; they have 24 pins, compared to 14 or 16 pins for the other chips. The first board has two '181 chips, while the last two boards each have three '181 chips. The last two boards are similar, but not identical. The three ALU/register boards from the Spacelab computer. Click this image (or any other) for a larger version. Finding a 32-bit ALU was a surprise to me, since the computer is a 16-bit computer. The expanded ALU was probably implemented to improve performance. Multiplying two 16-bit numbers yields a 32-bit result, so a 32-bit ALU makes multiplication faster. Moreover, the computer supports 32-bit floating-point numbers, so the 32-bit ALU presumably makes floating-point operations faster. The diagram below shows the architecture of the computer's 32-bit ALU system. In the middle is the ALU itself, operating on two 32-bit operands: A and B. At the left, multiplexers ("mux") select one of four values for A and one of four values for B. At the right, the output of the ALU can be stored in three 32-bit registers, or sent to the rest of the computer via the bus. The first two registers are shift registers, allowing the value to be shifted left or right, while the third register simply holds the value in flip-flops. The first two registers are connected by buses to the rest of the computer, while the value of the third register can only be accessed by using it for another arithmetic operation.8 I suspect that the shift registers are used for multiplication and division to shift the arguments at each step. Block diagram of the ALU/register board. The inputs to the multiplexers provide flexibility. For instance, you can add register 1 to a number from the bus, or add register 2 shifted to the right to register 3. (Note that this shifting is implemented by wiring the inputs to the multiplexer shifted left or right, completely separate from the shift register's shifting.) The "all 1's" input presumably acts as -1 in two's-complement, providing a decrement. The B input can be taken from the bus, allowing the value to come from memory or from a general-purpose register. The mix input is a jumble of signal lines, register bits, a shift register input, and a pull-up with no apparent pattern. I describe a few more mysteries in the footnote;9 presumably, the mysteries would be resolved if I reverse-engineered the whole computer. The functions of the multiplexers, ALU chips, and registers depend on what instruction is being executed. Specifically, the computer's microcode engine generates control signals for the computer, including the ALU/register boards. Some of these control signals select which multiplexer inputs are used. Other control signals select the ALU's function. Finally, control signals select which register receives the ALU's output. The board that I reverse engineered implements 12 of the 32 bits of the ALU and registers. The diagram below shows the role of each chip on the board. The three 4-bit ALU chips are indicated 2, 1, and 0. Each ALU chip has two multiplexer chips to select the four A input bits and two multiplexer chips to select the four B input bits.10 Thus, there are 12 multiplexer chips on the board. The three 12-bit registers A, B, and C are each implemented with three 4-bit chips. Three hex inverter chips and a 4-input NAND chip complete the board.11 The ALU/register board with the chips labeled. These printed-circuit boards (PCBs) have some interesting features. In most electronics, circuit boards have holes only where they are needed, but the Spacelab boards have holes in a fixed grid pattern. (IBM used similar boards in its System/360 computers in the 1960s.12) A hole can hold an IC pin or other component. Or a hole can be used as a via, connecting PCB traces on different layers. Another interesting feature of the boards is the vertical metal bars underneath the integrated circuits. These bars carry heat away from the integrated circuits. The PCB traces are more visible on the back of the board (below). The traces are thin enough that two traces can pass between a pair of holes. Note the yellow "bodge" wires, correcting errors on the circuit board. I assume that these errors were fixed for the computers used in flight. Back of an ALU/register board. This is a different board from the one I reverse engineered, since I wanted to show the yellow wires. Each board has a 96-pin connector at the bottom, which plugs into the computer's motherboard. Note the three cylindrical pins sticking out of the connector. These pins are keyed to ensure that a board can only be plugged into the correct slot. That is, each pin has a metal tab oriented in one of six directions. On the motherboard, the connectors have corresponding notches. If the tabs and the notches don't match up, the board can't be plugged in. A close-up of the connector, showing the keying. Also note that the zig-zag pin numbering on the left changes to an irregular number on the right. Unexpectedly, pin 52 is between pins 49 and 51, for example, The boards in the Spacelab computer are dense, tightly packing integrated circuits to minimize the size of the computer. However, the boards are considerably less dense than American aerospace computers. In particular, the Spacelab computer used the same integrated circuit packages that were used in consumer electronics: through-hole DIPs (dual in-line packages with two rows of pins). In contrast, IBM's line of 4 Pi aerospace computers used "flat-pack" integrated circuits that were considerably smaller and thinner (details). As a result, IBM's double-sided circuit boards could hold 156 integrated circuits compared to 30 on a single-sided Mitra board of roughly the same size. A brief history of the French computer industry leading up to this computer Bull is one of France's earliest computing companies, created in 1931. Bull initially sold punch-card equipment, competing with IBM. By the 1960s, Bull was a major computer company with products such as the transistorized Gamma 60 computer, a large-scale mainframe that was said to be the first system specifically designed for parallel and multiprogramming. Unfortunately, Bull had difficulty competing with IBM, its stock collapsed, and Bull was acquired by General Electric in 1964, forming Bull-GE. The collapse and controversial takeover were a blow to the French computer industry, and the incident was dubbed the Affaire Bull. To make things worse, GE soon canceled two of Bull's computers, focusing instead on GE's computer line. The Affaire Bull was not only an affront to French pride, but an indication that France was largely dependent on the US for computer technology. A second incident revealed the critical military consequences of France's weakness. In the early 1960s, France was attempting to improve its nuclear strength by develop a hydrogen bomb. The mathematics of fusion is computationally intense, so France attempted to buy powerful American computers: the CDC 6600 supercomputer and the IBM 360/92.13 However, the US government blocked the export of these computers to France in an attempt to limit nuclear proliferation. These problems led French president Charles de Gaulle to decide that France needed a strong computer industry of its own. In 1966, he developed a plan for computing (Plan Calcul)14, where the French government would reorganize the computer industry, picking companies to lead in each sector from minicomputers to semiconductors. In the minicomputer sector, the government created a company called CII by combining three French computer companies: SEA, CAE, and SETI. CII was primarily owned by a large French company called Thomson-CSF (now Thales).15 CII played a key role in the Spacelab computer, since CII developed the Mitra line of computers. In the mid-1970s, CII and the American company Honeywell merged, with the computer division spun off to form a new company called SEMS, with majority shareholder Thomson. Another Thomson subsidiary, CIMSA, focused on military electronics and produced the militarized versions of the Mitra line. In particular, CIMSA produced the computer for Spacelab.16 France's Plan Calcul is generally viewed as a failure. Despite expensive subsidies, the French computer industry remained weak and unable to escape American dominance. When Giscard d'Estaing was elected president of France in 1974, he ended Plan Calcul. There are various interpretations, such as the failure of government planning versus the free market, but my view is that in the 1960s and 1970s, IBM crushed most challengers in the computer industry, both American and foreign, so Plan Calcul didn't have a chance. As for Bull, the company went through a dizzying sequence of American takeovers and nationaizations by France.17 Just two months ago (March 2026), the company was reacquired by the French government. Replacement by the IBM AP-101SL computer Since Spacelab was a European project, using a European computer was a point of pride. Unfortunately, the French computers were eventually replaced by IBM computers due to performance needs and undoubtedly political factors. During the Space Shuttle program, the computers on the Shuttle and in Spacelab became obsolete as computer technology rapidly advanced. Although the computers were originally considered powerful, their performance and memory capacity became problems over time. The Space Shuttle's IBM AP-101 computers were upgraded to IBM AP-101S computers, first flying in 1991. The AP-101S was half the size, three times faster, and had more than twice the memory, using semiconductor memory instead of magnetic core memory. The Spacelab computer system needed a similar upgrade, and in 1991, the CIMSA computers on Spacelab were replaced with IBM AP-101SL computers. The AP-101SL was based on the Shuttle's upgraded AP-101S computer, but modified to support the Mitra's hardware architecture, instruction set, and I/O capabilities. The packaging of IBM's computer was slightly changed to match the dimensions of the CIMSA computer and to use an external heat exchanger rather than an internal heat exchanger. The IBM AP-101SL Spacelab computer. The circuit boards are much larger than the original Spacelab computer boards or the original AP-101B boards. Note the flat-pack ICs on the boards. Photo courtesy of Kyle Owen. Changing the Shuttle's 32-bit AP-101S computer to run the 16-bit Mitra instruction set was easier than you might expect, since the AP-101S already supported multiple instruction sets: a 32-bit instruction set derived from the IBM System/360 and a 16-bit instruction set called 1750A that was an Air Force Standard. Because the AP-101S implemented its instructions in microcode—low-level software that specified the steps of a machine instruction—the instruction set could be modified by updating the microcode. I compared the circuit boards in an AP-101S with the boards in an AP-101SL to quantify the changes. The semiconductor memory boards and power supplies were essentially identical. The CPU boards had minor changes. Unsurprisingly, the I/O boards were completely different, and the complex I/O Processor (IOP) in the Shuttle's AP-101S was omitted. For more on the IBM AP-101 line, see my History of IBM's 4 Pi computers. Conclusions The Spacelab computer provides an interesting look at how computers were built before microprocessors took over. The components of a computer, such as the ALU, registers, and control circuitry, were constructed from simple chips. Since each chip didn't do much, the computer required 36 boards full of chips. Even so, the computer was compact enough to go into space. By modern standards, these computers aren't much—each computer had a memory capacity of just 128 KB of magnetic core memory—but they played a critical part in the space program. I'm not going to reverse-engineer the full computer, but I may write some more about it. For updates, follow me on Bluesky (@righto.com), Mastodon (@[email protected]), or RSS. Credits: Thanks to Steve Jurvetson for providing the Spacelab computer for examination. AI statement: Despite the presence of the em dash, no AI was used in the writing of this article (details). Notes and references For details on Spacelab, see Spacelab News Reference. ↩↩ To avoid cluttering the main article, I'll summarize the French acronyms and companies in this footnote. CAE: Compagnie européenne d'automatisme électronique (European Electronic Automation Company). A French computer company founded in 1960, selling versions of American computers such as TRW's RW-300. Part of the 1966 merger that formed CII. CII: Compagnie internationale d'informatique (International Computer Company): the company that created the Mitra line of minicomputers. CII also sold computers designed by the American company SDS (Scientific Systems), which was bought by Xerox in 1969 and became XDS (Xerox Data Systems). XDS was shut down in 1975, costing Xerox hundreds of millions of dollars. CIMSA: Compagnie d'informatique militaire, spatiale et aéronautique (Military, Space, and Aeronautical Computing Company): the company that manufactured the Spacelab computer. CSF: Compagnie Générale de Télégraphie Sans Fil (General Wireless Telegraphy Company). A radio company dating back to 1918. It merged with Thomson in 1968 to form Thomson-CSF. MATRA: Mécanique Aviation Traction (Mechanics-Aviation-Traction). An electronics company that was the contractor for Spacelab's data systems. Mitra: Mini-machine pour l'Informatique Temps Réel et Automatique ("Mini-machine for Real-Time and Automatic Computing"). A line of minicomputers. SEA: Société d'électronique et d'automatisme (Electronics and Automation Company): a French computer manufacturer, started in 1947 and merged into CII in 1966. SEMS: Société Européenne de Mini-informatique et de Systèmes (European Society for Minicomputers and Systems). A subsidiary of Thomson, created by the French government in 1976 during the merger of CII and Honeywell. SEMS took over the manufacturing of Mitra computers from CII. SETI: Société européenne de traitement de l'information (European Information Processing Society). SETI was a French computer company formed in 1961. The American computer company Packard Bell owned a quarter of SETI, and SETI sold the desk-sized Packard Bell 250 computer. ↩ On the ground, the Spacelab project used Mitra 125 S computers that were functionally identical to the Mitra 125 MS (details). ↩ Spacelab's Command and Data Management Subsystem (CDMS) is surprisingly complicated because of the data communication paths between Spacelab, the Shuttle, and the ground. Moreover, multiple units store, encode, and decode data. In the CDMS block diagram below, I've highlighted the three computers; they are just a small part of the CDMS. See Section 3.5 of Spacelab News Reference or The Command and Data Management System of Spacelab for details on CDMS. A block diagram of Spacelab's Command and Data Management Subsystem. From The Command and Data Management System of Spacelab. Click for a larger version. ↩ I reverse-engineered the 74181 ALU chip in this article and explained the motivation for its quirky set of operations in this article. ↩ Another board in the Spacelab computer has four 74S181 chips implementing a 16-bit ALU. My guess is that this board is part of the I/O processor. The board has the cryptic label "HMSG". ↩ My reverse-engineering process was straightforward but tedious. I used a multimeter to beep out the connections between the integrated circuits as well as the connections to the connector. (Unlike many systems that I look at, these boards didn't have conformal coating, which made beeping out the connections practical.) I created a schematic in KiCad from this data; this schematic was "physical", with the layout of the chips and pins matching their physical location on the board. Next, I converted the integrated circuit symbols from physical rectangles to logical symbols. Finally, I moved the symbols around on the schematic to make a reasonable schematic. (I had to go back and beep out more connections as I discovered errors or missing connections.) Theoretically, I could reverse-engineer the entire computer, but reverse-engineering one of the 36 boards is enough for me. ↩ My full reverse-engineered schematic of the ALU/register board is below. Click for a larger version. Schematic of the ALU/register board. ↩ A few mysteries remain in the ALU/register board. The three registers probably act as an accumulator, a temporary register, and an extra register for multiplication/division, but it's not clear which register is which. I don't understand why the inputs are organized as they are; for instance, you can't add register 1 to register 2 shifted. The mix input seems very random; maybe these signals are part of a self test? On the board, I expected to see 12 bits out of a uniform 32-bit ALU. However, the top two 4-bit "nibbles" have different control lines and different zero-detection from the third. Perhaps this is because the Mitra floating-point numbers have 24 bits of mantissa and 8 bits of exponent. It would make sense for the ALU/register board to handle these parts separately. Another mystery is that the board has a circuit to test two hardwired bits and two external bits to see if they are all 0 or all 1, for some reason. ↩ The multiplexer chips are dual 4-to-1 multiplexers. Thus, two multiplexer chips are required to support four bits. ↩ The chips in the Spacelab computer use a variety of part number systems. A few chips have standard industry part numbers such as "SNJ5483" (equivalent to a 7483 adder). Most of the chips are labeled with military part numbers such as JM38510/07801 BJB, using the MIL-M-38510 standard. These part numbers can be cross-referenced using the MIL-HDBK-983 handbook. Other chips, like the ones below, have Fairchild part numbers that are a mystery to me. The first line is presumably the part number, "929 567" and "929 705", but I can't find these numbers anywhere. If you know what these numbers mean, please let me know! (07263 is the CAGE code for Fairchild, and the last line is the date code.) Two Fairchild ICs with mysterious part numbers. The ALU/register board that I examined uses the following JM38510 part numbers, which I have converted to standard parts: /01403 = 54153 dual 4-1 multiplexer /07003 = 54S04 hex inverter /07006 = 54S20 4-input NAND /07601 = 54S194 4-bit shift register /07801 = 54S1814-bit ALU /30107 = 54LS175 quad flip-flop ↩ The photo below compares an IBM board (top) with a Spacelab board (bottom), both from the early 1980s. It's interesting how similar the boards are. Both use a 0.1" grid of holes, unlike most printed-circuit boards, which only use holes where needed. Both boards are multi-layer with integrated circuits on one side. The IBM board is denser; the chips are spaced 0.1" apart rather than 0.3" apart. An IBM computer board (top) and a board from the Spacelab computer (bottom). I don't know which IBM system used this board, but it was a commercial system, not an aerospace system. This board is a bit unusual for IBM, since most of the chips are standard DIPs rather than the square metal cans that IBM typically used. ↩ The US blocked computer exports to France with NSAM 294, a 1964 National Security Action Memorandum. The US later allowed sales of the CDC 6600 and IBM 360/91 computers to France on the condition that France not use the computers for atomic weapon development, a condition that France apparently violated. See A.E.C. Bids Industry Avoid Sales Aiding French Tests (1964) and Paris Promises Not to Use Equipment for Atomic Weapons (1966). The CDC 6600 supercomputer executed up to 10 million instructions per second (MIPS) while the IBM 360/91 executed about 17 MIPS. (In comparison, a 1995 Pentium Pro or a 2012 cell phone is faster than these computers.) In 1971, Henry Kissinger was still blocking computer exports to France, as shown in this transcript. (One confusing issue in these articles is that IBM announced the 360/92 computer in 1964, but renamed it as the 360/91 before it shipped in 1967.) ↩ Some contemporary articles on Plan Calcul are France Entering Computer Battle: Starts All-French Company to Compete (New York Times, 1967) and France: First the Bomb, Then the "Plan Calcul" (Science, 1967). See History of Computing in France: A Brief Sketch for an overview of the French computer industry. ↩ Thomson has a complicated history. In 1883, two Americans, Thomson and Houston, started the Thomson-Houston Electric Company. A decade later, this company became General Electric, with a French subsidiary: Thomson Houston International. After various mergers, the French subsidiary became Thomson-CSF, a major defense and electronics firm. In a sense, Thomson-Houston both created and destroyed GE. The Thomson-Houston Electrical Company became GE, but the French subsidiary of Thomson-Houston ended up being a key part of GE's collapse almost a century later. Specifically, the French rail transport company Alsthom (later Alstom) was formed from the French heavy engineering subsidiary of Thomson-Hudson in 1928; the "thom" in "Alsthom" comes from "Thomson". In 2014, General Electric acquired Alstom for $10.1 billion. The acquisition was a disaster, and in 2018, GE wrote off $23 billion. This loss, along with other financial problems, led to GE's announcement in 2021 that it would break up into three companies. ↩ One more company should be mentioned: MATRA. MATRA was the contractor for Spacelab's data systems, so the Spacelab computer was produced under a contract from MATRA. People often confuse Mitra (the name of the computer line) with MATRA. ↩ Due to financial difficulties, Bull was acquired by General Electric in 1964, then was acquired by Honeywell, nationalized by France, partnered with NEC, acquired Zenith, privatized by France, and acquired by Atos. Less than two months ago, France acquired Bull, continuing the series of reorganizations. ↩
More in technology
Australians! They walk among us! Do not be deceived by those charming faces! precious bodily fluids, we must remove the scurrilous larrikin influence of Australia upon our American home computers, and I know exactly where to start! Why allow Dick Smith's name (even though he'd already sold Dick Smith Electronics' controlling interest to Woolies by then but stop ruining my intro) to corrupt this, um, rubber-keyed diminutive beige home computer when we can return it to its prior, pristine, plasticky state as it once rolled out from a glorious Asian factory? Then, to avoid wrecking it with a botched logic board repair, we'll bolt on a USB serial port using the very latest peripherals from down under, write cycle-counted Z80 assembly language to blast data to it at 57.6kbps, and hack a few games. Because only this will make the VZ200 great again! TI vs. Everybody"), was a seismic event in computing. Hong Kong entrepreneurs Allan Wong and Stephen Leung were two of many to realize that the microchip would trigger a revolution in consumer electronics, and over several years accumulated sufficient funding to establish Video Technology Ltd in 1976. Their first factory operated from the Freder Centre in Ma Tau Kok, a semi-industrial area on the west side of Kowloon Bay. Initially VTech, as it became known, concentrated on video games, primarily as an OEM for the more profitable North American and European markets. Their first products were Pong clones, released in the United Kingdom as the Grandstand Adman T.V. Game 2000 (black and white) and Adman T.V. Game 3000 (colour) in 1977, both based on the Texas Instruments TMS1965N, TI's clone of the well-known General Instrument AY-3-8500 Pong-on-a-chip (compare with the rather more complex MOS 7601). Grandstand was a brand name of Adam Imports, then a substantial toy and games importer to the UK and for a period of time New Zealand, and had other Asian contacts, notably Tomy. If the picture on VTech's history page is to be believed, and I point out there are some verifiable inaccuracies on that page, VTech continued to produce other consoles for Grandstand/Adam like the (deep breath) Grandstand Adman Colour TV Game 3600 Mk III, which used a regular AY-3-8500 and was produced until 1979. For the portable market, VTech produced a number of handheld LED, VFD, LCD games, sold under various brands and through retailers such as Radio Shack. VTech was hardly the only such Hong Kong tech company, of course; across the Bay in Kwun Tong was EACA, established in 1975 by Guangzhou escapee Eric Chung. EACA also produced consumer products such as radios and its own video games, notably the 1978 Colour TV Game, also based on the TMS1965N and variously sold under other brands such as the Sonesta Hide-Away TV Game. Creative Computing in August), but in fact ripped off from and largely compatible with the TRS-80, and advertised as such (well, the compatible part, anyway). While there were some internal differences and significant changes to the keyboard layout, EACA mostly copied the TRS-80 system ROMs for production with only minor changes, shipping it with a licensed version of Microsoft Level II BASIC. At Summer CES in Chicago it directly competed with the APF Imagination Machine and the Texas Instruments 99/4 (the original), and indirectly with the Atari 8-bits which earlier debuted at the Winter show. While it lacked the $599 model's monitor (a TV set or Tandy monitor was required), it had a better keyboard mechanism and a built-in cassette recorder, and was variously announced between $500 and $600 with 16K of RAM [$2200-$2760]. Electronics Australia, John Kennewell's National Semiconductor SC/MP-based MINI-SCAMP, running the CPU at roughly 500kHz (based on a typical 2μs cycle time) and 256 bytes of RAM expandable to 1K (64K addressable). DSE advertised the machine as "33% of the cost of the EDUC-8," an earlier Electronics Australia bit-serial TTL hobbyist system inspired by the DEC PDP-8 and designed by Jamieson Rowe — remember that name — who became an enthusiastic proponent of the new machine. Over in Silicon Valley, Palo Alto arcade game builder Exidy had developed their own Z80-based computer in 1978, the Exidy Sorcerer, a premium system featuring programmable character graphics, a faster 2.1MHz CPU and a built-in internal S-100 bus. Exidy saw the export market as a growth opportunity and aggressively inked deals with multiple foreign distributors, including DSE, who were taking ready advantage of the Whitlam government's 1973 import tariff reduction to bring more finished goods to DSE stores. The Sorcerer arguably found greater success in Europe than it ever did in the United States, particularly in the Netherlands where the licensed Compudata Sorcerer became the default government-supported educational system, and certainly in Australia due to Dick Smith's dogged promotion. Still, even in the US it was considered relatively expensive at $895 [$4580], and with tariff and import costs tacked on it didn't price itself well to the Aussie working class nerd. Conversely, the EACA Video Genie had meanwhile achieved some popularity of its own within Europe, notably West Germany, in no small part due to its lower cost. That alone made it a logical system to transition to, and better still, EACA had absolutely no objection to DSE outright rebadging it as a Dick Smith unit. Micro-80 disliked the altered keyboard (no CLEAR and TAB, no left and right arrows, up and down replaced by ESCAPE and CONTROL), complained about its changes to the character set and video circuitry, found the built-in cassette deck hideous, and noted the lack of board sockets and the missing-at-launch S-100 expansion box, but approved of the "brilliant" and "attractive" appearance, its overall functionality, and most of all its purchase price. "Even if you buy a decent tape deck from your local Big W and put it in the System 80," Hartley concluded, "you end up at least $150.00 [US$130 spot, US$520 in 2026 dollars] ahead — and that pays for your next 16K of RAM chips ... the machine has an identical computing capacity to the TRS-80, for a lot less dollars." At this point it was inevitable someone would poke the Tandy bear, and that someone was Recortec (they're still around), established in Sunnyvale, California in 1969 to specialize in magnetic tape recording technology. In 1980 Recortec, also attempting to expand their product base, opened Personal Micro Computers, Inc. (PMC) as a new venture in Mountain View, initially entering negotiations with Exidy to buy out the Sorcerer — until, through EACA's American subsidiary, they became aware of the Video Genie. To PMC/Recortec, the Genie was a remarkable opportunity, a less expensive TRS-80 compatible system already selling in Europe and entering the Australian market, and PMC now had the chance to corner it for American distribution. The company immediately backed out of the deal with Exidy, bought up Genie distribution rights in August for the entire Western Hemisphere, rebranded it as the PMC-80 and launched it in 1981 with 16K of RAM for $675 [$2330]. InfoWorld was more complimentary than Micro-80 had been, noting PMC's planned Fastload high-speed cassette scheme, a 50-40 adapter to connect Model I peripherals directly and a true lowercase conversion kit. "Tandy," said columnist Tracy Deliman, "is apparently curious now" — and in particular their attorneys, who promptly filed suit in federal court against both PMC and EACA of America, claiming, among other allegations, that the name PMC-80 infringed their trademark and that EACA and by extension PMC had committed copyright infringement as well by substantially copying the system ROMs. (Tandy didn't dispute the BASIC ROM, as that was licensed from Microsoft, but EACA and PMC dragged Microsoft into court with them anyway as a third-party defendant. Microsoft was a lot smaller then.) In their motion to dismiss, PMC and EACA did not deny that the code had been copied and that then-current copyright law covered computer programs, but argued that section 117 of the in-force 1976 Copyright Act required the infringement claim to be interpreted according to the law prior to January 1, 1978 ("this title does not afford to the owner of copyright in a work any greater or lesser rights with respect to the use of the work in conjunction with automatic systems capable of storing, processing, retrieving, or transferring information, ... than those afforded to works under the law, whether Title 17 or the common law or statutes of a State, in effect on December 31, 1977"). Robert Peckham, chief judge for the Northern District of California, disagreed in August 1981 and denied the motion, writing "that section 117, as it existed in the 1976 act, was aimed at the problem of copyrighted material inputted [sic] into a computer, such as books, magazines, and even computer programs. It was not intended to provide a loophole by which someone could duplicate a computer program fixed on a silicon chip." Moreover, even if it did, "[t]he plaintiff has suggested that the evidence may well show that the chip was duplicated by first taking a visual display or printout of the program in question ... If this method of unauthorized duplication in fact is proved, there can be no doubt that the unauthorized duplication of a visually displayed copy of the program would fall within the reach of the federal copyright laws." The case was quietly settled out of court, and although it obviously didn't enjoin EACA outside of the United States, domestically PMC replaced the line with the CP/M-based MicroMate in 1983. By then, and unknown to his backers, Eric Chung's failed investments in the Hong Kong real estate market had put him millions of dollars in debt. In October 1983 he abruptly fled to Taiwan reportedly with $10 million stuffed in a suitcase, leaving EACA to quickly fold. Simultaneously, Dick Smith sold a 60% stake in Dick Smith Electronics to Woolworths (the Australian version) later in 1980 and then the rest in 1982, leaving only his name and his bespectacled grin to remain at the company he founded. Although DSE sold the Video Genie's modestly upgraded direct successors also as System 80 variations, the System 80 family never included the Colour Genie, EACA's last system before its ignominious demise. PMC's former headquarters in Mountain View are now collectively Google Building E475. first step to computer literacy. The success of the ZX80 suggested other dirt-cheap home computers might also flourish. VTech accordingly began developing a low cost computer of their own in 1981 that could work like the TRS-80, planning to adopt its BASIC (and thus its Z80 CPU) much as crosstown rival EACA did and speed time to market, but by explicitly abandoning compatibility they were free to slash its production cost as much as practical. A substantial reduction in part count became possible immediately by using the inexpensive Motorola 6847 Video Display Generator, introduced in 1978, which replaced nearly the entire video system: with minimal support circuitry, the VDG chip could generate a 32x16 text display, comparable to the TRS-80 and Video Genie's 32-column mode for colour TV sets, 64x32 colour semigraphics reminscent of the same, and a variable high-resolution bitmap display depending on available memory. On top of that, the entire system could run from the VDG's standard 315/88 (3.58MHz) crystal, including the Z80, and part count could be reduced even more for a black-and-white low binned model by omitting the colour encoder completely. Everything else (cassette output, keyboard lines) could be supported with discrete components and a handful of TTL logic, price could be adjusted further on the basis of included RAM, edge connectors wired to the processor bus would suffice for peripherals and expansion, and any sort of keyboard would be a step up from a flat membrane. While the low-end computer was in development, VTech also hedged its bets with a higher-spec video game system, which typical for the era (see, for example, the Intellivision Keyboard Component) was convertible into a home computer of its own. This console was likewise built from off-the-shelf components, using a 2MHz Rockwell 6502 CPU and the Texas Instruments TMS9918A for graphics, 17K of RAM (1K for the 6502's zero page, stack and low memory, and the other 16K for the VDP), and controllers that doubled as a membrane keyboard when used with the optional BASIC cartridge. It shared no parts or significant engineering with the computer prototype and proceeded along a largely separate development track, released to select European test markets first as the VTech CreatiVision in 1982. Meanwhile, Sinclair Research and manufacturing partner Timex Corporation subsequently joined forces to launch the Timex Sinclair 1000 in the United States, a slightly reconfigured ZX81 with NTSC-compatible video output and 2K of RAM, but otherwise identical. It hit stores in the summer of 1982 at the same psychologically desirable price point, now US$100 [$345], though Timex Sinclair didn't get the bargain American home computer market to itself like the ZX80 mostly did in the UK: it now had to contend with Commodore, selling the VIC-20 as their well-supported low-end system, plus the ailing Atari and their Atari 400, Tandy's own TRS-80 Color Computer, and even Texas Instruments, then only months away from igniting a price war using the TI-99/4A. Nevertheless, industry observers generally believed the T/S 1000 would be a strong competitor, and its debut led to an accelerated scramble from VTech and others hoping to duplicate the ZX80/1's success. VTech identified two overall product positions, a super-low-cost black-and-white variation with Microsoft Level I BASIC for selected markets, and a colour model with full Microsoft Level II BASIC, each of which VTech intended to sell both under its own name and as an OEM. To prepare for the American launch of the nearly complete low-end computer and the CreatiVision, VTech opened a U.S. subsidiary that year in Elk Grove Village, Illinois outside Chicago (the picture above is from VTech's history page). Computer Gaming World issue 3.2), it took the Las Vegas Convention Center, the Hilton Convention Center, the Riviera Convention Center, the rest of the Riviera and the old Rotunda to contain it all. Mattel introduced the Aquarius for $199 [$670] licensed from Radofin, also in Kwun Tong (with a 3.58MHz Z80A and 4K of RAM, cassette storage, no bitmap graphics option and a rubber chiclet keyboard), Texas Instruments hawked the TI-99/2 for $99 [$330] (with a 2.7MHz TMS9995, 4K of RAM, cassette storage, no bitmap graphics option and no colour, and a plastic chiclet keyboard), Sanyo proffered the PHC-20 also for $99 as the midrange of the pocket computer PHC-10 and higher-end PHC-25 (with a 3.58MHz Z80 clone and 4K of RAM, cassette storage, no bitmap graphics option and no colour, and a rubber chiclet keyboard), and at the higher end came the Panasonic JR-200U for $349 [$1170] (with a 0.89MHz 6800 clone and 36K of RAM, cassette storage, no bitmap graphics option, and a rubber chiclet keyboard), the NEC PC-6001 also for $349 (with a 4MHz Z80 clone and 16K of RAM, cassette storage, but bitmap graphics and a rubber chiclet keyboard that was quickly replaced with a typewriter-style one), and the Spectravideo SV-318 for $299 [$1000] (with a 3.58MHz Z80 and 16K of RAM, also bitmap graphics, and a rubber chiclet keyboard). There were multiple conversion kits to turn the Atari 2600 VCS into a low-end computer of its own, several with rubber chiclet keyboards, and even a completely unlicensed ripoff of the T/S 1000, the Unisonic Futura 8300 (with a rubber chiclet keyboard) for $99. Not to be outdone, Timex Sinclair themselves announced the T/S 2000, a modified US version of the ZX Spectrum, with 16K or 48K of RAM, a 3.5MHz Z80, colour bitmap graphics and a rubber chiclet keyboard; the 16K version started at just $150 [$500]. The latecomers arrived at the Summer CES in Chicago, though by that point the rot was already setting in. Against the background of Commodore slashing prices even lower on the VIC-20 and C64 to Texas Instruments' profound discomfort, Mattel suddenly decided the Aquarius needed a sequel (i.e., the other system Radofin was developing; price point to be determined but without a rubber chiclet keyboard); Timex Sinclair replaced the T/S 2000 with the enhanced T/S 2024 and T/S 2048 with higher resolution graphics, more RAM and a plastic chiclet keyboard, plus an upgraded T/S 1500 which was a T/S 1000 with 16K of RAM and a rubber chiclet keyboard; Rabbit Computer (who? also from Hong Kong) introduced its own Z80-based Rabbit RX83 with 2K of RAM, BASIC, three-channel sound, cassette storage, bitmap graphics and a plastic chiclet keyboard for $99; and Tomy unveiled the Tomy Tutor for "under $150" [$500] with a 2.7MHz TMS9995 (from a 10.7MHz crystal), 16K of RAM, cassette storage, bitmap graphics and a rubber chiclet keyboard. In the fall Tandy, never one to be left out of a race to the bottom, delivered the MC-10 Micro Color Computer for $120 [$400] with an 0.89MHz 6803 and 4K of RAM, cassette storage and bitmap graphics, and a rubber chiclet keyboard. Even Commodore, failing to learn its lesson from the critically maligned Max Machine, was working on their own ultra-low-end family of computers to follow on to the C64 — one of which (the 116) would have a rubber chiclet keyboard. And, oh yeah, one other system made its debut at the Winter show. COMPUTE! in their March 1983 reporting called it "the first under-$100 [$330] color computer." Anticipated to hit American store shelves in April, the new VTech VZ200 featured 4K of RAM (expandable to 16K for $45 [$150] and 64K eventually), 12K of ROM (remember these numbers) with BASIC, and a simple push-pull piezo for sound. Two kilobytes of the 4K was allocated to the 6847, which used it to generate its default 32x16 text display, 64x32 semigraphics or 128x64 bitmap graphics. It had built-in jacks for cassette, TV and composite video, and shared its booth with the CreatiVision which VTech planned to sell States-side for $189 [$630], with the BASIC cartridge for $10 [$33] and an inevitable rubber chiclet keyboard for $30 [$100]. It isn't clear where the name VZ200 came from, possibly a riff on "ZX," but the computer's low cost even amongst a sea of low-cost computers still attracted positive attention. Creative Computing got a 4K VZ200 in for review in their May issue (accounting for publishing delays this would have to have arrived in February or early March), though they noted that they had no chance to try the peripherals or software. The article has some glaring technical errors — among others, they said the CPU was a 6502 — but reviewer David Ahl called the machine "a compact microcomputer with a great deal of capability and many unexpected features at a very attractive price." Although the review found the 4K of RAM "sparse" and was openly critical of the keyboard, particularly the absent space bar, single SHIFT key, nonstandard layout and the keys' inconvenient tendency to stutter, Ahl was nevertheless impressed by the full-screen editor ("a pleasure") and the 12K ROM implementation of BASIC (unbeknownst to him, secretly derived from the TRS-80 with added support for the on-board hardware), concluding the VZ200 to be "a great value for the suggested retail price of under $100." There are certain attributes of the machine shown in both the COMPUTE! and Creative Computing photos that don't match released units, but we'll address this later on. Creative Computing Winter CES cover showing the VZ200, the Timex Sinclair 2000 (in its original form), the Texas Instruments 99/2, the Mattel Aquarius and the Spectravideo SV-318. Personally, however, I lump these computers together as the "crap home computers." I use this term with only love, and this uniquely terrible subtype of the home computer was indeed greatly loved, because as the ZX80 had demonstrated, ordinary people could now finally afford them. Heck, my first computer — the Tomy Tutor, introduced at Summer CES — was one of these 1983 crap home computers because it's what we could afford. We couldn't afford a Commodore 64 right then, but we could afford that. Not for nothing did Jack Tramiel thunder, "computers for the masses, not the classes!" What these systems all had in common, other than crummy keyboards, a striking preference for the Z80 and an unabashedly low starting price, was aspirational and arguably fraudulent marketing, plus inadequate specifications requiring upgrades at additional cost to be practical — if there were any to begin with — alongside substandard quality control, a poor selection of software, and weak to non-existent customer support. Made cheap to sell cheap, most of these computers failed outright (e.g., the Mattel Aquarius) or were never even released (e.g., the TI 99/2). The glut that hit the U.S. market that year not only soured many American consumers on home computers generally, but their game-heavy libraries were also likely a contributing factor to the 1983 video game crash. Although managing to move over half a million units, Timex Sinclair was not immune to this effect, and the company became unprofitable as the sales crossfire between Commodore and Texas Instruments forced the T/S 1000's street price below $50 in mid-1983. The situation was compounded by Timex's ill-considered decision to make the more expensive T/S 2068 (the eventual sole member of the 2000 family) largely incompatible with the ZX Spectrum, robbing it of the extensive British Spectrum software library, and the joint enterprise that was once expected to dominate the American home computer market collapsed in early 1984. Even large players like Texas Instruments and Warner Communications-era Atari took hundreds of millions of dollars in losses, with only Tandy (due to their strong retail presence) and Commodore (due to the C64's prodigious installed base and their vertically integrated manufacturing) able to weather the maelstrom effectively. Family Computing's inaugural September 1983 issue the columnists mention the SV-318 and even the stillborne T/S 1500, but nothing on the Lasers, and Creative Computing around that time was only running ads for the 3000. A few VZ200s were rebadged by Texas door-to-door nuisance business Dynasty Computer Corporation as the Smart Alec Jr., though like their multi-level marketing attempt at rebadging the spent Exidy Sorcerer, they sold barely at all (the company folded in November). On the other hand, the (now) Laser 200 got off the ground in Europe under its own name and others, most notably through Sanyo, but also through Salora, Seltron and Texet. It launched there alongside the black-and-white model as an ultra-low-end system, originally dubbed the Laser 100, but after the ROM change becoming the Laser 110 with the same Level II BASIC of the colour version. However, there was one market where the VZ200 had particularly strong success, and that was of course Australia, though not exactly in its original form. History does not preserve the thought process of Dick Smith Electronics management, but DSE's probable aim was to nose past the Commodore VIC-20 on price and capability (DSE themselves even sold them for a time), which was colour and shipped with 5K RAM. That immediately excluded the black-and-white variation, since the ZX81 had since landed in Australia and the potential profit margin wasn't enough to bother, and it is instead more likely that during negotiations DSE prevailed upon VTech to strengthen the colour system and keep the price low. VTech's solution was a small 6K daughterboard retrofit that could replace the 2K system RAM chip, internally expanding the unit to a more appealing 8K (the other 2K video RAM chip was left unmolested) while still being able to use previously manufactured components. This modified VZ200, badged as a Dick Smith computer and subsequently sold elsewhere by VTech as the Laser 210, appeared in the 1983-84 catalogue as "new for 1983" at just A$199 [approximately US$220 spot and US$720 in 2026 dollars]. Australian Personal Computer April 1983 preview speciously characterised it as "to Dick Smith's specifications" (likely only the RAM complement was), he got quickly used to the keyboard, approved of the BASIC implementation (faster than the ZX Spectrum's) and full screen editor, noted the characters to be "rather like those produced by the TRS-80 Color Computer" (true!), and compared the memory loadout favourably to the VIC-20's. He was similarly pleased with the cassette tape performance and the included documentation, with about his only complaint being the weak sound. His editor Sean Howard was equally impressed, famously remarking that "I'm certainly going to buy one," which DSE promptly and repeatedly used in their advertising. many VTech rebadges DSE would eventually sell. Although nothing was going to catch the Commodore 64 by then, which had the same stratospheric sales there as it did most other places, the DSE VZ-200 had the added good fortune of ZX Spectrum manufacturing issues that eroded its availability, giving the DSE VZ-200 almost unrestrained run of the Aussie low-end market from which the VIC-20 was already fading and the ZX81 all but gone. In 1984 it remained a strong seller at its new lower price of A$169, dropping to A$99 by the end of the year. I think that suffices for a more detailed backstory; we'll talk a little more about its later history in Australia and VTech's overall as a postscript at the end. For now, we'll turn our attention to this orphaned American unit. A convention I'll establish from now on in this and future articles: although Dick Smith was not consistent on the hyphenation, variously rendering it VZ-200 and VZ200, in the few places it appears the American version was invariably written without one, so I'll write "VZ200" for the North American computer and "VZ-200" for the Australian computer. biblioteca. You can also see more clearly that the red blurb on top advertising "WITH 4K BYTES RAM" and "NTSC 4K" is in fact a sticker, so this box was almost certainly not exclusive to North America and may not have been exclusive even to 4K systems. increased to $149.95. Neither price matches its well-documented MSRP of $100. Unfortunately I can't make out the actual retailer, even with an extreme enlargement. markedly predominant French labeling might have prevented its sale in the Montréal outlet, that wouldn't have enjoined it elsewhere. As far as its provenance, however, the fact it wasn't labeled that way suggests Canadian sale was not initially contemplated, and it also has U.S. Federal Communications Commission clearance (I'll show you in a bit). COMPUTE! and Creative Computing pictures. Those earliest systems are labeled as a "VZ200 Personal Computer," not a "VZ200 Color Computer," and the colour labels over the number keys were absent. In fact, this same keyboard is used for the B&W Laser 110, though those early VZ200 systems must have been colour given that their colour capabilities were widely reported at the time. On the other hand, the VZ-200 that appeared in very early Dick Smith marketing like the flyer above was labeled a "VZ200 Color Computer" exactly like this one, including the American spelling. The keyboard consists of 45 keys, with a bottom right SPACE key in the corner, only one SHIFT on the bottom left, and no ESCape key. Necessarily, many have multiple functions accessible with the CTRL key or CTRL-ENTER key combo. Most of these alternative functions are one-touch BASIC keywords like the Sinclair machines, though unlike those computers, you are not obligated to use them and can spell keywords out if you want. Semigraphics characters are also selected by key combination, as well as moving the cursor, inserting and deleting characters, and interrupting a BASIC program. was removed, because the 16K RAM expander connects there. The cover is not in the box and I'll presume it was lost or destroyed by the previous owner. That's annoying from a preservation perspective, but no great loss functionally, because we'll have something plugged in there pretty much all the time later on. on the Wayback Machine, and is the only other NTSC VZ200 unit I have seen myself. Both his and mine have a "VZ200 Color Computer" bottom plate with a copyright date of 1982, and both have US FCC clearance tags and an RF switch to pick the channel (2 or 3). There are passive cooling vents on both sides, though given the fairly small amount of clearance its rubber feetsies afford from one's desk I hesitate to say they'd be effective. (At least they let you hear the piezo speaker.) There is also a small red sticker on the bottom which on mine is partially missing, but Bill's has a complete one, which reads "U NTSC 4K." I put a small piece of transparent tape over the sticker on mine to prevent further damage. Bill's unit also has both port covers. Although the serial number indicates his is a rather older unit, which we'll in fact confirm later, the label and keyboard are the same as mine and not those earliest CES models. Both units have FCC Part 15 clearance, specifically as a Class B computing device for home use; at the time Class B regulations were very strict and we'll see a consequence of that inside. The FCC ID is BNX84H80-0323, with an equipment authorization (EA) applied for February 10, 1983 and granted May 9, 1983. Accounting for publishing delays, this means Creative Computing must have had a pre-authorization prototype for their review. VTech later applied for a revised equipment authorization on July 11, 1983 and was granted BNX84H80-0323-1 on October 11, 1983; this change may have been for redesignation as the Laser 200. The listed address for VTech in Hong Kong appears on all entries for FCC grantee BNX and doesn't seem to have been their corporate address at the time, but the tester in both EAs is one Thomas Cokenias from Electro Service Corp., at 1116 Ninth Avenue in San Mateo, California, and Cokenias and Electro Service are seen in other EAs around that time for other Hong Kong manufacturers. However, the given address appears presently unoccupied, and the California Secretary of State indicates Electro Service is no longer in business. except its 16K RAM expansion (due to differing address mapping) would work on the older machine because many of them were effectively unchanged except for the labeling. (The address mapping difference is also why the VZ-200 16K RAM expander will work on the VZ-300, but only giving you an additional 8K.) Although there have been various other members spotted in the Laser 300 series, apparently differing only in RAM size or case type, none were reportedly sold widely if at all. The VZ-300/Laser 310 is otherwise nearly totally compatible with the VZ-200/Laser 210 except for its clock speed. As NTSC compatibility was no longer required, VTech switched to a single 17.734475MHz master crystal divided by four for the 4.43361875MHz PAL colourburst and five for the 3.546895MHz CPU clock. (The Motorola 6847 VDG in the VZ-300 and PAL systems generally is clocked with an altered signal which I'll talk about when we open the machines up.) Although that makes the VZ-300 slightly slower at 99.09% the speed of the VZ-200's 3.5795454MHz (315/88) oscillator, in practical terms the difference was imperceptible with most existing software — but of course it's going to be a problem for us later. VTech did no other upgrades, not even offering an alternate 6847 font ROM with lowercase, though we'll talk more about that when we get to the innards as well. a Christmas gift from my wife (I married well). The DSE pricetag on the back gives its price as A$9.50 but I don't know where or when it was originally purchased. While the TRM does not approach the sheer detail of, say, the Commodore 64 Programmer's Reference Guide, which even has an exhaustive memory map covering its 64K of RAM and 20K of ROM, it does include documentation on most of its important RAM locations and a full set of schematics, some of which we'll be using in this very article. A similar manual exists for the VZ-300 with its own set of schematics, which also discusses the VZ-200 and has some details not in the earlier text. (for Los Angeles residents, read "Vernon"). The North Ryde building was subsequently occupied by German truck and bus manufacturer MAN, whose old stripped logo can still be seen on the facade, and is now split between multiple tenants. Level I BASIC is quite, uh, basic, evolved by TRS-80 designer Steve Leininger from Li-Chen Wang's "copyleft" Palo Alto Tiny BASIC which Leininger substantially altered, reworking its structure and adding floating point math (because it couldn't accept Charles Tandy's salary when he typed it in), two string variables and a single array, and support for the TRS-80 hardware. VTech's version is similarly modified to support its own architecture but is otherwise the same. Level II BASIC is Microsoft BASIC, derived from Microsoft's own Extended BASIC on the Altair, and again VTech initially imported it nearly unchanged except for adding support for their hardware and graphics, which replaced some of the keywords (like TROFF with COLOR). Proof can be seen by comparing the order of keywords in their token tables, which would have no reason to match as precisely as they do unless they came from the same origin. Another persistent relic in the VZ BASIC ROM is the old Microsoft two-character error message table (e.g., ?SN ERROR instead of ?SYNTAX ERROR) even though the existing code never references it. Tandy's apparently successful legal action against EACA and PMC spooked VTech that they could be sued in the same way — but by Tandy and Microsoft. The company's solution was to dump Level I BASIC entirely, eliminating any objection from Tandy, and for Level II BASIC to secretly null out a large number of entries in the ROM BASIC keyword table potentially unusual enough to be used as evidence of copying. The tokens for those keywords still remained valid, however, and the ROM code for them also largely persisted. Disk-specific keywords were likewise omitted in the same fashion, at least until the VZ-300 disk drive debuted, but unlike the other gutted keywords were instead vectored through RAM for later expansion. These keywords (in token order) are CMD, RANDOM, DEFINT, DEFSNG, DEFDBL, RESUME, ON, OPEN, FIELD, GET, PUT, CLOSE, LOAD, NAME, KILL, LSET, RSET, SAVE, SYSTEM, DEF, DELETE, AUTO, FN, VARPTR, ERL, ERR, STRING$, INSTR, TIME$, MEM, FRE, POS, CVI, CVS, CVD, EOF, LOC, LOF, MKI$, MKS$, MKD$, CINT, CSNG, CDBL and FIX. Because their implementations often remained present, it was possible to resurrect many of them by hooking into the RAM vector for tokenizing "new" BASIC keywords, and some BASIC extensions did just that. The earliest versions of the Laser/VZ ROM use light green text on a dark green background. Without a colour encoder this would produce light text on a dark screen, which is indeed what you see on a black-and-white Laser 110. Bill's earlier NTSC VZ200 is the same way, using the same ROM 1.2. By ROM 2.0, as in this VZ-200, the display became dark green text on a light green background, like the Tandy Color Computer which uses the same MC6847 video chip. do have a 4K system, just a very late one. You may have noticed the oddly convoluted BASIC statement I entered to get that figure. That's because I had to avoid typing the number 5: the key didn't work. Normally the VZ200 will beep as you press keys, but there was no beep and no response when I did. In fact, an entire run of keys (5, T, G, B and N) was not working, and I was only able to enter the PRINT keyword by pressing SHIFT-P. We'll need to fix the keyboard now to do anything substantial with this machine. did appear to work. Still, it seemed like the most reasonable place to start, so let's crack the computer open. another VTech unit, the unrelated Laser 50) and a plastic cover sheet with slits for the top ports' card edges to reduce dirt getting inside. Also visible on the top right/northeast side is a sprawling heat sink screwed to the fin of a 7805 voltage regulator peeping out from the lower right/southeast corner. This heatsink sits under the ventilation slits in the top case. Much of the logic board is covered by a large sheet metal Faraday cage serving as an RF shield, festooned with soldered metal braids connecting everything to the ground plane, and then the whole assembly placed on an irregularly shaped metal plate on the bottom with the piezo. As mentioned, in those days the FCC was very strict about radio interference from computers and video games, particularly home units where a Class B device (as this is) had a 10dB lower maximum than a commercial Class A one. Some systems like the Atari 400 solved this problem by effectively encasing the entire system in a molded metal endoskeleton and placing as few holes in the case as possible from which radio signals could emanate. That made for a very sturdy computer but one more expensive to manufacture, so VTech went for this cheaper, hackier approach which was no doubt iterated upon until it just cleared the bar. One major component is not under the cage, however, and that is the Motorola 6847 VDG video chip, in a plastic carrier (MC6847P) with a date code of 24th week 1983. It's not precisely clear why that is, but it can be seen that the left board is connected to some of its lines. PAL synchronous demodulator, a surprising choice, since the MC6847 is usually paired with the MC1372 NTSC colour modulator. The 6847 emits YPbPr (as Y, B-Y and R-Y) video, which in the black and white Lasers only the Y (luma) signal is used. In other systems like the Tandy CoCo the MC1372 takes the YPbPr lines, encodes the colour, and emits a signal suitable for a television set and/or composite video depending on the specific components. The TBA520 can be made to do the same task, even generating NTSC colour with the right crystal, albeit with more supporting electronics. (I presume it was less expensive than an MC1372, plus there would be the advantage of not having a different chip for Euro and Aussie systems, since the TBA520 can obviously do PAL video too.) Reference B-Y and R-Y signals are generated to the TBA520 using the 3.58MHz (315/88) NTSC colourburst oscillator on the left board, while the B-Y and R-Y signals from the MC6847 are passed on different lines, with the MC6847 running on the same 3.58MHz clock. We then pulse the TBA520's line inputs at the necessary horizontal rate, approximately 15.7343kHz, causing the TBA520 to emit a single NTSC chroma signal (on its G-Y pin) from the 6847's PbPr signals. (This theoretically makes it possible to get proper S-video out of the VZ200, though we're not going to try that this time.) Discrete components then combine the luma and chroma into composite video for both the monitor connector and for feeding into the separate RF modulator. this problem), so I decided to just clip the tabs with angle cutters. One of those tabs is here over by the 7805 ... Scriptovision Super Micro Script, which has a 6802 CPU (a microcontroller version of the 6800) and a 6847 VDG, RAM, ROM and a simple keypad for entry. In that article I mentioned that those were enough to make it almost a home computer (replacing the ROM on the Super Micro Script to make it one) because home computers like the VZ-200 have a similar architecture. Now we'll prove the comparison is valid. In this view, the MC6847 is the large DIP on the far left/west side. The chips in the back, going from left to right, are a Hitachi HM6116P-2 2K static RAM used for video memory, the CPU, a clone SGS Z80 (the former state-owned SGS Microelettronica "Società Generale Semiconduttori" of Italy prior to merger into STMicroelectronics in 1987) with a date code of 19th week 1983, a Hitachi 74LS139 and 74LS32 used as part of the address decoding for the memory mapped I/O range, and lurking in the back right (east) corner a 74LS174 6-bit flip-flop serving as a latch register. In the front, also left to right, are a Hitachi 74LS245 octal bus transceiver which bridges the shared 2K video RAM between the CPU and VDG, a Hitachi 74LS04 hex inverter used for various tasks such as the CPU reset circuit, a Hitachi 74LS244 octal driver, another Hitachi 6116 2K SRAM (the system RAM this time), and the two 2364 8K system and BASIC ROMs with date codes of 27th week and 32nd week 1983 respectively. On the Dick Smith schematic using the same order, these chips are numbered U15 (the 6847), then U7, U4, U3, U2 and U1 (74LS174), then U14 (74LS245), U13, U12 (assumed), no designation for the single 2K SRAM, and U10 and U9 for the ROMs. The ROMs are unsurprisingly the newest chips in the system and mean the computer could not have been assembled earlier than then, likely making it part of the last production runs before VTech abandoned the line in North America. Obnoxiously, everything is soldered down; there are no sockets (cheap!). However, there are a number of unpopulated pads. Some extra pads near the ROMs were clearly intended to accommodate larger-capacity chips, and later machines indeed use a single 16K ROM with a change in board jumpers nearby. (Braver folks than I have extracted VZ-200 boards with 2364s and found bodge wires underneath. Apparently underpaid labour and smaller ROMs were less expensive at the time. Cheap!) There is also another set of pads near the VRAM chip between it and a big block of through-hole resistors. It's not clear what these pads were meant for, though the VZ-200 schematics show another resistor bank there serving as pull-ups. This bank is drawn on the schematic with dotted lines unlike the other set, so perhaps they were eliminated for cost reasons (cheap!). Now let's talk about what we don't see. One thing we don't see here is a 3.58MHz master crystal. That's because ... we already saw it. The entire system runs from the 3.58MHz crystal on the colour encoder, so everything is precisely synchronized to the same clock source, including the TBA520, the MC6847 and the Z80. It is therefore impossible to merely switch the colour encoder boards and turn an NTSC VZ200 into a PAL VZ-200 or vice versa because of the added line padding circuit in the PAL unit and the absence of a second system crystal in the NTSC unit (cheap!). What about the VZ-300, where there's no 3.58MHz crystal either? In that system, the VDG is entirely clocked by one of the gate array chips, providing the same line padding logic, but also using the same 3.54MHz clock as the CPU which is apparently "close enough." Another thing we don't see is something like a Motorola 6883 synchronous address multiplexer. Recall that the 6847 VDG has no externally exposed registers of its own (compare to, say, the VIC-II in a Commodore 64). Things like video modes and character attributes are twiddled by chip lines; for character attributes these lines are often wired to certain data bits from the video RAM, but to dynamically set a video mode under software control requires external hardware. Also, the VDG makes little attempt to cooperate with the CPU as to when it accesses video memory, other than indicating when it finishes a frame which is likewise asserted on one of its pins. In the Tandy Color Computers (prior to the CoCo 3, which uses a GIME), the MC6883 SAM sits between the 6809 CPU and the 6847 VDG and arbitrates all of this, managing the display mode and system timing, and servicing the VDG while the CPU is on the bus. On the other hand, this approach was judged too expensive for the cut-down Tandy MC-10, which instead uses a series of flip-flops to interleave bus access between its 6803 CPU and the 6847. A single 74LS245 bus transceiver allows the CPU unrestricted access to the video RAM when the processor is accessing memory. Neither approach is suitable in this case, however. An MC6883 would be too expensive for the VZ200 also (cheap!), and the Z80 sits on the bus longer during a CPU cycle than a 6502 or 6800-family chip would, so the MC-10's interleaved approach won't work either. As it happens, the VZ200 does nearly exactly what the Scriptovision Super Micro Script does: during CPU video RAM access, the VDG's memory fetch is immediately suppressed using its MS pin and the 74LS245 bus transceiver temporarily kicks it off the bus. The contention problem is solved in both cases with software (cheap!) by simply not doing anything with VRAM until the VDG indicates it's between frames and not reading screen memory. The only difference is how they find that out; the SMS busy-waits on the VDG's FS signal before doing a screen update, while the VZ200 just wires FS to its IRQ line — screen updates using ROM routines are batched and when the interrupt is triggered, the ROM then blits the deferred changes to the screen all at once. Of course, if you write directly to the video RAM when the VDG is accessing it you'll get intermittent artifacts, and I'll show you what that looks like, but you can just watch for the IRQ yourself if you really care about it (many programs didn't). Otherwise, the VDG's mode pins for bitmapped graphics and alternate colour selection are handled through bits in the 74LS174 latch within the memory-mapped range, which also handles the piezo and cassette output. Overall this is a good demonstration of how the SMS was almost a home computer, because here's a home computer whose video architecture was almost the same. A missed opportunity with the more upmarket VZ-300 was the potential for lowercase or at least an alternative character set, especially because it even got a word processing cartridge released for it later (we'll play with it, it works with the VZ-200 also). An external font ROM can be lashed to the 6847 with a bit of additional circuitry and the Super Micro Script has one to generate higher-quality character glyphs. It seems like VTech could have done something like that controllable by another latch bit, and with a six-bit latch there are a couple more data bits there that could be used, but I guess that was either judged too risky or not even thought about. On both systems the 6847 INT/EXT pin that would have controlled this is merely hardwired to ground. One note about the metal RF shield: if the cage is not pulled back down into position, it may distort and contact some of the pins on the 74LS174. This will cause weird graphical artifacts and knock out the piezo (no keybeep). It doesn't appear to harm the computer, but I was very careful to ensure it was bent back to as similar a position as before after this happened a couple times. Obviously this is no problem if you just completely take it off. that), which is why they could never complete a junction and be sensed. On the other hand, the 6, Y and H keys on that column are wired separately into the ribbon cable, so they were unaffected. I'm not sure how such a fault would have happened. The keys move, but they don't sweep or scour, and ordinarily they shouldn't be contacting the painted portions anyway. It also doesn't seem likely to have been a factory defect because that would have made the computer very difficult to use, and this computer was clearly used. I pondered the best way to fix it, since any repair would have to be flat or it would distort the key sheet on top (e.g., no solder blobs, no top bodge wires). I have a circuit pen I could use to draw a new trace, but it's temperamental, and I didn't want to do something I couldn't undo later in case it wasn't actually the problem. do work! Do not overtighten them or you will interfere with the conductive nubs being able to make contact. I had a couple dud keys initially after this which were returned to life by slightly loosening the screw nearest to them (to my great relief). COLOR ,1): #00ff00 and red is #ff0000 and so forth. That is definitely not the case; in fact, the default VDG palette is rather a bit muddy, with relatively poor saturation. For example, black (what the border is supposed to be) is often more like a very dark brown, buff is a dirty off-white, magenta becomes a flaccid purple where the red is a little too low, and what the documentation calls cyan comes out closer to seafoam green. Unfortunately, many simpler or older emulators provide an excessively rosy (no pun intended) simulation of what these typical home computer implementations usually generated. MAME uses the correct palette and the VDG's Wikipedia entry has a credible synthetic screenshot based on the YPbPr values in the datasheet, which you can compare with the real composite grabs above. absolutely capable of good output, but to do so it needs a quality encoder, and the VZ's ain't it. The best colour I have ever seen from a VDG is actually the Super Micro Script's, using a very high quality output stage as shown in the actual grab above, and comes out vibrant, beautifully saturated, and fabulous on a CRT. You would expect that, however — it's a $500 prosumer video titler from 1985, not a $99 crap home computer from 1983. The next order of business is software. I'd rather not use tape or audio files, and I don't have the disk drive. Fortunately, because the VZ series is so beloved in Australia, those wacky Aussies occasionally create their own modern peripherals in between prawns on the barbie. If you have a VZ-series computer, then you need the BennVenn VZ300 SD Loader. It is fairly inexpensive and provides you a way to load software into your VZ-series computer via SD card, along with topping off the RAM, even more memory with bank switching, and optional solder-yourself connectors for gamepads and I/O expansion. I figured it might be fun to build some hardware for it (and we're going to create a very simple expansion ourselves for the VZ200 in this article), so I ordered the full kit. It works well for my purposes and my wife has ordered another for the VZ-300 now at my in-laws' house in regional NSW. However, I am neither affiliated nor associated with Ben, merely an overall satisfied customer, so this is the part where I will also make three gentle constructive complaints about it. First, things like new firmware are largely delivered through a private Facebook group. This group appears to be very welcoming to new members, but it requires you to be on Facebook, and I don't want to be on Facebook. I managed to get the current firmware another way, and I will be putting it in the Github repo for this project so you don't need to join Facebook either. (If you do want to join, however, I'm sure the "VZ200 VZ300 Laser210 Laser310 fans" group would love to have you.) On the other hand, Ben was reasonably accommodating of my questions over E-mail which I did appreciate. looked like the right one until I got out the continuity tester and realized the actual fault was elsewhere. I'm not sure why some of them were routed around instead of in a straight line. Salora Fellow, a Finnish rebadge of the 4K PAL Laser 200 (by contrast, the Salora Manager is a Finnish rebadge of the CreatiVision-derived Laser 2001). This is determined by a simple memory map check in a snippet of its VHDL that Ben shared with me: x"B7FF" ) else '1'; --B800 or higher RAMarea200 <= '0' when (Address > x"8FFF" ) else '1'; --9000 or higher RAMareaSelora <= '0' when (Address > x"7FFF" ) else '1'; --8000 or higher put the reset button, nor was I particularly enthusiastic about drilling a hole in the case to make one, first due to the questionable quality of the plastic itself and second for purposes of historical preservation of an unusual machine. a Gremlin Blasto arcade board (where we had no reset circuit of any kind) that its 8080A CPU could be crudely reset by simply putting a pushbutton switch between its reset pin and ground. As the Z80 can serve as a drop-in upgrade for an 8080, it can be reset in the same way. .VZ format, which has a trivial 24-byte header indicating filename, starting address and type (BASIC or binary). The LOAD command will conveniently auto-execute binary files when the load completes. You can find many programs on Dave "Bushy" Maunder's exceptionally comprehensive site containing software, photographs, articles and documentation, and most software he offers can be copied directly to the card and used immediately. 2018AD. There's not much of a VZ200 demoscene, but there are a few out there, and this exceptional demo is unquestionably one of the best. It will not run correctly on this particular computer because the video timing is different — not because the clock speed is faster, like you'd see between an NTSC Commodore 64 which is faster than a PAL Commodore 64, but because the NTSC VDG draws the screen faster and thus fires the end-of-frame interrupt more often, messing up synchronization. For that, you'll just have to watch this YouTube recording on actual PAL hardware. It's set up like a trackmo, streaming cassette program data from one channel of a specially recorded CD audio track and using the other channel for music (admittedly a bit of a cheat but the music is excellent). If you didn't think rotozooms, raster splits and even FLD-type effects were possible on the 6847 VDG, then you're in for a treat. Another neat trick is the doubled vertical resolution while drawing the Kefrens bars. The source code is even available for your education. entirely done with semigraphics. It restores the old light-on-dark screen colours used in earlier ROMs with POKE 30744,1 (this works with twiddling the CSS pin with COLOR,1 also). Dubois and McNamara (i.e., Greg Dubois and Tricia McNamara, though Greg did all the programming), who created various titles for a number of DSE systems that were sold in stores. I should note that for many games, including this one, the more-or-less standard control keys are Q and A for up and down, M and comma for left and right, and where a fire button is used, typically SHIFT (SPACE for secondary). Note the "snow" in this shot — that's because the program was animating screen memory at the same time the VDG was trying to read it, so the VDG's memory access got briefly suppressed during that period. Because the display scan can't wait for the VDG to be enabled again, the result is a brief splat of garbage on that line until the VDG is allowed to proceed. Dubois could have simply waited for the VDG's next interframe interrupt, but there's also only so much time between frames before the VDG will start drawing again. As a result, for many programs where significant CPU time was required to do screen updates, outright ignoring the video artifacts turned out to be the least bad approach. that was) by Stephen Clarke. It shows loading from the SD card, the title and options screen (even the VZ200 had software pirates), and then playing the game, which worked fine on the keyboard. This and the other recordings I did for this entry were generated from the composite capture rig for video, but for audio using a microphone near the VZ200's piezo speaker to capture sound (since there's no audio out). You'll notice I'm pounding on the keys a bit, which the microphone faithfully picks up, though you do have to hit the keys with a bit of, shall we say, deliberateness to get them to register. Lemonade Stand: Meatpies, where you sell pies. Yes, the meaty kind, America. glasses pies you want to make, how many advertising signs you want to buy, and the price per item you want to request. Other than the pie business, Larry Taylor's port of the game seems to be heavily influenced by the well-known Apple II version and includes the same sort of simple graphics for weather reports and the like. It oozes professional quality with a slick title screen and menu, and is an extremely fun puzzler to boot. The aim is to create a factory from various primitive machines (paint, rotate, hole punch) that will generate a specific product. It is so well animated and so thoroughly polished that it deserves this short video to fully appreciate it. copious documentation for all its features, as it was a surprisingly credible word processor on par with at least, say, Color Scripsit on the Tandy Color Computer, though Color Scripsit is some years older. Although Wordpro came as a cartridge intended for the VZ-300, it would work on a VZ-200 with correspondingly less document memory available, since it occupied the slot where the RAM expander would go. On the other hand, the program seems to be calibrated for a VZ-300 keyboard since on this VZ200 the keys seem to frequently stutter. (I'll talk about how I got it to work on this 4K system later, though it would not have been possible without the BennVenn RAM expansion.) see this emulation — is also notable because the CoCo 1/2 and the VZ-200/300 all lack lowercase, so both programs solve it in the same way by displaying "capital letters" in reverse video. Wordpro's user interface is more sophisticated than Color Scripsit's, but it's also newer. The lack of a lowercase option on the VZ-300 was again a real missed opportunity, and with the number of machines DSE was buying you'd think they could have talked VTech into engineering a solution. Although Wordpro supports both disk and tape, the BennVenn cartridge currently doesn't emulate them sufficiently for Wordpro to use it. Perhaps this is a hack we can do some other time. a la Night Driver where you are apparently an alien with wings and feet ... It's only rendered at 90 degree angles, but it's fast and well-written, and deserved another video. Some games, though many were fine, would show a weird line pattern over certain sections of the screen like this port of Exidy Circus/Midway Clowns. The pattern was annoying, but in the first few games I played where it manifested, it appeared to be cosmetic (it does not restrain the jumping figures here) and I initially chalked it up to some other undiscovered difference in this NTSC unit. LDI that copies the contents of the address referenced by HL to the contents of the address referenced by DE; the instructions LDIR and LDDR expand upon it, running LDI repeatedly and decrementing the count in BC each time until it reaches zero, respectively incrementing or decrementing HL/DE on every step. The most obvious application for these instructions is copying a block of memory elsewhere, but a less obvious application is using them to fill memory. Consider this segment of actual code from Invaders (dumped with z80dismblr): Ignoring the instruction at $8ca1, you can see that this is setting the source to $7000 — i.e., the start of VRAM — and the destination to $7001 (?!), for a total of $0820 bytes (the zero test is post-decrement). Now, what would that accomplish? Just before the LDIR, we set the contents of $7000 (in HL) to zero. Let's step through the process LDIR takes manually. $7000 is first copied to $7001, which is now zero as well. HL is incremented to $7001, DE to $7002, BC decremented to $081e. Next, $7001 is copied to $7002, but $7001 had zero in it because it was copied from $7000, so all three locations are now zero. HL is incremented to $7002, DE to $7003, BC decremented to $081d. Then, $7002 is copied to $7003, so now all four locations are zero, and so on, filling all intervening locations with the immediate value before. At the end, when BC finally gets to zero, all locations from $7000 to $781f inclusive (i.e., the entirety of video memory and a little past it in system RAM) will have been zeroed out. This is how Invaders clears the hi-res screen and it is indeed faster than a naïve loop, especially for large tracts of memory. But our obnoxious little plastic beast here throws in a wrench by having a location where the RAM isn't working properly. When the "copy" gets to that point, because the copy is only between adjacent memory locations, for every subsequent location the stuck bit will be propagated forward and faithfully copied to each and every byte afterwards. That's also why the pattern doesn't cover the whole screen, because the problem doesn't actually manifest until the "copy" operation arrives there. In fact, in the process Invaders was unwittingly corrupting some of its own game variables with the same stuck bit when they should have been zero, possibly another reason why it wouldn't run correctly. The direct and most definitive solution would be to "simply" replace the VRAM chip, and I even have 6116 SRAMs in stock, but I warned you this is a very cheaply made PCB. Far better repairpersons than I have tried and failed to replace chips on these computers without requiring a lot of rework and bodges, and the prior portions of this article should have already convinced you it's only by the grace of God I haven't soldered my own fool face to the workbench yet. I did not want to try replacing that SRAM chip solely because of one stinking bad bit; I was only likely to make a bigger mess or render the computer completely inoperable. But again: we have an alternative. This fill trick was not universally used or even known by all programmers at the time. The games that do work clear the screen with a simple loop that doesn't propagate the bad bit forward, which works because the store doesn't depend on what memory contents are already "there." Likewise, VTech doesn't seem to use it in the ROMs, which is why the problem didn't manifest during the demonstration tape or with BASIC programs drawing to the screen with BASIC keywords. Most VZ programs are small enough and this code idiom distinctive enough (and usually only present once) that such code can be found and patched to use a slightly slower but functional loop. As such a loop would generally require more bytes, the patch could either direct execution to a tacked-on routine to do the clear, or we could patch it to point to a standard routine in memory. And how are we going to get a standard, always-present, stock routine into memory to do that? Easy: we're going to soft-alter the BennVenn SD loader's firmware. No, stop laughing, because we have a simple means to accomplish it. At the same time we'll combine that with a serial port loader so that we can test these programs live without having to constantly swap the SD card to and from the Talos II, so we'll also build it a bitbanged serial port (I said stop laughing). There were homebrew serial devices back in the day for these computers, so consider this one merely another entry from a venerable tradition. .VZ format. Here's a simple, complete example of "Hello World" showing how to construct that header and which can run directly from the card, demonstrated in the screenshot. This is one of several files you will find in this article's Github repo. As with all our assembler projects except for the 6502 and PowerPC, we crossbuild using the Macroassembler AS. The 24-byte header marks this as a machine language program that starts at $8000, the beginning of the extra memory furnished by the BennVenn device. Although the magic number VZF0 (for BASIC programs, which always start at $7ae9) or VZF1 would appear to be critical, the firmware doesn't seem to check it on loading or even generate it on saving, only that the byte just before the starting address word (everything is Z80 little-endian) is either $f0 or $f1. Upon execution our program then calls a "display null-terminated string" routine in the VZ ROM, the update for which is pushed to the screen during the next VDG interframe period, and returns to BASIC. The binary is assembled with AS like so, using a simple Makefile: >hello.vz (44 Bytes) % xd hello.vz 00000000 56 5a 46 31 48 45 4c 4c 4f 00 00 00 00 00 00 00 |VZF1HELLO.......| 00000010 00 00 00 00 00 f1 00 80 21 07 80 cd a7 28 c9 48 |........!....(.H| 00000020 45 4c 4c 4f 20 57 4f 52 4c 44 0d 00 |ELLO WORLD..| 0000002c LOAD"HELLO" will load and immediately execute it from the given entry address (which is both the load and execute address), as shown in the screenshot above. the Github repo I have a small program to cycle the LEDs on his proto board, which you can see in this brief video. It sets all GPIO pins to output and lights all 24 green LEDs connected to them (the red ones are check LEDs for 3.3V, 5V and 9V), then cycles a dark one through them from left to right until a key is pressed. This is done by hooking into the interrupt routine called when the VDG completes a frame, the only regular timesource on an unaltered VZ200, and used back in the day as a simple clock by various programs. Every third tick of the interrupt routine, this code runs: It rotates an in-memory image of the GPIO pin values, then emits that to the I/O locations. Because the rotation is to the left, we can see that the GPIO lines must also be oriented little-endian, i.e., the least significant bit of each GPIO output register is on the left. This then informs how we'll set up our bitbanger. A half-duplex system will suffice for downloading, since the sender will wait for us to indicate receipt between packets, and that will let us concentrate entirely on receiving until a full packet is obtained. The absolutely fastest speed we can receive at is generally limited by how quickly we can clock data bits into an accumulator from the receive line. If we connect the receive line to the least-significant input of one of the GPIO registers (we'll use the leftmost for convenience), we can do it in 23 cycles: The Z80's clock speed (in any of these systems) does not neatly divide into any standard bitrate, but theoretically 23 cycles per bit gives us a maximum possible transfer speed of ((315 000 000/88)/23) =~ 155632.4 bits per second. That suggests you might be able to get 115200bps with an unrolled loop, but at speeds this fast time required for other tasks starts to be a concern, such as storing to memory, checking how many bytes have been received, and branching back to get another, all of which together will certainly be more than 23 cycles. The other problem is the time required to sense the start bit, because this can occur at any moment, and hardware UARTs generally end up repeatedly snooping the line at some multiple of the bitrate to ensure they won't miss one. We, on the other hand, can't even check for a start bit at just twice 115200bps. In fact, the fastest we can check for a start bit (a zero) is which because of the unavoidable branch is actually longer than the time to clock in a data bit! However, these numbers do suggest that half that speed, i.e., 57600bps, is plausible. Flipping the equation around, that gives us a relatively generous ((315 000 000/88)/57600) =~ 62.1 cycles per bit, long enough to do our housekeeping tasks on each byte, and our tight startbit loop can poll the line at ((315 000 000/88)/25) =~ 143181.8 bits per second (a familiar number to some of you), which is at least twice the data rate and should be sufficient for the sort of continuous data transfer we'd experience receiving a data packet. We will target this speed. (Note from the future: an early draft used in a,(c) in the startbit loop, which is a 12-cycle instruction. This single extra cycle reduced the startbit poll rate to 137674.8bps, and at that speed multiple bytes got missed and/or corrupted. We are probably only just fast enough to make this work.) Parenthetically, VZ-300 owners in the audience will now have asked if this will work for them. If we substitute its lower clock speed at 57600bps, we get ((17734475/5)/57600) =~ 61.5 cycles per data bit and a maximum startbit poll rate of ((17734475/5)/25) == 141875.8 bits per second exactly. Because you can sample a little bit faster but never slower, we would need a separate version for the VZ-300; the same code will not work reliably on both. Sorry! That will be the subject of a future article. Note that by making receive fast, we made transmit slower: unless we occupy the least-significant bit of another GPIO register, which seems rather wasteful, the next fastest position is the second-to-least significant bit. This snippet needs no less than 31 cycles to send the next bit of a character stored in a register other than the accumulator (here we'll use B): If we had to completely guard that GPIO register from interfering with any other GPIO pins on the same register, it would be even longer because we would need to read the current state and then do the bitmasks. Mercifully we'll just refuse to support that, and as 31 cycles is still well within our 62 cycle maximum per bit, she'll be right. Texta Sharpie. If you don't have his board, you can still figure it out a little less conveniently with a voltmeter. Ensure all pins are set to output and turned off (something like FORI=68TO73:OUTI,0:NEXT will do from BASIC). The only live lines at that point should be ground, 3.3V, 5V and 9V. Find ground first, which you might do by checking for continuity with the ground test point Ben provides on the board, then use that as your common to find the voltage pins. Mark those; the rest are GPIO. Turn on pins one and two individually (OUT 71,1 or OUT 71,2) and look for voltage. don't connect the 3.3V line. Instead, for the programs below, ensure the HW-597 is already plugged into your host (such as with a USB extension cable) and showing bright status LEDs before powering on the VZ-200, or it may try to unsuccessfully power itself from the other lines and get a little daft. BITS) toggles the screen colour as it sees activity on the receive line. This is easiest to watch at a slow bit speed of around 150 baud or so. Here, I hooked it up to the Talos II, ran picocom -b150 /dev/ttyUSB0 (adjust for the path to your device), and just banged on the T2's keyboard. If you get alternating flashes of green and orange on the VZ while you do so, then your receive line at least has basic connectivity. ASCII), effectively one half of a very slow terminal program. We'll use the internal ROM routine to display a character, which will get us scrolling for free, and then force the update instead of waiting for the next IRQ — which is disabled anyway to make sure our timing remains precise. (Typing only upper case characters works; lower case shows as symbols.) This program runs at a sedate 300bps, and the reason is because the VZ ROMs are written for space efficiency, not time efficiency, at least to any extent they're efficient at all. 300 baud gives us an apparent surfeit of cycles using our formula — 11931 cycles per bit — but we may well need all of them since we've really got no idea how long it can take the ROM routines to do any arbitrary screen update. We won't be using the ROM much for our data blaster program, but a general purpose terminal emulator would have to consider a proper solution to achieve faster speeds. This is something else we might revisit in a future article. The other purpose of this ASCII test program is to mock up how we'll write the fast serial loader. Despite the fact we have over 10,000 cycles between bits at 300bps and could easily have written each bit we read as a subroutine call to save memory, I still inlined each clocked-in bit using a macro because we necessarily need to at 57.6kbps — among other things, each CALL is 17 cycles and the RET to return from it is 10, which would consume almost half our CPU budget by themselves. I'd also like to observe, again with my usual biases showing, that cycle counting isn't nearly as much fun on the Z80 as it is on the 6502. Most opcode tables will fortunately collapse the whole Z80 T-state and M-state business into a single unified cycle count, but unlike the 6502 where there are instructions with execution times of 2, 3, 4, 5, 6 or 7 cycles (so you can easily make a busywait from any combination), the Z80's cycle time options start at 4 and go as high as 23, skipping many numbers, and many of the smaller cycle times require specific conditions like not taking a branch. Having considered our little half-terminal program, here's what I settled on for 57.6kbps, written as AS macros: From our previous maximal case I turned the in b,NN instruction into a slightly slower in b,(c), which burns an additional cycle, but means we have 38 cycles left over of our 62 which we can split exactly between two ld (ix+N),b instructions of 19 cycles each. (This also lets us possibly alternate between multiple connected serial devices by changing C, but one catastrophe at a time, I always say.) The separate top and bottom waits are for situations where we have an odd number of cycles left over and need to have different wait times; consider this future expansion for the VZ-300. When the stop bit arrives, we need to dump the byte into a buffer and get ready for the next one in the same 62 cycles, since we expect the other end will be ready to fire the next start bit at us immediately. To make an interesting and vaguely useful display (as well as not requiring additional memory), the screen itself would seem like a good place, but this also imposes some constraints: we only have 512 bytes there (i.e., 32x16), some of which we also need for indicating status, meaning our received packets should really be no larger than 256 or 384 bytes to allow for a transmission log and other useful info. The protocol we select should have packets no larger than that, be easy to implement (because I'm lazy), and be something that pretty much everything can speak. While we've seen Xmodem-1K or Xmodem-CRC implemented other places (like The Newsroom's Wire Service variant), I just decided to go with good old O.G. Xmodem. That contains 132-byte packets and is easy to write and checksum, and any errors over USB between your host computer and the VZ200 would undoubtedly be from bad bit framing rather than line noise which the default checksum algorithm should detect. While it overruns memory a bit at the end, this is largely irrelevant for just loading something we intend to immediately execute. All that preamble yields us a stop bit stanza like this: Here we use the IX index register as a pointer into screen memory and the L register as the packet length countdown. A double-store of the same location onscreen once again soaks up 38 cycles, then the increment and decrement, then the branch. A nice thing about the JP instruction, which is absolute instead of relative, is that the conditional branch form requires 10 cycles regardless of whether it's taken or not, so this entire stanza always consumes precisely 62 cycles as well. We use that instruction a lot in the cycle-exact portions so that we always have predictable CPU time. Once we get a full packet, we know the sender won't do anything until we reply, so we can relax our timing and validate the packet at leisure, copy it into the correct place in memory and send the ACK for the next one. We send bytes using the same send-bit route I showed you before or a trivial variation, padded to 62 cycles per bit and also inlined. We accept .VZ-format files in this loader, so we have special handling for the first packet to make sure it has a generally correct format and note the type and memory address, which is where the rest of this packet and subsequent packets will be copied to. If it doesn't, then we send CAN and force the sender to abort. By contrast, the start bit is handled with the same 25-cycle code I showed you before, because this is the fastest way we can be sure we won't miss one. But this also means we have no way of checking the keyboard nor implementing a timeout: there is no spare time to count cycles or scan for keys, and the only free-running timer is the VDG end-of-frame IRQ which will totally mess up our timing if that runs, so during the entire transaction IRQs are disabled as well. The program therefore assumes your sender is up and ready to go the moment it starts executing. On startup it fires off the initial NAK and waits, possibly forever if the other end never gets the signal until you reset the VZ200. (We display a message to alert you that no transmission has yet been received, which is immediately overwritten on-screen by the .VZ metadata.) Let's see our loader in action. On the host side, to send the program to the VZ200 you can use any terminal program that speaks Xmodem (and just about everything does), just as long as it automatically starts the transfer as soon as the initial NAK arrives. With both my MacBook Air laptop and my Raptor Talos II workstation, I use lsx with the usb2ppp tool from BURLAP, which we earlier used to tunnel PPP over a serial line for the Brother GeoBook, but can be used to run pretty much any program over a serial port. Here's an example, substituting the path to the HW-597 that your machine uses (e.g., Fedora Linux on my Raptor Talos II uses /dev/ttyUSB0): We start the loader, which you can run as a separate program on its own and it will load anything that does not encroach on its default location at $e000. (We'll find an even better spot for it in just a minute.) Since our ASCII half-terminal program loads and executes from $8000, this is no problem; it takes up three blocks (there's apparently an off-by-one bug in lsx), so it's a good quick test of the machinery. The loader immediately sends NAK and we're off to the races. RUN you can just hit RETURN on to run a BASIC program. Ta-daaaaa! The Australian, paywalled link). Now we want to make it part of the system. To convert it to "firmware" takes advantage of a specific feature Ben built into the SD card reader for easier updates: the ability to load and run a new system "ROM" directly from the card. The default memory map for the VZ200 puts the system ROMs between $0000 and $3fff, reserving the space from $4000 to $67ff for ROM cartridges, though a cartridge could technically take over any address range above the TOM (that's how the RAM expanders worked, after all), and we'll come back to that point later. For the system to recognize code at $4000 or $6000 as part of a cartridge, a sequence $aa $55 $e7 $18 is required in that order, and execution then starts at $4004 or $6004. As shipped to you Ben's device not only fills in RAM above the TOM, it also fills RAM in from $4000 to $67ff and puts its own code there with that sequence, effectively "slushware" (a la the DECmate II, and we'll use the same term here since it's not really ROM). This code is run by the system ROM on startup like a "cartridge," because that's what it looks like to the system ROM, and this code is what does the RAM test and initializes SD card access. Once the system is up, it then does this: VZDOS.VZ it's loading from the card is "magic." If present, it will be used to temporarily replace the slushware at runtime; for a couple extra seconds spent loading it you don't have to mess around with burning it to the cartridge. But this binary is not signed or checksummed, nor does the load check if it's even a new copy of the slushware — any program will serve as long as the .VZ header loads it to $8000 but the code is written to execute from $4004 (as the onboard image would). The slushware then places a little trampoline copy routine at $a000 and runs that to copy the 8K from $8000 to $9fff to $4000, overwriting the old slushware, and jump into the new one. To make our replacement code useful, we should provide some quality-of-life features. We'll make it autostart into a transfer so that all you have to do is load up the program into your Xmodem sender and reset the VZ200, and after a polite delay it will pull down and run the program automatically. We'll also let you load multiple times if you want instead of immediately trying to execute the current file being transferred. We'll also finally put that routine in memory for the slower but more forgiving memory fill operation, and enable the VZ sticks by default in case we find something that really needs them. But more important than those, we should also let you drop back into BASIC and use the SD card loader normally without having to pop the card out. That requires us to include a copy of the actual VZDOS.VZ which we will embed in our replacement code. This adds an additional complication, because the 2.32 slushware (the most current as of this writing) is already 8068 bytes long minus the .VZ header, leaving us only a little over 2K for our own code. Moreover, if we're over 8192 bytes (and it's inevitable we will be), the loading process will overwrite at least 100 bytes of our code with the trampoline and fail to copy the rest. We'll solve this by immediately copying the remainder as the first step in our binary, and then post-processing the object to yield a new VZDOS.VZ with a 128 byte hole between the first 8K and the last 2K (remember it gets loaded to $8000, so we have plenty of space there). Part of this code will be used to make a jump table entry for our slower fill so the call will stay constant with future updates, if any. That looks like this: Since we are embedding VZDOS but we need to keep all its relative offsets intact, we skip the first 7 bytes and the .VZ header, and run those instructions later just before we jump back into it (if we do). We also do a couple patches so that VZDOS will reload (us) on a reset, but not when we execute the embedded copy, and still use an unmodified 2.32 so that you can see there's nothing up my sleeve. Time for our fill routine. 7001, etc. dec bc ld a,c or b ld a,(slobyte) ; flags kept jr nz,sloclrl ret not in VRAM, then do everything LDIR would and leave the routine with A, HL, DE and BC set as they would be at the end. (We do set the Z flag on exit, but most routines won't care about this.) Then our Invaders example, which was can be patched by overwriting the two instructions at $8caa with ld a,0:call 04008h. xor a and could just nop it.) (I couldn't cursorily find out more about this person), who also did Invaders and a number of other software releases for DSE under contract. except scrolling the attract-mode screen, because unavoidably we'll scroll up the stuck bit. I don't think there's a good general way around that. Fortunately it's purely cosmetic, and most games I converted in this fashion seemed to work fine without any glitches. WORDPRO.VZ can also be placed on the card and run from there as we did previously, though doing so doesn't enable file operations either.) You'll need copies of the actual ROMs, which do circulate. The entirety of the code — really a disguised linker script — looks like this: Remember that Wordpro was first and foremost written for the VZ-300, which has 16K of RAM, so its TOM is much higher ($b7ff). The cartridge, because it has full control of the bus, thus maps its much larger ROM in at $d000-$ffff, with 2K of $d000 also mapped to $6000 with the cartridge header sequence. This echo of the main cartridge ROM is what actually autostarts everything since the system ROM doesn't know to check anywhere else but $4000 and $6000. The same scheme works for the VZ-200, except there is no RAM between $9000 and $bfff. But with the BennVenn cartridge, we have RAM everywhere, so we load to $8000 and copy the Wordpro ROM dumps upon execution to their proper location(s), duplicating $d000-$d7ff to $6000-$67ff like a real one, and jump into the "cartridge" at $6004. This copy operation will destroy BFL-the-slushware, but we can just reset to reload it. Wordpro will get all the RAM it would expect to get on a VZ-300, even on this 4K VZ200. too efficient and constructed a general fill subroutine which lots of things called, the screen clear portion being only one of many. (Darn those efficient little assembly language programmers.) we are closed now!"), one of my favourite Intellivision titles, given a solid conversion as Hamburger Sam also by D&M. Z88 Development Kit. Arkaball by Jason Oakley, an obvious Arkanoid clone, but competently crafted and worth a video. VZ-DOOM, a Claude-written raycast Wolfenstein 3D-style game. It fortunately didn't need patching and "just worked." Your mileage may vary as to whether you think the AI usage is cheating, and this blog has a strict no-AI-article-text policy, but it performs as advertised on this NTSC machine and likewise merits a video. VZ-DOOM uses WASD for motion, comma and period to strafe, E to open and SPACE to shoot. VTech items continued to show up in Dick Smith stores, and VTech did make other Laser computers, these "later Lasers" were not closely related nor compatible with the VZ line, or each other, and most of them were much less successful — with the exception of their Apple II clones. The Laser 3000, fresh from its Summer CES 1983 debut, also made it down under to Dick Smith stores as the Dick Smith Cat. It required real Apple II ROMs in an external cartridge for compatibility, which also made it a target for Apple, fresh off their successful victory against Franklin Computer for using substantial portions of the Apple II ROM in the Franklin Ace 1000. Although VTech was still able to sell it elsewhere and the Apple II ROMs were never integrated into the base machine, Apple instead argued that the mere use of the ROMs was an infringement upon its intellectual property regardless, and successfully blocked further imports to the United States. VTech learned from this just like they learned from EACA, and developed new ROMs that were carefully clean-room reverse-engineered, additionally incorporating a licensed copy of Microsoft BASIC retrofitted to act like Applesoft BASIC. This process provided the legal assurance that not a nybble of Apple's code was even consulted, and VTech used these unencumbered ROMs to create what was introduced at Summer CES 1985 as a redesigned "90% compatible" (per Creative Computing) Laser 3000. In turn, that reworked Laser 3000 was transformed into the 1986 Laser 128, a semi-portable riff on the Apple IIe with an expansion slot and built-in 5.25" floppy (later 3.5"). VTech's work paid off handsomely: reviewers were impressed by its value for money, most software never noticed the difference, and Apple's repeated attempts to prevent its importation and sale all ended in failure. The Laser 128 family's low price and exceptional built-in functionality made them the most widely sold Apple II clones in the United States, finishing on the market as late as 1989 in an upgraded 3.6MHz version with a 3.5" disk drive and over 1MB of RAM. returned to journalism in 1987. Meanwhile, DSE was still selling enough VZ-300s to keep them in this 1987-88 catalogue, and according to Greg Dubois' contacts at Dick Smith even at that late date they continued moving over 100,000 units a year, but in the end it was actually VTech that wanted out: VTech wanted to redirect factory capacity to the Laser PC and wasn't willing to keep producing the older system, and even DSE's offer to double the order couldn't convince them otherwise. Although some software and accessories still appeared in the 1989-90 catalogue, the computer itself did not, and the line disappeared completely by 1991. For a time afterwards DSE sold IBM consumer PCs and even Commodore PC clones in the process of adopting its own DSX PC brand. In the 2000s the company failed to make a successful transition from its mail order origins to the new world of online sales, and despite several attempts to rework its retail presence Woolworths unloaded Dick Smith to Anchorage Capital Partners in 2012 in a controversial deal where much of the sale price was allegedly financed by Anchorage liquidating DSE's own assets. Anchorage took the company public in 2013, netting tens of millions, but the company did not recover and all 363 remaining stores were closed by May 2016. Today the Dick Smith brand lives on solely as a mark of online retailer Kogan, primarily selling consumer electronics. Australia's crap home computer, by golly. Much as Sinclair did in the UK and Commodore in the United States, the Aussie VZ-200 and its successor VZ-300 remain as beloved as they are because they introduced a entire generation of Australians to computers who could never buy one before. While a few importers tried to bring the also-rans to the South Pacific (DSE even had Radofin's undead zombie Aquarius in their 1985 catalogue!), the VZ was there first and in large numbers, over 20,000 VZ-200s alone, becoming the down-under standard against which all subsequent cheapo systems were measured. Indeed, when the desperately dire Tandy MC-10 got in front of Australian Personal Computer in December 1983, reviewer Surya commented that when considering it versus the VZ-200 "the MC-10 does not stand up well to this comparison." Legions of user groups and newsletters sprung up to support it, tinkerers designed all manner of expansions for it, and users wrote and sold their own software for it, ironically spawning exactly the sort of hobbyist-driven computer ecosystem post-Dick Smith that Dick Smith-era Dick Smith had previously tried to foster. Ultimately the little Hong Kong desk wedge became more of an Australian computer icon than even some truly homegrown ones. As for this NTSC VZ200, it should be very possible to clone it because the ROMs are the same as the better-known DSE flavour and it's otherwise all off-the-shelf hardware; moreover, it would be infinitely easier to maintain and repair than the ghastly PCB it's got now. The schematics for the PAL Dick Smiths are widely available and there are even fewer components needed to build an NTSC one. At least one person has already made an NTSC-compatible RC2014 workalike, though that project uses a GAL, and it seems like we could make a more straightforward knockoff just using what the original did — with the exception of the colour encoder, which would be improved and somewhat simplified by using a proper MC1372 instead of the TBA520. I know "Leaded Solder" Mike has his clone CreatiVision, so I look forward to him picking this up as a new challenge. ;) We'll be doing more with this system and particularly the VZ-300, now safely awaiting my next Southern Hemisphere trip, in future articles — along with a recently-acquired PAL CreatiVision of our own, the basis for the Dick Smith Wizzard, which we need to see if we can get up and running (I do like me a 6502 and a 9918). Meanwhile, David "Bushy" Maunder's VZ website can give you all the articles, technical information and software that you can stick on an SD card. are all on Github, including pre-built binaries and ready-to-go Bush Food Loader "slushware" you can use with your own SD card loader, all of which are under the BSD 2-clause license.
In short: from my experience, people like map and filter, but not reduce. I use functions like map and filter all the time. When I put that code up for review, my peers rarely complain. I get plenty of feedback about other decisions, but not about my use of map and filter. I cannot say the same for reduce. Often, when I’ve submitted a patch with reduce inside, I get a comment like, “this part is hard to read.” And I see reduce way less than map, filter, some, and so on. Anecdotally, I have come to believe that programmers don’t like reduce as much. I don’t know why, but I have a few theories: reduce is harder to read. reduce is less familiar. reduce can have worse performance compared to other options. reduce is less elegant in languages I use, like JavaScript, Python, and Swift. In my blissful stint as a Clojure developer, I did not get this feedback. I’m wrong, and I’m seeing a trend that’s not real. I usually just change reduce to something else and move on. Even though I prefer it, I don’t usually care much. But it’s a little social phenomenon I’ve observed, and I thought I’d document it. I’ve also noticed this less recently, possibly because code review is less thorough nowadays. Do you notice this? Do you like reduce? Please tell me.
Most people, when asked why they do what they do, lie. This isn’t because they’re malicious but it’s because the honest justification for a career is rarely noble. It’s usually a combination of a decent paycheck, tolerable hours, and whatever neurosis you
A Niri workspace with 7 visible columns. After having used practically the same xmonad configuration for a decade and a half I’ve now modernized my setup with the scrollable-tiling Wayland compositor Niri. It’s been a bit of a struggle to unlearn my old workflow but I’m really growing to love Niri’s scrollable workflow, especially on my new super ultrawide display. Samsung Odyssey Neo G9 G95NC 57” My new 57” single monitor setup. What kicked off my Niri journey was the purchase of a new super ultrawide monitor. I bought the 57” Odyssey Neo G9 as it was the largest monitor I could find. (It’s marketed as a “gaming” display but it’s really an amazing productivity display.) It replaced my old 3-monitor setup: My old 3-monitor setup. The new display is wider so I had to move the speakers around 10–15cm further apart. I was debating whether to replace the center 31.5” monitor or replace all monitors with a single one but I think I made the right choice with the ultrawide. The curvature wasn’t an issue (I’ve come to prefer it) and the extra vertical space the portrait side monitors provided wasn’t as crucial as I thought. I think an ultrawide is worth it just to get rid of the annoying bezels. Small things can be a big thing sometimes. A more dynamic workflow xmonad and Niri are similar yet different. Both automatically lay out windows as you spawn them but xmonad (at least the way I used it) follows a layout algorithm that re-flows using a “master” window and combines the rest of the windows into one space, while Niri lays out windows in columns. The change is subtle but it implies that a new window won’t change the size of other windows. This is very nice if you spawn a lot of short-lived terminals or web browsers like I do and it reduces the amount of manual reshuffling I spend time on. My xmonad workflow was more static than my Niri one. In xmonad I made heavy use of workspaces, mapping ten workspaces mentally to different programs, such as 0 Firefox and 1 terminal logs on the left monitor; 3, 4 and 5 for different Neovim instances on the center monitor; 8 as chat and 9 for music or video on the right monitor. I had no rules to enforce this; it’s an emergent behaviour that served me well for years. With Niri it’s more dynamic. I still use workspaces but they no longer have direct shortcuts, I simply go up/down in the workspace list. Maybe I’ll add them in the future but with 3–4 workspaces that’s not as necessary. I spawn workspaces/windows when I need them and remove them when I’m done. Usually it’s one workspace per project (yes, I’m now one of those who have multiple up at once) with all the related things such as editor, terminals, and browser with docs. I don’t typically utilize the full screen width and I try to keep the things I’m working on in the center, often leaving 10–30% gaps on the sides. Even though I don’t normally use the “endless scrolling” feature of Niri I re-center selected windows all the time so I can look straight ahead as much as possible. Keyboard shortcuts As a fan of keyboard layouts of course I have to spend some time tinkering with good keyboard shortcuts (especially as Niri’s recommended keybinds don’t map well with my custom keyboard or custom layout). Navigation layer What I did was add a new navigation layer that’s enabled by holding Tab (ring + middle + index on the left-hand side) with all Niri related movement and layout keybinds. In the graphics above, all green-colored keys emit Gui (which gates all window manager commands) and you can see: Long press on Close Window to close a window. The long press requirement prevents accidentally closing windows. Arrows move through columns/windows. Long press resizes them. Workspace Up/Down focuses a different workspace. Center a column. Consume/Expel to combine windows into one column. (consume-or-expel-window-left/consume-or-expel-window-right) Expand Column makes a column take up all remaining space. (expand-column-to-available-width) Audio controls. To press them I release the index finger (keeping the ring and middle finger pressed to keep the layer active) and use the index to press the audio buttons. Mouse buttons. In Niri you can move floating windows with Gui + Left Mouse and Gui + Right Mouse to resize them. As my main mouse is a trackball integrated into the keyboard I had to add them to the left-hand side. I ended up using QMK’s customizable key repress feature that allows me to: Tab combo with my three fingers (layer is active) Release only the index (layer is still active, same as with the audio controls) Press the index again (now detects the press Gui + Left Mouse key down) Use the trackball to move the window And similarly for the right mouse button to resize with the middle finger. Works great! Because there are so many commands I want to send I placed Ctrl on the thumb that provides movement-related commands like so: For example: Arrows move columns/windows in the four directions. Move columns to the neighboring workspaces. Center visible columns. (center-visible-columns) Slightly different consume/expel semantics. (consume-window-into-column/expel-window-from-column) Regular keymaps These are triggered in the “normal” way by first pressing the Super combo and then another key on the base layer (I use autoshift so I shift with a long press). Window management Super + F toggle windowed fullscreen (keep column width) Super + Shift + F fullscreen window (over the entire display) Super + M maximize column (moves other columns) Run stuff Super + Enter terminal Super + E Noctalia’s launcher (also exists on the navigation layer as Launch) Super + S show Noctalia control center Super + Shift + S show Noctalia settings Super + Q power off monitors (they wake on input) Super + Shift + Q show Noctalia session menu (reboot etc) Super + Shift + L lock screen Misc Super + H show hotkey overlay Super + P interactive screenshot Super + Shift + P screenshot selected window Tweaks to the standard CachyOS setup In the process of moving from xmonad to Niri I also moved from Void Linux to CachyOS and I let the installer install Niri and give me a basic configuration together with Noctalia (that provides a statusbar, notifications, and a bunch of things you apparently need). Center the status bar and other Noctalia windows My centered Noctalia status bar. Feels absolutely required on this screen otherwise things end up in the corners. Firefox on XWayland Force Firefox onto XWayland as the Wayland popup manager is broken: environment { MOZ_ENABLE_WAYLAND "0" } Dead keys for Ghostty For some reason dead keys were broken in Ghostty. This is bad for me as the OS keyboard is set to Swedish and it uses them to type ~ (quite a crucial character for a programmer). The fix: environment { GTK_IM_MODULE "ibus" QT_IM_MODULE "ibus" XMODIFIERS "@im=ibus" } This needs ibus installed and running. Melange colorscheme Noctalia discovers custom color schemes under ~/.config/noctalia/colorschemes/<Name>/<Name>.json, so I dropped in my trusty Melange colorscheme there: { "dark": { "mPrimary": "#EBC06D", "mOnPrimary": "#292522", "mSecondary": "#A3A9CE", "mOnSecondary": "#292522", "mTertiary": "#85B695", "mOnTertiary": "#292522", "mError": "#D47766", "mOnError": "#292522", "mSurface": "#292522", "mOnSurface": "#ECE1D7", "mSurfaceVariant": "#34302C", "mOnSurfaceVariant": "#C1A78E", "mOutline": "#867462", "mShadow": "#1a1816", "mHover": "#E49B5D", "mOnHover": "#292522", "terminal": { "normal": { "black": "#867462", "red": "#D47766", "green": "#85B695", "yellow": "#EBC06D", "blue": "#A3A9CE", "magenta": "#CF9BC2", "cyan": "#89B3B6", "white": "#ECE1D7" }, "bright": { "black": "#34302C", "red": "#BD8183", "green": "#78997A", "yellow": "#E49B5D", "blue": "#7F91B2", "magenta": "#B380B0", "cyan": "#7B9695", "white": "#C1A78E" }, "foreground": "#ECE1D7", "background": "#292522", "selectionFg": "#C1A78E", "selectionBg": "#403A36", "cursorText": "#292522", "cursor": "#EBC06D" } } } Then pick the colorscheme: "colorSchemes": { "darkMode": true, "predefinedScheme": "Melange", "useWallpaperColors": false } Layout appearance The default appearance was pretty I admit but way too much blank space and weirdness. Some tweaks: layout { // Required for noctalia-shell to set wallpaper background-color "transparent" // Never auto-center focused columns (too much movement) center-focused-column "never" // But do center a single window always-center-single-column // No extra space around it all struts {} // No gaps between windows gaps 0 // The focus ring was annoying focus-ring { off } // Use a border with consistent width for all windows instead border { on width 2 active-color "#ebc06d" inactive-color "#403a36" } // Setting widths is important with such a large screen preset-column-widths { proportion 0.15 proportion 0.3 proportion 0.4 } default-column-width { proportion 0.15; } // Heights too, why not? preset-window-heights { proportion 0.15 proportion 0.5 proportion 1.0 } } // Prevent the mouse from opening the overview in the corners gestures { hot-corners { off } } Keep windows centered Niri has the always-center-single-column option, which is nice as I want to keep as much as possible in the center of the monitor when I’m working. But I very frequently use 2–3 smaller windows and with my frequent opening and closing I’d like them centered too. Luckily, Niri has an IPC you can use to make a small program that reacts to events and does this for you. I made a small rust project using the niri-ipc crate that does this for me: The autocenter implementation [dependencies] niri-ipc = "26.4.0" use std::collections::HashMap; use std::io; use niri_ipc::socket::Socket; use niri_ipc::{Action, Event, Request, Response, Window, Workspace}; #[derive(Clone, Copy, PartialEq, Eq, Hash)] struct WindowId(u64); #[derive(Clone, Copy, PartialEq, Eq)] struct WorkspaceId(u64); struct OutputName<'a>(&'a str); struct WindowState { workspace: Option<WorkspaceId>, width: f64, } fn main() -> io::Result<()> { let mut socket = Socket::connect()?; if !matches!(socket.send(Request::EventStream)?, Ok(Response::Handled)) { eprintln!("niri rejected event stream"); std::process::exit(1); } let mut known: HashMap<WindowId, WindowState> = HashMap::new(); let mut read_event = socket.read_events(); loop { let result = match read_event()? { // A full snapshot of the current state. Just refresh our state. Event::WindowsChanged { windows } => { known = windows .into_iter() .map(|w| { ( WindowId(w.id), WindowState { workspace: w.workspace_id.map(WorkspaceId), width: w.layout.tile_size.0, }, ) }) .collect(); Ok(()) } Event::WindowOpenedOrChanged { window } => { let workspace = window.workspace_id.map(WorkspaceId); let entry = WindowState { workspace, width: window.layout.tile_size.0, }; let prev = known.insert(WindowId(window.id), entry); match prev { // Don't center floats. _ if window.is_floating => Ok(()), // New window, try to re-center. None => maybe_center_new(&window), // Window changed workspace, try to re-center. Some(state) if state.workspace != workspace => center_focused_if_fits(), // Skip other things. Some(_) => Ok(()), } } Event::WindowClosed { id } => { if known.remove(&WindowId(id)).is_some() { center_focused_if_fits() } else { Ok(()) } } Event::WindowLayoutsChanged { changes } => { // Only re-center if the width was changed, otherwise our re-center will // loop back indefinitely. let mut resized = false; for (id, layout) in changes { if let Some(state) = known.get_mut(&WindowId(id)) { if (state.width - layout.tile_size.0).abs() > 0.5 { state.width = layout.tile_size.0; resized = true; } } } if resized { center_focused_if_fits() } else { Ok(()) } } _ => Ok(()), }; if let Err(e) = result { eprintln!("autocenter: {e}"); } } } /// Center a newly created window if the workspace is focused and if there's surrounding free space left. fn maybe_center_new(window: &Window) -> io::Result<()> { let Some(workspace_id) = window.workspace_id.map(WorkspaceId) else { return Ok(()); }; let Some(focused) = focused_workspace()? else { return Ok(()); }; if WorkspaceId(focused.id) == workspace_id { center_if_fits(&focused)?; } Ok(()) } /// Center windows in the focused workspace if there's surrounding free space left. fn center_focused_if_fits() -> io::Result<()> { if let Some(focused) = focused_workspace()? { center_if_fits(&focused)?; } Ok(()) } /// Center windows in the workspace if there's surrounding free space left. fn center_if_fits(workspace: &Workspace) -> io::Result<()> { let Some(output) = workspace.output.as_deref().map(OutputName) else { return Ok(()); }; let Some(width) = output_width(output)? else { return Ok(()); }; if workspace_width(WorkspaceId(workspace.id))? < f64::from(width) { center_visible_columns()?; } Ok(()) } /// Issue a one-shot query to Niri, wait, and return the response. fn query(request: Request) -> io::Result<Response> { match Socket::connect()?.send(request)? { Ok(response) => Ok(response), Err(msg) => Err(io::Error::other(msg)), } } /// Get the focused workspace. fn focused_workspace() -> io::Result<Option<Workspace>> { match query(Request::Workspaces)? { Response::Workspaces(ws) => Ok(ws.into_iter().find(|w| w.is_focused)), _ => Ok(None), } } /// Get the width of an output (monitor). fn output_width(name: OutputName<'_>) -> io::Result<Option<u32>> { match query(Request::Outputs)? { Response::Outputs(outputs) => Ok(outputs .get(name.0) .and_then(|o| o.logical.as_ref()) .map(|l| l.width)), _ => Ok(None), } } /// Calculates the width of all columns in the workspace. fn workspace_width(workspace_id: WorkspaceId) -> io::Result<f64> { let Response::Windows(windows) = query(Request::Windows)? else { return Ok(0.0); }; let mut columns: HashMap<usize, f64> = HashMap::new(); for w in windows { if w.workspace_id.map(WorkspaceId) != Some(workspace_id) { continue; } if let Some((col, _)) = w.layout.pos_in_scrolling_layout { let width = columns.entry(col).or_insert(0.0); *width = width.max(w.layout.tile_size.0); } } Ok(columns.values().sum()) } /// Send a command to center the visible columns. fn center_visible_columns() -> io::Result<()> { if let Err(msg) = Socket::connect()?.send(Request::Action(Action::CenterVisibleColumns {}))? { eprintln!("center-visible-columns rejected: {msg}"); } Ok(()) } One catch is that if a new window overflows the monitor width, the script won’t center the columns even if there would be free space left afterwards. This is a little weird but it’s consistent with Niri’s center-visible-columns command. I had a small itch to try to hack around it but in the end I left it alone… Is Niri worth it? Yes, absolutely. Niri has been a huge upgrade for me in combination with a single wide screen. My xmonad setup worked really well with three monitors—arguably a better fit in that context than Niri—but for the big-screen use-case Niri is superior. I’m curious how it holds up on my laptop, once I gather enough energy to install CachyOS on it… But that’s a side quest. The big-screen setup I spend most of my days in is the best I’ve ever had, and I have no desire to go back.
