PET 2001-32N - Diag works in UD9, but with Kernal it fails to start

[dhoelzer]

I'm a bit stumped on this one. I'm waiting on some LS TTL parts to come to replace some marginal components in the video signal circuit on the motherboard, but I have things working well enough that I get a pretty solid composite signal out. I've also decided to move forward with replacing the 9" CRT, which has been nothing but problems, with a 9" LCD mounted in its place (hence the composite conversion).

My problem now is that with the typical PETTEST ROM in place of the Kernal, I had been getting screens of Gs and character sets, no problem. It worked every single time. When I replace the PETTEST with the 901465-03 KERNAL ROM, it fails to start. Strangely, it had been mostly starting (COMMODORE, etc.) a few days ago. Now, when I put back in the PETTEST, I'm getting what you see in the photos, which feels like a bad RAM somewhere? Yes? No? Suggestions? Would that cause Dave's TEST ROM fail to run in the KERNAL slot? I wouldn't have thought so.

At this point I've verified and/or replaced all of the ROMs with freshly written 2516s... The ROMs in there at the moment verify correctly for:

UD6 - 901465-01
UD7 - 901465-02
UD8 - 901447-24
UD9 - 901465-03

I'm stumped as to where to look next. Here's a couple of photos, if it helps.

KERNAL installed:


This can vary a bit in that the @s can be Gs if I have just recently swapped the test ROM in or out.

Clearly wrong test ROM. This was correct this morning, now it is alternating Bs and Gs:


And the other screen of charsets, which also looks wrong.. I don't think it should be alternating caps:


Thanks folks!

 

[dave_m]

At this point I've verified and/or replaced all of the ROMs with freshly written 2516s... The ROMs in there at the moment verify correctly for:

UD6 - 901465-01
UD7 - 901465-02
UD8 - 901447-24
UD9 - 901465-03

I assume you are using 2532 4K EPROMs except for the EDIT EPROM which must be a 2516 or 2716 2K EPROM?

The pettest shows bad RAM in the first 1K. This will prevent boot.

Try daver2's pettest V3. It must be run in the EDIT ROM socket (D8 ). Leave the kernal ROM (D9) in place. You can find it here: https://drive.google.com/drive/folders/1Q2hoJwwgTWz0vUkE7ABqa231ZXItOQWP

If the RAM is good, it goes on the verify the checksums of the ROMs and then lets you test your keyboard.

 

[daver2]

Yes, it looks like you have an alternating data bit fault. The bad/good indicates page 0. The video display indicates screen memory. Unless you have two faulty RAMs? The other alternative is an address to data bus short (or some other type of interaction).

Yes, my test ROM runs in the EDIT socket...

Dave

 

[dhoelzer]

Yes, it looks like you have an alternating data bit fault. The bad/good indicates page 0. The video display indicates screen memory. Unless you have two faulty RAMs? The other alternative is an address to data bus short (or some other type of interaction).

Yes, my test ROM runs in the EDIT socket...

Dave

Yes, sorry, I mis-typed that. I was trying your tester in the EDIT slot with a Kernal in place; it shows about the same screen and fails to start.

 

[dave_m]

As a 'space' is hex 20 and a '@' is hex 40, this shows problems with the D5 and D6 bits. A 'G' is hex 47. As daver2 mentioned, perhaps bad display RAM is confusing the issue.

Thinks to consider before having to replace the eight lower RAM chips:

NOP Generator to check out Address circuitry.
Replace or piggyback the two video static RAM chips (F7 and F8 ).

 

[dhoelzer]

As a 'space' is hex 20 and a '@' is hex 40, this shows problems with the D5 and D6 bits. A 'G' is hex 47. As daver2 mentioned, perhaps bad display RAM is confusing the issue.

Thinks to consider before having to replace the eight lower RAM chips:

NOP Generator to check out Address circuitry.
Replace or piggyback the two video static RAM chips (F7 and F8 ).

Thanks for this. I actually replaced the video RAM with sockets about 2 years ago and have socket new chips in there, so I don’t think that’s the issue.

