Sunday 25 February 2024

Commodore PET 2001 Repair Part 2 - IEEE-488 Bus

In the previous post, I got the PET 2001 to the stage it was running, and could load from cassette. However, the IEEE-488 port was not working, the usual "?Device not present error".

As part of some of the other testing, I had already swapped out the easy to replace socketed chips, the 6502, 6520s and 6522 for known working chips, but the problem was still present.

I was concerned about some rather dubious work that had been done in the past on some of the chips related to the keyboard 6520 and the 6522.

I was starting to think I was going to have to undo a lot of that work, clean up, repair traces and through hole plating and refit. However, before I tackle any of that, I'd like to check with the IEEE-488 diagnostics board in case it is something else.

This has sixteen LEDs which light to indicate which of the sixteen signals on the bus are currently active (active = asserted = driven low; inactive = not asserted = floats high)

The first test is to reset the PET, and see the IFC LED lights briefly and then goes out, which it did.

REN is always lit as the PET has this hard wired to ground, so it acts as a sort of power LED. SRQ is not driven, so floats low, and registers as active.

The IEEE-488 bus is implemented on the PET using two pins for most of the signals, one to write, and one to read. These two signals go to the MC3446 buffer chips, and out to a single pin on the IEEE-488 bus connector.

The result of this is you can sort of get it to test itself, by writing to the output pins and reading back on the inputs to see if they change. A single bus signal is shown as an example. PB0 writes to the bus via one of the MC3446 drivers, and this is read back though another MC3446 buffer to PA0.

For more information, see this previous post - http://blog.tynemouthsoftware.co.uk/2023/10/pet-ieee-488-diagnostics-updated-version.html

I got lucky first time.

I wrote all zeroes to the data port, which should have asserted all 8 data signals and lit all 8 green LEDs.

Four of the LEDs have changed correctly, but the other 4 have not changed.

Completing the cycle confirms the problem, When it should be 0 ($00), it is 32 ($20), and when it should be 255 ($FF), it is 47 ($2F). It is easier to think of these in hex, as that more easily translates to binary. So again, this is showing the lower 4 bits are working correctly, and the upper 4 are stuck with 1111 on the bus and reading back as 0010.

The 2001 has a lovely hand drawn schematic where they clearly ran out of room and had to squash up the last of the signals on the bus.

Looking at the schematic, the four bits that are not working are controlled by the MC3446 at A8, the middle of these three chips. At least two of which appear to have been changed already as none of them match. Based on the soldering, I guess this was long before the other "repair" work that had been done on this board. The four working data lines and control lines use other chips, so it points to that one chip being bad.

I double checked with the 'scope. The signals on all 8 bits were changing on the output of the 6520, and the other MC3446s, just nothing on the middle MC3446.

I went through the other signals, and all the other signals were responding correctly.

IFC couldn't be lit with the rest as that is driven from the reset line (and has been previously verified).

(note EOI out is used on the 2001 to also control video blanking, so when it is active like this, it disables the video until you deactivate EOI or reset the PET)

Time for a new MC3446. I don't have many of these left. Hope I don't have too many more faulty PETs to deal with.

And it is possible to replace it without damaging traces or wrecking the board.

Everything seems to be still intact.

Time to repeat the tests.

And there we go, all data bits responding correctly.

Time to try an SD2PET.

Always fun to see all the LEDs flashing away when things load.

And this time I loaded Invaders.

That all seems to be working.

This was with a variety of replacement parts, time to put all the originals (or nearest we have) back.

Original 6520 reinstalled. Still working.

Non-original Synertek 6522 reinstalled. Still working.

Non-original MC6821 (or whatever it was before it was remarked) reinstalled. Still working.

Fake 6502 (or also whatever it was before it was remarked) reinstalled and still working.

I am leaving the PET ROM/RAM in place as the original ROMs had failed and there is no more than about 4K of working 6550 RAM chips.

Speaking of which, the last thing to be replaced were two working 6550 RAM chips for the video RAM, scavenged from the main RAM.

And that is everything back in place. Time for some more testing, a quick bit of Tut-Tut.

Everything seems to be working now, so I will give that a bit more testing and then it is ready to go back...........

Hmmmm, I don't remember spikes on the walls in 3D Monster Maze.

I wired up a new logic analyser I have been testing, to try to verify this is what I think it is (a similar problem to that seen on the Minstrel 2 which is inherent in the ZX80 design).

But it appears it does not want to play ball today.

OK, I think there may be a part 3.

How ironic, back to where we started. "HW_no_device_found", the modern equivalent of "?device not present error".

Advertisements

SD2PET

