Microcomputers As A Space Spinoff 3843

Eric Chomko

In 1975, I moved from the University of Copenhagen academic computer center to a commercial systems house (doing minicomputer real-time systems). As it happened, my first project was on a Nord-10, integrating an analog input system into the operating system for Skibsteknisk Laboratorium (loosely affiliated with the Technical University now called DTU). It was the first mini I ever touched that had semi- conductor memory. The system had severe stability problems, that were eventually traced to the memory subsystem, where disk allocation bit maps were susceptible to "bit rot". It was like a "burn in" effect where a bit that had long held a certain value and then got flipped, and not looked at for another long time would revert to the previous state. If you flipped it often or if you looked at it regularly, it would be fine. Looking back from my knowledge today, I am pretty sure that must have been STATIC RAM, rather than dynamic. It did serve to impress on many of us, that semiconductor memory was inherently unreliable (compared to core) and not to be trusted.

core for another 3 years, until the LSI-11s pioneered inexpensive DRAM. We loved the core systems, because they were pretty immune to bad power. If the power flickered off, the powerfail interrupt handler saved the registers, and when the power came back, it restarted, although you had to wait for the disk drives to spin up again. That was important to our customers in industrial plants.

As late as 1987 (long after I had moved from Denmark to California), I worked on a project where we discovered a DRAM refresh design problem in a Z80-based communications front-end processor. The system had multiple microprocessors with a shared memory. Each processor refreshed its local memory, and the shared memory would normally ride along on the main processor's refresh cycles. But if the secondary processors were tying up the global memory bus with their accesses to the shared memory, a timeout would kick a local counter on the shared memory board, which would then steal cycles from the slave processors to ensure that the global DRAM got refreshed. This subsystem was used in a variety of applications with a variety of different firmware loads, but at ONE customer site we had stability problems that were originally attributed to software bugs. Since I was responsible for the software, it fell to me to eventually prove that the memory was losing bits in hardware. That was hard to believe, since the design was by then 8 or 9 years old. Once that was proven (which took months) I worked with an extremely gifted hardware engineer who eventually figured it out: When the local refresh circuit on the memory board kicked in, it would send out wait states to fend off memory accesses from the main processor until the refresh had progressed far enough to back off again. It was when climbing down from that wait state that there was a timing error. The design validation diagnostics had never loaded the memory bus hard enough to go through this sequence, so the onboard refresh mechanism had essentially not been exercised by the design engineers.

The irony was, that I had seen exactly this problem 8 years earlier, while still in Copenhagen. I was working on a datacomm project where we used this exact same board set, and we had stability problems during debugging, when we used global DRAM for code. The problems went away when we burned the code into EPROMs, so that was how we worked around it. And the designers of the board set buttured us that if the code worked in EPROM failed when running in DRAM, we obviously had a bad store somewhere.

Our customer in 1987 was a high-security quasi-military installation. It caused a lot of complications that the two engineers buttigned to this projects were both foreign nationals (a Dane and a Canadian). For a while they were not sure that it would be possible to bring us into the site, but eventually they built a cage of chain-link fence around the section of the computer room where "our" VAX was located.

We were subcontracting to Martin on this project. Martin had had the foresight to bring in two subcontractors to do this subsystem. (They did not tell us that until the end, though.) For all the grief we had in delivering, we were still "the good guys" and I believe that the other sub never managed to get their version to work at all.

Lars Poulsen