• Please review our updated Terms and Rules here

XXDP 'switch' settings?

shirsch

Veteran Member
Joined
Aug 17, 2008
Messages
852
Location
Burlington, VT
This is probably laughably simple, but I cannot find a single concrete example explaining how one sets the various 'switches' for XXDP tests. The docs generally mention an address and, e.g. SW00, SW01, etc. I gather these are bits that need to be set, but cannot figure out how one does this from the console.
 
What model machine do you have? Normally you set the switches on the front panel. If I'm right the 11/44 has a software programmable switch register. But an 11/73 does not have any switch rigister at all...
 
Hi, Roland. I'm working with a Heath H11 (LSI-11/03 CPU). It does not have a front panel, but I believe I can gain access to memory by HALT-ing to ODT. Is that the approach to use?
 
Depending on what diagnostics you are running, many of the newer ones have a software switch register you can set, if you're running on a machine without a real switch register.
Check the diagnostics handbook. It should contain the information you need.
 
Not sure where people are looking. Check http://www.bitsavers.org/pdf/dec/pdp11/xxdp/PDP11_DiagnosticHandbook_1988.pdf.
Looking at 11/44 diagnostics, it seems for all, you set the switch register by:

^P
D SW xxxxxx
C

And that's it.

For the 11/03 diagnostics, it seems to depends a little on which diagnostic we're talking about on how you set the "switch register" value. Some seem to have handling in software, others require that you halt and deposit information in memory (different addresses for different test programs), and some have no options.

Read the documentation for each test.
 
Not sure where people are looking. Check http://www.bitsavers.org/pdf/dec/pdp11/xxdp/PDP11_DiagnosticHandbook_1988.pdf.
Looking at 11/44 diagnostics, it seems for all, you set the switch register by:

^P
D SW xxxxxx
C

And that's it.

For the 11/03 diagnostics, it seems to depends a little on which diagnostic we're talking about on how you set the "switch register" value. Some seem to have handling in software, others require that you halt and deposit information in memory (different addresses for different test programs), and some have no options.

Read the documentation for each test.

I have read the documentation and understand _what_ the bits do. What I haven't been able to work out is how to condition the bits in the first place. Once again, the 11/03 diagnostics say not a word about the syntax or mechanics for setting / clearing the bits. I'm 100% sure this stuff is bloody obvious to anyone who has been working with PDP-11 family machines for a while. I'm brand new to this universe and just trying to feel my way through.
 
I have read the documentation and understand _what_ the bits do. What I haven't been able to work out is how to condition the bits in the first place. Once again, the 11/03 diagnostics say not a word about the syntax or mechanics for setting / clearing the bits. I'm 100% sure this stuff is bloody obvious to anyone who has been working with PDP-11 family machines for a while. I'm brand new to this universe and just trying to feel my way through.

Diagnostics will usually use the hardware switch register at 177570 for the program options. When this is not available on certain hardware (like the 11/03, 11/24, etc) the software switch register will be used. Or if the hardware switch register is set to all 1s (ie, all switches up/on) it will defer to the software switch register, normally at location 176 octal.

From a typical diagnostic listing:

Capture.PNG - Click image for larger version  Name:	Capture.PNG Views:	0 Size:	255.3 KB ID:	1208497
 
I have read the documentation and understand _what_ the bits do. What I haven't been able to work out is how to condition the bits in the first place. Once again, the 11/03 diagnostics say not a word about the syntax or mechanics for setting / clearing the bits. I'm 100% sure this stuff is bloody obvious to anyone who has been working with PDP-11 family machines for a while. I'm brand new to this universe and just trying to feel my way through.

And my point was that the diagnostics handbook also tries to tell how to set the software switch register. As in on a PDP-11/44 you type ^P (control-P), then D SW xxxxxx (where xxxxxx is just the octal value you want in the switch register), and then C to continue program execution. When you hit ^P, the processor halts, and you get a >>> prompt, where you give the commands.
For something like the 11/03, which don't have this, the diagnostics handbook does mention ^G in the diagnostics themselves, where that is available, to set the value. For some, you instead need to halt the processor and just deposit the value at a specific address in memory. How you write words into memory from the serial console of a halted processor is described in the processor handbook.
The diagnostics handbook then tells just what specific address you should be writing the value to.

Yes, I am fairly sure that it's easier for someone who are used to these machines, but really. I wouldn't expect it to be that hard to understand the concept of putting a word into a specific memory address as such. And I would have expected that anyone would figure that the processor handbook would have the information on how you write words into memory of a machine.

Not trying to offend you or anything. Trying to help...
 
...
For something like the 11/03, which don't have this, the diagnostics handbook does mention ^G in the diagnostics themselves, where that is available, to set the value. For some, you instead need to halt the processor and just deposit the value at a specific address in memory. How you write words into memory from the serial console of a halted processor is described in the processor handbook.
The diagnostics handbook then tells just what specific address you should be writing the value to.
...

All the references to ^P and ^G were what threw me. Neither of those key inputs has any impact on my system. I just needed confirmation that "setting switches" was indeed a memory location deposit (per my note above that mentioned ODT) as opposed to an interactive software operation (e.g. typing 'SET blah, blah at the command line). Again, this probably seems silly to anyone who has a background in these systems but it certainly wasn't obvious to me coming in cold. In a couple of cases I have been successful in changing behavior of the test by patching under ODT followed by @200G to restart the test. In other cases setting bits had no apparent effect, but I'm not going to worry about that at the moment.

The underlying problem: I'm finding that after the unit has been on for a while, a number of the processor and memory tests HALT spontaneously into ODT with a printout of:

000010
@

Since I see this exact printout on a number of different tests, I'm not convinced it's a test fail, per se, but perhaps an indication of something more low level that's broken. Once the system starts HALTing out of the tests, I reboot into RT-11 and run 'IND VERIFY' to compile and link IVP.MAC. This works when run immediately after cold start, but will now abort with:

?MON-F-Trap to Trap 10 010500

(Always the same numbers). What's the best approach to getting at the underlying problem?
 
<000010><@> indicates a memory error of some sort.

<?MON-F-Trap to Trap 10 010500> indicates an instruction error just before location 10500. However,
IVP.SAV doesn't access any location past 1000, so that would seem to be a side-effect of some earlier
problem, perhaps a stray interrupt.

If this issue only occurs only after the system has been running for awhile then it could be a heat related
issue with memory or the CPU. I have seen this kind of flakey problem fixed by cleaning the contacts of
the cards that slot into the backplane. I'm not a hardware person (at all), but someone else here probably
knows how to do that (it needs to be done carefully with an eraser or isopropyl).
 
All the references to ^P and ^G were what threw me. Neither of those key inputs has any impact on my system. I just needed confirmation that "setting switches" was indeed a memory location deposit (per my note above that mentioned ODT) as opposed to an interactive software operation (e.g. typing 'SET blah, blah at the command line). Again, this probably seems silly to anyone who has a background in these systems but it certainly wasn't obvious to me coming in cold. In a couple of cases I have been successful in changing behavior of the test by patching under ODT followed by @200G to restart the test. In other cases setting bits had no apparent effect, but I'm not going to worry about that at the moment.

The underlying problem: I'm finding that after the unit has been on for a while, a number of the processor and memory tests HALT spontaneously into ODT with a printout of:

000010
@

Since I see this exact printout on a number of different tests, I'm not convinced it's a test fail, per se, but perhaps an indication of something more low level that's broken. Once the system starts HALTing out of the tests, I reboot into RT-11 and run 'IND VERIFY' to compile and link IVP.MAC. This works when run immediately after cold start, but will now abort with:

?MON-F-Trap to Trap 10 010500

(Always the same numbers). What's the best approach to getting at the underlying problem?

Ok. So the ^P and ^G notation was probably more commonly understood 30 years ago. It's certainly nothing DEC or PDP-11 specific, but might have become less common these days.

Your halt is at address 10.
Also, the trapping in RT-11 is to address 10. Which is interesting. This is the trap location for illegal and reserved instructions. If this happens when the machine has been on for a while, it sounds like you have some kind of hardware problem that might be temperature related, or something similar.

A card extender, and some cooling spray or heat to different locations of the board while trying to run that testing again and again, in order to identify physically which component might be the problem.
 
Ok. So the ^P and ^G notation was probably more commonly understood 30 years ago. It's certainly nothing DEC or PDP-11 specific, but might have become less common these days.

Your halt is at address 10.
Also, the trapping in RT-11 is to address 10. Which is interesting. This is the trap location for illegal and reserved instructions. If this happens when the machine has been on for a while, it sounds like you have some kind of hardware problem that might be temperature related, or something similar.

A card extender, and some cooling spray or heat to different locations of the board while trying to run that testing again and again, in order to identify physically which component might be the problem.

I understood the notation, but the test environment fails to respond to either ^G or ^P. ODT works fine so not a major issue.

It's valuable to understand that there's a common element behind both runtime and test failures. My extender board arrived today so I can certainly dig deeper into the CPU.
 
Is this what you are looking for?
I had to surge for it again, With my PDP11/23 also lot of questions about those Switches.
This is what I found back then. Give me an email and you get the documentation I have.
PDP11_DiagnosticHandbook_1988_1123-Switch.jpg
PDP11_DiagnosticHandbook_1988_1123-Switch.jpg
 
Is this what you are looking for?
I had to surge for it again, With my PDP11/23 also lot of questions about those Switches.

The thing is - there is nothing universal about this. Each diagnostic can do things differently, and often do. So just because that FPP diagnostic for an 11/23 prompts for the switch register value to use, don't mean a thing when you are running any other diagnostic.
 
Ok. So the ^P and ^G notation was probably more commonly understood 30 years ago. It's certainly nothing DEC or PDP-11 specific, but might have become less common these days.

Your halt is at address 10.
Also, the trapping in RT-11 is to address 10. Which is interesting. This is the trap location for illegal and reserved instructions. If this happens when the machine has been on for a while, it sounds like you have some kind of hardware problem that might be temperature related, or something similar.

A card extender, and some cooling spray or heat to different locations of the board while trying to run that testing again and again, in order to identify physically which component might be the problem.
Hi Johnny,

I haven't used micro-ODT for about 40 years. but I think the first trap reported:

000010
@

is a trap to 4, intercepted by a trap catcher for address errors, such as:

.asect
.=4
000004 000006 .+2
000006 000000 halt
000010 ...


where the PC ODT displays is the PC at the completion of an instruction, i.e. after the HALT.

So, given we have both address and instruction errors, what were probably seeing is the end result
of some system failure rather than the point of failure itself. I don't think the switch settings are going
to make a great deal of difference in this scenario.

But what I don't understand is why the RT-11 bug always occurs at the same place. It's not random.
(note: I was wrong in my initial post because I thought the bug occurred while running IVP, instead it
seems to be happening during the assembly/link process.) That's debuggable if all the heat-related
fixes fail.
 
Hi Johnny,

I haven't used micro-ODT for about 40 years. but I think the first trap reported:

000010
@

is a trap to 4, intercepted by a trap catcher for address errors, such as:

.asect
.=4
000004 000006 .+2
000006 000000 halt
000010 ...


where the PC ODT displays is the PC at the completion of an instruction, i.e. after the HALT.

So, given we have both address and instruction errors, what were probably seeing is the end result
of some system failure rather than the point of failure itself. I don't think the switch settings are going
to make a great deal of difference in this scenario.

But what I don't understand is why the RT-11 bug always occurs at the same place. It's not random.
(note: I was wrong in my initial post because I thought the bug occurred while running IVP, instead it
seems to be happening during the assembly/link process.) That's debuggable if all the heat-related
fixes fail.

Suspect you might be right. I was a bit unsure here, but was hoping that maybe we had an odd address at address 10, and that made it halt reporting that same address, as it seemed an interesting coincident otherwise that RT-11 was getting traps through 10.

Anyway - something running for a while, but then having the same program running causing failures sounds like iffy hardware. But of course, nothing is certain.
 
Back
Top