Mysterious RAM problems in two Dick Smith System 80 X-4020 Expansion Units

Introduction

A couple of major items in the System 80 haul were two (somewhat yellowed) expansion units.

Figure 1. "Haul" X-4020 System 80 expansion boxes

Having dealt with any floppy drive issues and repaired one of the System 80s, it was now time to assess these X-4020s.

At first, neither unit recognised RAM successfully. I decided to tackle this issue first before moving onto any other expansion box functions, like disk operations. Part one of this two-part repair blog then deals with conspicuous absence of RAM!

Expansion box, or computer?

You might recall in the past I'd de-modded an old 48k unit down to 16k and cleaned it up . In fact I now had two working 16k System 80s, as the second haul machine was now carrying a CPU card that had been similarly chopped down from 32k to 16k.

I decided to focus on one unit at a time. The first thing i discovered is that two 4116 RAM chips were faulty in the batch I'd used for the preliminary testing. That was unhelpful. After culling out the bad ones and ascertaining the rest were ok, I pressed on with unit number 1, the least yellowed and cleanest of the units.

Plugging in the first 16k machine to the expansion unit under test with the X-4020's first RAM bank filled (8000H to BFFFH) and checking memory showed 16k rather than double that amount as expected? Hmm..not good. Plugging in the SECOND 16k machine into the box also showed 16k?

That confirmed it. For some reason all that juicy RAM wasn't being recognised??!

Figure 2. RAM banks in a X-4020 showing the first bank (8000H to BFFFH) populated

I wondered. In a previous life BOTH these machines sported an internal memory upgrade that I'd removed. Had I missed a cut track or some other vandalism associated with the previous memory modifications? Was it the machines, or was it the expansion box that needed treatment?

Before poking around the pins I thought I'd try my stock System 80 expansion unit obtained years ago with my Blue Label unit. That had never basked in the snug feeling of full RAM banks, as both my existing System 80s carried 48k under the keyboard. I expected no issues thereby proving the fault lay in the "haul" X-4020 rather than both my 16k machines. I filled up the expansion unit with known good 4116 chips and plugged the box into both machines in turn.

What?? Huh?? Both machines also failed to recognise the RAM in my EXISTING expansion unit!! Hurmff...??? The "failed to de-modify the computers properly" theory suddenly gained some weight. I hoped so because if this theory proved false, I had my existing X-4020 box to fix along with the one gained in the haul!

Figure 3 - Expansion RAM testbed with a 16k System 80

As if that wasn't strange enough, there was some more weirdness to mull over. The 32k internally expanded System 80 I had on hand recognised the final 16k of RAM fitted in the top bank of the the haul expansion box?? It seems then that it was only the FIRST bank from 8000H to BFFFH that was affected? However, this was not the case with my original expansion unit. The same 32k machine connected to my original box with the top C000H-FFFFH RAM bank populated still showed only 32k!!

The picture was getting murkier by the day!

Checking out the de-modified System 80s

I took these two machines apart, donned goggles set to the highest magnification and had a close, close look at both of them, searching for cut tracks or anything out of the ordinary.

Ah ha!! I HAD missed something. According to circuit diagrams, on IC number Z21 pins 1 and 2, and 4 and 5 were joined in stock 16k units. To upgrade memory internally, these pins needed to be separated. Removing the memory means they should be re-joined. One of these roughly cut dividing canyons was still present in both the 16k machines. From memory, I think I had seen the pin 4 and 5 cut when demodifying the machines initially and already joined it. A blob of solder soon restored both boards back what was normal for the 16k state.

Figure 4. Cut join between pins 1 and 2 on the Z21 NAND gate

However, even as I was fixing the de-mod, I was still skeptical. Even if the 48k and 32k line was floating, I couldn't see any reason why it should cause a failure to recognise RAM in the expander?

I tried the machines again. Sure enough, same result. Both failed to recognise RAM! Back to the drawing board. Having spent a few nights on this already that old phrase "Are we having fun yet?" sprang to mind.

In fact that phrase often springs to mind when I'm grappling with problems such as these!

Back to the expansion boxes

Ok, finding nothing else out of the ordinary as far as the 16k computers themselves were concerned, I returned to the theory that BOTH expansion boxes were RAM-challenged. Certainly my original X-4020 should have shown its fitted RAM with the 32k machine!

Now I'd discounted the computers I remembered I had a THIRD expansion unit, the most yellowed and beaten up one from the haul. I'd checked this before but I now knew I'd used faulty RAM. I reinstalled the GOOD RAM and checked again. This time both System 80s showed expanded memory attached to the box! That confirmed that the two computers WERE ok and it was the two other X-4020s that were faulty. But what could be causing the problem? Why did both boxes have a similar issue?

I did some preliminary checks with circuit diagram, scope and logic probe. Readings seemed normal! I checked continuity between the RAM chips. This was fine.

