PDA

View Full Version : Nice PET but garbage screen



tezza
October 28th, 2008, 11:39 PM
Hi,

I've taken posession of one of the models which was top of my "must have" list. It's a mint-condition Commodore Pet (3032 model).

http://classic-computers.org.nz/blog/images/08-10-29-pet-unpacked.jpg

I bought it as a faulty unit, but I'm hoping I can probably work through the problems and eventually fix it. The main problem is this..

http://classic-computers.org.nz/blog/images/08-10-29-pet-screen-garbage.jpg

..which I figure might be RAM. But then, I've learnt from the Apple experience that you can never tell with such non-specific symptoms.

One thing that surprised me was just how few of the ICs were socketed (compared to the Apple II)? Given the vintage, I'd expected at least the RAM to be socketed but they are hardwired in, which is going to make things a lot tricker.

Anyway, I started off with a simple 4116 RAM piggy-back trick. Oddly, on the second chip I got a change; the screen turned to all zeros? Even stranger, I couldn't repeat this symptom? When I tried piggybacking the chip again, there was no change to the standard garbage display. Piggybacking on the other chips also made no difference. I never saw those zeros again. Weird! Maybe I just didn't have the legs lined up properly.

So. Never mind. I'm glad I've at last got a Pet and in such good cosmetic condition. The video seems rock-solid without any sway or flicker.

Any comments, hints or advice is welcome.

I'm not going to be doing much in the next two weeks though. I'm off to Cyprus for a conference. The hotel has wireless Internet so I'll probably check into the boards from time to time.

But then again... :)

Tez

tezza
October 28th, 2008, 11:57 PM
Just to let people know, I've already found this thread (http://www.vintage-computer.com/vcforum/showthread.php?t=5381). It looks useful and I'll try these when I get back

Tez

pontus
October 29th, 2008, 12:11 AM
sweet. One of those are pretty high up on my list as well :) But they are rather bulky aren't they?

Oh by the way. You guys need to check out the bbc series "Look around you". A hilarious comedy with references to old computers :) Most episodes are on youtube

http://www.bbc.co.uk/comedy/lookaroundyou/wallpaper/images/640/look_around_you.jpg

carlsson
October 29th, 2008, 12:54 AM
Pontus: The 40 and 80 column PETs recently (?) have become reasonably common in Sweden, down to price levels around 200-600 SEK each depending on condition, location and marketplace. If you are eager to get one, it shouldn't be that hard. In worst case, I may be able to supply you.

Tezza: Good luck with the repair. Unfortunately I think I've used up my last good 3032 motherboard, but may find more. Even if I gave them away, shipping would however cost a little. If you find a particular chip has gone bad, perhaps I can help you although most of those chips are reasonably available elsewhere as well.

tezza
October 29th, 2008, 01:04 AM
LOL, I'll have to check that out.

I just put the PET to bed but before I did I tried a few more things. Firstly, following the advice of Druid in the link above, I did the piggy-back RAM thing again, but this time looking for changes in the pattern. There was very SMALL changes in the pattern occasionally (the odd character) but this pattern would often remain, even when the piggybacked chip was then removed! I'm assuming a MAJOR change is the one to look for if more than one chip is non-functioning and you are trying the piggyback method.

One more thing. When I turned it on to work on it again a screen full of zeros came up!?? Switching off and on again it resumed to garbage. I'm starting the zeroed screen is another boot problem, perhaps intermittent.

I had a quick go at removing the CPU. It's wedged in tight. A job for another day I think.

Tez

tezza
October 29th, 2008, 01:18 AM
Tezza: Good luck with the repair. Unfortunately I think I've used up my last good 3032 motherboard, but may find more. Even if I gave them away, shipping would however cost a little. If you find a particular chip has gone bad, perhaps I can help you although most of those chips are reasonably available elsewhere as well.

Anders, keep me in mind if you do come across a working one. The case and VDU on this unit are in great condition. The PSU seems good too. With all these soldered ICs and not having a working equivalent I can use as a test machine, I'm less confident about fixing this one as I was with the Apples. I'd consider paying a few bucks for a 3032 board, and for the shipping also. It's a lot less from Europe than it is from North American for some reason, even though the former is further away from here.

Tez

tezza
October 29th, 2008, 01:24 AM
sweet. One of those are pretty high up on my list as well :) But they are rather bulky aren't they?


No, not rather bulky, they are VERY bulky. Here is the box it came in. :)

http://classic-computers.org.nz/blog/images/08-10-29-pet-box.jpg

Tez

dongfeng
October 29th, 2008, 02:58 AM
An IBM box too, how ironic! :D

carlsson
October 29th, 2008, 03:54 AM
European shipping costs vary greatly, at least for continental shipping. Traditionally the UK has been the most expensive, followed by countries such as Italy, possibly Spain and unfortunately Sweden. On the inexpensive end you have Germany and the Netherlands. Not sure if France ranks among the cheap or expensive, it depends who the seller is, so to speak.

Fortunately a motherboard doesn't weigh more than 1-2 kg packaged which doesn't drive up the costs too far. In the mean time, you may come across some kind of service manual that would help you find the fault. I strongly believe the CPU is fine, otherwise probably nothing would display at all and besides I've yet come across any 6502 equipment (computer, disk drive) where the CPU was the fault. More likely RAM or perhaps a small logic chip. How about ROM, if the code is corrupted maybe the boot halts?

Vint
October 29th, 2008, 05:14 AM
Tez,
Just have to say that is one fine looking PET you have there! Great on knocking one off the wish list.
For me that PET would definitely be a flagship to my collection. Alas, unless I found one lying along the road somewhere I fear I'll never possess one :(
I've even considered buying a hopeless wreck of one and then trying a restore - but me and IC chips don't seem to get along. Back in the 70's when I was home studying with National Radio Institute taking a Color TV course I worked on many IC projects and although I was decent on theory, I was lame on the practical end. I remember I built this color bar generator thing and I couldn't get it right to save my life. It was full of IC's and that kind of put me off to working with them much. I never finished the course :(
Sorry, I'm getting off course here - but seeing that nifty PET of yours evokes old memories.

Good luck with fixing it and 'bringing it back alive' in 2008!

pontus
October 29th, 2008, 05:56 AM
Pontus: The 40 and 80 column PETs recently (?) have become reasonably common in Sweden, down to price levels around 200-600 SEK each depending on condition, location and marketplace. If you are eager to get one, it shouldn't be that hard. In worst case, I may be able to supply you.


I've seen some show up on "blocket" and "tradera" and I almost went down to Gothenburg to pick one up. Anyway I have too much stuff going on right now to search for one actively, but should you come across one that you don't want for yourself I'm certainly interested.



"So much by thus has never been due much if a reduced number." - Babelfish mangled quote

Churchill?

Luzur
October 29th, 2008, 08:22 AM
I almost went down to Gothenburg to pick one up.

hmm? someone i know? :)

billdeg
October 29th, 2008, 08:52 AM
I had the same exact problem and 80'sfreak on this board helped me by supplying the chip I needed. We basically switched them out until we found the one with the problem. It was one of the 85xx chips, not the RAM.
Bill

carlsson
October 29th, 2008, 11:30 AM
Luzur hooked up with a seller outside Stockholm who had a truckload of PETs, and there has been some other PETs in the Stockholm - Uppsala - Västerås region. I sold one refurbished 2001N on Retro Gathering.

(And yes, my signature is Churchill's famous one, translated a few steps too many)

Luzur
October 30th, 2008, 09:17 AM
yep, he even had a PET 2001, i think he got a decent load of money out of the load as well.

he even gave a working 8032 to me as a "thank you" for helping him. :)

pontus
October 30th, 2008, 01:44 PM
hmm? someone i know?

Maybe, it was an ad on blocket with two Pets and some calculators. Judging from the pictures the owner had some fancy wallpaper :)


I sold one refurbished 2001N on Retro Gathering.

I've missed Retro Gathering completely, next time I'll have to go.

Hmm, were getting a bit of topic. Hows it going with the garbage on the screen?

carlsson
October 30th, 2008, 02:43 PM
Hmm.. I just found a loose 4032 motherboard. I also have a complete 3032. Functionality wise, would the 4000 series board work in the 3000 computer (power connector, keyboard, monitor) just that it comes with Basic V4 instead of V2?

I'll look it up and if it appears safe, swap boards in the weekend. If the 4032 board is fully OK, I may offer Tezza to buy it. While it wouldn't make his PET a genuine 3032 anymore, it would make it work.

tezza
October 30th, 2008, 04:06 PM
Hi Andres,

Let me know how it goes. I'd certainly consider it although it would depend on what the all up cost is incl. shipping etc.

My ultimate goal would be authenticity but a working PET would be ok, while I slowly work at the 3032 board to get it going, or perhaps see if I can source another in the long term.

Anyway, I'm packing for Cyprus at the moment and probably won't be on the boards for a few days. I hope to log on from there though.

Tez

Mike Chambers
October 31st, 2008, 08:01 AM
that PET is awesome, good luck getting it running right.

pontus
November 4th, 2008, 04:57 AM
Speaking of the devil:

http://www.tradera.com/Antik_dator_Commodore_CBM_3032-auktion-76668891

per
November 4th, 2008, 05:21 AM
Speaking of the devil:

http://www.tradera.com/Antik_dator_Commodore_CBM_3032-auktion-76668891

I don't know the values on those, but I think I figured 750 Kroner is pretty cheap for that system.

I remember an IBM PC TX on finn.no that was listed for 5000 Kroner! That's what I call overpriced!

carlsson
November 4th, 2008, 05:40 AM
750 SEK was a bargain two years ago. Today it is pretty much the going rate, perhaps a tad on the low side. On the other hand it is the opening bid, so chances are the final bid would be higher than that.

I sold a 3032 + 3040 drive in June for 800 SEK, local pickup. Currently I have a pile of broken drives but not yet any clues how to trouble shoot them other than switching chips at a random.

Of course prices in Norway are a completely different matter than Sweden. Vintage computers tend to cash in 50-100% as much on the Norwegian market, which is why some Swedish sellers have begun to look across the border.

per
November 4th, 2008, 05:59 AM
Of course prices in Norway are a completely different matter than Sweden. Vintage computers tend to cash in 50-100% as much on the Norwegian market, which is why some Swedish sellers have begun to look across the border.

I know. Commodore 64es goes for about 750-1000 kroner. they're like 100-200 kroner on Ebay.

Radioman
November 18th, 2008, 03:39 AM
Hi,
I bought it as a faulty unit, but I'm hoping I can probably work through the problems and eventually fix it. The main problem is this..

http://classic-computers.org.nz/blog/images/08-10-29-pet-screen-garbage.jpg

Tez


Hello tezza

I'm new to this group and are wading trough all posts with interrests.
I can tell you that me and my son (14 years old) bought exactly this model with exactly the same problem at an auction last year

.(The auction was at ETA at Chalmers technical university in Gothenburg. There is a very good and funny auction once a year and it will be one this year as well, in two weeks. You nearly allways make a bargain. I f.e. bought a sleve with Telefunken NOS tubes, ECC803S for 100SEK he he he :D :cool: at the same auction last year.)

We measured the PSU and different voltages couldn't find anything wrong.

My son read somewhere to try to "exercise" all chips that sat in sockets. He actually did that and... oh what a happy guy he was when the puters welcome screen suddenly appeared. :) Back from the dead in to a working computer with, as I recall, all the updates to ROM that was available at the time.

This is great fun to see that other people think this old computer is worth to take care of.

I guess I have to comeback with data on ROM's and some pictures as well. Yet another "site" on my allready crowded homepage have to be made :)

Have you tried the "exercising of the chips in the sockets tezza?
// Ove

pontus
November 18th, 2008, 05:27 AM
.(The auction was at ETA at Chalmers technical university in Gothenburg. There is a very good and funny auction once a year and it will be one this year as well, in two weeks. You nearly allways make a bargain. I f.e. bought a sleve with Telefunken NOS tubes, ECC803S for 100SEK he he he :D :cool: at the same auction last year.)


Are you going this year? I will be going for the first time, it would be nice to at least say hello to another forum dweller.

Radioman
November 18th, 2008, 05:53 AM
Hi Pontus

Yes I will :)
We nearly missed it this year because of a vacation travel to Lanzarote. We are back late friday and the auction is on saturday so me and my son are looking forward to this event.
It's not just an auction, it's a happening with very nice and funny people running the auction. Some very special humour to say the least..
:clap2::rofl::geek:

tezza
November 18th, 2008, 02:09 PM
Have you tried the "exercising of the chips in the sockets tezza?
// Ove

Unfortunately for me, very few of the chips are in sockets. Almost all expect the large ones are soldered directly onto the board. (bugger!).

I did wriggle the ones that were in sockets but that didn't make a difference.

I've decided as a long-term project, I'll slowly work through replacing chips starting with the RAM first, and socketing the replacements as I go. The alternative is to get a working motherboard, so I'm keeping my eye out for this too.


Tez

carlsson
November 18th, 2008, 02:54 PM
I'm keeping my eyes open too. Unfortunately there was no score at all last weekend.

tezza
November 18th, 2008, 03:10 PM
I'm keeping my eyes open too. Unfortunately there was no score at all last weekend.

No worries Anders,

Thanks for keeping an eye out for me. Let me know if you find anything. In the meantime I'm going to start working on this board. I'm not going to hurry it. It's going to take me some time to replace and socket all these chips. Hopefully it's RAM but...from my Apple experience I know this fault could be anything.

Tez

Luzur
November 19th, 2008, 03:53 AM
My son read somewhere to try to "exercise" all chips that sat in sockets. He actually did that and... oh what a happy guy he was when the puters welcome screen suddenly appeared. Back from the dead in to a working computer with, as I recall, all the updates to ROM that was available at the time.

yeah i used the same trick when i got rid of my garbled screen problem on the 3032 i got.

tezza
November 21st, 2008, 07:20 PM
Hmm..Ok, I've decided I will NOT replace the ICs on this 3032 motherboard. Rather, I'll look for a new motherboard.

