-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathparity-handling.html
415 lines (371 loc) · 24.1 KB
/
parity-handling.html
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8">
<title>fritzm.github.io - PDP-11/45: Parity error handling</title>
<meta name="description" content="">
<meta name="author" content="Fritz Mueller">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<!-- Le HTML5 shim, for IE6-8 support of HTML elements -->
<!--[if lt IE 9]>
<script src="https://fritzm.github.io/theme/html5.js"></script>
<![endif]-->
<!-- Le styles -->
<link href="https://fritzm.github.io/theme/bootstrap.min.css" rel="stylesheet">
<link href="https://fritzm.github.io/theme/bootstrap.min.responsive.css" rel="stylesheet">
<link href="https://fritzm.github.io/theme/local.css" rel="stylesheet">
<link href="https://fritzm.github.io/theme/pygments.css" rel="stylesheet">
<!-- Photoswipe -->
<link rel="stylesheet" href="https://fritzm.github.io/theme/photoswipe.css">
<link rel="stylesheet" href="https://fritzm.github.io/theme/default-skin/default-skin.css">
<script src="https://fritzm.github.io/theme/photoswipe.min.js"></script>
<script src="https://fritzm.github.io/theme/photoswipe-ui-default.min.js"></script>
<script src="https://fritzm.github.io/galleries.js"></script>
<script type="text/javascript">
var pswipe = function(gname, index) {
var pswpElement = document.querySelectorAll('.pswp')[0];
var items = galleries[gname];
var options = { index: index };
var gallery = new PhotoSwipe(pswpElement, PhotoSwipeUI_Default, items, options);
gallery.init();
};
</script>
<!-- So Firefox can bookmark->"abo this site" -->
<link href="https://fritzm.github.io/feeds/all.rss.xml" rel="alternate" title="fritzm.github.io" type="application/rss+xml">
</head>
<body>
<div class="navbar">
<div class="navbar-inner">
<div class="container">
<a class="btn btn-navbar" data-toggle="collapse" data-target=".nav-collapse">
<span class="icon-bar"></span>
<span class="icon-bar"></span>
<span class="icon-bar"></span>
</a>
<a class="brand" href="https://fritzm.github.io">fritzm.github.io</a>
<div class="nav-collapse">
<ul class="nav">
</ul>
</div>
</div>
</div>
</div>
<div class="container">
<div class="content">
<div class="row">
<div class="span9">
<div class='article'>
<div class="content-title">
<h1>PDP-11/45: Parity error handling</h1>
Mon 25 May 2020
by <a class="url fn" href="https://fritzm.github.io/author/fritz-mueller.html">Fritz Mueller</a>
</div>
<div><p><em>[A catch-up article, documenting events of Jan/Feb 2019.]</em></p>
<p>At the end of the previous article, a bunch of repairs had been made to my MS11-L memory board. The
associated MAINDEC diagnostic ZQMC was able to run cleanly <em>but only with parity tests disabled</em>. When parity
tests were enabled, the parity fault LED on the MS11 would light (expected) and the machine would halt with
ADRS ERR lit (unexpected...)</p>
<p>So the first step is to read and research how memory parity handling is implemented on the KB11-A CPU.
Immediately here we run into some trouble:</p>
<ul>
<li>
<p>The 1973 edition of the 11/45 Processor Handbook has a section 2.5.6, "Memory Parity", which states: "Parity
errors cause the Central Processor to either trap through location 4 or to halt." There is also an Appendix
E, "Memory Parity", which details CSRs for parity memory:</p>
<p><img style="display:block; margin-left:auto; margin-right:auto" src="/images/pdp11/memory-csr-73.png" title="1973 Memory CSR"/></p>
<p>It is stated there that there are 16 of these, at addresses 772110-772146, each corrsponding to an 8K word
block of address space.</p>
<p>By the 1976 version of the processor handbook, however, all of this information had been expunged. The new
Appendix A, "UNIBUS Addresses", lists range 772110-772136 simply as "UNIBUS memory parity". Here, trap 4
is listed as "CPU errors", and trap 114 is listed as "Memory system errors". All subsequent revisions of
the handbook state unambiguously that parity errors generate a trap 114.</p>
</li>
<li>
<p>What do the KB11-A processor maintenance manuals have to offer? Paragraph 7.7.7 of the 1972 KB11-A
maintenance manual states:</p>
<blockquote>
<p>A Parity error on the Unibus A is indicated by BUSA PA L high and BUSA PB L low. The parity error
causes UNI PERF (Unibus parity error flag) to be set when MSYN is cleared. UNI PERF (1) L asserts UBCB
PARITY ERR SET L during the pause cycle, which sets the console (CONF) flag and halts the CPU.</p>
<p>The semiconductor memory control EHA and EHB (enable halt) flip-flops may be set under program control
to assert SMCB PE HALT if a parity error is detected. This input also asserts UBCB PARITY ERR SET L,
which sets the console flag and halts the CPU. Thus, if either a Unibus A parity error or SMCB PE HALT
L is asserted, the processor will be vectored to trap when the CONT switch is pressed.</p>
</blockquote>
<p>Note that this text addresses how the CPU handles detected parity errors in both Unibus (first paragraph)
and fastbus (second paragraph) memory systems. Unibus parity errors are stated to set the CONF flag and
halt the CPU, just as I am seeing on my system... Fastbus parity handling (halt first vs. direct trap)
can further be mediated by EHA and EHB, called out here to drawing SMCB in the MS11-B/C fastbus
semiconductor memory print set.</p>
<p>But here, too, by the time we get to the later revision 1976 KB11-A,D maintenance manual, this information
is revised. The updated description makes no further mention of CONF, halting, or halt control, and seems
to imply that all reported parity conditions trap directly through 114.</p>
</li>
<li>
<p>How about contemporaneous memory systems? The MS11-B/C solid state memory systems released with the 11/45
(note: not what I'm running; I have the much later MS11-L) consisted of either MOS or bipolar memory
matrices with an associated controller card (the M8110). These supported both Unibus and fastbus interfaces.
Here, in the 1972 schematics, we see the implementation of the EHA/EHB halt control bits, mentioned above,
in the upper left of sheet SMCB:</p>
<p><img style="display:block; margin-left:auto; margin-right:auto" src="/images/pdp11/ms11-eha-ehb.png" title="MS11 halt control bits"/><br></p>
<p>We can see the bit assignments here match the CSR layout from the 1973 processor handbook, and the
associated MS11 maintenance manual from 1973 also describes them in its table 3-12:</p>
<p><img style="display:block; margin-left:auto; margin-right:auto" src="/images/pdp11/ms11-table-3-12.png" title="MS11 CSR w/ halt control bits"/></p>
<p>And once again, by the 1974 revision of the same maintenance manual, no surprise: descriptions of the halt
control bits have been expunged from table 3-12. Okay, we're starting to get a consistent picture here...</p>
<p>I don't know much about the core memory systems that were configured with the early 11/45s? It would be
interesting to know if anything other than the MS11-B/C ever supported this older CSR layout.</p>
</li>
<li>
<p>Let's have a look at the KB11-A engineering drawings themselves. The set I've been using during my
restoration dates from 1974. The first, most obvious, place to look is trap vector generation; this is
accomplished on the lower left of drawing DAPE:</p>
<p><img style="display:block; margin-left:auto; margin-right:auto" src="/images/pdp11/trap-vector-decode.png" title="KB11-A trap vector generation, circa 1974"/></p>
<p>This small combinational net feeds trap vector bits to the K1MX constant multiplexer. One non-obvious
wrinkle noted elsewhere on the drawing: vectors generated for reserved instruction (004), EMT (014), and
TRAP (016) are further left-shifted, downstream, by microcode (state RSD.10, drawing FLOWS 12) to result
in 010, 030, and 034 respectively. That's not strictly relevant to the discussion at hand, but might be
helpful if pondering the logic implemented in the diagram above.</p>
<p>This drawing is definitely from the "post 114" era. On a parity error, we'll have ~IOT and ~PIRQ and
~SEGT, together driving TV02 high; that's our traditional vector 004. But here we also see UBCB PE TRAP
(1) L, active low, entering from the left. When driven low, we'll get TV03 and TV06 high as well, all
together generating vector 114.</p>
<p>Here we can see some clues, too, of how the change to 114 might have been bodged in: as drawn, TV01, TV02,
TV03, TV04 and TV05*07 proceed nicely in order from bottom to top. But TV06, needed by the change as the
most-significant "1" in "114", looks like it was just wedged in out of order on the drawing...
Presumably, it makes use of a previously unused section of hex inverter E11. The change to activate TV03
here as well would have been a cut/jump at the inputs of E7.</p>
<p>And sure enough, here we see differences with my actual hardware! Here's part of the layout of module
DAP from the '74 engineering drawings, and a snap the same corner of my DAP spare which is same as the
one I'm currently running in the machine:</p>
<p><br/><div style="margin-left:auto; margin-right:auto; width:75%">
<img src='/images/pdp11/dap-layout_thumbnail_tall.png' title='Corner of DAP layout from 1974 drawings' onclick='pswipe("pdp11",80);'/>
<img src='/images/pdp11/dap-corner_thumbnail_tall.png' title='Corner of one of my DAP boards. Note missing R17.' onclick='pswipe("pdp11",81);'/>
</div><br/></p>
<p>Note particulary that R17, a pullup for UBCB PE TRAP (1) L, is missing on my board. A little further work
with the beeper shows that on my boards E7 pin 1 is connected directly to E7 pin 13, and is not connected
to edge connector AP1. E11 pin 3 appears to be NC. Furthermore, examination of the backplane shows that
there is no wire wrapped in place at DAP AP1 to deliver signal UBCB PE TRAP (1) from the UBC board. So, I
think I can conclude we're not looking at a bug or component failure here; <strong>my 11/45 simply pre-dates the
change from vector 4 to vector 114.</strong></p>
</li>
<li>
<p>Okay for the vector, but what about the halt behavior? Here, the text quoted earlier from the 1972 KB11-A
maintenance manual has our clue where to look. The parity derived signal eventually resulting in the halt
on either Unibus or fastbus parity error is UBCB PARITY ERR SET L (note "SET" in the signal name here, don't
confuse with UBCB PARITY ERR L...) The 1974 drawings imply that a fastbus parity err, but <em>not</em> a Unibus
parity error, will halt the machine, in conflict with this text. But looking here, we see another bodge
clue: the hookup at E68 pins 4 and 5 as drawn looks a little suspicious...</p>
<p><img style="display:block; margin-left:auto; margin-right:auto" src="/images/pdp11/ubcb-parity-halt.jpeg" title="UBC parity halt logic"/></p>
<p>And indeed, on my hardware, E68 pins 4 and 5 are <em>not</em> connected together; rather, E68 pin 5 is connected
to E79 (Unibus parity error flag) pin 5. <strong>So, Unibus parity errors will also halt this version of the
11/45 hardware, by design.</strong></p>
<p>Some other differences related to parity are also apparent looking at my version of the UBC board. E57,
seen above generating UBC PE ABORT L, is not populated. This seems related to some further refinement of
abort sequencing, but the cirumstances surrounding the need for this aren't clear to me at this point.
Also, jumper W1 and associated logic to entirely disable Unibus parity error detection are not present:</p>
<p><br/><div style="margin-left:auto; margin-right:auto; width:75%;">
<img src='/images/pdp11/ubc-layout_thumbnail_tall.png' title='Corner of UBC layout from 1974 drawings' onclick='pswipe("pdp11",82);'/>
<img src='/images/pdp11/ubc-corner_thumbnail_tall.jpeg' title='Corner of one of my UBC boards. Note missing W1, R161, and unpopulated E57.' onclick='pswipe("pdp11",83);'/>
</div><br/></p>
</li>
</ul>
<p>So, what does all this mean? Well, for one thing, there apparently isn't anything actually in need of repair
here -- as far as I can tell, this version of the hardware is functioning per design, such as it is.</p>
<p>And as it turns out, with a now properly repaired MS11-L, actual parity errors are few and far between (I've
yet to see any that weren't intentionally created by diagnostics.) According to Noel, stock Unix V6 doesn't
do anything whatsoever with parity. RSTS/E V06C boot code seems to be properly probing and identifying the CSR
on my MS11-L. And good old RT11 has seemed happy enough in the past. So I just may not <em>need</em> a totally
up-to-date parity implementation on my machine.</p>
<p>There is still the issue of more broadly tracking down and implementing outstanding ECOs for this machine. I
have so far had limited success in locating these (more on this next time!) I'm certainly equipped here to
implement field cuts and jumps, but it might get tricky to track down newer versions of boards for any ECOs
that involved total swaps to updated etches. In any case, in the absence of complete information on the ECOs
I'm hesitant to cherry pick changes such as those identified here unless I am really blocked without
them; better by far not to leave the machine in an undocumented "in-between" state.</p>
<hr>
<p>Footnotes: a lot of the discovery documented here took place in the context of the enthusiast community on
the cctalk mailing list, and also in private communications. Noel Chiappa and Paul Koning were both
particularly generous with their time (thanks, guys!) Here are some interesting related bits that didn't
fit directly in the narrative above, for completeness and for future reference:</p>
<ul>
<li>
<p>On RSTS parity CSR sniffing, from Paul:</p>
<blockquote>
<p>From: Paul Koning<br>
To: cctalk<br>
Subject: Re: PDP-11/45 RSTS/E boot problem </p>
<blockquote>
<p>Fritz Mueller wrote:</p>
<p>There is a lot of inconsistent and incomplete information in the documentation about memory CSRs. They
appear to come in different flavors depending on memory hardware; some of the earlier ones support
setting a bit to determine whether parity errors will halt or trap the CPU, while some of the later
ones (like my MS11-L) simply have "enable" and don't distinguish between halt and trap. I'm curious
how OS init code sniffs out what memory CSRs there are, determines their specific flavors and, in a
heterogeneous system, determines how much address space is under the auspice of each CSR? Maybe Paul
and Noel can comment here wrt. RSTS and Unix respectively?</p>
</blockquote>
<p>I quickly skimmed some RSTS INIT code (for V10.1). Two things observed:</p>
<p>1. At boot, INIT determines the memory layout. It does this by writing 0 then -2 into each location to
see if it works. If it gets an NXM trap (trap to 4) or a parity trap (trap to 114) it calls that 1kW
block of memory non-existent. For the case of a parity error, it tells you that it saw a parity error
and is disabling that block for that reason.</p>
<p>2. In the DEFAULT option (curiously enough) there is a routine that looks for up to 16 parity CSRs
starting at 172100. This happens on entry to the memory layout option. You can display what it finds
by using the PARITY command in response to the "Table suboption" prompt.</p>
<p>It checks if the bits 007750 are active in the parity CSR, if so it takes that to be an address/ECC
parity CSR. It figures out the CSR to memory association by going through memory in 1 kW increments,
writing 3, 5 to the first 2 words, then setting "write wrong parity" in each CSR (007044), then doing
BIC #3,.. BIC #5,... to those two test words, then reading them both back. This should set bad parity,
and it scans all the CSRs to see which one reports an error (top bit in the CSR). If no CSR has that
set, it concludes the particular block is no-parity memory.</p>
<p>I probably got some of the details wrong, the above is from a fast skim of the code, but hopefully it
will get you started.</p>
</blockquote>
<p>My machine currently has one MS11-L, which has the newer CSR layout referred to by Paul above (different
than the much older MS11-B/C CSR layout depicted at the top of this article; see MS11-L docs for further
details). RSTS init defaults->memory->parity on my system reports (correctly):</p>
<div class="highlight"><pre><span></span> 0K: 00000000 - 00757777 ( 124K) : 00
</pre></div>
<p>Presumeably, RSTS carries out this identification activity with the CSR report enable bits off, and the
CSR error bits still function correctly in these circumstances; otherwise, per above, my machine would
summarily halt during this process!</p>
</li>
<li>
<p>Noel, in some of his research, found Deeper magic from before the dawn of time re. evolution of the Unibus
parity implementation <em>before</em> the era of the start of this article, bridging back to the KA11 (11/20) CPU.
Quite interesting!</p>
<blockquote>
<p>From: Noel Chiappa<br>
Subject: Change in UNIBUS parity operation (Was: PDP-11/45 RSTS/E boot problem)<br>
To: cctalk </p>
<blockquote>
<p>Even better, it claims to be able to control whether the memory uses odd or even parity! (How, for
UNIBUS memory, I don't know - there's no way to do this over the UNIBUS.</p>
</blockquote>
<p>So this really confused me, as the UNIBUS spec says parity is wholly within the slave device, and only
an <em>error</em> signal is transferred over the bus. E.g. from the 'pdp11 peripherals handbook', 1975 edition
(pg. 5-8): "PA and PB are generated by a slave ... [it] negates PA and asserts PB to indicate a parity
error ... both negated indicates no parity error. [other combinations] are conditions reserved for
future use."</p>
<p>The answer is that originally the UNIBUS parity operation was <em>different</em>, and that sometime around the
introduction of the PDP-11/45, they <em>changed</em> it, which is apparently why Appendix E, about parity in
the /45, says what it does!</p>
<p>I found the first clue in the MM11-F Core Memory Manual (DEC-11-HMFA-D - which is not online, in fact no
MM11-F stuff is online, I'll have to scan it all and send it to Al); I was looking in that to see if the
parity version had a CSR or not (to reply to Paul Koning), and on the subject of parity it said this:
"The data bits on the bus are called BUS DPB0 and BUS DPB1." And there is nothing else on how the two
parity bits are <em>used</em> - the clear implication is that the memory just <em>stores</em> them, and hands them to
someone else (the master) over the bus, for actual use.</p>
<p>Looking further, I found proof in the "unibus interface manual" - and moreover, the details differ
between the first (DEC-11-HIAA-D) and second (DEC-11-HIAB-D) editions (both of which differ from the
above)!</p>
<p>In the first, Table 2-1 has these entries for PA and PB: "Parity Available - PA ... Indicates paritied
data" and "Parity Bit - PB ... Transmits parity bit"; at the bottom of page 2-4 we find "PA indicates
that the data being transferred is to use parity, and PB transmits the parity bit. Neither line is used
by the KA11 processor."</p>
<p>(Which explains why, when, after reading about parity in the MM11-F manual, I went looking for parity
stuff in the KA11 which would use it, I couldn't find it!)</p>
<p>In the second, Table 2-1 has these entries for PA and PB: "Parity Bit Low - PA ... Transmits parity bit,
low byte" and "Parity Bit High - PB ... Transmits parity bit, high byte"; at the top of page 2-5 we find
wholly different text from the above, including "These lines are used by the MP11 Parity Option in
conjunction with parity memories such as the MM11-FP."</p>
<p>I looked online for more about the MP11, but could find nothing. I wonder if any were made?</p>
<p>This later version seems to agree with that Appendix E. I tried to find an early -11/45 system manual,
to see if it originally shipped with MM11-F's, but couldn't locate one - does anyone have one? The ones
online (e.g. EK-1145-OP-001) are much later.</p>
<p>It's also interesting to speculate about reasons <em>why</em> these changes were made; I can think of several!
:-)</p>
</blockquote>
</li>
</ul>
<p>All for now!</p></div>
<hr>
</div>
</div>
<div class="span3">
<div class="well" style="padding: 8px 0; background-color: #FBFBFB;">
<ul class="nav nav-list">
<li class="nav-header">
Site
</li>
<li><a href="https://fritzm.github.io/archives.html">Archives</a>
<li><a href="https://fritzm.github.io/tags.html">Tags</a>
<li><a href="https://fritzm.github.io/feeds/all.rss.xml" rel="alternate">RSS feed</a></li>
</ul>
</div>
<div class="well" style="padding: 8px 0; background-color: #FBFBFB;">
<ul class="nav nav-list">
<li class="nav-header">
Categories
</li>
<li><a href="https://fritzm.github.io/category/arcade-games.html">Arcade Games</a></li>
<li><a href="https://fritzm.github.io/category/math.html">Math</a></li>
<li><a href="https://fritzm.github.io/category/micros.html">Micros</a></li>
<li><a href="https://fritzm.github.io/category/pdp-11.html">PDP-11</a></li>
<li><a href="https://fritzm.github.io/category/programming.html">Programming</a></li>
<li><a href="https://fritzm.github.io/category/radios.html">Radios</a></li>
</ul>
</div>
<div class="social">
<div class="well" style="padding: 8px 0; background-color: #FBFBFB;">
<ul class="nav nav-list">
<li class="nav-header">
Social
</li>
<li><a href="http://facebook.com/fritzmueller">facebook</a></li>
<li><a href="http://instagram.com/infrafritz">Instagram</a></li>
<li><a href="http://www.linkedin.com/pub/fritz-mueller/a/679/62/">LinkedIn</a></li>
<li><a href="http://jsfiddle.net/user/fritzm/fiddles/">JSFiddle</a></li>
<li><a href="https://github.com/fritzm">GitHub</a></li>
</ul>
</div>
</div>
</div>
</div> </div>
<footer>
<br />
<p><a href="https://fritzm.github.io">fritzm.github.io</a> © Fritz Mueller 2023</p>
</footer>
</div> <!-- /container -->
<!-- Photoswipe -->
<div class="pswp" tabindex="-1" role="dialog" aria-hidden="true">
<div class="pswp__bg"></div>
<div class="pswp__scroll-wrap">
<div class="pswp__container">
<div class="pswp__item"></div>
<div class="pswp__item"></div>
<div class="pswp__item"></div>
</div>
<div class="pswp__ui pswp__ui--hidden">
<div class="pswp__top-bar">
<div class="pswp__counter"></div>
<button class="pswp__button pswp__button--close" title="Close (Esc)"></button>
<button class="pswp__button pswp__button--share" title="Share"></button>
<button class="pswp__button pswp__button--fs" title="Toggle fullscreen"></button>
<button class="pswp__button pswp__button--zoom" title="Zoom in/out"></button>
<div class="pswp__preloader">
<div class="pswp__preloader__icn">
<div class="pswp__preloader__cut">
<div class="pswp__preloader__donut"></div>
</div>
</div>
</div>
</div>
<div class="pswp__share-modal pswp__share-modal--hidden pswp__single-tap">
<div class="pswp__share-tooltip"></div>
</div>
<button class="pswp__button pswp__button--arrow--left" title="Previous (arrow left)">
</button>
<button class="pswp__button pswp__button--arrow--right" title="Next (arrow right)">
</button>
<div class="pswp__caption">
<div class="pswp__caption__center"></div>
</div>
</div>
</div>
</div>
<script src="http://ajax.googleapis.com/ajax/libs/jquery/1.7.1/jquery.min.js"></script>
<script src="https://fritzm.github.io/theme/bootstrap-collapse.js"></script>
</body>
</html>