-
Notifications
You must be signed in to change notification settings - Fork 0
/
index5.html
751 lines (599 loc) · 45.2 KB
/
index5.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
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8">
<title>fritzm.github.io</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">
<a href="https://fritzm.github.io/diagnostics-11.html"><h1>PDP-11/45: Diagnostics XI - FP11 FPU, cont.</h1></a>
Sun 23 October 2016
by <a class="url fn" href="https://fritzm.github.io/author/fritz-mueller.html">Fritz Mueller</a>
</div>
<div><p>Wrote some small test programs to investigate FP add/subtract. Turns out that single-precision add/subtract
works fine, but double-precision results come back with some erroneous bits set in the fraction.
Here's the test code I ended up using for troublshooting -- when executed on my machine, bits 24 and 25
end up incorrectly set in the result at D3:</p>
<table class="highlighttable"><tr><td class="linenos"><div class="linenodiv"><pre> 1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17</pre></div></td><td class="code"><div class="highlight"><pre><span></span> <span class="nt">000000</span> <span class="nt">AC0</span><span class="o">=%</span><span class="nt">0</span>
<span class="nt">000001</span> <span class="nt">AC1</span><span class="o">=%</span><span class="nt">1</span>
<span class="nt">000000</span> <span class="p">.</span><span class="nc">ASECT</span>
<span class="nt">001000</span> <span class="o">.=</span><span class="nt">1000</span>
<span class="nt">001000</span> <span class="nt">170011</span> <span class="nt">START</span><span class="o">:</span> <span class="nt">SETD</span> <span class="o">;</span><span class="nt">SET</span> <span class="nt">DOUBLE</span> <span class="nt">PRECISION</span> <span class="nt">MODE</span>
<span class="nt">001002</span> <span class="nt">172467</span> <span class="nt">000014</span> <span class="nt">LDD</span> <span class="nt">D1</span><span class="o">,</span><span class="nt">AC0</span> <span class="o">;</span><span class="nt">FETCH</span> <span class="nt">FIRST</span> <span class="nt">ADDEND</span> <span class="nt">FROM</span> <span class="nt">D1</span>
<span class="nt">001006</span> <span class="nt">172567</span> <span class="nt">000020</span> <span class="nt">LDD</span> <span class="nt">D2</span><span class="o">,</span><span class="nt">AC1</span> <span class="o">;</span><span class="nt">FETCH</span> <span class="nt">SECOND</span> <span class="nt">ADDEND</span> <span class="nt">FROM</span> <span class="nt">D2</span>
<span class="nt">001012</span> <span class="nt">172100</span> <span class="nt">ADDD</span> <span class="nt">AC0</span><span class="o">,</span><span class="nt">AC1</span> <span class="o">;</span><span class="nt">ADD</span> <span class="nt">THEM</span> <span class="o">(</span><span class="nt">RESULT</span> <span class="nt">IN</span> <span class="nt">AC1</span><span class="o">)</span>
<span class="nt">001014</span> <span class="nt">174167</span> <span class="nt">000022</span> <span class="nt">STD</span> <span class="nt">AC1</span><span class="o">,</span><span class="nt">D3</span> <span class="o">;</span><span class="nt">STORE</span> <span class="nt">RESULT</span> <span class="nt">TO</span> <span class="nt">D3</span>
<span class="nt">001020</span> <span class="nt">000000</span> <span class="nt">HALT</span>
<span class="nt">001022</span> <span class="nt">040200</span> <span class="nt">000000</span> <span class="nt">000000</span> <span class="nt">D1</span><span class="o">:</span> <span class="p">.</span><span class="nc">WORD</span> <span class="nt">040000</span><span class="o">,</span><span class="nt">000000</span><span class="o">,</span><span class="nt">000000</span><span class="o">,</span><span class="nt">000000</span> <span class="o">;</span><span class="nt">0</span><span class="p">.</span><span class="nc">5</span>
<span class="nt">001030</span> <span class="nt">000000</span>
<span class="nt">001032</span> <span class="nt">040200</span> <span class="nt">000000</span> <span class="nt">000000</span> <span class="nt">D2</span><span class="o">:</span> <span class="p">.</span><span class="nc">WORD</span> <span class="nt">040000</span><span class="o">,</span><span class="nt">000000</span><span class="o">,</span><span class="nt">000000</span><span class="o">,</span><span class="nt">000000</span> <span class="o">;</span><span class="nt">0</span><span class="p">.</span><span class="nc">5</span>
<span class="nt">001040</span> <span class="nt">000000</span>
<span class="nt">001042</span> <span class="nt">000000</span> <span class="nt">000000</span> <span class="nt">000000</span> <span class="nt">D3</span><span class="o">:</span> <span class="p">.</span><span class="nc">WORD</span> <span class="nt">000000</span><span class="o">,</span><span class="nt">000000</span><span class="o">,</span><span class="nt">000000</span><span class="o">,</span><span class="nt">000000</span>
<span class="nt">001050</span> <span class="nt">000000</span>
<span class="nt">001000</span> <span class="p">.</span><span class="nc">END</span> <span class="nt">START</span>
</pre></div>
</td></tr></table>
<p>So, the usual procedure: KM11 in the floating point slot, and FRL (where these bits are handled) out on
extenders. First step is to verify the microcode sequencing with the KM11 and front panel, and it looks good.
In particular, the FPU is sequencing through states ADD.04 and ADD.06 per expectation for double-precision,
branching correctly for non-zero operands, and taking the equal exponents branch through ADD.24 (refer to
page FLOWS 8 of the FP11 engineering drawings).</p>
<p>Next, stopped in state ADD.38, where the fraction addition occurs, and scanned the inputs and outputs of
all the 74181 bitslice ALUs with a logic probe. Bit 28 of the A input to the FALU (E16 pin 2, refer to page
FRLJ of the FP11 engineering drawings) is incorrectly set. This is arriving via the AR register.</p>
<p>The value in the AR register is originally fetched from the register scratchpad, then flows through QR, BR,
and the FALU during microstates ADD.04, ADD.06, and ADD.02. Some more stepping and logic probe work showed
that the fraction values are correct along these paths through these states. So it looks like AR itself
may be at fault.</p>
<p>Set up the logic analyzer on E15, which is a 74194 shift-register that holds bits 28-31 of AR. It looks
like it is indeed faulty:</p>
<p><img src='/images/pdp11/bad-ar.jpg'/></p>
<p>Here we can see what should be a broadside load: positive CLK edge, S0 and S1 both asserted, and inputs of
all zeros. But the output sticks brokenly at 8. Pulled this shift register, soldered in a socket, and put
a replacement and a couple of spares on order. All for now, until the parts arrive.</p></div>
<hr />
</div>
<div class='article'>
<div class="content-title">
<a href="https://fritzm.github.io/diagnostics-10.html"><h1>PDP-11/45: Diagnostics X - FP11 FPU, cont.</h1></a>
Sat 01 October 2016
by <a class="url fn" href="https://fritzm.github.io/author/fritz-mueller.html">Fritz Mueller</a>
</div>
<div><p>Okay, here's the dig in on the FP11 STST diagnostic failure. As detailed previously, I'd been seeing an
incorrect FEC after executing a small test program to generate a minus-zero condition. I'd verified that
the microcode sequence was per expectation, and that the correct FEC was being stored and retrieved from
AC7[1:0] in microstates TRP.50 and the start of TRP.60.</p>
<p>The end of TCP.60 and all of state TRP.70 are used to move the FEC and FEA from AC7[1:0] to AC7[3:2] via QR
and BR, and something was going awry here. Since the nominal FEC is octal 14, I decided just to trace the
four least significant bits. Consulting the engineering drawings, the nominal flow of these bits through
logic on the FRL during these states would be:</p>
<style>
.logiclist { display: inline; border-collapse: collapse; margin-right: 1em; }
.logiclist caption { font-weight: bold; }
.logiclist tr:nth-child(4n+2), .logiclist tr:nth-child(4n+3) { background-color: #f2f2f2; }
.logiclist .microstate { background-color: #ffffff; }
.logiclist th, .logiclist td { padding: 5px; }
.logiclist td { border: 1px solid lightgray; font-family: Menlo,Consolas,monospace; }
</style>
<table class="logiclist">
<thead>
<tr><th>Function</th><th>Package</th><th>Dir</th><th colspan="4">Pin:Level</th><th>Microstate</th></tr>
</thead>
<tbody>
<tr><td>ACi<03:00></td><td>E85</td><td>out</td><td>11:H</td><td>9:H</td><td>7:L</td><td>5:L</td><td class="microstate" rowspan="2">TRP.60 (2)</td></tr>
<tr><td>QR<06:03></td><td>E74</td><td>in</td><td>3:H</td><td>4:H</td><td>5:L</td><td>6:L</td></tr>
<tr><td></td><td></td><td>out</td><td>15:H</td><td>14:H</td><td>13:L</td><td>12:L</td><td class="microstate" rowspan="14">TRP.70 (3)</td></tr>
<tr><td>BR<07:04></td><td>E75</td><td>in</td><td>13:H</td><td>12:H</td><td>4:L</td><td></td></tr>
<tr><td></td><td></td><td>out</td><td>15:H</td><td>10:H</td><td>2:L</td><td></td></tr>
<tr><td>BR<03:00></td><td>E87</td><td>in</td><td></td><td></td><td></td><td>5:L</td></tr>
<tr><td></td><td></td><td>out</td><td></td><td></td><td></td><td>7:L</td></tr>
<tr><td>FALU<07:04></td><td>E77</td><td>in</td><td>20:H</td><td>22:H</td><td>1:L</td><td></td></tr>
<tr><td></td><td></td><td>out</td><td>11:L</td><td>10:L</td><td>9:H</td><td></td></tr>
<tr><td>FALU<03:00></td><td>E89</td><td>in</td><td></td><td></td><td></td><td>18:L</td></tr>
<tr><td></td><td></td><td>out</td><td></td><td></td><td></td><td>13:H</td></tr>
<tr><td>ACMX<03:02></td><td>E83</td><td>in</td><td>13:L</td><td>3:L</td><td></td><td></td></tr>
<tr><td></td><td></td><td>out</td><td>9:L</td><td>7:L</td><td></td><td></td></tr>
<tr><td>ACMX<01:00></td><td>E84</td><td>in</td><td></td><td></td><td>13:H</td><td>3:H</td></tr>
<tr><td></td><td></td><td>out</td><td></td><td></td><td>9:H</td><td>7:H</td></tr>
<tr><td>ACi<03:00></td><td>E85</td><td>in</td><td>12:L</td><td>10:L</td><td>6:H</td><td>4:H</td></tr>
</tbody>
</table>
<p>Note that the bit values are inverted here by the FALU, since the reigster file used on the FP11 has
inverting outputs.</p>
<p>Threw the FRL out on extenders and starting verifying the chart above with a logic probe. Surprisingly,
everything probed out correctly (?!) Reset and ran the test program and verified that the bug had gone away.
Hmmm... My only guess here is that there was some dust or a whisker shorting some of the pins that I
dislodged with the logic probe, or perhaps an oxidized board conection. In any case, it seems to work
robustly now. Of the FP11 diagnostics, the following now pass:</p>
<style>
.diaglist { display: inline; border-collapse: collapse; margin-right: 1em; }
.diaglist caption { font-weight: bold; }
.diaglist tr:nth-child(even) { background-color: #f2f2f2; }
.diaglist th, .diaglist td { padding: 5px; }
.diaglist td { border: 1px solid lightgray; font-family: Menlo,Consolas,monospace; }
</style>
<table class="diaglist">
<thead>
<tr><th>Diagnostic</th><th>Description</th><th>Status</th></tr>
</thead>
<tbody>
<tr><td>CFPAB0.BIC</td><td>LDFPS,STFPS,SETI,SETL,SETF,SETD,CFCC</td><td>pass</td></tr>
<tr><td>CFPBB0.BIC</td><td>STST</td><td>pass</td></tr>
<tr><td>CFPCD0.BIC</td><td>LDF,LDD,STF,STD</td><td>pass</td></tr>
<tr><td>CFPHB0.BIC</td><td>CLR,TST,ABS,NEG</td><td>pass</td></tr>
<tr><td>CFPKB0.BIC</td><td>LDEXP</td><td>pass</td></tr>
</tbody>
</table>
<p>CFPDB0.BIC, which tests floating point adds/subtracts, is failing. All for now -- on to debugging
add/subtract next time...</p></div>
<hr />
</div>
<div class='article'>
<div class="content-title">
<a href="https://fritzm.github.io/h720e-teardown.html"><h1>PDP-11/45: H720E teardown and inspection</h1></a>
Sun 18 September 2016
by <a class="url fn" href="https://fritzm.github.io/author/fritz-mueller.html">Fritz Mueller</a>
</div>
<div><p>Started in on the H720E power supply that is part of RK05 storage system. Just initial teardown, cleaning, and
inspection for obviously failed parts. Looks pretty good, though there is a lot of dust and grime because this
unit lost its top cover plate somewhere over the years (I'll have to build some sort of replacement).</p>
<p>There are a couple of 22,000 mFD 50v electrolytic caps here that I'll try reforming before hitting them at full power,
since they've been sitting idle for upwards of 30yrs! Also, one obviously leaking 330 mfd axial on regulator board, so
I'll replace this and all its identical twins. Parts on order...</p>
<p><img src='/images/pdp11/h720e-breakdown_thumbnail_tall.jpg' title='Tearing down the H720E power supply for the RK11 storage controller' onclick='pswipe("pdp11",38);'/>
<img src='/images/pdp11/h720e-leaking-cap_thumbnail_tall.jpg' title='Leaking tantalum cap on H720e regulator board' onclick='pswipe("pdp11",39);'/></p></div>
<hr />
</div>
<div class='article'>
<div class="content-title">
<a href="https://fritzm.github.io/diagnostics-9.html"><h1>PDP-11/45: Diagnostics IX - FP11 FPU, cont.</h1></a>
Sat 10 September 2016
by <a class="url fn" href="https://fritzm.github.io/author/fritz-mueller.html">Fritz Mueller</a>
</div>
<div><p>Did a lot of reading on the FP11 design. A few interesting notes that are buried in the maintenance manual:</p>
<ul>
<li>
<p>When debugging FP11 microcode with a KM11 in single-microstep mode, the 11/45 front panel microcode display shows
the address of the <em>next</em> microinstruction, NOT the current microinstruction. This is because the stop-point for
single microinstruction is at a point between T2 and T3, just <em>after</em> the next microinstruction addr has been
calculated. This is different behavior than the 11/45 CPU front panel microaddress display.</p>
</li>
<li>
<p>There's a note in the maintenance manual that explicitly cautions that when using extender boards for debug, the
RC maintenance clock should be used, and set with period >50ns. I had not been doing similar while debugging the
KB11-A CPU, and maybe this explains the occasional different behavior I'd see when throwing boards out on extenders...
In particular, I had seen this when debugging a spare CPU GRA; next time I return to that board I will try the CPU
RC clock.</p>
</li>
</ul>
<p>Okay, so here's my first simple test program for STST:</p>
<table class="highlighttable"><tr><td class="linenos"><div class="linenodiv"><pre>1
2
3
4
5
6
7
8
9</pre></div></td><td class="code"><div class="highlight"><pre><span></span><span class="nt">000000</span> <span class="nt">AC0</span><span class="o">=%</span><span class="nt">0</span>
<span class="nt">000000</span> <span class="p">.</span><span class="nc">ASECT</span>
<span class="nt">001000</span> <span class="o">.=</span><span class="nt">1000</span>
<span class="nt">001000</span> <span class="nt">170127</span> <span class="nt">044000</span> <span class="nt">START</span><span class="o">:</span> <span class="nt">LDFPS</span> <span class="p">#</span><span class="nn">044000</span> <span class="o">;</span><span class="nt">FID</span><span class="o">+</span><span class="nt">FIUV</span>
<span class="nt">001004</span> <span class="nt">172467</span> <span class="nt">000004</span> <span class="nt">LDF</span> <span class="nt">NEGZ</span><span class="o">,</span><span class="nt">AC0</span> <span class="o">;</span><span class="nt">LOAD</span> <span class="nt">A</span> <span class="nt">MINUS-ZERO</span>
<span class="nt">001010</span> <span class="nt">170300</span> <span class="nt">STST</span> <span class="nt">R0</span> <span class="o">;</span><span class="nt">STORE</span> <span class="nt">FEC</span> <span class="nt">TO</span> <span class="nt">R0</span>
<span class="nt">001012</span> <span class="nt">000000</span> <span class="nt">HALT</span>
<span class="nt">001014</span> <span class="nt">100000</span> <span class="nt">000000</span> <span class="nt">NEGZ</span><span class="o">:</span> <span class="p">.</span><span class="nc">WORD</span> <span class="nt">100000</span><span class="o">,</span><span class="nt">000000</span> <span class="o">;</span><span class="nt">MINUS-ZERO</span>
<span class="nt">001000</span> <span class="p">.</span><span class="nc">END</span> <span class="nt">START</span>
</pre></div>
</td></tr></table>
<p>This would be expected to produce the 000014 "Floating Undefined Variable" (minus-zero) exception code in R0, but I see
an incorrect value of 177417. Using the KM11 on the FPU shows the -0 trap and STST microstate flow is per expectation.</p>
<p>Put the FRL out on the extender and started stepping the microcode, examining the state of the pins at the AC register
file along the way. In the -0 trap flow, the FEC code 000014 presented (inverted) at TRP.50 via the EALU, and
subsequently retrieved at TRP.60 looks correct. However, the value presented at TRP.70 via QR, BR, and the FALU does
not. Out of time this weekend; Will have to chase signals back through those paths next time!</p>
<p><img src='/images/pdp11/minus-zero-microcode.png'/></p></div>
<hr />
</div>
<div class='article'>
<div class="content-title">
<a href="https://fritzm.github.io/diagnostics-8.html"><h1>PDP-11/45: Diagnostics VIII - FP11 FPU</h1></a>
Sat 03 September 2016
by <a class="url fn" href="https://fritzm.github.io/author/fritz-mueller.html">Fritz Mueller</a>
</div>
<div><p>Slotted in FP11 spares that I hadn't tried previously, and this has produced some improved results -- returning to
diagnostic CKBME0 (11/45 traps) this now passes with the floating point installed. Additionally, diagnostic
CFPAB0 passes.</p>
<p>CFPBB0 and CFPCD0, however, are failing. Unfortunately, the source code for these is not available in the PDP-11
diagnostics database at retrocmp. The names of the diagnostics tell which instructions they are testing, though.
CFPBB0 is annotated as testing the STST instruction. Rather than work through disassembling the rather lengthy
diagnostics, I'll probably just write some simple test programs around the STST instruction for next time. In the
meantime, I'll do some reading on the FP11 in preparation for microcode-step debug.</p></div>
<hr />
</div>
<div class='article'>
<div class="content-title">
<a href="https://fritzm.github.io/diagnostics-7.html"><h1>PDP-11/45: Diagnostics VII - KT11 MMU</h1></a>
Sat 13 August 2016
by <a class="url fn" href="https://fritzm.github.io/author/fritz-mueller.html">Fritz Mueller</a>
</div>
<div><p>Moving on to the KT11 MMU: running the first diagnostic in the CKT suite, got error reports at 010340, 010560, and
011000. Consulted the diagnostic listings, and these particular tests have to do with D-space translations from
kernel, supervisor, and user modes. The D-space logic is largely on module SSR, so I swapped this out for a spare.
After that, I was able to pass the full suite of basic MMU tests:</p>
<style>
.diaglist { display: inline; border-collapse: collapse; margin-right: 1em; }
.diaglist caption { font-weight: bold; }
.diaglist tr:nth-child(even) { background-color: #f2f2f2; }
.diaglist th, .diaglist td { padding: 5px; }
.diaglist td { border: 1px solid lightgray; font-family: Menlo,Consolas,monospace; }
</style>
<table class="diaglist">
<thead>
<tr><th>Diagnostic</th><th>BEL</th><th>Description</th><th>Status</th></tr>
</thead>
<tbody>
<tr><td>CKTAB0.BIC</td><td>017412</td><td>KT11-C basic logic part 1</td><td>pass</td></tr>
<tr><td>CKTBC0.BIC</td><td>015674</td><td>KT11-C basic logic part 2</td><td>pass</td></tr>
<tr><td>CKTCA0.BIC</td><td>023304</td><td>KT11-C access keys</td><td>pass</td></tr>
<tr><td>CKTDA0.BIC</td><td>016360</td><td>KT11-C MTPD and MTPI</td><td>pass</td></tr>
<tr><td>CKTEB0.BIC</td><td>015310</td><td>KT11-C MFPD and MFPI</td><td>pass</td></tr>
<tr><td>CKTFD0.BIC</td><td>016422</td><td>KT11-C aborts</td><td>pass</td></tr>
</tbody>
</table>
<p>Put the failing SSE module in the repair queue along with the other failed spares I've identified along the way, and
will return to troubleshoot/repair it later. For now, things are looking pretty good with the CPU! I still need to
run and pass the more heavyweight diagnostics: the 11/45 instruction exerciser, KT11 exerciser, and MS11-L exerciser.
All three of these still seem to have halts, but they are quite complicated diagnostics in comparison to the rest,
making use of additional peripherals, etc. I'll need to study these a bit before I can be sure I am using them
correctly. I have also skipped the power fail diagnostics for now as I will need to restore some core memory in order
for these to work correctly.</p>
<p>Next up will be to work on the FPU...</p></div>
<hr />
</div>
<div class='article'>
<div class="content-title">
<a href="https://fritzm.github.io/diagnostics-6.html"><h1>PDP-11/45: Diagnostics VI - GRA ALU PROM repair</h1></a>
Sun 07 August 2016
by <a class="url fn" href="https://fritzm.github.io/author/fritz-mueller.html">Fritz Mueller</a>
</div>
<div><p>Data I/O Series 22 PROM programmer from eBay showed up, as well as some unprogrammed Signetics 82S123.
Punched in the subsidiary ALU control ROM contents from the listing on GRAK in the 11/45 engineering drawings
and burnt a new PROM. Put a socket and the new PROM in place of the failed part on my original GRA, slotted it
into the CPU, and success! Diagnostic CKBOA0 now passes. I will probably return to the other faulty GRA at a
later point, as it is partially diagnosed and I like to have spares working and ready to go.</p>
<p>Next time I'll be moving on to the CKT series of tests for the KT11 memory management cards...</p>
<p><img src='/images/pdp11/prom-programmer_thumbnail_tall.jpg' title='Data I/O series 22 PROM programmer, arrived from eBay' onclick='pswipe("pdp11",36);'/>
<img src='/images/pdp11/alu-prom-replaced_thumbnail_tall.jpg' title='GRA board with replaced ALU PROM' onclick='pswipe("pdp11",37);'/></p></div>
<hr />
</div>
<div class='article'>
<div class="content-title">
<a href="https://fritzm.github.io/diagnostics-5.html"><h1>PDP-11/45: Diagnostics V - D0AA0-D0MA0, CKBOA0</h1></a>
Sun 31 July 2016
by <a class="url fn" href="https://fritzm.github.io/author/fritz-mueller.html">Fritz Mueller</a>
</div>
<div><p>The day gig has been keeping me pretty busy for the last couple of weeks, but had some time to work on the PDP-11
again this weekend, so here's an update.</p>
<p>Looking a little deeper at the diagnostics database over on retrocmp.com, I realized that I had skipped the entire
set of generic 11-family "D0" tests. Downloaded and ran these via PDP11GUI and they all passed. BEL character
patch locations, as described previously, are summarized here for future reference:</p>
<style>
.diaglist { display: inline; border-collapse: collapse; margin-right: 1em; }
.diaglist caption { font-weight: bold; }
.diaglist tr:nth-child(even) { background-color: #f2f2f2; }
.diaglist th, .diaglist td { padding: 5px; }
.diaglist td { border: 1px solid lightgray; font-family: Menlo,Consolas,monospace; }
</style>
<table class="diaglist">
<thead>
<tr><th>Diagnostic</th><th>BEL</th><th>Description</th><th>Status</th></tr>
</thead>
<tbody>
<tr><td>D0AA0.BIN</td><td>014212</td><td>Branch</td><td>pass</td></tr>
<tr><td>D0BA0.BIN</td><td>004336</td><td>Con branch</td><td>pass</td></tr>
<tr><td>D0CA0.BIN</td><td>005526</td><td>Unary</td><td>pass</td></tr>
<tr><td>D0DA0.BIN</td><td>016370</td><td>Binary</td><td>pass</td></tr>
<tr><td>D0EA0.BIN</td><td>010562</td><td>Rotate/shift</td><td>pass</td></tr>
<tr><td>D0FA0.BIN</td><td>017224</td><td>CMP equality</td><td>pass</td></tr>
<tr><td>D0GA0.BIN</td><td>013650</td><td>CMP non-equality</td><td>pass</td></tr>
<tr><td>D0HA0.BIN</td><td>013434</td><td>Move</td><td>pass</td></tr>
<tr><td>D0IA0.BIN</td><td>014126</td><td>Bit set clear test</td><td>pass</td></tr>
<tr><td>D0JA0.BIN</td><td>007472</td><td>Add</td><td>pass</td></tr>
<tr><td>D0KA0.BIN</td><td>007124</td><td>Subtract</td><td>pass</td></tr>
<tr><td>D0LA0.BIN</td><td>015722</td><td>Jump</td><td>pass</td></tr>
<tr><td>D0MA0.BIN</td><td>003250</td><td>JSR RTS RTI</td><td>pass</td></tr>
</tbody>
</table>
<p>Of the "CKB" series of tests, CKBOA0 (11/45 states) is the only one I that is not yet passing. Looking into
this a little further, the first failing sub-test is T65:</p>
<table class="highlighttable"><tr><td class="linenos"><div class="linenodiv"><pre> 1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16</pre></div></td><td class="code"><div class="highlight"><pre><span></span><span class="nt">010540</span> <span class="nt">010701</span> <span class="nt">T65</span><span class="o">:</span> <span class="nt">SCOPE</span> <span class="o">;</span>
<span class="nt">010542</span> <span class="nt">012737</span> <span class="nt">030000</span> <span class="nt">177776</span> <span class="nt">MOV</span> <span class="p">#</span><span class="nn">PUM</span><span class="o">,@</span><span class="p">#</span><span class="nn">PSW</span> <span class="o">;</span><span class="nt">KERNEL</span> <span class="nt">MODE</span><span class="o">,</span> <span class="nt">PREV</span> <span class="nt">USER</span> <span class="nt">MODE</span>
<span class="nt">010550</span> <span class="nt">012706</span> <span class="nt">000500</span> <span class="nt">MOV</span> <span class="p">#</span><span class="nn">KPTR</span><span class="o">,</span><span class="nt">KSP</span> <span class="o">;</span><span class="nt">SET</span> <span class="nt">KERNEL</span> <span class="nt">STACK</span> <span class="nt">POINTER</span>
<span class="nt">010554</span> <span class="nt">012716</span> <span class="nt">000700</span> <span class="nt">MOV</span> <span class="p">#</span><span class="nn">UPTR</span><span class="o">,(</span><span class="nt">KSP</span><span class="o">)</span>
<span class="nt">010560</span> <span class="nt">106606</span> <span class="nt">MTPD</span> <span class="nt">USP</span> <span class="o">;</span><span class="nt">SET</span> <span class="nt">USER</span> <span class="nt">STATCK</span> <span class="nt">POINTER</span>
<span class="nt">010562</span> <span class="nt">005067</span> <span class="nt">170110</span> <span class="nt">CLR</span> <span class="nt">UPTR-2</span>
<span class="nt">010566</span> <span class="nt">052737</span> <span class="nt">140000</span> <span class="nt">177776</span> <span class="nt">BIS</span> <span class="p">#</span><span class="nn">UM</span><span class="o">,@</span><span class="p">#</span><span class="nn">PSW</span> <span class="o">;</span><span class="nt">USER</span> <span class="nt">MODE</span><span class="o">,</span> <span class="nt">PREV</span> <span class="nt">USER</span> <span class="nt">MODE</span>
<span class="nt">010574</span> <span class="nt">106506</span> <span class="nt">MFPD</span> <span class="nt">USP</span> <span class="o">;</span><span class="nt">PUSH</span> <span class="nt">USER</span> <span class="nt">STACK</span> <span class="nt">POINTER</span> <span class="nt">ONTO</span> <span class="nt">USER</span> <span class="nt">STACK</span>
<span class="nt">010576</span> <span class="nt">042737</span> <span class="nt">140000</span> <span class="nt">177776</span> <span class="nt">BIC</span> <span class="p">#</span><span class="nn">UM</span><span class="o">,@</span><span class="p">#</span><span class="nn">PSW</span> <span class="o">;</span><span class="nt">KERNEL</span> <span class="nt">MODE</span><span class="o">,</span> <span class="nt">PREV</span> <span class="nt">USER</span> <span class="nt">MODE</span>
<span class="nt">010604</span> <span class="nt">106506</span> <span class="nt">MFPD</span> <span class="nt">USP</span> <span class="o">;</span><span class="nt">PUSH</span> <span class="nt">USER</span> <span class="nt">STACK</span> <span class="nt">POINTER</span> <span class="nt">ONTO</span> <span class="nt">KERNEL</span> <span class="nt">STACK</span>
<span class="nt">010606</span> <span class="nt">022716</span> <span class="nt">000676</span> <span class="nt">CMP</span> <span class="p">#</span><span class="nn">UPTR-2</span><span class="o">,(</span><span class="nt">KSP</span><span class="o">)</span> <span class="o">;</span><span class="nt">CHECK</span> <span class="nt">THAT</span> <span class="nt">USER</span> <span class="nt">STACK</span> <span class="nt">POINTER</span> <span class="nt">WAS</span>
<span class="nt">010612</span> <span class="nt">001401</span> <span class="nt">BEQ</span> <span class="o">.+</span><span class="nt">4</span> <span class="o">;</span><span class="nt">PUSHED</span> <span class="nt">PROPERLY</span> <span class="o">(</span><span class="nt">ONCE</span><span class="o">)</span>
<span class="nt">010614</span> <span class="nt">000000</span> <span class="nt">HLT</span> <span class="o">;</span><span class="nt">ERROR</span><span class="o">!</span>
<span class="nt">010616</span> <span class="nt">022767</span> <span class="nt">000700</span> <span class="nt">170052</span> <span class="nt">CMP</span> <span class="p">#</span><span class="nn">UPTR</span><span class="o">,</span><span class="nt">UPTR-2</span> <span class="o">;</span><span class="nt">CHECK</span> <span class="nt">THAT</span> <span class="nt">USER</span> <span class="nt">STACK</span> <span class="nt">POINTER</span> <span class="nt">IS</span> <span class="nt">ON</span> <span class="nt">THE</span>
<span class="nt">010624</span> <span class="nt">001401</span> <span class="nt">BEQ</span> <span class="o">.+</span><span class="nt">4</span> <span class="o">;</span><span class="nt">USERS</span> <span class="nt">STACK</span>
<span class="nt">010626</span> <span class="nt">000000</span> <span class="nt">HLT</span> <span class="o">;</span><span class="nt">ERROR</span><span class="o">!</span>
</pre></div>
</td></tr></table>
<p>This runs amok on the MFPD instruction at 010574, which should push the user stack pointer onto the user stack.
Instead, the user stack pointer is pushed to memory at an incorrect address; 010676 instead of 000676. This actually
overwrites subsequent test code. Since the value pushed is 000700, a hard-coded loop is created that prevents the
test from completing the pass even if resumed from halt.</p>
<p>The relevant states in the microcode flow here are MFP.80, MFP.90, and MFP.10:</p>
<p><img src='/images/pdp11/mfpd-microcode.png'/></p>
<p>Stopping at T2 of MFP.10 using the KM11, I can see that the correct value 000700 was fetched to DR (as displayed by
the console address lights), but the incorrect value of 010676 is appearing at the output of the ALU/shifter (as
displayed by the console data lights when set to data paths). Throwing the DAP card out on extenders and taking
a look around with a logic probe revealed that the errant bit 12 is sourcing from the ALU. At each slice of the ALU,
function selectors S3-S0 are correct, CIN is correct, and overall B-mux constant value "2" is correct. The errant bit
is arriving to the ALU from the A-mux...</p>
<p>Chasing this upstream, A-mux selectors S1,S0 are correct, but the bad bit arrives to the mux input on GRAH SR12. Hmmm,
maybe this is one of the things the "BAD" sticker on the GRA is referring to... Next step is to throw the GRA on
the extender, and chase the signal back towards SR and the register files. However, here I hit a snag: the M9301
monitor does not run correctly when the GRA is on the extender! That's pretty weird. Some investigation with the
KM11 and some hand-toggled instructions revealed that at least the Z status bit is not set correctly/reliably when
the card is on the extender. Some of the Z bit logic lives on the GRA also, so I can take a look at that, but I am
now out of time for this weekend. Next time!</p>
<p>A few other miscellaneous notes in wrap-up:</p>
<ul>
<li>
<p>I have been running with the spare GRA marked "BAD" because the first GRA I was using turned out to have a failed ALU
subsidiary PROM. In the meantime I tracked down a PROM programmer and some compatible parts on eBay -- these should
arrive sometime this week at which point I should be able to repair the original board and give it another try.</p>
</li>
<li>
<p>The uPB feature of my home-brew KM11 really doesn't work quite right. It often stops the machine at the requested
micro-state but on the wrong instruction (skipping the first occurrence of the target state seemingly). This caused
me a great deal of confusion today, as I was stepping through flows at a different program location than I had assumed,
until I finally noticed the address lights on the console.</p>
</li>
<li>
<p>ESC key on the VT52 is non-functional, making it impractical to use for RT-11. The key mechanism looks okay from the
top (thanks for more helpful advice from the vcfed forum!). I think I'll need to pull the keyboard PCB and re-flow the
solder on the affected mechanism as a next step.</p>
</li>
<li>
<p>Looking forward to checking out Vintage Computer Fest West sometime next weekend!</p>
</li>
</ul></div>
<hr />
</div>
<div class='article'>
<div class="content-title">
<a href="https://fritzm.github.io/diagnostics-4.html"><h1>PDP-11/45: Diagnostics IV - CKBME0</h1></a>
Sun 17 July 2016
by <a class="url fn" href="https://fritzm.github.io/author/fritz-mueller.html">Fritz Mueller</a>
</div>
<div><p>Some progress with the CKBME0 diagnostic mentioned previously. It seems the concern with how the test behaves wrt.
preconditions of the serial interface was well founded.</p>
<p>In order to debug more easily, I extracted the failing test and built a small loop around it, with a pass counter
and display register update, etc. In the original test suite, a RESET instruction is executed immediately prior to
the failing test, and it takes some time to come around the failing test on each pass, so I included a RESET and
a delay loop in my test code as well. I then got failure modes and rates consistent with the original test suite.</p>
<p>The experiments previously described had indicated timing sensitivity (e.g. running on the RC maintenance clock at 50%
clock speed changed the pass failure rate from ~50% to 100%) so I began to think more seriously about timing
between the processor and the serial card, and how the time taken to circulate the entire suite of tests could affect
the precondition of the serial interface when entering the test in subsequent passes. A re-read of the DL11
documentation showed that the transmit data is also double-buffered; if the transmit shift register is empty, a
character written to the output buffer will be latched to the transmit shift register causing the output buffer to
go ready again almost immediately.</p>
<p>I inserted the following code before the BIS/WAIT sequence in the original diagnostic (listed previously), which
establishes consistent preconditions (shift register full, buffer empty) before the BIS. Success rate went to 100%:</p>
<table class="highlighttable"><tr><td class="linenos"><div class="linenodiv"><pre>1
2
3</pre></div></td><td class="code"><div class="highlight"><pre><span></span> <span class="nt">MOV</span> <span class="p">#</span><span class="nn">40</span><span class="o">,@</span><span class="p">#</span><span class="nn">177566</span> <span class="o">;</span><span class="nt">ENSURE</span> <span class="nt">XMIT</span> <span class="nt">SHIFT</span> <span class="nt">REGISTER</span> <span class="nt">HAS</span> <span class="nt">SOMETHING</span> <span class="nt">TO</span> <span class="nt">CHEW</span> <span class="nt">ON</span>
<span class="nt">L0</span><span class="o">:</span> <span class="nt">TSTB</span> <span class="o">@</span><span class="p">#</span><span class="nn">TTCSR</span> <span class="o">;</span><span class="nt">CHECK</span> <span class="nt">XMIT</span> <span class="nt">BUFFER</span>
<span class="nt">BPL</span> <span class="nt">L0</span> <span class="o">;</span><span class="nt">LOOP</span> <span class="nt">UNTIL</span> <span class="nt">READY</span><span class="o">,</span> <span class="nt">ENSURES</span> <span class="nt">INT</span> <span class="nt">IMMEDIATELY</span> <span class="nt">AFTER</span> <span class="nt">BIS</span>
</pre></div>
</td></tr></table>
<p>I then further verified that the unmodified original diagnostic suite passes 100% if I turn the M7800 down to 4800
Baud. Worth noting when trying to run these older diagnostics!</p></div>
<hr />
</div>
<div class='article'>
<div class="content-title">
<a href="https://fritzm.github.io/vt52-repair.html"><h1>PDP-11/45: VT52 repair</h1></a>
Sat 16 July 2016
by <a class="url fn" href="https://fritzm.github.io/author/fritz-mueller.html">Fritz Mueller</a>
</div>
<div><p>Replacement oscillator arrived for the VT52, so spent some time getting it back going again. Things got <em>much</em> better
with a stable timing chain, but some glitchiness remained -- tracked this down to the socketed microcode ROMS which
just required a reseat.</p>
<p>Here you can see the new oscillator fitted (silver rectangular can with tie-wrap). The microcode ROMS are the four
socketed chips towards the right in the picture. Interestingly, the schematic I have calls for 8 ROMS of half the size
of the ones that are in here, and indeed you can see the unpopulated spaces for these on the board.</p>
<p><img src='/images/pdp11/vt52-repair_thumbnail_tall.jpg' title='VT52 open for repairs with new clock oscillator installed' onclick='pswipe("pdp11",35);'/></p></div>
<hr />
</div>
<div class="pagination">
<ul>
<li class="prev"><a href="https://fritzm.github.io/index4.html">← Previous</a></li>
<li class=""><a href="https://fritzm.github.io/index.html">1</a></li>
<li class=""><a href="https://fritzm.github.io/index2.html">2</a></li>
<li class=""><a href="https://fritzm.github.io/index3.html">3</a></li>
<li class=""><a href="https://fritzm.github.io/index4.html">4</a></li>
<li class="active"><a href="https://fritzm.github.io/index5.html">5</a></li>
<li class=""><a href="https://fritzm.github.io/index6.html">6</a></li>
<li class=""><a href="https://fritzm.github.io/index7.html">7</a></li>
<li class=""><a href="https://fritzm.github.io/index8.html">8</a></li>
<li class="next"><a href="https://fritzm.github.io/index6.html">Next →</a></li>
</ul>
</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>