PET 4032 symptoms I can't even find mention of

[Gregert Beardrondo]

I recently found a Commodore PET in the Greater Toronto Area, and bought it. (for slightly more than it was worth, but it's the first I've seen in the country, let alone nearby) At the time it worked wonderfully, though the keyboard needs cleaning.

A few days ago I left it running a program, simple, that flashed "GAME OVER" on the screen, as I'd offered to loan it to someone making a short film, and he needed it to do that. After about ten minutes (I never left the room, I just moved on to other things) something terrible happened:

The screen did not exactly 'invert', but something similar. White space was replaces with zeros, and most other characters with, well, other characters. But the program continued to run, and one could see GAME OVER on the screen, but written in verticle lines on a background of zeros. Again, though, the program continued to run, from all zeros to GAME OVER (sort of).

Now, hoping that some bit of memory had become corrupted, I turned it off and on again. No dice. But it DID successfully boot, just, again, white-space zeros and non-white-space incorrect. But it does, as it did before, flash garbage on the screen before the reset and boot.

I thought maybe this was just a problem with the video hardware, that perhaps the correct data WAS stored in RAM or VRAM. So I tried typing some BASIC commands, and they were shown as garbled on the screen, and got "SYNTAX ERROR", but, again, not actually that but a garbled version of it. Thus implying that what is shown on the screen is what is stored.

Both input from the keyboard and output from the CPU produce characters consistently incorrect. That is to say, and 'A' from the keyboard and an 'A' from the CPU both produce, for example, 'Q'. But they ALWAYS produce 'Q'.

Here's what's actually shown on the screen immediately after booting:
:::0S<]]<T<RU0RQSYS04>00:::0000000000000
0000000000000000000000000000000000000000
0317430RYTUS0VRUU0000000000000000000000
0000000000000000000000000000000000000000
RUQTY>000000000000000000000000000000000
0000000000000000000000000000000000000000
0000000000000000000000000000000000000000
0000000000000000000000000000000000000000
0000000000000000000000000000000000000000
0000000000000000000000000000000000000000
0000000000000000000000000000000000000000
0000000000000000000000000000000000000000
0000000000000000000000000000000000000000
0000000000000000000000000000000000000000
0000000000000000000000000000000000000000
0000000000000000000000000000000000000000
0000000000000000000000000000000000000000
0000000000000000000000000000000000000000
0000000000000000000000000000000000000000
0000000000000000000000000000000000000000
0000000000000000000000000000000000000000
0000000000000000000000000000000000000000
0000000000000000000000000000000000000000
0000000000000000000000000000000000000000
0000000000000000000000000000000000000000
(The non-zeros above translate to:
"COMMODORE BASIC 4.0
317430 BYTES FREE

READY")

I read (I cannot remember where) that the PET has a workaround to reduce snow on the screen caused by the inability of the video hardware to access VRAM while the CPU is accessing VRAM,(The VRAM runs at such a speed that at any given time one of the two is blocked out) and that the CPU retrieves input from VRAM, rather than directly from the keyboard. Since the program that was running continued to work fine,(Other than the garbled output) it can be assumed that the system RAM is fine.

Thus it is either of two causes: 1) The VRAM is damaged in such a way so as to produce the same failure every time. 2) Some chip that translates and records data to VRAM from BOTH the keyboard and CPU is damaged in such a way as to produce the same malfunction every time.

The first seems the more likely culprit, but I feel as though errors in (V)RAM should be less consistent. I don't know enough about the PET to even know if the second is possible.

So, here's where you come in: What type or VRAM does the PET 4032 (Or really, any of the 30xx, 40xx, or 80xx, I expect) have, and any idea where I could get it?

THANK YOU

 

[MikeS]

I believe the video RAM consists of two 2114 chips; I'm also pretty certain that I have some, but I'm not at home at the moment so I can't confirm. I'll have a look when I get back.

 

[Gregert Beardrondo]

