Non-working Commodore PET 3016 - Page 65 - UK Vintage Radio Repair and Restoration Discussion Forum

Slothie · 31st Mar 2021, 9:11 am

I don't think the current drain is an issue at all, "modern" (i.e. made in the 80s or later) EPROMs have significantly less power draw than the mask-programmed ROMs of the 70s. The ROMs in my 2001-8 would get uncomfortably hot, so they must have been dissipating several watts each. I've never encountered an EPROM that becomes even noticibly warm.

SiriusHardware · 31st Mar 2021, 9:25 am

I agree with Owen's observation that it would be 'nicer' if the 2716 CE / OE pins could be swapped but as this is for short-term testing I think I'll just be grateful that the relevant pins on a 2716 land where they do.

It looks as though I'll be putting Slothie's code in a 2716 in the adaptor (because it needs to work when A11 = high, address range F800-FFFF) and we'll just let the other code (address range E000-E7FF) go in a 2716 to be plugged in directly to the UD8 socket? Fingers crossed.

ScottishColin · 31st Mar 2021, 11:58 am

I have spare 24 pin turned pin sockets - is that what's required?

Colin.

Quote:

Originally Posted by SiriusHardware

You obviously feel there aren't any spectacular differences between any one of those lines and the rest so we'll have to say that also seems inconclusive (but we did not know that until you looked, so it was worth looking).

The test 'PROMs' are now programmed. Both of the test code files I have are 2K in length so I have programmed them into 2 x 2716 EPROMs. These can't be dropped straight into a PET 2001N PROM socket without a slight tweak to the pin wiring, so I've made a simple adaptor from two stacked sockets.

I've fitted both of the test EPROMs into the adaptor and read them as though they were 2532 EPROMs which we know are directly drop-in compatible with the PET's PROM sockets - the 2532 is a 4K device so, with A11 of the PROM socket disconnected by the adaptor, the content of these smaller (2K) devices just appears twice when read as though they are a 2532.

Slothie's code is written to run in the UD9 (Kernel PROM) position - when placed there the 2K of code will appear at both F000-F7FF and F800-FFFF, the second being the 'true' image.

The other test code, written by Daver2 over on VCFED, is written to run in the UD8 (edit PROM) position and that will appear at E000-E7FF and E800-EFFF, the latter being the 'true' image as far as I know.

I'll try, circumstances allowing, to get these into the post in time to arrive on Saturday, if not earlier.

My only concern is that depending on the type of IC sockets the PROMs are fitted in, the pins on the adaptor may not reach far enough into the socket holes. If so, that could probably be got around by plugging a conventional 24-pin IC socket into the mainboard PROM socket and then plugging the adaptor into that.

ScottishColin · 31st Mar 2021, 12:01 pm

I'll re-do the tests for all the RAM chips and post images later on today for comparison.

Colin.

Quote:

Originally Posted by SiriusHardware

You obviously feel there aren't any spectacular differences between any one of those lines and the rest so we'll have to say that also seems inconclusive (but we did not know that until you looked, so it was worth looking).

The test 'PROMs' are now programmed. Both of the test code files I have are 2K in length so I have programmed them into 2 x 2716 EPROMs. These can't be dropped straight into a PET 2001N PROM socket without a slight tweak to the pin wiring, so I've made a simple adaptor from two stacked sockets.

I've fitted both of the test EPROMs into the adaptor and read them as though they were 2532 EPROMs which we know are directly drop-in compatible with the PET's PROM sockets - the 2532 is a 4K device so, with A11 of the PROM socket disconnected by the adaptor, the content of these smaller (2K) devices just appears twice when read as though they are a 2532.

Slothie's code is written to run in the UD9 (Kernel PROM) position - when placed there the 2K of code will appear at both F000-F7FF and F800-FFFF, the second being the 'true' image.

The other test code, written by Daver2 over on VCFED, is written to run in the UD8 (edit PROM) position and that will appear at E000-E7FF and E800-EFFF, the latter being the 'true' image as far as I know.

I'll try, circumstances allowing, to get these into the post in time to arrive on Saturday, if not earlier.

My only concern is that depending on the type of IC sockets the PROMs are fitted in, the pins on the adaptor may not reach far enough into the socket holes. If so, that could probably be got around by plugging a conventional 24-pin IC socket into the mainboard PROM socket and then plugging the adaptor into that.

SiriusHardware · 31st Mar 2021, 12:13 pm

Quote:

I have spare 24 pin turned pin sockets - is that what's required?

The bottom end of the adaptor IS a 24-pin turned pin socket, as you might be able to see from the image a few posts back. If the pins aren't long enough to reach right into the PROM socket on the main PCB then plugging a conventional socket into the mainboard PROM socket first may help.

