UK Vintage Radio Repair and Restoration Powered By Google Custom Search Vintage Radio and TV Service Data

Go Back   UK Vintage Radio Repair and Restoration Discussion Forum > Specific Vintage Equipment > Vintage Computers

Notices

Vintage Computers Any vintage computer systems, calculators, video games etc., but with an emphasis on 1980s and earlier equipment.

Reply
 
Thread Tools
Old 12th Aug 2023, 1:51 am   #621
SiriusHardware
Dekatron
 
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,375
Default Re: Commodore PET 4032/8050/3022

Sorry I've been out of it this evening - I have also been wondering whether we should investigate those buffers before tearing out the RAMs, mainly due to the fact that the page 0 / page 1 result didn't change even when we swapped the upper and lower banks over. It suggests that the cause is something common to the operation of both banks.

If Colin doesn't mind socketing UE8, UE9 and UE10 we can test them in the UD13 / UD14 (main address buffers) position by running a NOP test and making sure we have the expected address line waveforms with the suspect buffers fitted in those positions (or if there are more new 244 buffers available, just try those in UE8 / UE9 / UE10 position).

Buggies, I'm not sure the databus is stuck at any value because there are small blocks of the page 0 / page 1 RAM which the Daver2 test EPROM is able to write to and read back correct values from.
SiriusHardware is offline   Reply With Quote
Old 12th Aug 2023, 3:10 am   #622
ortek_service
Octode
 
ortek_service's Avatar
 
Join Date: May 2018
Location: Northampton, Northamptonshire, UK.
Posts: 1,332
Default Re: Commodore PET 4032/8050/3022

Yes, although it should in theory be possible to check the '244's in-circuit, probing either side of the address line paths, this really needs a 3rd 'scope / Logic-analyser channel to look at enable signal at the same time.
And with three '244's, with outputs in-parallel, it could be tricky to find any particular one that is not-tri-stating.
So, knowing the reputation of these in the PET, socketing these may be quickest solution to seeing if any are faulty.

Testing the 4116 3-rail DRAM's is rather more-involved, without known good ones to hand / another computer with these all socket-ed (rival Sinclair) Spectrums were quite handy for this,once you'd socket-ed all 8 in that.

Quote:
Originally Posted by SiriusHardware View Post
Buggies, I'm not sure the databus is stuck at any value because there are small blocks of the page 0 / page 1 RAM which the Daver2 test EPROM is able to write to and read back correct values from.
Yes, it's more a case of only certain databits/lines that might be stuck (High), so making the (many, especially with more than one faulty data-line) locations fail, where these should be Low in the counting-sequence.

