SDS added drums to the 940 system whose CPU design was taken from the SDS 930 system as modified by the Berkeley project Genie. The drums were fixed head devices—one track per head. They provided low latency and high bandwidth for swapping virtual memory. They were fairly reliable and hardware parity check seemed to detect the few data errors. Drum addressing and drum IO was by the page but drum addressing seemed to be wrong sometimes and drum addresses for both read and write were evidently occasionally mis interpreted by the hardware. It was difficult to be more certain of the problem than this.

We allocated a core array with one drum content check word per drum page frame. We divided the 24 bit check word into three parts, X, Y and Z. In the core array entry for a given drum page frame we kept <X pay load from page, write count for page frame, Z pay load from page>. On the drum we kept in some fixed relative position within each page, perhaps word two, the following word: <hash of drum address, payload, write count>.

Upon writing a page to drum we incremented the in core write count for that page, moved pay load data from word two of the page to the in core check word for the page, then planted the write count and drum address in the page and wrote the page to drum. After reading a page we verified that the drum address found in word two of the page was as expected, and compared the write count in the newly read page with that in the check word in core. Finally we replaced the pay load data that had been maintained in the check word in core.

On some of the machines we thus verified that the drums were indeed addressing the wrong drum page frame on both reads and writes about once per day. We would sacrifice one or two customer's calculations and continue with the rest. This provided the information necessary to diagnose the hardware design problem.