Commodore PET 4016

[ortek_service]

Well if this circuit is only a stabilised 'regulated' supply, then if a standard rather than Darlington is used for the TIP29, then Motor supply will be around 0.65V / nearly 10% higher.
Measuring this output-voltage (probably best under load of the Datassette motor) on different PET's / the different cassette ports on one PET if only one TIP29 has been changed this time, should show if this varies / what this should be / if it is correct.
And if the motor in the Datasette has some speed-adjustment (either internal or external), then that may also depend on exact input voltage, depending on well this has been implemented.

[julie_m]

Well, I think this might be ready to call a release .....


Refresh test is now performed just once -- it should catch any refresh errors then. (They'll only show up as misreads in the alternate block later anyway, by the nature of a refresh fault; this is looking specifically for ones that appeared after several seconds sitting in a tight loop, in memory that had been zeroed-out beforehand, and displaying a message that will persist long enough to get a picture.)
testrom_11.zip
I made this version so you can actually reprogram the final byte of the EPROM from &FF to &7F to disable the read-modify-write test. This is possible because erasing an EPROM sets all the bits to 1, and programming sets some of them to 0. If you alter the file with a hex editor, you can just reprogram the chip without first doing a blank test (which it would obviously fail). And I made the few spare bytes that were left all &FF, which ought to speed up programming, if only by a tiny bit.

[ScottishColin]

Thanks Julie.

I'll make a start tomorrow.

I need to pop some sockets back in for the ROM chips (and work out which have failed).

Once I've done that I'll start with this version and carefully work my way through the inidicated failed chips one by one and take some photos along the way.

Are there any events you'd like photos taken of in particular and would you prfer I use the 'full' version or the 'quick' one? Or a mixture?

Colin.

[julie_m]

Hi Colin

The "skippable" part of the test is really only important when first testing an unknown PET; it's just to prove the integrity of the screen memory, and sort of gets in the way once that is done.

(If you fancy trying to reprogram location &7FF of a 2716 that has already been programmed with the full test, just to prove that overwriting a "1" with a "0" works, though, be my guest! You will have to skip the blank test, of course).

As far as pictures go, anything "interesting" you can get is fine.

[ScottishColin]

OK - baseline photos here from the following diagnostic tools I have:

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

1. ToePost
2. Tynemouth Diagnostics
3. PETTESTER v4
4. Commodore Diagnostic clip

Points to note:

1. a full Toepost 'run' took c. 47 minutes
2. both PETTESTER v4 and the Commodore Diagnostic Clip can only see 16k of RAM and don't test the upper RAM at all
3. ToePost and the Tynemouth diagnsotic tool slightly differ on where the problems are - I guess we'll see when I start to replace chips tomorrow (Toepost thinks D6, 3, 2, 1 and 0 have failed, Tynemouth reports D7, 6, 3, 2, 1 and 0)

I'll start with D0 and work my way up from there unless anyone thinks that's the wrong place to start.

Colin.

[SiriusHardware]

0, 1, 2, 3, 6 seem common to both Toepost and Tynemouth Diag, so those first, and then D7 if there still seems to be a system problem or 'amount of RAM' problem afterwards.

[julie_m]

I think there's something very funny going on with the address decoding. In the upper memory, it's always addresses ending in &FF that are failing on write and read back. And why is it matching 8 bits of the address? 7 bits I could understand, because that's a whole row or column. Faults at &7F and &FF would be a sign of a duff column. Bits 14, 11, 10, 9 and 8 of the address bus reading back on bits 6, 3, 2, 1 and 0 of the data bus when bits 7-0 of the address bus are all 1 has got to mean something! (I can see bit 0 is always set, which isn't entirely surprising as we wrote 1 in that location.)

I almost wonder if a power or ground trace hasn't gone high-resistance and a bunch of ones on the address lines are enough to create a wrong logic level somewhere downstream ..... or a decoupling capacitor given up the ghost and causing wrong logic levels when everything switches on at once and the capacitor has to do its job .....

What happens if you swap CAS0 and CAS1? That just involves lifting one end of each of R10 and R11 and wiring each one to where the other one came from (see page 31 of the PDF linked in a post above.)

[SiriusHardware]

That's worth another try, now that other faults have been caught and fixed - although the most likely outcome is failure of zero page / page 1 which will impose limitations on what Toepost and other test routines can do.

I wonder if the pragmatic approach here is going to be to socket and replace all of the system RAM and see if it still appears faulty - that's more or less where Colin is headed anyway, having already replaced so many of the RAMs.

I suspect it -will- still appear faulty and that something in the system RAM's life support infrastructure is really to blame, but we will be better able to focus on that once we are sure that every one of the fitted RAMs is OK, in and of itself. Once removable, they can all be tested in one of Colin's other PETs which have at least some of the RAM already socketed.

As someone once remarked on another forum, the best way to test PET RAM is to... put it in a PET.

[ScottishColin]

OK - R10 and R11 swapped and screenshots are here:

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

Summary:

1. PETTESTER unsurprisingly failed at the first screen and wouldn't continue
2. Tynemouth Diagnostics swapped low and high RAM errors from before
3. The Commodore Diagnostic Clip reporting a RAM failure at UA5 (D7) and stopped
4. ToePost gives differing errors than before - it reported that D3, 2, 1 and 0 are failed but no others

I'll put R10 and R11 back in their original place and work from there by replacing D0 and report back.

I still want to see what needs to be done to persuade both the Commodore Diagnostic Clip and PETTESTER to see 32k of RAM that has been installed in this PET.

Colin.

[ScottishColin]

UA18 (D0) replaced - screenshots are here:

