Commodore PET 4016

[ortek_service]

Originally Posted by ScottishColin

>>
>>
Could someone educate me regarding my confusion between 0v and earth/ground please?

Thanks.

Colin.

Well 0V will normally be the DC-power return for the +5Vdc etc. power to the IC's.
Whereas Earth is where the mains Earth connects to, and although usually the (metal) case of the equipment, The DC 0V rail doesn't necessarily have to connect to that / might take a bit of a route to there so can end-up with DC voltage offsets
- I've recently been replacing all the dodgy clear-epoxy RIFA capacitors, after one had a burn-up in a Computer Products SMPSU of an HP Dynamic Signal Analyser. And discovered that its 0V common for its DC output rails wasn't directly-connected to the metal casing, but was actually a 7V difference!
This may have been done deliberately to prevent 'hum-loops' as this was designed to make precision low-noise audio etc. measurements.

'Ground' can be used to refer to various things like Earth or 0V DC. And you can having multiple (Power, Signal, Analogue, DC, RF etc) grounds with some IC's etc. that connect to their own separate PCB power-planes that only join at a single 'Star ground' point, to ensure currents don't flow where they shouldn't for best low-signal performance.

Plus Earth (or 'Ground') isn't always connected to the most-negative DC power rail - even on single rail digital systems.
As many old cars & Germanium transistor radios etc.used 'Positive-Earth/Ground' with the DC power rail being negative with respect to this.

Even when ground / Earth / DC 0V area all directly connected, there will be some resistance between these which could lead to different voltage readings. So usually want to find a 0V point close to the voltage you are trying to measure so that you are actually measuring what the IC etc has across it.

Hopefully that's not too confusing, but here's a webpage (mainly focused on USA terminology / power systems) on it:
https://www.allaboutcircuits.com/technical-articles/an-introduction-to-ground/
Although there will no doubt be differences in opinion on the terminology between different publications (The different 'Ground' symbols used by CAD systems and IC datsheets tends to confuse matters even-more, with many traditionally using the mains-earth symbol for their 'DC 0V' ground).

[ortek_service]

Originally Posted by ScottishColin

I've ordered some more RAM but in the meantime we've had another interesting failure.

The screen started to wobble then lost all characters to be replaced with an unusual 'fizzing' type noise from the monitor and a collapsed screen display which swiftly got turned off.

I've taken a look at HSync and VSync on the CRTC chip (page 10 of 11 the schematic) and they both have signals and what I think are the correct frequencies - 50Hz VSync and 20KHz on HSync.

I've then gone to pin 4 and pin 1 of UC2 (same page of schematics) which is marked as F7486PC QM7948 and I can see those waves/frequencies there. What I can't see is them coming out of UC2 on pins 6 and 3 - should I see those waves and frequencies there too?

I have removed the montor plug from J7 while I'm doing all of this testing.

Colin.

Those symptoms / a fizzing sound from the monitor did rather sound like a High-voltage breakdown problem at first.
- But if it has lost Vert-drive, than that might give similar symptoms.

Does the Tynemouth (Composite?) video interface board bypass the apparently failed 7486 ?
- Assuming you have one of these boards? to allow further fauklt-finding on the PET's main board.
Otherwise, will have to wait until video output is restored
- As I assume you haven't got any already-socketed 7486's in the other PET;s that can be temporarily borrowed?

[SiriusHardware]

Earth (which usually specifically means a solid connection to mains earth, or an actual connection to the ground via a buried conductive rod) is not always connected to circuit 0V, although it often is, and in the case of your PETs I think usually is.

Because circuit 0V is not always connected to GND/Earth, I tend not to ask people to measure between test point x 'and Earth' in case they literally do that.

To confuse matters more, the term GND seems more commonly interchangeable and may mean either circuit 0V or Earth, depending on context.

Worrying about this shouldn't take up a whole lot of your time.

Edit: Crossed with Owen.

