• Please review our updated Terms and Rules here

PET cemetery - 4016 repair

P

plagued

Experienced Member
Joined
Jun 30, 2024
Messages
105
I've decided to punish/reward myself with another neglected 80s "treasure" and got my hands on a 4016 that's been sat in a shed for 20+ years and become a woodlouse graveyard. It's in a fair state, but as a wise man once said "I've had worse"
1000019614.jpg
The woodlice, spiders and wasps husks have been evicted and I've got the board on the bench. Power supply has been refurbished and the board cleaned, socketed chips cleaned and re seated with a bit of deoxit.
Reset was stuck which corresponded to the worse area of corrosion around the 555 timer. So I've rebuilt it and popped a new 555 in and the reset signal was back up and running. Checking the CPU and nothing on the address lines despite power and clock and reset all good so I swapped it out and the data and address lines sprang to life. But still no boot. Checking the enable lines on the ROMs and no activity, traced it back to the 74154. Swapped that out and now the kernel ROM is active.... But that's as far as I've got. Popped a logic analyser on the ABCD lines to the 74154 and I can only see it produce "15" and thus "SELF" is the only ROM select line active.
I've had a good poke about and the address lines look good but I don't like the look of the data lines, lots of cases where it's not dropping lower than 2.5v. So I'm guessing I may have something bad on any one of the chips sat on the data line.
I've burned a copy of Dave's test ROM but it's not going to get me very far if it won't boot it.
Any advice on what to turn my attention to? I'd much rather diagnose an issue than starting randomly pulling chips, but it can be awkward identifying issues on the bus. So any common failure points would be good. This was apparently working before it was stored.
As I've not worked on a PET before, I'm making some assumptions, like I can get it booting without the keyboard connected.
 
Such a contrast of plastic against rust. My PETs are sll metal and i dont own the plastic variety but I can see by your photo the bracket under the crt is metal too. I did not know that.



Its definitely saveable.

Looking forward to your progress. More photos please.
 
Yep, it will boot without a keyboard.

If your databus looks 'weird' then you are probably on the right track regarding devices on the databus.

How many ROMs are in IC sockets?

Last time we had a problem like this, it was a faulty ROM that was driving the databus even when it wasn't selected.

The PIAs and VIA are sometimes culprits as well. Are these devices in sockets?

Dave
 
I'm recording most of the restoration, so if I can ever find the time I'll get some videos on that there you tube. But for now I'll leave a few pics here.
The case has had a good bath as it needed it, the rusty crt frame had stained the top here's the before:
1000019625.jpg
The crt frame cleaned up well and I even found a rustoleum paint called "heirloom" that matched the slightly horrible cream/yellow of the original:
1000020253.jpg

The tray is now rusty free also
1000019704.jpg
Regarding the PCB work, only the Kernel and edit ROMs are socketed. (Both CRC check fine) And the CPU.
I think I'll take your suggestion on looking at the other ROMs Dave, as the only sign of prior work is a possible replacement of one of them (but no socket) it's probably handy to have them all swappable and that fulfills my need to not randomly pull chips :)

Edit .... wow these pics are pretty huge, might resize in future, sorry about that.
 
plagued said:
I'm recording most of the restoration, so if I can ever find the time I'll get some videos on that there you tube. But for now I'll leave a few pics here.
The case has had a good bath as it needed it, the rusty crt frame had stained the top here's the before:
View attachment 1290291
The crt frame cleaned up well and I even found a rustoleum paint called "heirloom" that matched the slightly horrible cream/yellow of the original:
View attachment 1290292

The tray is now rusty free also
View attachment 1290293
Regarding the PCB work, only the Kernel and edit ROMs are socketed. (Both CRC check fine) And the CPU.
I think I'll take your suggestion on looking at the other ROMs Dave, as the only sign of prior work is a possible replacement of one of them (but no socket) it's probably handy to have them all swappable and that fulfills my need to not randomly pull chips :)

Edit .... wow these pics are pretty huge, might resize in future, sorry about that.
Click to expand...
I use the same Heirloon white paint by rustoleum on many of my restorations as well. I just used some for an external floppy drive enclosure. Its the quintessential "beige".
 
