Commodore PET 4016

[ScottishColin]

Yes - there are several which are marked as Ceramic axial .1uF 50V on the BoM.

They are in between the RAM chips - see the location on page 25 (layout diagram) of the .PDF below:

https://www.zimmers.net/anonftp/pub/cbm/schematics/computers...s_4016-4032_Technical_Reference.pdf

Colin.

Originally Posted by julie_m

Are there any small ceramic capacitors (probably 100nF) near the memory ICs? They will be for decoupling the power rails, and all manner of weird stuff could happen if they are bad.

[ScottishColin]

UA18, UA16 and UA14 replaced (D0, D1 & D2). Results below:

https://drive.google.com/drive/folders/17-5h_XPYXGSDNX3aP67sNCYP4-HaAsAN?usp=sharing

Consistent set of results to previous summaries; Tynemouth is progressively happier, PETTESTER and Commodore Diagnostic Clip only see 16K and ToePost has the ff errors as before.

Colin.

[ScottishColin]

Dave has suggested some changes to PETTESTER to force a 32K check in the thread below:

https://forum.vcfed.org/index.php?threads/pettester-versions-and-manuals.1238265/page-2

Colin.

[ScottishColin]

UA18, UA16, UA14 & UA12 (D0, D1, D2 & D3) replaced - screenshots below:

https://drive.google.com/drive/folders/1U3IthEJABNHdPzQRkHqABl33cPYtQgj3?usp=sharing

Consistent reaults as before.

One thing I have noticed - on the low page tests (up to 40), I get 255 plus signs (+) written across the screen. After 40 I don't get any plus signs and that's when the errors start to occur - is that by design?

Colin.

[julie_m]

You should always get 256 characters, one for each byte in the page. Something seems to be going a bit wrong somewhere (the W is showing in position &xx00, but the program is saying the fault is at &xxFF). I'm going to have to check everything again tonight, very carefully ..... I must have awakened some sort of latent fault.

[ScottishColin]

Sorry - but I suppose that's what testing is for.....

Colin.

Originally Posted by julie_m

You should always get 256 characters, one for each byte in the page. Something seems to be going a bit wrong somewhere (the W is showing in position &xx00, but the program is saying the fault is at &xxFF). I'm going to have to check everything again tonight, very carefully ..... I must have awakened some sort of latent fault.

[julie_m]

Oh, absolutely! No matter what fiendish suite of tests you devise in the lab, and how sure you think you are that something just works unconditionally, The Field will always throw something at you that you've never seen before.

[ScottishColin]

Just as a note, I'm using the testrom_11-32K-quick.bin file from the .zip in post 542.

Colin.

[ScottishColin]

OK - UA18, UA16, UA14, UA12, UA6 and UA4 all replaced and the PET now reports 32k if I boot it up, the Commodore Diagnostic Clip reports 32K as does PETTESTER v4. The Tynemouth Diagnostic board now reports no errors.

I'm running v11 of ToePost again as I believe this PET is now full of good RAM (although I haven't done a soak test yet) to see what it reports.

I could have swapped R10 and R11 and got to the duff chips that way I suppose, but that would have meant I had a corrupt page zero again and I'd need to find a tool to fix that (ToePost). Alos if I had done this, the PETTESTER would not have moved on to testing the RAM.

I could also have simply done what Tynemouth Diagnostics reported as that seems to be reporting correctly on this PET.

However, I wanted to help out with ToePost and still do - I have all of the faulty RAM chips labelled and stored so I can put them back in to simulate further errors.

