-
Notifications
You must be signed in to change notification settings - Fork 0
/
index.html
1769 lines (1585 loc) · 124 KB
/
index.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
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
<!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/gt40-2.html"><h1>GT40 Terminal II: Lunar Lander</h1></a>
Fri 01 September 2023
by <a class="url fn" href="https://fritzm.github.io/author/fritz-mueller.html">Fritz Mueller</a>
</div>
<div><p><em>[Continuation of restoration work on a DEC GT40 graphic display terminal; part one
<a href="https://fritzm.github.io/gt40.html">here</a>.]</em></p>
<p>At this point, Scott had taken over the restoration work as I had had to leave town for work. We consulted a
few times via IMs and video calls over the next couple weeks; the following is a narrative of Scott's
continued work on the project as I understood it remotely.</p>
<p>The next thing that needed doing was to replace the failed microcode PROM described at the end of the previous
article. I did some work to manually transcribe the PROM contents from the binary microcode listings included
in the engineering drawings (4 bits x 256 microcode locations). Scott double-checked my work here and found
and fixed at least three transcription errors (always good to have a double check on tedious tasks like this,
and I seem to be developing a worsening dyslexia with age -- thanks, Scott!)</p>
<p>Scott tracked down and burned a replacement PROM and replaced the failing one on the board, and we were back
again to the previous high water mark (able to run toggle in programs and the ROM bootstrap terminal emulator,
with the same linefeed and binary load failures I had seen previously).</p>
<p>Scott played around with the binary loader for a bit, but it seemed to be suffering a pretty frustrating blend
of several different issues. Attention was turned back to the bootstrap ROM terminal emulator LF handling
problem, which was consistent and repeatable. Scott began single stepping the code by instruction, using the
listings in the GT40/GT42 User's Guide, and soon made two discoveries:</p>
<ul>
<li>
<p>The unit has the GT42 version of the boostrap ROM, and not the GT40 version (this can be seen because
the bootstrap terminal emulator correctly handles TAB characters).</p>
</li>
<li>
<p>Upon receiving a LF char, the bootstrap code got to a loop which was scanning the input buffer looking for
LFs, but failed to find any and looped indefinitely.</p>
</li>
</ul>
<p>The malfunctioning ROM code scanning for LFs can be seen at location 166310, in the listing on PDF page 81 of
the GT40/GT42 User's Guide, and is as follows:</p>
<table class="highlighttable"><tr><td class="linenos"><div class="linenodiv"><pre>1
2
3
4
5
6</pre></div></td><td class="code"><div class="highlight"><pre><span></span><span class="nt">166310</span> <span class="nt">122300</span> <span class="nt">LFLOOP</span><span class="o">:</span> <span class="nt">CMPB</span> <span class="o">(</span><span class="nt">SCAN</span><span class="o">)+,</span><span class="nt">CHAR</span> <span class="o">;</span><span class="nt">AND</span> <span class="nt">LOOK</span> <span class="nt">FOR</span> <span class="nt">A</span> <span class="nt">LINEFEED</span>
<span class="nt">166312</span> <span class="nt">001406</span> <span class="nt">BEQ</span> <span class="nt">LFOUND</span> <span class="o">;</span><span class="nt">GOT</span> <span class="nt">IT</span><span class="o">,</span> <span class="nt">SEARCH</span> <span class="nt">HAS</span> <span class="nt">ENDED</span>
<span class="nt">166314</span> <span class="nt">020327</span> <span class="nt">007000</span> <span class="nt">CMP</span> <span class="nt">SCAN</span><span class="o">,</span><span class="p">#</span><span class="nn">BLIMIT</span> <span class="o">;</span><span class="nt">ARE</span> <span class="nt">WE</span> <span class="nt">AT</span> <span class="nt">END</span> <span class="nt">OF</span> <span class="nt">BUFFER</span><span class="o">?</span>
<span class="nt">166320</span> <span class="nt">103773</span> <span class="nt">BLO</span> <span class="nt">LFLOOP</span> <span class="o">;</span><span class="nt">NOPE</span><span class="o">,</span> <span class="nt">KEEP</span> <span class="nt">ON</span> <span class="nt">LOOKING</span><span class="o">.</span>
<span class="nt">166322</span> <span class="nt">012703</span> <span class="nt">001000</span> <span class="nt">MOV</span> <span class="p">#</span><span class="nn">BSTART</span><span class="o">,</span><span class="nt">SCAN</span> <span class="o">;</span><span class="nt">IF</span> <span class="nt">AT</span> <span class="nt">TOP</span><span class="o">,</span> <span class="nt">RESET</span> <span class="nt">TO</span> <span class="nt">BOTTOM</span> <span class="nt">OF</span> <span class="nt">BUFFER</span>
<span class="nt">166326</span> <span class="nt">000770</span> <span class="nt">BR</span> <span class="nt">LFLOOP</span> <span class="o">;</span><span class="nt">AND</span> <span class="nt">KEEP</span> <span class="nt">ON</span> <span class="nt">LOOKING</span><span class="o">.</span>
</pre></div>
</td></tr></table>
<p>Scott began microstepping at address program address 166310, which is machine code 122300, <code>CMPB (R2)+,R0</code>.
The microcode flow traced through is as follows, using state names from the microcode listings in the
engineering drawings:</p>
<ul>
<li><code>H-2</code>: Tracing activity starts with the machine halted and looping in microstate H-2. The KM11 is set to
manual clock mode, front panel CONT switch depressed and held, and several manual clocks taken causing
microbranch to...<br><br></li>
<li><code>CCS-1</code>: Loads B←PC, causing PC to be displayed on console lights.</li>
<li><code>CCS-2</code>: Loops waiting for CONT switch to be released.</li>
<li><code>CCS-3</code>: Turns on RUN light.<br><br></li>
<li><code>F-1</code>: Loads BA←PC, and initiates asynchronous bus cycle to fetch instruction.</li>
<li><code>F-2</code>: Loads B←PC+2, causing next instruction address to be displayed on console lights.</li>
<li><code>F-3</code>: Loads PC←B, updating the PC, and suspends processor clock until instruction fetch bus cycle reaches
SSYN.</li>
<li><code>F-4</code>: Resumes here when fetched instruction is on bus; latches into B (displaying instruction on console
lights) and also into the IR decode register; releases the bus.</li>
<li><code>F-5</code>: First big microcode branch based on instruction type.<br><br></li>
<li><code>S2-1</code>: Source addressing mode 2 (register auto-increment). BA←R[S], and initiates asynchronous bus cycle to
read source operand from memory.</li>
<li><code>S2-2</code>: B←R[S]+1+BYTE.BAR, which increments the source register by 1 or 2 depending on byte or word
instruction.</li>
<li><code>S2-3</code>: R[S]←B (stores back incremented source register), suspends processor clock until source operand
fetch bus cycle reaches SSYN.</li>
<li><code>S1-2</code>: Resumes here when source operand is on bus; latches into B (displaying source operand on console
lights) and releases the bus, then branches on byte even, byte odd, or word.</li>
</ul>
<p>So far so good. In the case being traced, we happen to be doing a byte read from an odd address. In this
case, the fetched source data must next be shifted right 8 bits; this is done over the course of the next 8
microsinstructions, <code>SBO-1</code> - <code>SBO-8</code>. Here Scott noticed a problem: bit 3 was always set in the B register
after <em>any</em> single right shift, even if the bit4 to the left was zero. This points directly at E044 on sheet
DPA, a four bit shift register which implements bits 0:3 of the B-register:</p>
<p><img style="display:block; margin-left:auto; margin-right:auto" src="/images/pdp11/KD11-B-bad-BREG-shift.png" title="KD11-B data path bad BREG shift register" width="85%"/></p>
<p>This part was pulled and replaced, and the ROM terminal emulator could then correctly handle LFs! After a
few additional red herring to do with loose power connectors and occasional accidental bumping of the test
switches on the M7013 display control board, Scott was also able to get the lunar lander code to load and run
via the ROM bootstrap binary loader, though still with some display problems:</p>
<p><img src='/images/pdp11/gt40-line-feeds_thumbnail_tall.jpg' title='GT40 displaying multiple lines after CMPB (R2)+,R0 LF fix.' onclick='pswipe("pdp11",113);'/>
<img src='/images/pdp11/gt40-first-lunar-run_thumbnail_tall.jpg' title='GT40 running the lunar lander game, but still with some display issues.' onclick='pswipe("pdp11",114);'/></p>
<p>Scott discovered a major clue concerning remaining loader problems: some GT40 binary-loader encoded binaries
we had been using which were downloaded off other enthusiast web sites contained erroneous extra linefeed and
"!" characters, which confused the loader and/or triggered bad checksums. After stripping these out, the
loader was seen to work quite reliably.</p>
<p>With diagnostics now in hand, Scott was able to track down a few remaining hardware issues on the display
boards (a bad register with a stuck high bit, and a swap of one of the DACs which had been acting flaky with
one from a spare board. I don't have precise details on these particular fixes, but will expand here later
if/when I get more information.)</p>
<p>Below, screen shots of some diagnostics, and at long last, Scott lands on the moon and gets his cheeseburger!
Drop by and visit Scott at his booth at VCFMW this weekend, see and play game, and hear tales of the
restoration first-hand!</p>
<p><img src='/images/pdp11/gt40-diags_thumbnail_tall.jpg' title='Repaired GT40 running diagnostic MAINDEC-DDGTE.' onclick='pswipe("pdp11",115);'/>
<img src='/images/pdp11/gt40-lunar-better_thumbnail_tall.jpg' title='Repaired GT40 running the lunar lander game.' onclick='pswipe("pdp11",116);'/>
<img src='/images/pdp11/gt40-cheeseburger_thumbnail_tall.jpg' title='Repaired GT40: Scott lands on the moon and gets his cheesburger!' onclick='pswipe("pdp11",117);'/></p></div>
<hr />
</div>
<div class='article'>
<div class="content-title">
<a href="https://fritzm.github.io/gt40.html"><h1>GT40 Terminal</h1></a>
Mon 21 August 2023
by <a class="url fn" href="https://fritzm.github.io/author/fritz-mueller.html">Fritz Mueller</a>
</div>
<div><p>A while ago my friend Scott approached me with an idea to collaborate on restoration of a DEC GT40 graphic
display terminal of unknown status, belonging to a third collector friend of ours; the idea was to restore the
machine to working order for exhibition at the various summer/fall vintage computer shows. The GT40 ran an
early (pre-Atari) graphical version of the lunar lander game which was released in 1973. The 50th anniversary
of this code seemed a nice theme for the exhibit.</p>
<p>The GT40 was an integrated product consisting of a PDP-11/05 (KD11-B) CPU, a VT11 vector display processor,
a VR14 X-Y monitor, a light pen, keyboard, and a DL11 serial interface:</p>
<p><img style="display:block; margin-left:auto; margin-right:auto" src="/images/pdp11/GT40.png" title="The DEC GT40"/></p>
<p>Scott retrieved the terminal, which had a fairly bad case of screen rot. We agreed that Scott would work on
restoration of the monitor while I dug in on the system unit. Scott got to work while I dealt with
distractions of ongoing home renovations, a ton of work-related travel, and my first bout of COVID (blaargh!)</p>
<p>The screen rot is caused by a deterioriation of a polyvinyl acetate (PVA) layer sandwiched between the front
surface of the CRT glass and an outer protective implosion shield. All of this is held together by a retaining
ring affixed to the CRT with silicone adhesive. The only fix for this is to disassemble the monitor, separate
the sandwich, and clean out and replace the deteriorated PVA layer.</p>
<p>After chatting with some folks who had successfully conducted a similar VR14 restoration at the <a href="https://www.ricomputermuseum.org/">Rhode Island
Computer Museum</a>, Scott obtained some <a href="https://prosoco.com/product/dicone-nc9/">silicone
digester</a> to aid in separation of the retaining ring. The terminal
was disassembled and then digester was repeatedly injected under the ring with a syringe, allowed to sit, and
the resulting softened silicone scraped away over the course of a week.</p>
<p>Scott then worked to conform a lexan sheet to the interior of the implosion shield as a replacement for the
PVA layer, as RICM had done. This process, conducted in a home oven, proved to be quite fiddly. But
persistence paid off, and the end result looks very nice!</p>
<p>After a precautionary reform of the larger power supply electrolytics, careful reassembly, and a gradual
bringup on a variac, the monitor showed proof of life on the bench, hooked up to a signal generator source.</p>
<p><img src='/images/pdp11/VR14-screen-rot_thumbnail_tall.JPG' title='GT40 display (VR14) with screen rot' onclick='pswipe("pdp11",105);'/>
<img src='/images/pdp11/VR14-digesting_thumbnail_tall.JPG' title='Silicone digester repeatedly injected beneath the retaining ring, and softened silicone sraped away a layer at a time.' onclick='pswipe("pdp11",106);'/>
<img src='/images/pdp11/VR14-apart_thumbnail_tall.JPG' title='After a week of work the retaining ring was freed and the layers were able to be separated and cleaned.' onclick='pswipe("pdp11",107);'/>
<img src='/images/pdp11/VR14-plexi_thumbnail_tall.JPG' title='Conforming plexiglass in the oven to fill the gap between the display tube and the implosion shield where the PVA used to be.' onclick='pswipe("pdp11",108);'/>
<img src='/images/pdp11/VR14-working_thumbnail_tall.png' title='Display re-assembled and working, driven by a test oscillator, and looking nice!' onclick='pswipe("pdp11",109);'/></p>
<p>In the meantime, starting to feel better, I began to look at the CPU unit. Power supply electrolytics
appeared to be in good shape, and the supply came up on the bench without much difficulty.</p>
<p>The module utilization for this backplane is as follows:</p>
<style>
.module-utilization {
font-size: smaller;
width: 50em;
margin-left: auto;
margin-right: auto;
margin-top: 1rem;
margin-bottom: 2rem;
border-collapse: true;
}
.module-utilization th {
padding: .5em;
font-weight: normal;
}
.module-utilization tr:first-child th {
width: 16.67%;
}
.module-utilization td {
border: 1px solid black;
padding: .5em;
text-align: center;
}
.module-utilization td:empty {
background-color: LightGray;
}
.module-utilization tr:first-child td:first-child {
border: none;
visibility: hidden;
}
</style>
<table class="module-utilization">
<tr><td></td><th>A</th><th>B</th><th>C</th><th>D</th><th>E</th><th>F</th></tr>
<tr><th>1</td><td colspan=6>A320 VT40 Display Generator</td></tr>
<tr><th>2</td><td colspan=6>M7013 VT40 Display Control</td></tr>
<tr><th>3</td><td colspan=6>M7014 VT40 Bus Control</td></tr>
<tr><th>4</td><td colspan=2></td><td colspan=4>M7800 DL11 Serial</td></tr>
<tr><th>5</td><td colspan=2>M930 Term. / UNIBUS out</td><td colspan=4>H214 Core Stack (8K x 16)</td></tr>
<tr><th>6</td><td colspan=6>G231 Core Memory Driver</td></tr>
<tr><th>7</td><td colspan=6>G110 Core Memory Control</td></tr>
<tr><th>8</td><td colspan=6>M7261 KD11-B Control</td></tr>
<tr><th>9</td><td colspan=6>M7260 KD11-B Data Paths</td></tr>
</table>
<p>On the assumption (later proved wrong) that this was effectively the same as a PDP-11/05 setup, I began debug
with just the two CPU cards, an M9301 boot/terminator in position 5A-B, and a grant continuity "knuckle
buster" in position 4D. Some problems were immediately apparent from the front console: deposit and examine
operations to various memory-mapped CPU registers seemed to work as expected, but when examining contents the
M9301 ROM locations bit 13 was always displaying zero. The CPU would not enter run mode, nor could it be
single stepped.</p>
<p>Docs suggested that the GT40 would accomodate a KM11 debug module in postion 1B, so in this went. The machine
behaved even more strangely when the KM11 was in, hanging up entirely unless the KM11 was put in manual clock
mode, and even then stepping microstates at unexpected times. It took a little probing of the CPU clock
circuits to discover why:</p>
<p><img style="display:block; margin-left:auto; margin-right:auto" src="/images/pdp11/GT40-CPU-clock.png" title="GT40 CPU clock circuit"/></p>
<p>Here we see the RC clock at E019. CONJ MAN CLK L is wired to KM11 switch S2, and inhibits the RC clock when
pulled low. With the RC clock thus disabled, NOR gate E027 admits manual clocking via CONJ S CLK ON L,
connected to KM11 (momentary) switch S4. The output at E027 pin 11 continues downstream from here as the
basis of the main processor clock signal.</p>
<p>As it happened, momentary switch S4 was wired on my KM11 replica with opposite sense from that expected. Thus
in its resting postion CONJ S CLK ON L was <em>asserted</em> (low), which meant the clock output at E027 pin 11 was
forced constantly high, regardless of the state of the RC clock. This was verified by leaving S2 "off" and
pulling S4 over to its momentary position, whence the CPU clock immediately picked up again.</p>
<p>I had never noticed this switch reversal when using the KM11 with the 11/45, the RK11-C, or the 11/34 -- all
of these have different clocking circuits unaffected by the default postion of S4. Desoldered and rotated S4
180 degrees, and the problem was fixed.</p>
<p>After having addressed this, I single stepped through a few of the console microcode flows and was able to
match the microcode listings to what was displayed on the KM11 and the console lights with some success. An
action shot of the KM11:</p>
<p><img src='/images/pdp11/GT40-KM11_thumbnail_tall.jpg' title='GT40 system unit with KM11 replica board and microcode control board out on debug extender below. The next microcode address is displayed in the bottom two rows of LEDs, with the LSB at the bottom right. Dark LEDs are logic 1, and lit are logic 0. The next address displayed here is octal 316. From the microcode listings, we can see we are about to branch to micro-state CCS-1 (console continue switch), and can deduce that we are currently in micro-state H-2, about to branch out of the halt microcode loop to the continue switch handler.' onclick='pswipe("pdp11",110);'/></p>
<p>A few tips for anybody else who might be micro-stepping the KD11-B CPU, while we are here:</p>
<ul>
<li>
<p>The MPC address displayed on the KM11 is <em>negated</em> -- dark LEDs are ones, and lit LEDs are zeros. This
definitely takes a little getting used to...</p>
</li>
<li>
<p>The MPC address displayed on the KM11 is the address of the <em>next</em> micro-instruction, not the current
one. This is also pretty tricky until you get the hang of it. One nice thing about it, though, is that
the displayed next address does include the wired-or outputs of micro-branches.</p>
</li>
<li>
<p>Each manual clock toggle is one <em>bus clock</em>, and typically, a micro-instruction will take two bus clocks to
execute. An exception is the inner part (single shifts) of the micro-flows for shift and rotate
instructions, which only take a single bus clock. Generally, it is useful to go ahead and advance two bus
clocks at a time, as it is easy to get confused probing for signals that by design aren't clocked until the
second bus clock within the micro-instruction.</p>
</li>
<li>
<p>The console lights are hard-wired to always display the ALU B-leg input. Useful intermediate information is
often displayed there intentionally by the microcode flows.</p>
</li>
</ul>
<p>Now it was possible to put the data paths board out on extenders and step the microcode for a console
examine of a ROM location with bit 13 set, and see why bit 13 never showed up on the console lights. To
understand this properly, we need to see an excerpt of the KD11-B data paths:</p>
<p><img style="display:block; margin-left:auto; margin-right:auto" src="/images/pdp11/KD11-B-datapath.png" title="KD11-B data path (excerpt)" width="70%"/></p>
<p>Here you see the ALU in the middle, fed by its B-leg and A-leg inputs. B-leg is fed from the B-register, with
provisions for shifting, sign-extension, or forcing the constant +1. B-leg is also continuously displayed on
the console lights. A-leg contains, significantly, the 16-location scratch-pad memory (SPM). The first eight
locations of this hold processor registers R0 through R7; the remaining eight locations serve as temporary
registers for use by the microcode. A-leg can also provide misceallaneous constants from a small ROM.</p>
<p>The A-mux, below the ALU, determines whether the main processor data path is fed from the ALU output, or from
the UNIBUS data lines.</p>
<p>With this in mind, the relevant microcode source sequence (taken from the listings in the engineering
drawings) is as follows:</p>
<div class="highlight"><pre><span></span>LOC NXT * CONSOLE EXAMINE SWITCH- FIRST TIME IN SEQUENCE (DON'T INC R[17])
/ GET TO CE1-1 FROM H-2 VIA BUT SWITCH
/ GET TO CE1-1 FROM CE2-2 VIA GOTO
317 307 CE1-1 BA,B←R[17]; BUT SWITCH
/ DISPLAY ADDRESS BY PUTTING INTO THE B REGISTER WHILE EXAMINE IS DOWN
/ LOOP ON CE1-1 UNTIL SWITCH IS RELEASED
307 326 CE1-2 DATI; CKOFF
326 302 CE1-3 B←UNIBUS DATA; GOTO H-2
</pre></div>
<p>At micro-location 317 (state CE-1, "console examine 1"), the bus address register and B-register are loaded
from SPM location 17, which holds the current console load/examine address. BUT SWITCH ("branch micro-test
switch") causes the microcode to loop here as long as the examine switch is depressed. During this time, the
fetch address is displayed on the console lights since it has been loaded into the B-register. This was all
observed to be functioning normally.</p>
<p>When the examine switch is released, we branch to micro-location 307. Here, a UNIBUS read (DATI) bus cycle is
initiated, and the processor clock and microcode execution are suspended until the bus target asyncrohonously
asserts SSYN (indicating valid data on the bus) or alternatively times out. The bus cycle was observed to
occur normally, leaving SSYN and the correct data (including a correct bit 13) asserted on the UNIBUS.</p>
<p>Proceeding to micro-location 326, we see that the A-mux should be set up there to admit the data from the
UNIBUS to the main processor data path and then the B-register should be latched for display. Here a problem
was apparent. Sheet DPD of the GT40 engineering drawings covers bits 15:12 of the data paths; package E015
there is an 8266 2x4 mux which implements that slice of the A-mux. E015 was seen via logic probe to be set up
with correct select codes and correct input from the UNIBUS. UNIBUS bit 13 was not being correctly passed on
to its corresponding output, however -- a failed part.</p>
<p><img style="display:block; margin-left:auto; margin-right:auto" src="/images/pdp11/GT40-bad-amux.png" title="KD11-B AMUX 15:12"/></p>
<p>The 8266 is out of production and somewhat rare; for the time being a functioning 8266 was "borrowed" from a
spare GT40 data paths board that we obtained from our fellow collector. Removed the bad part, socketed, and
replaced with the borrowed part, and the bit 13 display problem was fixed!</p>
<p>Moving next to the run/step problem, the machine was seen to be hanging up in micro-state F-3, after
initiating the DATI bus cycle to fetch an instruction. This lead to investigation of some of the the bus
control logic, as detailed on sheet CONC of the engineering drawings:</p>
<p><img style="display:block; margin-left:auto; margin-right:auto" src="/images/pdp11/KD11-B-DATI-bus-control.png" title="GT40 DATI bus control logic (excerpt)"/></p>
<p>The CPU must negotiate for control of the UNIBUS and assert BBSY if successful. Here I could see the DATI
request being successfully latched, but BBSY assertion was blocked at E014 by CONC NPR GRANT H, a
non-processor request (DMA) bus grant. Sure enough, some more probing indicated the the processor had issued
a NPR grant because it was reading an NPR request over the UNIBUS. Where was that coming from with nothing
else in the system?</p>
<p>Well, it turns out in the GT40 the near-side bus termination is integrated onto the M7014 GT40 bus control
board that must but in slot 3, so you can't really debug without this card in place! (It <em>could</em> be that an
additional M930 terminator in 3-A,B would work, as in a stock 11/05, but I haven't checked the backplane wire
list in detail to be certain of this.) In any case, slotted in the M7014, and the machine began to behave
much more rationally with a properply configured bus...</p>
<p>Went for broke and slotted in the rest of the display interface boards and (why not?) the core memory and DL11
as well. The machine was showing very promising signs of life. The terminal emulator in the bootstrap ROM
ran and was able to render recevied characters on the display! Characters typed on the keyboard were also
successfully forwarded out the DL11. A line feed character typed to the terminal emulator seemed to crash it,
so that still needed to be looked into. Took the time to toggle in a small test program from the user guide,
and this executed correctly rendering a square on the display, indicating most of the logic in the display
interface boards was also functioning correctly:</p>
<p><img src='/images/pdp11/GT40-good-sign_thumbnail_tall.jpeg' title='First sign of end-to-end life on the GT40: terminal emulator boostrap running, and rendering received characters.' onclick='pswipe("pdp11",111);'/>
<img src='/images/pdp11/GT40-square_thumbnail_tall.jpeg' title='GT40 display list processor running, rendering a square.' onclick='pswipe("pdp11",112);'/></p>
<p>The toggle-in program running above:</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</pre></div></td><td class="code"><div class="highlight"><pre><span></span><span class="nt">000100</span> <span class="nt">012706</span> <span class="nt">000500</span> <span class="nt">START</span><span class="o">:</span> <span class="nt">MOV</span> <span class="p">#</span><span class="nn">500</span><span class="o">,</span><span class="nt">R6</span> <span class="o">;</span> <span class="nt">SETUP</span> <span class="nt">STACK</span>
<span class="nt">000104</span> <span class="nt">012737</span> <span class="nt">002000</span> <span class="nt">172000</span> <span class="nt">MOV</span> <span class="p">#</span><span class="nn">TABLE</span><span class="o">,@</span><span class="p">#</span><span class="nn">DPC</span> <span class="o">;</span> <span class="nt">START</span> <span class="nt">VT11</span> <span class="nt">ON</span> <span class="nt">TABLE</span>
<span class="nt">000112</span> <span class="nt">000001</span> <span class="nt">DONE</span><span class="o">:</span> <span class="nt">WAIT</span> <span class="o">;</span> <span class="nt">LET</span> <span class="nt">NPR</span> <span class="nt">HAPPEN</span>
<span class="nt">000114</span> <span class="nt">000776</span> <span class="nt">BR</span> <span class="nt">DONE</span> <span class="o">;</span> <span class="nt">KEEP</span> <span class="nt">WAITING</span> <span class="nt">IF</span> <span class="nt">INTERRUPTED</span>
<span class="nt">002000</span> <span class="nt">117124</span> <span class="nt">TABLE</span><span class="o">:</span> <span class="p">.</span><span class="nc">WORD</span> <span class="nt">POINT</span><span class="o">+</span><span class="nt">INT4</span><span class="o">+</span><span class="nt">LPOFF</span><span class="o">+</span><span class="nt">BLKOFF</span><span class="o">+</span><span class="nt">LINE0</span>
<span class="nt">002002</span> <span class="nt">000500</span> <span class="nt">000500</span> <span class="p">.</span><span class="nc">WORD</span> <span class="nt">500</span><span class="o">,</span> <span class="nt">500</span>
<span class="nt">002006</span> <span class="nt">110000</span> <span class="p">.</span><span class="nc">WORD</span> <span class="nt">LONGV</span>
<span class="nt">002010</span> <span class="nt">040200</span> <span class="nt">000000</span> <span class="p">.</span><span class="nc">WORD</span> <span class="nt">200</span><span class="o">+</span><span class="nt">INTX</span><span class="o">,</span> <span class="nt">0</span>
<span class="nt">002014</span> <span class="nt">040000</span> <span class="nt">000200</span> <span class="p">.</span><span class="nc">WORD</span> <span class="nt">0</span><span class="o">+</span><span class="nt">INTX</span><span class="o">,</span> <span class="nt">200</span>
<span class="nt">002020</span> <span class="nt">060200</span> <span class="nt">000000</span> <span class="p">.</span><span class="nc">WORD</span> <span class="nt">200</span><span class="o">+</span><span class="nt">INTX</span><span class="o">+</span><span class="nt">MINUS</span><span class="o">,</span> <span class="nt">0</span>
<span class="nt">002024</span> <span class="nt">040000</span> <span class="nt">020200</span> <span class="p">.</span><span class="nc">WORD</span> <span class="nt">0</span><span class="o">+</span><span class="nt">INTX</span><span class="o">,</span> <span class="nt">200</span><span class="o">+</span><span class="nt">MINUS</span>
<span class="nt">002030</span> <span class="nt">160000</span> <span class="nt">002000</span> <span class="p">.</span><span class="nc">WORD</span> <span class="nt">DJMP</span><span class="o">,</span> <span class="nt">TABLE</span>
</pre></div>
</td></tr></table>
<p>Tried to get some program uploads going over the built-in binary loader in the bootstrap terminal emulator,
but this didn't seem to be quite working, either. Took a short break for dinner, returned to examine this
further, ran for a few minutes, then disaster... Something in the CPU let go, and the machine was once
again unable to execute code.</p>
<p>Digging in on this new failure a little, when attempting to single step ROM code from the front panel, the
PC was seen to increment by +1 instead of the expected +2; this resulted in an immediate bus error that
halted the machine. Back in goes the KM11, then, and the same microcode stepping technique was used to
begin investigating.</p>
<p>So how does the KD11-B (ostensibly) increment the PC by 2? It turns out this is done by selecting the PC (SPM
location 7) onto the ALU A-leg, constant +1 on the ALU B-leg, and introducing the additional +1 at the carry
input of the least significant bit slice of the ALU on sheet DPA of the engineering diagrams:</p>
<p><img style="display:block; margin-left:auto; margin-right:auto" src="/images/pdp11/KD11-B-plus-2.png" title="KD11-B ALU least-significant slice"/></p>
<p>Signal CONF CIN H comes from microcode, wire-or'd with output of operation decode ROMs in the ALU aux control
circuitry. In this case, the logic probe revealed that this signal was erroneously low; further investigation
revealed that microcode PROM CONF E094 had failed:</p>
<p><img style="display:block; margin-left:auto; margin-right:auto" src="/images/pdp11/KD11-B-CONF-E094.png" title="KD11-B faile microcode PROM CONF E094" width="75%"/></p>
<p>Alright, this is an IM5603 (equiv. 82S126N) bipolar PROM, and I don't happen to have that in stock. So now
we're stuck until we can source one. At this point, the day job once again intervened, and I needed to
prepare to head off to the Rubin Observatory in Chile for a couple of weeks. Scott came by to pick up the
work in progress; had time to share a short demonstration of microcode debug techniques, then off to pack and
prepare for my trip...</p>
<p>[ to be continued... ]</p></div>
<hr />
</div>
<div class='article'>
<div class="content-title">
<a href="https://fritzm.github.io/apple-power-lang.html"><h1>Apple II Plus: power supply and language card</h1></a>
Mon 21 March 2022
by <a class="url fn" href="https://fritzm.github.io/author/fritz-mueller.html">Fritz Mueller</a>
</div>
<div><p>Okay, so the Apple II Plus I was using to test the VM4209 monitor worked fine for about a half hour, then
smoked a RIFA cap in its power supply. These are a very common known failure in various old microcomputer
power supplies, and I really should have already caught this on inspection and shotgunned it. Boy, do they
generate a lot of smoke and stink when they go...</p>
<p>Electrolytics in here are also all pushing 40 years at this point and Astec opted for only 85C parts for many
of these, so I went ahead and ordered a <a href="https://console5.com/store/apple-2-power-supply-cap-kit-p-n-605-5703-astec-aa11040b-aa11040-b.html">whole replacement
kit</a> from
Console5. I replaced the front end filters and anything on the back end that was 85C or looked even slightly
bulgy, which ended up being most of them:</p>
<p><img src='/images/micros/apple-ii-rifa_thumbnail_tall.jpeg' title='Blown RIFA capacitor from Apple II Plus power supply' onclick='pswipe("micros",5);'/>
<img src='/images/micros/apple-ii-pwr-before_thumbnail_tall.jpeg' title='Apple II Plus power supply before cap replacements' onclick='pswipe("micros",6);'/>
<img src='/images/micros/apple-ii-pwr-after_thumbnail_tall.jpeg' title='Apple II Plus power supply after cap replacements' onclick='pswipe("micros",7);'/></p>
<p>Put it all back together and back in business, except noticed an additional problem: DOS 3.3 booted but
neither recognized nor loaded the "language card" (soft ROM) present in the machine. Since my machine has
Applesoft BASIC in system ROM, this meant no Integer BASIC (and no ROM mini-assembler) for me until this was
fixed.</p>
<p>For those who might not be familiar with the Apple II language card, it provides several features. An Apple
II or II Plus can have at most 48K of RAM on the system board. The overall memory map looks like this:</p>
<style>
.memmap {
font-family: monospace;
width: 30em;
margin-left: auto;
margin-right: auto;
margin-top: 1rem;
margin-bottom: 2rem;
border-collapse: true;
}
.memmap td {
border: 1px solid black;
padding: .5em;
text-align: center;
}
</style>
<table class="memmap">
<tr><td>$0000-$BFFF</td><td>RAM (48K)</td></tr>
<tr><td>$C000-$CFFF</td><td>IO space (4K)</td></tr>
<tr><td>$D000-$FFFF</td><td>ROM (12K)</td></tr>
</table>
<p>The first thing the language card provides is a 2K ROM which by default overlays whatever ROM is in the system
board socket for addresses <code>$F800</code> to <code>$FFFF</code>. This ROM holds the 6502 reset vector and the boot monitor; the
version provided on the language card has an "autostart" capability that will search for and boot off an
attached Disk II floppy. I am not sure why Apple provided this ROM on the language card since the same ROM
could be upgraded directly on the fully-socketed system board, and indeed everything after the Apple II Plus
came with this autostart ROM pre-installed. Possibly this was done for maximum backward compatibility with
Apple's previously-offered "Firmware Card", which also contained this ROM? Third-parties would later offer
clones of the language card that did <em>not</em> contain the additional/redundant F8 ROM, and nobody seems to have
particularly cared or noticed...</p>
<p>The second thing the language card provides is an additional 16K of RAM. This can be loaded, then
write-protected and mapped over the entire ROM space of the machine from <code>$D000</code> to <code>$FFFF</code>, providing a "soft
ROM" capability. Since the available ROM address space is only 12K, the leftover 4K or RAM on the language
card is bank switchable at address range <code>$D000</code> to <code>$DFFF</code>.</p>
<p>Advanced software which doesn't depend on the system ROMs at all can also map the RAM over the system ROM
address space and leave it in read/write mode, thus gaining access to a full 64K of RAM (with the caveat of
the switched bank at <code>$D000</code>.)</p>
<p>The language card programming interface presents as follows:</p>
<p><br><img style="display:block; margin-left:auto; margin-right:auto" src="/images/micros/apple-ii-lang-controls.png" title="Apple II language card control codes"/><br></p>
<p>My goal is to be able to run the initial (1980) release of Apple DOS 3.3. This version loads up the language
card at boot in soft ROM mode with Integer BASIC and an older version of the F8 monitor ROM, which contains a
few extra niceties like a built in mini-assembler and primitive step/trace capabilities. A system so loaded
can then be conveniently switched back and forth between BASIC and monitor versions with the DOS "INT" and
"FP" commands. But detection of my language card seemed to be failing, so it was never loaded up at boot.
Attempts to manually load and activate it also came to naught.</p>
<p>So, time to dig in and see what's going wrong... DOS 3.3 does initial checks and setup of the language card
via a small machine language program, loaded into RAM at boot by the DOS master disk's <code>HELLO</code> BASIC program.
Machine code is used for this part rather than BASIC so the probe/setup code can be placed and run from RAM
outside the mapping range of the language card (the BASIC interpreter itself running from ROM addresses
<em>within</em> this mapping range). Here is the machine language program, after being <code>POKE</code>d into RAM by <code>HELLO</code>,
listed via the ROM monitor:</p>
<div style="text-align: center"><img style="display:inline-block" src="/images/micros/dos33-hello-1.jpeg"
title="DOS 3.3 language probe, part 1/2"/> <img style="display:inline-block"
src="/images/micros/dos33-hello-2.jpeg" title="DOS 3.3 language probe, part 2/2"/></div>
<p>I interpret the actions of this code as follows:</p>
<ul>
<li>
<p>The code first retrieves and stashes the contents of location <code>$E000</code>, within the mappable address range. A
read of <code>$C081</code> then maps the ROMs on the system board (see programming interface above), and the contents
of <code>$E000</code> are checked again. If the contents now differ, the code assumes the card, now in mapped ROM
mode, was previously in mapped RAM mode, and it jumps to address <code>$0332</code> to put things back the way it found
them and bail out.</p>
</li>
<li>
<p>If not, the code reads from address <code>$C083</code> twice, which puts the card, if present, in writable mapped RAM
mode. Two different values are written to and compared back from location <code>$D000</code>. If a language card is
<em>not</em> present, this location will still be mapped to ROM on the system board, and at least one of these
compares will fail; if either one does, the code jumps to <code>$0332</code> to bail out.</p>
</li>
<li>
<p>Otherwise, we've verified that a card is present and wasn't already in active play. The program now reads
from address <code>$C081</code> twice to move back to mapped ROM mode, but leaving RAM writable to be loaded by the
remainder of the <code>HELLO</code> program after return (in this mode, reads will come from system ROMs, but writes
will go to the corresponding locations in language card RAM). A success return code is loaded, and the code
jumps forward to the exit code at <code>$0334</code> to return to the caller.</p>
</li>
<li>
<p>The bail out routine at <code>$0332</code> just sets up a fail return code, then falls through to <code>$0334</code>. Code here
stores the return code to the return code location and does one last compare between the stashed and current
values at <code>$E000</code> to determine if mapped RAM mode must be restored; if so this is done via a read from
location <code>$C080</code> (RAM is left write-protected). Control is then returned to BASIC.</p>
</li>
</ul>
<p>In any case, the above is what the code <em>does</em>, even if I may have misinterpreted some of its motivations. On
my system, the ROM on the language card seemed to be working correctly (monitor ran fine, but if ROM on
language card was pulled the machine failed to boot, indicating the monitor was in fact running successfully
out of ROM on the card). However, mapped RAM mode seemed never to engage. The machine code snippet above
returned "00" without crashing, and the DOS <code>HELLO</code> program assumed no card present. Manually accessing the
appropriate control registers also had no effect.</p>
<p>The language card design does not seem to be documented in detail, but a schematic is available and it is not
too hard to suss out. The first thing to check would seem to be the register interface. Here is an excerpt
from the schematic, with a couple of annotations added:</p>
<p><br><img style="display:block; margin-left:auto; margin-right:auto" src="/images/micros/apple-ii-lang-schem.png" title="Apple II language card schematic excerpt"/><br></p>
<p>The register interface is principally implemented by a 74LS175 quad flip-flop at D4. These flip-flops share a
common reset at power-on, and a common clock based on the expansion slot DEV_L signal; DEV_L is a
slot-specific signal strobed by the system on any bus cycles to IO address space allocated to that slot.
Examination of the programming interface along with address line decodes feeding the D inputs here leads to
the conclusion that the top-most flip-flop holds RAM/ROM mapping mode, the next one down is RAM bank select,
the next is RAM write-enable, and the last is a one-bit count to support write-enable after only two
successive reads.</p>
<p>Put a chipclip on at D4, and observed behavior of the flip-flops on the logic analyzer while exercising the
control registers via the monitor. Problems were apparent right away: while the bank select and count
flip-flops were responding as expected, the mapping mode and wite-enable flip-flops were not. The shared
reset and clock appeared correct, and all flip-flops themselves were responding logically correctly with
respect to their inputs. The issue was apparently with the incoming D lines to two of the flip-flops.
Starting with the ROM/RAM enable flip-flop, then, that D line is fed via C3 and C4. And a visual inspection
in preparation for clipping these up for the analyzer revealed that, surprisingly, these two chips had
actually been reversed on the board!</p>
<p>The language card is fully socketed, so presumeably this reversal had occured during previous troubleshooting
or service by the former owner? In any case, it was easy to swap the chips back to their correct locations,
and the logic analyzer showed that the entire register interface seemed to be behaving according to design
after that. DOS 3.3 now recognized the card at boot (yay!), but the system would crash after loading and
mapping the RAM. So, maybe a bad RAM chip as well?</p>
<p>To troubleshoot the RAM, I followed a technique described in <a href="https://www.youtube.com/watch?v=wVUWaodwNNI&t=1309s">this
video</a> on the "Adrian's Digital Basement" YouTube
channel. Basically, a couple short machine language programs, entered and executed via the monitor, to copy
ROM contents into the language card RAM, then copy back out to another location in system RAM. This allows a
comparison of source data in ROM and round-tripped data in system RAM; a mismatch indicates a RAM problem on
the card. Here are the two programs I used and, and dumps of the resulting data:</p>
<div style="text-align: center">
<img style="display:inline-block" src="/images/micros/apple-ii-copy-in.jpeg" title="Copy ROM to language card RAM"/>
<img style="display:inline-block" src="/images/micros/apple-ii-copy-out.jpeg" title="Copy language card RAM to system RAM"/>
<img style="display:inline-block" src="/images/micros/apple-ii-data-comp.jpeg" title="ROM data vs round-trip language card data"/>
</div>
<p>And sure enough, it's quite visible here that bit 7 is having problems. Swapped out the 4116 at A2, and
that seems to have done it for this one. Now I need to go find a copy of Choplifter...</p>
<p><img src='/images/micros/apple-ii-lang-card_thumbnail_tall.jpeg' title='Apple II Plus language card repairs: yellow indicates two chips that were found swapped on the card; red indicates a failed 4116 RAM chip that was replaced.' onclick='pswipe("micros",8);'/>
<img src='/images/micros/apple-ii-repaired_thumbnail_tall.jpeg' title='Apple II Plus: Successful DOS 3.3 boot after language card repairs' onclick='pswipe("micros",9);'/></p></div>
<hr />
</div>
<div class='article'>
<div class="content-title">
<a href="https://fritzm.github.io/vm4209.html"><h1>Sanyo VM4209</h1></a>
Sun 13 March 2022
by <a class="url fn" href="https://fritzm.github.io/author/fritz-mueller.html">Fritz Mueller</a>
</div>
<div><p>Some time back I purchased a Sanyo VM4209 B&W video monitor on eBay. Sold as working, it arrived with
apparently working horizontal but no vertical deflection. The price had been right, however, so it was just
shelved into the repair queue.</p>
<p><br><img style="display:block; margin-left:auto; margin-right:auto" src="/images/micros/vm4209.png" title="VM4209 video monitor"/><br></p>
<p>I now have a few DEC VT series terminals to work on and would like to have a small video monitor available on
the bench for this, so I pulled down the VM4209 to give it a look. Given the lack of vertical deflection, the
first thing to check would be the vertical deflection power transistors, Q105 and Q106 here:</p>
<p><br><img style="display:block; margin-left:auto; margin-right:auto" src="/images/micros/vm4209-vert-schem.png" title="VM4209 vertical deflection"/><br></p>
<p>It turns out these transistors are quite well buried in the guts of the monitor on a small aluminum heat sink.
Took a while to work my way in to them, and required unsoldering a few leads and removing the CRT:</p>
<p><img src='/images/micros/vm4209-crt_thumbnail_tall.jpeg' title='VM4209: CRT' onclick='pswipe("micros",0);'/>
<img src='/images/micros/vm4209-chassis_thumbnail_tall.jpeg' title='VM4209: chassis with CRT removed' onclick='pswipe("micros",1);'/>
<img src='/images/micros/vm4209-bottom_thumbnail_tall.jpeg' title='VM4209: underside of main board' onclick='pswipe("micros",2);'/>
<img src='/images/micros/vm4209-vtrans_thumbnail_tall.jpeg' title='VM4209: vertical deflection heat sink, with Q106 replacement' onclick='pswipe("micros",3);'/></p>
<p>Sure enough, the lead connecting Q106 collector to ground had been broken, and the part tested bad. Q105
appeared healthy, and there were no other apparent signs of distress in the surrounding circuitry. Q106 is an
out of production 2SB474 germanium PNP in the less common TO66 package; I opted to replace it with the
"modern" equivalent NTE226. Re-assembled, and was greeted immediately with a functioning raster. Pulled out
an Apple II Plus to test with:</p>
<p><img src='/images/micros/vm4209-appleii_thumbnail_tall.jpeg' title='VM4209: repaired, with Apple II Plus' onclick='pswipe("micros",4);'/></p>
<p>This was quite fun for a short while, until a RIFA cap in the Apple II power supply let go, filling the dining
room with acrid smoke. So, expect an additional article on that one in the near future :-)</p></div>
<hr />
</div>
<div class='article'>
<div class="content-title">
<a href="https://fritzm.github.io/rt11-basic.html"><h1>BASIC-11 under RT11</h1></a>
Sun 15 August 2021
by <a class="url fn" href="https://fritzm.github.io/author/fritz-mueller.html">Fritz Mueller</a>
</div>
<div><p>I figured it might be fun to play around a little bit with BASIC-11 under RT11 on the newly-restored
PDP-11/34. If I got that working, it could also be included on the RK05 RT11 disk image that I use regularly
for demos on the larger PDP-11/45.</p>
<p>The first thing to do was to find a compatible disk image and get it running under simh. Bitsavers had
<code>BASIC-11_V2.1_RX02.DSK.zip</code>, which would seem to fit the bill, but the contained image would not mount
successfully on simh's RY device. Looking through a dump of the image, there was an apparent "RT11A"
signature, so that looked promising. Tried <code>putr</code> under dosbox as well, but it would hang mounting the image.
So, off to the cctalk mailing list for some advice...</p>
<p>Glen Slick on the list first noticed a file size discrepancy:</p>
<blockquote>
<p>That BASIC.DSK image file has a size of 486,400 bytes. I don't know where that size would come from.</p>
<p>A physical RX-02 floppy should have a sector size of 256 bytes, with 26 sectors per track, and 77 tracks,
which would be a total of 512,512 bytes, or 505,856 bytes if the first physical track is ignored.</p>
<p>Indeed, the other RX-02 floppy images available here do have a size of 505,856 bytes:
http://www.bitsavers.org/bits/DEC/pdp11/floppyimages/rx02/</p>
<p>Hmm, maybe that BASIC.DSK image file was created by something that only copied the initial allocated logical
sectors and ignored unused logical sectors at the end of the floppy, and maybe PUTR doesn't handle disk
image files that are not the expected full size?</p>
<p>Example of padding the 486,400 byte BASIC.DSK image file to a size of 512,512 bytes on a Windows system:</p>
<div class="highlight"><pre><span></span>FSUTIL FILE CREATENEW BLANK 26112
COPY /B BASIC.DSK+BLANK TEST.DSK
C:\PUTR>DIR TEST.DSK
Volume in drive C has no label.
Volume Serial Number is 14CE-1A29
Directory of C:\PUTR
08/11/2021 12:55p 512,512 TEST.DSK
C:\PUTR>PUTR
PUTR V2.01 Copyright (C) 1995-2001 by John Wilson <[email protected]>.
All rights reserved. See www.dbit.com for other DEC-related software.
COPY mode is ASCII, SET COPY BINARY to change
(C:\PUTR)>MOUNT RX: TEST.DSK /RX02 /RT11 /RONLY
(C:\PUTR)>DIR RX:
Volume in drive RX is RT11A
Directory of RX:\*.*
11-Aug-2021
BSOT0D.EAE 12 04-Apr-1983
BSOT0S.EAE 10 04-Apr-1983
BSOT1D.EAE 9 04-Apr-1983
BSOT1S.EAE 6 04-Apr-1983
BSOT0D.EIS 12 04-Apr-1983
...
</pre></div>
</blockquote>
<p>...etc. Nice. Still no luck mounting under simh, though. Glen further offers:</p>
<blockquote>
<p>As far as I can tell by default PUTR expects to work with logical sector order RX-02 disk images that are
512,512 bytes in size. The BASIC-11 RX-02 disk image available here is in logical sector order, but is less
than 512,512 bytes in size: http://www.bitsavers.org/bits/DEC/pdp11/floppyimages/rx02/ PUTR appears to be
unhappy with the disk image unless it is padded to 512,512 bytes in size.</p>
<p>On the other hand as far as I can tell by default SIMH expects to work with physical sector order RX-02 disk
images. If I mount the logical sector order RX-02 disk image that works with PUTR in SIMH, then RT-11 gives
a "?DIR-F-Invalid directory" error. If I translate the logical sector order RX-02 disk image back into a
physical sector order disk image (dealing with track shifting, sector interleaving, and track to track
sector skewing) then RT-11 on SIMH is happy with the disk image.</p>
</blockquote>
<p>and:</p>
<blockquote>
<p>One bit of information that I found helpful as a reference when I looked at this quite a while ago was the
2.11BSD RX02 floppy disk device driver source code, which can be viewed online here:</p>
<p>https://minnie.tuhs.org/cgi-bin/utree.pl?file=2.11BSD/sys/pdpuba/rx.c</p>
<p>In particular, the routine rxfactr(), which as the comment says it calculates the physical sector and
physical track on the disk for a given logical sector.</p>
<p>I used that as a starting point to write a simple utility to read an RX-02 disk image file in logical sector
order and output an RX-02 disk image file in physical sector order.</p>
<div class="highlight"><pre><span></span><span class="cm">/*</span>
<span class="cm">* rxfactr -- calculates the physical sector and physical</span>
<span class="cm">* track on the disk for a given logical sector.</span>
<span class="cm">* call:</span>
<span class="cm">* rxfactr(logical_sector,&p_sector,&p_track);</span>
<span class="cm">* the logical sector number (0 - 2001) is converted</span>
<span class="cm">* to a physical sector number (1 - 26) and a physical</span>
<span class="cm">* track number (0 - 76).</span>
<span class="cm">* the logical sectors specify physical sectors that</span>
<span class="cm">* are interleaved with a factor of 2. thus the sectors</span>
<span class="cm">* are read in the following order for increasing</span>
<span class="cm">* logical sector numbers (1,3, ... 23,25,2,4, ... 24,26)</span>
<span class="cm">* There is also a 6 sector slew between tracks.</span>
<span class="cm">* Logical sectors start at track 1, sector 1; go to</span>
<span class="cm">* track 76 and then to track 0. Thus, for example, unix block number</span>
<span class="cm">* 498 starts at track 0, sector 25 and runs thru track 0, sector 2</span>
<span class="cm">* (or 6 depending on density).</span>
<span class="cm">*/</span>
<span class="k">static</span>
<span class="nf">rxfactr</span><span class="p">(</span><span class="n">sectr</span><span class="p">,</span> <span class="n">psectr</span><span class="p">,</span> <span class="n">ptrck</span><span class="p">)</span>
<span class="k">register</span> <span class="kt">int</span> <span class="n">sectr</span><span class="p">;</span>
<span class="kt">int</span> <span class="o">*</span><span class="n">psectr</span><span class="p">,</span> <span class="o">*</span><span class="n">ptrck</span><span class="p">;</span>
<span class="p">{</span>
<span class="k">register</span> <span class="kt">int</span> <span class="n">p1</span><span class="p">,</span> <span class="n">p2</span><span class="p">;</span>
<span class="n">p1</span> <span class="o">=</span> <span class="n">sectr</span> <span class="o">/</span> <span class="mi">26</span><span class="p">;</span>
<span class="n">p2</span> <span class="o">=</span> <span class="n">sectr</span> <span class="o">%</span> <span class="mi">26</span><span class="p">;</span>
<span class="cm">/* 2 to 1 interleave */</span>
<span class="n">p2</span> <span class="o">=</span> <span class="p">(</span><span class="mi">2</span> <span class="o">*</span> <span class="n">p2</span> <span class="o">+</span> <span class="p">(</span><span class="n">p2</span> <span class="o">>=</span> <span class="mi">13</span> <span class="o">?</span> <span class="mi">1</span> <span class="o">:</span> <span class="mi">0</span><span class="p">))</span> <span class="o">%</span> <span class="mi">26</span><span class="p">;</span>
<span class="cm">/* 6 sector per track slew */</span>
<span class="o">*</span><span class="n">psectr</span> <span class="o">=</span> <span class="mi">1</span> <span class="o">+</span> <span class="p">(</span><span class="n">p2</span> <span class="o">+</span> <span class="mi">6</span> <span class="o">*</span> <span class="n">p1</span><span class="p">)</span> <span class="o">%</span> <span class="mi">26</span><span class="p">;</span>
<span class="k">if</span> <span class="p">(</span><span class="o">++</span><span class="n">p1</span> <span class="o">>=</span> <span class="mi">77</span><span class="p">)</span>
<span class="n">p1</span> <span class="o">=</span> <span class="mi">0</span><span class="p">;</span>
<span class="o">*</span><span class="n">ptrck</span> <span class="o">=</span> <span class="n">p1</span><span class="p">;</span>
<span class="p">}</span>
</pre></div>
</blockquote>
<p>An RX02 image shuffled into physical sector order generated by Glen and suitable for use with simh is
attached <a href="https://fritzm.github.io/PHYS.zip">here</a>.</p>
<p>Jerry Weiss further suggested that the original, logically ordered image may work as is under simh if attached
as an MSCP device rather than RX02. This turns out also to be the case:</p>
<blockquote>
<blockquote>
<p>On Fri, Aug 13, 2021 at 9:46 AM Jerry Weiss wrote:<br>
Could you attach logical sector (block?) image as MSCP disk in SIMH? Other than some minor image
manipulation for removing track 0 if present, is there any reason this would not be readable?</p>
</blockquote>
<p>Hmm, it didn't occur to me to try that. Mounting the logical sector order RX-02 disk image, without any
modification necessary, as a raw MSCP disk does indeed appear to work!</p>
<div class="highlight"><pre><span></span>sim> ATTACH RQ1 BASIC.DSK
RQ1: 'BASIC.DSK' Contains RT11 partitions
1 valid partition, Type: V05, Sectors On Disk: 950
sim> SHOW RQ1
RQ1 486KB, attached to BASIC.DSK, write locked
RD54, UNIT=1, autosize
RAW format
.DIR DU1:
BSOT0D.EAE 12 04-Apr-83 BSOT0S.EAE 10 04-Apr-83
BSOT1D.EAE 9 04-Apr-83 BSOT1S.EAE 6 04-Apr-83
BSOT0D.EIS 12 04-Apr-83 BSOT0S.EIS 9 04-Apr-83
BSOT1D.EIS 9 04-Apr-83 BSOT1S.EIS 6 04-Apr-83
BSOT0S.FIS 7 04-Apr-83 BSOT1S.FIS 6 04-Apr-83
...
</pre></div>
</blockquote>
<p>...etc. Armed with the above, I was able to get BASIC-11 into an RT11 image in the Unibone card, and running
on the new PDP-11/34. Here's output from the <a href="https://rosettacode.org/wiki/Mandelbrot_set#DEC_BASIC-PLUS">DEC BASIC mandelbrot
program</a> at rosetta code:</p>
<p><img src='/images/pdp11/basic-mandel-output_thumbnail_tall.jpeg' title='BASIC-11 Mandelbrot program on a PDP-11/34, program output' onclick='pswipe("pdp11",103);'/>
<img src='/images/pdp11/basic-mandel-list_thumbnail_tall.jpeg' title='BASIC-11 Mandelbrot program on a PDP-11/34, program listing' onclick='pswipe("pdp11",104);'/></p></div>
<hr />
</div>
<div class='article'>
<div class="content-title">
<a href="https://fritzm.github.io/unibone.html"><h1>Unibone</h1></a>
Wed 24 March 2021
by <a class="url fn" href="https://fritzm.github.io/author/fritz-mueller.html">Fritz Mueller</a>
</div>
<div><p>I have been keeping an eye on Jörg Hoppe's interesting <a href="http://retrocmp.com/projects/unibone">Unibone project</a>
for some time -- it is a general-purpose Unibus device emulator and diagnostic tool, built around a
<a href="https://beagleboard.org/black">BeagleBone Black</a> compute module running embedded real-time Linux. The
PDP-11/34 restoration project finally provided enough impetus for me to pull the trigger on getting one.</p>
<p>Sent Jörg an email to order a kit, which arrived some weeks later complete with bundled BeagleBone. The kit is
pretty well thought-out and was enjoyable to put together. Had to throw in a few of my own pin headers and
jumpers to complete the assembly. The only other small confusions were a few of the resistor packs which did
not match the schematic (Jörg informed me these are non-critical values.)</p>
<p>The kit did not include card handles. I decided to try having some 3D printed by Shapeways, using their
"processed versatile plastic" process, which is a laser sintered nylon, color dyed and smoothed. I used a
card handle model by Vince Slyngstad found <a href="https://so-much-stuff.com/pdp8/cad/3d.php">here</a>. The results
were nice, sturdy, and dimensionally correct. The chosen "purple" color is a rather intense magenta in real
life. Not exactly cheap for just a couple parts, but I had been wanting to try their print service.</p>
<p><img src='/images/pdp11/unibone-kit_thumbnail_tall.jpeg' title='Unibone: unassembled kit' onclick='pswipe("pdp11",100);'/>
<img src='/images/pdp11/unibone-handles_thumbnail_tall.jpeg' title='Unibone: 3d printed handles' onclick='pswipe("pdp11",101);'/>
<img src='/images/pdp11/unibone-assembled_thumbnail_tall.jpeg' title='Unibone assembled' onclick='pswipe("pdp11",102);'/></p>
<p>The Unibone has all sorts of capabilities, and proved itself <em>very</em> useful during the '11/34 restoration:</p>
<ul>
<li>
<p>Ability to bus master to probe the Unibus address space and run diagnostics on memory found there. This was
very useful for debugging the memory card that came with the -11/34 and sussing out its undocumented
configuration switch settings.</p>
</li>
<li>
<p>Ability to directly load and execute MAINDEC diagnostics, without needing a functioning console emulator or
storage subsystem. This is a convenient and speedier alternative to PDP11GUI.</p>
</li>
<li>
<p>Subsequently, the ability to emulate entire storage subsystems, very useful for loading and running full
operating systems on this -11/34 which otherwise has no storage of its own.</p>
</li>
</ul>
<p>The Unibone goes in a quad SPC slot; I opted for slot 9 on the -11/34, and this entailed removing the NPG
jumper on the backplane there to allow the Unibone to bus master. The device worked well straight-away after
assembly.</p>
<p>There are, alas, a couple small frustrations with the current design:</p>
<ul>
<li>
<p>It is desireable to configure the Unibone and backplane to allow the Unibone to bus master and interrupt.
However, this leaves grant chain(s) open at boot until the Unibone's own embedded software can boot and take
control of the card (which takes on the order of a minute or so). During this time the host system is
non-functional or may hang, and it needs to be subsequently reset (this reset can be scripted from the
Unibone, but all of this does significantly increase end-to-end boot time of the machine). It would be nice
if the Unibone had something like some normally-closed relays on the grant chains, to preserve grant
continuity until control is actively assumed.</p>
</li>
<li>
<p>It would be desireable to be able to power the embedded BeagleBone in isolation, in place in a
system, without having to having to have the entire host system powered at the same time (e.g. for
maintenance of the Unibone's embedded software stack, maintenance of locally stored storage system media
images, etc.) There is a relay on the Unibone which switches in Unibus power when available, but
unfortunately, the design is such that if the BeagleBone is also externally powered the relay remains
engaged when the host system is shut down. This could lead to the BeagleBone trying to power then entire
Unibus via its 5V supply/connector, which could obviously be problematic... For now it seems best just to
pull the card in order to run it in isolation, which is a little less than convenient.</p>
</li>
</ul>
<p>That said, the designs and software are open source, and the card comes with some generous prototyping areas
built right in, so some mods to address these issues could be a fun project. All in all, Jörg has put
together a fantasically useful bit of kit, and I'm certainly glad to have it in my toolbox!</p></div>
<hr />
</div>
<div class='article'>
<div class="content-title">
<a href="https://fritzm.github.io/1134.html"><h1>PDP-11/34</h1></a>
Tue 09 March 2021
by <a class="url fn" href="https://fritzm.github.io/author/fritz-mueller.html">Fritz Mueller</a>
</div>
<div><p>This spring I worked on repair/restoration of a friend's PDP-11/34. The system was in fairly good shape, but
missing a few bits and pieces and with the usual sorts of issues for 45-year-old kit. Started per usual with
disassembly, cleaning, and inspection. The BA11-K chassis was in pretty decent shape; just a few scratches
requiring some sanding and a little touch-up paint to inhibit future corrosion.</p>
<p>Date codes on the chassis and CPU cards are from 1976, but other components in the chassis are a bit of
mix-and-match (a KY11-LB console interface and a third-party Monolithic systems memory board date from 1981,
and a DL11-W SLU/RTC card is from 1977). Serial number is 2001. There is also a sticker for "OHIO NUCLEAR",
which was an <a href="https://en.wikipedia.org/wiki/Technicare">early manufacturer of CT devices</a>.</p>
<p><img src='/images/pdp11/1134-serial_thumbnail_tall.jpeg' title='PDP-11/34: serial number tag' onclick='pswipe("pdp11",88);'/>
<img src='/images/pdp11/1134-chassis-sticker_thumbnail_tall.jpeg' title='PDP-11/34: BA11-K chassis sticker dating the system to 1976' onclick='pswipe("pdp11",89);'/>
<img src='/images/pdp11/1134-ohio-nuclear_thumbnail_tall.jpg' title='PDP-11/34: partial sticker for 'Ohio Nuclear' -- manufacturers of CT systems' onclick='pswipe("pdp11",90);'/></p>
<p>Foam problems here were limited to a decayed air pre-filter at the front of the chassis and some padding on
the cable retaining bar at the rear. A heat gun and a paint scraper are your friend for removing the leftover
cellophane adhesive strips that were used to secure the foam. For the replacement pre-filter, I opted for 3M
Filtrete carbon pre-filter sheet (part FAPF-UCTF2PAMZ) which comes in sheets large enough to cover the front
of the chassis and is easily cut to size with scissors.</p>
<p>The front panel brackets ended up being a bit of a puzzle to reassemble -- I unfortunately failed to pay close
attention to how exactly the lower fasteners were configured during disassembly. Most of the wisdom out in
the restoration community seems to pertain to a newer, and much more convenient, version of these brackets (or
the ones that arrived on this system were mismatched?) Here's a picture of the brackets that I have, and a
shot of the arrangement I finally opted for for the flange-blinded mounting hole at the bottom of the chassis:
machine screws driven from the back of the bracket with Keps nuts toward the front. I also added some 1/8"
nylon spacers so the pre-filter could be extended across the entire front of the chassis, behind the brackets,
and everything still remains square when tightened up. A serviceable replacement power knob was tracked down
<a href="https://www.millsupply.com/knob-fan-speed-grumman-olson-53777.php?p=324629">here</a>.</p>
<p><img src='/images/pdp11/1134-brackets-2_thumbnail_tall.jpg' title='PDP-11/34: BA11-K front panel mounting bracket' onclick='pswipe("pdp11",91);'/>
<img src='/images/pdp11/1134-brackets-3_thumbnail_tall.jpeg' title='PDP-11/34: BA11-K front panel mounting detail, with nylon spacers to make room for pre-filter' onclick='pswipe("pdp11",92);'/>
<img src='/images/pdp11/1134-brackets-4_thumbnail_tall.jpeg' title='PDP-11/34: Front panel mounted with replacement air pre-filter in place behind brackets and replacement power knob' onclick='pswipe("pdp11",93);'/></p>
<p>The BA11-K chassis has an integrated H765 power supply. The power-controller unit was in pretty good shape,
but I replaced the line cord since the old one had some fairly serious nicks in its outer jacket. Also
replaced cap C1 (50uF) which seemed to be drifting off value. Replaced the .1uF across-the-line caps mounted
on the power transformer with modern X2 safety caps. The DC regulator modules (2x H744 +5V and 1x H745 -15V)
were disassembled and cleaned. Reformed all the large electrolytics, then load tested the reassembled
regulators individually. Nothing out of sorts here except the usual replacement of burnt out incandescent
indicator bulbs.</p>
<p><img src='/images/pdp11/H765-power-controller_thumbnail_tall.jpeg' title='PDP-11/34: H765 power controller module cleaned with new line cord' onclick='pswipe("pdp11",94);'/>
<img src='/images/pdp11/H765-transformer_thumbnail_tall.jpeg' title='PDP-11/34: H765 power supply main transformer, with modern X2 safety caps (orange) installed' onclick='pswipe("pdp11",95);'/>
<img src='/images/pdp11/H744-load-test_thumbnail_tall.png' title='PDP-11/34: Load testing an H744 DC regulator module; 'scope displays switching waveform' onclick='pswipe("pdp11",96);'/></p>
<p>I filled out the system with a near-side M9301 bootstrap-terminator (recent eBay purchase), some G727 "knuckle
buster" grant continuity cards, and an M9302 SACK turnaround far-side terminator. New on this restoration was
a <a href="http://retrocmp.com/projects/unibone">UniBone Linux-to-Unibus bridge</a>, used to emulate storage devices
among other things (more on this in a separate article soon). Checked/adjusted NPR continuity on the
backplane (continuity wire wraps in place for all slots except slot 9, to accommodate the UniBone). Module
utilization as follows:</p>
<style>
.module-utilization {
font-size: smaller;
width: 50em;
margin-left: auto;
margin-right: auto;
margin-top: 1rem;
margin-bottom: 2rem;
border-collapse: true;
}
.module-utilization th {
padding: .5em;
font-weight: normal;
}
.module-utilization tr:first-child th {
width: 16.67%;
}
.module-utilization td {
border: 1px solid black;
padding: .5em;
text-align: center;
}
.module-utilization td:empty {
background-color: LightGray;
}
.module-utilization tr:first-child td:first-child {
border: none;
visibility: hidden;
}
</style>
<table class="module-utilization">
<tr><td></td><th>A</th><th>B</th><th>C</th><th>D</th><th>E</th><th>F</th></tr>
<tr><th>1</td><td colspan=6>M7266 CPU control</td></tr>
<tr><th>2</td><td colspan=6>M7265 CPU data path</td></tr>
<tr><th>3</td><td colspan=2>M9301 boot term</td><td colspan=4>M7859 console</td></tr>
<tr><th>4</td><td colspan=6>Monolithic Systems 303-0158 64 KiB memory</td></tr>
<tr><th>5</td><td colspan=2></td><td colspan=4>M7856 serial / line clock</td></tr>
<tr><th>6</td><td colspan=3></td><td colspan=1>G727</td><td colspan=2></td></tr>
<tr><th>7</td><td colspan=3></td><td colspan=1>G727</td><td colspan=2></td></tr>
<tr><th>8</td><td colspan=3></td><td colspan=1>G727</td><td colspan=2></td></tr>
<tr><th>9</td><td colspan=2>M9302 SACK term</td><td colspan=4>UniBone</td></tr>
</table>