ok, that was somewhat successful. All the roms read OK with the exception of UD10 which is the 901465-23 basic rom. This just reads garbage, so it's bad ... I'm not sure I have any 2732 so I'll get some on order (unless there's some hiding in the mess) and maybe make an adapter for one of the larger eproms I've got, if I actually get to the point it's trying to boot before they arrive.
On the ROM front don't the 23xx roms have inverted CS lines compared to the 73xx eproms? I can see the data sheet for the commodore 2332 state "Pin Compatible with 2716 & 2732 EPROM" I can just remember issues with Apple II roms needing an adapter making to invert them ... unless I'm thinking of something else.
However ... having found a bad ROM I can still see the issue on the data lines with all ROMs bar the kernal ROM removed. I've not had much time to look further but I did notice that I can see a dip going below -1v for a fraction of a second when signal does actually try and go low and the idle seems to be around 2v, so maybe I've got a leakage somewhere from the -5v rail unless there's any other way it could drop below 0v
I'll see if I get any time this evening to have a proper poke about, but my actual "modern" computer has just died that I use for the data analyser, and rom burner leaving me with the only functional computers in that room being a Powertran Cortex and an Atari Falcon ..... They don't make em like they used to ... mutter .... mutter
 
plagued said:
I've not had much time to look further but I did notice that I can see a dip going below -1v for a fraction of a second when signal does actually try and go low and the idle seems to be around 2v, so maybe I've got a leakage somewhere from the -5v rail unless there's any other way it could drop below 0v
Click to expand...

If its around 10 nanoseconds it may be undershoot due to transmission line effects you get when signals switch. You can also get increased under/overshoot that is probing artifact if you have a long ground lead on the scope probe. More of a problem with later faster logic families but does exist with any logic when trace length long compared to distance signal travels in rise/fall time.

Overshoot/undershoot diagram
https://resources.pcb.cadence.com/blog/2024-high-speed-signal-analysis-design-tips-cadence
 
hmmm yea, it could be that as it does bounce back quickly. I've just not come across it to this degree before.
I've just had a go at trying to isolate the issue. I've removed and socketed most of the chips on the data bus, just leaving the CPU which is a known good part and the kernel ROM which reads fine.... However, I could still see the issue where data lines were not pulling up to 5v and sticking at 2v. That was untill I then pulled the kernel ROM. So it's looking like that may have been the issue (or one of the issues), so despite it reading fine externally in isolation it could possibly be a bit unwell. I have found a spare 2732 so assuming it's not faulty and I don't need to Invert the CS lines (just flip the A11 and CE pins) .... Oh and if I can get my laptop to boot one more time. I'll burn a new kernel ROM and give it a go.
 
Last edited:
OK, slight confusion on the ROMs front, so I'm making some assumptions.
The schematics show the Edit ROM as a 2316, but no difference in its wiring, which means presumably that they have the CS3 line set as active high rather than the the usual active low or it would be disabled by the "NO ROM"
This would also put the CS2 line onto A11 which I guess isn't actually used to enable the chip as it has CS1 so it relies on A11 presumably also being low whenever it's being read.
to replace the Kernal ROM with a 2732 I'd need to do the following:

2732PET.png
So GND pin 20 and then route the /CE to pin position 20 and A11 to position 18

For the 2716 Test ROM using the edit ROM slot, I'm presuming the same only pin21 is Vpp not A11 so just take that to Vcc?
 
ok, I'm making progress.
Replacing the kernal rom with a 2732 cleaned up the data bus, but is still didn't look good. D2 was still just as "off" as before, but also confusingly the data lines on the other side of the UB10 buffer also looked off, which should be isolated .... I could see good address and enable on the UC4 & UC5 video ram but D0 to D3 was complete junk. So I pulled the 4116 DRAM at UA16 that sat on the main D2 off and both the UC4 UC5 SRAM off, and they're all bad.
I then pulled a couple of other DRAM off to see if this could be another case of a failed regulator taking out the whole string, and out of the first 3 two were bad. So I've pulled them all and fitted sockets. In the end 4 were bad and 5 are OK.
So my question is, should I bother putting 4116 back in, or is it easy enough to modify for 4164? I'd normally put back what I took off, but I'm considering a 32K upgrade if I can get this working, and 4116 are getting rarer, and I've got a load of 4164.
From what I can tell it's only the DRAM using the -5 and 12v, so I could remove the regs, bridge over to the 5v and I wouldn't have cut any traces..... or have I missed something?
So far the failure count is at:
1 x CPU
2 x ROMS
2 x SRAM
3 x DRAM
1 x 74154
1 x 555
and a load of caps and resistors (mainly due to corrosion/age)
 
As no one else has yet mentioned it, the directly pin compatible EPROMs which you need are 2532 rather than 2732 - you can use 2732 but only in an adaptor because as you have rightly noticed two of the pins are transposed. The 'Edit' ROM is a special case as you can use a 2716 to replace that ROM, but only because of the way the ROM socket is used / wired in that particular position.
 