Also I attach a photo of the 12v rail showing that the green covering (I'm sure it has a better name than that) has come off in places. The motherboard is on stand-offs but would it be best if I went over the missing green areas with something like clear nail varnish just to protect it?

Colin.

[julie_m]

OK, I think I have a fix for PetTester to force it to test all 32KB.

It involves editing a copy of your curent PETTESTER ROM image as follows:
Original version:

000002d0  85 0b 85 0d a9 0f 85 0c  85 0e a9 04 85 14 85 05  |................|
000002e0  a9 00 a8 a9 55 91 0d d1  0d d0 23 a9 aa 91 0d d1  |....U.....#.....|

Change to:

000002d0  85 0b 85 0d a9 7f 85 0c  85 0e a9 32 85 14 85 05  |...........2....|
                         ##                 ##
000002e0  a9 00 a8 a9 55 ea ea ea  ea d0 23 a9 aa 91 0d d1  |....U.....#.....|
                         ## ## ##  ##

This will trick it into always testing 32KB; by pre-initialising different values as though it had just tested location &7FFF and passed, and not actually performing the first test, but branching straight to the end as though it had failed.

ToePost had an embarrassing schoolgirl error in it It wasn't updating the variable bt_wr_pos with the write position until after a test had already passed. So basically, it was always one less what it should have been equal to; and when X was 0, bt_write_pos was 255, and it ended up only testing one location. I hope I've improved my abilities with the VICE Monitor in the meantime.

Fixed ToePost:
testrom_12.zip
On an emulated 4016, every address in page &40 seems to read back as &40, and if the test is allowed to go on longer, in general page xx reads as xx everywhere; but I don't know how faithful that is.

[ortek_service]

Originally Posted by ScottishColin

>>
>>
>>
Also I attach a photo of the 12v rail showing that the green covering (I'm sure it has a better name than that) has come off in places. The motherboard is on stand-offs but would it be best if I went over the missing green areas with something like clear nail varnish just to protect it?

Colin.

This is known as Solder-Resist or Solder-Mask and is mainly designed to stop solder-bridges from occurring during the soldering process - particularly 'wave-soldering' where a wave of molten solder flows across the underside of the board and sticks to all exposed metal parts (i.e. the pads and component pins) but not to all the tracks.
It is also often used to protect copper tracks from oxidising looking a bit grotty or getting corroded by contaminants in the air.
However, on this particular board, the tracks have already been tin or solder plated, before the solder resist/mask was applied.
Note: 'FR4' etc. Fibreglass PCB material is actually light grey, but gets coated in between the tracks as well, so ends up looking all green (or whatever colour solder resist is used).

The reason it has flaked-off the larger 'plane'-filled areas is probably due to how it was applied (via a film sheet over the board, then exposed and developed?) and the hot-wave of solder causing it to bubble and crack.
Modern PCB's tend to have a much-better solder resist, that remains very-flat over large areas, even after heating during soldering.
As the flaked-off solder-resist areas are already plated with tin / solder, then there isn't really any need to coat these with anything else.

You can get (moderately-expensive) 'Overcoat' pens from Electrolube? etc. for touching-up the resist, with a similar green-colour liquid-material that dries solid.
Or I have also used a green permanent marker such as Staedtler Lumocolor 318-5 Fine Green, but can be difficult to get these individually and they are usually a bit different shade of green to the existing resist.
You can also spray over entire area with clear 'PCB' lacquer (that you can still solder-through again if required), in order to protect the area and help prevent accidental shorting in future.

Whilst nail varnish might also work, you may have trouble finding the right colour-match, so might make it look worse if not using clear-varnish.
And also need to be careful that there's no chemicals in it that could attack the PCB tracks etc.
I do recall trying to use some to repair etch-resist, when first making a PCB back in the early 80's. But that was only temporary, until it was etched.

[SiriusHardware]

Congratulations to Colin, as always, for patiently and methodically getting to the bottom of all the problems one by one by using the full range of tools available to him, also well done to Julie for creating an entirely new test firmware tool which, now that it is approaching completion, is probably going to be the toughest tester of PET RAM currently available, especially in the way that it looks for errors which could arise in the event of a refresh fault. This was a particularly fine effort considering that no actual PET was available to Julie for use as a test bed.

I hope Julie and Colin can continue to refine Toepost to the point where it can always flag up even really tough faults such as those caused by addressing and refresh faults. You could maybe continue that here since much of the story of its development is here, or start a specific new thread focused on the refinement of Toepost.

Thanks also (Julie) for generating the 32K, 40 column specific version of Pettester which will also come in useful - I think that before now we weren't really aware that Pettester did the 'size' test and then proceeded accordingly so it seems it would be useful to generate different versions to suit different fixed memory size / number of column combinations. From what Daver2 said it sounds as though he was considering making it easier to do that by changing one variable / parameter in the source code prior to assembling the code, so that machine specific versions would be easier to generate on demand. Maybe this could also extend to the generation of the CRTC parameter table, so that it would be relatively easy to specify 50Hz or 60Hz and 40 column or 80 column too.

[ScottishColin]

Thanks for the comprehensive reply. Sharpies are not an issue in this house - also clear nail varnish can be found too.

I'll go hunt.

Colin.

Originally Posted by ortek_service

This is known as Solder-Resist or Solder-Mask and is mainly designed to stop solder-bridges from occurring during the soldering process - particularly 'wave-soldering' where a wave of molten solder flows across the underside of the board and sticks to all exposed metal parts (i.e. the pads and component pins) but not to all the tracks.
It is also often used to protect copper tracks from oxidising looking a bit grotty or getting corroded by contaminants in the air.
However, on this particular board, the tracks have already been tin or solder plated, before the solder resist/mask was applied.
Note: 'FR4' etc. Fibreglass PCB material is actually light grey, but gets coated in between the tracks as well, so ends up looking all green (or whatever colour solder resist is used).

The reason it has flaked-off the larger 'plane'-filled areas is probably due to how it was applied (via a film sheet over the board, then exposed and developed?) and the hot-wave of solder causing it to bubble and crack.
Modern PCB's tend to have a much-better solder resist, that remains very-flat over large areas, even after heating during soldering.
As the flaked-off solder-resist areas are already plated with tin / solder, then there isn't really any need to coat these with anything else.

You can get (moderately-expensive) 'Overcoat' pens from Electrolube? etc. for touching-up the resist, with a similar green-colour liquid-material that dries solid.
Or I have also used a green permanent marker such as Staedtler Lumocolor 318-5 Fine Green, but can be difficult to get these individually and they are usually a bit different shade of green to the existing resist.
You can also spray over entire area with clear 'PCB' lacquer (that you can still solder-through again if required), in order to protect the area and help prevent accidental shorting in future.

Whilst nail varnish might also work, you may have trouble finding the right colour-match, so might make it look worse if not using clear-varnish.
And also need to be careful that there's no chemicals in it that could attack the PCB tracks etc.
I do recall trying to use some to repair etch-resist, when first making a PCB back in the early 80's. But that was only temporary, until it was etched.

[ScottishColin]

OK - the RAM checked out in a PETTESTER soak test so I think we now have known good 32k.

I've replaced UA6 (upper memory D6) with the old faulty chip and the original PETTESTER now goes back to seeing 16k (as expected from previous results).

I'll run both v12 of Toepost and the forced-32k-PETTESTER and report back.

Colin.

[ScottishColin]

PETTESTER changes worked fine - 32k being checked. Screenshot of the memory failure detected attached.

Colin.

[julie_m]

According to Dave's PetTester documentation, that result means: During test 0, sub-test 0, at address &4000, the bit represented by &40 failed; the value read back was &40 (implying 0 must have been written).

That's also what ToePost sees (in fact, since ToePost just carries on testing, it probably will see &40 everywhere in page &40), so I think this probably is a genuine fault.


I've also got a possible explanation for why that might be happening! I think it's just 6502 behaviour; there is enough stray capacitance to hold high-impedance (i.e., tristated) bus lines at the last level they were driven to. (This is evidenced in an episode of Ben Eater's breadboard 6502 series, but I didn't grasp the significance of it at the time.) I think if the 6502 tries to LDA &4000, X then what will happen as this instruction is being processed is, it will read the &00 and shove that and the contents of X through the adder to get the low byte of the address; read the &40 and decide whether or not it needs to pass that through the adder; and because &40 was the last thing it was thinking about, it persists on the data bus (which is hi-Z so it can read) unless something actually drives it high or low. If the memory is faulty in some way that leaves its data input/output floating (or it's just never getting a good CAS) then the high byte of the address bus could well appear on the data lines. And because each bit is stored in a separate IC, if some of them are working and others not, then the working bits will appear "correctly" and the non-working ones will take their values from A8-15.

[ScottishColin]

For future reference, a copy of the .bin file for PETTESTER v4, CRTC enabled that forces a 32k scan.

Colin.

[ScottishColin]

Interestingly, all 6 RAM chips removed from high memory give the exact same failure message as in post 575 when inserted into the UA6 socket. I haven't yet checked the low memory ones I removed.

Colin.

[SiriusHardware]

For future reference, a copy of the .bin file for PETTESTER v4, CRTC enabled that forces a 32k scan.

And I would assume when you say CRTC enabled you mean for 40 columns?

[julie_m]

UA6 is bit 6 in the high bank (&4000 - &7FFF) and all addresses in this range will have A14 set, which is bit 6 of the upper byte.

What does PetTester do if UA6 is not fitted at all? If my understanding above is correct, it should show "mem fail 0 0 4000 40 40!" as, with this bit position unpopulated, any read from the missing UA6 will return bit 6 of the address (possibly not perfectly faithfully, just because it's all happening by accident rather than intentionally).

And that also has me beginning to suspect a dodgy connection to UA6; most probably pin 14 (Data out) or pin 15 (CAS).