Commodore PET 8032-SK

[SiriusHardware]

OK - UD5 (11) working as expected, it's just that Dave's Pettester is not accessing the associated area of memory when it is looping on the test it sticks on - using the NOP test forces the CPU to access all areas / activate every memory address.

The captures so far don't look too bad actually - when looking at the raw databus, what you are seeing is different ICs all over the system accessing the same data line at different times. Some of them have higher drive output strengths than others so that manifests itself as a mixture of different logic '1' levels visible on the data line.

True 'half-levels' are what happen when you have two adjacent lines shorted together - the half-levels occur when one of the two shorted lines is trying to drive the line high, and the other one is trying to drive it low. The other giveaway would be that the two shorted lines would have absolutely identical looking signals on them - which is almost unheard of for data lines. I haven't seen this in what you have posted so far.

I'll assume you are about to post further DRAM pin 2 captures before continuing.

[ScottishColin]

Next 4 - I have been wrestling with a silent Windows 10 update which managed to delete the driver for the scope (or at least 'update' it to one that doesn't work).

Colin.

[ScottishColin]

Last image.

My recollection is that Dave's code needs the first 1k of RAM to work to be able to progress.

Colin.

[SiriusHardware]

UA14 pin 2 (which should be D2) does look a bit unorthodox doesn't it? Bearing in mind that that is the socketed IC, socketed by someone else, and I know you've already speculatively changed it to no obvious good effect, can you also check D2 under the exact same operating circumstances on the following pins:

UA14 pin 14
UA15 pin 2
UA15 pin 14

6502 pin 31

Depending on what we see there we'll try the CAS0 / CAS1 swapover trick next to swap over the upper and lower banks of RAM and see what effect that has.

[SiriusHardware]

Just in case I'm not around later, a reminder that the bank swap trick is to unsolder the outgoing ends of R10 and R11 and route each one to the hole that the other was originally in, thereby swapping over the drive signals to the memory CAS0 and CAS1 lines.

[ScottishColin]

UA14 pin 14 attached; again 2 files showing differing readings.

UA15 pin 2 is the same as UA14 pin 2 and UA15 pin 14 is the same as UA14 pin 14.

6502 pin 31 attached - clean pulses but the voltage seems a little low (3.39V) - will that affect anything?

I'll swap over the resistors but this may be tomorrow.

Colin.

Originally Posted by SiriusHardware

UA14 pin 2 (which should be D2) does look a bit unorthodox doesn't it? Bearing in mind that that is the socketed IC, socketed by someone else, and I know you've already speculatively changed it to no obvious good effect, can you also check D2 under the exact same operating circumstances on the following pins:

UA14 pin 14
UA15 pin 2
UA15 pin 14

6502 pin 31

Depending on what we see there we'll try the CAS0 / CAS1 swapover trick next to swap over the upper and lower banks of RAM and see what effect that has.

[ortek_service]

Originally Posted by ScottishColin

Not got to it yet. I'd rather replace only those chips that have failed rather than remove the lot.

I've not mentioned - one RAM chip has been replaced before I got it and is socketed so I could likely put a new replacement chip in that socket and use that as a reference.

Colin.

Well it seems a previous repairer got quite-lucky, if they managed to find the one in sixteen of these which had originally failed.
But having a socket there (plus a replacement DRAM IC) - as well as now many other logic IC's being socket-ed / replaced, does mean it will never be totally original so having a few more DRAM's socket-ed shouldn't matter too much.
And if they are carefully removed, with no damage, then they can always be put back into sockets if proved to actually be OK. Plus having these socket-ed does make any future repairs / checking of the DRAM's rather easier.

So having at least one bank of eight 4116's socket-ed would probably be useful - particularly if it does appear that many of these could be faulty so do need swapping.

However, if the diagnostic utilities do show what resulting data-value is being read back, as well as what was written that doesn't match, at an address that failed, then it should be possible to work-out what databits are stuck and the corresponding DRAM IC(s).
But I presume working Screen-RAM etc. is required, for this to be able to be displayed, unless diagnostic could output message on I/O ports.

[ScottishColin]

I'm going to try to play the game of only replacing those that need replacing for as long as people entertain my ham-fistidness here.

The video sub system is sorted now though - all works fine with RAM provided by the Tynemouth board and using on-board ROMs so I know they work too.

Colin.

Originally Posted by ortek_service

Well it seems a previous repairer got quite-lucky, if they managed to find the one in sixteen of these which had originally failed.
But having a socket there (plus a replacement DRAM IC) - as well as now many other logic IC's being socket-ed / replaced, does mean it will never be totally original so having a few more DRAM's socket-ed shouldn't matter too much.
And if they are carefully removed, with no damage, then they can always be put back into sockets if proved to actually be OK. Plus having these socket-ed does make any future repairs / checking of the DRAM's rather easier.

So having at least one bank of eight 4116's socket-ed would probably be useful - particularly if it does appear that many of these could be faulty so do need swapping.

However, if the diagnostic utilities do show what resulting data-value is being read back, as well as what was written that doesn't match, at an address that failed, then it should be possible to work-out what databits are stuck and the corresponding DRAM IC(s).
But I presume working Screen-RAM etc. is required, for this to be able to be displayed, unless diagnostic could output message on I/O ports.

[SiriusHardware]

6502 pin 31 attached - clean pulses but the voltage seems a little low (3.39V) - will that affect anything?

Not necessarily, although it could point to something loading that data line (which, remember, goes all over the system and isn't only connected to pin 31 of the CPU - so that short burst of activity you caught could be from anything on the system).

We may have to take the further step of looking at the data lines from the DRAMs again, but this time triggering from the chip enable lines of the DRAMs so we can home in on the states of the data lines at the actual moment at which the DRAM is being enabled onto the data bus.

First try the bank swap test, because if just the first part of the other bank is working then that will give pettester enough wiggle room to proceed on to the other tests. It comes under my heading of 'things which are quite easy to try and could yield useful results'.

[SiriusHardware]

Just to recap how the first stage of the zero page test is carried out by Daver's Pettester:-

-It only gets there once the screen RAM test has passed, which apparently it now does since UB9 was replaced.

-It fills (or attempts to fill) the 256 bytes of zero-page with the consecutive values 00 through to FF and then reads them back. The result from those 256 zero page bytes is shown in two different ways in two blocks of 256 consecutive character cells on the screen.

The first 256 character cells on the screen show a 'g' (for 'good') if the value read back from the corresponding zero-page memory location matches the value which was attempted to be written to it. If the value read back does NOT match the value which was attempted to be written to the memory location, it displays a 'b' (bad) instead.

Let's say the third character on the screen shows 'b' while all other characters in the first 256 displayed are 'g' - that means that reading from the third location in zero page (02h) did not give the expected value of 02h.

The second group of 256 characters in the output from Pettester also represent the 256 locations of zero page, but this group shows a 'dot' (period) for each location from which the expected value was successfully read back. For each location where the value read back was NOT the value expected, Pettester outputs the PETSCII character corresponding to the code / value which was read back instead of a 'dot'.

Armed with a PETSCII table, we know which of the codes 00 through to FF correspond to which PETSCII characters, so by looking up the code of the displayed character and comparing it with the code which should have been placed in that zero page location to see what the difference between them is, it should be possible to work out which bit(s) in those locations in zero page are faulty.

Pettester also tests Page 1 of the RAM and displays the results from that in the third and fourth group of 256 character display cells just as described for zero page above, so on an 80-column PET the Page 0 / Page 1 test will output 1024 characters altogether.

[ScottishColin]

Screen images attached showing pre and post R10 and R11 swap. It's changed, but the test does not move on.

Colin.

[ScottishColin]

Something I have noticed is that for the first 30 seconds or so of the test, some of the b and g characters change. Then it stops to display a steady screen.

See video link:

https://drive.google.com/file/d/1mmlwPlc7A6uCgX_FXkbb7C2m1j-5n1b8/view?usp=sharing

Colin.

[SiriusHardware]

OK, swapping the CAS signals was worth a try but it has told us that the first 256 bytes of the upper RAM bank is also unusable - you can put the resistors back as they were.

Thanks for including the hi-res shots as the forum did render the embedded versions hard to read.

I don't know what to make of the video footage yet and actually I didn't see the point where the items you mentioned stopped changing - maybe I misunderstood what we were looking for. A special request from me when shooting video in future, please turn the phone on its side when videoing because my (PC) screen is landscape format, as are just about all TVs and laptop screens. The more the footage fills our screens to each far corner, the more chance we have of seeing the smaller detail.

Let's grind onwards.. on each of the DRAMs can you please scope the following pins with the NOP test running:-

5, 7, 6, 12, 11, 10, 13 (look for activity)

4, 15 (Look for activity).

The signal should look the same on all of the pin 5s, and it should look the same on all of the pin 7s, the same on all of the pin 6s, same on all of the pins 12s, and so on.

Remember when you replaced the UD8 ROM and for a time had worse problems than you had originally had until you got back on top of it - I'm wondering about the possibility that something similar may have happened when someone socketed that RAM IC at some time in the past.

For that reason could you please also meter for continuity between the following sets of pins:-

CPU (26), (UA4 (2, 14), UA5 (2, 14) and UD8 (17)

CPU (27), (UA6 (2, 14), UA7 (2, 14), and UD8 (16)

CPU (28), UA8 (2, 14), UA9 (2, 14), and UD8 (15)

CPU (29), UA10 (2, 14), UA11 (2, 14), and UD8 (14)

CPU (30), UA12 (2, 14), UA13 (2, 14), and UD8 (13)

CPU (31), UA14 (2, 14) UA15 (2, 14) and UD8 (11) * note pin 12 skipped

CPU (32), UA16 (2, 14) UA17 (2, 14) and UD8 (10)

CPU (33), UA18 (2, 14) UA19 (2, 14) and UD8 (9)

[ortek_service]

Originally Posted by ScottishColin

Something I have noticed is that for the first 30 seconds or so of the test, some of the b and g characters change. Then it stops to display a steady screen.

See video link:

https://drive.google.com/file/d/1mmlwPlc7A6uCgX_FXkbb7C2m1j-5n1b8/view?usp=sharing

Colin.

Well I presume that's due to the test endlessly-repeating and that the (most likely only one) bit(s) in error at those locations that occasionally show 'g' do sometimes read-back OK.
So might be an indication of only one DRAM (in each bank) that's faulty at those locations.

But it's probably easiest to ignore those intermittent ones for now and start right at the first byte of page0 RAM which (like most bytes after it) is showing constantly bad.
And as 0 should be being written to that location, then if you can work out the bit-pattern of the corresponding (first one after the g/b's ? as no Linefields inserted) displayed PETSCII
- Assuming there is actually a corresponding displayable character for all 256 PETSCII characters - unlike with ASCII?
(It would have been more-helpfull if hex values had been displayed, preferably with spaces in between, to make it easier to read)

Also, Just counting-up and storing that value in each location is a rather-flawed memory test as it does test that any bit at a location isn't stuck low or high. You need to re-test each location with an inverse of all the bits in the originally-written bit pattern, to properly test it.
And it's normally easier to just test all locations with 00 /FF or (55 & AA), although that may not check for shorts between / stuck address-lines, without doing an up then down test and alternating bits pattern between these passes.

[SiriusHardware]

If the zero page test passes the first hurdle then it does go on to do further bitwise tests, I think.

[ortek_service]

Originally Posted by ScottishColin

Screen images attached showing pre and post R10 and R11 swap.
It's changed, but the test does not move on.
Colin.

Originally Posted by ortek_service

>>
>>
But it's probably easiest to ignore those intermittent ones for now and start right at the first byte of page0 RAM which (like most bytes after it) is showing constantly bad.
And as 0 should be being written to that location, then if you can work out the bit-pattern of the corresponding (first one after the g/b's ? as no Line-Feeds are inserted) displayed PETSCII
- Assuming there is actually a corresponding displayable character for all 256 PETSCII characters - unlike with ASCII?
>>

Well I've cropped (after rotating slightly by a degree, to straighten) the screenshot that Colin had attached, to just show the contents on the screen that are of interest. And I've re-attached this (including a zipped-up version to avoid extra compression), to hopefully make the actual resulting characters (I have checked that 256 of these do appear, between end of page 0 256off b/g's and start of page 1 b/g's).

However, I'm struggling to work out what code results in a reverse-video lower-case 'w' that is being-shown for the first few Bytes.
As this PETSCII wikipedia page: https://en.wikipedia.org/wiki/PETSCII is far from clear and doesn't show this on the maps
(and seems to imply that for reverse video, you need to send the RVS ON code first)

This is a little-more helpful, showing actual displayed characters in 2nd column: https://www.c64-wiki.com/wiki/PETSCII_Codes_in_Listings But I can only find Reverse-Video Upper-case characters, with Reverse-video 'W' = Ctrl+'W' = 17h.

So maybe the more-experienced Commodore users can explain what actual Byte-value is being read when reverse-video lower-case 'w' is being shown ?
- in order to try and work-out which databits are stuck-high, when all should be low at address 0.

[SiriusHardware]

Colin, on one of your working PETs write a program which POKEs every value from 0 to 255 into successive screen RAM locations - maybe from halfway down the screen onwards rather than the very start - and see if any of the characters produced on-screen is a lower-case inverse 'w'.

Edit: Belay that, I've just cropped the attached image from Daver's manual for pettester and this shows what appears on the PET screen when the screen RAM is flooded with the values 00-FF over and over again. I've clipped only one complete cycle of 00-FF, with the sequence beginning to repeat again at '@' about halfway through the last line.

It would appear that bit 7 high signals 'this character is inverse' so the codes of the non-inverted characters run from 0 to 127 decimal / 00 to 7F hex, with the codes for the inverse characters running from 128 to 255 / 80 to FF Hex.

Counting from 80h at the start of the inverse characters, I make the code for inverse lower case 'w' to be 151 dec / 97 Hex.

[ortek_service]

I did notice on the Wikipedia page that the 'Control' characters (which oddly went upto 159) differed between the PET 2001 and the 8032 (as well as other Commodore systems).
So not sure if that affects the lower-values (<32) of what is displayed in the full non-shifted & shifted character sets

EDIT: I've just seen this update to previous message:

Originally Posted by SiriusHardware

>>
Edit: Belay that, I've just cropped the attached image from Daver's manual for pettester and this shows what appears on the PET screen when the screen RAM is flooded with the values 00-FF over and over again. I've clipped only one complete cycle of 00-FF, with the sequence beginning to repeat again at '@' about halfway through the last line.

It would appear that bit 7 high signals 'this character is inverse' so the codes of the non-inverted characters run from 0 to 127 decimal / 00 to 7F hex, with the codes for the inverse characters running from 128 to 255 / 80 to FF Hex.

Counting from 80h at the start of the inverse characters, I make the code for inverse lower case 'w' to be 151 dec / 97 Hex.

Well that would indicate that rather than reading all databits as 0, 10010111 is actually being read.
Which implies that the (Lower-bank, assuming Upper ones are being disabled correctly and aren't conflicting) DRAM IC's connected to Databits D7, D4, D2, D1 & D0 are all faulty at that location 0 at least!
- So virtually all of these might need replacing (in the lower-bank at least, although the upper bank also seemed to have many errors).
I wonder if changing the one already socket-ed affects this displayed result / whether changing one of the DRAM's on those incorrect databits and then repeating does then show a different result with that databit now OK, just to prove it was the cause before changing many of these.

This is assuming there isn't any remaining buffers not already changed, that could be causing so-many faults.
(Or maybe an issue with the RAS / CAS timing that is on-edge and could also explain some 'b' / 'g' fluctuations ?)

However, that display from the manual is maybe a little confusing, as 'a' is at address 1, following '@' at address 0.
Whereas info I'd seen showed it was actually 'CTRL-A' that was PETSCII code 1.

[SiriusHardware]

Either the DRAM is a complete disaster area or there is something common to all of the DRAM which hasn't yet been picked up on, just as you say. I know it's tedious but it will be useful if Colin can do the checks asked for in #133 in order to rule out more mundane stuff.

I would ignore all the PETSCII tables which I agree are confusing and just go with the physical evidence of what working screen hardware displays when flooded with consecutive values 00-FF, as seen in post # 137.

[ScottishColin]

It's funny - I don't find this tedious or a grind. I'm perfeclty happy doing this.

Anyway - all continuity checks below are good.

Scope tests to come.

Colin.

Originally Posted by SiriusHardware

OK, swapping the CAS signals was worth a try but it has told us that the first 256 bytes of the upper RAM bank is also unusable - you can put the resistors back as they were.

Thanks for including the hi-res shots as the forum did render the embedded versions hard to read.

I don't know what to make of the video footage yet and actually I didn't see the point where the items you mentioned stopped changing - maybe I misunderstood what we were looking for. A special request from me when shooting video in future, please turn the phone on its side when videoing because my (PC) screen is landscape format, as are just about all TVs and laptop screens. The more the footage fills our screens to each far corner, the more chance we have of seeing the smaller detail.

Let's grind onwards.. on each of the DRAMs can you please scope the following pins with the NOP test running:-

5, 7, 6, 12, 11, 10, 13 (look for activity)

4, 15 (Look for activity).

The signal should look the same on all of the pin 5s, and it should look the same on all of the pin 7s, the same on all of the pin 6s, same on all of the pins 12s, and so on.

Remember when you replaced the UD8 ROM and for a time had worse problems than you had originally had until you got back on top of it - I'm wondering about the possibility that something similar may have happened when someone socketed that RAM IC at some time in the past.

For that reason could you please also meter for continuity between the following sets of pins:-

CPU (26), (UA4 (2, 14), UA5 (2, 14) and UD8 (17)

CPU (27), (UA6 (2, 14), UA7 (2, 14), and UD8 (16)

CPU (28), UA8 (2, 14), UA9 (2, 14), and UD8 (15)

CPU (29), UA10 (2, 14), UA11 (2, 14), and UD8 (14)

CPU (30), UA12 (2, 14), UA13 (2, 14), and UD8 (13)

CPU (31), UA14 (2, 14) UA15 (2, 14) and UD8 (11) * note pin 12 skipped

CPU (32), UA16 (2, 14) UA17 (2, 14) and UD8 (10)

CPU (33), UA18 (2, 14) UA19 (2, 14) and UD8 (9)