PET 4032 restoration

[JonB]

The PIA#1 (G8 ) is the only device programmed to issue an Interrupt Request. It does so every 60 Hz (16.66 mS) when the SYNC signal (Video On) pulses at the CB1 input (pin18 ). Hold /RES down to see if /IRQ is released. If so, it may get stuck low due to faulty 6520. The interrupt routine does the keyboard scan, increments the jiffy clock, blinks the cursor, etc.

IRQ isn't released when the reset is held low - it just stays low all the time. Guess this means 6520 swap out time. Not got the 40 pin sockets yet, or I'd be reporting on whether it worked or not!

 

[JonB]

OK, I pulled both 6520s and it is booting to BASIC 4.0 and showing 31743 bytes free. No cursor or keyboard though, as it's not generating any IRQs now.

Looks like both PIAs are borked - I tried each in my 3016 (socketed, thank god) at UC7 which I think on the 2001 non CRTC board is the interrupt generating one:

• PIA 1 one didn't boot (IRQ stuck low, per the 4032 original finding)
• PIA 2 booted to the M/C monitor (also per the 4032 when I forced /IRQ active)

So, two new PIAs on order, plus some sockets. I still need to properly replace UE2 (it's piggy backed at the moment; without it I get 17432 bytes free) and I need to restore the pin 11 connection on UA20 (which I lifted in order to isolate one of the inputs to the UB16 PIA).

And here we are...



Almost too easy! More soon.....

 

[JonB]

Righty ho.. I received the 40 pin IC holders and fitted them to the mainboard, along with the other permanent fixes (UE2 properly socketed and UA20 pin 11 soldered back down).

After swiping a pair of 6520 PIAs from my long suffering 3032 andf firring them into the 4032, I seem to have a working PET. However, on attempting to enter a simple program I see there are several keys not working and the shift lock key (whose latch is broken so it won't stay down). What is the correct replacement for the shift lock key? It's a discrete keyswitch for anyone not familiar with the keyboard design, and it's the only one (all others are contacting the PCB directly).

At this rate I'm going to have to thieve the 3032's keyboard as well!

 

[circuit]

Righty ho.. I received the 40 pin IC holders and fitted them to the mainboard, along with the other permanent fixes (UE2 properly socketed and UA20 pin 11 soldered back down).

After swiping a pair of 6520 PIAs from my long suffering 3032 andf firring them into the 4032, I seem to have a working PET. However, on attempting to enter a simple program I see there are several keys not working and the shift lock key (whose latch is broken so it won't stay down). What is the correct replacement for the shift lock key? It's a discrete keyswitch for anyone not familiar with the keyboard design, and it's the only one (all others are contacting the PCB directly).

At this rate I'm going to have to thieve the 3032's keyboard as well!

Re: the non working keys - you probably already knew but have you tried the pencil eraser on PCB method? Nothing I tried worked till I did that

 

[Witchy]

I always take the PCB off and rinse it with IPA then use an eraser on any contacts that look dull. For yuks I also treat the carbon tips of the keys themselves with a 2B pencil (or not 2B, etc).

W

 

[JonB]

Yep, I know... but with a known working keyboard from the 3016 there are some interesting problems.

These keys - CLR/HOME and CURSOR left/ right - have no effect. I wonder if it's the editor ROM?
The IEEE-488 port is playing up, there is no response from CATALOG with the PETDisk installed (load "$",8 or ,9 fails, too).
I got 15k free on one boot up. pressed in the socketed chips and back to 32k. May be a cracked track, that board does flex quite a bit when bearing down on the chip sockets.

..but on the plus side the screen geometry is adjusted.

 

[KC9UDX]

You're missing a row or column signal between the keyboard and the PIA.

I usually drink the IPA whilst I work on the keyboard. Of course, everything round here is called IPA now. I mean, what does it mean American IPA?

 

[JonB]

You're missing a row or column signal between the keyboard and the PIA.

Wouldn't that affect an entire row or column? The keys (left/right arrow, CLR/HOME aren't even adjacent, and all keys around them are working).

Oh hang on, there is a pattern here. The following keys are not working:

! # % & ( [left arrow sign (not the cursor move key)] CLR/Home CusrsorLeft/Right

These are alternative keys of the same row, with the exception of the ] key, which is a little odd. Off now to check the schematic!

Cheers

Edit: Do you mean "India Pale Ale"? So called because the Brits used to ship it to India to quench the thirst of the soldiers of the British Raj. It was brewed specifically for travel.

 

[JonB]

Hmm, cannot find it...

I founf this, which maps the business keyboard's keys to the various row/columns of the matrix:

http://www.zimmers.net/anonftp/pub/cbm/schematics/computers/pet/8032/320284.gif

But I can't see one for the 4032 "graphic" keyboard. Yet. Anyone got a link?

 

[JonB]

This seems to fit the bill: http://www.6502.org/users/andre/petindex/imgs/klayout.png

afachat to the rescue, again!

Seems to be saying row 0 is dead, and on checking, sure enough the BCD-Decimal Decoder at UC11 has a stuck output that corresponds to row 0 of the keyboard. All its inputs are pulsing, outputs q1-q9 are pulsing, but output q0 is stuck high. That'll be it, then... since on the graphic layout, row 0 being dead corresponds exactly to the observed dead keys.

1x74LS145 on order...

Now, meanwhile, how best to diagnose the IEEE-488 interface? As I said, the PETDisk is not being recognised. I could probe around the line drivers, as they are the only components between the PETDisk and the (known working PIA), but what am I looking for? It may be just a matter of stuck lines...

 

[KC9UDX]

Wouldn't that affect an entire row or column? The keys (left/right arrow, CLR/HOME aren't even adjacent, and all keys around them are working).

