• Please review our updated Terms and Rules here

Pet 2001N horizontal line

I am desperate because i've seen that i already tested ud2 outputs in previous post!! :(
 
I am afraid I can't suggest anything else...

I have already posted all of the failure modes that I can think of.

All I can suggest is that you haven't correctly identified the fault associated with one of those failure modes (i.e. it is hiding from you).

Unless anyone has any other thoughts that we may have missed?

Dave
 
Can be ud9 kernal incompatible with this pet? 901465-22.bin is correct for this?
 
If you are using the Kernal ROM with my PETTESTER it shouldn't matter which version you use - because my PETTESTER ROM is designed to work with any known PET Kernal ROM.

The only reason my PETTESTER wouldn't work (and the CPU stop executing instructions) is if the Kernal ROM contents became corrupt (or read incorrectly). In this case, this is only valid for a few bytes of the Kernal ROM.

If you have put this Kernal ROM into another (working) PET - and my PETTESTER correctly identifies the checksum as being correct - then this is as good as it gets. Of course, it could be the IC socket the Kernal ROM is plugged into - you were responsible for replacing this item, soldering it and checking the pins for continuity.

Ditto for the PETTESTER ROM itself (and the associated IC socket).

If you transplant the Kernal and PETTESTER ROMs from this (faulty) PET and try them in a (working) PET and they work - then they are good...

Dave
 
If you are using the Kernal ROM with my PETTESTER it shouldn't matter which version you use - because my PETTESTER ROM is designed to work with any known PET Kernal ROM.

The only reason my PETTESTER wouldn't work (and the CPU stop executing instructions) is if the Kernal ROM contents became corrupt (or read incorrectly). In this case, this is only valid for a few bytes of the Kernal ROM.

If you have put this Kernal ROM into another (working) PET - and my PETTESTER correctly identifies the checksum as being correct - then this is as good as it gets. Of course, it could be the IC socket the Kernal ROM is plugged into - you were responsible for replacing this item, soldering it and checking the pins for continuity.

Ditto for the PETTESTER ROM itself (and the associated IC socket).

If you transplant the Kernal and PETTESTER ROMs from this (faulty) PET and try them in a (working) PET and they work - then they are good...

Dave
can i try to desold some logic to test with logic tester?
 
But you have to look at the schematics and come up with a VALID reason for desoldering something and testing it - otherwise you are wasting your time.

With the NOP generator in place the CPU is running OK (indicated by pulses on CPU pin 7). This indicates the clock input and the reset signals are fine. This also likely indicates that the CPU is working. I understand you have used multiple 6502 CPUs and obtained the same result. You have also replaced the CPU socket - so it isn't that.

You have already checked the address buffers C3 and B3 using the NOP generator and your oscilloscope - looking for the correct frequencies on the 'output' side. These buffers must be working...

You should have already tested the 4:16 decoder D2. This takes the high 4 buffered address lines in and decodes these to provide 16 off 4K decodes. If you have tested this correctly (as we have specified) then it is also working.

You should have removed the following ICs: E9, E10, C6, C5 and C7. These interact with the data bus - so removing them means that they can't interact with the data bus any more and confuse our tests.

The only other thing that is sitting on the data bus are the two ROM devices (Kernal and PETTESTER) all of the other ROM devices having been removed. The kernal and PETTESTER sockets have also been replaced (as I understand it).

Pretty much all of the other logic will have an effect on other sub-systems, but not on getting the PETTESTER to work (i.e. observing pulses on CPU pin 7) so doing something with them is all well and good (and you may identify something that is faulty) but I will guarantee that it will not fix the current problem!

The only way it COULD fix the problem is if it is producing noise on the power lines or is drawing a high current - but you should have tested for this as the very first thing you did.

Basically, you will (in my opinion) be wasting your time. But, if you feel that you need to be 'doing' something... In my opinion you should put the PET away for a period of time and then get it out again and recheck all of the things I have asked you to (power supply noise, NOP generator, Kernal and PETTESTER ROMs etc.).

In my opinion, needlessly desoldering ICs may make things worse rather than better. You have been warned.

