-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathgt40.html
436 lines (388 loc) · 28.1 KB
/
gt40.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
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8">
<title>fritzm.github.io - GT40 Terminal</title>
<meta name="description" content="">
<meta name="author" content="Fritz Mueller">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<!-- Le HTML5 shim, for IE6-8 support of HTML elements -->
<!--[if lt IE 9]>
<script src="https://fritzm.github.io/theme/html5.js"></script>
<![endif]-->
<!-- Le styles -->
<link href="https://fritzm.github.io/theme/bootstrap.min.css" rel="stylesheet">
<link href="https://fritzm.github.io/theme/bootstrap.min.responsive.css" rel="stylesheet">
<link href="https://fritzm.github.io/theme/local.css" rel="stylesheet">
<link href="https://fritzm.github.io/theme/pygments.css" rel="stylesheet">
<!-- Photoswipe -->
<link rel="stylesheet" href="https://fritzm.github.io/theme/photoswipe.css">
<link rel="stylesheet" href="https://fritzm.github.io/theme/default-skin/default-skin.css">
<script src="https://fritzm.github.io/theme/photoswipe.min.js"></script>
<script src="https://fritzm.github.io/theme/photoswipe-ui-default.min.js"></script>
<script src="https://fritzm.github.io/galleries.js"></script>
<script type="text/javascript">
var pswipe = function(gname, index) {
var pswpElement = document.querySelectorAll('.pswp')[0];
var items = galleries[gname];
var options = { index: index };
var gallery = new PhotoSwipe(pswpElement, PhotoSwipeUI_Default, items, options);
gallery.init();
};
</script>
<!-- So Firefox can bookmark->"abo this site" -->
<link href="https://fritzm.github.io/feeds/all.rss.xml" rel="alternate" title="fritzm.github.io" type="application/rss+xml">
</head>
<body>
<div class="navbar">
<div class="navbar-inner">
<div class="container">
<a class="btn btn-navbar" data-toggle="collapse" data-target=".nav-collapse">
<span class="icon-bar"></span>
<span class="icon-bar"></span>
<span class="icon-bar"></span>
</a>
<a class="brand" href="https://fritzm.github.io">fritzm.github.io</a>
<div class="nav-collapse">
<ul class="nav">
</ul>
</div>
</div>
</div>
</div>
<div class="container">
<div class="content">
<div class="row">
<div class="span9">
<div class='article'>
<div class="content-title">
<h1>GT40 Terminal</h1>
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>
<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>