We'll cross that bridge if we come to it.

ScottishColin · 31st Mar 2021, 12:18 pm

OK - I'll make sure I have some conventional sockets here for the weekend.

Colin.

Quote:

Originally Posted by SiriusHardware

Quote:

I have spare 24 pin turned pin sockets - is that what's required?

The bottom end of the adaptor IS a 24-pin turned pin socket, as you might be able to see from the image a few posts back. If the pins aren't long enough to reach right into the PROM socket on the main PCB then plugging a conventional socket into the mainboard PROM socket first may help.

We'll cross that bridge if we come to it.

SiriusHardware · 31st Mar 2021, 12:28 pm

Rather than rush off and order them just try fitting one of the TP sockets you have there into UD9' socket and meter all the socket 'holes' to see if they are all making contact with the pads on the mainboard (you might have to measure on the underside). If they do then you won't need another socket.

This repair may cost you a bit more yet, so don't go buying parts unnecessarily. It all adds up.

ScottishColin · 31st Mar 2021, 2:46 pm

OK - UI2-9 and UJ2-9 pins 14 (green) and 15 (yellow) attached.

There will be four of these posts to attach all screen shots - not as a ZIP so all can read them.

1 of 4

Colin.

ScottishColin · 31st Mar 2021, 2:48 pm

OK - UI2-9 and UJ2-9 pins 14 (green) and 15 (yellow) attached.

There will be four of these posts to attach all screen shots - not as a ZIP so all can read them.

2 of 4

Colin.

ScottishColin · 31st Mar 2021, 2:48 pm

OK - UI2-9 and UJ2-9 pins 14 (green) and 15 (yellow) attached.

There will be four of these posts to attach all screen shots - not as a ZIP so all can read them.

3 of 4

Colin.

ScottishColin · 31st Mar 2021, 2:50 pm

OK - UI2-9 and UJ2-9 pins 14 (green) and 15 (yellow) attached.

There will be four of these posts to attach all screen shots - not as a ZIP so all can read them.

4 of 4

Colin.

SiriusHardware · 31st Mar 2021, 6:58 pm

Thanks for doing all that. Remember when we were closing in on the video circuit problem and we were getting very similar output from all of the bits of every address of the original video RAM instead of the random output we were expecting? This is looking a bit like that, but then this is dynamic RAM so I don't know if we can expect the bits of this memory to initialise in random states.

I think the thing to do now, before going any further down the hardware route, is to try running some test code. I'll get those items off to you as soon as I can, hopefully tomorrow.

ScottishColin · 31st Mar 2021, 7:18 pm

Would we see any activity here if I pressed keys on the keyboard? Presuming the keyboard actually works that is....

Colin.

Quote:

Originally Posted by SiriusHardware

Thanks for doing all that. Remember when we were closing in on the video circuit problem and we were getting very similar output from all of the bits of every address of the original video RAM instead of the random output we were expecting? This is looking a bit like that, but then this is dynamic RAM so I don't know if we can expect the bits of this memory to initialise in random states.

I think the think to do now, before going any further down the hardware route, is to try running some test code. I'll get those items off to you as soon as I can, hopefully tomorrow.

SiriusHardware · 31st Mar 2021, 7:27 pm

With things as they are, no, because the keyboard scanning is run by the code in the PROMs and the CPU is currently only able to get so far before stopping, so it doesn't set up the periodic interrupt which does the keyboard scanning. (Or maybe it does, but doesn't work because interrupts, like subroutine calls, need working system RAM in order to work).

One of the two test PROMs includes code which directly accesses the keyboard scanning hardware so you can see things changing on the screen when you press keys - if the keyboard scanning hardware is working, that is.

Mark1960 · 1st Apr 2021, 1:50 am

I wonder if #1288 to #1291 is that the memory content FF FF 00 00 FF FF 00 00 etc.

At least it is confirming that every ram can drive both high and low levels. Also as the level stays high or low until driven during the next read cycle is also a good sign.

As soon as we get the test code running I’d like to see what RAM RW looks like. Hopefully not seeing activity on this RW before was just that there are so few write cycles when the PET code is running.

SiriusHardware · 1st Apr 2021, 1:26 pm

I put the two test EPROMs in the post to Colin today. I have not studied their operation in detail but I would think the most likely behaviour is that they keep going until the first time a RAM read / write operation fails, stop, and report the failure.

From a diagnostic point of view it would be useful if, on failure to write to and read from a RAM location, it just kept on continually trying the same operation. Then you would be able to follow the signals, hopefully to the point of failure.

ScottishColin · 4th Apr 2021, 12:23 pm

Hi - I've just been told I had a delivery yesterday and found the EPROMs - apologies. I have had words....

So - ready when you are.

