• Please review our updated Terms and Rules here

PET 4016...the adventure continues!

T

twistedpneumatic

Experienced Member
Joined
Apr 9, 2017
Messages
380
Location
N Bellmore, LI
Hi guys,

Working on my PET again. Borrowed a oscilloscope from school to help out. So far this is the data I've gathered:

UC5 2114 VRAM bad...replaced. Video works fully...ish!
Character gen chip...I think the socket is bad. Every other character shows up wrong, but for example on the all character display screen "b" is corrupted, but on the RAM check screen it is okay. You can see parts of the letter on that screen, other ones look fine. Strangely enough, the RAM screen doesn't have this issue which is why I don't think its VRAM related. Also pulling the chip out and replacing causes different artifacting.
Found a broken connection on RAS between chip 1 and 2, repaired.

Now for what is still wrong: RAM check comes up entirely bad. I checked the address lines, data lines, and control signals for all the RAM ICs, they seem to be working. There are no shorts between any of the address lines either. CAS stays high except for a negative spike every once in a while(few seconds)...not sure if this normal behavior or not? Voltages on all the RAM ICs seem okay as well.

Any ideas where to go from here?
 
How are you testing your PET?

Are you using a PETTESTER ROM of some description or what?

the /CAS line going low ‘once a blue moon’ is not correct (again, depending on how you are testing it). The /CAS signal should pulse low for every RAM read or write access.

Testing for open and short circuits is part of the equation. On the address bus, there are address buffers and on the RAM there are address multiplexers. Any of these could be at fault. I would be inclined to use a NOP generator and ensure you have the correct signals on the address bus and the 4 to 16 address decoder works correctly. You should also be able to use this to checkout the RAM address line multiplexers possibly.

Then try my EDIT ROM PETTESTER replacement.

The ‘every other’ VDU character error could be the video RAM latch for either the ODD or EVEN RAM chips or the control lines driving it (if you have ruled out the video RAM first).

The faulty ‘b’ does sound like the character generator.

i suspect you have a few concurrent faults, so work on one at a time...

Dave
 
Yeah I'm using one of the older versions of pettest2, the one with the 5 second delay because the CRTC code was tacked on the end or something.

I checked the input of the CAS line at the 74LS00, one line seemed to be active, other was dead low. Might need to backtrace from there and see what's going on.

The reason I don't necessarily suspect the VRAM at first is because you can see parts of the characters and they're stable. It's trying to draw the correct characters and failing. I can take a look at the surrounding support chips and see what it looks like there.
 
Here is mine https://drive.google.com/drive/folders/1fyLbr1kcG98a2FDOMo1H5pj9lIdJpHcx?usp=sharing

This fits in the EDIT ROM socket (not in place of the kernel ROM) so there should be no desoldering involved. You will require a 2KB EPROM though.

It has a few more tests than the original... The documentation is in the same location. There is currently one known error in the documentation that I know of - the checksum for the Kernal ROM for BASIC 1 is not correct.

If one CAS line works OK then there is only a DRAM fault, one of the 74LS10 gates in G7 faulty, H2 inverter pins 8 and 9 faulty, the 8K/16K selection link or one of the buffered address lines BA14 or BA13 faulty. Of course, the test program you are running may also not be accessing the second bank of RAM... Page 0 will be within the first bank of DRAM chips - and it may be these accesses you are seeing.

My PETTEST has a ROM checksum routine and a comprehensive RAM test routine. The page 0 ram test is a little minimal at the moment, but I am looking to correct that...

Dave
 
CAS line works on boot, not sure why it keeps deleting my old messages, odd. Also the forum is stuck on mobile mode on my desktop, so thats wierd. Anyway, seems the CAS line is working, just no RAM activity after boot.
 
You might check the address decoder lines to see what address it is stuck at. There are 16 possible places to get stuck.
If you have a digital scope, you can usually see data before the trigger. If you have two traces, you can trigger on that decode and look to see where it was last.
Of course, if it decodes to a ROM address, that can be helpful as well.
Dwight
 
I don't totally understand how you want me to check it? I checked the inputs and outputs of UE8,9,10 and they seemed alright. How can I confirm the bus drivers are working? Also, I have a 2 channel scope...how can I decode 16 lines with only 2 channels?
 
Alternate idea: MUX 2 on that chip is unused, is there any reason I couldn't put a jumper between pins 2&5, 3&6 and 4&7 so that it uses MUX 2 instead of 1?
 
But is that schematic valid for your machine though?

OK, the schematics look similar, but...

So, what you are proposing to do is to parallel up the unused MUX with the faulty MUX. But what happens if the fault is either on one of the input pins of the faulty MUX or the output pin of the faulty MUX? It may not resolve the issue. But, if it is an internal fault within the IC, it may.

Dave
 
daver2 said:
But is that schematic valid for your machine though?

OK, the schematics look similar, but...

So, what you are proposing to do is to parallel up the unused MUX with the faulty MUX. But what happens if the fault is either on one of the input pins of the faulty MUX or the output pin of the faulty MUX? It may not resolve the issue. But, if it is an internal fault within the IC, it may.

Dave
Click to expand...

Looks like all the MUX outputs are dead, which would kill off RAS0 and CAS0, or atleast give false outputs. Also 3 into UE1 is dead as well. Looks like it needs to be replaced. What other chips should I get if I make a Digikey order?
 
twistedpneumatic said:
I don't totally understand how you want me to check it? I checked the inputs and outputs of UE8,9,10 and they seemed alright. How can I confirm the bus drivers are working? Also, I have a 2 channel scope...how can I decode 16 lines with only 2 channels?
Click to expand...

If I have the right schematic. UE-12 is a 74154. It decodes all the blocks of address for the top 4 address bits, A12, A13, A14 and A15. Looking at the decoded outputs, you can see which address block it is currently in. If it is steady there in one block that means it is hung there. If it is pulsing, that means it is going one place that is sending it some place else and bouncing about.
The output pulsing low means it is executing in one place but also fetching in another. If it is a static low, that means it is stuck in one address bank. Each bank of address it 4K of space. If it is stuck in one address space it might be useful to know which it is. If it is stuck it might be useful to see where it was last. You can reset the computer by momentarily shorting cross C50. You can then trigger on the line for UE-12 that hangs low for the low edge and then see what the last place it was at by looking at the selects before it went static. This part assumes you have a digital scope that can sample at the center as opposed to the left edge of the screen.
If the select is jumping up and down, it means it is going one place and then another, either to only fetch code or possibly to look at some other address. In which case you can trigger on what looks like a repeating edge with one probe and then probe the address but to see where it is accessing. ( it make sense to write the address bits down if it is always the same ).
Dwight
 
Sure, I can check that, the only thing is first UE2 is broken so I highly doubt the RAM will even do anything without working control signals RAS0 and CAS0.
 
You must log in or register to reply here.
Back
Top