RSX11M+
Veteran Member
- Joined
- Feb 14, 2011
- Messages
- 1,075
This ended up being kind of a long (rambling?) post, so if it's not helpful - just skip it and maybe save it for later.
CPU troubleshooting is almost an exercise in clairvoyance. You're sitting there trying to psyche-out what's going on inside the machine. (I get off on it because it's a kind of ZEN exercise) Often it requires a lot of specific knowledge about how it's constructed.
But there are generalizations that can often help one narrow down what direction to investigate.
The simplest program is a HALT. Second is probably an unconditional BRANCH to self and the NOP. All are single word instructions and are unambiguous on any PDP-11. (some PC self referencing instructions are notorious for executing differently on different PDP-11 family members - so I avoid these unless I know specifically what to expect)
In choosing an instruction you might think about what's involved to execute it:
Whichever you choose, try to look for evidence that it is indeed happening as you expect. If using a scope or logic analyzer - ask yourself: how will I trigger it to visualize what's happening?
In my troubleshooting I attempt to assure memory integrity first. It's easy to do and eliminates a huge number of unknowns. Follow this with unconditional branches of various types... which takes us immediately to Loops.
Once the basics are established, one of my favorite "first light" programs is a memory scan. A loop that does nothing but read all of memory sequentially. On a PDP-11 this is not as simple as some other machines. For example: PDP-11 systems often go through undesirable gymnastics when a memory area is read that doesn't exist in hardware. This makes it necessary to design the loop to focus on memory locations that do exist. So, some conditional instructions need to be working. Another alternative would be for the test program to handle the "gymnastics" as I put it - by ignoring the error and continuing. This in turn requires interrupts and stack to be functional.
This isn't intended as a laundry list... only as an example of how to think it through. Start simple and target a particular behavior you can prove.
Being unfamiliar with the instruction set is a handicap, especially if you're trying to learn it and diagnose a machine at the same time TOGETHER. Having a PC simulated PDP-11 can be helpful - but it's limited to instruction help and isn't testable with the same tools as your real system.
Your mind is dealing with a lot of unknowns at the same time. My advice is to break it down to one element at a time. Pick an instruction and learn it completely. Run it, test it, watch it execute. Play with it until you're sure you understand it and have proved it to yourself.
It's clear you have tremendous tenacity and perseverance. This work will take time - a lot of it. That's ok - Let it. You'll end up with your head inside these machines in a way that is most uncommon. Fun - is contagious.
~~
After this phase, you'll eventually want to avail yourself of DEC written Diagnostics. (unless you plan to learn and test every instruction manually - an exercise [exorcise?] I wouldn't put past you!) Have you thought about how that might be done? Will they be sent via a serial console to your system or do you have some mass storage on it? These are more questions for later, but answering them now will help us (me) understand what possibilities might exist for you.
CPU troubleshooting is almost an exercise in clairvoyance. You're sitting there trying to psyche-out what's going on inside the machine. (I get off on it because it's a kind of ZEN exercise) Often it requires a lot of specific knowledge about how it's constructed.
But there are generalizations that can often help one narrow down what direction to investigate.
The simplest program is a HALT. Second is probably an unconditional BRANCH to self and the NOP. All are single word instructions and are unambiguous on any PDP-11. (some PC self referencing instructions are notorious for executing differently on different PDP-11 family members - so I avoid these unless I know specifically what to expect)
In choosing an instruction you might think about what's involved to execute it:
- Is it "Conditional" or "Absoute" (requiring no evaluation)
- Is it "Short" (one word) or "Long" (Multiple word)
- Does it reference an internal CPU register? (beyond the PC)
- Does it reference memory? (other than the instruction's memory)
- Does it require stack or use the stack pointer?
- Does execution involve the ALU? (Add, Subtract, Multiply, Divide)
Whichever you choose, try to look for evidence that it is indeed happening as you expect. If using a scope or logic analyzer - ask yourself: how will I trigger it to visualize what's happening?
In my troubleshooting I attempt to assure memory integrity first. It's easy to do and eliminates a huge number of unknowns. Follow this with unconditional branches of various types... which takes us immediately to Loops.
- Can I watch the CPU execute a loop with my equipment?
- Do the console lights bear it out correctly?
- Can I pause and restart it via the console?
Once the basics are established, one of my favorite "first light" programs is a memory scan. A loop that does nothing but read all of memory sequentially. On a PDP-11 this is not as simple as some other machines. For example: PDP-11 systems often go through undesirable gymnastics when a memory area is read that doesn't exist in hardware. This makes it necessary to design the loop to focus on memory locations that do exist. So, some conditional instructions need to be working. Another alternative would be for the test program to handle the "gymnastics" as I put it - by ignoring the error and continuing. This in turn requires interrupts and stack to be functional.
This isn't intended as a laundry list... only as an example of how to think it through. Start simple and target a particular behavior you can prove.
Being unfamiliar with the instruction set is a handicap, especially if you're trying to learn it and diagnose a machine at the same time TOGETHER. Having a PC simulated PDP-11 can be helpful - but it's limited to instruction help and isn't testable with the same tools as your real system.
Your mind is dealing with a lot of unknowns at the same time. My advice is to break it down to one element at a time. Pick an instruction and learn it completely. Run it, test it, watch it execute. Play with it until you're sure you understand it and have proved it to yourself.
It's clear you have tremendous tenacity and perseverance. This work will take time - a lot of it. That's ok - Let it. You'll end up with your head inside these machines in a way that is most uncommon. Fun - is contagious.
~~
After this phase, you'll eventually want to avail yourself of DEC written Diagnostics. (unless you plan to learn and test every instruction manually - an exercise [exorcise?] I wouldn't put past you!) Have you thought about how that might be done? Will they be sent via a serial console to your system or do you have some mass storage on it? These are more questions for later, but answering them now will help us (me) understand what possibilities might exist for you.
Last edited:
