System/1 Build Log
An ongoing chronology of System/1's construction, and any other related musings.
18th January, 2015 - Populating and testing the memory interface
With the memory interface and RAM boards cleaned and left to dry overnight, it's time to get on with testing them out!
The RAM board had already passed a cursory continuity test on all the bus signals yesterday, so it got stuffed with chips first; I almost got halfway through populating the interface board before I realised that I'd forgotten to buzz it out, so after a momentary hesitation decided to pull the chips I'd fitted back out and grab the multimeter. Which was lucky, because I found one signal that wasn't making it to the right places — and since it was one of the control signals for the MDR shift register that was only making it as far as the first chip, it might not have been the most obvious fault to diagnose!
That broken connection repaired and the chips fitted, I plugged the interface board into my backplane breakout board, wired up the mbed, and ran some test routines to generate various memory operations whilst monitoring the AE, READ and WRITEx signals with the logic analyser. Full word writes looked to be perfect but single-byte writes were always asserting WRITE0 regardless of address; reads weren't asserting READ at all!
Rude words were said at this point.
Tackling the single-byte write issue first, the various signals through the WRITEx paths were all consistent with the write actually being to an address at an exact multiple of four, which was peculiar, until I noticed that all the address lines were 0. As were all the data lines. The penny dropped, and I realised I'd left RESET floating on the backplane breakout; strapping it high with a jumper wire brought the other three WRITEx signals to life.
Tracking down the lack of READ signals was a bit trickier, but following the first law of troubleshooting (thou shalt check voltages) showed the internal READ signal as sitting at 0.7V. This is not a particularly pleasant voltage for a logic signal to be sitting at, so I pulled the inverter that turns it into READ and the AND gate that generates it and still measured 0.7V on the relevant pins. Looking at the other chips that consume that signal, I pulled one of the '299s that make up the MDR and it fell back to a nice clean 0V. Hmm. Swapping that '299 with another made no difference, so it was obviously something to do with the socket it was in rather than the chip — a look under the loupe with a bright light showed a whisker of enamelled wire just managing to bridge that READ signal at pin 19 to pin 18, which is tied to ground. A quick poke with a scalpel sorted that out, and READ started behaving as it should too.
The next step was obviously to try out a few memory transactions, so I plugged the RAM board in and wrote a few of the traditional hex 'words' to the first few locations in RAM; reading the first one back I got 'deadfeef', which was definitely pretty close. Some of the others had similar single-bit errors in the fifth nibble, although 'c0ded00d' survived unmolested; the data on the bus looked fine with the RAM board unplugged so a closer inspection of the board found another bridge between D14 and D15 on the upper bank, which was a bit bigger than the other one but still a simple enough fix with a bit of wick...
... and now both boards are working happily, with random test transactions of all flavours passing with flying colours. The decoding logic on the RAM board seems to be working as far as I can test it without fitting a second bank of chips — that is, if I change the 'address' DIP switches it appears in a different location in the memory space — so I'm happy for now. Later in the week I'll get on with doing some more thorough testing.