I dragged the MB out of the machine and had a good look at it the other day. While the case, power supply and VDU seem fine, the motherboard is actually in poor condition. About 1/2 the ICS have corroded pins and many of the diodes and resistors also show rust on their legs.

I don't like throwing in the towel, but I think the job is simply too big. Here are some photos...

http://www.classic-computers.org.nz/blog/images/08-11-20-pet%20motherboard%20showing%20rust%20and%20corrosi on.jpg

http://www.classic-computers.org.nz/blog/images/08-11-20-pet%20motherboard%20showing%20corrosion%20on%20dio des%20and%20resistors.jpg

Chips at the front of the MB (like the RAM) look ok, with no rust as all. I tried the piggyback method but it's didn't reveal anything. Although no mice have been nesting in here, the corrosion at the back of the unit is actually worse than it was in those old APPLE IIs I was gifted. With those machines, there were a number of ICs which were faulty.

Andres is keeping his eye out for a replacement board. It anyone else comes across one, I'd like to know about it.

Tez

billdeg
November 22nd, 2008, 04:20 AM
The 3032 is pretty rare in the USA. I don't think that I would tackle the job either, but if there was a way to immerse the board in a solvent that would clean it, I would try that.

Has anyone seen the Commodore 3000 series poster? There was a cool poster that showed the Commodore 3032 and with tons of info. It was a wall poster for techs and computer programmers and I guess it came with the 3032 when you bought one, or you could get it from the store as a promo.

Bill

Druid6900
November 22nd, 2008, 12:25 PM
Hmm..Ok, I've decided I will NOT replace the ICs on this 3032 motherboard. Rather, I'll look for a new motherboard.

I dragged the MB out of the machine and had a good look at it the other day. While the case, power supply and VDU seem fine, the motherboard is actually in poor condition. About 1/2 the ICS have corroded pins and many of the diodes and resistors also show rust on their legs.

I don't like throwing in the towel, but I think the job is simply too big. Here are some photos...



Chips at the front of the MB (like the RAM) look ok, with no rust as all. I tried the piggyback method but it's didn't reveal anything. Although no mice have been nesting in here, the corrosion at the back of the unit is actually worse than it was in those old APPLE IIs I was gifted. With those machines, there were a number of ICs which were faulty.

Anders is keeping his eye out for a replacement board. It anyone else comes across one, I'd like to know about it.

Tez

Well, since you have nothing to lose, if you want to know how I fix up boards like that, let me know and I'll let you in on a few tips.

It will take a lot of soldering, but, no un-soldering.

Chances are about 50/50 that you can recover it or, at least, get it to a point where you will be able to discover the actual fault and fix it.

ampuma
November 29th, 2008, 01:38 PM
Hello,

I had a similar problem:

http://pagesperso-orange.fr/ampuma/pet-2.JPG

After some research, the regulator 5 Volt power line in 6502 was down. 1N4005 diode fails.

I replaced these two components and PET to restart:

http://pagesperso-orange.fr/ampuma/pet-3.JPG

If this can help.

Bruno.

tezza
December 1st, 2008, 12:30 PM
Thanks Bruno,

Druid sent me some advice, which I'm slowly working through. Certainly the board is much cleaner now and all of the rust is gone.

Unfortunately the "garbage screen" symptom could be almost anything, but while waiting for a board to appear I am slowly trying a few things. I'll do a few more checks on the power.

I'm actually in Australia right now. Life has been hectic lately and the vintage computer hobby has gone on the back burner.

Tez

ampuma
December 3rd, 2008, 12:08 AM
Hello Tez,

At your service. I'm french, and passionate collector of the Commodore brand since 1981.

I went to Australia in September 2006 for a month, very beautiful country!

Good luck to spread your PET.

Currently, I started restoring a 2001 PET.

http://pagesperso-orange.fr/ampuma/pet2001-2.JPG

See you soon.

Bruno.

tezza
December 3rd, 2008, 08:59 PM
Nice Pet Bruno,

I would have loved a 2001, as they are the "original" Pet but none seem to ever appear on the market here.

My wife and I are in Melborne for a few day's holiday. Back to New Zealand on the weekend.

Cheers

Terry

carlsson
January 6th, 2009, 06:42 AM
Today I salvaged one more PET, a 4032 model that showed no sign of life when I powered it on. Since those models don't have an internal beeper to indicate life, I thought hard how to determine whether it was the power supply, motherboard and/or monitor that had gone bad. Then it struck me: attach a floppy drive. Those blink their LEDs when the computer is powered on. So I connected a 8250LP drive I had nearby, and just as expected nothing happened.

Fortunately I had a spare power supply from a 8000 series PET, that electrically uses the same PSU as the 2000, 3000 and 4000 series PETs it seems. However the wires to the monitor were cut off, but that's a problem to fix later. First I had to remove the old power supply, which is a story in itself. The supply is screwed onto a metal plate, but actually one should not separate those as it all comes loose as a unit. Instead there are two screws from the inside one removes, then two from the back side. The power supply also features a gigantic capacitor attached with cable tie, that I had to cut loose.

But still it wouldn't let go. Three ground wires were attached to the case, underneath the motherboard and in a way not accessible from the outside! So I had to remove the board, then using a small wrench unscrew the bolt and get the wires free. Finally!

Attaching the replacement power supply went in the other direction, but much faster now when I knew all the steps required. It also has a huge capacitor which I will need to use a fresh cable tie to fasten. Time for the power on test - will it smoke, go BANG or work as expected? Yippie, it powered on nice and easy.

Now for the monitor power, two thin wires that ideally should be soldered onto the power supply. Instead of fiddling with a soldering iron, I grabbed two slices of screw type terminal block and merged the wires. Ooh, will that be enough? I powered it up again and:

### COMMODORE BASIC ###
31743 BYTES FREE
READY.

Wow! Unfortunately the keyboard is rather dull, but I know how to take apart those and clean to full function. I'll conduct more testing later, but it looks promising.

It also means since I'm in the middle of working, I can try a different motherboard to have something to offer Tezza, thus I wrote in this thread. :-D

Update: Ok, two motherboards tested OK. Since the latter one is equipped with Basic 4.0 and lower case characters, I installed it into the 4032 and will trade the other first one.

Luzur
January 6th, 2009, 09:19 AM
Nice Pet Bruno,

I would have loved a 2001, as they are the "original" Pet but none seem to ever appear on the market here.

My wife and I are in Melborne for a few day's holiday. Back to New Zealand on the weekend.

Cheers

Terry

those have been sold occasionally in germany and here in sweden over the years, but all my attempts to get one have failed due to those pesky last-second snipers. aaarggg! :mad:

and a guy in germany sold 3 non functional PET 2001's, without the datasette not so long ago, so they show up every now and then.

Luzur
January 6th, 2009, 09:59 AM
i had some urge to play with my PET 2001 after reading through this thread, so i get it out of storage and plug it in and is met by this:

tezza
January 6th, 2009, 10:00 AM
Time for the power on test - will it smoke, go BANG or work as expected?

Yes, I know that feeling of anticipation and dread :)



Update: Ok, two motherboards tested OK. Since the latter one is equipped with Basic 4.0 and lower case characters, I installed it into the 4032 and will trade the other first one.

Good one Anders! Another PET up and running. Any Pics?

Tez

carlsson
January 6th, 2009, 11:13 AM
I pondered taking some pictures this afternoon, but I was swamped with tools and never went up to grab the camera. Certainly I could take some after pictures.

Luzur: Too bad about your PET. I have one more motherboard, mostly working but may be missing some chip. Should I investigate for you or will you trouble shoot first?

Luzur
January 6th, 2009, 11:39 AM
you what it is then? it works as i can print stuff "behind" that "curtain" of garbled graphics, so it must be something to do with some videchip, right?

i have no clues on PET 2001 computer schematics so i dont know where to start.

carlsson
January 6th, 2009, 12:38 PM
Me neither, but I'd bet on partial RAM problems. I would look up which 4116 RAM chip holds the screen matrix. If it is bad, the computer will read garbage from memory when it generates the display.

For schematics, look here. I believe yours is a 2001N, a.k.a. 3000/4000.
http://zimmers.net/anonftp/pub/cbm/schematics/computers/pet/index.html

By the way, I believe the 6502 CPU generates the video display on the early PETs. Latter models has a 6545 video generator which helps quite a bit, but is nothing compared to even latter video chips like VIC and so on.

Luzur
January 6th, 2009, 02:23 PM
so it could be the 6502 CPu thats making the fuss then?

this is the right schematics for the roms i want, yes?

http://zimmers.net/anonftp/pub/cbm/schematics/computers/pet/2001N/320349-8.gif

i never was much of a schematics reader.... my brother is the professional on computer repairing, but he's offon vacation for 2 weeks now when i need him the most.

tezza
January 6th, 2009, 02:44 PM
so it could be the 6502 CPu thats making the fuss then?

Maybe. Seems like it could be lots of things. This is problem I've found with my PET. There seems to be so many things that might cause the "garbage screen" symptom. RAM seems to be the "most likely" but the effort to unsolder and solder in a whole new bank of RAM begs a more definitive diagnosis.

The question is "where do you start?" If there were some quick tests which could be done to isolate the problem to one part of the circuitry, it would make the problem a lot less daunting.

Anyone know of any type of "diagnostic tree-diagram" for early Pets using a logic probe and/or voltmeter, which might assist people diagnosing faults in these beasts, or at least getting closer to what part of the circuit is not working?

Tez

Luzur
January 6th, 2009, 03:37 PM
well if its soldering involved im screwed, was never a solder master either, i better wait til my brother comes home then try something myself.

one thing i noticed was that UD4 was empty, no chip in place, is that normal?

carlsson
January 6th, 2009, 04:14 PM
Yes, if I understand correctly the whole row of UD2 to UD9 are ROM slots. Well, maybe not UD2 as it contains a SN74154N. The upper four are (without checking) Kernel, Basic and Character ROMs. The remaining three: UD3, UD4 and UD5 would be option ROMs, e.g. for expansion software. The board I'm sending to Tezza has all three empty.

If you can type in a program in blind and execute it, there is probably nothing wrong with the CPU. Of course it means you need to trust that the keypresses register. On the other hand if there would be a CPU fault I doubt you would get any display at all.

While the board in front of me is not a 2001N, I suppose you have a row of 4116 RAM chips at one end. How many and at what locations? It should be U12 to U19, with room for expansion at UJ2 to UJ9. Possibly you also have 32K RAM so all positions would be filled. I don't know if the two small capacitors next to each RAM chip can go bad and cause the fault you're observing. Since you probably don't need to use your PET tomorrow, I'd wait for your brother to have some time to look at it, in combination with schematics. I have some stuff on paper in the basement too, but I believe it all is identical to what's on the web.

Luzur
January 6th, 2009, 05:40 PM
UD3, UD4 and UD5 would be option ROMs, e.g. for expansion software. The board I'm sending to Tezza has all three empty.

UD3 and UD5 have ROMS in them, HN462716 and 2516JOD or JOL (hard time reading what it says cuz someone has made a dot with a marker pen there)


If you can type in a program in blind and execute it, there is probably nothing wrong with the CPU. Of course it means you need to trust that the keypresses register. On the other hand if there would be a CPU fault I doubt you would get any display at all.

havent tried typing any command in yet, perhaps i should, but i wouldnt have a clue if it worked though :)


While the board in front of me is not a 2001N, I suppose you have a row of 4116 RAM chips at one end. How many and at what locations? It should be U12 to U19, with room for expansion at UJ2 to UJ9. Possibly you also have 32K RAM so all positions would be filled. I don't know if the two small capacitors next to each RAM chip can go bad and cause the fault you're observing. Since you probably don't need to use your PET tomorrow, I'd wait for your brother to have some time to look at it, in combination with schematics. I have some stuff on paper in the basement too, but I believe it all is identical to what's on the web.

U12 to U19 have HM4716A-4N in full rows, likewise with UJ2-UJ9and all capacitators looks fine my human eyes.

BG101
January 6th, 2009, 06:50 PM
Tantalums (the little yellow caps) are notorious for going short-circuit - should be easy to check with a meter if you have one. (Cold check) If not maybe bridging the cap using an LED in series with a coin cell.



BG

pavery
January 18th, 2009, 02:26 PM
I'm helping out Tezza by attempting to repair his PET. This 3032 is in excellent condition & as PETs are so rare here in New Zealand - it's mightily deserving in having attention thrown at it.

Summary so far: When turned on, the screen displays garbage. Terry has cleaned the CPU board and removed nearly all rust visible in the photos (at beginning of this thread). He has removed, cleaned pins & re-inserted all socketed ics. He tried piggy-backing the 4116 RAM chips one at a time watching for any change. No consistent change.

I enter the scene. With a scope I have verified Power Supply is fine. All voltages are correct & show no signs of problem ripple. RESET signal at CPU appears fine at start-up. Stays active (lo) for nearly a second after power up. There is also a good CLK signal coming in, plus RDY is active.

Address lines appear all active (signals present on all), however I believe I have found a fault on the Data bus - D4 appears stuck LO.

Referring to circuit diagram: [URL="http://zimmers.net/anonftp/pub/cbm/schematics/computers/pet/2001N/320349-8.gif"]

Pin 14 of F7 (Video Ram 6114) appears stuck HI. There is slight sign of a signal trying to work there, but 98% stuck HI. All other Data pins to F7 & F8 are good signal. Following SD4 thru the buffer (E7) to pins 17,18 - BD4 is stuck LO.

Now, I'm a newbie to Commodore PET design & have had little experience in faultfinding CPU boards. I ask where to from here? Am I correct in assuming D4 is truly stuck? If so, how do I go about determining exactly what is pulling it down? Lastly, am I correct in thinking the 6114 Video Ram can't be 'sticking' it, otherwise the signal would be fine on the otherside of the buffer ic (E7)?

Thanks for any help
Philip

carlsson
January 18th, 2009, 02:44 PM
Hopefully, a good working board should be on its way and arrive in a few days of time. Once there, you should be able to check the jumper settings, then pop it in and go. It'll be configured with Swedish characters though, but it is just a change of character ROM; I think the kernel is identical.

