• Please review our updated Terms and Rules here

My PET 2001-8 Revival Project

OK, I peeked inside my PET, and found R12 shorted. And it seems I remember almost nothing about this and would have to start all over to see why I did that.

R12 pulls /INIT up, which can be found at TP7.

What I do know is that somehow I figured /INIT should never go low and some chip is erroneously pulling it low. So by shorting the pullup, I hoped eventually the offending chip would burn out so I could find and replace it. It's been over a year (I think) and it hasn't happened.

Dave, what is /INIT, and does bringing it low cause an IRQ (by way of PIA)? Does Jim's PET even have this signal?

Matt
 
I thought on sheet 6 of Dynamik PET schematics. It could be 7 or 8 though. But I'm positive it's 6, 7, or 8.

It outputs to the inputs of flip flops all over in the RAM refresh areas and display generation.

One of those inputs on mine is bad and pulls the signal low. My limited memory says that when this happens (shortly after boot), /IRQ either gets pulled low, or at least pulses before the ISR gets to SEI. (Spurious interrupts).
 
Keep in mind that the 6502 could be fetching either an instruction or data at $FFFF. Which it is, determines what happens next. I don't think the wrong thing is happening here.

Also, assuming it is correctly reading the vector (which I believe it is), and /IRQ is held low, the IRQ vector is being continuously fetched.

Is /IRQ being held low at the time of the crash? Does removing the PIA after the crash cause the system to resume? (For best practise, install the chip with the IRQ output pins bent up, and use small screwdrivers or wires in the socket to make and break contact)

My memory is being jogged here and it seems this is what I did. Mind you, the only diagnostic tools I used were a logic probe and the PET's usual CRT display.

I may have to put my PET on the bench anyway, just to help you out. I think it's likely it has the same problem yours has. And again, my solution isn't actually correct, but it does make for a working PET. :)

Hi KC,
After the hang the processor is definitely halted. The SYNC (pin 7) of the 6502 which Dave mentioned and I've confirmed on the web should pulse high when reading op codes and low otherwise is held low after the hang. It seems like the last thing the uP does before halting is read the interrupt vector. BTW, to answer Dave, I did try to freeze the H3 and/or H7 chips after the hang and tried again last night. Heck, at one point I put the whole MB in the freezer for 10-15 min and it still didn't change. Only the passing of time seems to make it bootable again. Of course I didn't freeze the transformer, smoothing capacitor or the keyboard...

I just read a blurb about interrupts at http://wilsonminesco.com/6502interrupts/#1.3 and the BRK at http://wilsonminesco.com/6502interrupts/#2.2. Based on my results with TMON and the hanging behavior without it I'm pretty confident that when warmed up the CPU is ending up at a BRK instruction which uses the same vector as /IRQ, namely $FFFE/$FFFF but sets the BRK bit high of the status register to differentiate the two. This leads it to the unset BRKV at $021b which halts the processor unless you have TMON loaded and then from my previous post, I got the following:

B* PC SR AC XR YR SP
.; F75F B4 32 E6 00 E4

The SR flags indicate that a BRK software interrupt has occurred and that interrupts are disabled.
The location $F75F is in the middle of an instruction as shown below. Somehow the PC was set to
$F75E which has value 00 and caused the BRK. I noticed that the PC value printed is the BRK address + 1.

Now the instruction at $F75D is this:
F75D BD 00 02 iF75D LDA x0200,X

below is this instruction which has the only reference to label iF75D
F768 D0 F3 BNE iF75D

if somehow the lower 4 bits of the 3 in F3 got flipped it would be F4 which would cause the BNE statement to go to F75E, cause the BRK and hang the computer.
Could one of the 74LS244 bus driver chips be bad as mentioned to be common here: http://www.6502.org/users/andre/petindex/repairs.html#memory
I already bought 4 of those chips and sockets just in case. BTW, I do have a scope now. I looked at the VIA signals but most of them PA0-7 PB0-7, RS0-1, CS0,-2 look pretty complex while things are running and I'm not yet familiar with how that chip works.

I think we've made some progress here.
 
I forgot to say the other obvious possibility which is that the H4 ROM F000-F7FF is flaky after warm up. I haven't tried replacing that one. I'll get it to hang with TMON loaded a few times and see if it's always the same BRK point in that ROM. I already have a replacement ROM board and EPROM. I can send the EPROM back to Matthew D'Asaro and he can reprogram it to the H4 ROM for me.
Jim
 
