BUT... while investigating this I discovered a bug in the SAP-1 design, and this one is not my fault.
While the 74189 16x8-bit RAM chip used for program and data storage in the SAP-1 has tri-state outputs, it doesn't have a separate output enable line. Instead, the outputs are driven based on the state of the chip enable and write enable lines as follows:
|Function||Chip Select||Write Enable||Outputs|
The problem comes in the way the SAP-1 loads the RAM. The book says to select the "Program" mode, which disconnects the Chip Select line from the normal RAM read logic and drives it low. The RAM address and data is then set into the address and data switches, and the "Write" button is pressed momentarily to drive the write enable low and load the RAM location. With the "Write" button released the write enable line goes high.
Note that with the write enable line high, the RAM is driving the contents of the selected address onto the "W" bus. However, immediately after a reset the system is in state T1, during which the contents of the Program Counter are driven onto the "W" bus. This means that while the operator is flipping switches both the RAM and the PC are trying to drive the "W" bus at the same time. The PC drivers can happily sink 24 milliamps, but the RAM can't source anywhere close to that. With any luck this will merely cause the RAM chip to get hot, but it could cause physical damage to the chip. So it probably wouldn't be a good idea to leave a real SAP-1 in "Program" mode for too long.
Of course this won't damage my simulation at all. I just see a bunch of red Xs on the "W" bus signal in this state. But any time I see red Xs in simulation I take notice.