Yes. But, you found out already, electronic rows and columns don't necessarily coincide with physical rows and columns.

Edit: Do you mean "India Pale Ale"? So called because the Brits used to ship it to India to quench the thirst of the soldiers of the British Raj. It was brewed specifically for travel.

Yes. There's a type of beer here that has gone by a whole series of names over the years, and the most recent is American IPA. Almost every brewery round here now makes one. But, to call it an American India Pale Ale doesn't make a whole lot of sense. They aren't even that much like an IPA.

 

[KC9UDX]

Now, meanwhile, how best to diagnose the IEEE-488 interface? As I said, the PETDisk is not being recognised. I could probe around the line drivers, as they are the only components between the PETDisk and the (known working PIA), but what am I looking for? It may be just a matter of stuck lines...

I usually start by swapping out the VIA, because it seems to be a common point of failure. But if you don't have a spare VIA, then you're going down the right road already.

 

[JonB]

I have a spare VIA, it's in the 3016. Poor old thing....

 

[Witchy]

Edit: Do you mean "India Pale Ale"? So called because the Brits used to ship it to India to quench the thirst of the soldiers of the British Raj. It was brewed specifically for travel.

I meant Isopropyl Alcohol, but whatever floats your boat

W

 

[dave_m]

For yuks I also treat the carbon tips of the keys themselves with a 2B pencil (or not 2B, etc).

Some people just use Isopropyl Alcohol on the foam tips and it seems to restore them to conductivity. The lead pencil trick works but usually doesn't last very long. There are keyboard repair kits that contains silver paint that works OK.

 

[JonB]

There are some other issues here.

• Row 0 is also not working, so I have no shift, 0 . - = keys. Will be fixed by the new decoder.
• With the PETDisk installed, I am getting strange memory counts on boot up (15xxx, 17xxx, 19xxx K).

That second one is most odd indeed. Let's have a quick play:

[reset] - 15362 bytes free
[reset] - 15360 bytes free
[reset] - 15361 bytes free
[PETDisk unplugged] - 15360 bytes free
[power cycle] - 15360 bytes free
[power cycle, flex board] - 15362 bytes free

There's something weird going on here! And it looks like UD5 has broken down (again), because the /CAS1 line has stopped coming out of it (pin 11), but its inputs are fine (pins 12 & 13). That's mighty annoying, because I am out of 74LS00s.

 

[JonB]

The 74LS145 BCD decoder turned up so I swapped the broken one out. Looks like the keyboard is working nicely now.



What's odd is that on reboot it is coming up with the correct amount of memory again (and I definitely have not swapped out the 74LS00 at UD5). Maybe there is a short to +5v somewhere. I tried resting the pin without the chip and there was nothing, though. Can a TTL chip fail then work again?

Edit: Seemingly not. On a reset (not power cycle, holding /RES low) it has gone back to 15365 bytes free. No matter though, I have another 74LS00 on prder..

 

[JonB]

Another observation. It seems to report 31743 bytes free when it is cold, then after a while a rest gives 15534 bytes free.

Maybe it's temperature related.

 

[KC9UDX]

My 2001 does the opposite.

When it's cold, the numbers are pretty random. I've seen everything from zero to over eighty megabytes. Sometimes there are fractions of bytes too.

Of course, it also tends to be a GOMMODOVE.

 

[JonB]

More keyboard problems.

I noticed that X, V and M weren't working, so I checked the other keys on the matching row which is 7 according to Andre's diagram. Opened the keyboard up and couldn't see anything untoward, but on testing XVM with a logic probe I could see that one side of the contacts weren't actually connected to anything. Hmmm, can't see a broken track, but what's that fat line that is connecting them together? Yes - funny tracks overlaid on the normal tracks using lacquer and conductive paint. Obviously a cost cutting measure, because you can have a single sided PCB using these, but the flip side is they deteriorate and break down.

So I scraped the crud off the pads and hard wired them using prototyping wire and all's well with the keyboard (G is a bit reluctant, but it just needs a clean).