https://drive.google.com/drive/folders/1tqzng8Z-P6whtXLKn_Z9U6CihqY1bmDg?usp=sharing

Summary:

1. Commodore Diagnostic Clip still thinks there's only 16K
2. PETTESTER ditto
3. Tynemouth Diagnostics has errors in D0 gone now
4. ToePost still has D0 having a problem, although overall there are far far fewer errors on a whole run.

D1 next.

Colin.

[ScottishColin]

UA18 (D0) and UA16 (D1) replaced - screenshots here:

https://drive.google.com/drive/folders/16BYraEMPWx4KyxlYWF7a-qfDlicAf7As?usp=sharing

Summary - pretty much the same as before except ToePost is happier with D1 now (although it still has the same number of errors as per post 550).

Colin.

[Mark1960]

It might be better to test the upper ram chips after replacement while upper and lower banks are swapped. This might then eliminate the chips as a problem when they are moved back in the upper bank.

[SiriusHardware]

Regarding the problem with Pettester and DiagClip both thinking there is only 16K, maybe both do a rudimentary AA->55 test of the RAM from zero upwards and if they don't get a single correct response from the upper RAM then maybe they assume that the machine only has 16K.

That may also be how the OS decides how much memory the machine has, and I do know from looking in the past that the PET's own power-on memory test is just to write / read 55, write / read AA, from 0000 upwards.

I don't know if Julie can have a look at Daver2's source for Pettester to see how that determines how much memory the machine has?

[julie_m]

It looks as though locations &xxFF are still reading back wrong. But in the latest collection of pictures, D1 in the upper bank seems to be behaving itself. The reason the error count has not gone down is because it's counting locations, not individual bits. So even if D1 is being written and read back correctly in every location, any location with a fault in any bit other than D1 will still count as an error.

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.

("It makes no SENSE, damnit!", she screamed, slamming the whiskey bottle down on the desk. "Why those addresses, even? XXFF is two columns! How can it be reading back wrong like that? And why is bit 1 behaving its ..... self ... now?" There was a break in the cadence of her words as a thought suddenly struck her. "Or could it be reading back fine, but writing the wrong values to those locations somehow?")

Anyway, all the faults are in the upper 16KB. I think it's safe to assume we have a working stack and zero page, so it would be a shame not to use them. I'm going to work on a new test, and this time I get to use all the instructions

[ortek_service]

Originally Posted by SiriusHardware

Regarding the problem with Pettester and DiagClip both thinking there is only 16K, maybe both do a rudimentary AA->55 test of the RAM from zero upwards and if they don't get a single correct response from the upper RAM then maybe they assume that the machine only has 16K.

That may also be how the OS decides how much memory the machine has, and I do know from looking in the past that the PET's own power-on memory test is just to write / read 55, write / read AA, from 0000 upwards.

I don't know if Julie can have a look at Daver2's source for Pettester to see how that determines how much memory the machine has?

If the (RAM) data-bus idles high due to pull-ups / TTL buffers etc, then maybe just reading location 4000h (after writing 0 or anything other than FFh to it) and checking whether it is FFh (for 16K) with any other result meaning that at least one-bit of the upper memory is present) is a simple way to establish memory size (even if the PET also has links for setting this, which does seem a bit unnecessary).

[julie_m]

As far as I can make out, PetTester is writing &55 then &AA in turn to locations &0FFF (which should always work), &1FFF (works on 8K but not on 4K), &3FFF (works on 16K but not on 32K), &7FFF (works on 32K) and &FFFF (won't work, but stops the test) in turn; and stopping when a value written there reads back incorrectly.

I'm not surprised it's failing Colin's PET, which has an issue with &xxFF addresses specifically.

[ScottishColin]

I asked the author of PETTESTER on vcfed - here's his response:

"Hi Colin.

PETTESTER performs a very simple test, starting very low down and working upwards in powers of 2 to sense what memory there could be present by a simple write and readback.

This is so that machines from the humble original 2001 (with partial 6550 RAM) up to 32K can be tested. But it does have the side effect (in the case of (say) an 8032) where a faulty byte in the first byte of the second bank of 16K would cause PETTESTER to only think there was 16K present to test.

There are two ways to approach this...

If the first 16K is OK, you can swap the two banks of 16K over by desoldering one end of the two resistors in series with the /CAS0 and /CAS1 signals and 'swapping the banks over' by crossing the signals such that /CAS0 drives the second bank of 16K and /CAS1 drives the first bank of 16K

Since you have the sources for PETTESTER, bypass my simple memory test and hardcode the amount of memory you 'know' is in your machine.

I have developed PETTESTER to be as 'generic' as I can, so it will work with all models of PET computers and different revisions of the Kernal ROM. However, providing the sources gives you the flexibility to customise it to your specific PET.

Although you have given me an idea for version 5 - to incorporate a macro to permit you to define the actual amount of memory rather than the simple memory test. Version 5 should hopefully have a better test for page 0 and 1 RAM, but I am having difficulty in fitting it all into 2K...

Dave"

[SiriusHardware]

OK, so Julie, could you cook up a version of Pettester which is fixed at 32K RAM size, as Daver2 suggested, to force it to test and show results from the upper 16K?

It would be interesting to see if it then agrees with Toepost, as regards the actual problems being found.

[SiriusHardware]

And sorry, a reminder that if you start from the original Pettester source, the CRTC initialisation values will need to be patched for 40-column as they currently are in Toepost.

[julie_m]

No worries. I've found the tools I think I'm going to need, and I'll be on the case later with a "forced 32K" PetTester with your CRTC initial parameters.