• Please review our updated Terms and Rules here

Help wanted with Commodore PET 8032: Can't find obscure video fault

P

Phu

Member
Joined
Apr 24, 2009
Messages
21
Hi,

Anders Carlsson has told me that this forum is the best place to ask for help on a rather obscure problem with a Commodore PET 8032 that I can't track down.

At the Retro Computer Museum we have a standard issue PET 8032. From all outward appearances it seems to work fine. At our last open day, it developed a fault around the screen memory resulting in random characters appearing (and being read back by the input routines). I replaced the four 2114 screen RAMs and the problem appeared to go away.

However, anything that causes the screen to scroll causes some characters to be "mis-moved". As if it's not being read correctly before being written back to the preceeding row.

If you run a program that displays rows of aligned text, e.g.

10 print "Commodore PET 8032! ";
20 goto 10

the effect is like watching The Matrix. Random points get replaced with the wrong characters that then proceed to scroll up the screen.

So far, I've replaced five of the 74LS244s buffers associated with the screen memory, as well as 3 74LS157s that concern memory multiplexing.

Can anyone give any pointers as to what to try next?

Any help gratefully received.

Cheers

-- Richard
 
Two out of three of my "Dynamic Pet" motherboards display that symptom to a greater or lesser degree, and I have yet to deduce what is at fault. (other than it appears generally to be something wrong with address generation/multiplexing in the video section.) It's not the video RAM because the same video RAM from one of the boards displaying the symptom will work fine when transplanted to the "good" board.

If I don't come up with any better ideas my plan (once I find the time for it) is to take one of the boards, remove *every* capacitor, and replace them, on the theory that what's happening might be noise or mis-timing caused by something analog rather than a bad digital component. But I'm certainly open to better ideas myself.
 
Richard,
It seems to me that you replaced the right candidate parts. Can you give us some of the 'before' and 'after' characters in case there is a clue in that information.
-Dave
 
dave_m said:
Richard,
It seems to me that you replaced the right candidate parts. Can you give us some of the 'before' and 'after' characters in case there is a clue in that information.
-Dave
Click to expand...

I've also replaced the 74LS373 video latches in case their inputs were faulty and "back feeding" into the RAM data outputs. No joy there either.

The best way to think of it is that when a character goes wrong its "new" ASCII code appears to borrow certain bits from the last output of that particular RAM set (bearing in mind the odd/even column layout of the 8032).

For example, what should be $40 might become $41 because the last character from those RAMs was $21 (though not all the time). Does that make sense?

-- Richard
 
Phu said:
For example, what should be $40 might become $41 because the last character from those RAMs was $21 (though not all the time). Does that make sense?
Click to expand...

That sure seems like faulty dynamic RAMs to me, but those were the first items replaced. Did you check the bias voltages? On the RAM chip:
pin 1 should be -5V (Vbb)
pin 9 should be +5V (Vcc)
pin 8 should be +12V (Vdd)
 
I haven't replaced any dynamic RAMS (main memory), just the screen RAMs (4 off 2114 1K x 4bit static RAMs).

Does the kernal store lines of screen data in main RAM while scrolling?

-- Richard
 
Phu said:
I haven't replaced any dynamic RAMS (main memory), just the screen RAMs (4 off 2114 1K x 4bit static RAMs).

Does the kernal store lines of screen data in main RAM while scrolling?

-- Richard
Click to expand...

I forgot the video RAM chips are static devices. This is really a tough problem. Hopefully someone will have a better idea to try.
-Dave
 
MikeS said:
Good question; anybody know the details of how and where the CRTC models handle scrolling?
Click to expand...

Mike,
I don't think this problem is a function of the CRTC or the character ROM. I think the scrolling is done in software. Here is the segment of code in the editor ROM. It looks like when the screen is full (25 lines), this routine is called to push up the last 24 lines and blank the 25th. The timing for this is exactly the same as any other memory read and writes. And Richard has replaced the buffers and multiplexers that are unique to the screen RAM. Curiouser and curiouser.

Code: 
; -    Scroll Screen

 E3E8    iE3E8    LDX $E0        ; 3+4.40: Screen Line Link Table / Editor Temps
 E3EA        DEX
 E3EB    iE3EB    INX
 E3EC        JSR $E06C
 E3EF        CPX $E1        ; 4.80: last line of window
 E3F1        BCS $E408
 E3F3        LDA $E756,X
 E3F6        STA $C7        ; Pointer: Tape Buffer/ Screen Scrolling
 E3F8        LDA $E76F,X
 E3FB        STA $C8
 E3FD    iE3FD    INY
 E3FE        LDA ($C7),Y    ; Pointer: Tape Buffer/ Screen Scrolling
 E400        STA ($C4),Y    ; Pointer: Current Screen Line Address
 E402        CPY $D5        ; Physical Screen Line Length
 E404        BCC $E3FD
 E406        BCS $E3EB
 E408    iE408    JSR $E1C1    ; -    Clear Screen Line
 E40B        LDA $E812
 E40E        CMP #$FE
 E410        BNE $E420
 E412        LDY #$00
 E414    iE414    NOP
 E415        DEX
 E416        BNE $E414
 E418        DEY
 E419        BNE $E414
 E41B    iE41B    LDY #$00
 E41D        STY $9E        ; No. of Chars. in Keyboard Buffer (Queue)
 E41F    iE41F    RTS
 