Thank you for the info. If you do have some, would you like to trade? I'm certain I can find something of value. As far as discrete components, I have little. A few 8088's is the only thing special. Assorted unknown PROMs, etc. I'm sure I can find something, though. Anything specific you need?

 

[Dwight Elvey]

Hi
Chips often fail at an I/O pin. It looks like you
have such a single bit failure. It could be your VRAM,
something between that and the character ROM or
the buffering chip from the CPU bus.
An ASCII 0 is 00110000 in binary while and
ASCII space is 00100000 in binary. The other letters
seem to have the same bit munged( I didn't go through
them all ).
Swapping the VRAM chips should cause a similar
change in the errors if it is one of those
chips that has failed. This should not be too hard to
trace down. I recommend a little trouble shooting
before turkey shooting.
Dwight

 

[dave_m]

An ASCII 0 is 00110000 in binary while and
ASCII space is 00100000 in binary. The other letters
seem to have the same bit munged( I didn't go through
them all ).

Nice detective work. Yes, it sure looks like bit 4 is stuck high or open.

I recommend a little trouble shooting before turkey shooting.

Nice play on words. Yes, random shotgunning can be dangerous to the health of a computer.

 

[Gregert Beardrondo]

That's excellent! I'll go through most of the letters tonight to make sure. That would explain why some DO work correctly.(All those with a zero at bit 4) My mutli-meter and scope are both a few hours away right now, but I'm sure I can find something to borrow.

My hero!

EDIT: I was of course going to try the 'piggy back' trick with the VRAM before doing anything permanent...

 

[Gregert Beardrondo]

I was on google looking to find out what chip was used as the character ROM in the PET, and found an entry in Tezza's blog: http://classic-computers.org.nz/blog/2009-01-27-repairing a commodore pet.htm

On that page is this image:

This is, aside from being a different version of ROM, exactly the same. It was caused when they replaced a 2114 VRAM chip with one thought to be faulty. That exactly the same thing happened (white space switched for zero, rather than something else, likewise for the other characters) implies it was even the same pin. Perhaps a batch was made with a weakness at this pin?

Here's the datasheet for the 2114: ftp://206.248.167.39/38957.pdf Interestingly, they are 4-bit, and so the two together are 1kB, and presumably every character is written across each chip? It must be, because if one character were written in halves to two nibbles, then there would be two bits wrong in each character, and as the whole screen is 1000 bytes, half the characters, those written to the good 2114, would be fine.

