Commodore PET 4016

[ScottishColin]

OK - changes made to configure the board to 32k.

However, PETTESTER still thinks it's a 16k machine, but the memory tests are now working (albeit 16k only).

Tynemouth diagnostics is reporting 6 failed memory chips in upper RAM so I wonder whether they are affecting the PETTESTER memory testing?

Hmmm.

My understanding from p25 of the manual's .pdf is that I have set it correctly.

http://cini.classiccmp.org/pdf/Commodore/CBM%204016-4032%20Tech%20Ref.pdf

I suppose in the end I could replace all of the RAM chips as so many seem to be faulty or on the edge, but I'd prefer to replace only those that we can confirm are faulty really.

Colin.

[Mark1960]

I think it would also be good to wait for Julie’s latest version before making any more ram changes, if only to see what her tests can find that your other test can’t.

[SiriusHardware]

I'm assuming Colin is socketing the RAM as he goes, so - best of both worlds - he can fit a new RAM to see if it fixes the problem but also retain and mark the faulty RAM removed from that position and put it back in to recreate the fault for the benefit of Julie's test software if needed. Although - if Julie's test code can finger a specific chip or two that would avoid having to disturb others unnecessarily.

Julie, you are going to have to think of a name for your finished Utiliitie(s) - Dave has his 'Pettester', on the hardware side we have things like the 'Romulator' - yours will need to have a name so that in future we can just say 'Run (InsertNameOfYourUtilityHere) and see what that shows'.

[ScottishColin]

Every chip I remove I label so I know where it came from if I need/want to put it back for whatever reason.

I have one chip for example that passes Julie's current tests and fails the PETTESTER tests consitently. That might be useful for future test programs.

Colin.

[julie_m]

Sorry for the delay -- this is proving a little harder to debug than I was expecting.

It's doing the tests beautifully; it's just not quite telling the truth about what it's doing, which is not what you want in a testing program .....

[julie_m]

Found it! Someone didn't understand how her own code works You have to poke the values into the right locations .....

Anyway. As promised, this version just tests one page of memory after another. As it tests each page, it's also doing a test for address clashes against the last page tested.

I've added a little map showing the bits where write and read errors were detected in any byte. There are two groups of digits displayed in inverse at the end of the on-screen memory map:

The left group of digits will change to W on a write failure in the corresponding bit in any byte, and the right group will change to R on a read failure in the corresponding bit in any byte. This will show which bits are failing.

ZIP file with ROM images for 16K and 32K tests, with source code:
testrom_08.zip

[julie_m]

Never mind -- spotted another issue, which is fixed here. My experimental code was causing the ROM image to overflow bigger than 2Kbytes, so I had to cut some of it out. Ah, well, there'll be room for it in another 2732 .....

testrom_08-fixed.zip

[ScottishColin]

OK - two failures, one on the 16K code and one on the 32k code.

The PET is now configured as a 32k PET so in theory all memory is available for checking.

So far, I have replaced the following RAM chips all in lower memory:
UA7 (D6)
UA9 (D5)
UA11 (D4)
UA13 (D3)
UA19 (D0)

No RAM chips have yet been replaced in upper RAM.

Colin.

[ortek_service]

Originally Posted by ScottishColin

OK - two failures, one on the 16K code and one on the 32k code.

The PET is now configured as a 32k PET so in theory all memory is available for checking.

So far, I have replaced the following RAM chips all in lower memory:
UA7 (D6)
UA9 (D5)
UA11 (D4)
UA13 (D3)
UA19 (D0)

No RAM chips have yet been replaced in upper RAM.

Colin.

Does that mean the memory now all works OK - the lower 16K at least?

And on all Diagnostic Testers, without any locking-up?

- I'm surprised 'D0', 'D3' & 'D4' also needed changing, if faults had only been found on 'D6' & 'D5' in the lower 16K ?
But I presume one of the Testers must have found a problem with these as well?

[julie_m]

Originally Posted by ScottishColin

OK - two failures, one on the 16K code and one on the 32k code.

The PET is now configured as a 32k PET so in theory all memory is available for checking.

Any chance of a picture?

[SiriusHardware]

OK - two failures, one on the 16K code and one on the 32k code.

I'm scratching my head a bit as well - what was it that identified these failures, was it a joint effort by more than one diagnostic tool or did you need to use a combination? Ideally we want to get to the point where we have one infallible mega-tester which never misses a system RAM fault.