[SiriusHardware]

Does the Tynemouth (Composite?) video interface board bypass the apparently failed 7486 ?

No, it works by mixing together the TTL-level V_Drive, H_Drive and video_out signals with a dollop of DC bias and attenuation to get composite video, but in order to do this it needs the V_Drive and H_Drive signals which are currently missing in action.

[julie_m]

Just in case anyone else is playing along at home, here's my latest test code.

It fixes a bug that was causing insufficiently-thorough testing, and could have let a fault slip through. It's slower because it's testing each location 8 times, setting one bit in turn and making sure none of the other 255 locations in the block contain a "1". Which is what it was supposed to do before, but because I missed re-zeroing a register it didn't do that everywhere, only testing most locations once and with incorrect values taken from the program code, which might even have included zeros and so left some locations untested. Moral: Just because something looks as though it's working, does not mean it's working.

testrom_05.zip

It still stops on the first error, but I have made sure the potential exists to resume testing after an error is detected. There is actually a thorough visual test of the graphics memory, but it's slow, so I put in a JMP past it -- which you can feel free to NOP out if you desire. You'll probably want to wait for version 6, though.

[SiriusHardware]

Julie: Thanks for your continuing work on this. I've been in touch with Daver2 (author of Pettester) to suggest a tweak which will provide a little bit more feedback about the nature of any read errors found during the screen RAM test and if he is ever able to spare the time that might happen, but experience has taught us that we need as many different test tools as we can lay hands on to obtain a complete picture of what is going on - so please continue on to the bitter end, and I guarantee that your finished test EPROM will be gratefully received and see regular use.

Case in point: Even after the 'read from screen RAM' hardware fault had been caught and shot and Pettester gave the screen RAM the all-clear, The Tynemouth Diag device was still expressing doubt about the screen RAM until a further remedial step was taken and both Pettester and Tynemouth Diag now finally agree that the screen RAM is OK.

As you may have seen the machine has now suffered a mysterious failure of the output drive signals from UC2 and we're going to have to wait a little while before we have a running but still-faulty machine on which to stress-test your code.

[SiriusHardware]

When we get to that point it would be interesting (and reassuring) to see your new more thorough screen RAM test pass the screen memory in this machine, but as it is bypassed with a jump in the version of the test code attached to #225 can you advise which EPROM locations will need to be patched to NOP (= EA?) in order to re-enable it? I don't think Colin is set up to assemble and generate the code from source himself.

[julie_m]

Originally Posted by SiriusHardware

{A}s it is bypassed with a jump in the version of the test code attached to #225 can you advise which EPROM locations will need to be patched to NOP (= EA?) in order to re-enable it?

The quick answer is, at offset &101 into the version 5 binary, change the three hex values 4C 50 E1 (which is JMP &E150) to EA EA EA (which is three NOP instructions).

With that being said, though, I'll very probably have a better version together by the time Colin's PET is out of dry dock, and there is no guarantee those addresses won't change.

[ScottishColin]

No - the Tynemouth diagnostics board requires the 7846 to be fitted to boot up - it won't even chirp if the 7846 is absent from the motherboard, so add that to the long list of chips that if they have failed stop PETs booting.

I've not had a 7846 failure before so I have none socketed in other PETs.

I had made one of these before and was going to use it to continue my work with an external monitor but seeing as the PET won't start in the absence of the 7846 I'm a bit stuck right now I think.

https://github.com/svenpetersen1965/PET-A-V-Interface

Colin.

Originally Posted by ortek_service

Those symptoms / a fizzing sound from the monitor did rather sound like a High-voltage breakdown problem at first.
- But if it has lost Vert-drive, than that might give similar symptoms.

Does the Tynemouth (Composite?) video interface board bypass the apparently failed 7486 ?
- Assuming you have one of these boards? to allow further fauklt-finding on the PET's main board.
Otherwise, will have to wait until video output is restored
- As I assume you haven't got any already-socketed 7486's in the other PET;s that can be temporarily borrowed?