But yes, it would be nice to diagnose the fault on the existing board. By the way when you say 6114, do you mean 4116 or are there chips of both numberings?

tezza
January 18th, 2009, 03:20 PM
Hopefully, a good working board should be on its way and arrive in a few days of time. Once there, you should be able to check the jumper settings, then pop it in and go. It'll be configured with Swedish characters though, but it is just a change of character ROM; I think the kernel is identical.

But yes, it would be nice to diagnose the fault on the existing board. By the way when you say 6114, do you mean 4116 or are there chips of both numberings?

Yea, it would be good to get this board fixed too. That what we are aiming for.

Either way, that PET is gonna be going soon! :)

Tez

patscc
January 18th, 2009, 03:26 PM
carlsson said...you say 6114, do you mean 4116 or
The 6114 is a 1k x 4 static ram in the video circuit.
patscc

tezza
January 18th, 2009, 03:26 PM
Pin 14 of F7 (Video Ram 6114) appears stuck HI. There is slight sign of a signal trying to work there, but 98% stuck HI. All other Data pins to F7 & F8 are good signal. Following SD4 thru the buffer (E7) to pins 17,18 - BD4 is stuck LO.

Sounds like you've narrowed it down Philip. Good going!

Not sure how many old ICs you've got in your workshop there? I've got a few logic chips here from the Apple Haul if it comes to the point where we need to subsitute a chip or two. The two systems seem to have a few ICs in common.

Hopefully someone will have an idea of how to proceed from here. There seems to be a lot less web material on the PET compared to the Apple as far as details of the electronics go, but maybe I just haven't looked hard enough.

Tez

patscc
January 18th, 2009, 03:35 PM
SD0 ends up driving the LSB of the character ROM. Are you getting anything on pin 5 (A0) of F8 (6114) ?

You might want to try connecting SD1 to SD0 ( pin 13 to pin 14 ) and see if there's any difference on the monitor, and if the signal on SD1 collapses.
None of this stuff is socketed, right ?

patscc

pavery
January 18th, 2009, 04:16 PM
SD0 ends up driving the LSB of the character ROM. Are you getting anything on pin 5 (A0) of F8 (6114) ?

You might want to try connecting SD1 to SD0 ( pin 13 to pin 14 ) and see if there's any difference on the monitor, and if the signal on SD1 collapses.
None of this stuff is socketed, right ?

patscc

Thanks Patscc

Strange. The second paragraph of your post only became visible when I replied.

I think you might be looking at the other 6114 (F8 ) instead of F7 where SD4 is. However I tried shorting SD4 with SD5 on F7 and yes, the monitor changes most chars. Eg where 'X' are, these change to 'H' (see original monitor photo). SD5 signal does NOT collapse. Nope, none of this socketed.

Philip

patscc
January 18th, 2009, 04:29 PM
That's because I went back and editied to add a question. F7, F8 close enough. Never could count real well anyway. But you got it anyway.

Well, what I'd do is desolder SD4 (pin 14 on F7) from the board, and then do the same thing you did before (SD5 to the SD4 on the board). If you get the same behavoiur, I'd say dead 6114.

patscc

pavery
January 18th, 2009, 06:12 PM
Well, what I'd do is desolder SD4 (pin 14 on F7) from the board, and then do the same thing you did before (SD5 to the SD4 on the board). If you get the same behavoiur, I'd say dead 6114.

patscc

