• Please review our updated Terms and Rules here

Commodore 3016 scrambled screen

Pin 21 should be a HIGH voltage. It will be an incredibly grotty signal because it is a pull-up resistor connected to too many logic gates.

As long as the voltage is 4V (or more) at the lowest point then that is a logic HIGH.

Dave
 
I am (perhaps) more interested in what your investigation found about the pins of E11 before we look back at F10...

Dave
 
F10 pin 21 is OK then.

This is a curious fault then.

Can you check all of the pins of F10 for activity please. There are a number of pins (such as 21) that are strapped to 0V or +5V. I would be interested in what is either HIGH or LOW (i.e. no pulses on them).

Dave
 
Just another thought. Can you post a photograph of F10 and the area around it please (component side of the board).

Dave
 
That all seems normal there then.

It would also be worth checking that pins 12, 18 and 20 are connected to 0V.

You can do this by connecting the positive lead of your multimeter to +5V (F10 pin 24) and then using the negative lead of the multimeter as a probe onto the specified pins of F10.

This is getting to be a weird fault...

Dave
 
>>> In what case is your pettester not working? Should it always work if there is any power?

This information is in the manual. Unfortunately it requires much more than just the power. It requires the CPU clock. A healthy CPU reset signal. The Kernal ROM (UD9) at least partially working. The EDIT ROM socket (UD8) where the PETTESTER is going to be plugged in working. The VDU subsystem working (it display the results on the screen). It also requires the address decoding etc. to be working. So quite a list... The things that usually go wrong that will stop the PETTESTER working can be simply found with a multimeter and a logic probe. However, there can be some 'nasty' problems (or multiple concurrent faults) that take much longer to find...

The biggest problem with the PET is either faulty RAM or faulty ROMs. My PETTESTER does not require the RAM to be working to perform the initial tests. Likewise, it doesn't require the bulk of the ROMs to be working, just a handful of instructions in the Kernal ROM (UD9).

If you don't get any joy with the PETTESTER to start with, then you revert to the NOP generator and test the address buffers, address decoding and the data bus buffer enable signals.

A number of ROMulator products have in-built ROM and RAM emulation (including a copy of my PETTESTER code) and NOP generator capability. This means that you can get PETTESTER up and working much quicker than in a 'bog standard PET' with an EPROM swap. So, these tools are very useful where the faults are more complex.

The white IC sockets are usually a cause for concern. In this case, printing out the schematics and continuity testing between all the pins of the ROMs (from one end e.g. UD3) to each of the other ROM sockets in turn should identify any problematic pins. You may have to insert a 'dummy' EPROM into the UD3 socket. This works for all pins except pin 20. The NOP generator should have been used to checkout pin 20 of each EPROM. Note that you should only 'lightly' press the probe onto the pin of the ROM. Do not apply too much force, as this could make a non-contact appear as a contact! I would highlight each pin of each socket in turn on the schematic with a highlighter pen as you go. Also avoid too many ROM changes, as this tends to wear out the sockets! Another good reason for using a ROMulator.

Of course, the CPU socket is also white. In this case, you would need to check for continuity from the pins of the CPU IC to where they go to on other devices by following the signals on the schematic. You can (of course) do this for ALL of the devices in white sockets (including the VIA and PIAs). Pour a nice glass of wine (replace with a drink of your choice) and enjoy a nice evening with the schematics and your multimeter!

However, your particular problem appears to be with the video generator logic (independent of the CPU). The video RAMs provide an 8-bit code. 7 bits are passed to the character generator, whilst the 8th bit is the video invert bit. The 7 bit code should select one of the characters within the character generator. There are 8 bytes per character (one byte per line of each character), and these are cycled through a line at a time. The data from the character generator is presented to the parallel to serial shift converter, where it is converted into serial bit form and sent to the monitor. The video invert bit is then applied before the signal is sent to the monitor (as is the video blanking associated with the horizontal and vertical drive).

With random bytes appearing in the video RAM at start-up - there should be a screen full of random characters and each character may be normal or inverse (depending upon the setting of the 8th bit in the video RAM). In your case, the 8th bit appears to be random, but either the lower 7 bits are not random (and so fixed - thus generating the same 'block' character); or somewhere we are losing the data generated by the character generator (or the character generator is being told to produce the same data pattern again, and again, and again...).

Dave
 
Last edited:
Thanx for you're informatiom. I indeed think that i first should check the pins if there is any interruption. Should it be better if i just change the CPU socket into new one?
I noticed that you can easy pull out the CPU out of his socket. It's also a good tip that i should press to much when measuring. I did that sometimes :(
So first i check CPU pins, then UD9 pins and then UD8 pins because Pettester is not working. Maybe i find something there (Bad contact)
 
>>> Thanx for you're informatiom.

No problem at all.

>>> Should it be better if i just change the CPU socket into new one?

It is your machine, it is your choice...

>>> I did that sometimes

This is where experience comes in... Been there, done that!

In fact, you can check the data lines from the CPU directly to UD8 and UD9 because they are all directly connected to each other (via PCB tracks) and do not go via data bus buffers - so that would be a good test.

Dave
 
Something strange happend. When is was testing PETTESTER in other sockets i saw this image when i turned it on in UD5
I copied the screen from your manual, because when i switch it off and on again i didn't saw it again. I only saw the first set of lines.

1684159823048.png
 
That is interesting...

UD5 is responsible for addresses $B000 through $BFFF.
UD8 is responsible for addresses $E000 through $EFFF (or, more technically, $E000 through $E7FF).

$B = 1011.
$E = 1110.

There are two (2) address differences here (A14 and A12).

Either the CPU address bus (or address bus buffers) are not functioning correctly, or the address decoder (UD2) is not working correctly, or there is an IC socket issue.

All of these things should have been identified with the NOP generator...

Perhaps we need to go back to that and re-check this in more detail...

Dave
 
You must log in or register to reply here.
Back
Top