Thanks for the pointer on 7 and 8. I couldn’t easily see which RAM chips were at issue, so I started replacing from the bottom up. I’m six DRAM chips in with no improvement so far. I’ll skip ahead when I get back from the beach, but I may just move forward with replacing or at least docketing all of them.

 

[dhoelzer]

Great progress. I've now pulled out all of the old DRAM and replaced with sockets and replacement chips. I have two problems at this point:

The keyboard is iffy. I've pulled it apart to clean the carbon contacts, but have discovered that even shorting the contacts is spotty on most of the keyboard and often is the wrong character. I'm assuming this is the 6522? I've tried swapping them but that showed no measurable difference; it may have been worse. I've proactively ordered some Rockwell 6522s.

Here's the test starting:



The second problem is the DRAM test. One test resulted in:


The screen reads: MEM FAIL 3 1 1CEC 01 FF!

After a power cycle and letting it sit, I came back to find it here:


(That reads 01......... PASS 000004.)

I let it sit quite a bit longer and found it at pass 8. I think I may have to sit and watch it to make sure it's not halting.

So, the issues are, The $ hanging around on the screen and the failed DRAM test. If I replace the EDIT ROM, it seems to start fine and no dollar signs. I can't really test keyboard function because of the above, so that remains to be seen. The second issue is the failed DRAM test. How can I translate that output to a chip to try reseating/moving?

The board after the DRAM work:

 

[dave_m]

Good work so far.
For some reason, the way you are attaching the photos are making them small even when you click them.
The keyboard chip is C7 a 6520 PIA. Is that the chip you are swapping?

 

[dhoelzer]

Good work so far.
For some reason, the way you are attaching the photos are making them small even when you click them.
The keyboard chip is C7 a 6520 PIA. Is that the chip you are swapping?

Ah.. For some reason I thought it was one of the 6522s. I have to see if I have a spare 6520 around.

I noticed that. Not sure what I did differently. I'll try again in a few.

 

[dhoelzer]

Well that's interesting. First, it was definitely freezing during the RAM tests.

I managed to get a picture of it running tests. You can see the $ $ in the bottom.

Then I got a failing test... Not sure how to trace this back to a chip...

But since then I am back to failing to start. I just get a random screen and the KERNAL fails to start the test EPROM in the EDIT slot, so that seems to be a DRAM problem again...??? I went through and swapped every chip, no good. Good it be the 74153's? I tried piggybacking, but no change.




Last one... After this, it once again fails to start even after progressively swapping every DRAM chip.

 

[dave_m]

Well that's interesting. First, it was definitely freezing during the RAM tests.

I managed to get a picture of it running tests. You can see the $ $ in the bottom.

A clue may be that a 'space' is hex 20 and a '$' is hex 24. Issue in video RAM data bit 2??

But since then I am back to failing to start. I just get a random screen and the KERNAL fails to start the test EPROM in the EDIT slot, so that seems to be a DRAM problem again...???

You seem to have sockets in ROM area. Perhaps a bad connection? Reflow solder joints.

 

[dhoelzer]

A clue may be that a 'space' is hex 20 and a '$' is hex 24. Issue in video RAM data bit 2??





You seem to have sockets in ROM area. Perhaps a bad connection? Reflow solder joints.

For the video RAM, I've tried swapping the two 2114 chips, but the $ don't move.

As to the EPROMS.. Mmm... I'll give that a look! Thanks! I've never had a good look at those sockets.

I suppose a loose connection on the EPROMs could also make it crash during the RAM test. Any ideas about the failed RAM test?

 

[dave_m]

Any ideas about the failed RAM test?

No, we need to wait for daver2 the programmer. He has not finished the user manual. What he has is on his google drive page. With the RAM test failing, the code does not go on to ROM and keyboard tests.

 

[dhoelzer]

No, we need to wait for daver2 the programmer. He has not finished the user manual. What he has is on his google drive page. With the RAM test failing, the code does not go on to ROM and keyboard tests.

Hmm.. It sort of looked like it was just looping through the RAM test over and over until it crashed.