As noted earlier, this sounds really reminiscent of something I'm seeing with a couple non-CRTC PET motherboards, and I've been keeping an eye on this hoping a good suggestion comes up. On my affected boards it really seems like the root cause might be some sort of instability in the multiplexing between video address generation (which is of course discrete circuitry on one type of PET, sourced from the CRTC on the other) and CPU-supplied addresses, as the problem manifests as both corrupted characters in the "right" place and characters (right or wrong) being written to the wrong location. You can really see the problem on the one machine by loading a game that does a lot of screen updates, like "Breakout", and playing it for a while. You'll get phantom balls and other characters slowly collecting on the screen.

(My wild guess is that the "corrupted" characters *might* be happening because the address lines might be changing state in the middle of a write, or something.)

It's a little discouraging to see you've replaced all the obvious buffers and multiplexers and are still seeing it. That's why I'm sort of grasping at the straw that it's an "analog" problem. (Noise or glitches from a bad capacitor or something.) Granted I've had no time to really, really dig into it with the logic analyzer.
 
Hi,

Here is a wild guess: On an Atari 800XL (using an 6502 CPU as in the PET) the PHI2 Signal is sometimes very "bad" (means not rectangular), on my 800XL machine the unclean signal did not disturb the normal operation, until i upgraded the RAM to 320kb and it just would not work or work very unrelieable (including screen flickering) ... after i built the small PHI2 referesh circuit described here everything worked OK!
http://www.abbuc.de/~bernd/tipps/phi2.html

Maybe ... but still only a wild guess ;-)
 
I replaced a few other parts out of suspicion last night:

74LS02 at UD1 - this is used in the timing signal distribution, and in particular VRCLK and VRLATCH. No effect.
74LS154 - Generates the SEL signals, of which SEL8 is used in the 74LS42 to select the VRAM for reading or writing. No effect.

I'm running out of chips to replace!

I'm thinking possibly the 74164 at UE3 is up for replacement next. This is an 8-bit shift register in which a logical 1 is walked clocked by CLK1, producing 8 CLK1 phases, which in turn drive the CPU/video timing. I'm thinking that a weak output that picks up the signal from a neighbour might be triggering the video cycle one phase too early or too late, etc.

scouter3d: It's an interesting idea, but I don't think it's the case here. From all other indications, the system is running fine, i.e. no errors in BASIC, runs programs fine, display is stable (no flickering characters) it just mis-copies data.

-- Richard
 
Phu said:
I replaced a few other parts out of suspicion last night:

74LS02 at UD1 - this is used in the timing signal distribution, and in particular VRCLK and VRLATCH. No effect.
74LS154 - Generates the SEL signals, of which SEL8 is used in the 74LS42 to select the VRAM for reading or writing. No effect.
Click to expand...

I would put a scope on the decoder chip UC3 outputs looking for a glitch. One some 8032 schematics the part is a LS138 and on older machines it is a LS42. It generates some key read and write video signals.
 
The 74LS42 has already been replaced once.

I also tried a 7445 that I had spare (which as far as I can tell differs only in the maximum input/supply voltages), but that doesn't work at all.

-- Richard
 
Maby this Thread will help, it helped me waking up my PET
[URL="http://www.vintage-computer.com/vcforum/showthread.php?24898-Frank-s-Danish-PET&highlight=danish"/URL]

/Frank
 
When replacing the chips, be sure to match or better the characterisitcs. Not all TTL chips are the same speed rating? But that still doesn't explain the sudden onset of the problem. It is a good time to start poking around with a scope probe.....
 
Just curious: are all the bits and all the columns involved when the characters change or by any chance is it just the upper/lower 4 bits or odd/even columns that are affected?
 
gv308:

A little bit of history.. at one of our previous events, the PET was working fine, then at some point during the day the display went to pot. Random characters all over the place, characters flicking in out on the screen. Total chaos. It kind of upset Scramble because it was reading the screen back to work out if the ship had collided with anything ;)

It was still running otherwise, so we kind of left it as "extreme scramble challenge".

I took it back with me, and immediately replaced all four 2114 RAM chips. The display cleared right up. I thought I'd fixed it completely, then ran a simple program to fill the display, and noticed the mis-copying.

So I figure at some point something overloaded/drew too much current and took some chips with it. The RAM at least, but also a 74-series chip somewhere in the system.

MikeS:

It isn't limited to one RAM chip, but does seem limited to specific bit-columns. namely, bits 0 and 3 of odd-low, bit 1 of odd-high, and bit 2 of even-low. I don't think there's anything too this though; I think this is just timing tolerances on the individual bit-columns.

-- Richard
 
frank_DK said:
Maby this Thread will help, it helped me waking up my PET
[URL="http://www.vintage-computer.com/vcforum/showthread.php?24898-Frank-s-Danish-PET&highlight=danish"/URL]
Click to expand...

The video on page 3 of that post is almost identical to what I'm seeing! interesting... I shall read further :)

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