Commodore PET 4016

[ScottishColin]

Home. Very nice couple of days away at Rosneath.

The 78LS86s are here (I bought 2).

I may need to retract my statement that the PET won't book without a 7486 in place as either the 7486 went faulty and took something else out or it happened the other way around.

I tested the display and the display motherboard by swapping in the working 4032 and that all works fine so there doesn't seem to have been any damage there at least.

In short, the PET won't boot at all.

Even more interestingly, I can't get any frequencies/signlas using the NOP adapter at all,.

I have volts in the right place, but there's no sign of life.

So I'm back to square one (and perhaps behind that).

Where would I start to look if I can't see any frequencies or signals using the NOP tester?

Colin.

[ScottishColin]

And now with my ham-fisted prodding, I've blown the slow-blow fuse. This one is a different length/diameter to any of my spares so I'm now waiting for them to turn up in the post.

I'll check the other PETs to see what they have in case anyone has any smart ideas.

Let's hope I haven't done anything even worse to it.

Colin.

P.S. I do quite like it when they don't work. That's the fun part for me.

[ortek_service]

Originally Posted by ScottishColin

Home. Very nice couple of days away at Rosneath.

The 78LS86s are here (I bought 2).

I may need to retract my statement that the PET won't book without a 7486 in place as either the 7486 went faulty and took something else out or it happened the other way around.

>>

Colin.

I presume you actually ordered & received 7486's? - As the lower-power / less-output drive (and sometimes a bit slower) 74LS86 may not always work in place of a 7486 if that's what was originally used
- And presumably Commodore had used the original 7486 version, as the later 74LS86 Low-Power Schottky version (that most moved onto) wasn't suitably.

[ortek_service]

Originally Posted by ScottishColin

And now with my ham-fisted prodding, I've blown the slow-blow fuse. This one is a different length/diameter to any of my spares so I'm now waiting for them to turn up in the post.

I'll check the other PETs to see what they have in case anyone has any smart ideas.

Let's hope I haven't done anything even worse to it.

Colin.

P.S. I do quite like it when they don't work. That's the fun part for me.

