• Please review our updated Terms and Rules here

DOA PETs. (2001-8, 4032 and 8032)

Eudimorphodon said:
I'll see if I can get my hands on a replacement CRTC. I think I've found a local source.

I'm still worried about the results, or lack thereof, of the experiment to try to drive the 8032's monitor with a 4032 motherboard that *is* producing video. (Garbage though it may be.) I suppose it's perfectly possible that machine might have both a dead CRTC and a dead monitor. (Perhaps I need to gather the parts for a composite video adapter.)
Click to expand...

Ah... I missed that part of your diagnosis... that is troubling. Do you see any glow at all on the CRT neck?
 
The CRT neck is glowing (although, and this is an unscientific observation, it seems a little bit more sickly-yellow than I remember the back of a CRT looking.), and I can hear a sort of static "whoosh" when I turn the machine on. (The face of the CRT takes on a static charge.) But I don't see any sign of brightness on the screen, either a generalized glow or a dot, and I don't hear/see any sweep activity regardless of the position of the brightness knob.

Of all the things that might be wrong with it I *really* hope the picture tube isn't damaged.
 
Eudimorphodon said:
The CRT neck is glowing (although, and this is an unscientific observation, it seems a little bit more sickly-yellow than I remember the back of a CRT looking.), and I can hear a sort of static "whoosh" when I turn the machine on. (The face of the CRT takes on a static charge.) But I don't see any sign of brightness on the screen, either a generalized glow or a dot, and I don't hear/see any sweep activity regardless of the position of the brightness knob.

Of all the things that might be wrong with it I *really* hope the picture tube isn't damaged.
Click to expand...

I am usually pretty adept at hearing the squeal from the horizontal output circuit myself, and IIRC I never could hear mine. The fact that you have the tell-tale static charge on the surface of the CRT seems to indicate that you do in fact have HV output to the CRT, if anything briefly.

Some monitors have some HV protection that will shut them down, so I wonder if maybe that's what's happening here. Looks like the schematics have a lot of voltage probe points and input waveforms. Do you have a scope?
 
We seem to be all over the place; when you first checked the video connector you said there were *no* signals at all; is that still correct (and did you check the other side of the buffers as suggested)?

You obviously won't get anything on the monitor without any drive, so I wouldn't spend too much time worrying about the monitor until you're sure you actually have something to display.
 
MikeS said:
We seem to be all over the place; when you first checked the video connector you said there were *no* signals at all; is that still correct (and did you check the other side of the buffers as suggested)?

You obviously won't get anything on the monitor without any drive, so I wouldn't spend too much time worrying about the monitor until you're sure you actually have something to display.
Click to expand...

He did say he tried the 4032 board that was displaying garbage video on the 8032 monitor and got nothing with it. But I think you're right... one problem at a time.
 
geoffm3 said:
He did say he tried the 4032 board that was displaying garbage video on the 8032 monitor and got nothing with it. But I think you're right... one problem at a time.
Click to expand...

Yeah, I agree. I just mentioned the "try this monitor on that" experiment because it was one of the first things I tried *way* back when I was first trying to triage the machines. I don't think I've seen a definitive answer on whether it should even work so I'm going to ignore the results. (They just happened to not be reassuring.)

I haven't had a chance to go back and do any more "probing" on the systems this week. (Currently the plan is that Twylo will be coming over this Friday with some test equipment and perhaps by the end of the night we will have made some progress.) The "psuedo-scope" I have instead of a real oscilloscope is out of its league to poke around inside the monitor, which is why I haven't even fathomed messing with that until I'm pretty darn sure I have a video signal from the 8032's motherboard for it to display.
 
Nama...

I've followed your link, and that sounds like a great thing to look at. I've found the resistor in question on the parts layout and schematic on Zimmers, next time I have the thing open I can at least try a continuity test across it.
 
Results of troubleshooting party

Results of troubleshooting party

Twylo dropped by yesterday night and we spent the better part of five hours poking and prodding the sick 4032 and 8032. I thank him very much for his efforts and the loan of an 80mhz analog oscilloscope for further testing. Unfortunately we didn't manage to hit pay dirt on either machine.

