Commodore PET 4016

[ScottishColin]

Yes - just those jumpers.

Colin.

Originally Posted by TonyDuell

What exactly do you change to make it a 16K PET? Is it just the Y and Z jumpers on schematic sheet 6? If so, then a '16K PET' should not ever assert CAS1/ so should never access the upper block of RAM.

Of course there could be a fault in the RAM (meaning it tries to output data when it shouldn't) or in the block select or RAM timing logic on sheet 6

[SiriusHardware]

Re this:

re the x10, both the scope software settings and the probe switch were set to x10, so I'm still not clear what's happening here but for now it doesn't seem to have got in the way of things.

Actually it did, it sidetracked us into thinking there was a problem on the +12V rail for a while. Measuring devices which aren't measuring correctly can waste a lot of time - remember your frequency meter range on one of your multimeters which would display 4MHz and 2MHz but not 1MHz until we fooled the meter into thinking the 1MHz signal was AC rather than Pulse-DC?

Please try measuring the voltage of a battery, either a 9V PP3 or even a 12V Sealed-Lead-Acid battery first with your meter and then with your scope and let us know what you get.

The reason I'm suggesting a battery is that the output from a battery is pretty much guaranteed to be noise and ripple free.

[ortek_service]

Well that 's strange, as if the probe was set to dividing-by-10, then the 'scope should only be seeing 1.2Vdc
- Well within its max +/-5Vdc straight into the input spec.
So something-odd is happening,and probably worth fully-testing the inputs / probes, in case you need to measure these voltages again in future.

If you have a variable DC PSU (even a switchable voltage DC PSU 'mains-adaptor'), then that may be useful for verifying these.
- As would a simple Low-frequency sine or square-wave signal generator that might be built into something you already have, that ideally you could vary the output level of (or wire-up a potentiometer across the output, to tap-off a variable amount).

But trying the other channel / another probe / maybe measure 5V supply with probe set to x1 as well as x10 should be a quick way of verifying you equipment / find out where the problem is.

Standalone 'scopes usually have a 'Cal' output, to check the probes / adjust their frequency-compensation trimmer-capacitor across the x10 divider. But these are usually only 1Vp-p and I presume PC 'scopes don't have this (but may be some have a signal generator output, as do some DMM's etc)

Originally Posted by ScottishColin

>>
re the x10, both the scope software settings and the probe switch were set to x10, so I'm still not clear what's happening here but for now it doesn't seem to have got in the way of things.

Colin.

[ScottishColin]

PP3 battery - meter reads +9.78v

Scope screen attached.

Colin.

Originally Posted by SiriusHardware

Re this:

Actually it did, it sidetracked us into thinking there was a problem on the +12V rail for a while. Measuring devices which aren't measuring correctly can waste a lot of time - remember your frequency meter range on one of your multimeters which would display 4MHz and 2MHz but not 1MHz until we fooled the meter into thinking the 1MHz signal was AC rather than Pulse-DC?

Please try measuring the voltage of a battery, either a 9V PP3 or even a 12V Sealed-Lead-Acid battery first with your meter and then with your scope and let us know what you get.

The reason I'm suggesting a battery is that the output from a battery is pretty much guaranteed to be noise and ripple free.

[ScottishColin]

I do have a (cheap) variable DC voltage power supply. I'll try a few readings and report back on that too.

Colin.

Originally Posted by ortek_service

Well that 's strange, as if the probe was set to dividing-by-10, then the 'scope should only be seeing 1.2Vdc
- Well within its max +/-5Vdc straight into the input spec.
So something-odd is happening,and probably worth fully-testing the inputs / probes, in case you need to measure these voltages again in future.

If you have a variable DC PSU (even a switchable voltage DC PSU 'mains-adaptor'), then that may be useful for verifying these.
- As would a simple Low-frequency sine or square-wave signal generator that might be built into something you already have, that ideally you could vary the output level of (or wire-up a potentiometer across the output, to tap-off a variable amount).

But trying the other channel / another probe / maybe measure 5V supply with probe set to x1 as well as x10 should be a quick way of verifying you equipment / find out where the problem is.

Standalone 'scopes usually have a 'Cal' output, to check the probes / adjust their frequency-compensation trimmer-capacitor across the x10 divider. But these are usually only 1Vp-p and I presume PC 'scopes don't have this (but may be some have a signal generator output, as do some DMM's etc)

