PET 4032 CRT Issue

[daver2]

Ok. That sounds perfect.

For each logic HIGH you should get one complete vertical line of pixels in each column of characters. The image on the screen should be completely stable.

If you pull-down all of the data line outputs, you should have a completely black screen.

If you pull-up all of the data line outputs, you should have a completely white screen.

The more pull-ups you have, the more vertical lines of illuminated pixels you should have.

If you notice in your first picture, you have some slight differences over the screen image.

Dave

 

[dave_m]

The screen is going into inverse video every 128 characters. Is that coming from the msb out of the video RAM?

 

[daver2]

Good thinking Dave!

That now accounts for the odd effects on the first picture as well...

Dave

 

[Hugo Holden]

Good thinking Dave!

That now accounts for the odd effects on the first picture as well...

Dave

Interesting.

I recently made this remark on a Desperado thread:

Of the two PET boards I have repaired so far, I have found that the most unreliable IC's are the 4116 DRAM and the 2114 video SRAM. They seem a lot less reliable, or resistant to the effects of aging than the general 74LS series IC's. Since there are only 2 of the video RAM IC's, it would not be unreasonable to socket them off the bat for this sort of fault (assuming the soldering/de-soldering skills are good) and have known good & tested 2114's on hand.

It does make one wonder when faults like this turn up it might be a good move to socket the video RAM off the bat as it likely would accelerate the repair process. Though I'm not one to want to replace vintage parts unnecessarily, but the PET video RAM appears to be notoriously unreliable and ends up featuring in most PET repairs at some point. These RAMs are a lot less reliable than any of the electrolytic capacitors on the pcb, that get replaced sat the drop of a hat. All of the ones on my pcb were still fine. On the other hand I'm a fan of replacing the Tants if they are there as they have a definite penchant for shorting out.

 

[BrainStruck]

@daver2 @dave_m @Hugo Holden

Ok, so I think I'm making some progress. I made a tool out of perf board to plug into the char ROM socket and use jumpers to pull data pins high and low. Just for grins, I attached photos of the configuration of the tool and the associated screen output. Looking at the top view of the tool in the pictures, the middle row of pins are the data pins and they're laid out from left to right, D0 -> D7. The bottom row is GND, and the top row is +5V.

