Got out my ancient oscilloscope and did a bit of
probing and got a
little more info:
On power up, the CPU reset line is held low for ~1 sec, then goes high.
At this point if I look at the address/data lines, I can see a very
brief burst of activity and then nothing at all (it's during this
activity that a few characters on screen change). After this activity,
all address lines are high. IRQ & NMI lines are high. CPU is being
clocked throughout all of this, clock rate seems to be correct.
Assuming that it is clocked and has been reset correctly, there are
generally only two reasons that a CPU stops running (fetching opcodes):
1) It is being held in a hardware wait state.
Check the state of the RDY line on the 6502 and if it
is asserted, backtrace through the circuit to find out why.
2) It executes an instruction which causes it to stop
Usually a HALT instructionor of some sort or other, there are sometimes
undocumented opcodes which cause this behaviour as well - A bit of
net searching should turn up details on the undocumented opcodes.
There are generally two reasons why a processor would execute an opcode
to shut itself off:
1) On purpose
Usually while waiting for an interrupt - given that you PET hasn't
even cleared it's screen, I doubt this is the case.
2) By executing "random" code
Can be caused by:
- Bad ROM - actual code gets corrupted
- Bad RAM - stack failure results in "return" to random address
- Bad bus buffers - hardware failure resulting in corruption in the
address or data buses.
- Bad decode logic - no device or multiple memory devices being
selected when only one should be.
I've seen a least two 2001's with bad ROM chips. And a number of PETs
with bad RAM - I'd suspect one of these two.
If you have a storage scope, you should be able to trigger on the
SYNC signal at the CPU and catch the last few opcode fetches - walking
the data and address bus signals and writing them down will reveal
the last opcode executed and the address from which it was executed.
Look at the opcode that was executed to see what exactly caused the
CPU to stop.
Try this a couple of times and see if the CPU is always stopping in
the same place. Scope the select lines and note *which* ROM was
selected for the last opcode fetch, or in the case of a "wild" access,
which ROM was selected last before it stopped.
If the address where that opcode was fetched in within the ROM, get
the PET rom binaries and see if it's "supposed" to be there - a bit
of disassembly around that address should tell you if the code is
real code, or some random bit of data that the processor wandered
off into. If you can read the PET ROMs (I made an adapter to stuff
them into my homebuild EPROM programmer) you can compare against the
binaries to check the entire ROM content - The PET roms are not standard
pinouts - but you can make an adapter to put a normal ROM in the
socket - IIRC I needed a TTL chip to provide an extra select - I've
got photos on my site of a PET that I had to repair this way.
If the address is NOT within the ROM, trigger on the ROM select and
see what the last opcode executed from ROM was - if it was RTS or
RTI I would strongly suspect a RAM problem. It might also be a jump
indirect (same suspicion). As above, look at the code contained at
this address and see it if "makes sense" as a valid place to be
With a decent scope you can get several fetches on the screen, and
therefore determine the opcode/address for the last few instructions
executed - If you can't get any of that to make sense, try single-
shot trigger and capture the first few instructons executed - see if
they make sense and match the ROM.
With a bit of poking around you should be able to determine what the
processor is doing at the time it went insane - hopefully at some point
the "ah-ha" light will go on.
dave06a (at) Dave Dunfield
dunfield (dot) Firmware development services & tools: www.dunfield.com
com Collector of vintage computing equipment: