PET cemetery - 4016 repair

[daver2]

Maybe...

It'll keep you out of mischief over the holiday period if nothing else !

You can test the multiplexer ICs out one at a time. In fact, you can check each individual switch out one at a time.

Monitor the select pin, if the select pin is HIGH, one of the inputs will be transferred to the output. Conversely, if the select pin is LOW, the other input will be transferred to the output.

Monitor the select line, the two inputs and output from each switch. Make sure you observe all four (4) different input states (00,01,10,11) with the select line both high and low. Ensure the switch output matches what you would expect from the data sheet.

If this is above your head, let me know and I will explain it more simply...

Dave

 

[SiriusHardware]

Regarding the figures for 40-column CRTC operation briefly discussed in #68, they were arrived at by locating the original setup string in the 'EDIT' ROM for that particular machine. Here is where we found them in that particular case. To complicate matters slightly there are actually two CRTC initialisation tables in the EDIT ROM - I speculate that one is used when the machine has a 'graphics' keyboard and the other is used when the machine has a 'business' keyboard.

The values in this particular EDIT ROM may not completely suit all 40-column machines with a CRTC controller as they were taken from the EDIT ROM of a 50Hz machine - if you are intending to add the ability to select a 40-column CRTC mode in the already excellent Pettester you may want to look at the figures contained in the edit ROM for a 60Hz 40 column CRTC based PET as well.

 

[plagued]