Moving on to the progress part. I desoldered a few IC's and tested them in my Retro Chip Tester.
UA2 (74166) -> Good (socketed now)
UB1 (74LS74) -> Good (socketed now)
UB2 (74LS74) -> Good (socketed now)
UB3 (74LS373) -> Good (but in rough shape so I replaced it anyway - I don't have any 20 pin sockets lying around)
UB4 (74LS244) -> Good (but in rough shape so I replaced it anyway - I don't have any 20 pin sockets lying around)
UB5 (74LS244) -> Good (but in rough shape so I replaced it anyway - I don't have any 20 pin sockets lying around)
UB9 (74LS244) -> Good (but in rough shape so I replaced it anyway - I don't have any 20 pin sockets lying around)
UB10 (74LS244) -> Good (but in rough shape so I replaced it anyway - I don't have any 20 pin sockets lying around)
UC4 (2411 RAM) -> Good (socketed now, and I ordered new ones anyways)
UC5 (2411 RAM) -> Good (socketed now, and I ordered new ones anyways)
UE14 (7425) -> Bad

I had nothing to lead me to UE14 other than that it was already socketed and easy to get out and test. Low and behold it's bad. UE14 is a quad input NOR gate (DM7425) that controls the chip select on the edit ROM socket. I'm not 100% certain if that's causing the problem, but it seems to me that since it's directly affecting the socket that's supplying the code to paint the screen, it could be painting it wrong and is probably a miracle that I'm getting any video at all. I don't have any 7425's lying around, so I ordered some from eBay, but they'll arrive while I'm out of town for Christmas week, so they'll go in the following week.

This Retro Chip Tester is one of the best tools I've bought.

Brian

PS
Thank you all so much for your help on this!

 

[Hugo Holden]

Hmmmm.......I wonder, the 7425 is one of the more interesting 74 series chips where it has an additional control line which can enable or disable the gate .I would have to look that up. Your tester might be smart enough to know this or it may not. When you get the new 7425 try it out in your tester.

 

[BrainStruck]

Hmmmm.......I wonder, the 7425 is one of the more interesting 74 series chips where it has an additional control line which can enable or disable the gate .I would have to look that up. Your tester might be smart enough to know this or it may not. When you get the new 7425 try it out in your tester.

Sorry for the 6 month lag. Life happened and I had to put the PET away to work on stuff for my job.

The tester said the 7425 was bad, so I had ordered a couple of replacements and it said they were bad too. I'm betting it's just not smart enough to test those chips. I may take a closer look at the datasheet and try to throw together a test rig with an Arduino to test them.

Today I ran desoldered and tested the following chips

UC1 (74S74) -> Good (socketed now)
UC2 (74LS86) -> Good (socketed now)
UC3 (74LS138) -> Good (socketed now)
UD1 (74LS02) -> Good (socketed now)
UD2 (74S04) -> Good (socketed now)
UD4 (74LS10) -> Good (socketed now)
UE7 (74LS10) -> Good (socketed now)

I also probed all of the traces (according to the schematic) for each chip for continuity and everything came back good. As far as I can tell, that's everything that has to do with the video logic. I'm still getting the same screen with the lines on it.

@dave_m What is msb?

Short of going through all of the rest of the logic chips and testing them, I'm not really sure where to go next. Anybody have any ideas?

Thanks,
Brian

 

[daver2]

The abbreviation msb stands for most significant bit.

When used in this context, the msb of the video RAM is used to invert characters (so black becomes white and vice versa).

Let me re-read the thread later to see what is going on. I am a little concerned that you are removing chips to test them though...

Dave

 

[daver2]

Can you just set D0 from the character generator to a '1' and everything else to a '0' and post a photograph of the screen please.

Something is not quite making sense...

Dave

 

[BrainStruck]

@daver2 Here's an image of the screen with D0 pulled high and d1-d7 pulled low.

Thanks,
Brian

 

[daver2]

Thanks, but I am not seeing a vertical line for each character cell on the screen as I would be expecting to observe.

Perhaps check the pins of the E11 (74LS165) next, in particular the logic levels of pins 3-6 and 10-14 first to confirm your board is working correctly and is presenting the expected logic levels to the parallel to serial converter.

If these pins are good, we can then check the dynamic signal pins of E11.

Dave

 

[BrainStruck]

Thanks, but I am not seeing a vertical line for each character cell on the screen as I would be expecting to observe.

Perhaps check the pins of the E11 (74LS165) next, in particular the logic levels of pins 3-6 and 10-14 first to confirm your board is working correctly and is presenting the expected logic levels to the parallel to serial converter.

If these pins are good, we can then check the dynamic signal pins of E11.

Dave

Per your concerns above I've been doing testing with a logic analyzer rather than desoldering and socketing chips.

UE11 is a 74LS00, not a 74LS165 - I tested all of the gates with a logic analyzer and they're good
UE5 and UE14 control the /CS1 line on D000-DFFF based on the output of /SEL-E from the 74LS154 and XBXX (which I couldn't find anywhere on the schematic) and those logic gates tested good with the logic analyzer
UE12 is a 74LS154 - It's a 4 to 16 decoder and it controls the chip selects on the ROM chips. I tested that and the output matches the truth table in the datasheet. Attached is the logic analyzer output.

At ~1.42555s seconds it selects F000-FFFF for 12us, deselect if for 3us, selects it again for 1us. Then it selects D000-DFFF (Edit ROM) for 353us, and cycles it off for 2us and back on for 2us 7 times. The 8th time it holds it selected for 10us, then it starts the pattern over again.

There's no 74LS165 that I could find on the in the BOM. There's a 74LS164 at UE3 and a 74LS145 at UC11. I did not test those. I can tomorrow if you want.

It appears to me that the chip selects are working properly. It must be something on the data bus or the address bus. I pulled both 6520s to try to eliminate things that could be talking on the buses. No change.

Thanks,
Brian

 

[daver2]

I was using the non-CRTC circuit diagram rather than the circuit diagram with the CRTC - hence the part types and circuit IDs are different.

I will put a reference here for my own benefit to remind me: http://www.zimmers.net/anonftp/pub/...4000_Series_4016-4032_Technical_Reference.pdf.

UA2 is a 74166 parallel to serial converter, so the pins to check are 2-5, 10-12 and 14.

Please note that because you have removed the character generator, and installed a little board to drive the outputs of the character generator, the CPU has no purpose (largely) in driving the video output other than to initialise the CRTC.

I am expecting a single vertical bar to appear on the screen for every character cell. The video sense will alternate every 128 characters (assuming PETTESTER is doing it's job and writing the correct characters (repeating sequences of $00 to $FF) into the video RAM). This appears to be the case from the image posted in #30. Bit 7 of the video RAM (LSD7) drives the video inverting gate (UC2 pins 11,12 and 13) via two delay latches (UB2) to account for the different timing from the signals propagating through the character generator.

Incidentally, the EDIT ROM resides in $Exxx not Dxxx.

Dave

 

[BrainStruck]

I tested the 74166 with my chip tester a while back and it tested good. I attached the logic analyzer's output. There doesn't appear to be any data going through that. The sample shows the system clock and the Shift/Load pin going high and low toggling between serial and parallel. Channel 7 is the serial pin and it never goes high.

I tested UB2 and UC2 in the chip tester a while back and they tested good.

I also captured the databus pulse the R/W pin on both video RAM modules. I don't know if I'm doing this right, but I'm reading the databus when the R/W pin goes low. From what I can tell what's writing to the VRAM is hex counting from 0x00-0x0F in groups of 8.
Example
0x00 (8 times) starting at 1.1355225 seconds with about 5us between R/W pulses on the VRAM
0x01 (8 times)
0x02 (8 times)
0x03 (8 times)
...
0x2F (8 times) starting at 3.8000265 seconds
Again, not sure if I'm interpreting that properly.

I can change what shows up on the screen by changing the jumper positions on the board I have plugged into the character ROM socket.

RE: edit ROM addresses, yeah it was late in the evening when I typed that and apparently my brain forgot how to count in hex LOL.

Thanks,
Brian

 

[daver2]

With your little test card in place of the character generator ROM I was hoping that you would just check the eight (8) parallel data input lines to the parallel to serial shift register to confirm that their static logic levels match with your link settings... If they don't, then it is just possible that what is being shifted out is nothing - if nothing is being supplied.

Dave

 

[Hugo Holden]

One thing about the logic analyzer settings, could be wrong, it looks like it is set for cmos which puts the threshold voltages for the inputs of the analyzer at 2.5v. Probably this is ok, most of the time with TTL because a TTL threshold is often around 1 to 1.4V, but TTL logic highs can be very variable in the range of 3V(no pullup) to 5V(with a pullup). And TTL circuits can often have moderate noise on its logic high, unlike cmos. If those noise pulses riding on the logic high in a TTL system extended below 2.5v it could fool the analyzer into believing there was a logic low. Probably best to have the analyzer set on TTL rather than cmos for checking the PET, just in case. The same thing applies to single logic probes.

 

[daver2]

>>> I can change what shows up on the screen by changing the jumper positions on the board I have plugged into the character ROM socket.

Which is fine, but I am trying to detect a unique 'cause and effect'. If you have set your links to $01 as was asked, this should result in 'A' being set HIGH and 'B' - 'H' being reset LOW at UA2 - and we should be able to detect the signal on the bitstream at UA2 pin 13.

If not, there is either something wrong with UA2, the driving clock signals or the surrounding logic.

Assuming you have my PETTESTER running in the EDIT ROM socket on start-up, the test program writes repeating sequences $00 to $FF throughout the video RAM (2K), then reads back (and verifies) 1K of video RAM against (what should be) known data contents.

So, 8 lots of $00, followed by 8 lots of $01, etc. doesn't look correct to me.

I have provided the commented source code for PETTESTER, so you can read what it is exactly doing.

Dave

 

[BrainStruck]

If you have set your links to $01 as was asked, this should result in 'A' being set HIGH and 'B' - 'H' being reset LOW at UA2 - and we should be able to detect the signal on the bitstream at UA2 pin 13.

When you say set links to $01, is that the same as pulling D0 on the character ROM high and leaving the remaining pins low? If so, that's how it's currently set. The image "LA-UA3-at-boot.png" attached to post #34 shown A high and B-H low.

I'll check pin 13 on UA2 tomorrow to see if it's outputting anything.

Assuming you have my PETTESTER running in the EDIT ROM socket on start-up, the test program writes repeating sequences $00 to $FF throughout the video RAM (2K), then reads back (and verifies) 1K of video RAM against (what should be) known data contents.

So, 8 lots of $00, followed by 8 lots of $01, etc. doesn't look correct to me.

Troubleshooting at this level is new to me and Iay be interpreting the logic analyzer output incorrectly.

@Hugo Holden I'll change the settings to TTL and recheck.