So there you have it, I/O2 (2 if the designers were sane and didn't write the characters backwards as well as across two chips) on one of the 2114's is stuck at zero.

Now, to get this thing downtown where I can use one of the school's oscilloscopes to find out which chip is the problem!

I've found plenty of 2114's for sale on the internet, but they're all so new... I'll hate having to put a new IC in this old beast, but it must be done. While I'm at it I'll be adding a socket, as well, I think.

 

[MikeS]

I was on google looking to find out what chip was used as the character ROM in the PET, and found an entry in Tezza's blog: http://classic-computers.org.nz/blog/2009-01-27-repairing a commodore pet.htm

On that page is this image:

This is, aside from being a different version of ROM, exactly the same. It was caused when they replaced a 2114 VRAM chip with one thought to be faulty. That exactly the same thing happened (white space switched for zero, rather than something else, likewise for the other characters) implies it was even the same pin. Perhaps a batch was made with a weakness at this pin?

Here's the datasheet for the 2114: ftp://206.248.167.39/38957.pdf Interestingly, they are 4-bit, and so the two together are 1kB, and presumably every character is written across each chip? It must be, because if one character were written in halves to two nibbles, then there would be two bits wrong in each character, and as the whole screen is 1000 bytes, half the characters, those written to the good 2114, would be fine.

So there you have it, I/O2 (2 if the designers were sane and didn't write the characters backwards as well as across two chips) on one of the 2114's is stuck at zero.

Now, to get this thing downtown where I can use one of the school's oscilloscopes to find out which chip is the problem!

I've found plenty of 2114's for sale on the internet, but they're all so new... I'll hate having to put a new IC in this old beast, but it must be done. While I'm at it I'll be adding a socket, as well, I think.

Well, you're close ;-) It's D4, not 2, and it's stuck at 1 instead of 0 but otherwise you're right on; 2114s were notorious, so it's not at all an unusual problem.

The data is split between the lower and upper 4 bits and in your case bit 4 appears to be stuck at 1 (high); this is pin 14 of UC5 (the one toward the rear of the machine).

Why does a replacement 2114 have to be old, especially if you're putting in a socket? How old does it have to be?

 

[tezza]

If you can't find a source, in our PET repairs Philip and I got the replacement 2114 out of a junk Vic-20. They have a few of them, and were reasonably easy to desolder out

Tez

 

[carlsson]

Yes, a first generation VIC-20 will have eleven 2114 chips. A second generation VIC has only three 2114 or so. Another source would be a broken PET. I still have some motherboards but I'm afraid all RAM chips are soldered to the board and I'm not eager to do any desoldering.

 

[Gregert Beardrondo]

Well, you're close ;-) It's D4, not 2, and it's stuck at 1 instead of 0 but otherwise you're right on; 2114s were notorious, so it's not at all an unusual problem.

The data is split between the lower and upper 4 bits and in your case bit 4 appears to be stuck at 1 (high); this is pin 14 of UC5 (the one toward the rear of the machine).

Why does a replacement 2114 have to be old, especially if you're putting in a socket? How old does it have to be?

...That's what I meant...

I assumed that D1 was the 1-bit, D2 the 2-bit, D3 the 4-bit, etc.

You say that D4 is stuck high, but the datasheet says D4(I/O4) is pin 11?
And of course is doesn't HAVE to be old. It just feels wrong for it not to be. I don't think I would socket an old one; I really want to keep this as close to factory-default as possible.

Thanks for the tip, Tezza. (And the awesome blog post) I'll see if I can find a damaged VIC-20 in Toronto. I know a place where there might be some hope. If I can't find one, I'll send you a PM and we'll work something out?

 

[MikeS]

Some people like to take simple problems and make them complicated... ;-)

Admittedly there can be some confusion about pin names, especially on old data sheets like the 2114; these days the data pins are usually labelled zero to whatever, but just like disk drives they are and were also labelled starting at one.

But either way I don't know how you got I/O 2 stuck at 0? The problem is obviously with the 16-bit; being stuck high adds 16 to the ASCII value of the displayed characters, which turns a space (32) into a zero (48 ), etc.

The 16-bit is the fifth bit (D4 or D5 depending on how they're labelled) which, since the 8 bits are split into two halves is the lowest bit of the upper four, i.e. pin 14 of UC5.

It is of course also possible that it's the buffer that's defective, but my money's on the 2114.

I did mention that I have lots of 2114s and I'm in Toronto, didn't I? I can scuff one up a bit and make it look old if that's important...

 

[Dwight Elvey]

...That's what I meant...

I assumed that D1 was the 1-bit, D2 the 2-bit, D3 the 4-bit, etc.

You say that D4 is stuck high, but the datasheet says D4(I/O4) is pin 11?
And of course is doesn't HAVE to be old. It just feels wrong for it not to be. I don't think I would socket an old one; I really want to keep this as close to factory-default as possible.

Thanks for the tip, Tezza. (And the awesome blog post) I'll see if I can find a damaged VIC-20 in Toronto. I know a place where there might be some hope. If I can't find one, I'll send you a PM and we'll work something out?

Hi
I think things are getting a little confusing. He was talking about bit 4 of
the 8 bit bus 0 through 7.
You were talking about what the manufacture called a pin of the part. These
are two different things.
Also note that different manufactures lable pins differently for a 4 bit part,
they might be 1 through 4 or they might be 0 through 3.
For things like RAMs there is no rule that says the parts bit number need
to correspond to and particular bit on the bus. Some components do need
to have some correspondents to function correctly, such as ROMs.
It would seem that for the video, there are 2 4 bit chips in creating an
8 bit value. It might be something like:

Bus bits chip bits
0 D1
1 D2
2 D3
3 D4
4 D1
5 D2
6 D3
7 D4

So his statement that it is pin1 of some chip is most likely correct.
Dwight

 

[carlsson]

Watch out for "factory default". From my limited experience, socket or not socket seems to have been an almost random decision, perhaps from factory to factory or production runs. You might find two identical PET motherboards of the same revision and similar production date where one has plenty of sockets and the other has close to none. It gets even more interesting if you look at which chips are socketed or not.. roll a dice. If you score 5 or 6, insert a socket on the motherboard. Otherwise solder the chip directly to the board.

 

[MikeS]

BTW, how do you know how old the ones on ebay are? FWIW, my 4032 uses OKIs dated 3645; when was that? On the other hand, my 8032 uses NSCs.

I may have some OKIs but they'll take some time to find. I do have NEC, Moto and Intersil versions at hand; if you want one of those PM me and we'll arrange the where and when.

 

[carlsson]

3645 got to be the beginning of November 1936, right? Those chips are really old, manufactured before even the transistor was invented! :lol:

 

[Gregert Beardrondo]

@MikeS: I didn't even look on ebay, actually. I've always had poor experiences there. I found two or three sites which were selling them, and they appeared to be newly manufactured, rather than new old-stock.

@Carlsson: You've convinced me. I'll use a socket.

@Dwight: That's cleared things up very well, thank you. But (ha) now that I've been told, it makes perfect sense that RAM could be attached to the bus in any way, so long as reading and writing bit n on the bus both pointed to the same pin.

For clarity: In the following I refer to the bus as bits 0-7, bit-7 being binary 128.

A fellow computer science student at school who I spoke to yesterday convinced me that I didn't need an oscilloscope to figure out which chip it was, and he was correct. This may sound terrible: "short out one or several of the data pins and see what changes on the screen". So, since when I woke up this morning all I had nearby that was metal was a transit token, I turned on the PET, waited for it to warm up, and then pressed the token against only the data pins of the chip nearest the front. I then made note that this changed, among other things, the zeros to 4's. PETSCII 0 is x30, and 4 x34, thus the chip I was touching was bit 0-3 on the bus, and therefore the 'good' chip. Because I had just woken up I decided to do the same to the other chip, and from sheer dumb luck, I shorted bit 4 on the bus, likely D1 on the bad chip, and the problem inverted itself; that is, bit-4 on the bus was pulled low. Thus, all characters which had been incorrect became correct, and those few which were correct became incorrect.

So, the bad 2114 is the one nearest the back of the PET.

Yesterday I exhausted craigslist and kijiji in the Toronto area, and went to all the stores I know of looking for a, preferably broken, VIC-20. I found nothing, and I'm definitely not going to butcher the one I already have! So MikeS, I'll send you a PM. I see we're both in Toronto, as well.

So long and thanks for all the fish.

 

[Dwight Elvey]

@MikeS: I didn't even look on ebay, actually. I've always had poor experiences there. I found two or three sites which were selling them, and they appeared to be newly manufactured, rather than new old-stock.

So long and thanks for all the fish.

Hi
I'm not sure if anyone still amnufactures these. Most people that
stock them are NOS or pulls.
JameCo does have them in three versions; The regular 450ns, 200ns
and 200ns low power.
I always like to use the low power ones as they run cooler and
stand a chance of longer life.
JameCo is also a handy place for DataSheets. They have DataSheets
for many of the older parts.
Dwight

 

[Gregert Beardrondo]

Wonderful news. With a gracious donation from MikeS, and a borrowed desoldering pump, this old beast is back to life and running beautifully. I've attached two photos; one of the program it was running when The Bad Thing happened, and one of the boot message.

Thank you all so very much for your help!

It's a little blemished; the sticker's mostly gone and some of the paint is chipped, but IT WORKS.

 

[tezza]

Great! It's very satisfying seeing something spring back to life.

Well done.

Tez