[ScottishColin]

Thanks re clarifying Earth/Groun/0V - I suppose seeing as I've never seen this in PET schematics I'm not used to it.

I'll read that link to see if any of it stays in my brain.

Interestingly on Page 8 of 11 of the schematics, it shows connections to a Ground symbol (R19), a Chassis symbol (R49 and pin 12 of the IEEE-488 interface) and Signal Gnd (several pins from the IEEE-488 interface). These have no connection until the motherboard is screwed into the chassis where the chassis has an earth wire attached to the nut that the motherboard screws goes into.

I suppose in the end when screwed in, all three 'grounds' mean the same thing electronically.

Colin.

[ScottishColin]

Thank you. I'll burn this and try it in my working 4032 so I know what it's supposed to do.

Colin.

Originally Posted by julie_m

Just in case anyone else is playing along at home, here's my latest test code.

It fixes a bug that was causing insufficiently-thorough testing, and could have let a fault slip through. It's slower because it's testing each location 8 times, setting one bit in turn and making sure none of the other 255 locations in the block contain a "1". Which is what it was supposed to do before, but because I missed re-zeroing a register it didn't do that everywhere, only testing most locations once and with incorrect values taken from the program code, which might even have included zeros and so left some locations untested. Moral: Just because something looks as though it's working, does not mean it's working.

Attachment 313703

It still stops on the first error, but I have made sure the potential exists to resume testing after an error is detected. There is actually a thorough visual test of the graphics memory, but it's slow, so I put in a JMP past it -- which you can feel free to NOP out if you desire. You'll probably want to wait for version 6, though.

[ScottishColin]

I patched the .bin file and ran that and I think I prefer the slower version - I can see what's happening much easier.

Also, I think it may be worth (after a suitable 10sec or so pause from a successful test) to clear the screen and loop back and run it again so I could probe when the test is running again?

Colin.

Originally Posted by julie_m

Just in case anyone else is playing along at home, here's my latest test code.

It fixes a bug that was causing insufficiently-thorough testing, and could have let a fault slip through. It's slower because it's testing each location 8 times, setting one bit in turn and making sure none of the other 255 locations in the block contain a "1". Which is what it was supposed to do before, but because I missed re-zeroing a register it didn't do that everywhere, only testing most locations once and with incorrect values taken from the program code, which might even have included zeros and so left some locations untested. Moral: Just because something looks as though it's working, does not mean it's working.

Attachment 313703

It still stops on the first error, but I have made sure the potential exists to resume testing after an error is detected. There is actually a thorough visual test of the graphics memory, but it's slow, so I put in a JMP past it -- which you can feel free to NOP out if you desire. You'll probably want to wait for version 6, though.

[SiriusHardware]

I think it may be worth (after a suitable 10sec or so pause from a successful test) to clear the screen and loop back and run it again so I could probe when the test is running again?

That would work for a screen-only test where you might want to leave a continuous test running as a stress-test but I think here, the assumption is that if the screen memory passes, you don't need to test it again and the test can move on to the next step.

If Julie makes it so it goes back and does another screen test, and another, and another even if the first test was successful, then it will never be able to move on to the zero page / page 1 / main RAM etc tests.

Running a continuous re-test (both write to and read from) after a screen RAM test failure, that would make sense as it would give you continuous screen RAM related signals to take scope readings from.