[ScottishColin]

Apologies; I meant to attach these two pictures.

Colin.

Originally Posted by julie_m

Any chance of a picture?

[julie_m]

That's showing a fault on D3. (And showing an error on my part; I forgot to add alternate-page misreads to the bit maps ..... Well, that's fixed now.)

Does the fault move about if you swap the RAM chips about?

Here's my latest effort: (No screenshot, as there's so little to see)
testrom_09.zip

It doesn't stop if there are any failures in pages 0 or 1, it just ploughs on with testing up to 32K and starts again from page 0.

[ScottishColin]

This PET is haunted.

Back to video errors now after nothing other than running a 1.8 test and rebooting it.

Colin.

[ortek_service]

Well assuming the (previously-replaced) 2114's haven't now decided to fail - At least easy to check, by swapping with others / trying in another PET
Then no doubt it's one of the buffers playing-up
- Are there any that haven't been changed yet?
And are all of these now socketed, to allow easy (re)checking by substitution of these?


I'm still confused by how many / which of the main-memory DRAM's were actually faulty - As from screen shots it seemed that only one bit (Misread Byte = 08, so bit 3) was affected.
And with all 32K enabled, it still seemed that errors were occurring in zero page / stack area in lower 16K?

[SiriusHardware]

This PET is haunted.

Congratulations, Minecraft on a PET!

I this may be a new failure (of something which hadn't previously failed) but as per Owen, as you already have the video RAMs and the associated buffers socketed then of course eliminate them by substitution first, as it is the easy thing to try.

However it looks as though you have lost whatever takes the content of the screen RAM and renders it to the screen as characters, the only part that is working is the inversion of the screen when one of the upper bits in the screen memory location is high.

The chip which takes the parallel data from the character ROM and converts it to a serial stream of pixels is UA2 / 74166. Just check that the character ROM is still properly seated first.

Look at these pins of UA2:-
Pin 13 for high speed random-looking data (video)
Pin 7 (CK) for clock signal
Pin 15, (S/L), what activity do you see there?
What state or activity do you have on pin 6 (CKINH)?
Pins 2, 3, 4, 5, 10, 11, 12, 14 for random looking digital activity.

[julie_m]

At this point, I'm more inclined to suspect a problem with the motherboard or power supply than a whole bucket of faulty ICs.

The -5V supply is only used for the RAM and if there was anything amiss with it, zeros might well read as ones.

[ScottishColin]

This 4016 motherboard is in the 4032 chassis using that power supply so I'm currently ruling that out (although that might be wrong in the end I suppose).

Colin.

Originally Posted by julie_m

At this point, I'm more inclined to suspect a problem with the motherboard or power supply than a whole bucket of faulty ICs.

The -5V supply is only used for the RAM and if there was anything amiss with it, zeros might well read as ones.

[ScottishColin]

I started replacing them from post 211 onwards as a result of the Tynemouth disgnostics information.

Colin.

Originally Posted by ortek_service

Well assuming the (previously-replaced) 2114's haven't now decided to fail - At least easy to check, by swapping with others / trying in another PET
Then no doubt it's one of the buffers playing-up
- Are there any that haven't been changed yet?
And are all of these now socketed, to allow easy (re)checking by substitution of these?


I'm still confused by how many / which of the main-memory DRAM's were actually faulty - As from screen shots it seemed that only one bit (Misread Byte = 08, so bit 3) was affected.
And with all 32K enabled, it still seemed that errors were occurring in zero page / stack area in lower 16K?

[SiriusHardware]

Unfortunately experience with Colin's PETs - this is his... sixth one now? (I'm losing count) has shown that these machines often are mass chip extinction events. It must be something to do with plastic packaged ICs not coping very well in a sustained damp environment.

Even so Colin, you could assuage Julie's doubts by scoping the regulated supply rails to see if there are undue amounts of noise on them.

I seem to recall your PC-based scope doesn't have an 'AC' coupling mode - a limitation of the hardware - so you'd need to connect your scope probe tip to the point of interest via a capacitor, say 0.1uF or 0.47uF (non electrolytic) in order to look for a relatively small amount of high frequency noise in the presence of a much greater DC offset voltage.

Looking at the power rails in 'normal' DC coupled mode should also show you whether there is excessive low frequency ripple on the supply voltages - they should all look like a stable, straight line with no regular bumps or 'sawtooth' shape superimposed on them.