Special offer: There is currently £25 off the SD2PET. This is on backorder, which means TFW8b has all the bits to make more, but they have not yet completed the process of being built, programmed, tested, cased and tested again. But you can order safe in the knowledge that they will be ready to ship shortly. The discount will be removed once they are in stock, so act quick if you want a bargain.

https://www.tfw8b.com/product/sd2pet-commodore-pet/

PET ROM/RAM

As mentioned above, many PET faults are down to bad ROM chips or bad RAM chips, and a PET ROM/RAM chip can often help bypass those. You can order one from The Future Was 8 bit.

https://www.tfw8b.com/product/commodore-pet-rom-ram/

More info in a previous post:

http://blog.tynemouthsoftware.co.uk/2022/08/testing-pet-rom-ram-boards.html

Mini PET B

Or if you want an easier solution, the Mini PET B is a drop in replacement for a PET / CBM 40 column 32K motherboard.

More info in a previous post:

http://blog.tynemouthsoftware.co.uk/2023/10/building-a-mini-pet-b-kit.html

Mini PET B at SellMyRetro:

PET IEEE-488 Diagnostics

The PET IEEE-488 Diagnostics module is available from my SellMyRetro store, in assembled or kit form.

More info in a previous post:

http://blog.tynemouthsoftware.co.uk/2023/10/pet-ieee-488-diagnostics-updated-version.html

PET IEEE-488 Diagnostics module at SellMyRetro:

PET Diagnostics

The PET Diagnostics modules are available from my SellMyRetro store:

PET Dual Userport Joystick

I have recently revived the PET dual userport joystick, as a through hole version, available from my SellMyRetro store:

Patreon

You can support me via Patreon, and get access to advance previews of posts like this and behind the scenes updates. These are often in more detail than I can fit in here, and some of these posts contain bits from several Patreon posts. This also includes access to my Patreon only Discord server for even more regular updates.

https://www.patreon.com/tynemouthsoftware

Posted by at
Labels: , , ,

Sunday 18 February 2024

Commodore PET 2001 Repair - Part 1

Here we have a PET 2001 board in for repair.

This one has been in use for a year or so with a PET ROM/RAM board, and all the system ROM chips removed, and I am told it had been running fine.

Then one day it stopped working, the symptom being nothing on the screen, no raster with brightness turned up full. It also made odd noises from a piezo attached to the userport just before it failed.

I talked the user through trying a few things out, like removing and finally swapping the 6520 chips, and also removing the RAM chips, which had been left in place, even though they were being replaced by the RAM on the ROM/RAM board.

None of these simple tests seemed to help, so it was sent to me to investigate further. I asked for the RAM to be included (is it foreshadowing when you guess the fault before the board is sent in?), and the sender realised as soon as they posted the board that they had put the chips in upside down. Not a problem, as I was planning to remove them before powering on anyway.

Two of the same type of chips are used for video RAM, so it is useful to have spares around. With the ROM/RAM board replacing main RAM, it just needs 2 of the 18 chips present to work

The two chips installed are different. One is dated 1978 which matches the rest of the board, so there must have been problems in 1981 or later when the second chip was fitted.

Hmm, the board does seem a little banana shaped, hopefully nothing has delaminated or been damaged.

I may have to raise questions with a C. Armstrong - test and inspection or quality control?

And then the alarm bells begin to ring.

So that chip has been replaced, and a new socket fitted. Odd since it would have been socketed originally. And oh dear, what has happened to the trace to the left of the chip? Seems to have been lifted and twisted around. Not a good start.

Also, the sticker says 6520, but what lurks beneath?

Ah, it's a 6821. Fair enough, this is functionally compatible with the 6520, so that is OK.

Ah, but is it an MC6821? It has clearly been blacktopped and laser etched with an unlikely date code of 30th week 2019, for a chip that probably went out of production in the 1990s. (edit, last buy date 4th September 1999, later than I had expected, but 20 years before the fake date code)

So it could be anything, but hopefully something vaguely compatible.

On that subject, the 6502 has also been black topped and laser etched, so again, no idea what that was, but the package doesn't look like a MOS chip. At least the date code is reasonable, although unlikely to be related to whatever that chip originally was.

And then I turned the board over...............

Oh dear. This board has had quite a lot of work done, and some of it looks a little worrying.

Well, it was working, so hope I can just leave that alone. I would like to remove the socket, repair the tracks and replace, but there are about 8 chips that have been replaced like this, so it is a lot of work. Will check with the owner if they want the full works, or replace the board and try to forget about it.

Until I try to sleep and those images haunt my nightmares......