Colin.

Quote:

Originally Posted by SiriusHardware

I put the two test EPROMs in the post to Colin today. I have not studied their operation in detail but I would think the most likely behaviour is that they keep going until the first time a RAM read / write operation fails, stop, and report the failure.

From a diagnostic point of view it would be useful if, on failure to write to and read from a RAM location, it just kept on continually trying the same operation. Then you would be able to follow the signals, hopefully to the point of failure.

SiriusHardware · 4th Apr 2021, 1:24 pm

Hi Colin, glad they got there. I am tied up for this afternoon, heading for my first vaccine shot at long last. Back later.

ScottishColin · 4th Apr 2021, 3:25 pm

Hope it goes OK. Had mine a couple of weeks back and it knocked me for six for 24 hours. Take it steady.

Colin.

Quote:

Originally Posted by SiriusHardware

Hi Colin, glad they got there. I am tied up for this afternoon, heading for my first vaccine shot at long last. Back later.

SiriusHardware · 4th Apr 2021, 3:28 pm

Right then,

It's very simple. Restore the machine to normal configuration (CPU directly fitted).

Remove UD9 (only) and try the 'Slothie' EPROM - fitted in the adaptor - in that position, turn on, see what happens. If it works at all it will most likely report an error message of some sort as long as the machine is working enough for the EPROM to be able to work at all. Slothie, being the person who kindly wrote that code, will know more about the detail of what it does but I gather it does tests and reports the results in plain english on the screen (which of course is why we went to such trouble to get the display hardware working first).

If it does work take a screen shot of the screen it stops on / error it reports.

Regardless of whether it does or doesn't work, then refit the original UD9, remove UD8 and fit the Daver2 EPROM in the UD8 position without the adaptor and again just see what happens and if it runs at all, show us or tell us what happens.

The UD8 replacement EPROM does quite a few tests and there is a well written manual for it which I will try to find the link to again, but that will be academic if it just doesn't work anyway.

31st Mar 2021, 9:11 am	#1281
Slothie Octode Join Date: Apr 2018 Location: Newbury, Berkshire, UK. Posts: 1,287	Re: Non-working Commodore PET 3016 I don't think the current drain is an issue at all, "modern" (i.e. made in the 80s or later) EPROMs have significantly less power draw than the mask-programmed ROMs of the 70s. The ROMs in my 2001-8 would get uncomfortably hot, so they must have been dissipating several watts each. I've never encountered an EPROM that becomes even noticibly warm.

31st Mar 2021, 9:25 am	#1282
SiriusHardware Dekatron Join Date: Aug 2011 Location: Newcastle, Tyne and Wear, UK. Posts: 11,556	Re: Non-working Commodore PET 3016 I agree with Owen's observation that it would be 'nicer' if the 2716 CE / OE pins could be swapped but as this is for short-term testing I think I'll just be grateful that the relevant pins on a 2716 land where they do. It looks as though I'll be putting Slothie's code in a 2716 in the adaptor (because it needs to work when A11 = high, address range F800-FFFF) and we'll just let the other code (address range E000-E7FF) go in a 2716 to be plugged in directly to the UD8 socket? Fingers crossed.

31st Mar 2021, 12:28 pm	#1287
SiriusHardware Dekatron Join Date: Aug 2011 Location: Newcastle, Tyne and Wear, UK. Posts: 11,556	Re: Non-working Commodore PET 3016 Rather than rush off and order them just try fitting one of the TP sockets you have there into UD9' socket and meter all the socket 'holes' to see if they are all making contact with the pads on the mainboard (you might have to measure on the underside). If they do then you won't need another socket. This repair may cost you a bit more yet, so don't go buying parts unnecessarily. It all adds up.

31st Mar 2021, 2:46 pm	#1288
ScottishColin Octode Join Date: May 2012 Location: Perth, Scotland Posts: 1,804	Re: Non-working Commodore PET 3016 OK - UI2-9 and UJ2-9 pins 14 (green) and 15 (yellow) attached. There will be four of these posts to attach all screen shots - not as a ZIP so all can read them. 1 of 4 Colin. Attached Thumbnails

31st Mar 2021, 2:48 pm	#1289
ScottishColin Octode Join Date: May 2012 Location: Perth, Scotland Posts: 1,804	Re: Non-working Commodore PET 3016 OK - UI2-9 and UJ2-9 pins 14 (green) and 15 (yellow) attached. There will be four of these posts to attach all screen shots - not as a ZIP so all can read them. 2 of 4 Colin. Attached Thumbnails

