Non-working Commodore PET 3016

[ScottishColin]

OK - question regarding pin 12 of UD9. Should it connect to earth as all the other Pin12s do? I can't get continuity to earth after my soldering. It has a track on the underside from pin 12 that goes to one of the legs of capacitor C9 and tha has continuity, but I'm now confused about Pin12/earth?

Colin.

[SiriusHardware]

Yes, pin 12 of UD9 socket should be connected to system 0V. Is it possible that pin 12 of the socket didn't go through the hole when you fitted it? Folded over under the body of the socket instead?

(This would only be possible if the socket you fitted was conventional, not turned pin).

[ScottishColin]

OK - pin 12/earth problem resolved.

Back to zero page error - stopped

I'll go check the other recent suggestions.

Colin.

[ScottishColin]

For the record, I do have the 901447-10 character ROM in tis PET.

Colin.

Originally Posted by ortek_service

That's assuming you have the later (for BASIC 2 / 4) 901447-10 character ROM (which used +32 character codes for lower case letters - so was closer to proper ASCII), rather than the original (BASIC 1) 901447-08 version (which used different +64 character codes for lower case). Which I discovered from here, that does seems to explain it all fairly-well:
https://www.atarimagazines.com/compu...ACTER_SETS.php

[ScottishColin]

UF9 pins all look fine and clean and not folded over.

Colin.

Originally Posted by SiriusHardware

Oh, may even be worth removing UF10 and inspecting the pins in case one of them got folded over the last time the IC was reinserted.

[julie_m]

Slothie may have imbued the 32s bit with some special significance, or at least recognise the failure mode, so it might be worth waiting for a word from him.

Anyway, this is the drastic RAM transplant test I'm proposing: (Colin -- don't worry if it goes over your head a bit, I can always go a bit slower if nobody else can point out a good reason not to!)

