SPAM mark III has never been built, and will never be build. However, it could be built. These are ideas that we know we can implement, and for some, were actually planning to implement.
Selective Message Erase
Fast Play, Reverse Play, Fast Reverse Play
Message Encryption
Other Simple Improvements
From the vantage point of the mark II, selective message erase is not far off, in terms of design. Our plan was to add a new set of auxiliary counters that could address the data ram (which would have to be multiplexed with the existing counters), and a four (4) bit register for copying data. We would actually only need two new counters, since variable length messages only have a granularity of 256, the high byte of the address. The data inputs on these counters would need to be connected to the address bus, so they could be loaded from the ewe ram.
In addition to the counters, we would probably need another EPROM and another controller input mux, since currently we are using all inputs and outputs, and multiplexing the outputs would be difficult since most are not mutually exclusive. From a user I/O standpoint, no additional hardware would be needed, since the ERASE button would function as selective erase while playing messages.
The microcode to handle this is fairly complicated. When erase is pressed, we decrement the message count. Then, we need to pack down the messages in the data ram, so that it does not become fragmented. Suppose we are deleting message one, with three (3) messages stored. We need to make message two into the new message one. First we load the main counter with the start of message two, and load the auxiliary counter with the start of message one. We then copy the value in the data ram at the main counter address into the new register, and then back into the ram at the aux. counter address. We repeat this process until all of message two has been moved down, and then store the new end of message one, which will be contained in the aux counter. Then, we do the same thing to move message three down, and turn it into message two. The main reason we didn't attempt this was that adding a new EPROM would have been extremely difficult, since we would have needed a new board, and the microcode assembler (meant for a 16 bit computer) would have been difficult (though not impossible) to adapt to three EPROMS. Also, it was 5am Wednesday morning.
Playing messages at double speed would be a trivial addition to SPAM, requiring only a few lines of microcode. Since the address controller is incremented only from the controller, and the controller runs at eight (8) times the speed of the 8KHz clock, we could play twice as fast by waiting for the 8K clock to change, rather than waiting for it to go low, as we do now. Playing in reverse would only require a new controller signal and some up/down counters to replace the 74161's being used now. Playing fast in reverse is a waste of time.
For SPAM to be used by the government, we would probably need to implement some form of message security, so that evil spies wouldn't be able to hear important top secret two (2) second messages. To implement this, all ADC output would be pipelined through a three step process, consisting of XORing with a fixed value, adding a fixed value, and XORing again with another value. All DAC input would first go through the same pipeline in reverse. This would give twelve settable encryption bits (four bits X three pipe stages). We could hook a 12 key keypad (from a phone) to the project, and use it to set two registers, the 'In' and 'Out' encryption keys. The 'In' key would be used for the ADC output pipeline, and the 'Out' would be used for the DAC input pipeline. The paranoid individual would then set the 'In' key, clear the 'Out' key, and let his/her machine take some messages. Playing them with the wrong 'Out' key would produce garbage, but by setting the correct out key, the messages would come out clear as the window on an EPROM.
Minor things that we never got around to doing are
Next: SPAM Mark IV