thanks for that. I've made up an adapter for the 2732 as I don't have any 2532.
I've also now removed the -5v rail and set the 12v to 5v to allow 4164 DRAM.
So, I now know I should have good DRAM and SRAM, the CPU was a known good, and the ROMS all read OK.
But I'm no further forward. I'm not sure if @daver2 test ROM would help yet, as I'm seeing no activity out of the main select decoder other than 0 (NC) and 15 (SELF) so nothing is being enabled other than the kernal ROM.
Which chips do I need to boot? for example do I need UB15, UB16 and UB20 from the IEEE-488 and cassette & keyboard circuits to be in, or can I omit them while trouble shooting?
 
The outputs from the 4 to 16 decoder are a function of the program that is running. I would put my PETTESTER in...

Dave
 
daver2 said:
The outputs from the 4 to 16 decoder are a function of the program that is running. I would put my PETTESTER in...

Dave
Click to expand...
Dave thanks. I'll burn a copy of your test ROM to a 2716. In the manual it states a 40 column PET with a CRTC needs the rom patching but the nabble.com link is dead and the CRTC link refers to a 6545. I have a HD46505, do I need to patch anything?
My only hesitation with trying the ROM is that I do not see any activity on the X8XX or SELE lines to UD7 and thus the CSI line is held high, which I assume means the test ROM would never be active.
 
If you have a 40 column PET with a CRTC then yes, you will have to patch the CRTC initialisation table.

If I remember correctly, the tables are in my PETTESTER source code...

You should find that all of the 'original' PET CRTC controllers are the same. We have found some incompatibilities when it comes to 'modern' replacements (shall we say).

You misunderstand what I am saying. If the existing ROMs have got themselves stuck in a loop (in the Kernal ROM) - for whatever reason - then nothing else will be accessed...

The PETTESTER still needs a handful of instructions (and the reset vector) of the Kernal ROM to be working for it to 'take control' of the PET.

Dave
 
daver2 said:
If you have a 40 column PET with a CRTC then yes, you will have to patch the CRTC initialisation table.

If I remember correctly, the tables are in my PETTESTER source code...

You should find that all of the 'original' PET CRTC controllers are the same. We have found some incompatibilities when it comes to 'modern' replacements (shall we say).

You misunderstand what I am saying. If the existing ROMs have got themselves stuck in a loop (in the Kernal ROM) - for whatever reason - then nothing else will be accessed...

The PETTESTER still needs a handful of instructions (and the reset vector) of the Kernal ROM to be working for it to 'take control' of the PET.

Dave
Click to expand...
Thanks, slightly out of my comfort zone compiling 6502 source code ... but where's the fun if you don't have a go ;)
I've taken the values from the table in the source for a 50hz PET which also match the "4032 text" values from http://www.6502.org/users/andre/petindex/crtc.html
I've burned that to a ROM and I'm actually seeing activity! I can see data from the CRTC and I have Horizontal and vertical drive and a video signal!.....but the vertical drive looks too slow?
I'm getting 2.4Hz on the vertical drive, 3.9Khz on the Horizontal.
Anyway it's great to actually see the board with some life in it.
My next issue may also be that I'd be surprised if the CRT is working with the amount of failures I'm seeing on the mainboard, and I doubt any of my existing rgb/cga/ega/yuv etc converters would be compatible.
 
Actual progress!! I stopped poking at the data lines and started looking for other issues. I found the sel8 line was being pulled low, and the most likely culprit was the 7410 at ue13 so I pulled that and replaced it. That immediately cleaned up the data lines, although it still looked odd, like d7 I believe wasn't doing much and no video sync. I popped back in the test ROM and I had 50hz and 20khz on the sync lines, so I hooked my unknown monitor up and low and behold a picture!! Not sure what it means yet but that's a nice step forward!
1000020517.jpg
 
Excellent detective work.

I am just about to go to bed now - but I will get back to you tomorrow.

What is the state of the video RAM I wonder?

There is also a little trick I did on another PET thread where we removed the character generator and used 8 off 100 Ohm resistors to pull-up / pull-down the data outputs from the character generator. This allows us to see small, vertical lines in each character cell of the screen to make sure everything is working after the character generator.

Is the video RAM in IC sockets or not?

If so, you can remove the video RAM and do the same trick with the pull-up and pull-down resistors on the data outputs from the video RAM. This should get us unique characters displayed on the entire screen.

Dave
 
Sounds like a good plan, I'd already pulled the video ram as it was corrupting the ESD data lines (and tested bad), it's socketed and had been replaced with tested good ram but that gives me a good poking point!
I've not started to look for issues, the character rom is socketed and I'm not sure if I've tested it yet as I hadn't got that far :p I had run out of hiding-from-the-wife time yesterday just as I got the video sync up so I just plugged in the monitor and had to run off (and have a celebratory beer). Hopefully I'll get some more time this evening to poke some resistors in.... and maybe clear some space for the monitor.
 
You must log in or register to reply here.
Back
Top