Remove UI10 and UI11. (This will disconnect the motherboard RAM from the data bus.) Get a 62256 static RAM IC and a 74LS00 (you may already have one). Use one of the NAND gates to invert A15, by tying the other input to +5V via a 4k7 resistor; feed its output, and the processor clock ø2, to another gate; and take the output of that gate to the 62256 pin 20, chip select. (This will hold CS high all the while the clock is high, so the chip is only selected while the clock is low.) Tie unused 74LS00 inputs to +5V via 4k7 resistors, to prevent instability. Connect A15 to 62256 pin 22, output enable. (This will disconnect the RAM outputs from the data bus when the selected address is in the range &8000-&FFFF.). Connect BR/W the buffered read/write to 62256 pin 27, write enable. (This will allow the CPU to write to the RAM whenever R/[o/W[/o] is low.) Connect the 62256 address lines to the appropriate BA lines, and the data lines to the appropriate BD lines (where UI10 and UI11 used to be; right side of schematic, not necessarily right side of chip). Don't forget the power and ground!

If there is a spare 24-pin ROM socket on your PET, all but three of the connections will actually be in the right places for all but seven of the pins of the 62256, which would make the wiring much easier.

[ortek_service]

Originally Posted by ScottishColin

UF9 pins all look fine and clean and not folded over.
Colin.

How about UF10? (it was IC A2 on the 320132 / 320137 boards schematics I looked at, which I presumed was the one in yours - I had guessed the 3016 wouldn't still have BASIC I in it) 2316 character ROM
- especially Pin23 (A8) = 'SD5' on this ?

Although it seems that maybe you are now getting a reliable correct message - maybe by coincidence, and could change again.
I trust you noticed the link I'd put to the actual PET character maps: https://www.atarimagazines.com/compu...ACTER_SETS.php
- Strangely, the best one I found was on an Atari website!

[SiriusHardware]

Originally Posted by ScottishColin

OK - pin 12/earth problem resolved.
Back to zero page error - stopped

Is that now 100% solid, all the time, every time, since replacement of the UD9 socket and solving whatever the problem was with UD9 socket pin 12?

Quite a few of the suggestions above have gone racing off after a character generator fault, which you may not actually have. (Or admittedly you may, if operation of the Slothie EPROM is still not 100% consistent).

Julie has suggested replacing the entire system RAM with a 'modern' 62256 SRAM IC but I think this may be a little bit too complex for Colin to attempt at this stage. Although Julie's explanation is detailed enough for most of us here I think it would have to be a more literal step by step guide for Colin.

Colin, can you describe more fully what happens when original UD9 is in UD9 socket and Daver2 EPROM is in UD8 position? I'll read up again what that test EPROM does.

[julie_m]

I can write up a proper, detailed explanation of the RAM job if required. I'm just being a bit cheeky, mentioning it here in case anyone else can see something obvious I've missed that would stop it from ever working at all. Looking at pictures of 3000-series PET motherboards, they all seem to have some unpopulated 24-pin ROM sockets; if Colin's one has these too, so much the better.

If a ground pin is disconnected on a CMOS IC, the input protection diodes will try to provide a return path for the supply current via any input held at a logic 0. This is highly unreliable, so no surprise it sort of worked a bit but not quite.

[ScottishColin]

The Slothie error message is now reliably consistent as zero page error - stopped. I have rebooted several times and watched the characters change for c. 5 seconds and then conclude with that error message.

I have left it for an hour or so and switched it back on in case it's in any way temperature related and still get the same message.

So I guess I don't have a character ROM issue? I'll still check as per recent messages though.

As before, my mission has always been to preserve as much of the original PET as I can. if there's any way I can work with the existing RAM setup (I know 4108s are like hen's teeth) I would rather. Having said that, if it's just impossible to either locate the error or source replacements, I guess I'm off down some alternative RAM route.

In terms of using the Daver2-UD8, I consistently get one screen every boot which is the photo attached. It looks to me like the whole caharcter set repeated. I'll go look at the manual (as I suspect you will) to see what I can find.

The character ROM is the only one that has not been checksummed - I'm still not 100% convinced by my Arduino wiring so is it worth me sending it to you for a check?

Colin.

Originally Posted by SiriusHardware

Is that now 100% solid, all the time, every time, since replacement of the UD9 socket and solving whatever the problem was with UD9 socket pin 12?

Quite a few of the suggestions above have gone racing off after a character generator fault, which you may not actually have. (Or admittedly you may, if operation of the Slothie EPROM is still not 100% consistent).

Julie has suggested replacing the entire system RAM with a 'modern' 62256 SRAM IC but I think this may be a little bit too complex for Colin to attempt at this stage. Although Julie's explanation is detailed enough for most of us here I think it would have to be a more literal step by step guide for Colin.

Colin, can you describe more fully what happens when original UD9 is in UD9 socket and Daver2 EPROM is in UD8 position? I'll read up again what that test EPROM does.

[ortek_service]

Yes, from the original photos posted there was several empty sockets.
And I guess you my be able to do something similar with an 8KB 6264, or possibly a 2KB 6116 24pin DIL one - just to probe it can start-up OK, once zero-page & stack are present.

But I guess it's a bit of a 'cheat', if you do want to keep it fairly original, so ultimately will have to find out at some point what's wrong with the Main system RAM.
If these are DRAM's, and all supplies are present, then it's probably getting quite close to having to swap some over (at least 4116's are fairly easily available - I keep getting emails offering me 8 for £10 from the usual auction site)
But quite a bit of socketing, without more info on exactly where the zero-page test is failing., so no doubt some more checks on other IC's can still be done, just in case.

I think that Pin12 issue that was resolved, was only found after changing the socket - so may not have been an issue originally.

[ScottishColin]

I have empty 24 pin sockets in UD3 4 and 5.

Colin.

Originally Posted by julie_m

I can write up a proper, detailed explanation of the RAM job if required. I'm just being a bit cheeky, mentioning it here in case anyone else can see something obvious I've missed that would stop it from ever working at all. Looking at pictures of 3000-series PET motherboards, they all seem to have some unpopulated 24-pin ROM sockets; if Colin's one has these too, so much the better.

If a ground pin is disconnected on a CMOS IC, the input protection diodes will try to provide a return path for the supply current via any input held at a logic 0. This is highly unreliable, so no surprise it sort of worked a bit but not quite.

[ScottishColin]

I did thanks and have bookmarked it. It's interesting that the Atari site has what is the best explanation I've seen so far...

Colin.

Originally Posted by ortek_service

I trust you noticed the link I'd put to the actual PET character maps: https://www.atarimagazines.com/compu...ACTER_SETS.php
- Strangely, the best one I found was on an Atari website!

[ScottishColin]

Having looked at the Daver manual, I get a pass exactly as per Figure 2 in the manual, but I progress no further. Wit hmy extremey limited knowledge, the next test should be Page 0 & 1 of system RAM and that's not happening (or if it is, it's failing very quickly). Does this still point to RAM issues?

Colin.

Originally Posted by SiriusHardware

Is that now 100% solid, all the time, every time, since replacement of the UD9 socket and solving whatever the problem was with UD9 socket pin 12?

Quite a few of the suggestions above have gone racing off after a character generator fault, which you may not actually have. (Or admittedly you may, if operation of the Slothie EPROM is still not 100% consistent).

Julie has suggested replacing the entire system RAM with a 'modern' 62256 SRAM IC but I think this may be a little bit too complex for Colin to attempt at this stage. Although Julie's explanation is detailed enough for most of us here I think it would have to be a more literal step by step guide for Colin.

Colin, can you describe more fully what happens when original UD9 is in UD9 socket and Daver2 EPROM is in UD8 position? I'll read up again what that test EPROM does.

[ScottishColin]

Last thing - with this ROM in UD8, when I power off, I get a dot in the centre of the screen for a minute or so - that's new.

Colin.

[ortek_service]

Originally Posted by ScottishColin

The Slothie error message is now reliably consistent as zero page error - stopped. I have rebooted several times and watched the characters change for c. 5 seconds and then conclude with that error message.

I have left it for an hour or so and switched it back on in case it's in any way temperature related and still get the same message.

So I guess I don't have a character ROM issue? I'll still check as per recent messages though.

As before, my mission has always been to preserve as much of the original PET as I can. if there's any way I can work with the existing RAM setup (I know 4108s are like hen's teeth) I would rather. Having said that, if it's just impossible to either locate the error or source replacements, I guess I'm off down some alternative RAM route.