[ScottishColin]

Evening. UA15 replaced but I still get zero page failed errors.

Are there other screen shots that I could take that might be useful?

I'm letting the v9 code run for a while now and will take a phot of that when it has gone through all of the page checks.

Colin.

Originally Posted by julie_m

Check the IC responsible for D2 in the low bank -- I think it's UA15. It could be a duff chip, or it could be a poor connection on some of the address pins.

[SiriusHardware]

I know it's a bore but can you check you have continuity between UA15 pins (2, 14) and the 6502 DA2 pin (31)?

Interesting that your scope seems to measure the battery voltage OK - it suggests that maybe the 0V you were using for your scope on the mainboard wasn't really 0V, or possibly even that somewhere which should be a legitimate 0V point isn't, due to a fault.

Where exactly are you attaching your scope GND lead to when making the measurement of the +12V rail to the RAMs? Measure for continuity between that point and the -Ve end of the large electrolytic capacitor on the mainboard.

[ScottishColin]

Confirmed continuity between all three pins in post 427.

I was using pin 1 of a brand new 4116 for ground, and also used the -ve end of C7.

And the scope is now showing +12.1v on pin 8 so I'm really not sure what happened there. At the very least it seems OK now, but it makes me realise that sometimes I need to use two different bits of equipment just to make sure I'm getting the correct reading.

fyi, PETTESTER now runs and is running a memory test right now so UA15 has nudged us forwards I think. I don't quite understand how Julie's code can give use zero page failures and yet Dave's code is now running. Beyond me I'm afraid.

What is also interesting is that Dave's code seems to be convinced that there's only 16k in this PET at the moment as that's the memory test it is running.

I won't be touching anything (ie replacing anything) yet. I want to help out with the development of ToePost with an apparently broken PET.

Colin.

[julie_m]

As far as why ToePost reports errors where Dave's PetTester ROM doesn't goes, there are two possible explanations.

One: There's a real fault that Dave's code isn't picking up but mine -- which is testing zero page pretty hard -- is.

Two: My code is giving a false positive when running on real hardware.

We also should not discount the RAM refreshing circuits. I'll take a look at the schematic and see what's going on there.

EDIT: There are a couple of 74177s, UE6 and UE7; and a 74LS244, UE8, refreshing the memory.

Actually, there's a third possible explanation: I could have somehow stopped the memory from being refreshed at all with something my code is doing. EDIT: I don't think so. There doesn't seem to be anything like an enable signal for the refresh.

Zeroing out a block of memory and testing it straight away might well be refreshing it "by accident", only for the contents to change during the pause between test cycles, for want of refreshing. And that's a hardware behaviour that's never going to be emulated faithfully .....