I presume the fuse wasn't blown when it failed to boot, and only later got blown?
And these are 32mm (1.25") ones that were once used in (now vintage) cars etc and American companies were quite fond of carrying-on using rather than the smaller 20mm ones more-commonly used here / Europe.

Depending on the type of fuse-holder, you might be ably to temporarily-fit a 20mm one - or even a BS1362 main plug fuse that you can get down to 1A values and which I believe are also fairly slow-medium blow rather than quick blow.
Or borrow one from another PET for now, as presumably they all use the same ones?

[ortek_service]

Originally Posted by ScottishColin

Home. Very nice couple of days away at Rosneath.

>>
>>

In short, the PET won't boot at all.

Even more interestingly, I can't get any frequencies/signlas using the NOP adapter at all,.

I have volts in the right place, but there's no sign of life.

So I'm back to square one (and perhaps behind that).

Where would I start to look if I can't see any frequencies or signals using the NOP tester?

Colin.

Well the things to check if a uP isn't running are usually:
1. Power(+Gnd) pins have 5V across them.
2. nRST is not stuck low / pulses-low at power-up.
3. There is a correct amplitude & frequency clock signal on those pins
(Compare with a working PET's, if required).
4. The Interrupt (In particular nNMI) inputs are not stuck-low

You could try looking at the 6502 machine-cycle state output (SYNC), to ensure it is running and able to execute NOP's.
And also that RDY & S0 inputs are set correctly.
Otherwise maybe check the data & address buses for shorts / stuck lines.
And ensure the 6502 is still OK (By subtitution with / in another PET.

This webpage may be useful, for referencing all the signals / their directions on the 6502 pins: https://www.cpcwiki.eu/index.php/MOS_6502
(Pinout image attached)

[julie_m]

Welcome back, Colin

I've not been slacking while you were away. This is what I have come up with so far:

You get a visual map of the memory it's testing, showing which locations passed, which were write errors (i.e., what was read back was different from what was written) and which were read errors (i.e., zero was expected in a location other than the one written to, but something else was read back). After an error, testing resumes by re-zeroing the location just tested and going on to write a "1" in the next location. Error messages scroll up the screen (probably too fast to read).

For the purposes of the screenshot, I simulated the errors using the monitor built into VICE (which is part of the emulator itself, nothing to do with the emulated machine).

Here's the ROM image and source code:
testrom_06.zip

The bad news is, I'm rapidly running out of room in a 2716! Still, as far as the test goes, it proves the first 256 bytes of screen RAM can be written and read back, and no bit of any byte affects any other; and then it uses that space to test the 6502 stack at page 1 and zero page, and display the results. If the rest of screen RAM is working correctly, it is used to display extended information, but if necessary it ought to be able to function without that. What it hasn't tested yet is that there are no clashes between zero page and the stack; that'll be up next. And then we have a known good subset of the machine's memory which we can use tor more testing, even if it runs to two ROMs.

[SiriusHardware]

I presume you actually ordered & received 7486's?

Actually the parts list (specifically PDF page 21 of the service manual linked to earlier) states that UC2 is in fact a 74LS86, so I would assume that is why LS parts were ordered. Colin does usually take care to order like for like parts.

In any case, it would take a lot more than that to stop a NOP test in its tracks, you have to have something pretty fundamentally wrong for that.

Colin, how are you judging the NOP test as not running? The absence of waveforms on the A0-A15 lines?

You mentioned you have volts, but not which volts where - specifically, check for +5V across the power pins of the 6502 itself (0V on pins 1 and 21, +5V on pin 8).

If you have supply volts to the CPU, now move to the clock input: You should have 1MHz on the clock-input pin (37). If you don't, check back through UD3 pin 12 (1MHz) and UD3 pin 8 (16MHz) and UE5 pin 6 (16MHz) and UE4 pin 5 (16MHz) and UE4 pin 4 (16MHz). If you are measuring frequency with the scope keep in mind that the chosen scope sample rate must be significantly higher than the frequency you are trying to measure or you will get false results. If you have 1MHz at UD3 pin 12 you can reasonably assume that the 16MHz oscillator and its output buffer chain are working, so you need only check back further if you don't have 1MHz at UD3 (pin 12).

If the clock is OK, check the state of the RESET pin, that should be momentarily low at power-on, returning to steady high - same if you press / release the temporary reset switch you fitted. If RESET is stuck low, investigate why that is, investigate back through UD15 pin 6, UE15 pin 2, UD16 pin 3, pressing / releasing the reset switch and observing what happens at each of those points.

If all of the above seems normal then just try testing the 6502 in another machine - a failed CPU would obviously also prevent a NOP test from running.

Edit: Crossed with Owen, who put it all in much more concise terms. (Post #245).

Julie, good to hear work is still ongoing - of course we need to coax a bit more life out of this PET before it will be able to run the latest version, but hopefully that won't take too long.

[ortek_service]

Originally Posted by SiriusHardware

Actually the parts list (specifically PDF page 21 of the service manual linked to earlier) states that UC2 is in fact a 74LS86, so I would assume that is why LS parts were ordered. Colin does usually take care to order like for like parts.
>>
>>

Colin had previously mentioned it was a 7486, so had assumed that was what had originally been used.
But good to hear that it was actually the same 74LS86 that had been ordered.

[ortek_service]

I've just noticed this: https://atariprojects.org/2024/10/19/troubleshoot-the-6502-p...d-using-an-oscilloscope-15-30-mins/

Whilst aimed at an Atari, it does cover 'scoping a 6502's various signals with example 'scope waveforms quite-well.
- So it may well be useful, when fixing PET's and other 6502 etc. computers.

[SiriusHardware]

The bad news is, I'm rapidly running out of room in a 2716!

Going to a 4K chip potentially lends another layer of complication - the chip select for the EDIT ROM only operates over the range of a 2716 so if you wanted to move to a 4K chip you would instead have to write it to replace the Kernal ROM instead.

Two problems with that:

One, the ROM in the Kernal ROM position has the pinout of a 2532, not 2732, EPROM so you'd either have to program the test code into a 'native' 2532 to drop straight in or you'd have to put a 2732 in an adaptor.

Two, the 'EDIT' ROM is sometimes the only ROM which is in a socket in a machine which is in original, untouched condition, which is another reason why Dave chose to replace the EDIT ROM rather than the Kernal (Boot) ROM, which on the face of it would have been the more obvious choice.

[ScottishColin]

The part I removed was marked as a 748 (no LS) but I replaced it with a 74LS86. I have a couple of 7486's on order in the event that this is actually the problem.

I have put the 4016 motherboard in the 4032 chassis for testing while I await new slow-blow fuses for the 4016. The 4016 is fitted with 20mm long fuses and all the other PETs are 32mm long and I only have 32mm spares.

Re below:

Pin 0/21 in the 6502 (in the NOP Generator) - 0.009v
Pin 8 on the 6502 - 5.1v

No frequency present on pin 37 of the 6502

No frequency present on UD3/12

16Mhz visible on UD3/8

16Mhz visible on UE4/4 and UE4/5

Does this mean UD3 may need replacing?

Colin.

Originally Posted by SiriusHardware

Actually the parts list (specifically PDF page 21 of the service manual linked to earlier) states that UC2 is in fact a 74LS86, so I would assume that is why LS parts were ordered. Colin does usually take care to order like for like parts.

In any case, it would take a lot more than that to stop a NOP test in its tracks, you have to have something pretty fundamentally wrong for that.

Colin, how are you judging the NOP test as not running? The absence of waveforms on the A0-A15 lines?

You mentioned you have volts, but not which volts where - specifically, check for +5V across the power pins of the 6502 itself (0V on pins 1 and 21, +5V on pin 8).

If you have supply volts to the CPU, now move to the clock input: You should have 1MHz on the clock-input pin (37). If you don't, check back through UD3 pin 12 (1MHz) and UD3 pin 8 (16MHz) and UE5 pin 6 (16MHz) and UE4 pin 5 (16MHz) and UE4 pin 4 (16MHz). If you are measuring frequency with the scope keep in mind that the chosen scope sample rate must be significantly higher than the frequency you are trying to measure or you will get false results. If you have 1MHz at UD3 pin 12 you can reasonably assume that the 16MHz oscillator and its output buffer chain are working, so you need only check back further if you don't have 1MHz at UD3 (pin 12).

If the clock is OK, check the state of the RESET pin, that should be momentarily low at power-on, returning to steady high - same if you press / release the temporary reset switch you fitted. If RESET is stuck low, investigate why that is, investigate back through UD15 pin 6, UE15 pin 2, UD16 pin 3, pressing / releasing the reset switch and observing what happens at each of those points.

If all of the above seems normal then just try testing the 6502 in another machine - a failed CPU would obviously also prevent a NOP test from running.

Edit: Crossed with Owen, who put it all in much more concise terms. (Post #245).

Julie, good to hear work is still ongoing - of course we need to coax a bit more life out of this PET before it will be able to run the latest version, but hopefully that won't take too long.

[julie_m]

Originally Posted by SiriusHardware

Going to a 4K chip potentially lends another layer of complication - the chip select for the EDIT ROM only operates over the range of a 2716 so if you wanted to move to a 4K chip you would instead have to write it to replace the Kernal ROM instead.

Two problems with that:

One, the ROM in the Kernal ROM position has the pinout of a 2532, not 2732, EPROM so you'd either have to program the test code into a 'native' 2532 to drop straight in or you'd have to put a 2732 in an adaptor.

Two, the 'EDIT' ROM is sometimes the only ROM which is in a socket in a machine which is in original, untouched condition, which is another reason why Dave chose to replace the EDIT ROM rather than the Kernal (Boot) ROM, which on the face of it would have been the more obvious choice.

I'm aware of that -- I had to do some searching just to find out how even to begin this project!

Looking back at the code in the cold light of day, I can see at least 150 bytes free, plus another 100 bytes of left-over code that is now redundant and can be removed. So there's definitely room for my stack / zero page clash test; and that's the last thing that will need this clunky programming style, so maybe a population test will also fit.

But anything beyond that probably is going to have to go into its own separate ROM image.

[ScottishColin]

Thanks Julie.

Omce I stop breaking things, I'll test this code out and let you know how it goes.

Colin.

Originally Posted by julie_m

Welcome back, Colin

I've not been slacking while you were away. This is what I have come up with so far:
Attachment 313839
You get a visual map of the memory it's testing, showing which locations passed, which were write errors (i.e., what was read back was different from what was written) and which were read errors (i.e., zero was expected in a location other than the one written to, but something else was read back). After an error, testing resumes by re-zeroing the location just tested and going on to write a "1" in the next location. Error messages scroll up the screen (probably too fast to read).

For the purposes of the screenshot, I simulated the errors using the monitor built into VICE (which is part of the emulator itself, nothing to do with the emulated machine).

Here's the ROM image and source code:
Attachment 313838

The bad news is, I'm rapidly running out of room in a 2716! Still, as far as the test goes, it proves the first 256 bytes of screen RAM can be written and read back, and no bit of any byte affects any other; and then it uses that space to test the 6502 stack at page 1 and zero page, and display the results. If the rest of screen RAM is working correctly, it is used to display extended information, but if necessary it ought to be able to function without that. What it hasn't tested yet is that there are no clashes between zero page and the stack; that'll be up next. And then we have a known good subset of the machine's memory which we can use tor more testing, even if it runs to two ROMs.

[julie_m]

Originally Posted by ScottishColin

Thanks Julie.

Omce I stop breaking things, I'll test this code out and let you know how it goes.

I forgot to mention, that version has the slow test skipped so I could get to the bits I was testing sooner (and the places you need to alter are different this time).

I'll have an alternative version up soon, with two rom images -- one with the slow test enabled and one without -- maybe even before your PET is ready for it!

[SiriusHardware]

Does this mean UD3 may need replacing?

This is all very strange - when the video output failed you diagnosed the 74(LS)86 faulty because you had clear activity on the inputs to that IC, but now you have an apparent failure which couldn't be any further from that fault if it tried. I hope this doesn't mean there has been some sort of catastrophic wipeout going right through the machine.

It's not looking good for UD3, but just check a couple more things first.

Look for:
Supply volts on the power pins of UD3 (14=5V, 7=0V).
A logic 'high' state, on UD3 / 1 and UD3 /13
8MHz on UD3 / 5
4MHz on UD3 / 9
2MHz on UD3 / 2

I had better ask, how are you measuring these frequencies? On your original PET we got a bit sidetracked when one of your multimeters, which did have a frequency range, was happy to show 8MHz, 4MHz and 2MHz but bizarrely not 1MHz on pin 12 - until we provided the meter with a half-supply reference point to put the black lead on so the meter thought it was looking at an 'A.C.' signal. Then we found out that the 'missing' 1MHz had been there all along.

..Just in case that's what's happening again.

[ortek_service]

Well if the test-code does end up being >2KB, and so two different 2716's are required to fit in the EDIT 2KB ROM socket, then maybe both of these could be programmed into a 2732 (or 2532 if that mostly matches the best to a 2716), and then the 4KB EPROM's upper-address bent-up and connected to a small DIP etc. switch to select which Test ROM / set of tests to run.

I do recall that Interword on the Beeb managed to use a 32/64KB? 'ROM' in a 16K memory-slot by having it's own on-board latch / PAL? IC that I presume was controlled by memory-access to a specific location. So allowing much-more code to be run from a single-socket. But this did come on a small carrier-PCB, so would have to produce something similar - which whilst OK for suppliers of diagnostic test modules, may be a bit too involved for most to build to aid in fixing their PET.

[ortek_service]

Originally Posted by ScottishColin

The part I removed was marked as a 748 (no LS) but I replaced it with a 74LS86. I have a couple of 7486's on order in the event that this is actually the problem.

I have put the 4016 motherboard in the 4032 chassis for testing while I await new slow-blow fuses for the 4016. The 4016 is fitted with 20mm long fuses and all the other PETs are 32mm long and I only have 32mm spares.

>>
>>

It's odd that Commodore decided to change the size of the fuse on this 4016 board, to 20mm, when presumably they started with 32mm ones in the other PET's (and would have expected the 4032 to have the same board in it? although Commodore were reknowned for having many different boards in the same models!).
Especially when they used 32mm ones in the later VIC-20 / C64.

Originally Posted by ScottishColin

>>
>>
Re below:

Pin 0/21 in the 6502 (in the NOP Generator) - 0.009v
Pin 8 on the 6502 - 5.1v

No frequency present on pin 37 of the 6502

No frequency present on UD3/12

16Mhz visible on UD3/8

16Mhz visible on UE4/4 and UE4/5

Does this mean UD3 may need replacing?

Colin.
>>
>>

It is rather looking like UD3 could be at fault - What is it / have you any spares / socketed ones in other PET's?
(Assuming you have used a 'scope to check what is on these pins, and it does seem like the 6502 has lost its 1MHz clock input)

[SiriusHardware]

What is it

74177 4-bit counter, divides the output of the 16MHz master clock oscillator down to 1MHz for the 6502 CPU's clock.

[ScottishColin]

Interestingly the BOM states it is a 74177. Fitted in the 4016 is a 74LS197.

As I understand it, they are compatible albeit the 74177 is a reduced power device.

I'll probably go with a 74LS197 as that is what is fitted unless someone tells me differently.

And no - I don't have any...

Colin.

[TonyDuell]

I would fit a replacement of the same type as the original (here : 74LS197). The machine has worked with that type of IC ftted so if there are any changes needed to use it they will have been done.