Memory problem with PET 2001

[grbrady]

Hi There,

I'm working on a PET 2001-16B (2001N motherboard with "business" keyboard, "CBM 2001 Series" branding on the front label.) After a long time of replacing bad ICs, sockets and remediating corroded solder, etc., it seemed like I had it all working and I was ready to put it back in the case. However, when I put it in the case, instead of showing ~15k bytes free it shows 45 bytes free. When I first started troubleshooting this the problem was intermittent and seemed like tilting the board one way or another would cause it to start up seeing the full complement of memory, which makes me suspect a bad solder joint or other poor connection somewhere. However, I can't seem to find it. All the address lines from the CPU, through the buffers, muxes and resistors seem to have good continuity and I've reflowed all those joints. I've swapped around and replaced the buffers and muxes as well and don't see any change.

I have also probed all of the address and data lines with an oscilloscope and don't see anything terribly unusual. Signals seem to be present where I would expect to see them, although the high logic level is only typically about 4 V, but I think this should be fine for TTL logic.

I've also run PETTEST v.4 on the machine. It got past the countdown and into the memory test, but finds an error shortly thereafter. However, the address and bit at which it finds the error seems kind-of random. Example output from a series of attempts:

mem fail 0 0 02f7 02 42!
mem fail 1 0 0275 80 7f!
mem fail 0 0 206e 20 20!
mem fail 1 0 0275 04 ff!
mem fail 1 0 042e 01 08!
mem fail 0 0 02f7 80 00!
mem fail 1 0 042e 02 09!
mem fail 1 0 042e 02 09!

Looking at this now, I see a few addresses up there multiple times which might be significant.

I have not replaced the memory yet, although I have piggy-backed 4116s on all of the memory chips without any change. Is my best bet to start socketing and swap out the memory? Is there anything more I should try short of that?

Can anyone suggest any strategies for figuring this out?

Thanks,
Greg

[daver2]

As this is your first post, welcome to VCFED...

Don’t forget to put your location in your profile. You may find some knowledgeable VCFED members close by.

Also, your posts will be moderated for a period of time, so there will be a delay between your post and it appearing. The mods. are busy people, and don’t get paid, but it keeps the spam very, very low as a result...

Did you download the PDF documentation that goes with my PETTESTER to enable you to decode the data bit at fault? If not, that will help. EDIT: You did specifically mention bit in your original post...

4V TTL signals are just too low though. They should be 4.75V minimum (ideally).

Have you checked all of the power supply rails for both dc voltage level and ripple?

You have a random smattering of bits (0, 1, 2, 5 and 7) with faulty bits both high and low.

I would checkout the power supplies first and then check the DRAM refresh signal and counters before swapping the RAM. That would be my recommendation at any rate. I will lookup the schematic later...

Dave

[grbrady]

I added a little info on my profile. Also, I did download and read through the documentation, at least enough that I think I understand the output from the memory test error.

The power rails seem good. On a memory IC they are -5.1 V, +12.26 V and +4.99 V. The ripple on the +/- 5 V lines is around 10 mV and is about 30 mV on the 12 V line. At the far end of the board (near the CPU, other regulator than what supplies the memory, I believe) the +5V rail is 5.01 V and the ripple is about the same. Note that all the regulators are new as the old ones were badly corroded and, except for one of the two 5 V regulators, gave crazy voltages. So I replaced them all.

I have looked at the address counters and CAS and RAS signals in the past and didn't see anything too worrisome (other than low logic levels) but I will revisit them.

I was initially worried a bit about the low logic levels, but after a while I felt like I was chasing my tail trying to fix it when TTL spec is above 2.75 V for a high.

Things that I didn't mention that I find concerning but didn't think were core to this problem. When I measure the resistance between Vcc and GND on the socket of an arbitrary logic IC it's usually about 20 Ohms. Not a dead short and the regulators seem to be able supply enough current to keep the voltage at 5V. But, low enough that my meter thinks there's continuity between Vcc and GND. Should that resistance be higher?