Ok Patscc. Yes - I get the same behaviour. With SD4 (pin 14 on F7) desoldered and SD5 & 4 linked - I get the 'H's. SD4 on the board now has good signal (as it's now tied to SD5), so I assume nothing was actually pulling it up - it was just that line (D0) of F7 is dead. So I need to replace that 6114 - yes?

Hey Tezza. You gotta 6114 ic (or 2114 as that is what this one is actually)? I ain't.

Question: If this is the only fault in this PET, wouldn't the PET boot up normally and just have a less strange screen than this? I'd expect it to have a mostly clear screen once booted (normally), and that in this case the clear parts of the screen should have the same (albeit wrong) character displayed.

So I ask: Is there something I can type at the keyboard which would activate a latch/port which I could measure without screen feedback?

Philip

patscc
January 18th, 2009, 06:35 PM
Does this have the cassette ?
Try LOAD "foo",1

I think that's the load command.
You should also be able to POKE a memory location to make it beep or write a character to screen, but this varies with model & ROM version.

If you have a manual, the memory locations might be in there.

patscc

patscc
January 18th, 2009, 06:37 PM
Well, a line pulled high in the middle of your character mapping is bound to give you some strange results. Does anything change on the screen when you type ?

patscc

pavery
January 18th, 2009, 07:23 PM
Well, a line pulled high in the middle of your character mapping is bound to give you some strange results. Does anything change on the screen when you type ?

patscc

No change when typing.

So should I go ahead & replace that 6114 (2114)?

My gut feeling is there is at least one other issue as I don't believe we're getting to the READY prompt.

Philip

tezza
January 18th, 2009, 07:48 PM
Hey Tezza. You gotta 6114 ic (or 2114 as that is what this one is actually)? I ain't.



Hmm...maybe. I have both MM2114-3L and MM2114-3 ICs in a C-64 and Vic 20 I have. Will this do?

I see I have a MM2114-3L in my working vic20. What's more it is socketed. I think I have a spare socket also, so if this IC will do the job, it would be a case of soldering in a socket and using the known good 2114 to see if this is the problem. I could post you both the socket and the known working 2114 from the Vic-20, if this is indeed is a equivalent IC.

Tez

tezza
January 18th, 2009, 07:57 PM
My gut feeling is there is at least one other issue as I don't believe we're getting to the READY prompt.

Philip

My gut feeling is the same. If this chip was faulty (or at least if it was the ONLY one that was faulty) you would see the characters change in response to keyboard input yes? Looks like it's not even getting to that phase yet.

The PET could have several issues of course. That PET board was almost as as poor condition as some of those old Apples I processed (but without the mouse droppings) and they all had two or three non-working ICs.

Tez

patscc
January 18th, 2009, 08:56 PM
I'd replace it. I don't know if the 4032 is just locking up due to the bad RAM chip, since I don't know testing/initialization it does. At least if you replace it, you should be able to see what's going on on the sreen & track down whatever other issues.
patscc

tezza
January 18th, 2009, 09:42 PM
I'd replace it. I don't know if the 4032 is just locking up due to the bad RAM chip, since I don't know testing/initialization it does. At least if you replace it, you should be able to see what's going on on the sreen & track down whatever other issues.
patscc

Thanks patscc. I'll liase with Philip off this forum, to progress the chip replacement. However before I do, can you (or someone) verify that either the MM2114-3L or MM2114-3 ICs I have are a proper substitution for the IC in question and if so which is best.

You mentioned a 6114 but from Philip's posts this seems to be labelled 2114?

Tez

patscc
January 19th, 2009, 08:56 AM
The 6114 is a CMOS part, the 2114 is a (I think) NMOS part.
I'll take a look and post back.
Meanwhile, what's the ACTUAL chip on your board ?
I was just going by the schematic.

patscc

pavery
January 19th, 2009, 11:13 AM
Meanwhile, what's the ACTUAL chip on your board ?
I was just going by the schematic.

patscc

The actual chip is 2114

Thanks
Philip

patscc
January 19th, 2009, 12:50 PM
I think it should work. MM, if I remember, is Monolithic Memories.
I dug out my CBM 4032 and tonight will see if still fires up, hopefully actually having one in front of me will help.
patscc

patscc
January 19th, 2009, 01:28 PM
Ok, I have a working 4032, except the keyboard is a bit iffy, so if you guys want a comparison scope reading on something, I can hopefully help out.
patscc

tezza
January 19th, 2009, 02:09 PM
Does anyone know the difference between a MM2114-3 and a MM2114-3L ? Is it significant?

Tez

pavery
January 19th, 2009, 02:10 PM
Wow, thanks Patscc. That could be a great help.

I've had a poke around on the Data & Address Pins on the CPU & there seems to be activity for a brief instant after the Reset comes off, then it hangs. As you suggest, perhaps the problem in the video Ram is causing the boot-up to Halt. So, I'll wait until the 2114 is replaced before going any further.

Thanks Patscc for your help to date - I feel we're really making progress.

Philip

patscc
January 19th, 2009, 02:37 PM
The 'L' only uses 370 mW, max.
The regular one uses a whopping 525 mW.

The -3 is a 300 ns part, the -2 a 200, and the unmarked is a 450.
If you put a slower one in, that might cause a problem.
patscc

tezza
January 19th, 2009, 03:06 PM
Got it!

Thanks Patscc for this and all your help so far.

Tez

MikeS
January 19th, 2009, 04:56 PM
Hey Philip! Glad to see you're expanding your horizons!

I think you *may* be barking up the wrong tree: if BD4 ( E7/17&18 ) is really stuck low, that would bring the whole system to its knees; since SD4 is high and the '244 is non-inverting, I'd suspect E7 before I'd worry about display RAM. If there's a trace from E10/17&18 to E7/17&18 you could try cutting it to see if the system wakes up (with wrong characters of course); either way you can then just bridge the cut again. Easier than pulling chips.

Good luck!

patscc
January 19th, 2009, 06:03 PM
MikeS makes an interesting point.
tezza, I assume you guys still have the pin for SD4 unsoldered. pavery, when you bound SD5 to SD4, did you by any chance sheck BD4 to see if there was activity ?
Actually, while you've got the pin for SD4 unsoldered from earlier, take the scope to the actual pin of the 2114 and see if activity has picked up again.

patscc

tezza
January 19th, 2009, 06:15 PM
I think Philip (pavery) may be away from the Forum right now, but I'll ring him tonight to make sure he's read the message from Mike. I'll be posting him some ICs tomorrow and he might need a few more or different ones.

Thanks for that insight Mike.

We'll get there :)

Tez

pavery
January 20th, 2009, 12:10 PM
Hey Philip! Glad to see you're expanding your horizons!

I think you *may* be barking up the wrong tree: if BD4 ( E7/17&18 ) is really stuck low, that would bring the whole system to its knees; since SD4 is high and the '244 is non-inverting, I'd suspect E7 before I'd worry about display RAM. If there's a trace from E10/17&18 to E7/17&18 you could try cutting it to see if the system wakes up (with wrong characters of course); either way you can then just bridge the cut again. Easier than pulling chips.

Good luck!

Hiya Mike! I thought you might be strolling the Halls of Commodore. Thanks for looking in.

@ MikeS & @ patscc

I've taken time out to thoroughly check measurements & conclusions so far, to ensure we're not barking up the wrong tree.

My initial posting (#51) was seriously flawed. After lots of further schematic study & thinking about this video ram circuitry a whole lot more - I see my errors. I was treating SD# & BD# the same & I was assuming that E7 (244) was active, it wasn't. I'm sorry if this misled you Mike. Best disregard most of Post #51.

Current Conclusion: On power up (after Reset has lifted), I see signals on the Address Bus (AB#) measured at CPU pins, and all Data lines at CPU & at BD# pins of E7,E8. These signals (both Address & Data) are only present for about 0.5 sec thou, then go all HI.

Video Ram: SD4 has always been stuck HI. On a desoldered Pin 14 F7, Pin 14 stays HI, SD4 goes LO. Meanwhile all other Data pins of F7 & F8 have signal - merrily providing Data for the Screen, albeit garbage because it hasn't been initialised by CPU yet. The fact that Pin 14 (F7) D0 stays high desoldered, means to me that F7 2114 is defective.

Here is a snap shot which shows the above:

F7 Pin 14 desoldered:

F7 Pin 14 = HI
E7 Pin 2 = LO (proves my desoldering works :) - no connection between SD4 & D0 (F7))
E7 Pin 17 = HI
E7 Pin 1 & 19 HI (244 inactive)

Incidently I've never seen enable LO pins of E7 & E8 (Pin 1 & 19) be anything but HI (even during boot up phase). I assume then the CPU isn't getting to the stage where it is writing to the Video ram.

So, if we all agree I'll replace the 2114 (F7) when another arrives (1-2 days away). In the meantime can we diagnose why the CPU is going HI after a short spell? If it came across a HLT instruction (either intended or otherwise), that wouldn't cause the Address lines to go HI would it?

Thanking you
Philip

carlsson
January 20th, 2009, 12:25 PM
Let's see if you get to solve this before Tezza has picked up the spare motherboard. Hopefully it is undamaged after a long journey, and also will fit. You two may have to look over the jumper settings, although I don't have a guide handy what they mean.

patscc
January 20th, 2009, 12:32 PM
pavery said...CPU is going HI after a short spell?
All of them ?
Is it actually going high as in ~5 V, or does it look like the bus is going into 'third' state and simply disengaging from the bus ?
While this is going on, are you still seeing a stable system clock ?

I don't think the 6502 does HALT. What are the interrupt lines to the processor up to, by the way ?

patscc

pavery
January 20th, 2009, 01:43 PM
All of them ?
Is it actually going high as in ~5 V, or does it look like the bus is going into 'third' state and simply disengaging from the bus ?
While this is going on, are you still seeing a stable system clock ?

I don't think the 6502 does HALT. What are the interrupt lines to the processor up to, by the way ?

patscc

Ok, here is a snap shot of CPU lines when it comes to a stop.

D0-D7 = LO (0.8V) After some power ups, these stop at HI, after others, they stop at LO
AB0-AB7 = HI (3.8V-4.4V) These always seems to go HI
AB8 = 0V
AB9 = HI
AB10 = 0V After some power ups, AB8,10,12,14 go HI as well.
AB11 = HI
AB12 = 0V
AB13 = HI
AB14 = 0V
AB15 = HI

R/W = HI
(IRQ) = HI
CLK = Good
RDY = +5V
SO = +5V
(NMI) = +5V

Philip

patscc
January 20th, 2009, 04:07 PM
If you've got the time, watch the RDY pin on a scope while it's booting. See if does anything wierd. The RDY can essentially latch an address on to the bus during a read, which sounds like what you've got. I'll try to grok the schematic some more after dinner and see what might be messing with the RDY line.

patscc

pavery
January 20th, 2009, 04:54 PM
RDY goes HI on power up & stays there - no interruption as far as I can see. On a normal scope would it be possible to see a one-off pulse anyway.

I tried my logic probe with Pulse Mem function, but that just records the rising HI of RDY.


I'm using schematic: http://zimmers.net/anonftp/pub/cbm/schematics/computers/pet/2001N/320349-1.gif

Philip

patscc
January 20th, 2009, 06:11 PM
My bad on RDY. I realized later that it only goes to a memory expansion, which presumably you don't have anyway.

With R/W high it looks like it's stuck on a read. If you try to decode the address using your HI-0 V values, I come up with 1010101011111111 , or 0x0AAFF, or 43775 in dec.
What lives there ?
patscc

pavery
January 20th, 2009, 07:53 PM
With R/W high it looks like it's stuck on a read. If you try to decode the address using your HI-0 V values, I come up with 1010101011111111 , or 0x0AAFF, or 43775 in dec.
What lives there ?
patscc

Yikes. I don't know the answer to that. That question is for a Commodore Pet Gonzo :)

If anyone is interested, the entire collection of schematics I'm using is at: http://zimmers.net/anonftp/pub/cbm/schematics/computers/pet/2001N/index.html

I've done two more measurement sessions when the CPU hangs after power up. Unfortunately they're not all the same. Further to above (Measurement 1), I get:

Measurement 2: All Address pins HI, ie AB0-AB15
All Data pins HI except DA1 = LO

Measurement 3: Address pins as in Measurement 1 (ie 0x0AAFF)
All Data pins LO except DA0 = HI. Strangely also on these LOs is a small square waveform about 0.2V hi (taking total amplitude to 1.0V) with a period of about 5ms. I could provide further info, photo of this if necessary.

Philip

PacMan
January 21st, 2009, 05:35 AM
According to my knowledge of the NMOS version of the 6502 processor there is only one input signal that would actually cause the processor to halt like that and it is the RDY signal. But you say that you have checked it so it should be fine. Possibly could also the reset signal make the chip behave like that if it was asserted in an operation but I seriously doubt it.

Now i don't know for sure if there are any illegal instructions that would cause the processor to freeze like this but i don't think so. But if it were so the processor could freeze due to execution of an illegal opcode, which is due to that memory logic fails.

Is there a clock on the phi2 output (Pin 39 of the CPU) ? If not, it could be due to a faulty A10 device or a faulty microprocessor. If there is a clock on the CPU also check that it is available on A10-8.

Do the address and data buffers outside the processor work properly ? You should see the same levels on both sides of a buffer when the processor is halted.

Do you have access to a logic analyser ? With this you could see what the processor does when it dies/halts/freezes.

Just some initial thoughts I had.
/PacMan

patscc
January 21st, 2009, 07:26 AM
PacMan said...processor to halt like that and it is the RDY signal.
You can use RDY & SYNC to single-step, but they only go to a memory expansion bus that doesn't have anything hooked to it.

I dug up a memory map, and it looks like there's free space for a 4k EPROM expansion there. You don't have an extra EPROM in there, by any chance ?

How far are you from getting the other 2114 in there ?

On all your 'stuck' measurements, does the R/W pin stay high ?

What happens if you try manually taking the reset line high ? (To reset with out actually powering down )

patscc

pavery
January 21st, 2009, 01:56 PM
Ok guys, I've replaced the 2114 that had D0 stuck HI. Video looks different, (more random) but alas no Ready prompt. (However I don't think we were expecting that to fix the whole machine.)

Something that puzzles me: SD4 now has a similar signal to SD5-7 - that's good. But strangely SD4-7 is at twice the frequency to SD0-SD3. I didn't notice that with the old 2114. This new 2114 is a 2114N-3L, so it maybe faster than its neighbour (a plain 2114), but they're strobed the same time, so why the difference?

Other stuff...
@PacMan

Is there a clock on the phi2 output (Pin 39 of the CPU) ? If not, it could be due to a faulty A10 device or a faulty microprocessor. If there is a clock on the CPU also check that it is available on A10-8.

Yes, clock on phi 2 and A10-8


Do the address and data buffers outside the processor work properly ? You should see the same levels on both sides of a buffer when the processor is halted.


I checked both sides of buffers C3 & C4. Same levels (HI) when halted.


Do you have access to a logic analyser ? With this you could see what the processor does when it dies/halts/freezes.

No logic analyser, only a 15mHz scope & logic probe.


@patscc


I dug up a memory map, and it looks like there's free space for a 4k EPROM expansion there. You don't have an extra EPROM in there, by any chance ?

Not sure what are the standard EPROMS are in this thing yet (I'm a newbie to PETs), but UD3 & UD4 are empty, rest are full.


On all your 'stuck' measurements, does the R/W pin stay high ?

What happens if you try manually taking the reset line high ? (To reset with out actually powering down )

Yes, R/W stays HI.
Ok to take Reset active (take LO), can I just link it to earth, say 6502 Pin 1? What signals do you want measured when Reseting?

Additionally I've taken the opportunity to replace the 6502 CPU (as it was socketed, easy to do) - no change.

I guess we should be considering that the ROMs maybe faulty. Research on common PET ailments lists the 2114, 4116 & ROMs being common causes. Perhaps when Carlsson's replacement board arrives, (Tezza willing) we maybe able to swap ROMs either onto or out of this board? That would verify that part of the puzzle.

Thanks for the brainpower you guys are shedding on this.
Philip

Terry Yager
January 21st, 2009, 02:53 PM
Someone correct me if I'm wrong, but doesn't the 6502 have the (undocumented) 'HCF' opcode (Halt & Catch Fire)?

--T

patscc
January 21st, 2009, 02:55 PM
Terry Yager quipped...(undocumented) 'HCF' opcode (Halt & Catch Fire)?
Well, that's part of the problem. It's halted, but hasn't caught fire yet.
patscc

patscc
January 21st, 2009, 02:59 PM
pavery said...Reset active (take LO),
That's fine. LO inhibits, the reset is triggered by the next positive edge after 2 clock cycles. So hold, let go, and see what happens.

Is your scope a two-channel, by the way ?
Also, do you have your channel input on the scope switched as AC or DC ?
patscc

pavery
January 21st, 2009, 03:29 PM
Is your scope a two-channel, by the way ?
Also, do you have your channel input on the scope switched as AC or DC ?
patscc

Scope is two channel. Only have two probes, ie can't trigger with a third. On DC.

Philip

Terry Yager
January 21st, 2009, 03:45 PM
Well, that's part of the problem. It's halted, but hasn't caught fire yet.
patscc

Ve haff our vays off arranging zeese sings, you know...

--T

patscc
January 21st, 2009, 04:37 PM
I'd wait on the ROMS. I think they're the mask kind, which are harder to kill than EPROM.
Is all this measuring going on with SD4 still disconnected, by the way ?
patscc

pavery
January 21st, 2009, 06:59 PM
Yeah, wait on ROMS. Sounds good to me - we could all do with a rest from this thang.


Is all this measuring going on with SD4 still disconnected, by the way ?

Yes, until the 2114 was replaced. Latest measurement is:

HI on AB0-AB15.
DA0=LO
DA1=LO
DA2=HI
DA3=LO
DA4=LO
DA5=HI
DA6=HI
DA7=HI

R/W=HI

Lastly, the only technical information I've found for 2001 type PETs is the schematic. Was there never any Theory of Operation or such published for it?

Thanks
Philip

patscc
January 21st, 2009, 07:02 PM
Ah, I missed this. So there's a new, working 2114 in there now ?
What's the display doing ? (Sorry if I missed the post)
patscc

pavery
January 21st, 2009, 07:22 PM
For Patscc: From Post #88


Ok guys, I've replaced the 2114 that had D0 stuck HI. Video looks different, (more random) but alas no Ready prompt. (However I don't think we were expecting that to fix the whole machine.)

Something that puzzles me: SD4 now has a similar signal to SD5-7 - that's good. But strangely SD4-7 is at twice the frequency to SD0-SD3. I didn't notice that with the old 2114. This new 2114 is a 2114N-3L, so it maybe faster than its neighbour (a plain 2114), but they're strobed the same time, so why the difference?

Philip

PacMan
January 21st, 2009, 10:21 PM
I found this page with some information on illegal opcodes for the 6502. http://bbc.nvg.org/doc/6502OpList.txt
It seems there actually is a 6502 opcode that will halt the processor and keep in that state until reset is asserted. If your Pet board is executing this opcode it could very well behave like what you are describing.

Are the ROM's socketed ? If so can you dump the them ?, maybe someone here can compare them with theirs to see if they are valid. If they are valid I would check the select logic for the ROM's (D2) to see that it is working properly.

I am not entirely convinced that it is the video logic that is causing the processor to halt like this, but i am often wrong so don't hold me to it ;-)

/PacMan

patscc
January 21st, 2009, 11:00 PM
pavery said...But strangely SD4-7 is at twice the frequency to SD0-SD3
Possibly the binary representation of the character set. Let me ask you a question. What are you triggering off of when looking at the waveforms ?

You've tried all the obvious stuff, like reseating the ROMS & character ROM, right ?

At this point I'd go get a cup of coffee or a lager, and start checking the SEL lines going to the sytem ROMS (pin 20 on the ROMS) (Don't know if you've done this yet).
Pick a line, reset, observe, next line, etc.

Too bad you guys don't live closer.

I'd also solder a wire to something, or a switch, or something like that so you can do a reset without turning it on/off, if you haven't done this already, so that you don't fry your CRT.

patscc

tezza
January 21st, 2009, 11:11 PM
You've tried all the obvious stuff, like reseating the ROMS & character ROM, right ?

Yep, I tried this when I first got the machine. Reseated and also cleaned them up.

They were well rusted in and during this process I snapped the bottom of a leg off one of the pins. I soldered a replacement on though and I think it's quite firm. It would pay to check it is conducting from the bottom of the motherboard through to the top of the IC though Philip. I think you can see which leg it is.

Anders's board should be here soon. We can then swap out the ROMs and see if there is any difference.

Tez

PacMan
January 22nd, 2009, 05:09 AM
I'd also make sure that the buffers (that would be E7 and E8 ) separating the video logic from the cpu bus is working as they should. If they are defective, by either letting data through although they are disabled or forcing a data pin in some direction, it would garble the data on the data bus while the processor is reading data from the PROM's.

/PacMan

patscc
January 22nd, 2009, 06:07 AM
PacMan said...(that would be E7 and E8 )
I think they've already done this somewhere along the line, at least, I've made a note that they've checked that, so it might just be me misremebering. Anyway, would that bring the bus grinding to a halt, expecially since it isn't happening immediately ?

Anyways, a question for the original fearless duo:
Further suggestions are probably going to go in the direction of injecting pulses at various parts of the board, so unless you're really motivated to fix the board...
And another question, assuming you guys really want to fix the board, can you guys get hold of a pulse/function generator ?

And one last question, which might have already been answered, so please forgive me if I missed it, and that's supposedly the PET has a built-in diagnostic mode. Have you guys heard of that and tried running it ?

patscc

carlsson
January 22nd, 2009, 10:10 AM
Anders's board should be here soon.
I get the feeling you should already have it?


Time Date Status
9.23 PM 12/01/09 Picked up
8.41 AM 14/01/09 Left country of origin
11.53 AM 19/01/09 Arrived in New Zealand
7.00 AM 20/01/09 Delivery Complete
Your item has been successfully delivered.

pavery
January 22nd, 2009, 12:09 PM
While checking system ROMS, I found no power at D9 (F000-FFFF) at Pin 24 (but there was at Pin 21). Another clean of pins of that ROM has restored power to the chip. The display has changed somewhat. Still a screen of garbage, but about 12 different character positions change rapidly (like 5 times a sec). Too quick for a normal cursor. They appear to alternate between 2 different chars. It's always the same 12 positions (after Resets) and they are positioned all over the screen.

The Address & Data lines appear to no longer hang.

The SEL line of D9 appears to flicker active after Reset, then stays inactive. The other SEL to D5-D8 appear never to go active.

Perhaps I shall have a further clean of the other socketed chips?



Possibly the binary representation of the character set. Let me ask you a question. What are you triggering off of when looking at the waveforms ?

You've tried all the obvious stuff, like reseating the ROMS & character ROM, right ?

At this point I'd go get a cup of coffee or a lager, and start checking the SEL lines going to the sytem ROMS (pin 20 on the ROMS) (Don't know if you've done this yet).
Pick a line, reset, observe, next line, etc.

Too bad you guys don't live closer.

I'd also solder a wire to something, or a switch, or something like that so you can do a reset without turning it on/off, if you haven't done this already, so that you don't fry your CRT.

patscc

Using Auto Trigger off Ch 1, off + edge. Yeap, got a Reset switch going.

Philip

patscc
January 22nd, 2009, 01:46 PM
When you guys did the repeated cleanings, did you pull the socketed chips out at all ?
patscc

tezza
January 22nd, 2009, 01:59 PM
When you guys did the repeated cleanings, did you pull the socketed chips out at all ?
patscc

Philip, it looks like you're making progress.

I pulled out all socketed pins initially and cleaned the pins with fine sandpaper. Then re-inserted them.

Tez

tezza
January 22nd, 2009, 02:00 PM
I get the feeling you should already have it?


Time Date Status
9.23 PM 12/01/09 Picked up
8.41 AM 14/01/09 Left country of origin
11.53 AM 19/01/09 Arrived in New Zealand
7.00 AM 20/01/09 Delivery Complete
Your item has been successfully delivered.

Cool, then it's probably waiting for me at my local Post Office. I'll check there tomorrow morning.

Tez

patscc
January 22nd, 2009, 02:07 PM
Do you have a magnifying glass to check and see if the inside contacts of the sockets are corroded as well, or is it just the IC's ?

patscc

tezza
January 22nd, 2009, 02:39 PM
Do you have a magnifying glass to check and see if the inside contacts of the sockets are corroded as well, or is it just the IC's ?

patscc

Philip has the machine but from memory the sockets (like the rest of the board) did not appear to be in the best of shape. I did work the ICs up and down a bit when I re-inserted them to ensure a clean connection and perhaps knock off some of the corrosion but I didn't dose them with any kind of solvent. Maybe I should have?

Tez

patscc
January 22nd, 2009, 02:49 PM
Well, the pics I went back and looked at looked pretty bad. I was wondering if perhaps some pins might have actually been corroded through. However, all that speculation can wait until you've got the ROM's from the new board in.
patscc

carlsson
January 22nd, 2009, 03:10 PM
Why not try to use the new board as it is, possibly replacing the character generator ROM? At least it is fully tested working, only matter is whether the jumper settings match Tezza's model.

pavery
January 22nd, 2009, 04:31 PM
Why not try to use the new board as it is, possibly replacing the character generator ROM? At least it is fully tested working, only matter is whether the jumper settings match Tezza's model.

That's Tezza's call - he may well just do that. On the other hand, the new board provides us with known good ROMs. We could try those in this board. If it turned out we just need another ROM we could probably get that, then Tezza would have two good boards :D


Well, the pics I went back and looked at looked pretty bad. I was wondering if perhaps some pins might have actually been corroded through. However, all that speculation can wait until you've got the ROM's from the new board in.
patscc

I've just pulled all socketed ics, scraped the pins with a knife - all good. Have reinserted & checked continuity from all pins to circuit board (track side). Still no change. :(

Philip

tezza
January 22nd, 2009, 05:32 PM
That's Tezza's call - he may well just do that.

In many ways it's Philip's call as he's doing all the hard diagnostic work! :)


On the other hand, the new board provides us with known good ROMs. We could try those in this board. If it turned out we just need another ROM we could probably get that, then Tezza would have two good boards :D


Yea, that's the aim really. To get two working boards or at least know what components ARE faulty. Pets are so rare here, it's always good to have a stock of known WORKING spares. Given the very tidy condition of the case and video, it's worth it.

Tez

patscc
January 22nd, 2009, 05:51 PM
Goody, I'd hate to see you guy bail now.
patscc

Druid6900
January 22nd, 2009, 06:51 PM
For what it's worth, I've always found it safer to pull chips from a defective board and try them in a known good board instead of the other way around.

Since whatever killed a chip in the first place (corrosion shorted traces, solder ball shorts, etc.) may still be in place on the defective board, it may save killing a known good chip.

Bad chips in a good board will be immediately obvious and you can just shut it down instead of slowly cooking a good chip on a bad board.

pavery
January 22nd, 2009, 07:08 PM
For what it's worth, I've always found it safer to pull chips from a defective board and try them in a known good board instead of the other way around.

Since whatever killed a chip in the first place (corrosion shorted traces, solder ball shorts, etc.) may still be in place on the defective board, it may save killing a known good chip.

Bad chips in a good board will be immediately obvious and you can just shut it down instead of slowly cooking a good chip on a bad board.

Thanks Druid6900. I'd say that's worth quite a bit, that advice. I had it mind.

When the other board arrives, I would like to: study it & compare it *very* carefully with the other board to ensure ROMs, jumpers etc are correctly placed. I do realise it is a 4032 not 3032 board, but I believe the difference is just ROM contents.

Then once the PET is going on new board, try socketed chips from old into new - I guess one at a time.

Back to old board: Tried invoking Diagnostics (taking Pin 5 LO on User Port J2) - no change.

Philip

carlsson
January 22nd, 2009, 10:39 PM
On this other forum I started a discussion:
http://landover.no-ip.com/pet/forum/index.php/topic,505.0.html (http://landover.no-ip.com/pet/forum/index.php/topic,505.0.html)

Check the link posted there:
http://www.amiga-stuff.com/hardware/cbmboards.html

Scroll down to PET 2001, 4xxx, 8xxx, 9xxx. As far as I know, the 3000 series seems just a relabeling of 2001N. The Schematic 320349-01 and PCB fabrication 320350-01 is consistent through a lot of models, only the PCB Assy number differs. I believe this is what is known as the universal board? It was pulled from a 4032 with graphics keyboard, but has Basic 2. As you probably already know, the schematics to 320349 can be found at Zimmers.net FTP (http://www.zimmers.net/anonftp/pub/cbm/schematics/computers/pet/2001N/index.html). There is some jumper information, although very sparse.

Good luck!

tezza
January 23rd, 2009, 12:57 AM
Good luck!

Thanks Anders, If the board is indeed waiting for me at the post office as it should be, I'll visit Philip on Sunday and we'll continue the diagnostic work. We'll let you know how we get on.

Tez

MikeS
January 23rd, 2009, 02:24 AM
Thanks Druid6900. I'd say that's worth quite a bit, that advice. I had it mind.

When the other board arrives, I would like to: study it & compare it *very* carefully with the other board to ensure ROMs, jumpers etc are correctly placed. I do realise it is a 4032 not 3032 board, but I believe the difference is just ROM contents.

Then once the PET is going on new board, try socketed chips from old into new - I guess one at a time.

Back to old board: Tried invoking Diagnostics (taking Pin 5 LO on User Port J2) - no change.

Philip
--------------------
Do I understand that you're getting a 4032 board? If so, it probably won't help much; AFAIK it's quite a bit different from the 3032, much more than just ROMs, although it should be a direct replacement.

Hmm, just read Anders' discussion and am now thoroughly confused and will be interested whether they are indeed similar; if it really came out of a 4032 it should be an 80320xx PCB and not a 320350, but I don't think 4032s ever came with BASIC2...

Maybe someone replaced the 4032 board with a 3032 (or maybe it's just one of those things ;-) ) And who knows what they did "over there"... ;-)

So, never mind; just get them working! Good luck!

patscc
January 23rd, 2009, 06:44 AM
pavery said...Back to old board: Tried invoking Diagnostics (taking Pin 5 LO on User Port J2) - no change
Don't you need to hook up a diagnostic plug to one of the headers on the board ?
patscc

carlsson
January 23rd, 2009, 07:08 AM
MikeS: Yes, the computer is labeled 4032 on the front. I haven't checked the back side. Wasn't there two series of those: one with 9" monitor and graphics keyboard, one with 12" monitor and business keyboard? Frankly I'm not fully educated in this business, just trying to pick up bits here and there. The board I ended up installed in the same computer has the same part/assy number but different ROMs, featuring lower case letters.

MikeS
January 23rd, 2009, 04:46 PM
Well, until now I always thought that all 4032s used the 8032 board, and the list at the Amiga site seems to confirm that (i.e. both 9" and 12" 4032s both show the same board).

But if your PCB is the same number as Tezza's then that's all that matters; either someone replaced the board in that 4032 or CBM labelled some 2001N/3032s as 4032s. Not the only confusion in their numbering history... ;-)

Let's see if Philip can use it to debug the other one; I'm mildly curious myself what's stopping that CPU.

tezza
January 23rd, 2009, 05:48 PM
Jus thought I'd let the people following this thread that I now have the board Anders sent me.

It looks in very good condition, with indeed the same formfactor as the old one. See the picture below. Apart from one bank of ROM being socketed, the only other difference from memory (as the PET is with Philip right now) is that there are three ROM sockets empty. I think mine only had two empty, but I could be wrong.

http://classic-computers.org.nz/blog/images/2009-01-24-new-pet-board.jpg

I'll be driving over to see Philip tomorrow, and we'll see if this replacement board can help us diagnose what's wrong with the original one.

Tez

carlsson
January 24th, 2009, 02:35 AM
The empty sockets are for application ROMs anyway. Now when I think about it, I believe this is a 2001/3000 series board since it has three empty slots. Lately I read that newer 4000/8000 series boards only has two such application ROM slots. Compare jumper settings J4 and J10 with the old board.

pavery
January 24th, 2009, 04:35 PM
Hi Tezza here posting under under Philip's username (and from his place):

Progress! Here's what we've found:


The board Anders supplied works just fine. No jumper changes were needed.
The board Andres supplied is exactly the same type as the original board.
The problems in the original board were the 2114 (which Philip diagnosed and changed) AND one of the ROM ICs (we don't know which one). We determine this by swapping the ROMs over. When we did the old ROMS in the Anders board gave the same symptoms as the original board (i.e. boot failure).
The ROMs in the original board were BASIC 4.0 while the ROMS in Anders board were 2.0! This means the working ROMS (the BASIC 2.0 ones) are more authentic for the 3032. Good stuff.
The keys on the PET don't all work (some are intermittent) but this is probably just a cleaning issue.


More later.

Tez

patscc
January 24th, 2009, 05:34 PM
Yay ! Glad you guys got it working.

By the way, what is this, shill posting ? :)

patscc

pavery
January 24th, 2009, 06:17 PM
Tezza's been working on the keyboard. From having nearly all keys NOT working, now we have all keys working - albeit a few are a bit stubborn. Perhaps with use, they'll improve.

We used Brasso on the PCB pads and a pencil on the rubber conductive key surfaces.

We've also swapped out the Character ROM, as it was Swedish (there were 3 differences on alpha characters that we found).

All in all a happy PET.

Philip

Terry Yager
January 24th, 2009, 09:13 PM
Yay ! Glad you guys got it working.

By the way, what is this, shill posting ? :)

patscc

More like identity theft...

--T

tezza
January 25th, 2009, 12:15 AM
Well, here it is, now working just as it should...


http://classic-computers.org.nz/blog/images/2009-01-25-commodore-pet-working-large.jpg

This was a real team effort. Apart from myself it involved Philip Avery, who spent many hours isolating and diagnosing the problem(s) on the original board, Anders Carlsson, who kindly sent me a working replacement and all the guys who gave moral support and contributed ideas through this forum.

As always, I'll write up the detail in a repair blog. You never know who might find it useful. I'll also add a blurb on the PET to my collection site soon.

carlsson
January 25th, 2009, 07:17 AM
Your next project should be to restore your old board, build a video adapter and keyboard adapter, hook up a different power supply and get another, monitor-less PET. I kind of tried that before, found a few diagrams on video adapters but none worked that well. One may need a very special monitor to handle the frequency. Keyboard should be somewhat easier, also power supply.

MikeS
January 25th, 2009, 08:10 AM
Well, the video is only a problem for folks like Anders & Tezza who live in PAL countries; for us North American folks using NTSC it's no problem at all.

But if you can find a "standard" ten-pin computer monitor or an NTSC-compatible TV it shouldn't be a big problem. A small AT-type PS should work, and PET keyboards and/or PS/2>PET converters are available as well; find a nice unusual enclosure or build one and you'd have a real conversation piece.

pavery
January 25th, 2009, 11:16 AM
Now that we have found the main cause of trouble with the old board is ROM(s) failure, Tezza & I are both curious if it is only one ROM & which one has failed - there are 4 possibles.

At first I suggested just calculate a checksum on each suspect ROM & compare to that of a good ROM (probably in VICE emulator as the new board's ROMs are different, albeit correct for this model of PET).

But it would be good to know 'how much' of the ROM(s) has gone bad. Is it just a single byte, or an Address or Data line gone down/rusty? What we now propose to do is place each ROM one at a time in a spare socket on the running PET & dump it's contents (probably to cassette), then read back & compare byte for byte in VICE. Then, we maybe able to replace just the faulty component in the spare board - the ultimate repair.

Secondly, remember this:

Still a screen of garbage, but about 12 different character positions change rapidly (like 5 times a sec). Too quick for a normal cursor. They appear to alternate between 2 different chars. It's always the same 12 positions (after Resets) and they are positioned all over the screen.

Well, when we got the old board working - it still had this fault. About 12 positions on the mainly blank boot-up screen, flashed rapidly alternating between say a 'blank' and another character.

We replaced one 2114 Video Ram previously, but I assume the other one has a few 'sticky bits' causing this. Is that a fair assumption?

Lastly, to satisfy our curiosity we reinserted the faulty 2114 (with stuck data line), just to see what the display would look like. It was pretty much as we anticipated. A photo of this, and more details will appear in Tezza's blog.

Thanks to posters (particulary Patscc), as I wouldn't have attempted the board repair without your knowledge & help. Thanks to Anders for bringing it to a timely end.:D

Philip

patscc
January 25th, 2009, 12:10 PM
pavery said...flashed rapidly alternating between say a 'blank' and another character

Earlier somewhere, I've lost track of the thread, didn't you mention something about jitter on one of the lines going to the 4114's ? Anyway, you might try using the R/W signal going to the video RAM area as trigger to see if you spot something weird on either the address or data lines to the 2114's.

After you're done with the ROM, you should make it into a button or tie-pin or something.

patscc

pavery
January 25th, 2009, 01:15 PM
Earlier somewhere, I've lost track of the thread, didn't you mention something about jitter on one of the lines going to the 4114's ? Anyway, you might try using the R/W signal going to the video RAM area as trigger to see if you spot something weird on either the address or data lines to the 2114's.

Well, I was getting a faster signal on the data lines of the new 2114, but it may have been a signal of 1010101 as opposed to 11001100. Just strange that two 2114s start off so differently. We didn't do any scoping once the board was working. Maybe... if we get the ROM(s) rectified... and had the old board back in the PET - then we would re-scope the 2114s & sort that fault too.


After you're done with the ROM, you should make it into a button or tie-pin or something.

Tezza oughta start a Shrapnel Jar.

Philip

patscc
January 25th, 2009, 01:24 PM
pavery said...faster signal on the data lines of the new 2114
From what I recall tezza posting, the new is a mite faster, so it'll settle quicker, but that should get smoothed out by the latches. Do you see any jitter on the character ROM address lines ?

patscc

tezza
January 25th, 2009, 03:01 PM
Tezza oughta start a Shrapnel Jar.

Philip

Believe me, the APPLE haul experience has left me with a very large and full one already :)

Tez

tezza
January 25th, 2009, 03:24 PM
..What we now propose to do is place each ROM one at a time in a spare socket on the running PET & dump it's contents (probably to cassette), then read back & compare byte for byte in VICE.

Does anyone know of any diagnostic/ROM-verification programs out there already? I don't think it would take much to write one, but if something is already be out there we could use or adapt it would be quicker.

Actually a diagnostic program which checked out the machine generally (RAM, ROM, etc,) would be nice. Anyone know of one available as a cassette image, which could be converted to audio for loading into the PET?

Tez

pavery
January 25th, 2009, 03:31 PM
From what I recall tezza posting, the new is a mite faster, so it'll settle quicker, but that should get smoothed out by the latches. Do you see any jitter on the character ROM address lines ?

patscc

The PET has left the Hospital and been transferred to the Rest Home (Tezza's place). No scope at Rest Home.

After Tezza has played around with his PET (remember neither of us have ever used one before), downloaded software, etc, then he is allowing me to borrow it for a while so I can evaluate the thing.
I'm particularly interested in seeing it's graphics abilities on it's little beady 9" screen. We may resume action on the old board then.

What were the unforgetable PET games & graphics programs we should be looking at?

Philip

carlsson
January 25th, 2009, 10:26 PM
You can find a set of PET games here:
http://www.portcommodore.com/petfiles.php?path=main-cbmidx-petidx

Some of those may be repeated here:
http://zimmers.net/anonftp/pub/cbm/pet/games/english/index.html

As you probably has found out, there is no native way to redefine the character set so all programs would have to do with C= character graphics. It took 30 years (!) before Nils Eilers (http://landover.no-ip.com/pet/forum/index.php/topic,421.0.html) built a 3rd party hardware expansion that will let you load custom graphics.

Regarding diagnostics, I don't know one off-hand. I have come across some harnesses to connect onto the CPU, I/O ports etc which should be usable to get on-screen diagnostics but I never had a chance to try them. Correct me if I am wrong, but wouldn't an EPROM programmer be able to read a real ROM too, given the proper settings? At least it appears some of the ROM slots on the PET would accept either a ROM or an EPROM (2532?).

patscc
January 25th, 2009, 10:32 PM
pavery said...graphics abilities
From the schematic you've all been staring at so long, the 2114's act as a page buffer for a page of text, and the data drives the address of the char. ROM.
So, if it ain't in the ROM, it ain't drawin' it.

patscc

tezza
January 25th, 2009, 11:08 PM
From the schematic you've all been staring at so long, the 2114's act as a page buffer for a page of text, and the data drives the address of the char. ROM.
So, if it ain't in the ROM, it ain't drawin' it.

patscc

Yea, Graphics as in PETSCII graphics of course. :)

Tez

pavery
January 26th, 2009, 11:37 AM
Does anyone know of any diagnostic/ROM-verification programs out there already? I don't think it would take much to write one, but if something is already be out there we could use or adapt it would be quicker.

Actually a diagnostic program which checked out the machine generally (RAM, ROM, etc,) would be nice. Anyone know of one available as a cassette image, which could be converted to audio for loading into the PET?

Tez

I see there is something in the link Anders supplied:

You can find a set of PET games here:
http://www.portcommodore.com/petfile...-cbmidx-petidx


under The Pet Utilities Archive section, there is ROM.TEST.BAS and RAM.TEST.BAS (albeit Disk image).

Thanks for the links Anders. That should satisfy our appetite for PET games :)

@Carlsson

Correct me if I am wrong, but wouldn't an EPROM programmer be able to read a real ROM too, given the proper settings? At least it appears some of the ROM slots on the PET would accept either a ROM or an EPROM (2532?).

I think you're entirely correct - just that neither Tezza or I have an EPROM programmer. So I think reading a ROM in a spare PET slot is good for us.

Philip

carlsson
January 26th, 2009, 11:50 AM
Okie. I got the feeling you (Philip) were "fully equipped" and that an EPROM programmer would be standard stuff to have around.

As for the disk images, does Tezza have a 40 track drive for the PET? If so, you can use a X-series cable (e.g. XM1541) connected to a 1541 compatible drive to download the images. Disks recorded on a 1541 are readable on 2031, 2040, 3040, 4040 drives. Just be cautious not to overwrite data on the floppy, it may cause sync marks to end up in the wrong places making it unreadable.

tezza
January 26th, 2009, 12:54 PM
Okie. I got the feeling you (Philip) were "fully equipped" and that an EPROM programmer would be standard stuff to have around.

As for the disk images, does Tezza have a 40 track drive for the PET? If so, you can use a X-series cable (e.g. XM1541) connected to a 1541 compatible drive to download the images. Disks recorded on a 1541 are readable on 2031, 2040, 3040, 4040 drives. Just be cautious not to overwrite data on the floppy, it may cause sync marks to end up in the wrong places making it unreadable.

I have an X-series cable and a 1541 but I suspect these are of little use on the old PET. Unless a cheap PET drive suddenly appears on our local auction site I think it will need to be cassette or nothing.

Or manually typing in the program listing *horror*!

Tez

tezza
January 26th, 2009, 01:13 PM
Speaking of typing things in, I'll be looking at that keyboard again tonight. Some of those keys still require a lot of presses before they activate. I was typing in a BASIC program last night and the L key in particular (which I used for LIST) needing repeated taps (and holding your tongue just right) before it worked.

I noticed while at Philip's place, the surface of the small (rubber) contacts at the bottom of the keys (the surface that hits the Circuit board during a keystroke) appear kind of pitted on the worse affected ones. I'm not sure if there is any fix for this. Hopefully there is! Anyway, I'll check them out under a magnifying glass once I've removed the keyboard tonight and see if the lead pencil trick sees further improvement.

I wonder if wiping them down with a damp cloth first would hinder or improve matters? Worth a go I guess.

Tez

carlsson
January 26th, 2009, 03:06 PM
For your knowledge, many of the PETs I rescued also have sturdy keyboards. I found most get better by cleaning the circuit board with isopropanol alcohol, but you may also need to improve the graphite layer on some rubber plungers.

Too bad about the lack of floppy drive. Tape it is then. In moments like those, the C2N232 interface (not currently available for sale) is very handy, something like a combined high speed null modem and tape interface working on any CBM except the B-Series (or perhaps even those if one installs some tape support ROM).

tezza
January 26th, 2009, 03:19 PM
Too bad about the lack of floppy drive. Tape it is then. In moments like those, the C2N232 interface (not currently available for sale) is very handy, something like a combined high speed null modem and tape interface working on any CBM except the B-Series (or perhaps even those if one installs some tape support ROM).

Yes, I think the best option might be to use the PC<-->64 transfer option via X-series cable and 1541 drive (which I can do), then save to tape using a datasette attached to the 64. This should work with straight BASIC programs, yes? I can forsee problems for machine language programs though.

But before I do that, I'll try to get all these keys working properly.

Tez

MikeS
January 26th, 2009, 04:45 PM
EPROM readers & programmers are a lot simpler than many people think, especially if you're only interested in the "standard" 27xxx series; I've built a few from scratch in my time, including one for the PET as a matter of fact.

Here's a reader using a couple of cheap CMOS 4040s that runs off a PC's parallel port; add a couple of transistors and a PS and you've got a burner:

http://www.zws.com/products/index.html

It's even easier on something like a PET where you have a fully programmable parallel port, but then you'd have to write your own software.
---
Re graphics: I don't recall any on-the-fly-programmable CGs from those days, but that doesn't mean they didn't exist; we certainly programmed custom EPROMs for different character sets. But any software doing graphics that way would probably be a lot slower than using one of the available "real" hi-res graphics boards, not to mention non-standard.
---
BTW, another option for the PC <> XM1541/C64 <> PET transfer problem is an IEEE cartridge for the C64 (or VIC-20) if you happen to run across one; also, there were RS-232 interfaces for the PET, and these days there are several other solutions including a couple of IDE HD/CF card interfaces for the PET in the works.

carlsson
January 26th, 2009, 11:56 PM
Dunno about IDE PET interfaces - can you enlighten me? However you're correct that one could wire up cbmlink with a null modem and transfer files that way. If one has a regular tape recorder, you may even generate WAV files out of any PRG and record those directly to tape without going via another computer.

I have a few IEEE interfaces, but I figured they're only good to connect an IEEE storage device (read: floppy disk), not to hook up a PET in the other end and use a VIC/C64 as a slave drive.

tezza
January 27th, 2009, 12:01 AM
I've written a repair blog (http://www.classic-computers.org.nz/blog/2009-01-27-repairing%20a%20commodore%20pet.htm)on this Commodore PET fix, for those who might be interested but don't want to wade through all the postings :)

