On Tue, 24 May 2016, william degnan wrote: There are some nice clean photos in that presentation. So, it was binary with some hexadecimal addressing. I like the slide entitled "How to test Machine Language Using a Program Listing Using Toggle Switches". That's pretty hard core. I'm surprised they didn't at least use component displays with LEDs to show the values rather than reading it straight off some blinkenlights. Maybe those weren't around yet or were too expensive. -Swift

On Tue, 24 May 2016, Charles Anthony wrote: Holy rocker switch, Batman! Is that all for one machine? That looks like a man-machine interface to run a nuclear power plant or something. FOUR panels. The black panel looks uber-cool. That definitely looks like something from a 60's or 70's James bond film. There needs to be a villain about ready to launch a missile standing next to one. Oh and here is a replica of an Apollo launch computer with a component LED display like I was mentioning: http://i.imgur.com/bbXZVcx.jpg ... probably too expensive to embed in a computer system, but still hard to beat for geek aesthetics. -Swift

Those aren't LED's on the Apollo display. They are EL's (Electro Luminescent displays). Each segment of each digit was controlled by a relay. They astronauts eventually got use to the tinkling sound of the relays. In fact the entire console panel of the command module was a giant EL, covered mostly in gray paint except where switch legends were needed. ELs were highly reliable and dim-able. Unfortunately they required a relatively high voltage (22 volts or so) which is why relays were needed to control the display segments on the computer readouts. I'm surprised no one has mentioned the control panel of the IBM 360/91: https://en.wikipedia.org/wiki/IBM_System/360#/media/File:360-91-panel.jpg Marc On Tue, May 24, 2016 at 9:54 AM, Swift Griggs <swiftgriggs at gmail.com> wrote:

On Tue, May 24, 2016 at 12:58 PM, Swift Griggs <swiftgriggs at gmail.com> wrote: Those were typically vacuum fluorescent (VFD).

On 05/24/2016 12:18 PM, Brent Hilpert wrote: You still see them in military/aerospace applications. Planar used to be industry leader in those, but it was acquired a couple of years ago by a Finnish outfit, Beneq. The business unit is called Lumineq: http://lumineq.com/ Thin-film EL displays are pretty cool. They're transparent. Like all modern EL displays, they're pre-patterned with display elements. --Chuck

On Tue, 24 May 2016, Brent Hilpert wrote: Ha! I was looking at that and I said to myself "This looks like something that'd have been at NASA during the Apollo missions on some old newsreel." Then @2 seconds later I see one of the photos has a banner in the background saying... "NASA". -Swift

The IBM 1800 was a much simpler machine than the IBM 360/370, yet it had a pretty complex front panel - http://www.dvq.com/1800/photos/paneln.JPG ... since not all of the registers could be displayed at the same time . ----- Original Message ----- From: "Paul Berger" <phb.hfx at gmail.com> To: cctalk at classiccmp.org Sent: Tuesday, May 24, 2016 10:18:45 AM Subject: Re: Front panel switches - what did they do? On 2016-05-24 1:54 PM, Swift Griggs wrote: The most impressive one I ever saw was when I was in technician school we had a tour of the underground in North Bay Ont. where we saw what was probably the last running AN/FSQ-7, the operator panel was very impressive. Some of the early 370 systems that still had blinkenlights only had one or two rows and rotary switchs selected what you where viewing. Attached to the switch there was a cylinder behind the panel that showed a legend of what the lights meant for the selected location. The also had hex dials on the panel for data input. Paul.

Swift Griggs wrote: It's much easier to tell if you have a stuck bit (data or address) with simple LEDs. This was (and is) a real possibility in old machines. Trying to watch for patterns of HEX or OCT digits to provide the same info would be really tough. Bill S.

It was thus said that the Great Swift Griggs once stated: Work with binary, octal and/or hexadecimal enough, and you'll learn how to sight read binary patterns. The conversion is pretty simple: OCTAL HEX - - - 0 - - - - 0 - - * 1 - - - * 1 - * - 2 - - * - 2 - * * 3 - - * * 3 * - - 4 - * - - 4 * - * 5 - * - * 5 * * - 6 - * * - 6 * * * 7 - * * * 7 * - - - 8 * - - * 9 * - * - A (or 10) * - * * B ( 11) * * - - C ( 12) * * - * D ( 13) * * * - E ( 14) * * * * F ( 15) So a byte value of * - - * - * * - is hexadecimal 96. On Octal, it wold be 226. -spc (I'll leave he decimal value to the reader)