And a counting-sequence is rather-better at identifying address-line (and also data-lines) shorts to low/high/each-other
But you still need to use the complement of each byte (as with simple 00 & FF) to find all of the actual locations that are affected by data-line shorts to low/high (as well as each-other, that simple 00 & FF patterns in all bytes wouldn't find). Also, using just 00 & FF won't find address-line issues, if write & read are just done together, after each other, on each byte in sequence.
ortek_service is offline   Reply With Quote
Old 12th Aug 2023, 9:28 am   #623
SiriusHardware
Dekatron
 
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,375
Default Re: Commodore PET 4032/8050/3022

Also, problems with the general address lines (which are buffered by UD13 and UD14 the moment they leave the CPU) seem unlikely because the Tynemouth board, while using internal buses for its internal RAM and ROM, still puts the address out on to the main address bus to select the peripheral ICs, Video RAM, etc and all of that works when the Tynemouth board is in charge, but using its own onboard RAM.

If there is an addressing problem for the main RAM it seems more likely to be within the circuitry which handles address selection within the RAM area, including those buffers.
SiriusHardware is offline   Reply With Quote
Old 12th Aug 2023, 4:34 pm   #624
ScottishColin
Octode
 
Join Date: May 2012
Location: Perth, Scotland
Posts: 1,739
Default Re: Commodore PET 4032/8050/3022

Apologies - life got in the way. I've removed UE8/9 & 10 and only two of them made it - I have a spare 244 so I'm OK.

What I don't have is enough 20 pin sockets so I'll solder in the two I have today and order some more and let you know when tey turn up.

Colin.
ScottishColin is offline   Reply With Quote
Old 12th Aug 2023, 10:38 pm   #625
ortek_service
Octode
 
ortek_service's Avatar
 
Join Date: May 2018
Location: Northampton, Northamptonshire, UK.
Posts: 1,332
Default Re: Commodore PET 4032/8050/3022

Quote:
Originally Posted by ScottishColin View Post
Apologies - life got in the way. I've removed UE8/9 & 10 and only two of them made it - I have a spare 244 so I'm OK.

What I don't have is enough 20 pin sockets so I'll solder in the two I have today and order some more and let you know when tey turn up.

Colin.
Sorry to hear one didn't quite survive intact - But maybe it can have a leg-repair, if only to be able to test it / keep more original IC's in it if still OK (more than because of cost, as these should be quite cheap - especially in quantities often needed to repair PET's!)

You could try the two you've removed, in UD13 & UD14 positions, in the meantime - as Graham suggested, below.
Quote:
Originally Posted by SiriusHardware View Post
>>
If Colin doesn't mind socketing UE8, UE9 and UE10 we can test them in the UD13 / UD14 (main address buffers) position by running a NOP test and making sure we have the expected address line waveforms with the suspect buffers fitted in those positions (or if there are more new 244 buffers available, just try those in UE8 / UE9 / UE10 position).
>>
It shouldn't probably matter if UE8,9 & 10 (or sockets for these, as long as there's no shorts between the PCB holes) are missing, to do this with the NOP tester that doesn't need the on-board RAM functioning. And missing the 7 address lines to the DRAM's from the buffers, shouldn't really be too much of a problem, as the still present nRAS / nCAS signals should prevent these outputting data at the wrong time on the data bus.

Also worth a try is maybe use the Tynemouth board, with on-board RAM. And should then be able to get a proper display if working 74LS244's are fitted elsewhere in UD13 / UD14 etc. So might want to try just swapping one at a time, to find out if it boots OK with any of the 3 you've removed.

If you are one socket short, you could if you wish either solder your new 74LS244 in, or if some of the removed ones turn-out to be OK, then re-fit those directly back-in. Whilst it is nicer to have all socketed for future repairs / diagnostics, at least if IC's are currently OK then shouldn't have to remove them again.
Hopefully having socket-ed these buffers and / or replaced these with good ones, it should avoid having to socket 8 DRAM IC's (if it looks like those have more-likely survived than the buffers).

Last edited by ortek_service; 12th Aug 2023 at 10:48 pm.
ortek_service is offline   Reply With Quote
Old 13th Aug 2023, 1:17 pm   #626
ScottishColin
Octode
 
Join Date: May 2012
Location: Perth, Scotland
Posts: 1,739
Default Re: Commodore PET 4032/8050/3022

OK. I got bored of waiting for the sockets. As a reminder I have socketed UE10 and UE9 and have the two original 244s in those sockets.

I got out my spare 244 and popped it into the motherboard in UE8 and booted and got an illegal exception error which is at least different.

So - more progress and a good idea of Sirius' to work on those 244s.

I then swapped out the old UE10 for a 244 from my working 3016 and it boots to the COMMODORE BASIC screen with the onboard RAM and looks fine with new 244s in UE10 and UE8 and an original in UE9.

Next step, I set the Tynemouth board to run with motherboard RAM and motherboard ROM so that Daver2s ROM boots and it initially looks good but with the more extensive RAM tests, I get the screen attached.

I then took the Tynemouth board out and just used the 6502 and got a second error after reboot.

Both errors are in the same byte (5df9) which I believe puts it in the higher memory bank and using the manual, I believe the error is in UA9.

Have I read that right?

Colin.
Attached Thumbnails
Click image for larger version

Name:	PXL_20230813_115720646.jpg
Views:	22
Size:	41.7 KB
ID:	283240   Click image for larger version

Name:	PXL_20230813_120508809.jpg
Views:	23
Size:	43.9 KB
ID:	283241  
ScottishColin is offline   Reply With Quote
Old 13th Aug 2023, 1:19 pm   #627
ScottishColin
Octode
 
Join Date: May 2012
Location: Perth, Scotland
Posts: 1,739
Default Re: Commodore PET 4032/8050/3022

Progress this morning (see below) - but you're right re the chips; I have managed to add a leg back onto chips before so once I have this working I'll attempt the same again. The original 6502 on this PET needs this attention too. As a matter of interest the same thing happened to the 6052 on my 3016 when I first removed the 6502 from its socket so I'm kind of used to it.

Colin.



Quote:
Originally Posted by ortek_service View Post
Quote:
Originally Posted by ScottishColin View Post
Apologies - life got in the way. I've removed UE8/9 & 10 and only two of them made it - I have a spare 244 so I'm OK.

What I don't have is enough 20 pin sockets so I'll solder in the two I have today and order some more and let you know when tey turn up.

Colin.
Sorry to hear one didn't quite survive intact - But maybe it can have a leg-repair, if only to be able to test it / keep more original IC's in it if still OK (more than because of cost, as these should be quite cheap - especially in quantities often needed to repair PET's!)

You could try the two you've removed, in UD13 & UD14 positions, in the meantime - as Graham suggested, below.
Quote:
Originally Posted by SiriusHardware View Post
>>
If Colin doesn't mind socketing UE8, UE9 and UE10 we can test them in the UD13 / UD14 (main address buffers) position by running a NOP test and making sure we have the expected address line waveforms with the suspect buffers fitted in those positions (or if there are more new 244 buffers available, just try those in UE8 / UE9 / UE10 position).
>>
It shouldn't probably matter if UE8,9 & 10 (or sockets for these, as long as there's no shorts between the PCB holes) are missing, to do this with the NOP tester that doesn't need the on-board RAM functioning. And missing the 7 address lines to the DRAM's from the buffers, shouldn't really be too much of a problem, as the still present nRAS / nCAS signals should prevent these outputting data at the wrong time on the data bus.

Also worth a try is maybe use the Tynemouth board, with on-board RAM. And should then be able to get a proper display if working 74LS244's are fitted elsewhere in UD13 / UD14 etc. So might want to try just swapping one at a time, to find out if it boots OK with any of the 3 you've removed.

If you are one socket short, you could if you wish either solder your new 74LS244 in, or if some of the removed ones turn-out to be OK, then re-fit those directly back-in. Whilst it is nicer to have all socketed for future repairs / diagnostics, at least if IC's are currently OK then shouldn't have to remove them again.
Hopefully having socket-ed these buffers and / or replaced these with good ones, it should avoid having to socket 8 DRAM IC's (if it looks like those have more-likely survived than the buffers).
ScottishColin is offline   Reply With Quote
Old 13th Aug 2023, 3:25 pm   #628
SiriusHardware
Dekatron
 
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,375
Default Re: Commodore PET 4032/8050/3022

Glad that it proved a worthwhile exercise to verify those buffers (Owen was also of that view). The machine still seems determined to fight us every step of the way though, now with a RAM fault.

I'm about to go out for the rest of the afternoon but I wonder if your test clip would now be able to give you more detailed information about the RAM fault?
SiriusHardware is offline   Reply With Quote
Old 13th Aug 2023, 3:43 pm   #629
SiriusHardware
Dekatron
 
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,375
Default Re: Commodore PET 4032/8050/3022

Quote:
Both errors are in the same byte (5df9) which I believe puts it in the higher memory bank and using the manual, I believe the error is in UA9.
The full address span of the RAM is from 0000-7FFF with 0000-03FFF being supplied by the lower bank and 4000-7FFF being supplied by the upper bank, so you are right that the failing addresses are in the upper bank.

However a quick squint at the circuit diagram shows that the lower bank ICs are the odd numbered UAx ICs and the upper bank ICs are the even numbered UAx ICs, so by that reasoning at least your culprit can't be UA9.
SiriusHardware is offline   Reply With Quote
Old 13th Aug 2023, 4:15 pm   #630
ortek_service
Octode
 
ortek_service's Avatar
 
Join Date: May 2018
Location: Northampton, Northamptonshire, UK.
Posts: 1,332
Default Re: Commodore PET 4032/8050/3022

Quote:
Originally Posted by SiriusHardware View Post
Glad that it proved a worthwhile exercise to verify those buffers (Owen was also of that view). The machine still seems determined to fight us every step of the way though, now with a RAM fault.

I'm about to go out for the rest of the afternoon but I wonder if your test clip would now be able to give you more detailed information about the RAM fault?
Well luckily (to save having to remove 8 DRAM's) it seems that at least one of the 3 'Muliplexor' buffers was faulty. Although if the damaged leg one also works it may be a case that '2 out of 3 aint bad!'

The DaveR test does give you quite a bit more info on the 0200h-7fffh RAM testing, compared to the simpler test it does on the first two pages. But not a bad idea to get a second (Diagnostic tool) opinion, to see what that reports / gain some familiarity with using it and how it compares.

Quote:
Originally Posted by SiriusHardware View Post
Quote:
Both errors are in the same byte (5df9) which I believe puts it in the higher memory bank and using the manual, I believe the error is in UA9.
The full address span of the RAM is from 0000-7FFF with 0000-03FFF being supplied by the lower bank and 4000-7FFF being supplied by the upper bank, so you are right that the failing addresses are in the upper bank.

However a quick squint at the circuit diagram shows that the lower bank ICs are the odd numbered UAx ICs and the upper bank ICs are the even numbered UAx ICs, so by that reasoning at least your culprit can't be UA9.
Yes, I've just been looking at this and agree that both the DaveR manual's example for an 8032 PET (With 8032029 board?) and the previously attached 8032087 schematics both have UA8 as being the Upper RAM IC on Data-line D5 that 20h represents.

What is rather odd is that whilst the location and bit-mask displayed values are the same, whether the Tynemouth board was in or not, the read byte values are rather different (as well as Test No. / Sub Test at which it failed at). I would have thought that these would all be the same, regardless of whether the Tynemouth board is in (If its RAM isn't being used).
With Tynemouth board, it failed at Test 3, sub-part 2 with 11000000 read, indicating that bit5 was 0, when it should have been 1?
With just 6502, it failed sooner at Test 1, sub-part 0 with 10111111 read, indicating that bit5 was 1, when it should have been 0?
- Which is a little odd, as normally a bit would be stuck Low or High!
The DaveR manual doesn't tell you in any more detail what the tests and sub tests do. But from counting the '.' it seems there are 11 in total and they go 0,1,2,3 (parts 0,1,2) - but not sure what next ones are as could be test 4 or further sub-tests on test 3.

And I wonder if you do just get different values for those numbers, each time the test is run with the same hardware set-up ?
(Particularly if this dodgy bit seems to be 'floating' at that location)

I note the manual does recommend running it multiple times, to ensure the identified bit-fault is the same each time, before going for the initially-identified suspect IC. Although I can't really see other DRAM IC's or the buffers causing a single-bit error in the middle of the upper memory.
So will most likely need to socket UA8 and find another good one (I don't think there were any of these ones socketed in your previous PET to try?)
But still a good idea to first run the test a few times, just to see what results it gives.

Last edited by ortek_service; 13th Aug 2023 at 4:42 pm.
ortek_service is offline   Reply With Quote
Old 13th Aug 2023, 4:36 pm   #631
ScottishColin
Octode
 
Join Date: May 2012
Location: Perth, Scotland
Posts: 1,739
Default Re: Commodore PET 4032/8050/3022

Yes - I've read that wrong haven't I. It's UA8 I think.

I'll run some more tests and see if it's still repeatable both with Dave's tests and the other Diagnostic Clip I have (although I note he says he's never tested it with a 4032).

Colin.
ScottishColin is offline   Reply With Quote
Old 13th Aug 2023, 6:07 pm   #632
ScottishColin
Octode
 
Join Date: May 2012
Location: Perth, Scotland
Posts: 1,739
Default Re: Commodore PET 4032/8050/3022

OK - it's run 30 tests so far on Dave's EPROM and I'll leave it running without an issue. I have soldered in a socket for all 244s.

I'll start on the MC3446s this week to try to sort out the remaining IEEE port issues.

Colin.
ScottishColin is offline   Reply With Quote
Old 13th Aug 2023, 6:49 pm   #633
SiriusHardware
Dekatron
 
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,375
Default Re: Commodore PET 4032/8050/3022

Quote:
What is rather odd is that whilst the location and bit-mask displayed values are the same, whether the Tynemouth board was in or not, the read byte values are rather different (as well as Test No. / Sub Test at which it failed at). I would have thought that these would all be the same, regardless of whether the Tynemouth board is in (If its RAM isn't being used).
I was thinking that maybe bit 5 of that RAM is not putting out a proper logic level, so is sometimes read as 0 when it should be 1 and sometimes read as 1 when it should be 0.

But then:

Quote:
OK - it's run 30 tests so far on Dave's EPROM and I'll leave it running without an issue. I have soldered in a socket for all 244s.
Woah - where did the RAM fault suddenly go?
SiriusHardware is offline   Reply With Quote
Old 13th Aug 2023, 7:19 pm   #634
ScottishColin
Octode
 
Join Date: May 2012
Location: Perth, Scotland
Posts: 1,739
Default Re: Commodore PET 4032/8050/3022

The tests that failed were two different ones - the first failure was with test 3 which is a MARCH-C test and the second test was test 1 which fills all memory bits with a 1 and checks to make sure they are all 1.

In terms of the RAM failure - yes; I agree. I don't like failures that 'move'.

The only difference is the soldering in of the socket for the 244 in UE8. It was laying on the motherboard before that. I'm not clear whether that's enough of a difference?

I'll leave it soak testing.

Colin.


Quote:
Originally Posted by SiriusHardware View Post
Quote:
What is rather odd is that whilst the location and bit-mask displayed values are the same, whether the Tynemouth board was in or not, the read byte values are rather different (as well as Test No. / Sub Test at which it failed at). I would have thought that these would all be the same, regardless of whether the Tynemouth board is in (If its RAM isn't being used).
I was thinking that maybe bit 5 of that RAM is not putting out a proper logic level, so is sometimes read as 0 when it should be 1 and sometimes read as 1 when it should be 0.

But then:

Quote:
OK - it's run 30 tests so far on Dave's EPROM and I'll leave it running without an issue. I have soldered in a socket for all 244s.
Woah - where did the RAM fault suddenly go?
ScottishColin is offline   Reply With Quote
Old 13th Aug 2023, 7:50 pm   #635
ortek_service
Octode
 
ortek_service's Avatar
 
Join Date: May 2018
Location: Northampton, Northamptonshire, UK.
Posts: 1,332
Default Re: Commodore PET 4032/8050/3022

Quote:
Originally Posted by SiriusHardware View Post
Quote:
What is rather odd is that whilst the location and bit-mask displayed values are the same, whether the Tynemouth board was in or not, the read byte values are rather different (as well as Test No. / Sub Test at which it failed at). I would have thought that these would all be the same, regardless of whether the Tynemouth board is in (If its RAM isn't being used).
I was thinking that maybe bit 5 of that RAM is not putting out a proper logic level, so is sometimes read as 0 when it should be 1 and sometimes read as 1 when it should be 0.

Yes, I'd also thought that this data-bit might be 'floating' internally at that location, between states, as I'd suggested below.
- But I wouldn't have thought it would have been an external data-pin voltage-level issue, as unlikely to fail at exactly the same memory address 2 times in a row.

Quote:
Originally Posted by ortek_service View Post
>>
With Tynemouth board, it failed at Test 3, sub-part 2 with 11000000 read, indicating that bit5 was 0, when it should have been 1?
With just 6502, it failed sooner at Test 1, sub-part 0 with 10111111 read, indicating that bit5 was 1, when it should have been 0?
- Which is a little odd, as normally a bit would be stuck Low or High!
>>
And I wonder if you do just get different values for those numbers, each time the test is run with the same hardware set-up ?
(Particularly if this dodgy bit seems to be 'floating' at that location)

I note the manual does recommend running it multiple times, to ensure the identified bit-fault is the same each time, before going for the initially-identified suspect IC.
Although I can't really see other DRAM IC's or the buffers causing a single-bit error in the middle of the upper memory.
So will most likely need to socket UA8 and find another good one (I don't think there were any of these ones socketed in your previous PET to try?)
But still a good idea to first run the test a few times, just to see what results it gives.

Quote:
Originally Posted by SiriusHardware View Post
But then:

Quote:
OK - it's run 30 tests so far on Dave's EPROM and I'll leave it running without an issue. I have soldered in a socket for all 244s.
Woah - where did the RAM fault suddenly go?
Yes, socketing the Buffer shouldn't really make it any better (Unless one pin wasn't quite solder completely originally but shouldn't need much solder to contact OK in a through-plated hole that previously was soldered).

Although I had suggested running multiple times with the same hardware setup.
- I'm not sure if you have to manually run the DaveR test each time, or whether you can leave it running continuously?
(If there is a dodgy DRAM etc. IC, then maybe Freezer spray / some hot-air on it may make it fail in-use).
ortek_service is offline   Reply With Quote
Old 13th Aug 2023, 7:57 pm   #636
ScottishColin
Octode
 
Join Date: May 2012
Location: Perth, Scotland
Posts: 1,739
Default Re: Commodore PET 4032/8050/3022

Yes - I'm leaving it to run for several hours to see what happens now - it continually runs and never stops until it has an error.

Colin.


Quote:
Originally Posted by ortek_service View Post

Although I had suggested running multiple times with the same hardware setup.
- I'm not sure if you have to manually run the DaveR test each time, or whether you can leave it running continuously?
(If there is a dodgy DRAM etc. IC, then maybe Freezer spray / some hot-air on it may make it fail in-use).
ScottishColin is offline   Reply With Quote
Old 13th Aug 2023, 11:15 pm   #637
SiriusHardware
Dekatron
 
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,375
Default Re: Commodore PET 4032/8050/3022

Quote:
The only difference is the soldering in of the socket for the 244 in UE8. It was laying on the motherboard before that. I'm not clear whether that's enough of a difference?
If you are telling me that the connections between the 20 pins of the IC and the associated pads on the PCB were initially largely dependent on gravity, then, yes, that would make a difference I am amazed it was working as well as it was to be honest.

So is the IEEE port test program still reporting zero parts of it working, or has that now changed?
SiriusHardware is offline   Reply With Quote
Old 13th Aug 2023, 11:42 pm   #638
ScottishColin
Octode
 
Join Date: May 2012
Location: Perth, Scotland
Posts: 1,739
Default Re: Commodore PET 4032/8050/3022

I'll try the IEEE test tomorrow. I left the RAM testing running for 96 tests over 2-3 hours and got no failures.

Attached for interest is a thermal image of the motherboard just before I powered it down.

No RAM chip looks hotter than any other. The ROM chips are a little warm and interestingly, the new Video RAM chip is warmer than the old one (bottom centre of the screen).

Colin.
Attached Thumbnails
Click image for larger version

Name:	1691966264283_100.jpg
Views:	14
Size:	34.8 KB
ID:	283270  
ScottishColin is offline   Reply With Quote
Old 14th Aug 2023, 12:28 am   #639
ortek_service
Octode
 
ortek_service's Avatar
 
Join Date: May 2018
Location: Northampton, Northamptonshire, UK.
Posts: 1,332
Default Re: Commodore PET 4032/8050/3022

Quote:
Originally Posted by SiriusHardware View Post
Quote:
The only difference is the soldering in of the socket for the 244 in UE8. It was laying on the motherboard before that. I'm not clear whether that's enough of a difference?
If you are telling me that the connections between the 20 pins of the IC and the associated pads on the PCB were initially largely dependent on gravity, then, yes, that would make a difference I am amazed it was working as well as it was to be honest.
>>
Yes, I'd also wondered if that was saying it hadn't actually been soldered in, now it seems it's been socket-ed which would have involved de-soldering it again.

Although you might get away with it with a brand-new IC, that still has the pins splayed-out and an auto-insertion machine briefly squeezes them in to align with the PCB holes.
And they do then spring out a bit to retain the IC in the board whilst soldering takes place (Also why you usually have to push them all towards the IC's body on thru-plated holes when de-soldering these, to free them from a slight bit of trapped solder), so may well contact the PCB's plated holes edges
- However, you'd want to ensure Power & Gnd at least had a very low-resistance contact.


I don't think I've ever tried to do this, as normally fit sockets. However, I (and Chris) have temporary inserted push-switches with kinked legs to retain them and do normally function OK for testing without soldering.these in.
ortek_service is offline   Reply With Quote
Old 14th Aug 2023, 12:38 am   #640
ortek_service
Octode
 
ortek_service's Avatar
 
Join Date: May 2018
Location: Northampton, Northamptonshire, UK.
Posts: 1,332
Default Re: Commodore PET 4032/8050/3022

Quote:
Originally Posted by ScottishColin View Post
I'll try the IEEE test tomorrow. I left the RAM testing running for 96 tests over 2-3 hours and got no failures.

Attached for interest is a thermal image of the motherboard just before I powered it down.

No RAM chip looks hotter than any other. The ROM chips are a little warm and interestingly, the new Video RAM chip is warmer than the old one (bottom centre of the screen).

Colin.
Although the thermal image will only help to show IC's that aren't being run within their ratings / ones that have developed a bit of a fault and drawing more current than they should. It won't necessarily show ones that have a fault which is temperature dependent (I once found a Z80A CPU IC that only worked for about 30s, but did work for longer if sprayed with freezer spray - Well butane lighter refill fluid, as that was all I had to hand! - to prove it was at fault).
I expect the NMOS 6502 CPU in this will also run quite-warm, as they normally draw around 200mA = 1W at 5V.
So may be similar to the Commodore ROM's which seem notorious for running quite hot (especially compared to many EPROM's.

If the video RAM's are different makes / types, then they could have different power-consumptions. Or maybe different data in these with a certain screen image, might affect the power they draw. Swapping them over would probably show which is the case.
ortek_service is offline   Reply With Quote
Reply

Thread Tools



All times are GMT +1. The time now is 6:33 pm.


All information and advice on this forum is subject to the WARNING AND DISCLAIMER located at https://www.vintage-radio.net/rules.html.
Failure to heed this warning may result in death or serious injury to yourself and/or others.


Powered by vBulletin®
Copyright ©2000 - 2024, vBulletin Solutions, Inc.
Copyright ©2002 - 2023, Paul Stenning.