Tez

carlsson
January 27th, 2009, 08:43 AM
Yep, I commented on your entry too. :)

Basically I think your old Kernel chip may be the first candidate to blame, 901465-22 if I understand correctly.

MikeS
January 27th, 2009, 09:05 PM
Dunno about IDE PET interfaces - can you enlighten me? However you're correct that one could wire up cbmlink with a null modem and transfer files that way. If one has a regular tape recorder, you may even generate WAV files out of any PRG and record those directly to tape without going via another computer.

I have a few IEEE interfaces, but I figured they're only good to connect an IEEE storage device (read: floppy disk), not to hook up a PET in the other end and use a VIC/C64 as a slave drive.
-----------
Jim Brain has an IEEE version of the uIEC in the works, and I thought that Ruud was also planning an IEEE interface to the IDE project he's working on, no?

Not IDE, but as you probably know there are several IEEE<>PC interfaces as well.

I only mentioned the C64/VIC20 IEEE interfaces in case an IEEE drive happens to turn up and you have a C64/VIC20 and XE1541 cable; I don't think you can easily communicate computer to computer. Cassette *audio* can be a little iffy, but you can of course transfer files semi-digitally between Commodores using the cassette ports.

As to the keyboard problem: this is a common issue these days with many of those conductive rubber types. Cleaning can sometimes help, but often the conductive material breaks down too much. Solutions that have worked include conductive PCB repair "pens", auto rear window defroster repair "ink", punching disks out of aluminium foil and gluing them on, etc.; I've tried all three of those and they all worked well.