This post is about the 4032. (I don't have the time to detail everything we did in one go.):

The first and most obvious thing we attempted on this machine was to substitute a known working set of ROMs from an identical 4032. (Twylo's.) Unfortunately there was no visible change in the system's behavior.

Various and sundry attempts were made to change the system's behavior, including piggybacking new 2114 RAM chips on the existing ones. Piggybacking on the second chip appeared to change the exact garbage being displayed, but don't appear to have gotten the machine any closer to booting. After that we chased several avenues related to the video system, noting that shortly after the system is power cycled the garbage on the screen changes. We've verified that this change is attributable to the character generator being switched from one character set to another by comparing the characters before and after the change to the chart here:

http://www.atarimagazines.com/compute/issue26/171_1_ALL_ABOUT_PET_CBM_CHARACTER_SETS.php

(The character generator is changing from the "alternate" set to the "standard", going by the terminology on that page. Does anyone know if this might be a normal part of the initialization cycle, and might be taken as a sign that the CPU is succeeding in executing at least some way into the ROM code?)

The next step was probing/connecting a small logic analyzer to various places on the video RAM memory bus, my idea being that perhaps we might be able to find some indication of whether the CPU was ever attempting to write to video. It *appears* we were able to verify that the output half of the video circuitry is working to the extend that data is being fetched to refresh the screen (IE, the junk on the screen at least appears like it may be coming from RAM).

(But there are possibly some reasons to be skeptical. The junk displayed on the screen is *very* but not entirely consistent between power cycles. We don't know if this might be just the static rams roughly "favoring" a given bit pattern on power up, if there might be bits stuck, or if the screen pattern might be the result of the computer attempting to clear the screen and the result being systematically garbled.)

Attempting to determine if the CPU were writing to RAM was another problem. We traced the path from the CPU bus to the video RAMs through the intervening buffers and tried getting a trace in the logic analyzer, and the results seemed very garbled. We attached probes from the analyzer to both sides of a given buffer for a given data line and powered on the machine, assuming we'd see a similar pattern from the two sides. Instead we got a very noisy trace with peaks of various widths. We don't know if what we're seeing is actually indicative of a problem with the buffers or our methodology/the probe... Twylo said he may try running some similar traces on his working 4032.

Another thought I had involved some documentation about the "Killer Poke", IE, how the PET stops itself from writing to video RAM when it's not in the blanking period. I wasted some time chasing through the schematic to see if this was actually imposed in hardware. (IE, if a write attempt inside the active display area would halt the CPU or otherwise physically block it. My thought was if that were "stuck" it might be halting the CPU when it attempted to clear the screen or put up the basic prompt.) I eventually found a theory page that explained it was a software loop in the output routines that looked for status on one of the VIA pins, so we checked that pin to see if it were cycling. It is, at what appears to be the appropriate rate.

So... overall, we seem to have eliminated a few things that it's *not*, but we don't seem immensely closer to determining what it is, which is of course a little disappointing. Sigh.

(Suggestions are of course welcome. The apparent "noise" we observed downstream of the data bus buffers between video RAM and the CPU has me wondering if it might be worth replacing some components in that area. System RAM isn't ruled out either, although I did piggybank the bottom 16k with no behavioral change. I'm also planning to try to poke the appropriate place to see if the machine is scanning the keyboard matrix. The idea to try that came too late in the evening to pursue. But... sigh. I'm still in way over my head here, apparently.)
 
MikeS said:
Which chips are socketed? I take it the video 2114s are not?
Click to expand...

Only chips socketed are the ROMs, the 6502, the VIA, and PIAs. (We didn't get to the point of attempting to desolder anything and replacing it.)

If one (or both?) of the 2114s were bad I'd still expect the computer to get to the BASIC prompt... wouldn't it? (Which would at least mean I'd get "changing garbage" on the screen when the BASIC prompt goes up and someone bangs on the keyboard? Unless both of them were completely unable to accept a write request and actually have it change the outputted data, I guess. I did for the heck of it try blind-typing "load" to see if it would activate the motor of an attached cassette drive with no results. Unfortunately I don't actually know if the cassette drive I have is good, nor whether I can type "LOAD" successfully.)

Now that I have a chance to page through the schematic while typing... the area where we were probing with the logic analyzer and getting seemingly "messy" results was on the 74LS244 chips at E7 and E8 on sheet 8 of the schematics. (Page number based on schematics from the "Commodore 4000 Series Technical Manual".) Our expectation was that we'd see similar activity on the "SDx" lines on the inside of those buffers as we see on the matching outside "BDx" lines going to the upstream buffers on page one, E9 and E10... and actually, now that I squint at the schematic that was probably a failed assumption. (Unfortunately neither of us working on this are EE's. Tywlo's a lot smarter at this than I am, don't get me wrong.) To get a trace to determine if the machine were attempting to write to VRAM we probably should of traced... an inside data pin, and outside data pin, and pin 19? Otherwise we'll just be hearing what's going on when the computer's hitting main *or* VRAM on one side and whether the VRAM data bus is active on the other.)

Are you thinking I should try replacing the 2114s just for the heck of it and see if they could both be bad?

It's *really* frustrating not being able to get a good idea whether this thing has a real heartbeat or not. Looking at the schematic my latest idea would be... looking at schematics sheet #3, probing lines... 2 through 5 on the C7 PIA and see if they're cycling? It *appears* to me that those are triggered by the keyboard driver to do row select on the keyboard matrix through C9, a 1 out of 10 decoder? If they're not cycling the machine wouldn't be reading the keyboard?

I find myself coming back around to that idea of burning an EPROM which does several identifiable things in a loop and subbing it for the Kernal ROM, but heck knows how long that will take and whether it'd actually help me find the problem. I really wish this technical manual had some "theory" pages to go along with all the photocopied schematics.
 
And about the 8032...

And about the 8032...

After giving up on the 4032 for the night we tried poking the 8032, and Twylo was thinking it might be closer to alive.

We started by looking at monitor connector. It turns out I was incorrect in thinking that there wasn't "anything" present there... I was on crack and full of fail when it came to the Horizontal and Vertical sync signals. Those are present and appear to be pulsing at at least close the correct frequencies. There is however nothing present on the "video" pin.

Working from the other end we did some basic tests on the 6545, and determined that it is at least cycling the address bus and otherwise giving indications of life. Since the 6545 doesn't actually generate the dots we then started tracing from UA2, the 74166 shift register hanging off the character decoder ROM's data pins. (Sheet 8 of 11 on the "Universal Board" schematic set.) Pin 13 showed output pulses. We then traced those to the input (pin 12) and output (11) on 7486 UC2, and again through 74574 UC1. ("in" pin 12 and "out" pin 9). Then at 74LS10 UD4 we see those input pulses on pin 1 but absolutely no activity on output pin 12. We traced the other two inputs on that 3-way NAND gate, pins 2 and 13, and also saw active pulse activity, and while we can't say definitively that the truth tables didn't always add up to "no output" we're very suspicious. I'm going to attempt to lay my hands on a 74LS10 and replace it, to see if doing so creates activity on the video output line.

We did some very ginger poking at the monitor itself, since there's also that lack of any sign of luminance in the monitor. I followed Nama's link about repairing a monitor for a PET 64 that seemed to show similar symptoms, but the details are a little sparse. We were unable to determine the component type nor value for resistor R752 from the schematics. (It's on sheet 321448. The resistor is stuck in a place that not only makes it hard to interpret it's value its label also appears to be obscuring a circuit connection.) A continuity check across it appears to indicate extremely high resistance. (On the order of 8 Megohms.) Unfortunately neither Tywlo or I (*especially me*) qualify as a TV repairman.

So... that's where we are there. I'm going to try to get a 74LS10, and if changing that creates a video signal but the monitor stays dark I guess I'll either try cross-connecting to the 9" PET's screen again, or... perhaps I can make one of those composite video adapters.

On the slim chance that works I'm wondering if there exists anywhere an 80 column EDIT ROM for graphics keyboard so I could simply stuff the 8032's board into the 4032's case and call it a job poorly done. But I'm not holding my breath.
 
Last edited:
I don't see any 80 columns graphics keyboard editor firmware on Zimmers FTP, but based on my recent experiments I think it is a matter of hex editing to create one? At least it was a matter of hex editing to rearrange the mapping within a 40 column graphics keyboard, but perhaps more work to produce an editor ROM that understands the other kind of keyboard than intended. In any case, it sounds like a job for the VICE emulator before starting to burn EPROMs.
 
Eudimorphodon said:
On the slim chance that works I'm wondering if there exists anywhere an 80 column EDIT ROM for graphics keyboard so I could simply stuff the 8032's board into the 4032's case and call it a job poorly done. But I'm not holding my breath.
Click to expand...

Why do you want 80 columns with a 9" display? Wouldn't a an editor ROM for a 40 column, graphics keyboard and CRTC be a better choice (901499-01)?

I'm not even sure that would work. Has anyone ever used a CRTC universal board with a 9" screen?
 
dave_m said:
Why do you want 80 columns with a 9" display? Wouldn't a an editor ROM for a 40 column, graphics keyboard and CRTC be a better choice (901499-01)?
Click to expand...
Well, either way it's heresy but yes, I'd think if you must, then converting the 8032 to a FAT40 would make more sense since it's a straightforward conversion and lets you use the vast majority of PET software that was written for a 40 column screen. But don't be so quick to give up.

I'm not even sure that would work. Has anyone ever used a CRTC universal board with a 9" screen?
Click to expand...
It's not very stable and the screen is offset and wrapped, but I suppose the CRTC could fairly easily be reprogrammed.

BTW, disconnecting the video signal (while leaving the syncs and grounds) should give you a reverse blank screen (all green except for border, with retrace lines) if the monitor is working; remember to turn up the brightness.
 
Last edited:
Eudimorphodon said:
Only chips socketed are the ROMs, the 6502, the VIA, and PIAs. (We didn't get to the point of attempting to desolder anything and replacing it.)

If one (or both?) of the 2114s were bad I'd still expect the computer to get to the BASIC prompt... wouldn't it?
...
Are you thinking I should try replacing the 2114s just for the heck of it and see if they could both be bad?
Click to expand...
No, I don't think the 2114s are the problem, at least not at this stage; I was just confirming that you had to piggyback because you couldn't easily replace them.

It's *really* frustrating not being able to get a good idea whether this thing has a real heartbeat or not. Looking at the schematic my latest idea would be... looking at schematics sheet #3, probing lines... 2 through 5 on the C7 PIA and see if they're cycling? It *appears* to me that those are triggered by the keyboard driver to do row select on the keyboard matrix through C9, a 1 out of 10 decoder? If they're not cycling the machine wouldn't be reading the keyboard?
Click to expand...
Yup, you should see pulses on both sides of C9, but I suspect that it didn't get that far; definitely worth checking though. If there is no activity there then I would remove both PIAs in case one is affecting the data or interrupt lines.

I find myself coming back around to that idea of burning an EPROM which does several identifiable things in a loop and subbing it for the Kernal ROM, but heck knows how long that will take and whether it'd actually help me find the problem. I really wish this technical manual had some "theory" pages to go along with all the photocopied schematics.
Click to expand...
Can you burn a 2532? Thanks to Ruud there's a binary image that just displays characters which might be helpful.
View attachment KERNAL2.txt (Rename to .bin)
 
Last edited:
dave_m said:
I took a quick look at the code and it is usable for the non CRTC 4032 but note it will not work on the 8032 as it does not initialize the 6545.
Click to expand...
Good point; I think we were talking about the 4032 2114s and video circuitry but yes, if and when we get a working display for the 8032 this won't work.
 
MikeS said:
Well, either way it's heresy but yes, I'd think if you must, then converting the 8032 to a FAT40 would make more sense since it's a straightforward conversion and lets you use the vast majority of PET software that was written for a 40 column screen. But don't be so quick to give up.
(...)
It's not very stable and the screen is offset and wrapped, but I suppose the CRTC could fairly easily be reprogrammed.
Click to expand...

I seem to recall reading in some other thread about converting an 8032 to a FAT40 and I sort of got the impression that merely changing the jumpers and the ROM wasn't enough... that there was some interference of some kind from the additional components being present. And I really don't want to be in the position of ripping components off the board to convert it if I were to get it "working" as an 80 column PET. :^/

80 column on a 9" wouldn't bother me particularly if I could run one of those 40 column PET emulators, but... yes, I don't really want to give up yet.

I did notice on page one of the "PCB Assembly/parts list" for the Universal board in the 4000 series technical manual that there's a part number 8032090-11 for a 'UNIV. DYNAMIC PET, 4032-9" - 60hz'. That sort of implies that it's possible to jumper the universal board to work properly with the 9" monitor...

BTW, disconnecting the video signal (while leaving the syncs and grounds) should give you a reverse blank screen (all green except for border, with retrace lines) if the monitor is working; remember to turn up the brightness.
Click to expand...

That's essentially what I saw, except it was rolling somewhat (like bad horizontal hold), when I connected a 9" PET monitor to the 8032 board and cranked the brightness up all the way. I have yet to see even the slightest sign of luminance from the 12 inch. If someone wants to loan me a known-working 8032 board to attach to it so I can absolutely prove the monitor has a problem I'd love to end up proved wrong about it being sick.

MikeS said:
No, I don't think the 2114s are the problem, at least not at this stage; I was just confirming that you had to piggyback because you couldn't easily replace them.
Click to expand...

Just as a shot in the dark I'm considering replacing the 74LS244s E9 and E10 on the 4032, since both system and video RAM lie downstream from them. (The ROMs and PIA/VIAs seem to be directly on the CPU's data bus.) Clearly I'm grasping at straws and just looking for the most "critical path" things besides the CPU and RAM.

Yup, you should see pulses on both sides of C9, but I suspect that it didn't get that far; definitely worth checking though. If there is no activity there then I would remove both PIAs in case one is affecting the data or interrupt lines.
Click to expand...

Already tried the "boot with no PIAs" installed test. No difference. :^(

Can you burn a 2532? Thanks to Ruud there's a binary image that just displays characters which might be helpful.
Click to expand...

I'd banged together something like that in a 6502 emulator but haven't tried it in VICE yet. I'll look at Ruud's and see what it does. Since burning a 2532 is doable for me (indirectly) but is something of a hassle I was considering seeing if I could come up with a short diagnostic that in addition to doing a fill of VRAM with characters might do some other useful things, like writing patterns to system RAM and reading them back, noting by changing screen character positions if a block of RAM passed or failed. While I'm dreaming I could try toggling lines on the user port on and off, which would be something I could hit with a probe.

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