• Please review our updated Terms and Rules here

Commodore 3016 scrambled screen

I am a little confused.

Are you telling me there is permanent activity on both UD8 AND UD9 pin 20?

Hang on a minute - have we still got the NOP generator in circuit?

Dave
 
UD9 trace looks good - but it shouldn't be like that if the PETTESTER ROM is actually running. UD9 should be accessed immediately after a reset (for a few instructions) and then stop.

The lower (cyan) trace is a mess! What is the actual voltage of that cyan trace? I can't see whether it is a HIGH, LOW or indeterminate voltage.

Dave
 
I am starting to think that UD6 (901465-01) is defect.
I tested it with the RetroChipTester for checksum against checksum from bin files in zimmers page.
Every test give different checksum. Others give same checksum every test and is the same as zimmers bin files.
Does it make sense that UD6 is defect?
 
I used two 'tulip' sockets, with pins soldered together, and made a NOP Generator that way. The 6502 clearly plugs into the top one and the bottom has those pin headers with the right pin-width to go into the socket on the board. Even then, I plugged another duel-leaf socket into the one soldered into the motherboard to protect it.

The end result is this "Tower of Power" :)


View attachment 1256832

View attachment 1256833
I bought one of these as it was too cheap to bother making one myself

 
>>> Does it make sense that UD6 is defect?

ROMs can fail in such a manner that they drive the data bus when they are not selected. This causes a bus contention situation to occur as the correct ROM is selected, but the content read out is corrupted by the errant ROM.

However, in this case, I would have expected to have seen some evidence on the oscilloscope of the bus contention. Just wondering whether you have missed it.

If I couldn't get the PETTESTER to work, my next step would be to remove ALL of the ROMs except for the Kernal ROM and the PETTESTER EPROM.

There is also a variant of my PETTESTER designed to replace the Kernal ROM.

If the checksum keeps changing, then it is duff anyhow...

Dave
 
UD9 is indeed the Kernal ROM - and UD8 is where the EDIT ROM would normally site (and should now be occupied by the PETTESTER EPROM).

That doesn't look like either a 'random' screen or a PETTESTER screen...

I am guessing that this is really a 'random' screen - but only the 'inverse video' bit is being used - with the remaining bits of the video RAM ignored for some reason.

The usual rules apply:

1. Check CPU pin 7 for signs of pulses (the CPU is still executing code).

2. Check UD9 and UD8 pin 20 for signs of activity. UD9/20 should be permanently HIGH whilst UD8/20 should have lots of activity.

3. Check E7 and E8 pins 1 and 19 for signs of activity.

4. Check E9 and E10 pins 1 and 19 for signs of activity.

The above will make sure that PETTESTER is actually trying to test the video RAM, or whether it has gone off into the weeds!

Onto some debugging with the video circuitry:

1. Check F9 pins 2, 19, 5, 16, 6, 15, 9 and 12 for signs of activity.

Dave
 
Hang on a minute - you haven't removed the character generator ROM by accident have you (F10).

That would give you the same screen display as you observe...

Dave
 
Ok, we can do some debugging tomorrow to see why we have no video data from the parallel to serial shift register.

Did you do the checks I suggested in post #70?

Dave
 
Ok, so the next checks would be as follows:

E11 pin 1 - a brief pulse at a frequency of 1 MHz.

E11 pin 2 - an 8 MHz clock.

E11 pins 9 and 7 - signs of activity (other than permanently HIGH or LOW. These pins are the video dot (pixel) outputs. One active high and the other active low.

E11 pins 3, 4, 5, 6, 10, 11, 12, 13 and 14 for signs of activity. These pins are the parallel data from the character generator.

Can you also check F10 pin 21 for permanently HIGH and pins 6, 7 and 8 for signs of activity.

Dave
 
Yes, but what voltage is the lowest part of the signal? I don't know where your ground reference is.

Dave
 
Back
Top