What does ToePost do in the working 4032? (You needn't run it for too long; just the workspace, stack and zero page tests will be enough.)

[ScottishColin]

4032 first screeen attached.

Colin.

Originally Posted by julie_m

As far as why ToePost reports errors where Dave's PetTester ROM doesn't goes, there are two possible explanations.

One: There's a real fault that Dave's code isn't picking up but mine -- which is testing zero page pretty hard -- is.

Two: My code is giving a false positive when running on real hardware.

We also should not discount the RAM refreshing circuits. I'll take a look at the schematic and see what's going on there.

EDIT: There are a couple of 74177s, UE6 and UE7; and a 74LS244, UE8, refreshing the memory.

Actually, there's a third possible explanation: I could have somehow stopped the memory from being refreshed at all with something my code is doing. EDIT: I don't think so. There doesn't seem to be anything like an enable signal for the refresh.

Zeroing out a block of memory and testing it straight away might well be refreshing it "by accident", only for the contents to change during the pause between test cycles, for want of refreshing. And that's a hardware behaviour that's never going to be emulated faithfully .....

What does ToePost do in the working 4032? (You needn't run it for too long; just the workspace, stack and zero page tests will be enough.)

[julie_m]

Right, no errors on the known-working board. ("Failed 0000 errors" is a consequence of a change I had made to help distinguish on screen between two different failure conditions and then got so busy forcing errors, I forgot about what would happen if no errors were detected. It will be fixed in the next version .....)

That means it doesn't stop refreshing the dynamic RAM when it's running code from the Editor ROM. So that exonerates my code, and I am not doing a little victory dance or anything

I'll return to the schematics and get working out where to probe the refresh logic .....

[TonyDuell]

The refresh address comes from the counters UE6 and UE7 (sheet 6) and is sent to the RAM via UE8 (I think, the printing is none-too-clear in the diagram I'm using -- on sheet 5)

Given the problems you've had with 74LS244s, is UE8 good?

Then check the outputs of UE6 and UE7 (signals RA1 to RA7). You should see a square wave on each of them, halving in frequency as you go down the counters.

[ortek_service]

Originally Posted by SiriusHardware

>>
>>
Interesting that your scope seems to measure the battery voltage OK - it suggests that maybe the 0V you were using for your scope on the mainboard wasn't really 0V, or possibly even that somewhere which should be a legitimate 0V point isn't, due to a fault.

Where exactly are you attaching your scope GND lead to when making the measurement of the +12V rail to the RAMs? Measure for continuity between that point and the -Ve end of the large electrolytic capacitor on the mainboard.

Well that 9.78V did seem a little-high for a PP3 - even a brand-new one.
Although I couldn't see that reading in the screenshot Colin had attached - Only 9.73V Max, 9.57V? Min. - Which did indicate quite a bit of 'noise/ripple' from this DC voltage-source battery. So not sure if the 'scope also displays an 'average' of these measured DC levels, as that might be rather closer tho that expected / may be comparable with what the DMM will read?

It does seem that maybe the 'scopes ground was somehow connected to a +3V level, to give that offset. Although there's not too-much that would have normally been at that level.
I did also wonder if the 'scope was 'maxing-out' / clipping at 9V (actually 0.9V if using a x10 set probe). So if Colin's adjustable DC PSU - in parallel with DMM as an accurate reading - can be used to do some measurements upto 12V (or maybe more, to as high as it goes / <=50V) - assuming using a x10 probe = then that should hopefully verify the 'scope / probes operation.

EDIT: Just catching up on posts, I see that Colin has now got the 'scope reading 12V OK. So must have been an issue with how it was originally connected!

[SiriusHardware]

Well that 9.78V did seem a little-high for a PP3 - even a brand-new one.

A Lithium version, possibly? They usually read well over 9V when new.

[SiriusHardware]

Given the problems you've had with 74LS244s, is UE8 good?

Already socketed and replaced early on in the thread, but all of these devices are getting on a bit now. Swap UE8 with another 244 somewhere else on the PCB and see if that changes the nature of the fault?

[ScottishColin]

UE8 replaced with one from the 4032 which passed the test and I still get zero page errors, albeit with a different number of errors (attached).

I'll put some pictures up this afternoon of RA1-RA7 as they're not as you described, either on UE6/UE7 and UE8.

Colin.

Originally Posted by TonyDuell

The refresh address comes from the counters UE6 and UE7 (sheet 6) and is sent to the RAM via UE8 (I think, the printing is none-too-clear in the diagram I'm using -- on sheet 5)

Given the problems you've had with 74LS244s, is UE8 good?

Then check the outputs of UE6 and UE7 (signals RA1 to RA7). You should see a square wave on each of them, halving in frequency as you go down the counters.

[ScottishColin]

Tesco's cheap "Extra Long Life" Alkaline. I bought a twin pack and they both measured the same.

Colin.

Originally Posted by SiriusHardware

A Lithium version, possibly? They usually read well over 9V when new.

[ScottishColin]

OK - here's a couple of .ZIP files.

Both tests undertaken with v9 of Julie's code running, scope GND attached to the -ve end of C7 in both PETs.

One showing nice healthy signals with appropriate frequencies from the 4032.

Another showing frankly a load of rubbish from the 4016.

I tested the scope with this configuration on a couple of RAM chips and I got square signals just in case there was a GND problem with the scope.

I'm confused how anything's working right now.

Colin.

[TonyDuell]

I would draw 2 conclusions from those results:

1) As the waveforms in the working PET are as I described them, my understanding of the circuit is likely to be correct.

2) The mess in the defective PET suggests at least one and possiby both of the 74177s have failed. I'd replace UE6 which should restore RA1-RA4, if RA5-RA7 are still wrong then also replace UE7. UE7 is clocked from an output of UE6 so depends on UE6 working to give the right outputs.

[ScottishColin]

Although the BOM and the schematics state 74177, what's actually fitted in UE6 and UE7 is 74LS197.

I don't have either so we're on pause again for a little while - is there any preference for either the 74177 or a 74197?

Colin.