I'm sure Tez will have many hours of fun with his new pet (lower case ;-) )

MikeS
January 27th, 2009, 09:35 PM
Pictures of a couple of PET projects from the dim past: my PET EPROM programmer, and the 25 foot cable that connected the 2001 game machine upstairs to the 8032/8050 "file & print server" in the office downstairs via the cassette ports.

carlsson
January 27th, 2009, 10:39 PM
Cool, I haven't followed up on uIEC enough to know Jim is working on an IEEE version. I figure timing is much trickier than on the IEC bus though. Ruud's project is to fit an IDE hard drive inside a 1541, using as much as possible of the old electronics which makes me think IEEE currently is not a target although he borrows quite a few ideas from how 8X50 drives work.

tezza
January 28th, 2009, 01:41 AM
Yep, I commented on your entry too. :)

Basically I think your old Kernel chip may be the first candidate to blame, 901465-22 if I understand correctly.

Yes, this is the one Philip suspects. We're working on verifying it. Tonight I played with the PET and wrote a couple of routines, one to dump ROM contents out to tape and other to load a dump in from tape and compare the values to those PEEKed from whatever test ROM is in an expansion socket.

The thought I had was to do a ROM 4.0 PEEK dump (4 parts representing the 4 real ICS) from the VICE Pet emulator saving the cassette data files as a WAV files. Record this on a tape, then read in the taped data on the real PET comparing the values to whatever the fitted test ROM contains.

Tez

MikeS
January 28th, 2009, 06:29 AM
If you only want to know *which* ROM is bad, it oughta be pretty easy to just calculate some kind of checksum for the ROMs and the VICE images & compare them, no?

But your plan using the cassette sounds like much more fun and also more versatile; keep us posted!

tezza
January 28th, 2009, 10:37 AM
If you only want to know *which* ROM is bad, it oughta be pretty easy to just calculate some kind of checksum for the ROMs and the VICE images & compare them, no?

But your plan using the cassette sounds like much more fun and also more versatile; keep us posted!

This is exactly right. There is something sublimly vintage in writing a bit of simple piece of BASIC code which interrogates the system, then reads/writes out sequential data to cassette tape and does comparisons. All this on a vintage system in classic green screen with 40 columns.

Watching and listening to that tape spin whilst writing a block, then stop, then start again as the next block was written while seeing the ROM bytes scroll by on the green screen really took me back. Pure nostalgia.

I guess that's why we do these things.

Tez

BG101
January 29th, 2009, 12:00 PM
I guess that's why we do these things.Absolutely! This is true computing. You couldn't imagine being so "hands on" and in complete control of a modern machine, could you?











BG

patscc
January 29th, 2009, 12:46 PM
BG101 remarked...You couldn't imagine being so "hands on"
Actually, both of my hands are definitely on my XP machine every time I come close to hurling it out the window.
patscc

carlsson
January 29th, 2009, 01:01 PM
On the other hand if you hurl a 15+ kg PET, you may get a slipped disc.

Tezza, you may want to build yourself a prlink cable and use the cbmlink software:
http://www.zimmers.net/anonftp/pub/cbm/crossplatform/transfer/C2N232/cbmlink.html#hw-conn-prlink

Here is a bootstrapping program that can be typed in, saved and run in order to download the cbmlink client software:


99 hs=201:rem system type
100 av=32:ack=59468: rem ack (out) is cb2
110 dat=59471: rem port a
120 ddr=59459
130 sv=2:srobe=59469: rem strobe (in) is ca1
199 rem *** init handshaking lines
200 poke ack, (peek(ack) and 254) or (128+64+32)
300 print "waiting for command":gosub990
310 printby
320 if by then 330
322 by=hs:gosub 1190
324 by=0:gosub 1200:gosub 1200:gosub 1200:gosub 1200
326 goto 300
330 if by=1 then gosub2000:goto300
340 print"(unknown function)":goto 300
989 rem *** switch from send to receive, then receive a byte
990 poke ddr,0
999 rem *** receive a byte
1000 if (peek(sr) and sv) = 0 then 1000
1010 poke sr,sv
1020 by = peek(dat)
1030 i= peek(ack): i = (i or av) - (i and av) : poke ack,i
1040 return
1189 rem *** switch from receive to send, then send a byte
1190 rem
1199 rem *** send a byte
1200 if (peek(sr) and sv) = 0 then 1200
1210 poke sr,sv
1220 poke ddr,15:poke dat,by
1230 i= peek(ack): i = (i or av) - (i and av) : poke ack,i
1240 if (peek(sr) and sv) = 0 then 1240
1250 poke sr,sv
1260 poke dat,by/16
1270 i= peek(ack): i = (i or av) - (i and av) : poke ack,i
1280 return
1999 rem *** load
2000 gosub1000:print"bank"by
2010 by=0:gosub1190
2020 gosub990:f=by:gosub1000:f=f+256*by:print"from"f
2030 gosub1000:t=by:gosub1000:t=t+256*by:print"to "t
2040 for a=f to t-1
2050 gosub1000:printa,by
2060 next
2070 return