Another possible anomaly is that the _INIT line is at a steady 2.6 V when measured at the low side of the pullup resistor R12 (and at the ICs I've measured it at.) This implies to me that the input impedance of at least one of the multitude of flip-flops, etc, that line is connected to is pretty low. Or there's a short in the board somewhere. Or something's trying to pull it low for some reason and can't. I haven't figured out a good way to figure this out, though.

Thanks again for any help,
Greg

[iz8dwf]

4V TTL signals are just too low though. They should be 4.75V minimum (ideally).

That's wrong.
TTL valid High levels start at 2.7V. Often in these old machines, H levels are around 3.5V. 4V is a solid high and perfectly reasonable on mixed 74LS and 74 families.

Frank IZ8DWF

[daver2]

Thanks Frank.

Brain fade - too much turkey and wine I fear .

You are 100% correct about the TTL levels.

I was obviously thinking about the power rails rather than the logic levels.

Dave

[daver2]

So, I have had a look at your error data posted back in #1 in a little more detail - and believe the problem is data reading/writing in a 'semi random' manner.

My testing for errors in pages 0 and 1 of the RAM is not very good - so I am going to introduce a more thorough test of these important memory locations in a later release. Unfortunately, the RAM in pages 0 and 1 can be working good enough to 'fool' the simple test - but not good enough to function correctly with the more thorough DRAM test. Generally, the test itself just fails - but there is the possibility of erroneous error reports - and it is this that I think is happening here...

For example, test 0 fills all of memory with a 'sea' of '0' bits and then checks to see if they are '0'. Conversely, test 1 fills all of memory with a 'sea' of '1' bits and then checks to see if they are '1'.

I would therefore expect a test 0 to return with some '1' bits in the byte reported and a test 1 to return with some '0' bits in the byte reported. At least one of those bits should match with the mask.

However, in some of your error reports this is not the case. For example:

>>> mem fail 0 0 02f7 80 00!

In this case (test 0) we are expecting a 00 byte and a 00 byte was reported. This is correct!

>>> mem fail 1 0 0275 04 ff!

In this case (test 1) we are expecting a ff byte and a ff byte was reported. This is also correct!

During both of these tests - the bit related to the mask (80 for the first case and 04 for the second case) must have read the opposite of what was expected - but it is subsequently reported correctly.

The test reads and detects the error and then reads the memory byte again to report the error. Somewhere in between these two reads the value has either changed, or the original value (the one read to perform the test) misread.

If you now view the error reports with this in mind - you can see a number of other discrepancies with the bits... Test 0 = 00 expected. Test 1 = ff expected.

>>> mem fail 0 0 206e 20 20!

Is this address a typo.? Should it be 026e by any chance.

Just out of interest, during the countdown phase, do the ROM checksums read consistently correct?

The fact that you have actually got BASIC to boot up (but it reports an incorrect amount of RAM) is also a good indication that something is marginal (to my way of thinking).

Starting with the power supply rails (dc voltage levels and ripple) is still a good way to proceed though.

You say you have been 'probing around with an oscilloscope' and looked at the MUX, buffers and RAM. But 'looking' just tells us if a signal is there or not (stuck bit) or looks 'horrid' indicating a faulty bit. Have you tried with (say) a NOP generator to generate the whole address range (in the address bus) and checked that each address line is correct as it traverses through the address buffers and RAM MUX devices?

Incidentally, the MUX and RAM buffers are known to be weak points - as is the 4116 DRAM devices (unfortunately).

Faulty refresh circuitry (schematic sheet 6 of 9) can also be problematic as the DRAM contents can become 'flakey'...

You may want to check the RAx signals and make sure they are all there, count correctly in binary and traverse through the RAM MUXes OK.

Dave

[grbrady]

I've been working on this problem and seem to have made negative progress.

Using the PETTEST ROM I now don't get past the 0/1 page tests and get a screen showing most of that RAM to be bad. The characters shown in the second 256 characters aren't exactly random, but I get a long string of, for example, f's followed by a long string of reverse tone b's, sometimes @'s, sometimes reverse tone f's and regular b's, an occasional d and once in a while a the desired ".".

Regarding Dave's last post

> >>> mem fail 0 0 206e 20 20!
> Is this address a typo.? Should it be 026e by any chance.
No, I checked the screen photo I took and it was indeed 206e

> Just out of interest, during the countdown phase, do the ROM checksums read consistently correct?

The ROM checksums are steady and seemed to be correct the last time I got that far. I will pull them and verify again with my burner. Oh, except for the "B" ROM, which isn't installed on this machine. It fluctuates around a bit.

> Starting with the power supply rails (dc voltage levels and ripple) is still a good way to proceed though.
I had already double checked those and reported in an earlier post. On a memory IC they are -5.1 V, +12.26 V and +4.99 V. The ripple on the +/- 5 V lines is around 10 mV and is about 30 mV on the 12 V line. Near the CPU the +5V rail is 5.01 V and the ripple is about 10 mV.

> You say you have been 'probing around with an oscilloscope' and looked at the MUX, buffers and RAM. But 'looking' just tells us if a signal is there or not (stuck bit) or looks 'horrid' indicating a faulty bit. Have you tried with (say) a NOP generator to generate the whole address range (in the address bus) and checked that each address line is correct as it traverses through the address buffers and RAM MUX devices?

I put together a NOP generator and followed the address lines from the CPU through to the input of the address MUX and got the expected square waves with the frequency increasing by a factor of 2 with each higher address bit. The square waves looked clean and the logic levels went from about 0 to about 4 V. I also looked at the output of the refresh counters and saw generally the same thing up to the MUX. The output of the MUX is more complicated to understand since we're switching between multiple address sources, but it did not look horrid. The _RAS, _CAS and _WE signals all look sensible as well-formed square waves, as well.

What does not look very nice are the data bits between output of the 74LS244 buffers and the memory chips. The signals seem like they're either more or less stuck low or stuck high but with a lot of noise around the nominal logic level. I only have a simple analog scope, so what I can tell here is somewhat limited without being able to sample. However the waveforms look much, much worse than those on the other side of the buffers. To get this far with this board I already had to replace those buffers (old ones were totally dead) so it was easy to swap those as a test, but that didn't help. As another test I socketed and swapped one of the RAM chips (I2, the MSB I think) and it's waveforms seems to be cleaner than the others. I think I'm going to go ahead and socket the other 7 RAM chips. Really, after the number of chips that I've had to remove and socket to get this board this far, it's not a huge amount more work. Between fixing corrosion on the PCB, replacing badly rusted or corroded chips, replacing plain dead chips and replacing wonky sockets, I've probably had to do well over 20 chips so far.

In my last post I also commented on two unusual things. The first was that the _INIT line voltage was quite low, about 2.6V. I traced this to the character ROM. The CS3 pin seems to be trying to pull this line low. I'm not sure if that's by design or not. However, I did pull the ROM and burned another 2716 as a character ROM, but it behaves the same way. Without the character ROM the _INIT line is about 4.9 V. I have no idea if this is expected behavior.

The other anomaly was that the resistance between 5V and GND was only about 20 ohms. Feeling around the board, I found that 2 ceramic 0.1µF decoupling capacitors seemed a bit hot, so I cut the leads to those and the 5V-GND resistance increased to about 50 ohms, still lower than I might have expected, but at least my meter can tell that Vcc and GND are different lines now. Those caps measured about 70 ohms resistance. I can't feel any other suspiciously hot components, but I'm using this as an excuse to get an IR camera so I can look more systematically.

Again, any help anyone can offer is appreciated,
Greg

[grbrady]

Continuing with the trend of making negative progress, now I can't seem to get it to talk to the ROM. I get random characters on the screen. If I use my Tynemouth ROM/RAM board it comes up ok, but I can't get PETTEST or the stock ROMs to work. I've checked the ROMs on my burner and they seem correct.

I'd be happy with the ROM/RAM board driving things, at least in the short term, but since this PET has the "business" keyboard it doesn't seem to read the keyboard matrix correctly.

I'm starting to lose my patience with this thing. I know it's probably something stupid I did, but I just wish I could figure out what! (Or, rather, which of the many stupid things I did are causing problems and which are benign stupid things.)

Greg

I've been working on this problem and seem to have made negative progress.

Using the PETTEST ROM I now don't get past the 0/1 page tests and get a screen showing most of that RAM to be bad. The characters shown in the second 256 characters aren't exactly random, but I get a long string of, for example, f's followed by a long string of reverse tone b's, sometimes @'s, sometimes reverse tone f's and regular b's, an occasional d and once in a while a the desired ".".

Regarding Dave's last post

> >>> mem fail 0 0 206e 20 20!
> Is this address a typo.? Should it be 026e by any chance.
No, I checked the screen photo I took and it was indeed 206e

> Just out of interest, during the countdown phase, do the ROM checksums read consistently correct?

The ROM checksums are steady and seemed to be correct the last time I got that far. I will pull them and verify again with my burner. Oh, except for the "B" ROM, which isn't installed on this machine. It fluctuates around a bit.

> Starting with the power supply rails (dc voltage levels and ripple) is still a good way to proceed though.
I had already double checked those and reported in an earlier post. On a memory IC they are -5.1 V, +12.26 V and +4.99 V. The ripple on the +/- 5 V lines is around 10 mV and is about 30 mV on the 12 V line. Near the CPU the +5V rail is 5.01 V and the ripple is about 10 mV.

> You say you have been 'probing around with an oscilloscope' and looked at the MUX, buffers and RAM. But 'looking' just tells us if a signal is there or not (stuck bit) or looks 'horrid' indicating a faulty bit. Have you tried with (say) a NOP generator to generate the whole address range (in the address bus) and checked that each address line is correct as it traverses through the address buffers and RAM MUX devices?

I put together a NOP generator and followed the address lines from the CPU through to the input of the address MUX and got the expected square waves with the frequency increasing by a factor of 2 with each higher address bit. The square waves looked clean and the logic levels went from about 0 to about 4 V. I also looked at the output of the refresh counters and saw generally the same thing up to the MUX. The output of the MUX is more complicated to understand since we're switching between multiple address sources, but it did not look horrid. The _RAS, _CAS and _WE signals all look sensible as well-formed square waves, as well.

What does not look very nice are the data bits between output of the 74LS244 buffers and the memory chips. The signals seem like they're either more or less stuck low or stuck high but with a lot of noise around the nominal logic level. I only have a simple analog scope, so what I can tell here is somewhat limited without being able to sample. However the waveforms look much, much worse than those on the other side of the buffers. To get this far with this board I already had to replace those buffers (old ones were totally dead) so it was easy to swap those as a test, but that didn't help. As another test I socketed and swapped one of the RAM chips (I2, the MSB I think) and it's waveforms seems to be cleaner than the others. I think I'm going to go ahead and socket the other 7 RAM chips. Really, after the number of chips that I've had to remove and socket to get this board this far, it's not a huge amount more work. Between fixing corrosion on the PCB, replacing badly rusted or corroded chips, replacing plain dead chips and replacing wonky sockets, I've probably had to do well over 20 chips so far.

In my last post I also commented on two unusual things. The first was that the _INIT line voltage was quite low, about 2.6V. I traced this to the character ROM. The CS3 pin seems to be trying to pull this line low. I'm not sure if that's by design or not. However, I did pull the ROM and burned another 2716 as a character ROM, but it behaves the same way. Without the character ROM the _INIT line is about 4.9 V. I have no idea if this is expected behavior.

The other anomaly was that the resistance between 5V and GND was only about 20 ohms. Feeling around the board, I found that 2 ceramic 0.1µF decoupling capacitors seemed a bit hot, so I cut the leads to those and the 5V-GND resistance increased to about 50 ohms, still lower than I might have expected, but at least my meter can tell that Vcc and GND are different lines now. Those caps measured about 70 ohms resistance. I can't feel any other suspiciously hot components, but I'm using this as an excuse to get an IR camera so I can look more systematically.

Again, any help anyone can offer is appreciated,
Greg

[Nivag Swerdna]

Are you able to substitute just $F000-$FFFF i.e. D9 using your ROM/RAM replacement board with your PETTEST ROM in D8?

You might have a bad Kernel ROM? Can you confirm which part# you currently have in D9?

There are other options too... the PET RAM could be contending with the PET ROM... there's not much logic there... B2 and G7 aided and abeited by I10 and I11...

Probably best to work incrementally with the ROM/RAM Board first.

Oh... and although it might be obvious... if you are making -ve progress then maybe you have dodgy/marginal sockets... particular D8 and D9... dodgy sockets or pins that don't register correctly (e.g. pins that get away from you and don't engage properly) are excellent ways to get odd behaviour...

[daver2]

Yes, the only thing that would prevent my PETTESTER from working would be the kernal ROM or an address selection fault.

When you say that you had problems with the voltage regulators, was the output voltage high or low? High could be bad news...

The voltage level of /INIT could be a problem. Having one pull-up resistor for so many ICs is just poor design! You could try reducing the value of this resistor a bit to increase the voltage. You can do this by paralleling the existing resistor with another one - suitably calculated.

Are you able to post a photograph of the oscilloscope trace of the RAM data bus you were seeing?

Be positive, we have got machines in a worse state than yours working... And that was with people who didn’t know anything about electronics before hand. You appear to know what you are talking about! We just have to work out what is going on in a systematic manner.

So, we appear to have good power rails?

Have you checked the /RESET line on power-up to ensure we are getting a healthy reset?

The data sheet for a 2716 states that pin 21 is VPP and this pin can draw 5mA from the supply. This is not a logic pin. On the original ROM it was an active high chip select logic pin... This may account for why the /INIT line is being dragged down. It may also affect the operation of the character generator?

Dave