Usually at about this stage in these projects (when I'm starting to climb up the wall) I ask for help. I sought and got some advice from the EACA forums. As usual, a couple of people chipped in with useful tips. The System 80 does a quick RAM check, but just because it might fail to READ memory doesn't mean to say it might not be able to write to it. At least if I could see it write to a memory location in the high memory, I could ascertain that SOME communication was happening between the expansion boxes and the computers. Another possibility was that during the memory check, the System 80 was finding a few faulty locations and then giving up on the whole bank?

My own diagnostic program

Exercising my rusty Level II BASIC skills I wrote a menu-driven quick and dirty program to interrogate higher RAM. This code allowed me to select a specified area of RAM to read, read+write, and to "hammer" (i.e. continuously write to). It was hoped the latter would be useful to create a blip on the scope during execution.

Figure 5. Testing the RAM with a home brew RAM tester

I ran this program. The results were telling. No RAM AT ALL was being recognised as existing above 7FFFH with either of the expansion boxes connected. It was like the lower bank in the haul unit and BOTH banks in my original one were simply switched OFF!

More testing

Ok, time to take stock. I had two X-4020 boxes that didn't recognise RAM. One failed to recognise the first bank and the second recognised neither bank. I started to look more closely at the former, as I figured with at least one bank working, I could look for differences in the signals used to address the two banks which might point to a diagnosis.

I returned to the circuit diagram. The ONLY thing I could see that would make the upper RAM bank work and the lower RAM bank not would be some difference in the CAS input as determined by the two logic gates in the 74LS32 IC at Z22. I'd measured these pins before and hadn't found anything amiss but (as I recall) I had not measured them with a powered-up computer attached. This time everything was switched on.

Figure 5. Part of the circuit diagram showing the gates in Z22

Ah ha. Now there WAS a difference in output regarding the two gates. Further checking revealed a difference in the 32K and 48K lines feeding pins 10 and 13 of the IC respectively. I can't remember now exactly which was HIGH and which was LOW but I think the 32K line was LOW. Regardless, these two lines should be the same!

Fault identified and fixed

(a) In the "haul" expansion box!

Like a bloodhound on a trail I followed the 32k line around the (confusing) circuit diagram to determined where it suddenly became different from the 48k one. Another page of the circuit diagram showed these two lines originating from a 74LS139 (Z29) and disappearing into an "internal connection". These lines then appeared in a different place in the same diagram (again from an "internal connection") as inputs into a 74LS20 at Z37. So...this being the case pins 10 and 9 on Z37 should be connected to pins 6 and 7 respectively on Z29, right?

Figure 6. 32k and 48k as indicated. These should all connect up!

I tested for a closed circuit with a multimeter. Pin 9 on Z37 and pin 7 on Z29 were connected. 0 Ohms as expected. But wait...pin 10 on Z37 and pin 6 on Z29 were not showing any connectivity at all!!

AH HA!!!!

Maybe a break inside the IC, but let's have a look for some vandalism first. I removed the board, donned the goggles again, applied maximum magnification and CAREFULLY scrutinized the respective pins on the two ICS and the connecting tracks in between. YES!! It wasn't easy to see but pin 10 had been cut!! Try as it might, the signal on the 32K line would NOT be getting through.

Figure 7. Broken pin 10 on Z37

A strategically placed blob of solder joined upper and lower pin again. Connecting up to a 16K System 80 revealed I had my lower bank of RAM back! YES!!

(b) In my original expansion box

Could a similar act of desecration be the reason my original X-4020 did not recognise its RAM? I checked for continuity between the same sets of ICs and pins. AH HA! This time BOTH lines were showing ZERO connectivity! On with the goggles again. I found both tracks had been cut just after they exited Z29.

Figure 8. Cut tracks on my original X-4020

A couple of fine jumper wires soldered underneath the board and the issue was fixed! My original unit now recognised when it was wearing RAM.

Reflections

Cut tracks. Cut pins. After-market hacks of the haul X-4020 and my original X-4020 caused the issues here. Discovering this cost me a lot of evenings and a good chunk of one weekend. I figure these tracks were cut to stop accidental doubleup RAM addition (and RAM confusion) as each X-4020 was coupled with internally expanded computers. The top bank of the haul unit was left untouched as the associated computer only had 32k on board. There was room for another 16.

As with all my difficult repairs, I've learned something from this experience.

First, expect stuff to be messed with especially if it is designed for a specific environment like a school. I'm not beating myself up for missing the circuit cuts in the first place. The workings were subtle and unless you knew exactly where to look they were almost invisible.

Second, do tests under operating conditions. The mistake I made right at the start, was (if my memory is correct) not checking those bank select gates with a live System 80 connected to the expander. Had I done so, I'm sure I would have made progress sooner. I WAS looking in the right place. If I remember rightly (and I can't be 100% sure) with the expander not connected, there seemed to be no difference in those Z22 lines.

Figure 9. Expanded RAM now testing OK

So...the RAM in the X-4020(s) was now fixed. Although the title and introduction suggested this article was about fixes to the "haul" expansion boxes, it was actually about just one of those. The other unit was my own long-held X-4020 that I didn't even know was faulty!

Now it was onto the next major area. The disk controller. Preliminary test showed the yellowed and beaten up expansion box was fine with disk functions. However, the unit that had given me the RAM grief showed not the slightest interest in attached drives! I had a non-working disk controller to repair then. It turned out THAT experience made the RAM fix above seem like a Sunday school picnic!! (See Part 2 ...)

Tez
21st October, 2010
Revised, 22nd October

Postscript: After publishing this article I got talking to a few people. It seems that if a X-2040 is being used with an internally expanded System 80 those lines HAVE to be cut to (in the words of System 80 enthusiast Peter Nield) "prevent the data transceivers (Z28/Z30) from being active on the data bus when those memory blocks are addressed for read (!DOEN signal)".

I'd better re-mod my now de-modded original expander and put a sticker on it to the effect of "No RAM expansion. For use with internally expanded System 80s only"!