On Tue, 24 May 2016, Jon Elson wrote: How long did it usually take to do it? Uhh, ouch! That'll learn ya! You'd better be a careful coder, then I guess. Sheesh. Man, it seems so elementary now. Everything had to be invented sometime, I suppose. It seems like that'd make working with computers a lot more "intentional" if you know what I mean. Hmm, so not as cool as 60's and 70's TV and movies seemed to suggest. Still at least it did happen. :-) Heh, my grandmother was a Cobol programmer on IBM 360s for Western National Gas (now Diamond Shamrock). She had mixed feelings about them, but she said they had a decent development environment vis-a-vis some of the competition at the time. Hmm, yeah, I seem to remember some similar style lights on old TEAC reel-to-reel audio gear from that era, too. Those multi-position switches are really cool. They remind me more of avionics style controls (which always seem to be the nicest physical gear in terms of build quality). -Swift

I don't think I ever used a PDP-5, but I did, back in the late '70s, use some HP rackmount machine with lighted buttons for front-panel switches and a manually-entered bootstrap. I got good at entering its bootstrap, to the point where the limiting factor was speed of moving my fingers between switches; once the code was memorized, dexterity was the limiting factor for speed. (I don't remember how long the bootstrap was; I think it was something like six or eight instructions. Probably something like "set DMA address and source sector in disk controller, tell disk controller to read, wait for completion, jump to loaded code". Probably only some five or ten seconds to enter.) /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML mouse at rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B

On Tue, May 24, 2016 at 9:44 AM, Swift Griggs <swiftgriggs at gmail.com> wrote: Definitely. Several OSes would show distinctive 'idle' patterns on the lights, this provided a quick visual cue about system load for the big multi-user systems. As I understand it, the Transputer (an early multicpu system designed to parallel computation had a simple buf effective display -- an LED for for each CPU indicatiing if the CPU was working or idle, this told you at a glance if you parallelization algortihim was effective. -- Charles

It was thus said that the Great Swift Griggs once stated: The Amiga has a minimal debugger embedded in the ROM that ran over the serial port (9600 8n1). It would automatically become active when a Guru Meditation (similar to a Unix kernel panic, or the Mac bomb, or the Windows Blue Screen of Death) but you could get to it at other times as well (I played around with it a bit). The debugger is *very* minimal (hex dumps of memory and registers, you could modify memory and registers, resume, etc). The original Connection Machine had one LED per CPU (max 65,536). You could get some pretty impressive visuals out of that one. -spc

On Tue, 24 May 2016, Sean Caron wrote: Heh, that would be when the sales girls come walking through doing client tours on Fridays while one of us geeks is doing service under the raised floor. Stunning views. j/k ;-P That reminds me of this MIT hack: https://www.youtube.com/watch?v=OnCNGNv-Fds -Swift

On Tue, May 24, 2016 at 9:44 AM, Swift Griggs <swiftgriggs at gmail.com> wrote: Hah. Video of some toggling in a bootstrap... https://www.youtube.com/watch?v=iIsZVqhaneo -- Charles

On 25/05/2016 5:06 AM, Paul Anderson wrote: I used to work on DEC systems of all types, loved the PDP-11, cause you could get right into it, not like VAX, which was huge and almost incomprehensible. I wrote button-in test programs as needed, below is a useful address checker, mostly used on instals, found bad switches giving wrong addresses. Used a similar one to trap vector addresses, find the wrong ones. I/O PAGE ADDRESS LISTER PROGRAM ------------------------------- 1000 012706 001000 MOV #1000, SP 1004 012737 001054 000004 MOV #TRAP,@#4 1012 012700 002000 MOV #2000,R0 1016 010001 MOV R0,R1 1020 005020 LOOP: CLR @(R0)+ 1022 020027 006000 CMP R0,#6000 1026 001374 BNE LOOP 1030 012700 160000 MOV #160000,R0 1034 005710 LOOP1: TST @(R0) 1036 010021 MOV R0,@(R1)+ 1040 062700 000002 LOOP2: ADD #2,R0 1044 020027 177776 CMP R0,#177776 1050 001371 BNE LOOP1 1052 000000 HALT 1054 022626 TRAP: CMP @(R6)+,@(R6)+ 1056 000770 BR LOOP2 THIS PROGRAM USES TRAP TO 4 ON UNIBUS TIMEOUT TO FIND ALL VALID UNIBUS ADDRESSES ON THE SYSTEM UNDER TEST. THE LIST OF ADDRESSES WILL BE STORED IN A TABLE COMMENCING AT LOCN 2000. THERE ARE SOME LARGE BLOCKS OF ADDRESSES WHICH SHOULD NOT BE PRINTED OUT. eg. 165000-165776 173000-173776. TO IDENTIFY THE ADDRESSES LISTED, SEE THE BACK PAGES OF THE PERIPHERAL HANDBOOK. SAMPLE RESULT:- SOUTHDOWN PRESS 11/24 OAKLEIGH 11/70 160200-160376 ???? 160120-160126 DZ11 160770-160776 AD01? 165000-165776 BOOT DIAGS 164200-164376 ???? 170200-170376 U/BUS MAP 165000-165776 BOOT DIAGS 172202-172376 SUPER PAR/PDR0-7 170200-170376 U/BUS MAP 172440-172476 RH70/TM03/TE16 172100 MS11-P CSR 172516 MMR3 172300-172316 KERNEL PDR 173000-173776 BOOT DEVICES 172340-172356 KERNEL PAR 176700-176752 RH70/RP06 172516 MMR3 177546 LINE CLOCK 173000-173776 BOOT DEVICES 177560-177566 CONSOLE 176500-176506 DL11 177570 SWR 176700-176746 EMULEX SC21 177572-177576 MMR0,1,2 177546 KW11-L 177600-177616 USER DATA PDR0-7 177560-177566 CONSOLE 177620-177636 USER INS PDR0-7 177572-177576 MMR0,1,2 177640-177656 USER INS PAR0-7 177600-177616 USER PDR 177660-177676 USER DATA PAR0-7 177640-177656 USER PAR 177740-177752 MEMORY REGS 177734-177736 LMA LO/HI WORD 177760-177776 CPU REGS 177766 CPU ERR REG 11/23 SYSTEM EXAMPLE:- --------------------- 172300-172316 MEM MAN KERNEL PDR 172340-172356 MEM MAN KERNEL PAR 172516- MMR3 173000-173776 BOOT DEVICES 176500-176526 DLV11-J (3 PORTS) 177170-177172 RXV21 177546 KWV11-L 177560-177566 DLV11-J (CONSOLE) 177572-177576 MMR0,1,2 177600-177616 MEM MAN USER PDR 177640-177656 MEM MAN USER PAR Lionel. *

On 28/05/2016 11:27 AM, Paul Anderson wrote: Hi Paul, and others You have stimulated me to drag out a couple more useful programs - basic stuff, I used them to demo to students, and get them started. Also the practical side to check console printers and screens. I have retired, and left these systems behind, but they were marvellous gear. CONSOLE OUTPUT PROGRAM ---------------------- 012737 000104 177566 A: MOV #104, OUTPUT 012700 100000 MOV #100000, R0 005300 B: DEC R0 001376 BNE B 000770 BR A THIS PROGRAM OUTPUTS A CHAR TO THE CONSOLE. THE REGISTER CAN BE CHANGED TO TEST ANOTHER DEVICE. KEYBOARD ECHO TEST ------------------ 105737 177560 LOOP: TSTB @#177560 100375 BPL LOOP 013700 177562 MOV INPUT,R0 010037 177566 MOV R0,OUTPUT 000770 BR LOOP THIS PROGRAM WAITS FOR A KEY DOWN, THEN OUTPUTS IT BACK TO THE TERMINAL PRINT BUFFER. FULL DISPLAY EXERCISER ---------------------- 013700 177562 START: MOV @#177562,R0 012701 000124 MOV #80,R1 105737 177564 A: TSTB @#177564 100375 BPL A 010037 177566 MOV R0,@#177566 005301 DEC R1 001371 BNE A 105737 177564 B: TSTB @#177564 100375 BPL B 012737 000015 177566 MOV #15,@#177566 105737 177564 C: TSTB @#177564 100375 BPL C 012737 000012 177566 MOV #12,@#177566 000750 BR START THIS PROGRAM MONITORS KBD IN AND REPEATS THE CHARACTER TO THE SCREEN UNTIL THE NEXT KEY IS PRESSED. TO TEST LA36 ETC LINE 2 READS 012701 000204 MOV #132, R1 TO DISABLE CACHE - SLOWS PROGRAM DOWN ------------------------------------- 012737 000014 177746 MOV #14, CCR 000137 XXXXXX JMP @ A ( XXXXXX IS A: ADDRESS) Lionel.

On 05/24/2016 11:34 AM, William Donzelli wrote: The early PDP-11s had a diode matrix ROM for the boot memory. You could change the boot code with a wire cutter and soldering iron. Jon

On Tue, May 24, 2016 at 9:56 AM, Swift Griggs <swiftgriggs at gmail.com> wrote: Wirewrap is solderless. https://upload.wikimedia.org/wikipedia/commons/thumb/3/35/Wire_Wrapping.jpg… Very good for prototyping, automated wirewrapping was for some production. -- Charles

On 5/24/16 10:44 AM, Chuck Guzis wrote: stitch wire you spot weld to a socket post

On Tue, May 24, 2016 at 1:08 PM, Chuck Guzis <cclist at sydex.com> wrote: Multiwire?

On Tue, May 24, 2016 at 3:28 PM, Chuck Guzis <cclist at sydex.com> wrote: The last COMBOARD product, for VAX BI used a similar technology from Augat called "Unilayer" - it was a bunch of wires autorouted from the netlist and stuck together and applied as a "mat" on each side of a perfboard with plated-through holes and tacked down at each via/wire junction, then small machine pin inserts were stuffed into the vias that became the sockets. We did it because of the 10-layer requirements of VAX BI and the costs of spinning up such a thick board in the early 1990s. Augat had a VAX BI "blank" and we sent them our layout and netlist and got back a stack of boards. They were expensive, but for the size of run we did, it was cheaper than the setup costs for our own PCB, and guaranteed to be compliant in the "BI Corner" which was essential for success. We sold a few. I still have the remainder of the run. Unless one needs a 68010 with some local RAM and a Z8650 SIO as a VAX peripheral, they are mostly a curiosity. I ported our HASP and 3780 products to it, but we never had any customer demand for SNA for VAX BI, so that never happened. So if not Multiwire, perhaps Unilayer. They are similar but visibly distinguishable. -ethan

We bought a Multiwire job on our clone of the Microdata 1600 and the tech it used, I think, was welded wires laid in muck that was soft. They would fab up a firm carrier board with all the thru-holes set, then put down a soft pliable layer of epoxy(??). They would weld one of the wires to an appropriate thru-hole then the wire would be pushed into the media and routed to the terminus. Similar to wirewrap process from the routing requirements (keep number of connections to any post / thruhole adhering to design rules). But when it was complete, you could see all the wires thru the goo they used after it hardened or was set up. The set we had worked well, but was about 3500 bucks for an approximately 8 x 10 board with a 130pin edge card connector. Kinda pricy. However, if you had a working design, it was overnight turnaround with a PC. thanks Jim On 5/24/2016 12:15 PM, Eric Smith wrote:

On 05/24/2016 02:15 PM, Eric Smith wrote: No, multiwire is a process where lots of wires are laid down on a PC board coated in uncured epoxy. When all the wires are in place, the epoxy is cured in an oven. Then, the board is CNC drilled, and the through-holes are plated. The wires are what is normally called "magnet wire" with an enamel coating, so they don't short to each other. Drilling through the wires leaves the end bare copper, so the plating process connects to all wires that pass across where the hole is drilled. It is quite amazing that it works at all! The one downside is that rework of the boards, as in replacing chips, is a VERY delicate operation. Jon

On 05/24/2016 02:33 PM, Brent Hilpert wrote: YUP!!! THAT'S IT! Even the wires are yellow, as I remember them! The system was made by AMP. Jon

On 05/24/2016 01:22 PM, Al Kossow wrote: No, there was another system made by AMP. The backplane connectors had rectangular posts, about .030 x .050" or something. You had rolls of stranded wire, maybe about 26 Gauge. There was a "gun" that had a roll of little metal clip (or maybe it was a stick-like magazine) that wrapped almost completely around the posts. So, you stuck the end of the wire into a notch in the gun and pressed the gun down onto the post and squeezed the grip. A mechanism would break the clip off the strip or roll and push it down onto the post, shearing the insulation off the wire and trapping it against the post. it was actually faster than wire-wrap. I think there was a way to do bussed wiring with it, so you just made a little loop of wire and went snap-snap-snap over the rows of posts. You could put 4 or 5 wires on a post easily, too. There was a special tool that would hook the clip and pull it off, when changes were needed. I also can't remember the name of this system. A big piece of gear, two or 3 relay racks full of boards, was built using this at a VERY prior place of employment, so that was in 1969. Jon

On 05/24/2016 11:00 AM, jwsmobile wrote: ...and the "transformer" ROS used on the 360/40 (and others). --Chuck

On Tue, May 24, 2016 at 12:25 PM, Paul Koning <paulkoning at comcast.net> wrote: IBM's TROS and Core Rope Memory use the same principle, but the physical construction is significantly different. Core rope memory was very labor-intensive to manufacture, while TROS was not.

On 2016-05-24 4:13 PM, Chuck Guzis wrote: The CROS cards used in a 360/30 where the same size as an 80 column card on purpose so you could you a keypunch machine to program the microcode.

On 2016-05-24 7:44 PM, Chuck Guzis wrote: Yes mylar with copper tracks keypunch was used to cut tracks as required. Paul

On 05/25/2016 12:41 PM, Lawrence Wilkinson wrote: The Mylar cards were VERY thin. I always assumed they were attached to a slightly thinner than usual paper card for punching, then separated from the paper to put into the ROS system. That picture you linked to is the best photo I've seen of a /30 ROS card! Jon

On 05/24/2016 02:13 PM, Chuck Guzis wrote: And the 360/25 had all writeable control store. The control store was just the top 16 KB of main core memory! To change emulators, restore from a microprogram crash, etc. you loaded the emulator from a card deck! Jon

On 05/24/2016 09:29 PM, Chuck Guzis wrote: For sure! The 360/30 was an 8 BIT machine, 8-bit memory, 8-bit data paths, etc. Really hobbled the performance, and restricted the peripherals that could be attached. The models /22 and /25 had 16-bit memory and data paths. Jon

On 05/24/2016 11:47 PM, Chuck Guzis wrote: No, the 360/20 was a 16-bit ISA, somewhat compatible with the 360 layout, but not really a 360. All registers were 16-bit, only 8 registers, lots of differences. But, EVEN the 360/20 had a 16-bit memory and data paths. The /20 had no channels, there were only 4 device types that could be directly attached to the built-in controllers. The 360/30 was a full 360 implementation (16, 32-bit registers, floating point was available as an option), but the underlying hardware was 8-bit wide. The 1130 was for a totally different market, the /20 was intended for very specific uses in 360 shops, and maybe as an entry-level "foot in the door" to move totally tab card shops into the 360 family. The only /20s I ever saw were used as offline spool printers and card readers in large 360 shops. Jon

On 05/25/2016 09:01 AM, jwsmobile wrote: According to WikiP, IBM leased over 7,000 of the 20s, so that would make it a contender for volume--I doubt that half as many 1130s were sold. Anecdote time. A Chicago-area manufacturer of fans and blowers used the usual (for the time), collection of unit-record equipment for their accounting and inventory needs. It worked well and the operation was pretty much a one-person setup. The president of the company was visited by an IBM marketing guy who made said president's eyes go all glassy with the prospect of having a real computer and detailed reports being delivered to his desk every morning. So he installed a 20 with its (censored) "Mother Fletcher's Card Mulcher) and associated gear, which, I believe, included a 2311 and a printer. He also would up hiring 2 more people. He got nice thick reports delivered to his desk every morning, as promised, but found that he could get more information by (shudder) visiting the manufacturing floor and talking with the managers there. So the stacks of green-bar paper piled up, unread. He was later invited to an IBM shindig set up by marketing. During which, he approached a systems engineer and described his operation, leaving out the fact that he already had the 20 setup. The response adequate for many years for an operation his size. He was on the phone to IBM the next day, canceling the lease of the 20 and associated gear. ------ My bad experience with the Model 20 was based on my wanting to syntax check a small deck of assembly. I knew where a rarely-used 20 was hiding out. So, with a bit of help, we got the assembler loaded and ran my deck in. I was greeted with the printer spewing out error after error. You know, you might start off a S/360 program with something like: BALR 15,0 USING *,15 URP! BALR? Reg 15? --Chuck

On 05/25/2016 12:35 PM, Dave Wade wrote: I had no idea! I've programmed an 1130, but it seemed to be rather limited, but maybe that was what contributed to its popularity and low cost. Does that number also include the 1800? --Chuck

On Wed, May 25, 2016 at 08:35:33PM +0100, Dave Wade wrote: And we know salesmen would never, ever, lie. mcl

On 5/25/16 12:16 PM, Mike Stein wrote: is the guy in texas?

The 360 model 44, with the emulation option, is somewhat similar. The base machine had a trimmed down instruction set, shades of microVAX: no decimal or string operations. So you could not run OS/360. Instead, you had to run PS/44 (or some such name). Alternatively, you could get the emulation option. That added some extra memory and an emulation mode, where reserved instructions would trap to the emulator and get emulated there. So now you could run OS/360, and PL/I or COBOL applications (albeit quite slowly). The emulator was loaded, on those rare occasions where the memory got wiped, using the "Emulator IPL" button, from a binary card deck. That deck was pretty slick: it was a channel program loop. No CPU code involved at all; the first card was a 4 (?) entry channel program that would read the remaining cards, which were a standard assembler output (object deck). Self modifying channel code: since each object card contained the address and length for its data, the channel program would pick up those two fields and drop them into the third channel command, which would transfer that number of bytes to that address. paul

On 2016-May-24, at 11:39 AM, Eric Smith wrote: We were discussing this last year, perhaps I'm being pedantic but I would note that while, as you say, there is commonality of principle in use of induction and the selective weave to represent the data, TROS and core rope (of the sort used in the AGC) also have differences in their principles of operation - they're not just physical variations on each other.

On 2016-May-24, at 1:49 PM, Eric Smith wrote: Yes, I examined this in some detail last year after mention on the list, and wrote it up: http://www.cs.ubc.ca/~hilpert/e/corerope/index.html The short of it is, schemes like TROS are using simple induction / transformer principles with a selective weave through the transformer cores to represent the data. In contrast, (AGC-style) core ropes are using switching cores and core-logic principles to also do the 1-of-n address decoding within the cores. The address decoding requires a varied weave of address wires through the cores, in addition to the selective weave for the data. The read/access operation also becomes far more complex for the AGC-style core rope.

Agreed! I'm going to have to study the training manual for the EL-X1 in more detail, because it describes how its ROM core memory works, and it doesn't seem to be an exact match of either of the ones in Brent's document. Since it goes back to 1958 it seems to be the oldest example, so it's worth digging out the details. paul

On 2016-05-24 9:30 PM, Eric Smith wrote: IBM TROS see United States Patent US3432830, If you have access to old issues of the IBM Journal of Research and Development there is apparently an article in the September 1964 issue. Other control stores used in early 360s was BCROS this is a capacitive memory using 2 capacitors for every bit, this is not the design used in the 360/30 but was used in higher end machines because it was faster. There is an article describing this control store in IBM Journal of Research and Development July 1968. The 360/30 used what is called CCROS it is described in a March 1966 IBM Journal of Research and Development IBM Journal of Research and Development scans are available on IEEE Explorer. There is also a breifer description of all three in the book "IBM's 360 and Early 370 Systems" beginning on page 210. Paul

On 05/24/2016 11:56 AM, Swift Griggs wrote: Here's some wire-wrap. And, yes, you did need to change the wire wrapping on some systems to configure different options. http://pico-systems.com/stories/1982.html But, the DEC diode ROM boards were printed circuit boards with a matrix of diodes diagonally connecting between vertical traces (on one side of the board) and horizontal on the other. Diodes were removed to change zeroes to ones. (or vice versa.) Here's a homebrew one: http://www.wintergroundfairlands.com/2013/10/visualizing-roms-1-diode-matri… Jon

On Tue, May 24, 2016 at 9:34 AM, William Donzelli <wdonzelli at gmail.com> wrote: Yep. Later model models of the Honeywell 6180 replaced all of those display panels with a minicomputer that generated video terminal displays of the data. -- Charles

On 05/24/2016 12:17 PM, Paul Koning wrote: Actually, all PDP-11s I used had one set of switches, that could be used for address or data, as appropriate to the operation. So, the load address switch would load the address with 18, 22 or whatever address width that model had. Otherwise, all operations only used the lower 16 switches. The data switches were readable as one I/O register. When you read it, it reported the switches. When you wrote to it, some models could display it on the panel. These were used in some diagnostic programs. Jon