PET 2001-8 progress...

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 executing. 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. Regards, Dave -- dave06a (at) Dave Dunfield dunfield (dot) Firmware development services & tools: www.dunfield.com com Collector of vintage computing equipment: http://www.classiccmp.org/dunfield/index.html