April 18, 2020

Giving an Old Mod a New Fix

Back in the September 1983 issue of Color Computer Magazine an article by Dennis Kitsz showed how to add an extra 4K of RAM to the MC-10 internally, bringing the total up to 8K.

At first it may seem a bit silly to bother with such a modification when it is far easier to add RAM via the expansion port.  But because the design of the MC-10 isolated the 6847 video display generator (VDG) from the expansion port, adding RAM externally would not solve the problem wherein the two highest resolution graphics modes (each of which requires 6K of video RAM) could not be used properly.  Adding RAM internally was the only way to fully support all the graphics modes.

Unfortunately the article seems to have been written prior to availability of the 16K Expansion module from Radio Shack. It is therefore unlikely that the modification was tested for compatibility with that module prior to publication.  As it turns out, when an external expansion module (including the MCX128) is used in conjunction with an MC-10 that has been modified according to the instructions given in the article, there will undoubtedly be some interference seen on the video display.  The intensity of the interference can vary greatly depending on what the software is doing at the time.  Examples can be seen in this YouTube video by CanadianRetroThings.





After rereading Mr. Kitsz article and carefully examining the details of his modification, the cause of the interference was revealed.  A 74LS139 chip was used to decode two of the address lines (A11 and A12) to produce the four individual chip-select signals for the 2K SRAMs (the two original SRAMs and the two piggybacked additions).  The problem is that the Enable pin (/G) of this decoder was erroneously connected to a signal that is used by expansion modules to insert themselves into the address space.  Any assertion of this signal will disable the decoder and prevent access to any of the SRAMs.  If the decoder is disabled early enough within a cycle, it can overlap the period in which the VDG is trying to access RAM and thus result in the interference seen on screen.

Original diagram from the article updated to show the correction.

The fix for this problem is relatively simple.  Eliminate the erroneous connection of the decoder's enable pin and tie it to GND instead.  This keeps the decoder enabled at all times, as it should be.