(Not having either a real PET or an emulated PET, I haven't seen how the test code currently works).

[ScottishColin]

Right. Away to the west coast for a few days in the motorhome. Hopefully the orders will be here when we get back for me to start progressing this.

Colin.

[ortek_service]

Originally Posted by ScottishColin

>>

Interestingly on Page 8 of 11 of the schematics, it shows connections to a Ground symbol (R19), a Chassis symbol (R49 and pin 12 of the IEEE-488 interface) and Signal Gnd (several pins from the IEEE-488 interface). These have no connection until the motherboard is screwed into the chassis where the chassis has an earth wire attached to the nut that the motherboard screws goes into.

I suppose in the end when screwed in, all three 'grounds' mean the same thing electronically.

Colin.

That rather sounds like them creating a 'Star-Ground' system, where the different purpose 'grounds' are only all connected together at one point, in order to prevent 'ground-loops' / ground 'return' currents from one part of the circuitry flowing in the ground of another part of the circuitry which could affect its operation (especially if 'Power ground' return current flows in 'signal grounds' so inducing voltages into that circuitry.

[ortek_service]

That sounds like this 7486 does other things on some of its four 2-input Ex-OR gates, as well as processing the video signals, if the Tynemouth diagnostics board doesn't run with ot being present.
So it's only if one of the other gates (to what had caused the no vertical scan drive display problem) has failed, that the PET wouldn't boot.
- Although it's possible that more than one gate had failed on this faulty 7486 (But PET must have been booting, if video-drive signals were all OK from 6545 - unless that was using some power-up defaults and had yet been programmed by the 6502).

Originally Posted by ScottishColin

No - the Tynemouth diagnostics board requires the 7846 to be fitted to boot up - it won't even chirp if the 7846 is absent from the motherboard, so add that to the long list of chips that if they have failed stop PETs booting.

I've not had a 7846 failure before so I have none socketed in other PETs.

I had made one of these before and was going to use it to continue my work with an external monitor but seeing as the PET won't start in the absence of the 7846 I'm a bit stuck right now I think.

https://github.com/svenpetersen1965/PET-A-V-Interface

Colin.
>>
>>

[SiriusHardware]

Odd that the absence of the IC should have that effect as three of its gates are directly involved in either inverting or not inverting the V_Drive, H_Drive and Video_Out and shouldn't really affect anything else. (Certain models of PET monitor expect one or more of these signals to be 'the other way up' so there is provision to set / choose the polarity of those signals via links, which were set at the factory to suit the monitor which was being supplied with the machine).

The 4th gate is involved only slightly further back in the video-out chain but it not being there obviously has a wider effect than we might at first expect.

No matter, we will see what it does once the replacement 7486 ICs arrive.

[TonyDuell]

As far as I can see that 7486 is only used in the video system and shouldn't, say, prevent the processor from running.

However the Vert_Drive signal can be read via the VIA at UB15 and cause interrupts via the PIA at UB2 (schematic page 3). It's possible the diagnostic checks this and won't do anything if it thinks the video system isn't running.

[SiriusHardware]

Well done noticing that feedback line from VERT_OUT, that's surely all it can be although not working altogether seems a severe over-reaction from a bit of hardware which is supposed to help you to find faults.

Maybe it thinks: No Vert_OUT, nothing can be displayed on the screen, no point in even running. It might even be trying to prevent screen burn, which I suppose could happen if you had H_Out but no Vert_OUT, resulting in a frame collapse.

[ortek_service]

I recall that BBC Computers can sometimes not boot, but hang if the system 6522 VIA is faulty. And seem to recall this generated a (50Hz?) regular interrupt to the CPU that the OS was expecting. (Assuming it wasn't actually that the Keyboard wasn't able to be been read correctly on the 'Slow-Bus' that was implemented by this System VIA, so invalid Bytes may be read as to start-up links etc. if the System VIA isn't working fully).
I can't recall if the Beeb also fed-back the 6845 CRTC VSync / could read this back from registers in that.

So may be a similar problem on the PET, if that is using the 6545 VSync for regular 'Clock Tick' Interrupts etc, that are needed for it to function.
- Although it seems they fed that back a bit later in the chain so also needed the 7486 to be OK.
It does also probably mean that without a working 6545, then you can't do any 'blind keypressing' to see if the CPU is running - Unless it is only the TD board that locks-up without VSync feedback and the PET's Kernal etc does normally still boot without this.