• Please review our updated Terms and Rules here

Dead PET 8032 - any suggestions?

Another bit of information -
Just checked all the 4016 RAM on the bad PET, to eliminate that as a variable.
Used an Apple II+ as a memory tester. All the chips tested ok..
I'm wondering if somehow the instructions the PET is fetching from ROM are getting corrupted somewhere along the way.
Seems like it might be a case for making a test EPROM. I don't have an EPROM writer, but I do have a few Atmel EPROMS which are fairly simple to write with a small microcontroller circuit. May look up 6502 opcodes and make a simple test.
 
The one thing that would complicate writing a tester ROM for an 8032 is the video system has to be set up in software before it works. (On the 9" PETs it's all hardwired so it's trivial for a tester to toss feedback about what it's doing into video RAM with no setup, so if the hardware works at all you'll at least see *something*.) I'm sure it would be possible to just pry the CRTC setup code out of an EDIT ROM image and incorporate it, but that's probably at least a "mid-level experience" machine language programming task.

Just for sanity's sake, do continuity tests across all the data lines in your ROM socket area. I had a bad trace on my 4032 that allowed the tester ROM I wrote for that to work, as well as letting enough of the KERNEL/BASIC ROM set make it into the debugger, but corrupted the contents of the last two BASIC ROMs.
 
Thanks for the information - I'll check on the continuity of the data lines.
One thing I just noticed on the 8032 board is a couple of intentionally cut traces and two jumper wires attached on the underside of the board.
A trace from pin 7 on UE8 (SN74LS244N) was cut between UE5 and UE6. Where the trace goes, I can't quite see. Another trace from pin 8 on UE6 was cut right next to the pin. Also two jumper wires are there, one between pin 8 on UE6 and pin 10 on UE4, and another between pin 11 on UE4 to a point next to UE6, which is on a trace which was connected to pin 8 UE6 but that trace is cut. Where it goes from there I can't quite trace.

Sounds like there are at least 3 people in the bay area who are trying to fix PETs right now - perhaps it's time for a PET repair party somewhere..
 
Checked the continuity of the data and address lines, and everything checks out so far. Checked the data lines from the ROM in the sockets to the CPU pins, all have continuity. Also checked the address lines to the 244 buffers, and from the buffers to the CPU, and those check out as well. Also looked into the cut traces I mentioned earlier, and now I think those were probably cut at the factory as part of a rework process. With the jumper wires in place and the cut traces, I confirmed that the connections match those described in the 8032 schematic from the zimmer site, so I'm pretty sure these were intentionally done. I even traded 6502 cpus just for kicks, with no change.
I observed the chip select lines for the different ROMs with my scope, and saw that the kernal rom (F000) is selected right after reset, then the E000 screen ROM, then the D000 for a moment and finally back to the E000 ROM, where it stays. Activity on the E000 ROM continues indefinitely. My only theory now is that there is some corruption in either the data or address bus which is feeding the CPU, and so the right instructions are not being executed. I'm pretty sure there needs to be some activity on address line 11, which selects the CRTC through the x8xx signal, and right now there is no activity on A11 after the first couple of seconds after reset. I had read somewhere that the RAM does not use the chip select to deactivate the RAM talking on the data bus and relies on a latch, perhaps that's something to look at.
I think next thing I'm going to try is to make some variation of the PETtester EPROM to see if I can pinpoint a bad data or address line or perhaps some bad memory interface circuitry. Wired up a simple microcontroller circuit to write an atmel EEPROM (28C64A-250) - seems like a convenient chip to use because you can write to it just like SRAM and only requires +5v power. Also has nearly identical pinout to a 2716. One thing I'm thinking is to have the microcontroller watch the data and address bus, and pull the RDY signal low to create a wait state while the uC sends the address/data values over a serial port to a computer. This way I could watch the activity on the bus to hopefully see a bad instruction or some corruption on one of the busses.
 
Looking at the schematic, the bit about the RAM using a latch doesn't sound right. From what I see the RAM is selected by the RAM R/W signal to the /WE pin..
 
gubbish said:
I'm pretty sure there needs to be some activity on address line 11, which selects the CRTC through the x8xx signal, and right now there is no activity on A11 after the first couple of seconds after reset.
Click to expand...

After power up, not really. Right after power up, the CRTC is initialized using I/O addresses at $E880 to get the display running. But after that, to write to the screen, you only need to address video RAM directly at $8000 to 87FF which does not need A11 set.

And after initialization, I don't think the CRTC is accessed again.
 
Hmm, ok.
One thing I observed is that on the bad PET 8032, the CS pin on the CRTC is continuously high, so to my understanding the chip is never selected. I compared this with the working 8032, and on the working one there is a signal at CS, so CS goes low repeatedly. Does this make sense?
Just by looking at the schematic, CS on the CRTC chip is generated by a 74LS10 NAND gate, with the inputs:
Inverted I/O, x8xx, and BA7.
This means that all of these need to be high for CS to go low on the CRTC.
Looks like I/O comes from a 74154 decoder, with inputs BA12-BA15. So I/O is low when a binary 14 appears on the inputs of the 71454 (BA12-BA15 = 0111)..
x8xx is from a inverted input AND gate (UE14, 7425), with inputs BA8-BA10 and inverted BA11. So BA8-BA11 = 0001 to get x8xx high..
So looks like overall, to have CS go low on the CRTC, you would need BA7-BA15 = 100010111, which equates to I/O Addresses $E880 - $E8FF, as you said. So I can wrap my head around that part.
So perhaps this I/O address is never accessed on the bad PET.

One question is, after the CRTC is initialized, what is it actually doing? I'm don't yet understand how the CRTC gets activated and reads from video RAM.. Does it do some form of cycle stealing from the CPU to access video RAM during a draw phase?

Thanks much for the assistance!
 
gubbish said:
One question is, after the CRTC is initialized, what is it actually doing? I'm don't yet understand how the CRTC gets activated and reads from video RAM.. Does it do some form of cycle stealing from the CPU to access video RAM during a draw phase?
Click to expand...

On power up, the registers in the CRTC are initialized with the proper constants to create the timing signals needed for the screen.

The CRTC is used to generate the vertical and horizontal drive signals and also to generate the incrementing addresses that continuously read out the video RAM including the addressing for the eight scan lines needed for every row of characters.

This is done by time sharing the Video RAM on the opposite phase of the 1 Mhz clock used by the 6502 CPU. Therefore the CPU and the video readout logic do not interfere with each other and both run at full speed with no need for cycle stealing.

It is late in California and I do not know how clear this answer will turn out to be so please ask followup questions if needed. I am acting like an 'expert' but just recently learned all this while helping a fellow (nama) troubleshoot his PET in Japan.
 
Thanks,

I checked on the activity at the CRTC chip in the bad PET.
Turns out that the CS line was going low at the CRTC chip - but I didn't trigger properly so I missed it the first time I was looking.
And I checked on the data appearing at the chip when the chip was selected, and compared this with the working 8032.
The data lines match up. In fact, the whole data trace at the time when the CRTC is selected matches up exactly with the working PET. Definitely didn't see obvious bad or stuck lines.
This makes me start to suspect that the problem may be the CRTC chip. The chip in the working PET is not socketed, so can't swap to test. And I see that the right data is presented at the CRTC chip when selected. Any idea how often this chip fails? If I can find a spare chip this would be a simple thing to check before going too crazy looking at other stuff. In this PET so far I'm sure the ROMS, RAM, and CPU are good. I've checked continuity with the data and address lines and everything looks good. Also the board appears clean and free of corrosion.. so might just see if I can get a spare CRTC for testing next.
 
Doesn't the Killer Poke work the other way around, i.e. software made for later CRTC PETs that try to speed up the raster beam (IIRC) will stress the monitor on older PETs to die?
 
carlsson said:
Doesn't the Killer Poke work the other way around, i.e. software made for later CRTC PETs that try to speed up the raster beam (IIRC) will stress the monitor on older PETs to die?
Click to expand...

No. Nine inch pets are immune to the killer poke (there's absolutely nothing programmable about their video system). The reason the poke exists is that old PETs will display "snow " on the screen if video memory is updated outside the vertical blanking period, so the ROM checks an input pin on one of the PIAs and waits to update until the raster is clear of the active area. The poke disables that check, allowing the computer to run faster at the cost of.having a little snow on the screen.

What makes it "killer " is the hardware bit that's poked is mapped to the CRTC on the 12" PETs. There's a technical discussion of what it actually does to the hardware on 6502.org.
 
MikeS said:
Actually I was wondering if any other than UD7 are in sockets, so you can easily test them in one of the other PETs. They're all the right ones although that 472-04 in UD12 is odd; UD12 is a spare socket and that ROM actually sounds like a printer ROM. You might as well remove it.
Click to expand...

901472-04 is a 4022 Printer ROM but it's also the Visicalc ROM. Commodore re-used some ROMs as "protection" for other programs.

Steve
 
sjgray said:
Commodore re-used some ROMs as "protection" for other programs.
Click to expand...
Yes, like those (Handic/Datatronic) Calc Result and Word Result cartridges for the CBM-II series. Those contain a PET character ROM if I recall correctly. As these machines don't have a programmable character set in the first place, the cartridge appears to act as a protection dongle. Supposedly somewhere there was a surplus of character ROMs which would be cheaper to use up than program new ROMs or even EPROMs with code/checksums of their own liking.
 
One more thing, and so far the only easily quantifiable difference in the signals I've observed at the CRTC between good/bad PET 8032s is the clock phase at pin 21 of the CRTC chip. In the working PET, the clock signal at 21 has the opposite phase from the signal at pin 23 (E, which I believe is an enable signal for reads/writes to/from the CRTC registers). In the bad PET, pin 21 has the same phase as the signal at 23. In fact what I'm seeing at pin 23 on the good PET doesn't match with the schematic I'm looking at. In the schematic it says that that pin 23 is connected to BA2 (buffered address 2) - on the good PET these pins are not connected, and in fact pin 23 is connected to /CLK1, inverted from the main clock signal by the inverter at UE4 pin 10.
So far this is the only clear difference in signals that I have observed. I tried gently removing just pin 21 on the bad pet's CRTC and connecting that to /CLK1. No effect. Not sure if this clock phase would be significant, but since the CRTC is supposed to read from VRAM on opposite clock edges from the CPU, it seems like it would.

Also, the CRTC chip in the bad PET is not a MOS 6545, it is a Hitachi HD46505SP. From the datasheets for these chips that I could find, the chips seem identical, except for the signal name for pin 23 and 21 - it is referred to as "E" in the hitachi, and phi-2 (clock) in the 6545. 21 is referred to as CLK in the hitachi and CCLK (character clock) in the 6545. Not sure if these matter, as the functions seem the same according to the descriptions. Just trying to fully understand how things work here.

At the moment, the theory I like best is that the CRTC is bad. I saw a few places online that sell 6545 chips, so I may buy one (or two) and test that theory. Thanks for all the help so far, I hope this PET is close to living again.. but you can never tell!
 
You must log in or register to reply here.
Back
Top