I'm still at a point where it completely fails to start again. I've tested all of the address and datalines between the DRAM and the buffers and the ROMs and the buffers and it all looks good.

 

[dhoelzer]

Hmm.. It sort of looked like it was just looping through the RAM test over and over until it crashed.

I'm still at a point where it completely fails to start again. I've tested all of the address and datalines between the DRAM and the buffers and the ROMs and the buffers and it all looks good.

More interesting... Powered on this morning after it completely failing last night... It shows DRAM problems again, but starts the tests in the KERNAL slot.

 

[daver2]

Daver2 is on holiday at the moment... Trying to use a keyboard where the Y and Z keys are transposed (on purpose that is)...

I re-used the memory test at work for a project, so I will copy and paste the documentation I wrote into the user manual upon my return.

My EPROM code does not require any form of RAM to be working at all for it to start up.

The first thing it does do is a very simple RAM test on Page 0 and 1 of memory and the video RAM. We need these to work for later. If that works OK, you should get to the point of performing a keyboard and ROM checksum before testing the RAM thoroughly.

Dave

 

[dhoelzer]

Daver2 is on holiday at the moment... Trying to use a keyboard where the Y and Z keys are transposed (on purpose that is)...

I re-used the memory test at work for a project, so I will copy and paste the documentation I wrote into the user manual upon my return.

My EPROM code does not require any form of RAM to be working at all for it to start up.

The first thing it does do is a very simple RAM test on Page 0 and 1 of memory and the video RAM. We need these to work for later. If that works OK, you should get to the point of performing a keyboard and ROM checksum before testing the RAM thoroughly.

Dave

I was at that point, Dave, but it has seriously regressed. Not only won't your tests start at this point, but now the typical PETTEST KERNAL version doesn't start, which seems very bad... and this is after replacing all of the DRAM and getting it to the point where the keyboard looked to be the only think I needed to work on.

I've traced out all of the address and data lines but there seem to be no breaks. The video RAM seems fine, but I have swapped chips to no avail. I spent some time scoping pretty much all of the logic chips on the board, and nothing stands out as non-functional. I'm at a loss as to where to go next. I'm seriously thinking about:

1) Writing some code that jumps from the reset vector to a continuous address/data sweep with some kind of diagnostic probe that I can scope

2) Dragging the logic analyzer up here and seeing what the processor is doing and where it's getting stuck

I have tried swapping the 6502, by the way.

 

[dhoelzer]

A bit of spotty progress. Following the advice of someone else I'm in touch with via email, I checked the ripple on the DRAM supplies. It's hovering between 400 and 500 mv on all three supplies. I replaced the electrolytics on the DRAM supply lines but that actually made the ripple *worse*, so I might have had some cheap capacitors in my drawer. However, while scoping those rails to check the ripple at the DRAM, the PET DIAG started to run with every other character corrupted! I'm going to work to cut the ripple in half and see what that does. My contact is suggesting that my problem might be that the DRAM is too sensitive to the ripple that's present in the circuit at the moment.

 

[iz8dwf]

A bit of spotty progress. Following the advice of someone else I'm in touch with via email, I checked the ripple on the DRAM supplies. It's hovering between 400 and 500 mv on all three supplies. I replaced the electrolytics on the DRAM supply lines but that actually made the ripple *worse*, so I might have had some cheap capacitors in my drawer. However, while scoping those rails to check the ripple at the DRAM, the PET DIAG started to run with every other character corrupted! I'm going to work to cut the ripple in half and see what that does. My contact is suggesting that my problem might be that the DRAM is too sensitive to the ripple that's present in the circuit at the moment.

That one else is me
The symptoms really smell like a data bus conflict probably dependent on A1 address line status. I'd pull the 6520s and the 6522 to see if things get better.

Frank IZ8DWF

 

[dhoelzer]

That one else is me
The symptoms really smell like a data bus conflict probably dependent on A1 address line status. I'd pull the 6520s and the 6522 to see if things get better.

Frank IZ8DWF

I'll try that this morning, but aside from that, I've promised to do real work the rest of the day.