31st Mar 2021, 2:48 pm	#1290
ScottishColin Octode Join Date: May 2012 Location: Perth, Scotland Posts: 1,804	Re: Non-working Commodore PET 3016 OK - UI2-9 and UJ2-9 pins 14 (green) and 15 (yellow) attached. There will be four of these posts to attach all screen shots - not as a ZIP so all can read them. 3 of 4 Colin. Attached Thumbnails

31st Mar 2021, 2:50 pm	#1291
ScottishColin Octode Join Date: May 2012 Location: Perth, Scotland Posts: 1,804	Re: Non-working Commodore PET 3016 OK - UI2-9 and UJ2-9 pins 14 (green) and 15 (yellow) attached. There will be four of these posts to attach all screen shots - not as a ZIP so all can read them. 4 of 4 Colin. Attached Thumbnails

31st Mar 2021, 6:58 pm	#1292
SiriusHardware Dekatron Join Date: Aug 2011 Location: Newcastle, Tyne and Wear, UK. Posts: 11,556	Re: Non-working Commodore PET 3016 Thanks for doing all that. Remember when we were closing in on the video circuit problem and we were getting very similar output from all of the bits of every address of the original video RAM instead of the random output we were expecting? This is looking a bit like that, but then this is dynamic RAM so I don't know if we can expect the bits of this memory to initialise in random states. I think the thing to do now, before going any further down the hardware route, is to try running some test code. I'll get those items off to you as soon as I can, hopefully tomorrow. Last edited by SiriusHardware; 31st Mar 2021 at 7:26 pm.

31st Mar 2021, 7:27 pm	#1294
SiriusHardware Dekatron Join Date: Aug 2011 Location: Newcastle, Tyne and Wear, UK. Posts: 11,556	Re: Non-working Commodore PET 3016 With things as they are, no, because the keyboard scanning is run by the code in the PROMs and the CPU is currently only able to get so far before stopping, so it doesn't set up the periodic interrupt which does the keyboard scanning. (Or maybe it does, but doesn't work because interrupts, like subroutine calls, need working system RAM in order to work). One of the two test PROMs includes code which directly accesses the keyboard scanning hardware so you can see things changing on the screen when you press keys - if the keyboard scanning hardware is working, that is.

1st Apr 2021, 1:50 am	#1295
Mark1960 Octode Join Date: Mar 2020 Location: Kitchener, Ontario, Canada Posts: 1,294	Re: Non-working Commodore PET 3016 I wonder if #1288 to #1291 is that the memory content FF FF 00 00 FF FF 00 00 etc. At least it is confirming that every ram can drive both high and low levels. Also as the level stays high or low until driven during the next read cycle is also a good sign. As soon as we get the test code running I’d like to see what RAM RW looks like. Hopefully not seeing activity on this RW before was just that there are so few write cycles when the PET code is running.

1st Apr 2021, 1:26 pm	#1296
SiriusHardware Dekatron Join Date: Aug 2011 Location: Newcastle, Tyne and Wear, UK. Posts: 11,556	Re: Non-working Commodore PET 3016 I put the two test EPROMs in the post to Colin today. I have not studied their operation in detail but I would think the most likely behaviour is that they keep going until the first time a RAM read / write operation fails, stop, and report the failure. From a diagnostic point of view it would be useful if, on failure to write to and read from a RAM location, it just kept on continually trying the same operation. Then you would be able to follow the signals, hopefully to the point of failure.

4th Apr 2021, 1:24 pm	#1298
SiriusHardware Dekatron Join Date: Aug 2011 Location: Newcastle, Tyne and Wear, UK. Posts: 11,556	Re: Non-working Commodore PET 3016 Hi Colin, glad they got there. I am tied up for this afternoon, heading for my first vaccine shot at long last. Back later.

4th Apr 2021, 3:28 pm	#1300
SiriusHardware Dekatron Join Date: Aug 2011 Location: Newcastle, Tyne and Wear, UK. Posts: 11,556	Re: Non-working Commodore PET 3016 Right then, It's very simple. Restore the machine to normal configuration (CPU directly fitted). Remove UD9 (only) and try the 'Slothie' EPROM - fitted in the adaptor - in that position, turn on, see what happens. If it works at all it will most likely report an error message of some sort as long as the machine is working enough for the EPROM to be able to work at all. Slothie, being the person who kindly wrote that code, will know more about the detail of what it does but I gather it does tests and reports the results in plain english on the screen (which of course is why we went to such trouble to get the display hardware working first). If it does work take a screen shot of the screen it stops on / error it reports. Regardless of whether it does or doesn't work, then refit the original UD9, remove UD8 and fit the Daver2 EPROM in the UD8 position without the adaptor and again just see what happens and if it runs at all, show us or tell us what happens. The UD8 replacement EPROM does quite a few tests and there is a well written manual for it which I will try to find the link to again, but that will be academic if it just doesn't work anyway.