In my opinion,

If the address bus is $FFFE or $FFFF, and BRK/IRQ is happening, SYNC should be low, because the 6502 is fetching data, not an instruction.

It sounds like you found that a BRK is encountered inside the Interrupt Service Routine (ISR). But, this only happens after some time delay.

If you leave the PIA out, the ISR never runs, and the system appears to run properly. So, I'd still bend up the IRQ output pins on the PIA, and let the system warm up for a while. If everything is working, you should end up with a BASIC boot message, and a READY. prompt, without a cursor, because the cursor is driven by the ISR. So, it should do the same thing it does when the PIA is out of the socket.

Now, you can assert /IRQ by grounding the /IRQ pin on the 6502, or at the memory expansion connector. If the system hangs on the first try, or after a few, you should end up with the same situation you had with the PIA fully inserted. If not, you should get a cursor after a few tries, and maybe even be able to type some letters.

What I'm getting at, is you're going to be calling the ISR just a handful of times, spread apart, rather than rapidly calling it a hundred times like normal.

This could possibly further isolate the problem.

Also, since you have a scope, now would be a good time to verify the clock frequency.

To answer your questions: It sure could be a bus driver, or a ROM, or the 6502, at this point. Or, it could just be a case of spurious interrupts. I'm not exactly sure what a 6502 does if you sporadically assert /IRQ too fast. If that's the case, the problem is at the PIA or downstream from it.
 
In my opinion,

If the address bus is $FFFE or $FFFF, and BRK/IRQ is happening, SYNC should be low, because the 6502 is fetching data, not an instruction.

It sounds like you found that a BRK is encountered inside the Interrupt Service Routine (ISR). But, this only happens after some time delay.

If you leave the PIA out, the ISR never runs, and the system appears to run properly. So, I'd still bend up the IRQ output pins on the PIA, and let the system warm up for a while. If everything is working, you should end up with a BASIC boot message, and a READY. prompt, without a cursor, because the cursor is driven by the ISR. So, it should do the same thing it does when the PIA is out of the socket.

Now, you can assert /IRQ by grounding the /IRQ pin on the 6502, or at the memory expansion connector. If the system hangs on the first try, or after a few, you should end up with the same situation you had with the PIA fully inserted. If not, you should get a cursor after a few tries, and maybe even be able to type some letters.

What I'm getting at, is you're going to be calling the ISR just a handful of times, spread apart, rather than rapidly calling it a hundred times like normal.

This could possibly further isolate the problem.

Also, since you have a scope, now would be a good time to verify the clock frequency.

To answer your questions: It sure could be a bus driver, or a ROM, or the 6502, at this point. Or, it could just be a case of spurious interrupts. I'm not exactly sure what a 6502 does if you sporadically assert /IRQ too fast. If that's the case, the problem is at the PIA or downstream from it.


Thanks, I'll try that.
If you look up in this thread I included some images of scope readings of some signals including the clock. It is always 1Mhz everywhere I've checked before and after being warmed up, but the two clock outputs of the 6502 appear different and one is rather sawtoothed in appearance which concerned me. Should I be concerned? Earlier on I did swap the 6502 with one from my last known to be working Apple II+ after the PET was warmed up and the hang still happened so I think I've ruled out the 6502 chip itself.

Jim
 
Yes I agree.Thanks for letting me know, I can't really see the pictures in this browser. v Bulletin just doesn't render right.
 
In my opinion,

If the address bus is $FFFE or $FFFF, and BRK/IRQ is happening, SYNC should be low, because the 6502 is fetching data, not an instruction.

It sounds like you found that a BRK is encountered inside the Interrupt Service Routine (ISR). But, this only happens after some time delay.

If you leave the PIA out, the ISR never runs, and the system appears to run properly. So, I'd still bend up the IRQ output pins on the PIA, and let the system warm up for a while. If everything is working, you should end up with a BASIC boot message, and a READY. prompt, without a cursor, because the cursor is driven by the ISR. So, it should do the same thing it does when the PIA is out of the socket.

Now, you can assert /IRQ by grounding the /IRQ pin on the 6502, or at the memory expansion connector. If the system hangs on the first try, or after a few, you should end up with the same situation you had with the PIA fully inserted. If not, you should get a cursor after a few tries, and maybe even be able to type some letters.

What I'm getting at, is you're going to be calling the ISR just a handful of times, spread apart, rather than rapidly calling it a hundred times like normal.

This could possibly further isolate the problem.

Also, since you have a scope, now would be a good time to verify the clock frequency.

To answer your questions: It sure could be a bus driver, or a ROM, or the 6502, at this point. Or, it could just be a case of spurious interrupts. I'm not exactly sure what a 6502 does if you sporadically assert /IRQ too fast. If that's the case, the problem is at the PIA or downstream from it.

KC,
I did the test you recommended bending up the /IRQ pins of PIA #1. This is what happened:

Right after power up the READY prompt is printed but there is no cursor. I ground the /IRQ using a wire and I see a cursor come on and go off with repeated groundings. Holding down a key while doing this results in the key's letter being printed on the screen.

Then I went off for 10-15 minutes and came back.
The very next time I grounded the /IRQ I got the familiar CPU jam with addr pins at $FFFF and data pins $E6. Upon cold reboot there is no change.
BTW, this was all done with my $F800 (H7) replacement ROM board installed so it ain't that ROM that's bad. So I think we've eliminated the possibility of spurious interrupts causing this problem.
I reread one of the best and related threads on this forum closer this time http://www.vintage-computer.com/vcforum/showthread.php?14730-PET-got-seriously-ill in which case a similar CPU jam as I'm getting was occurring although with no /IRQs happening. He reported either getting an infinite loop of BRKs or a CPU jam. The ultimate problem for him was a bad 4k $F000 ROM. Different machine but lots of similarities.

I now understand why "?Illegal Quantity Error" is printed on mine before the CPU jam. From my TMON experiment I know a BRK is occuring just before the CPU jam. I found that the default BRK vector is $0000, and that location JMPs to $D130 which is routine that prints guess what, "?Illegal Quantity Error", then "Ready."

It could be that my $E000-$E7FF ROM is bad after warm up. We know that $FFFE/$FFFF IRQ vector is $E66B, but if data went bad at $E66B why does the CPU jam seem to occur prior to loading the instruction at that location? There's also the matter of some instruction branching to a $00 in the middle of a real instruction at
$F75D. Are two ROMS bad or yet something else?

