Non-working Commodore PET 3016

[ScottishColin]

Slothie EPROM - cycles through some characters and pretty quickly (c. 5 seconds) ends with

zero page error - stopped

Daver2 EPROM - puts characters in PETSCII sequence from 32-63 then the same in inverse on the screen. At a random time afterwards, it changes to the second screen, and then flips between the two after a minute or two of showing the previous screen - see attached photos.

Colin.

[SiriusHardware]

That sounds to me like they are both doing what they are meant to, but in both cases encountering a problem and proceeding no further, much as we probably expected at this stage. The fact that both lots of test code show something on the screen - the character set in correct order - confirms that the screen memory and associated display hardware is all working as it should.

Slothie's code is telling us that even the critical first 256 bytes of memory (Zero Page) which the 6502 uses for some special purposes is not working, so that explains why the CPU does not get very far when trying to initialise with the normal PROMs fitted, as they rely on working RAM in zero page for correct operation of subroutine calls and interrupts.

Could you please capture between 8 and 16 cycles of the waveform(s) on UI11 pin 1 and UI11 pin 19 - (both at the same time), and also capture whatever there is on pin 3 of UJ2 - both to be taken with Slothie's EPROM fitted and in the interval between start-up and the appearance of the Zero Page error message.

[ScottishColin]

I'll to the traces as above. Note now that when I put UD8 back in and replace UD9 with the Slothie EPROM, I get the following message:

:%2/ 0!`% %22/2 - 34/00%$

I note that the UD9 socket is now very easy to push/replace the EPROM into - I wonder whether the turned pin socket has damaged the original motherboard scket in any way?

Colin.

[ScottishColin]

Pin 3 of UJ2 attached. Note I have had to change the voltage setting to get the waves readable. I'm finding it more difficult to get readings from UI11 - I need a third hand so I'll be with you as soon as I can.

Colin

[ScottishColin]

UI11/1 (yellow) and UI11 19 (green) attached. Again note I have had to change the voltage setting on the scope software.

Colin.

[Slothie]

Originally Posted by SiriusHardware

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.

Noted!

[SiriusHardware]

Originally Posted by ScottishColin

I note that the UD9 socket is now very easy to push/replace the EPROM into - I wonder whether the turned pin socket has damaged the original motherboard socket in any way?

It does sound like a possible case of cause and effect, if that seems to be the case then the only thing you can really do is replace the socket.

You can try putting the original UD9 and / or the Slothie EPROM in its adaptor into UD9 socket and checking continuity from all UD9 pins to the associated UD9 PCB pads to see if you can identify which, if any of the connections, is not making.

Bear in mind that on the Slothie EPROM adaptor pin 18 of the upper socket is intentionally not connected to pin 18 of the lower socket and is instead connected to pin 20 of both the upper and lower sockets.

It's not clear whether the readings you go with the curiously low waveform height were taken before or after this problem arose?

[Slothie]

My diagnostic ROM does the following:
1) Writes characters $FF (Checkerboard) to $20 (Space) to every screen location, to clear the screen and also show something on the screen. This takes about 5 seconds as noted and leaves the screen blank.
2) Checks memory locations $00-$FF by writing $55 and $AA to them and making sure they read back correctly. These patterns are chosen because they will reveal stuck, shorted or broken bits.
3) If 2 fails, displays the "Zero page error" message and then sits in a jump loop, so the processor should just be fetching instructions continually and not doing much else.
4) Memory from $200-$2FF (The stack area) is tested as in 2 & 3 above.
5) If the zero page and stack are OK then the I/O chips are initialised, a banner is printed to the screen, and it uses the zero page registers to test $0300-$7FFF (up to 32k) using the two patterns described above. It then writes the page number (the upper byte of the address, e.g. $03-$7F) into the memory location and moves on.
6) Due to a slight buglet, only if step 5 finds 32k of memory it will check that the page number written into each location is correct. It should test 4K, 8K and 16K machines too. This test should detect memories that get selected on multiple address ranges by bad address decoding by having the wrong page number written to them.

I intend to add other features including a better memory test that shows which blocks have been checked, and what the actual and expected values are when a test fails. I just need to write a non-interrupt version of the keyboard scan so options can be selected. Like an option to keep testing a "bad" block of memory so signals can be traced.

The two main points are:
1) This may not work on dynamic RAM pets if the refresh logic is SNAFU, but will always do the characters on the screen, banner message and bad zero page message even if there is no RAM at all (well, you have to have screen RAM at $8000-$83FF but you get what I mean), If you see the flashing characters then the screen ram is at least partially working, it the banner is garbled then the RAM or character ROM may be kaput (or the logic connected to it etc).
2) You need at least the first 0.75K to be working for the diagnostic to complete, although you will get a message if the ZP or Stack memory fails.

Comments/Suggestions always welcome.

[ScottishColin]

The waveforms were after.

I think I'll go for a socket replacement tomorrow and update you with the results.

Colin.

Originally Posted by SiriusHardware

It does sound like a possible case of cause and effect, if that seems to be the case then the only thing you can really do is replace the socket.

You can try putting the original UD9 and / or the Slothie EPROM in its adaptor into UD9 socket and checking continuity from all UD9 pins to the associated UD9 PCB pads to see if you can identify which, if any of the connections, is not making.

Bear in mind that on the Slothie EPROM adaptor pin 18 of the upper socket is intentionally not connected to pin 18 of the lower socket and is instead connected to pin 20 of both the upper and lower sockets.

It's not clear whether the readings you go with the curiously low waveform height were taken before or after this problem arose?

[SiriusHardware]

A warning in advance that if you do fit a new socket and you go to plug the Slothie test eprom + adaptor into that, only insert it just far enough so it 'sticks', don't push it all the way in because those sockets are not really designed to have the round pins of turned-pin sockets plugged into them.

If you do shove it all the way in you will find that a normal IC (with flat pins) will be a very slack fit afterwards, exactly the same problem as the one you are trying to fix now.

To remove a conventional socket the method, as originally suggested by AJ, is to cut the spars which join the two sides of the socket together and then gently rock each side of the socket from side to side until all the pins snap leaving only the remains of the pins in the board.

Turn the board over, melt the solder on each pin in turn and pick them out with a pair of tweezers.

Note this only applies to conventional sockets, turned-pin sockets are one of the most difficult things you could ever try to remove from an old double sided PCB (so try not to ever need to do that).

Slothie, thanks for the breakdown on what the code does in its current form. As you've already seen, it would be useful if, on failure to write to and read back from a specific RAM location or block, it would produce the error message but then continue to attempt the failed task so that the reason for the failure could be traced more easily.

From what you've said above it would actually be very difficult to catch the failure in the act at the moment because it's just a brief flurry which happens at the end of the 5-second screen memory test. I think we'll have to use BANK SEL as the trigger since that only activates when the system is writing to or reading from system RAM.

[ScottishColin]

Does that also apply if I fit a turned pin socket?

Colin.

Originally Posted by SiriusHardware

A warning in advance that if you do fit a new socket and you go to plug the Slothie test eprom + adaptor into that, only insert it just far enough so it 'sticks', don't push it all the way in because those sockets are not really designed to have the round pins of turned-pin sockets plugged into them.

If you do shove it all the way in you will find that a normal IC (with flat pins) will be a very slack fit afterwards, exactly the same problem as the one you are trying to fix now.

To remove a conventional socket the method, as originally suggested by AJ, is to cut the spars which join the two sides of the socket together and then gently rock each side of the socket from side to side until all the pins snap leaving only the remains of the pins in the board.

Turn the board over, melt the solder on each pin in turn and pick them out with a pair of tweezers.

Note this only applies to conventional sockets, turned-pin sockets are one of the most difficult things you could ever try to remove from an old double sided PCB (so try not to ever need to do that).

Slothie, thanks for the breakdown on what the code does in its current form. As you've already seen, it would be useful if, on failure to write to and read back from a specific RAM location or block, it would produce the error message but then continue to attempt the failed task so that the reason for the failure could be traced more easily.

[SiriusHardware]

You've quoted my entire post so I'm not sure what, specifically, you are asking about. If you fit a turned pin socket then be careful not to push the adaptor (which is also a turned pin socket) all the way into it, otherwise it will open out the holes in the newly fitted socket.

The 'cut and rock' method should never be used to remove a turned-pin socket.

[ortek_service]

Originally Posted by Slothie

My diagnostic ROM does the following:
1) Writes characters $FF (Checkerboard) to $20 (Space) to every screen location, to clear the screen and also show something on the screen. This takes about 5 seconds as noted and leaves the screen blank.
2) Checks memory locations $00-$FF by writing $55 and $AA to them and making sure they read back correctly. These patterns are chosen because they will reveal stuck, shorted or broken bits.
3) If 2 fails, displays the "Zero page error" message and then sits in a jump loop, so the processor should just be fetching instructions continually and not doing much else.
>>
>>
I intend to add other features including a better memory test that shows which blocks have been checked, and what the actual and expected values are when a test fails. I just need to write a non-interrupt version of the keyboard scan so options can be selected. Like an option to keep testing a "bad" block of memory so signals can be traced.
>>
>>

2) You need at least the first 0.75K to be working for the diagnostic to complete, although you will get a message if the ZP or Stack memory fails.

Comments/Suggestions always welcome.

I did wonder if showing the actual fail location would be useful, although if it's in zero page / stack it will be confined to a pair of 2114's anyway. However, displaying what is being written / the data being read back, should hopefully help in identifying which Lower / Upper nibble of the 2114's is at fault rather than having to take a 50:50 guess of which to remove / replace if both haven't failed.

Other Sinclair / Commodore etc. diagnostic ROM's will tell you IC number, but with so many different PET boards, then that's probably not too practical. Although I have also seen some using bars in the border to indicate which Databits are faulty.
So may be able to do something similar to indicate where fault is if screen RAM isn't entirely working and there's no audio beep feedback available. May also be able to pulse some user port etc. lines to indicate this.


Regarding the screen error message now mostly changing to different characters, that looks more like the screen memory has gone a bit faulty (or the character generator ROM - assuming this is using one - has connections to it a bit intermittent). As if there was a problem with the Data pins on the diagnostic EPROM socket, then the code wouldn't run on the 6502 correctly.

[Mark1960]

Originally Posted by ortek_service

I did wonder if showing the actual fail location would be useful, although if it's in zero page / stack it will be confined to a pair of 2114's anyway. However, displaying what is being written / the data being read back, should hopefully help in identifying which Lower / Upper nibble of the 2114's is at fault rather than having to take a 50:50 guess of which to remove / replace if both haven't failed.

The 3016 uses 4108s for zero page and stack, so it could be any one or more of the 8 x 4108 that causes the failure. Knowing the pattern written and read back would help diagnose which one or more of the eight is a problem.

For dynamic ram, a write followed by a read may not detect a fault. It might be best to write to every location, then a delay calculated from dram spec, then read from every location. Then repeat with a different pattern. This would be in addition to a read followed by write and read from each location not instead, as you want to check for address errors.

[ScottishColin]

That was my question - well divined and apologies.

I'll check continuity from the pins in the EPROM you sent me first before I make any changes, but I may go for a new socket; I'll let you know tomorrow. And if I do I'll be careful pushing another socket into it - I don't want to have to fight with trying to remove a turned-pin socket from this motherboard.

Colin.

Originally Posted by SiriusHardware

You've quoted my entire post so I'm not sure what, specifically, you are asking about. If you fit a turned pin socket then be careful not to push the adaptor (which is also a turned pin socket) all the way into it, otherwise it will open out the holes in the newly fitted socket.

The 'cut and rock' method should never be used to remove a turned-pin socket.

[ortek_service]

Originally Posted by Mark1960

The 3016 uses 4108s for zero page and stack, so it could be any one or more of the 8 x 4108 that causes the failure. Knowing the pattern written and read back would help diagnose which one or more of the eight is a problem.

For dynamic ram, a write followed by a read may not detect a fault. It might be best to write to every location, then a delay calculated from dram spec, then read from every location. Then repeat with a different pattern. This would be in addition to a read followed by write and read from each location not instead, as you want to check for address errors.

Yes, for DRAM's it's a bit more involved and important to know which bit is at fault. But I recall Slothie saying his code didn't support DRAM PET's at present, due to extra complexity of doing this on a PET (Which presumably doesn't have hardware-based refreshing, which computers with CRTC's / ULA's have that does this for you)

[ortek_service]

Originally Posted by ScottishColin

That was my question - well divined and apologies.

I'll check continuity from the pins in the EPROM you sent me first before I make any changes, but I may go for a new socket; I'll let you know tomorrow. And if I do I'll be careful pushing another socket into it - I don't want to have to fight with trying to remove a turned-pin socket from this motherboard.

Colin.

I think it's also worth carefully checking the Character ROM socket, as it would seem like that could also be a bit intermittent if characters have now changed a bit.


If a motherboard's IC socket's pins have got opened up a bit too much, and you were going to replace it at some point anyway, then inserting an extra turned-pin one into it temporarily may at least provide a better contact to it just for testing / eliminating things for now.
With normal rectangular pin type IC sockets, you could probably also fit one of these into the board's sockets, as a sacrificial 'saver' when inserting turned-pin adaptors to prevent damage to the board's ones.
- Although at least turned pins are usually only 0.64mm, whereas attempting to force 0.64x0.64mm square headers into IC sockets, that I have seen used before on some adaptor boards, almost certainly opens the socket's contacts out too much (if they even go in at all, on some types)

[Slothie]

Originally Posted by ortek_service

Yes, for DRAM's it's a bit more involved and important to know which bit is at fault. But I recall Slothie saying his code didn't support DRAM PET's at present, due to extra complexity of doing this on a PET (Which presumably doesn't have hardware-based refreshing, which computers with CRTC's / ULA's have that does this for you)

If the DRAM refresh is hardware then the diagnostic will work. From memory I beleive the DRAM refresh is tied into the video logic, so if the screen is at all stable then that would imply a high chance the DRAM refresh is working. I don't think the DRAM PETs need any specific software support, unless there are hardware registers that need initialising (e.g in CRTC PETs) However I recall Colin saying his PET doesn't have a CRTC?

[ortek_service]

Although the problem maybe that the screen memory originally used separate RAM IC's, so any video logic that runs through the screen RAM, refreshing it, won't see the main (D)RAM memory.
However it seems that the later 8296 at least PET's did have single RAM area, rather than dedicated video RAM IC's, and also used a 6545/6845 CRTC so this may have refreshed all of the DRAM's.
But 2001-(8/16)N versions in between these used DRAM's, that may have not all been accessed by the video circuitry.

However, it seems the later PET's may still have been all character generator only based, with bit-mapped graphics not available until the VIC-20 etc.

[julie_m]

If you fit new turned-pin sockets on the motherboard, you won't have to worry too much about loosening the contacts with repeated insertions and removals. A turned-pin socket will happily accommodate the round pins of another turned-pin socket and not lose any ability to grip the flat pins of an IC. If you are very concerned about damaging sockets (they are a nightmare to replace), you can just stack two together; if you damage the top one, you can always swap in a brand new one.

The DRAM refreshing is all done in hardware, between processor memory accesses for transparency. As far as the 6502 is concerned, it might as well be static RAM. (In fact, it was, in very early PETs .....)

P.S. That error message looks like it could be a corruption of ZERO PAGE ERROR ..... That'll be my mis-spent youth again .....