INMC News |
April/May 1980 · Issue 7 |
Page 22 of 39 |
---|
In the last issue we promised that we would collect together all thoughts about ‘Memory Plague’, and publish them. We are indebted to many members of the IMNC for writing to us detailing various symptoms and possible causes. For more recent members of the INMC let us first define ‘Memory Plague’: this was a euphemism coined to cover the small percentage of Nascom Series 1 memory cards (that’s the one with the four EPROM sockets) that proved to be unreliable through causes not otherwise due to faulty or slow chips. ‘Plague’ soon became apparent after the release of the Series 1 card, and the symptoms are unreliabilty when working machine code programs in the expansion memory. ‘Plague’ is not usually revealed by Tiny Basic or the memory test programs as these represent data stored in memory and not op-code. ‘Plague’ usually affects the op-code fetch (M1) cycle as the timing is more critical, and results in the misreading of the op-code byte, causing programs to crash. The probable cause is noise generated on the Nascom 1 busses, although this has never been conclusively proved. A number of ‘cures’ were published, which consisted of basically three things:
On a Nascom 1 these work. On a Nascom 2, step 3 represents overkill, and can cause poor operation at 4MHz, the time constant being calculated for 2MHz.
Over that intervening period other possible causes have come to light. One is the 33R damping resistors in series with the address and CAS lines are too low to be properly effective. Another possible is the DBDR signal coming off too early. Yet another is the MREQ signal (applied to IC31) arriving too late, related to the system clock which latches it.
With the advent of Nascom 2, which is buffered on board, bus noise has been much reduced, and plague is almost nonexistent. However, Nascom 2 has revealed that the memory card will not run reliably at 4MHz without ‘WAIT states’.
We therefore now recommend the following:
Page 22 of 39 |
---|