I think I'm going to add a reset button which takes a slightly different path. For all this testing I've been cold booting (with a video circuit board to NTSC to my own LCD screen to preserve the PET's CRT)

Also it seems like I really need to do some ROM value checking unplugged from the computer. The easiest but pricey way to do it is to buy a reader off Ebay and a converter from D'Asaro totalling another $60-70. Otherwise a breadboard, wires, and some patience might be enough to verify badness of the ROM. Not sure what I'm going to do there.

Also I have a 40 pin socket so I could make a NOP generator. Not sure if that's likely to help with my current issues though.

Jim
 
Also it seems like I really need to do some ROM value checking unplugged from the computer. The easiest but pricey way to do it is to buy a reader off Ebay and a converter from D'Asaro totalling another $60-70.

Jim,
Before you send a lot of money for troubleshooting, perhaps you should think about a RAM/ROM replacement. There are several people selling them. They are especially useful to replace impossible to get 6540 and 6550 parts.

If you have a single ROM adapter, I can send you an image for the H3 ROM in a 2716 if that's the type used in the adapter. Let me know.
-Dave
 
Are two ROMS bad or yet something else?

With the 6540 ROMs and 6550 RAMs that's a good possibility. With so many of those old parts, you have a lot of potential problems. Think about replacing the lot with a RAM/ROM replacement from bit fixer.com or Tynemouth Software (GB). I have used both and they work well.
 
Thanks, Dave. I see the PetVet is $70 assembled and I sent email to Tynemouth asking him if he's got them and how much they cost. That might be a worthwhile investment even if I fix the existing HW because it allows "upgrading" to 32KB and Basic 2,4, etc.

I did already spend $72 on 6 6550 RAM chips that were missing from this machine. Not sure if that was smart but I thought I'd try to keep it as original as possible. I tested all the RAM (swapping it up when necessary) with the basic RAM test program floating around and everything passed. Of course I can't test it after the computer has hung.

Yes the adaptor I bought from Matthew has a 2716 in it. That would be great if you didn't mind programming one with H3 for me before I decide to get the whole replacement board. I'll send you a message with my mailing info, etc.

Jim
 
I've replied via email, but I'll add a comment here in case anyone is reading this later on. The ROM/RAM boards I make are £60 (~$100) including international shipping. I can supply these with pins suitable for the high sockets used on early 2001's. These long thin pins shouldn't damage the socket like the large square ones can.

On my 2001, I have a couple of bad 6540 ROMs, so I've removed all of those and the precious set of working 6550 RAM, and stored them all safely and I am now running with just the ROM/RAM board.

This saves wear on the (almost) irreplaceable parts and reduces power consumption quite a bit. It also means I can run at 8K, 16K or 32K and with BASIC 1, 2 or 4, by just changing the DIP switch and pressing reset. I can have it as original, or fully upgraded (so I can use my pet microSD IEEE-488 disk drive which BASIC 1 doesn't support).

There are some photos of this in use on my 2001 on my blog:
http://blog.tynemouthsoftware.co.uk/2015/08/commodore-pet-2001-8-repair-part-1.html

Thanks,

Dave
 
Last edited:
I did already spend $72 on 6 6550 RAM chips that were missing from this machine.

$72 for several working 6550 RAM chips is a great deal. Or are they adapter boards for 2114's? Either way if you know RAM is the only problem, that is not a bad solution.

As for EPROMs, I know I have a few 2716's.
 
$72 for several working 6550 RAM chips is a great deal. Or are they adapter boards for 2114's? Either way if you know RAM is the only problem, that is not a bad solution.

As for EPROMs, I know I have a few 2716's.

These were honest to goodness 6550 RAM chips with dates of mid to late 1978. I got them off Ebay and there are still some left. I bought 8 and kept 6 working ones out of them and returned the 2 non-working ones for a refund. You can negotiate a little on the price of course. http://www.ebay.com/itm/MOS-MPS6550-Qty-1-dip24-Commodore-PET-Ships-1-90-in-USA-Tomorrow-/291471641336

Jim
 
These were honest to goodness 6550 RAM chips with dates of mid to late 1978.

I had no idea one could still find some of those RAM chips. But like Dave of Tynemouth says, it may pay to keep a working set of Commodore ROMs and RAMs in antistatic foam and run with the RAM/ROM board for normal use. Then in case you ever want to sell the 2001 PET, revert to the original memory devices. It is worth a lot of money if in original condition and working.
 
Hi Dave,
I tried to use the H3 and H4 you sent in my adapter but then on boot I was seeing a bunch of garbage characters all over the top of the screen just underneath the COMMODORE BASIC line and the number of bytes is missing. This initial happened a couple of times after I had bent up the \IRQ pins of the PIA #1, but got much more consistent after swapping ROMS. I put back the PIA#1 pins. The cursor is still there though and after every "return" it prints ?ILLEGAL QUANTITY ERROR. I put back the original ROMs and this behavior is still happening. I was wearing an antistatic wrist guard so I don't think I've broken a chip. It seems that messing around pulling out various ROM chips that I haven't touched since my initial cleaning has exposed some issues. Maybe there is a trace or socket pin or solder joint problem that has been hiding there. I guess a good way to check would be first to check the integrity of the ROM sockets again with the Ohm meter and then to use my scope's two inputs and compare the signals of the address and data lines of the ROMS to find out if one is not getting the same signals or producing different data line signals. It's not fun when things get worse, but maybe this is uncovering something that was already there.
Jim
 
Sorry if I missed this (hard to read on phone) but have you replaced the sockets? Or at least given them a thorough cleaning and inspection?

Some of the sockets C= used are downright lousy.
 
It's not fun when things get worse, but maybe this is uncovering something that was already there.
Jim
That's the way to look at it. Every experiment gives us more data. With power off, check continuity of signals measuring at the IC leg not the socket. Also look for shorts between adjacent pins.
 
Good news everyone! After one more try at replacing H3 with the adapter with 2716 the hang issue after 10 minutes is no longer happening! I left it on for much longer and loaded several programs and it stays running. Not sure where the garbage character problem went but it's gone for now after half a dozen boots. I checked signals on the chip legs and all were consistent at that moment. So the MB seems to be in good shape and that's great!

Now sorry to be a bother but it looks like I'm going to need help with a new problem with the CRT. After hooking it up for the first time in a while and letting it run for a while the screen degenerated to a waving pattern distorting the text and last time I powered up it was nearly collapsed vertically to a section of horizontal lines. I'll upload a video or pics. Unfortunately I have no experience with HV or analog circuitry. The AC voltage departing the transformer to the monitor was varying from 21-26 but usually around 23-24. Looks like a component just died on that board. I'll try working on it but may end up wanting to look for a CRT repair place.

Jim
 
Back
Top