tezza
January 29th, 2009, 04:03 PM
Thanks Andres,

I had a go last night at doing the PC ---> Pet transfer via cassette without much luck.

I saved the PET ROM dump/comparison program as a TAP file from VICE then used a utility called audiotap to convert this to a WAV I could output through the sound card to a conventional cassette recorder. After recording I'd transfer to a C-64 datasette attached to the PET and try loading.

No joy. Occasionally using certain volume levels the PET would "find" the file but the name would usually be garbled and no load would occur.

I suspect it's because my cheap and nasty MODERN cassette recorder (really a dictaphone) only has a MIC input and automatic levelling. Although the final tape sounds loud it probably has any peaks cut off.

Anyway, there are many ways to skin a cat with this one. Unfortunately, they are all with a blunt spoon! I need to solve the problem though, for along with wanting to do this ROM comparison, I want to get a library of tape software for the PET also.

I don't want to build any more hardware except as a last resort. So tonight I'll try one more TAP-->Wave converter (TAPClean) and if that doesn't work I'll look at..

Hooking up the 1541 C-64 drive via my X1541 series cable, booting opencmb and copying a D64 disk with the pet program(s) on it. I'll then use the C-64 as an intermediary, loading from disk and saving out the program(s) on cassette. I'll then load the programs in to the PET, applying the necessary m/l monitor hacks to get the PET to find the BASIC program location (which apparently would have loaded in to a location a C64 would expect..but one that is different for the PET). After recovering the program I'll then save it as a PET cassette file.

Whew! If this works, all should be sweet (maybe it IS faster to build a cable..lol).

If it doesn't work. Well...err. I'll cross that bridge when I come to it. I don't want to unpack my DOS machine if I can avoid it which means I've limited myself to Windows XP solutions at the moment. We'll see how they go.

Solving these problems is largely the fun of it all, isn't it? :D

Tez

carlsson
January 29th, 2009, 10:19 PM
Be aware of the slight speed/frequency difference between various CBM computers. Since you live in PAL land, your C64 probably runs at 0.985 MHz, your PET close to 1.00 MHz and your VIC-20 at 1.01 or even 1.02 MHz. These values may seem indifferent but since the computer is timing the pulses on tape it may be the make or break difference. In NTSC land, I believe all three run at the same clock speed or at least closer to eachother.

tezza
January 30th, 2009, 12:59 AM
Right. Good news.

1. On the software transfer front...

I managed to sucessfully get a PET BASIC program from a D64 disk image off the net into the PET via the X1541/opencmb method described above. It worked the very first time!


http://classic-computers.org.nz/blog/images/2009-01-30-pet-basic-game.jpg

I'm confident I can get whatever BASIC program I need for the PET transferred this way. This means I can start to build my software library. Not sure just how you would do machine code ones. Maybe it's even easier as it's simply a memory dump? No BASIC pointers to move about.

2. On the ROM testing front.

I've decided I don't actually need to move a program to the PET for this. I can use my C64 to compare the ROM data.

The program I wrote on the PET can interrogate the ROMS including the expansion ROM. I can dump the data of each BASIC 4 ROM IC onto cassette, by fitting them one at a time into a spare expansion socket and reading the whole IC.

I've also wrote a small program on the VICE PET emulator (in BASIC 4.0) on my Windows machine, which does the same thing except it dumps it's ROM contents out into virtual disk in D64 format. So I've now interrogated "good" ROM 4.0 contents, in chunks (five sequential disk dumps) which correspond to the 5 separate ROM ICs in the original board.

Tomorrow, make real C-64 floppy disks from the D64 images. I'll then write a THIRD program, this time on the real c64 which will take data from the tape dump made from the PET (of the ROM IC under test) and compare this data with the corresponding ROM data from the floppy disk made from the D64 disk dump produced in the PET emulator. This comparison should tell me exactly what ROM (and which addresses in the ROM) are faulty.

So. A program on the PET to read an expansion ROM socket and dump to tape, a program on the PC (in PET VICE) to read segments of BASIC 4.0 ROM and write it to disk, and a program on the c64 hooked up to drive and tape, to compare the two sets of data.

Should work, yes?

Tez

carlsson
January 30th, 2009, 04:12 AM
Basic and machine code pretty much are the same thing. A machine code routine can be located elsewhere than the start of Basic programs, it is when you load ,1,1 and need to know a SYS address to start it. Other machine code programs may have a Basic stub already containing the SYS, which makes it easier to start. Only if you want to save a block of memory (machine code) it gets a bit tricky.

By the way, VICE already comes with the ROMs as binary files. You may need to add a load address to them and merge onto a D64 although your way to do it will work too.

pavery
January 30th, 2009, 11:34 AM
Great progress Tezza. I am impressed with those PETSCII graphics - that's the first time I've seen them in action.

Those fine lines, on angles and all - amazing what's in those character graphics. Makes the TRS-80 I/III look prehistoric :shocked:

Following ROM Check with major interest.

Philip

billdeg
January 30th, 2009, 11:47 AM
Awesome. I never saw a working 3032 before.

tezza
January 31st, 2009, 03:03 PM
Ok, a progress report.

I decided in the end to check the ROMS this way..

1. Dump all ROM contents to cassette from the PET.
2. Use the C64 to transfer the ROM files from cassette to sequential files on disk
3. Make a D64 disk image from the disk with the ROM files
4. Use the Vice PET emulator configured as a 32k 3032 with BASIC 2.0 and whatever Basic 4.0 ROM (using ROM files found on the net) in the spare ROM slot B (as set up in the VICE Settings-->Rom Settings-->Computer menu) to do the comparison.

The idea is then to read in the sequential file from virtual disk of whatever ROM is under test and compare that to the ROM contents in the B ROM slot. All virtual, using the emulator.

I've written the programs and tested them. At the moment the C64 is churning away reading the ROMs on cassette and transferring them to disk.

I've already discovered one thing watching the data flow even without a comparison. The F000 kernal ROM certainly seems damaged (good deduction both Philip and Anders). What comes out of that is a series of triplets .ie. 234, 234, 234, 124, 124,124, 154, 154, 154 and so on. This is clearly wrong. Quite different from the dumps from the other ROMS, which is the expected seemingly random collection of numbers.

Anyway, once the ROM transfer is complete and I can check them all with the comparison program, I can see if any others are damaged.

I thought some of you might like to see the workbench while all this is going on:


http://classic-computers.org.nz/blog/images/2009-02-01-pet-rom-check-workbench.jpg

Casual readers might wonder WHY I'm going to this extent to diagnose just one broken IC rather than using checksums (I have wondered myself!). I guess it's a challenge and fun, and in doing so I've learnt a lot about Commodore DOS and file handling (this was mostly unknown to me), revisited some old programming skills and found out more about the (impressive) VICE emulator.

I'll let you know if the other ROMS check out ok.

Tez

tezza
January 31st, 2009, 05:56 PM
I've already discovered one thing watching the data flow even without a comparison. The F000 kernal ROM certainly seems damaged (good deduction both Philip and Anders). What comes out of that is a series of triplets .ie. 234, 234, 234, 124, 124,124, 154, 154, 154 and so on. This is clearly wrong.

And that was wrong. Actually on closer examination they are in a series of fours, not threes.

Tez

tezza
January 31st, 2009, 07:58 PM
right, finished. It looks like TWO of the Basic 4.0 ROMS were damaged. The F000H one as mentioned previously and also the one starting B000H. The other three checked out just fine.

The data in the B000H is not in fours like the F000 one. However, I've compared it to the two verisons of the ROM I could find (one was a "patched" version) and neither come close.

As a final check I got the test program to output the data to the screen in ASCII. I was hoping to see some embedded keywords or error messages there. Sure enough, on both the stock ROMs images those words appeared. Not on the test B000 ROM though. Nothing I could recognise at all.

It occurred to me that I might have read the wrong ROM chip so as a final, final check I re-inserted the IC in the PET and PEEKed at some values. They corresponded with the ROM dump so it was definitely a dump of B000.

It must be faulty too.

So...the old PET board is almost fully diagnosed. A faulty 2114, faulty F000 and B000 ROM ICs and (possibly) a second video 2114.

Now it's on to getting a few more PET programs from the NET to cassette.

Tez


Tez

MikeS
January 31st, 2009, 08:36 PM
My hat's off to both you and Philip; you guys are really making progress, all the more remarkable since neither of you has much experience with these babies nor a very comprehensive set of relevant tools. Are ya sure you don't want to build one of those quick & dirty EPROM reader/programmers?

Following your exploits is definitely tempting me to dig mine out and play with them a bit; I used to work with and on PETs professionally back in the dark ages, but I seem to have forgotten what little I knew; time for a few refresh cycles...

Enjoy!

m

MikeS
January 31st, 2009, 09:16 PM
By the way, AFAIK the 6332 type ROMs are pin-compatible with the ROM chips used in the old PCs & XTs (although only half the size); if you've got an old PC/XT with empty sockets it might be easier to read them there and have the contents on a PC in the first place.

They are NOT the standard JEDEC pinout for 27xxx EPROMS though; if you're going to replace single chips you'd need 2532s or equivalent, not 2732s (unless you want to make or buy an adapter).

Don't remember off-hand if they match the pinouts of a C64 game cart, but they weren't usually socketed (and probably not standard anyway)

If you're running with the old ROMs you probably don't have the built-in machine language monitor; that might be one of the programs you want to downoad if you're going to poke around in the ROMs...

Have fun!

m

tezza
February 1st, 2009, 12:52 AM
If you're running with the old ROMs you probably don't have the built-in machine language monitor; that might be one of the programs you want to downoad if you're going to poke around in the ROMs...



Actually Basic 2.0 (the one on the replacement Anders-sourced CPU board) DOES have the built-in machine language monitor. And just as well. I have to use it to tweak the Pet to recognise BASIC programs (even PET ones) sourced from the Internet but saved on the cassete from the C64. I have to do this is because BASIC programs saved on 64 loads in the wrong place on the PET to be seen by the BASIC interpreter. PET BASIC starts at location 1025 ($0401 in hex) and the later Commodore machines have different, higher starting locations.

Of course I have to use the c-64 as an intermediary to get Internet-sourced programs as Cassette is the only way this PET communicates with other machines.



My hat's off to both you and Philip; you guys are really making progress, all the more remarkable since neither of you has much experience with these babies nor a very comprehensive set of relevant tools.

Hey, I did play with a PET once in a shop 30 years ago!

Thanks for the encouragement Mike. Well, where this is a will there is a way. Having the right tools and experience would have made things quicker and more straightforward but we probably would have learned less and it wouldn't have been half as rewarding. In the end, albeit by a fairly torturous route, we got there.

Tez

carlsson
February 1st, 2009, 07:45 AM
I still own a few 2532's, but my regular EPROM programmer won't handle them. Currently I have borrowed a different programmer that theoretically could program them, but it is mostly of academic interest.

pavery
February 1st, 2009, 11:58 AM
While faultfinding the old board, we noticed one of the Basic ROMs was actually an EPROM. During its earlier life, this PET presumely must have had a ROM failure and it was repaired by burning & fitting an EPROM as a replacement. Tezza: Was that ROM one of the faulties?

Great work Tezza on identifying the bad ROMs with tools available. Brings me to the question: If a ROM isn't socketed, is it possible to read it with another system while it's in a dead board? Perhaps you can attach a clip or, last resort, solder a heap of wires to pins so to connect it to reader/another computer.

With emulators & ready access to ROM images on the net, this would make it easy to verify ROMs in the early stages of faultfinding a system.

Philip

tezza
February 1st, 2009, 12:39 PM
While faultfinding the old board, we noticed one of the Basic ROMs was actually an EPROM. During its earlier life, this PET presumely must have had a ROM failure and it was repaired by burning & fitting an EPROM as a replacement. Tezza: Was that ROM one of the faulties?



No, the EPROM ROM was actually OK. The two that were faulty were standard production ROMS.

It was interesting to see what a zapped ROM had inside it. The F000 one was repeating sequences of 4 bytes each. Makes you wonder why it happened?

The B000 is still a bit mysterious. It must be damaged as it doesn't correspond to the ROM dumps. However, it looks "normal" in that there is just a collection of bytes rather than being a pattern like the F000 one.

Out of curiosity, it would be interesting to try to disassemble it to assembly language just to make sure it IS garbage. It would be easy to do, as I have an image now and I'm sure I could find a PET disassembler on the net. I could do it all with the VICE emulator. I'd have to learn a bit of 6502 assembly language though otherwise I might think that it's talking sense.

Hmm...Maybe that's taking the diagnostic process just a little TOO far :)

Tez

pavery
February 2nd, 2009, 11:05 AM
It was interesting to see what a zapped ROM had inside it. The F000 one was repeating sequences of 4 bytes each. Makes you wonder why it happened?

I reckon A0 & A1 are stuck internally - that would give 4 consecutive reads the same.

Philip

tezza
February 2nd, 2009, 12:01 PM
I reckon A0 & A1 are stuck internally - that would give 4 consecutive reads the same.

Philip

Good point. That's probably it.

I wonder if a firm tap on the edge of a benchtop would unstick those things? :) (naa..just joking!)

Tez

MikeS
February 2nd, 2009, 01:53 PM
<snip>
If a ROM isn't socketed, is it possible to read it with another system while it's in a dead board? Perhaps you can attach a clip or, last resort, solder a heap of wires to pins so to connect it to reader/another computer.

