On Thu, Feb 28, 2008 at 9:40 AM, Josef Chessor <josefcub at gmail.com> wrote: That is a lot of switches, but didn't CDC (and other companies, I just thought of CDC first) make 60-bit and other large word-size machines, which I can only assume also had front panels? Sure, it may be annoying and impractical to have 128 switches, but it would be fun to make and play with. I guess if it comes down to it, I could just make one for the parallel port and figure out some way to interface it to various simulators... The biggest hurdle, I guess, would be figuring out how to interface it to the machine in a good way. The second biggest problem would be finding where to get that many identical switches and lights without bankrupting myself. John -- Ph'nglui mglw'nafh Cthulhu R'lyeh wgah'nagl fhtagn

On Thu, Feb 28, 2008 at 10:17 AM, Josef Chessor <josefcub at gmail.com> wrote: I just wonder how you'll connect it so that, without any kind of operating system, you can use the panel. If you want to go the serial or parallel route, just build the panel around some microcontrollers and it'll probably be nice... but only after you've brought up an OS with some appropriate drivers. I'm kinda thinking that modern PCs just aren't built to have front panels the way a PDP-8 did. Well, I should be able to get access to a metal shop at my university. It would be a fun design project, I think. If I ever design a computer from the ground up (senior design project?), it's definitely going to have a spiffy front panel. John -- Ph'nglui mglw'nafh Cthulhu R'lyeh wgah'nagl fhtagn