PROGRESS...... I hooked the data logger up to the multiplexers as I only have a 2 channel scope, (which is what I'd used to check they had a signal coming both in and out with)
I checked each pair individually to make my life easer and also hooked up the RAM end of the address line to ensure the signal was getting to the RAM.
UC8 looked OK, UC9 looked ok then I got to SA7 on UC10 and saw:

Where it's clearly treating input 2B as always being low as SA7 just pules high/low inline with the Select rather than having three high in time with 2B....


And now PETTEST is running!! ...... BUT I still have corruption and I still have the back to front characters.
I'm going to have to run off and prevent a divorce for a while so I've not looked into what this means, but the first test screen look OK, but it's on for such a short period my screen hasn't finished displaying the image so I can't really get a good photo, but it looks OK (other then the a@cbed issue)


the second screen seems to have a couple of f's and a slash?
The third screen looks OK, then the keyboard test screen has garbled text and the memory test also has garbled text.....
But I shall go reward myself with a beer for perseverance.
Cheers all for the help so far.

 

[daver2]

Excellent news. One step forward!

So the first screen appearing and disappearing means that PETTESTER wrote a correct pattern and read the correct pattern back. So probably two wrongs make a right!

I would complete all the multiplexer tests.

I think you still have video RAM address problems.

They may be on the video side rather than the CPU side of the multiplexers.

Dave

 

[Hugo Holden]

Interesting, the fault inside that 74157. Mostly when TTL logic fails to respond correctly to an input, the IC die behaves as though the input is stuck high, not low, because the input pin loses its connection inside the IC package to the die. But in this case it was behaving as though the input was stuck low (I have never seen one do that until now) so it must be an entirely different mechanism of failure where something has damaged the IC die.

 

[plagued]

I'm fairly surprised at the number of failures on this board so far. I may have a look to see if there's a common connection between the failed components to suggest a power spike. I didn't power it up until I'd replaced/rebuilt the PSU, replaced the corroded components and cleaned the board. Apparently it had been put away working ... but it does feel like perhaps the previous owner just had a quick go to see if it powered up by plugging it in. It's possible the 12v from the RAM made it onto one of the data lines. I recently rebuilt a missile command board that had 34 failed components from an AR2 power spike, and with that board the spike appeared to jump over some components which made mapping out the failure impossible. In the end it would have been WAY quicker to pull and socket the whole board .... but where's the "fun" in that
It would be helpful to know what the minimum components needed to boot the system are, so I can try and isolate the boot issue with the original ROM. For example do I need the serial controller chips, and all the roms. I don't need it to fully boot, just initialise the CRTC like the PETTESTER ROM is doing. I've had a little dig about with A0 which in my head would be the most likely contender for the flipped characters due to the fact that they're flipped every other one character not every 4 or 8 etc. But so far nothing seems unusual.

 

[SiriusHardware]

There are 4-bit buffers in the data path between the CPU and all of the video RAM - it would be a highly unusual failure mode, but what if a buffer in the data bit-0 path between the CPU and the video RAM has suddenly decided to start inverting data instead of merely buffering it?

i.e, UB4, specific to the 'Even' screen RAM which is the only video RAM bank fitted in a 40-column machine, or UB10, the lower main data bus buffer.

 

[daver2]

If we find this as a fault, do the national lottery quick!

It looks like the main RAM is OK, as PETTESTER seems to be getting through to the DRAM test.

I think we are just left with the video problem. It is interesting that we have an 'f' and a '/'. I will have a look at what characters these should be (when I have finished my chores list for today).

I am thinking of a 'slow' signal edge somewhere that is 'smearing' a logic '0' or '1' from one character position to the next.

The errant 'f' should be a 'g'.

Dave

 

[plagued]

The original roms don't initialise the CRTC at all, so I was under the assumption that I probably still have two + issues rather than just something on the video side.
Buffers are a likely issue for the sole reason that (possibly due to a curse) I nearly always have to replace one, and no matter what, it's always the last one I end up pulling.

 

[daver2]

When we sort out the video problem, PETTESTER will pinpoint any ROM problem for us!

If you don't have a DRAM problem, consider yourself very lucky...

For it to be a data buffer, it has to be an 'intelligent' fault (as post #87 was stating). This is a very low probability event, but it is still not 0.0!

One simple test I forgot is to remove the video RAM and wire the address pins (on the video RAM sockets) to the data pins. I am out on a walk at the moment, but I will post the details when I get back home.

This is definitely a weird (but interesting) fault. Possibly not for you though! You just want the darn thing fixed and working...

Dave

 

[daver2]

On UC4:

SA0 to ESD0
...
SA3 to ESD3

On UC5:

SA4 to ESD4.
...
SA7 to ESD7.

If this gives us the correct pattern, the fault must be in the video RAM.

Another possibility I thought of on my walk was the 8 bit latch after the video RAM (UB3). If there is a short circuit between pins 2 and 3 (on data bit 0) the latch is not doing its job.

Dave

 

[Hugo Holden]

There are 4-bit buffers in the data path between the CPU and all of the video RAM - it would be a highly unusual failure mode, but what if a buffer in the data bit-0 path between the CPU and the video RAM has suddenly decided to start inverting data instead of merely buffering it?

i.e, UB4, specific to the 'Even' screen RAM which is the only video RAM bank fitted in a 40-column machine, or UB10, the lower main data bus buffer.

It is hard to understand how a signal could end up inverted as a failure mode, the only one I could think of as plausible for most TTL is that sometimes the failures behave as though an input is stuck high when actually isn't and therefore if a signal was passing via an XOR gate and that input was supposed to be low that would invert the signal if high, but I don't think that scenario would apply here.

If a pulse arrived earlier or late with respect to another or some sort of smear effect as Dave suggests more likely or perhaps simply an output stage failure in a gate where it logic level was borderline and indeterminate close to TTL threshold and due to other bit patterns sometimes being interpreted as an opposite state. With that in mind it would be worth carefully examining the output switching levels in the area to see if any if them looked abnormal.

One thing I noted with DRAM failures: you can have failure scenarios where the output of a chip is interpreted low and other times high, because Commodore didn't use pull up resistors and their outputs actually cross the logic threshold level for the buffers over a time period, and can also be sometimes interfered with by chips in the other bank. I reported these effects on page 11 &12 of this article and it showed up in the chip failure analysis.

https://www.worldphaco.com/uploads/DRAM%20MEMORY%20TEST%20SYSTEM%20FOR%20THE%20DYNAMIC%20PET%20COMPUTER.pdf

 

[daver2]

I ought to clarify that by 'short circuit' in this context it could be an external short circuit (because the two pins - 2 and 3 - are physically next to each other) or it could be that the internal latch is acting as a 'short circuit' (i.e. not obeying the clock and just passing the input to the output).

Dave

 

[Hugo Holden]

I ought to clarify that by 'short circuit' in this context it could be an external short circuit (because the two pins - 2 and 3 - are physically next to each other) or it could be that the internal latch is acting as a 'short circuit' (i.e. not obeying the clock and just passing the input to the output).

Dave

A short circuit between adjacent IC pins is not all that uncommon, I have seen it a few times, the usual cause is a Tin Whisker, very hard to see with the naked eye. I had one of those on the Yang computer board.

Also, there was that very unusual case where another PET board that Desperado had, it had multiple chip failures as if the board had been over voltaged or had reverse polarity applied, and in one case, one of the logic IC's (think it was a 7400) had two of the input pins on one gate actually shorted together internally, which means the die must have partially melted. I had never seen that before with a TTL IC.

 

[daver2]

I have just spent a little time looking at the g . f and / character issue.

You should have 256 'g' characters followed by 256 '.' characters followed by a further 256 'g' characters again.

The last 'g' (in the first block) has been converted into an 'f' character.

The last '.' (in the first block) has been converted to a '/' character.

'g' = $07.
'f' = $06. Notice data bit 0 is a '0' and not a '1'.
'.' = $2E.

'.' = $2E.
'/' = $2F. Notice data bit 0 is a '1' and not a '0'.
'g' = $07.

Notice (in both cases) there appears to be an interaction of data bit '0' between what the character should be and what it turns out to be (based upon the character that follows it).

In the first case, the character should be a 'g' = $07. It turns out to be an 'f' = $06. The following character is a '.' = $2E (which just happens to have data bit 0 as a '0').

Likewise, in the second case, the character should be a '.' = $2E. It turns out to be a '/' = $2F. The following chapter is a 'g' = $07 (which just happens to have data bit 0 as a '1').

Either data bit 0 of the faulty character is accidentally being written with the inverse logic, or what is being displayed at the transition from a D0 logic '0' to '1' (or vice versa) is 'bleeding through' from one character cell into another.

As D0 is alternating in the PETTESTER test pattern, this could also account for the 'a@cbedgf' pattern observed.

In the PETTESTER page 0 and 1 memory test (however) we should get a string of 'g' characters followed by a string of '.' characters (assuming the main memory is working). The video data bit patterns are all the same up to the point where the character transition occurs. This is where we appear to get the fault.

Whilst D0 is constant, we get the correct character displayed. As soon as D0 transitions from a logic '0' to a '1' (or vice versa) - a fault occurs.

Either we have a slow video RAM on ESD0 - or there is something suspect somewhere in the ESD0 path. Possibly capacitive coupling (partially conductive flux?).

Dave

 

[plagued]

On UC4:

SA0 to ESD0
...
SA3 to ESD3

On UC5:

SA4 to ESD4.
...
SA7 to ESD7.

If this gives us the correct pattern, the fault must be in the video RAM.

Another possibility I thought of on my walk was the 8 bit latch after the video RAM (UB3). If there is a short circuit between pins 2 and 3 (on data bit 0) the latch is not doing its job.

Dave

not sure what the correct pattern should look like but this is what I get:

I pulled and tested UB3 and tests ok and there's no shorts.
Regarding the main DRAM I'd already identified issues with them and ended up pulling them all. 5 of them were faulty They have been replaced with 4164 with the 12v rail replaced with 5v and the -5v removed. All DRAM tested good and I checked for shorts and routing when replacing them all, so I'm fairly hopeful the DRAM is OK, I'm still not 100% that the SRAM is fast enough, although I have tried two sets of tested good 2114 that "should" be the same speed. I forgot to order some replacements from a reliable source.

 

[daver2]

That pattern is not correct. You should get multiple copies (circa. 4) of the entire 256 byte character set.

Perhaps you have misunderstood my shorthand?

Can you post a photograph of your links? There should be four (4) links in UC4 and four (4) links in UC5.

Dave

 

[plagued]

oopse ... yea sorry, completely misread that. And I've not even started drinking ... which reminds me I'd better get a beer.

With all four wires connected ... rather than two we get the same issue with the reversed characters.

edit... quick poke and we definitely have an issue on SA0-ESD0 removing all the other lines and the character set changes dramatically, like remove the SA7 and it inverts everything. If you remove the SA0 link though and half the image stays the same but every other character is corrupted, not a valid character

 

[plagued]

for reference, this is SA0-ESD0 link removed

 

[daver2]

We know it isn't the video RAM now and our problem is associated with SA0/ESD0 as you state.

With the link removed, that should rule out SA0, unless it is interacting with something it should not be.

It would be worth trying ESD0 with a 100 Ohm resistor to first +5V and then 0V to see if we can flush something out.

With ESD0 disconnected, it is floating around and could be picking up noise.

Post a photograph of ESD0 at 0V and the ESD0 at +5V.

Dave