With emulators & ready access to ROM images on the net, this would make it easy to verify ROMs in the early stages of faultfinding a system.

Philip
------
I'd think that it wouldn't be too difficult to just plug into the CPU socket and read memory from there (assuming the decoders & buffers are OK); reading at the ROM chip pins might be a little trickier since you'd be driving the *outputs* of address decoders & buffers etc. Also wouldn't help much if a bad memory chip was holding one of the address or data lines high or low permanently...

Interesting idea to explore though.

m

MikeS
February 2nd, 2009, 02:22 PM
Hmm, usually a bad ROM shows a pattern of some sort; any possibility that you're comparing that B000 Rom to a different image?

Have I got this right BTW: you've presumably unsoldered all 5 ROMs from a BASIC 4 board and are putting them into a BASIC 2 spare socket one at a time, saving to tape, and comparing that file to an image from the VICE set?

m

tezza
February 2nd, 2009, 03:33 PM
Hmm, usually a bad ROM shows a pattern of some sort; any possibility that you're comparing that B000 Rom to a different image?

Have I got this right BTW: you've presumably unsoldered all 5 ROMs from a BASIC 4 board and are putting them into a BASIC 2 spare socket one at a time, saving to tape, and comparing that file to an image from the VICE set?

m

Yes, that is correct Mike. Except they were socketed so no soldering was required. Also the board they were taken from is exactly the same type as the (Anders-sourced working) board with BASIC 2.0. I think the original board was a genuine 3032 one, which had a BASIC 4.0 upgrade.

From cassette the ROM data was transferred to a sequential disk file via a C64, then imaged into a .d64 disk image file the VICE emulator could read.

Both the VICE set of ROMS were looked at, and also ROM dumps sourced from the net. When testing, a 4k binary ROM DUMP matching the ROM under test was attached to the virtual ROM B socket in the VICE PET emulator running the 3032 configuration with 32k and BASIC 2.0. Essentially this reproduced exactly the system (our working PET) from which the test ROM data was sourced. The emulator read test data from the sequential file on the D64 disk image and compared this to the ROM data in the (virtual) spare socket.

For three of the ROMS it was a perfect match. The F000 test data showed all these 4x repeating values. However, The B000 showed no repeating values but it was a complete mismatch notheless.

The suspect B000 IC in question has the letters 901465-23 stamped on it. The ROM file I got from the Net had basic-4-b000.901465-23.bin as the file name and the website said it was from B000 of the BASIC 4.0. I also found another earlier version of B000 ROM 4.0 called basic-4-b000.901465-19.bin. I tried this one too, but again no match. I also compared the first 4k of the VICE BASIC 4.0 binary against the basic-4-b000.901465-23.bin and found it to be the same. Also, the standard B000 VICE or Net-sourced ROM image when viewed in ASCII shows a lot of BASIC error messages and keywords (as you would expect). The test B000 ROM DUMP shows none.

I thought perhaps I might have got the ROM dumps mixed up? So I inserted the B000 IC in the real PET's spare socket and peeked a few values, comparing them both with the standard ROM data and Test ROM data off the D64 disk image. No, the test ROM data showed exactly the same numbers, shown that it had indeed, come from this IC.

So I'm satisfied that the standard ROM B000 image I'm using for the test is correct. I'm also satisfied that the programming and transfer methodology is sound, as it worked fine for the other three ROMS. I've also verified that the ROM dump data is correctly labelled and did come from my real B000 IC.

I'm puzzelled about the lack of pattern too. Why might this be? I'm very tempted to disassemble the code to see if it is indeed garbage.

Tez

MikeS
February 2nd, 2009, 03:52 PM
Well, it sure sounds like you've covered all avenues. Any chance you just don't recognize the pattern? If one (or more) of the data bits is stuck it's not always obvious, since some bytes will probably match while others won't; especially obscure if more than 1 bit has a problem. A binary comparison can sometimes be helpful.

I'd be really interested in the programs you've written/are using to dump/read/compare these images (and even that mysterious B000 image itself); any chance you could zip something up and send it to me off-list? Might just be the thing to finally get me playing with the PETs again...

m

patscc
February 2nd, 2009, 04:04 PM
I wouldn't mind a copy of the code and ROM image as well.
patscc

tezza
February 2nd, 2009, 05:56 PM
I'd be really interested in the programs you've written/are using to dump/read/compare these images (and even that mysterious B000 image itself); any chance you could zip something up and send it to me off-list? Might just be the thing to finally get me playing with the PETs again...

m

Sure thing. Just so long as you don't laugh at my poor programming technique. :)

I'll get them organised, zip them up and post them as a link in this forum. I'm happy for others to take a look. It might take a day or two. I'll TYPE the programs I used on the PET and C64 out and add them as text files (they are both short and it's less hassel than transfering them both into a PC environment).

Tez

patscc
February 2nd, 2009, 06:06 PM
I'd never.
The main reason I want it is to make sure I'm reading the dump the way the code generated.
What are the markings on the bad ROM, by the way ?
patscc

tezza
February 2nd, 2009, 08:22 PM
I'd never.
The main reason I want it is to make sure I'm reading the dump the way the code generated.
What are the markings on the bad ROM, by the way ?
patscc

901465-23 is the B000 ROM

901465-22 is the F000 ROM

Tez

tezza
February 3rd, 2009, 12:13 AM
The (zipped) files I used for the ROM testing can be downloaded from this link (http://classic-computers.org.nz/blog/files/tezzas-pet-rom-check-files.zip).

They are not elegant. I'm not a professional program (or even in IT) so these were just quick and dirty hack files which did what needed doing.

Before zipping these up I checked those ROM images again. Yea, maybe there is a pattern of sorts on B000. There are very few bytes under 100 decimal for a start. And some repeating-type sequences. See what you make of it.

Also, C000 comes up with a mismatch at the very last byte. When I first ran this I thought that maybe I'd just miscalculated the length of the dump by one. Now I'm not so sure?

Anyway, enjoy.

Tez

tezza
February 5th, 2009, 01:03 PM
Hi, as with most of my vintage projects, I've summarised the ROM diagnosis in a blog entry (http://www.classic-computers.org.nz/blog/2009-02-6-diagnosing%20faulty%20pet%20roms.htm).

For those people who might be curious but haven't been following the discussion (and don't want to wade through the detail postings), or those who might like to see screen shots of the ROM check program in the VICE emulator.

P.S. one thing I'm curious about. This might be a stupid question but could the method be used to read and compare ANY pin-compatible ROM IC (say from an Apple?)?

Tez

MikeS
February 5th, 2009, 07:36 PM
P.S. one thing I'm curious about. This might be a stupid question but could the method be used to read and compare ANY pin-compatible ROM IC (say from an Apple?)?

Tez
------------
Why not? The key is "pin-compatible"...

It is a little roundabout, but hey, if it works. But don't you have anything in your collection that could read them and copy directly to a PC?

tezza
February 7th, 2009, 01:53 AM
------------
Why not? The key is "pin-compatible"...

It is a little roundabout, but hey, if it works. But don't you have anything in your collection that could read them and copy directly to a PC?

Yes, I guess I need to back up a bit and ask the question "Are all ROM ICs that have the same number of pins and same shape "pin compatible"? If I found a ROM IC from another computer which fitted into those spare PET ROM Sockets, would I be able to read it just by peeking at the memory address the socket occupied?

Or is every computer different? How standard are ROM ICs?

Tez

patscc
February 7th, 2009, 06:15 AM
Well, there's ROM, PROM, and various flavours of EPROM.
Until JEDEC standardized them, there were some differences.

You might have better luck if the ROM's are the same capacity, but even that's no guarantee.
If they are different capacities, the pinouts & board layouts on the CBM wouldn't really allow that.

For instance, the data & address lines are on almost the same pins on the CBM as on the IBM.
One of the differences is that where A12 on the IBM ROM is, CS3 lives on the CBM ROM, and CS3 is tied to VCC. So you couldn't just drop an IBM ROM into a CBM and read it out.

On the CBM, you'd be pretty much limited to something that uses only 12 address lines.
patscc

MikeS
February 7th, 2009, 07:07 AM
Just to add .02:

The only chips you'll be able to read in a PET will be those that are compatible with 2716s (2KB) and 2532s (4KB). The 24 pin ROMs in PC/XTs, C64s etc. are 8KB, so you'd only be able to read 1/2 the chip (although as I mentioned before, the PC should be able to read the PET's ROMs).

So, it'd have to be a 2KB or 4KB chip, and you'd have to look up the pinout to see if it's compatible.

tezza
February 7th, 2009, 09:54 AM
That answers the question. Thanks.

Tez

cosam
March 9th, 2009, 02:20 PM
I saved the PET ROM dump/comparison program as a TAP file from VICE then used a utility called audiotap to convert this to a WAV I could output through the sound card to a conventional cassette recorder. After recording I'd transfer to a C-64 datasette attached to the PET and try loading.

No joy. Occasionally using certain volume levels the PET would "find" the file but the name would usually be garbled and no load would occur.
I just tried that very technique to get a .PRG from a D64 image onto tape and, although it didn't work straight away, checking the "Invert waveform" box in audiotap got me a working tape. Quite a kick to have the PET running software again!

I was quite surprised to find a small selection of audio cassettes in the local big-chain consumer electronics store. Thankfully I found them straight away - given the average age of the staff there, I was really expecting a blank look if it came to asking if they stocked them!


I suspect it's because my cheap and nasty MODERN cassette recorder (really a dictaphone) only has a MIC input and automatic levelling. Although the final tape sounds loud it probably has any peaks cut off.
I guess a dictaphone would be optimised for speach frequencies or, maybe more likely, built to a budget and not much use for anything else. I dug out a "proper" data recorder I got with a Spectrum many moons ago and it works great.

Slightly dissapointing though is that I've not yet been able to save anything from the PET to tape, although I have the C64 the C2N came with so I can at least test if it's down to the PET or the tape unit.

patscc
March 9th, 2009, 02:42 PM
Have you guys tried those cd to cassette adapter they used to have where one part was a cassette that went into your cassette deck, and the other went into your 3.5mm output jack ? If you do try this, just make sure you feed the signal to both channels, not just one.
patscc

tezza
March 9th, 2009, 02:59 PM
>Slightly dissapointing though is that I've not yet been able to save anything
>from the PET to tape, although I have the C64 the C2N came with so I can
>at least test if it's down to the PET or the tape unit.

Hmm..that is strange. My Commodore C2N saved PET output just fine. Dirty heads in the Cassette recorder?.

Tez

cosam
March 9th, 2009, 04:21 PM
Unfortunately playing back the PET tape in the trusty data recorder revealed only a deathly silence, so I don't think it's the heads. Could of course be something just as simlpe, like a bad connection at the plug. If not, as long as I can at least narrow the cause down to either PET or tape drive, it shouldn't be too hard to trace.

track18
March 22nd, 2009, 12:02 PM
Hi Tez,


Thanks Bruno,

Druid sent me some advice, which I'm slowly working through. Certainly the board is much cleaner now and all of the rust is gone.

though not in the worst of all possible states, my PET's board could also use a cleanup -- it has a thin, but sticky layer of fine dust (forgot to cover the machine while renovating our house's upper floor), and some pins look a bit corroded. So do you think you could tell the public which measures you took in order to clean your board? (Or did I just miss the corresponding posting?)

Regards --

track18

tezza
March 22nd, 2009, 04:48 PM
Hi Tez,

though not in the worst of all possible states, my PET's board could also use a cleanup -- it has a thin, but sticky layer of fine dust (forgot to cover the machine while renovating our house's upper floor), and some pins look a bit corroded. So do you think you could tell the public which measures you took in order to clean your board? (Or did I just miss the corresponding posting?)


Well, in this case I removed all socketed ICs and put the board through the dishwasher (a technique first suggest to me by Druid). I used a small bit of detergent rather then dishwashing power (just a tiny amount or you get foaming). I stood the circuit board on it's edge.

After dishwashing, I then finished off the drying in a fan-bake over at about 50-60 degrees. In the meantime I scraped the rust off the socketed IC's with very fine sandpaper.

Just make sure it is completely dry before re-inserting the ICs or plugging it up.

I then attacked the soldered-in ICs, gently extracting the surface rust off the legs with sandpaper, and checking none had rusted completely. At the same time I checked the rusty legs of the static components to check if it was surface rust, or any of the legs had actually corroded through

Tez

track18
March 24th, 2009, 04:31 AM
Tez,


Well, in this case I removed all socketed ICs and put the board through the dishwasher (a technique first suggest to me by Druid). I used a small bit of detergent rather then dishwashing power (just a tiny amount or you get foaming). I stood the circuit board on it's edge.

After dishwashing, I then finished off the drying in a fan-bake over at about 50-60 degrees. In the meantime I scraped the rust off the socketed IC's with very fine sandpaper.

Just make sure it is completely dry before re-inserting the ICs or plugging it up.

I then attacked the soldered-in ICs, gently extracting the surface rust off the legs with sandpaper, and checking none had rusted completely. At the same time I checked the rusty legs of the static components to check if it was surface rust, or any of the legs had actually corroded through

Tez

thanks for these detailed instructions! Sounds a bit scary, though -- one wouldn't expect water and electronics to go well together... On the other hand: why not? A PCB shouldn't contain anything that coud be washed away, and if one waits until everything is really dry before re-applying power, everything should be fine.

(A couple of months ago I managed to spill some tea into my running laptop. After a few seconds, the thing went out and initially refused to come to life again, but after drying it thoroughly it worked just as before the accident!)

Regards --

track18

tezza
March 24th, 2009, 10:20 AM
thanks for these detailed instructions! Sounds a bit scary, though -- one wouldn't expect water and electronics to go well together... On the other hand: why not? A PCB shouldn't contain anything that coud be washed away, and if one waits until everything is really dry before re-applying power, everything should be fine.


Yea, it is a bit scary. I have to say also that I've usually done this with old circuitboards that were not working anyway, in order to clean the dust and mouse pee off them before repair.

So usual disclaimers apply :)

Tez