Jeff Davis wrote: That seems more achievable - although I think the OP wanted to control that actual PC, not a vintage emulator running on it. But yep, easiest route is probably to run linux/*BSD on a PC with no keyboard/mouse/display and then run the emulator on that. Hook the front panel into either a serial port (and use all the standard TTY access code for I/O access) or the parallel port (there's certainly support for userspace parallel port I/O in the Linux kernel - not sure about *BSD). How to actually merge that support into whatever emulator's running is another matter, but presumably most of them have reasonably sane code for the CPU and memory emulation. Maybe some sort of "generic front panel API" is useful - *most* FP's are probably pretty generic in what they do (even though the layout and number of switches/lights changes) cheers Jules

From: "Jeff Davis" <jdavis at soupwizard.com> OK, not to toot my own horn or anything, but Henk and I already did one of these. (The only thing we haven't done is to physically put the front panel and the PC in the same box.) You can go to http://www.pdp-11.nl/ and click "my projects" in the left panel to get an overview of some of the uses of the thing. (You have to click the little yellow folder to be allowed to drill down into the individual projects.) Henk, is there a better URL that specifically describes the Blinkenlight project? (I did some grunt work, but the idea was his.) Vince

If you guys are serious, I'd be happy to design a panel based on the specs you guys come up with. I can make it on my ShopBot quite easily. The electronics of course will still be up to you. :) g. -- Proud owner of F-15C 80-0007 http://www.f15sim.com - The only one of its kind.

Hi, have a look at my "PDP-11" front panel / console. Although I used a ?P (6809), the simple "protocol" is sufficient to drive the LEDs, read the switches and catch the toggles (momentary switches). Check out www.pdp-11.nl and browse to the "my projects" pages ... Patches in SIMH makes it a "98% full" operational PDP-11 console. At least, I can use the front panel to load a bootstrap and start RT-11 without touching the keyboard! I/O is easily expanded by using octal latches, otherwise you will run out of pins to LEDs/switches really fast. Count the required I/O for a "nice" front panel! I have bought from eBay (long ago) two front panels of the HP (IIRC 2113 and 2117). Never got the time to repeat the "trick" and run an HP in SIMH with a real front panel. - Henk

It was written.... *blink*

On 2/29/08, der Mouse <mouse at rodents.montreal.qc.ca> wrote: The answer, for me at least, is that it's so much more interesting than 1 button and 1 LED. Useful? Maybe not. But so far, they haven't ever taught me "Engineers must do only useful designs--fun is a sin", so I'm going to keep wanting a pretty blinkenlights board that I can play with. For now, at least, I think I'll look at ways of making something for the serial port that I could try using with SIMH or just some custom Linux software. I've just returned from the Computer History Museum, where I got a pretty good fix of huge beautiful control panels. SAGE was particularly interesting, as was WISC with the bullet holes, and of course the KL10 box. John -- Ph'nglui mglw'nafh Cthulhu R'lyeh wgah'nagl fhtagn

On 29 Feb 2008 at 15:53, Sridhar Ayengar wrote: Not nearly as impressive as seeing someone keypunch a boot loader without a crib sheet... Pat Finnegan wrote: That would explain why nobody wants to collect IBM 1401s--ugly drab gray with blue trim and very few blinkenlights. If, on the other hand, it was painted in shocking pink with chartreuse trim and acres of lights, it'd be a real collector's item... I understand now. :) Cheers, Chuck

Chuck Guzis wrote: Now, that might be a matter of personal preference. They're both impressive in their own way. It's the same knowledge, really. Peace... Sridhar

Hi My first computer had only a power switch and a reset. it was a Poly88. It had a great 1K monitor. It had a 8x8 memory display window, 8 byte dispaly for each register pair, ran the memory mapped video, had single step( in RAM only ) and ran the tape reader. It was a tight pack into 1k but they used a lot of tricks to compact the code. I still bought an IMSAI just to play with the switches and lights. It isn't as productive as the Poly but then it is just a hobby. Dwight _________________________________________________________________ Shed those extra pounds with MSN and The Biggest Loser! http://biggestloser.msn.com/

On 29 Feb 2008 at 22:46, Brent Hilpert wrote: You know, in my case, it wouldn't have helped. To this day, I remember inviting a member of the fair sex to my apartment to see my newly-assembled MITS 8800 happily running some blinkenlights program. Her reaction was devastating--"THAT'S NOT A COMPUTER--THAT'S A TOY!". Mencken was right. "How little it takes to make life unbearable: a pebble in the shoe, a cockroach in the spaghetti, a woman's laugh." Cheers? Chuck

As much as I like blinkenlights and rows of switches, I also have an appreciation for the 'blank monolith' or utilitarian cabinet style, for the contrast between the exterior simplicity and the complexity hidden within, imparting an element of mystery. I'm thinking of large old stuff here (perhaps like the 1401 Chuck mentioned), where you open it up and it's filled with rows and rows of little circuit boards, not a modern plain beige box where, once you open it up, you're met by another blank monolith in the form of a VLSI CPU chip. Digressing somewhat, in a fit of nostalgia my list of iconic aspects of computers would go something like: 1. blinkenlight panels 2. spinning open-reel vacuum-column tape drives 3. text in MICR font 4. punch cards 5. plugboards filled with a criss-cross maze of wires But I was a child in the 60's - those items were the popular/public face of computers in those days.

From: "Chuck Guzis": I think of blinkenlights as way ahead of a ROM with a debugger in it, and not for just the aesthetic reasons folks are talking about. It's a little like Tony's fondness for "things he can understand". When I use a front panel, there's no question what's going on in the hardware or what's in the register. The front panel is such a simple device there is no way for it to lie to me. No way is it going to miss my breakpoint and wander into the weeds, etc. I'm not acting through an intermediary -- I really am in control of the machine, and I'm seeing the real machine state. Later, this got stretched a bit. The actual workings of an IMSAI front panel leave some potential for strange things to happen, as what going on there is a little like a debugger activated by switches. At least you can really stop the machine, etc. Some of the 7-segment front panels with the microprocessor in them are stretching the point, too. There's a lot that can go wonky in those, that will make it look like things are going on in the CPU that aren't. But the classic wall-of-switches and lights was wired into the machine directly, and couldn't lie to you if it wanted to (except for the occasional burned out incandescent bulb :-)). I do use debuggers in core, of course, but I percieve that as a trade of ease-of-use vs knowing what's really going on. Vince

From: "Roy J. Tellason": Thanks :-). I'm speaking from memory, so I may have the details wrong, but what I remember is that the way the front panel works, is that the "Examine" key works (for example) is that it forces a "JMP xxxx" onto the CPU bus, then returns the CPU to the halted state, ready to fetch the new location. Of course, this only works if the CPU understands an 8080 JMP instruction, etc. My understanding is that other front panel functions were implemented by this sort of strategic lying to the CPU. That makes it a different beast than the front panels of old :-). Generally, I'm assuming working hardware, but want to see how the software went wrong. But whatever software I'm running is interacting with the hardware (device drivers or the sort of low level programs we wrote back then). Remember that those old machines didn't have a debugged operating system under them, with a virtualization or protection layer to catch them when they crashed and save their memory and registers. Most of the programs ran stand-alone and directly controlled relevant hardware resources. Vince

From: "Chuck Guzis" <cclist at sydex.com> I'm not talking about debugging hardware. I'm not really very good at that, so wouldn't presume to tell you which tools to use :-). We always assumed our machines were in good repair, and that the hardware was essentially perfect. (Our PDP-8's never contradicted us, either :-).) What I am saying is that, when debugging software, it is useful to be really sure about what is happening, an the front panels gave that reassurance, in a way that debuggers and emulators just don't. Since debuggers and emulators crash or malfunction, they don't mimic the underlying hardware perfectly, whereas the front panels gave visibility into the real thing. Sure. The fact that you ever had to grap a 'scope and read the P-counter seems to support my argument for real lights, not refute it :-). I don't claim they are useful in the long run. They are useful in certain difficult debug situations, similar to what is done nowdays with ICE. Vince

Chuck Guzis wrote: I suspect it has more to do with technology price-point. I couldn't have build an operating system for an unmapped Nova in 1974/5 without one; "program load" was an uncommon option on earlier versions of the later 800/1200 family and even then required the switch register in order to get the device code to use. Bigger iron had the option of dedicated supervisory processors, but I doubt that the "affordable" (i.e., low five figures) minicomputers of the early-to-mid 70s could have really managed that trick without breaking the bank. In my experience the front panel was also critical for figuring out what new and novel way the machine had broken. MTBF was measured in months, and while a machine might have been too sick to load diagnostics it's surprising how much could be learned by poking at it through the front panel with a scope handy. This proved true even in somewhat extreme cases, like the early S/200 with interleaved core in a memory expansion chassis that tended to fail pretty much any time the metal door to the machine room was opened or the 800 that we had to repair ourselves after the company with the maintenance contract refused to touch it (a current loop TTY with a hot chassis had worn through its data cable, dumped line voltage onto the loop, nuked the current loop/EIA converter, the mux, part of the bus interface on every board in the chassis and a chunk of both CPU1 and CPU2). -- Chris Kennedy chris at mainecoon.com AF6AP http://www.mainecoon.com PGP KeyID 108DAB97 PGP fingerprint: 4E99 10B6 7253 B048 6685 6CBC 55E1 20A3 108D AB97 "Mr. McKittrick, after careful consideration..."