Dave
 
The only way it COULD fix the problem is if it is producing noise on the power lines or is drawing a high current - but you should have tested for this as the very first thing you did.
How can i do to test this please??
 
Select AC volts on your oscilloscope (a low voltage range) and 'scope each of the power lines.

Keep reducing the volts/div knob until you start seeing noise - noise will always be present - and measure the peak-to-peak value (the highest and lowest voltage). Adjust your oscilloscope trace level to be in the middle of the oscilloscope screen. Positive voltages are then higher than the middle of the screen and negative voltages are lower than the middle of the screen. 0V (of ac noise) is in the middle.

Adjust the oscilloscope timebase to also obtain the maximum amount of noise. Noise appears at certain frequencies - so having your timebase set too fast or too slow will miss it. We are looking for the "inverse goldilocks scenario" (i.e. the worse noise).

There are multiple power rails (2 off +5V, +12V and +5V). I would suggest measuring them all now - although the two +5V supplies are the only ones that would actually affect us with the PETTESTER.

Look for hot devices to see if any device is passing a lot of current. The total can't be excessive, otherwise the voltage regulator(s) would have shut down.

Dave
 
Select AC volts on your oscilloscope (a low voltage range) and 'scope each of the power lines.

Keep reducing the volts/div knob until you start seeing noise - noise will always be present - and measure the peak-to-peak value (the highest and lowest voltage). Adjust your oscilloscope trace level to be in the middle of the oscilloscope screen. Positive voltages are then higher than the middle of the screen and negative voltages are lower than the middle of the screen. 0V (of ac noise) is in the middle.

Adjust the oscilloscope timebase to also obtain the maximum amount of noise. Noise appears at certain frequencies - so having your timebase set too fast or too slow will miss it. We are looking for the "inverse goldilocks scenario" (i.e. the worse noise).

There are multiple power rails (2 off +5V, +12V and +5V). I would suggest measuring them all now - although the two +5V supplies are the only ones that would actually affect us with the PETTESTER.

Look for hot devices to see if any device is passing a lot of current. The total can't be excessive, otherwise the voltage regulator(s) would have shut down.

Dave
Time to leave white flag i suspect :(
 
I suspect the data bus lines. When running the NOP and ignoring the data bus, the CPU runs OK.
I will create a simple binary that runs in the kernel socket. It will perform a ‘walking ones’ test. It will use SEL 9 as a scope trigger. It will do a series of Writes to memory at another empty socket, say $A000. You will have CH1 on SEL A, and CH2 will be used to probe the R/W line and then all the 8 data lines, looking for something suspicious.
You will have to program a 2532 EPROM.

While I am getting the binary file ready, you can perform the AC noise test on the DC power lines.
 
Thanks Dave - I think we used this code elsewhere didn't we?

I also suspect the data bus...

I am currently writing, commenting and documenting BASIC code for work (would you believe)...

Dave
 
Daver2,
Now I’m thinking, the problem may be when Reading the bus. Do you think I should write then read to a RAM location, or reading from a Pettest ROM location with known data pattern like $55?
-dave_m
 
I have just thought of another test that we have never tried before!

Remove ALL of the ROMs.

Use 8 off 1k resistors to connect the data bus of one of the ROM sockets to simulate a NOP instruction ($EA) by inserting a resistor into the associated data line and connecting the other end of the resistor to either +5V or 0V (depending upon whether we require a logic 1 or 0.

NOP = $EA = 1110 1010

With the CPU installed (not the NOP generator this time though - as we have simulated the NOP instruction via the resistors) then we should observe the the CPU generating lots of pulses on pin 7. If not - we can scope the data bus on the CPU and see what is going on...

Dave
 
We have removed the data bus buffers E9 and E10; so that should isolate the DRAM and VIDEO RAM from the CPU/ROM data bus.

If it doesn't - this would direct us to Desperado's soldering...

Dave
 
Right, this will be a good test of bus integrity. If we later try a $55 OP Code pattern, we perform a harmless 'EOR Operand, X' operation and if we get 2.5 V on a data line, we know two adjacent lines are tied together.
 
Back
Top