In terms of using the Daver2-UD8, I consistently get one screen every boot which is the photo attached. It looks to me like the whole caharcter set repeated. I'll go look at the manual (as I suspect you will) to see what I can find.

The character ROM is the only one that has not been checksummed - I'm still not 100% convinced by my Arduino wiring so is it worth me sending it to you for a check?

Colin.

Well it seems like may you did have an odd ground issue all along - although very odd that it manifested itself by seemingly only affecting one data line out of video RAM to character ROM. But if it seem to now be working, then I wouldn't worry about it anymore, and there not really any point in checksumming the character ROM as it does seem to be working as expected and it wouldn't cause the other problems with the main RAM errors.

As it seems 4108 were really half-dead 4116 - As DRAM's are normally always inherently a 'square-array' , then I can't see an issue with just using 4116's - after all Commodore did in some of these. Plus, once socketed, you could always revert to 4108's later on, if you did find some from a scrap board etc. somewhere.

[ortek_service]

Originally Posted by ScottishColin

Last thing - with this ROM in UD8, when I power off, I get a dot in the centre of the screen for a minute or so - that's new.

Colin.

That sounds like a lack of video-blanking when the power to the video generation circuits dies away. I can't see how the ROM's would affect this, so hopefully not something else that's gone a bit wrong - PET's do recently seem to have had a habit of further faults appearing!

[ScottishColin]

If we decide for this, I'm happy to give it a go - we've come this far. I'll need a bit more detail though.....sorry.

Colin.

Originally Posted by julie_m

Slothie may have imbued the 32s bit with some special significance, or at least recognise the failure mode, so it might be worth waiting for a word from him.

Anyway, this is the drastic RAM transplant test I'm proposing: (Colin -- don't worry if it goes over your head a bit, I can always go a bit slower if nobody else can point out a good reason not to!)

Remove UI10 and UI11. (This will disconnect the motherboard RAM from the data bus.) Get a 62256 static RAM IC and a 74LS00 (you may already have one). Use one of the NAND gates to invert A15, by tying the other input to +5V via a 4k7 resistor; feed its output, and the processor clock ø2, to another gate; and take the output of that gate to the 62256 pin 20, chip select. (This will hold CS high all the while the clock is high, so the chip is only selected while the clock is low.) Tie unused 74LS00 inputs to +5V via 4k7 resistors, to prevent instability. Connect A15 to 62256 pin 22, output enable. (This will disconnect the RAM outputs from the data bus when the selected address is in the range &8000-&FFFF.). Connect BR/W the buffered read/write to 62256 pin 27, write enable. (This will allow the CPU to write to the RAM whenever R/[o/W[/o] is low.) Connect the 62256 address lines to the appropriate BA lines, and the data lines to the appropriate BD lines (where UI10 and UI11 used to be; right side of schematic, not necessarily right side of chip). Don't forget the power and ground!

If there is a spare 24-pin ROM socket on your PET, all but three of the connections will actually be in the right places for all but seven of the pins of the 62256, which would make the wiring much easier.

[ScottishColin]

So if we did decide on this, get 16 x sockets and 16 x 4116 and replace all existing RAM with 4116?

Stupid question - would this affect the amount of RAM available to the PET and therefore need any jumper changes?

Colin.

Originally Posted by ortek_service

Well it seems like may you did have an odd ground issue all along - although very odd that it manifested itself by seemingly only affecting one data line out of video RAM to character ROM. But if it seem to now be working, then I wouldn't worry about it anymore, and there not really any point in checksumming the character ROM as it does seem to be working as expected and it wouldn't cause the other problems with the main RAM errors.

As it seems 4108 were really half-dead 4116 - As DRAM's are normally always inherently a 'square-array' , then I can't see an issue with just using 4116's - after all Commodore did in some of these. Plus, once socketed, you could always revert to 4108's later on, if you did find some from a scrap board etc. somewhere.

[ScottishColin]

I suspect I originally had a socket issue with a pin/some pins originally.

Then after I replaced the socket, I had a pin 12 issue which I have resolved and tested ok.

Colin.

Originally Posted by ortek_service

Well it seems like may you did have an odd ground issue all along - although very odd that it manifested itself by seemingly only affecting one data line out of video RAM to character ROM. But if it seem to now be working, then I wouldn't worry about it anymore, and there not really any point in checksumming the character ROM as it does seem to be working as expected and it wouldn't cause the other problems with the main RAM errors.

As it seems 4108 were really half-dead 4116 - As DRAM's are normally always inherently a 'square-array' , then I can't see an issue with just using 4116's - after all Commodore did in some of these. Plus, once socketed, you could always revert to 4108's later on, if you did find some from a scrap board etc. somewhere.