For the first test, I removed the ROM/RAM board and left the CPU socket empty. One neat trick of the PET 2001 (and the rest of the non-CRTC PETs) is that it will display something on the screen even if there is no CPU.

I used a PET composite video board to get a composite signal form the monitor connector.

Hmm, OK, that's unusual, you normally get a screen full of random characters, not just one, but I have seen that before with 6550 video RAM.

I think that is character $F4? If anything, I would expect $FF.

No change when the PET ROM/RAM and CPU were reinstalled. Could be bad video RAM.

Next test was to remove the video RAM chips.

Ah, that's good, that is what it should do. Character $FF is the chequerboard / goth batterburg character.

I dropped in a 6550 video RAM replacement board into the video RAM sockets.

That's better. The random characters as expected, and as you normally see for a second or two when you turn a older PET on.

I next installed a PET Diagnostics module, to give the board a bit of exercise.

And there we go.

Those results are to be expected with no ROM or RAM installed.

The video RAM test passed, and the font ROM looks good.

Note, due to some strangeness in the way 6550 RAM chips behave, the PET diagnostics does not cooperate with them, if you want to use it on a 2001 board that has 6550 video RAM, it needs to be replaced with a RAM module, then it works fine, just like any other PET board with normal static RAM.

Time to reinstall the PET ROM/RAM board and see if BASIC boots.

And there we go. A nice ready prompt.

And the obligatory 10 PRINT test program.

So far so good.

I will go back later and replace the video RAM with two good ones from the main RAM. Hopefully 2 out of the 16 spares will function. For the moment, I will leave the replacement RAM in place.

The question still remains why was there no picture for the owner.

Could be a bad monitor (or more likely a bad connection on the monitor cable?)

I had a bit of a look around the video circuitry, and I spotted something.

That's a 74HC107. That's not right. 74HC logic series isn't compatible with the 74LS chips over the rest of the board. It might work some of the time, but best be safe and go for the right chip.

I replaced that with a 74LS107, as would have originally been fitted.

It may be that worked at one point, but has drifted a bit with age and is no longer coping with the TTL logic levels on it's inputs?

It is a dual JK flipflop, and is part of the sync generation circuit, so that could explain the lack of video sync?

Back to testing, next is loading from datasette.

I was able to load simple programs.

And a memory test.

I left that running for a while. All looks good.

Time to test the IEEE-488 port.

Looks a little manky, so I gave all the ports a bit of a clean. Looks like someone has tried to solder to the three pins on the right, or were they just trying to retin the pins?

I plugged in an SD2PET and tried to load from it.


Ah, the good old "device not found".

OK, various options here, any of the three MC3446s the 6520, 6522 and whatever the other 6520 was.

I notice there are three different types of MC3446 chips. The soldering on these looks better and the flux has been cleaned up on the back of the board, so I guess some of these have been replaced in the past by a different person to the other chips.

I swapped out the 652x chips one by one with known working WD65C2x chips and tested each time, but still got device not found.

I also swapped in a known good 6502A in case there were any incompatibilities with whatever the remarked part was.

It did sound like it could be an issue with the 6522, and I note an AND gate in it's enable circuitry has previously been replaced.

Not convinced by the soldering there, but these boards are quite fragile, and it is easy to lift traces when removing chips.

I have a feeling I might need to undo and redo some of the previous repair work to check the tracks underneath and make (hopefully) better solder joints.

There I will leave it for part 1. I need to use the PET IEEE-488 diagnostics to check which signals are bad and fix those as appropriate.

Advertisements

PET ROM/RAM

As mentioned above, many PET faults are down do bad ROM chips or bad RAM chips, and a PET ROM/RAM chip can often help bypass those. You can order one from The Future Was 8 bit.

https://www.tfw8b.com/product/commodore-pet-rom-ram/

More info in a previous post:

http://blog.tynemouthsoftware.co.uk/2022/08/testing-pet-rom-ram-boards.html


Mini PET B

Or if you want an easier solution, the Mini PET B is a drop in replacement for a PET / CBM 40 column 32K motherboard.

More info in a previous post:

http://blog.tynemouthsoftware.co.uk/2023/10/building-a-mini-pet-b-kit.html

Mini PET B at SellMyRetro:


PET Diagnostics.

The PET Diagnostics modules are available from my SellMyRetro store:

Patreon

You can support me via Patreon, and get access to advance previews of posts like this and behind the scenes updates. These are often in more detail than I can fit in here, and some of these posts contain bits from several Patreon posts. This also includes access to my Patreon only Discord server for even more regular updates.

https://www.patreon.com/tynemouthsoftware

Posted by at
Labels: , , , ,
Subscribe to: Posts (Atom)