I so desperately wanted to get in on this novel personal computing thing, and I couldn't afford a computer. In 1976 I bought a book on machine and assembly language programming not knowing a thing from a bookstore on Wall St. somewhere. It was for the DEC PDP-11. I went through the first third or so of it with pencil and paper and put boxes on the side to show me the status of registers. Not productive, but not a waste of time. I then bought a Commodore PET in 1978 and the rest is history! That early exercise made it easy for me to learn 6502 assembly and work on the Vic-20, C64, C128, and PowerPC Macs.
Hey, this is not related to the original submission, but I just wanted to know what keeps someone like you (who's been interested in computers for much longer than I've been alive) going. It seems like it'd be very easy to tire of the industry/hobby after that long, I want to know what you're currently interested in and if you're comfortable sharing, what you're currently working on day-to-day in your job (if you're not retired by now).
Funny, but I took only a few jobs where coding was more than 50% of my day job, but for the most part I've held very eclectic jobs in a predominantly technical or artistic career.
I was reading about neural networks and genetic algorithms in the late 80s and programming in Lisp and C. Mark Watson's book (he's on HN)
"Common Lisp Modules: Artificial Intelligence in the Era of Neural Networks and Chaos Theory"
got me started in coding them rather than just reading the more academic tomes I read in the late 80s.
I am glad I didn't just focus on that then, although, I'd probably have more of a savings now and higher salary.
But not the adventures I managed to have by meeting people in all different types of jobs. And there's something about physical labor that calms me. Sitting at a desk all day seems so antithetical to actually living a life out in the real world and feeling the earth between your toes, the sun and wind on your body while taking in the green things around you!
I was dumpster diving and taking stepper motors out of dot matrix printers in the early 90s down on Wall street while working a 12 to 9 shift taking care of a VAX/VMS and Banyan Vines PC network for an environmental law firm. I used to write reports in Paradox, work on Concordance - a document management system - BRS search routines and queries. I used the steppers for my amateur robotics influenced by Rodney Brooks' subsumption architecture and Mark Tilden's BEAM stuff. I played Doom for the first time at that job!
I was an art handler (Brooklyn Museum), paintings conservator's assistant, 3D FX and animation on SGI intern using Prisms (now Houdini) at a NYC Ad agency/FX company, welder, machinist, CNC coder, technical diver and ropework technician (think IRATA/SPRAT), among the memorable items. I remember being one of the early funders for getting Blender3D open sourced way back when (2001/02), and writing a Python script to turn photos into wooden carvings back in 2002/03 with it on my CNC table. The software was based upon a paper by NASA about 'Shape from Shading'. it alsow churned out G-code for our table after downloading the client's file, and gave me an estimate of machine time and overall cost. This is before 3D printers, and tables used to be in the 6 figures, but this was an $8k 4 ft x 8 ft router table. My partner and I used it to cut out kayak designs we made out of 4 mm Okume plywood and the carvings I did in solid maple in bas relief. We did some urns for pets and pet cemeteries (really! http://thewoodenimage.com. Used to come up on the Wayback Machine without pics or other content). Sad to say, people loved our carvings at boat shows, etc., but nobody bought them. We had crowds at our table, but not a single purchase. Funny cemeteries were our market, and a gentlemen offered me money for the software to make bronze tombstone plaques from family photos!
I worked at a company as a sys admin, and did some coding in C, C#, Java, but mainly my strength was writing front ends for old Italian sheet metal punch machines and translating modern G-code into the 'Octo' machines' proprietary code. This was in C. Putting a temperature sensor in the server room, and have it ping a pager of me and the other sys admins.
I did Christmas display window animations for a display company in NYC as a welder and later as the head of their creative technologies. One Christmas (1996-7?). We had pneumatically operated 4 to 5 ft high Nutcrackers whose arms would go up with a bell in it if a child touched the window where there were five large buttons painted on the back of the window with a capacitive sensor behind it, a BasicStamp (think today's Arduino) running it, queuing the music and triggering the pneumatic valves. Remember right up until this, the internet and information from companies was not as accessible. I had to write letters, emails, and phone call for weeks.
I will probably never retire. I just put a deposit down on a live/work space to use my desktop cnc mill/lathe, 3D printer and electronics equipment (a CNC sewing/embroidery machine too).
I currently work at an engineering firm that specializes in stage machinery and anything entertainment-related. Because I don't code full-time for a living, I code up things in what works best for me and the company I work for. I write them in C, python, factor, J, forth, assembler (micros), and I play with a lot more PLs (Zig, Rust, Haskell, R/RStudio), but I am mainly sticking with C and J for now with Zig as a cross compiler. I avoid python, not because it isn't good or I don't like it, but it doesn't fit in with my preference for terseness and shedding bloat. I am having a renewed interest in C and assembler. I am getting older for some of the more physical work I did, so I am now coding more to try and see if I can make something of it.
I was working in Macau for 6-plus years for the The House of Dancing Water show up until the end of 2015. I have hundreds of technical dives working on hydraulics, air FX, and electrical systems under water. It is almost 10 m deep and was the world's largest commercial indoor pool!
Programming is not so much a career for me as it is simply a tool. The same for my electronics and metalworking experience, or any other skill. Critical thinking, problem solving, and knowing how to provide what's needed or desired are more important. I've always followed my heart or gut on what's next and it is landed me in a good place at my age. Follow your bliss to quote Joseph Campbell!
I have found getting certified in a skill like diving or ropework is not the point. It's what skills do you bring to the thing you dove or climbed to fix? Do you know hydraulics, basic electrical work, troubleshooting, etc. Learn those first. An old dive buddy of mine used to say you can teach a monkey to dive, but what can he do when he gets there? I need skilled people.
Also there are many types of technical diving: commercial diving and deep sea diving, wreck and cave diving, underwater welding, salvage, show divers (fairly new - since the show 'O' in Las Vegas - divers that escort performers underwater for water shows), and many more.
I can see how the PDP-11 would have been a great machine to ease you into 6502 assembler. We used an actual PDP-11 in my assembly class in college, long outdated even then, because it has a super clean architecture, and the assembly language reflected that.
Yes, and the book progressed very logically, and with little fluff or handholding. I struggled to work each exercise. I am not a fan of programming books that try and tell a story, or some other gimmick to involve you in learning. I think 6502 is cleaner than 8088 or later assembly, but that may be bias due to my early years! And you needed to know octal!
At LANL they put many experiments/sensors in the bomb stack.
A group I was with ran an experiment called PINEX (Pinhole Imaging Neutron Experiment), they used high speed video cameras to capture light/photons from a light intensifier. A meter diameter lead sphere was placed between the bomb and the light intensifier to attenuate the neutron signal. The length of the video cable (coax) was measured in time units.
They could get about a frame and half of video off the CCD and out of the bomb hole before everything was vaporized. The video was captured using analog-to-digital signal converters and then interpreted later. The ADC, memory, pulse generators (to trigger light intensifier, start the CCD sweep, etc.) were sitting in a CAMAC crate attached to a customized VAX. They even has a customized VAX and monitor to visualize or analyze the captured data. The captured frame would be rendered into a gray scale image of a concentric circles that meant something to the bomb physicists.
My intern project involved showing how the ridiculously expensive and fragile VAX setup could be replaced by a modern workstation running off the shelf software. Of course, this was not well received, that is why my mentor had me do the work and presentation - he would never have gotten away with it himself. No matter though, bomb testing was stopped soon enough.
BTW, this is article is not actually correct[1]. The technique is however. The measurement used an HP pulse generator to send a pulse down a piece of coax and that pulse, and the "echo" or return were both attached to Ch1 and Ch2 of an oscilloscope in the measurement trailer.
When a pulse was fired a Polaroid picture was taken of the screen at the same time. By measuring the difference between the leading edge of the initial pulse and the returning pulse the length of the cable could be computed. With a lot of pulse generators and oscilloscopes you could synchronize them to each fire slightly later than the next and get a number of solid data points on the cable being vaporized.
The Polaroids all included on the picture the rack and rack slot where they were located, and the sequencing was known, so you could digitize the pictures and extract the data.
[1] I actually worked in one of these trailers as part of a summer job during college writing code on said PDP 11/34.
Wow, that is awesome. I wish they had a picture from inside the trailer. Basically a Decwriter + PDP-11/34 at one end, and two back to back rows of 19" "telco" racks with scopes, pulse generators, and cameras.
I have a number of PDP11's (that escaped nuclear obliteration) and have the skills to keep your nuclear plant running until 2050 [0]. The instruction set is really worth studying to this day, and the fact it has both pre and post-increment/decrement surely informed the design of C (and its predecessors). So orthogonal a single instruction could replicate itself through memory:-
MOV (-PC),(-PC)
As the instruction counter (PC, AKA R7) auto-incremented on each instruction, that instruction first decrements the PC (so it points back to the current instruction) and then copies the contents of the memory location (i.e. the current instruction) to the next lower memory address. And since the PC has now been decremented twice, the operation can repeat until it hits somewhere without any physical RAM (as PDP-11's have a bus signal to tell them whether the addressed memory exists or not).
Also easy to program in octal; knowing that MOV is 01MRMR, addressing mode M is 4 for pre-decrement and R is the register number, no-one even needed an assembler to write that instruction as:-
014747
The ultra-regular ISA made it easy to learn and remember bootstraps, it'd just take a few passes along the toggle switches to key in a loader. It became rather easier with boot ROMs and serial terminals, e.g. on the LSI-11 just typing '173000G' was enough to bring up the system (back then I got to code a boot loader for 5" disk drives, 2 different 8" disk driver and a user interface with a prompt into 256 words of ROM).
Those were the days, my friend.
Funnily enough I booted one of the PDP's a few days ago and it wasn't even hard to remember op-codes learnt 40+ years ago.
"People often guess that they [ED. the increment and decrement operators] were created to use the auto-increment and auto-decrement address modes provided by the DEC PDP-11 on which C and Unix first became popular. This is historically impossible, since there was no PDP-11 when B was developed." The PDP-7 seems to have some features that might have played a role, albeit I don't think it's entirely clear from the document that they were the main reason for the existence of both prefix and postfix ++'<
That's interesting, as I'd assumed the BCPL/B/C progression happened alongside the PDP-7 to PDP-11 progression with the PDP-11 being the design that regularised things.
The full set of addressing modes uses 3 bits, thus 8 addressing modes. Using these addressing modes on the program counter (R7) gave a lot of flexibility and was how constants and memory were loaded and stored. It might sound complex but in practice was incredibly easy:-
mov #141,@#177566 ; Output 'a' to the terminal
That's a "MOV (PC)++,@(PC)++" instruction that loads the next word from memory (octal 141) and increments the PC and stores in the address given by the next word (after the constant, as the PC has just been auto-incremented) and finally autoincrements the PC again to leave it pointing to the next instruction. The layout in memory would thus be:-
Also related: G.I. Taylor who developed the theory of blast waves to the point where he could estimate yield from photographs published in newspapers, and wrote papers that published the classified yield of the first US nuclear tests.
Edit: His estimate was between 17 and 23 kilotons of TNT, the real yield was 22 kilotons.
> This remakrable achievement is often used as the setting-off point to explain dimensional analysis.
I was always a fan of dimensional analysis as it tickled "puzzle solving" aspect of my lizard brain, but if it were introduced via nuclear blast analysis in my classes I bet it would have grabbed a lot more attention.
I'm pretty sure this is apocryphal. It seems more likely that somebody used cables with TDR to measure yield at some point, and somebody noticed that the ethernet interfaces on their PDPs had similar equipment, and made a story that combined them.
There’s a lot of discussion here on how (or even whether) a ‘reflectometer’ (I had to look up what that even meant) works.
However, I’m more interested in the things I do understand, and in this case, my question is: considering the fact that there needs to be another (remote) computer to receive the readings, and considering that we’re speaking of processes that ‘degrade’ the cable dangling into the nuclear borehole at an alarming rate, just how does one go about performing an ordinary electrical transmission of data over those distant ranges in those minute times? The latencies are enormous and therefore clearly we’re not talking something like TCP and it’s three-way-handshake SYM/ACK kind of response.
And once the blast approaches the surface (assuming it doesn’t breach it)… is it sufficient for the computer to (comparatively) leisurely transmit its findings whilst it’s in the process of falling into the enormous crater that’s opening up beneath it? Can one presume that the power remains stable long enough for this to occur? (Assuming that the power supply has been destroyed and/or the cables jolted loose, how long does the machine “stay up whilst falling down”?)
...if the test happens deep enough to contain the explosion. But even an initially contained explosion may produce a crater later when the pressure in the created cavity drops and the cavity collapses.
To me, it’s just a depression (something shallow a computer cannot fall into), whereas the comment above made it sound like a pit (something deep it can fall into).
The crater may not be as colossal as I imagined, but the ground lifted a lot going out a long way. I’d imagine that anything with spinning disks would be quite sad even when quite far away.
"CORRTEX" is the magic word for finding details; thank you for that reply. (CORRTEX = COntinuous Reflectometry for Radius vs Time EXperiment.)
I found an article explaining CORRTEX at https://permalink.lanl.gov/object/tr?what=info:lanl-repo/lar...
It's based on a portable Motorola 6800 microprocessor, so the PDP-11 connection is unclear. A coaxial cable is placed up to the detonation point, and as the shock front progresses the cable is crushed, reflecting the TDR pulse back from that point. They call it "Radar on a wire". The interval between pulses is between 20 and 90 microseconds, so this is much faster than the alleged PDP-11 network card. The original system was developed in 1975 and evolved to the 6800-based system. More information in the paper http://dx.doi.org/10.1063/1.1136283
An earlier system was SLIFER (Shorted Location Indicator by Frequency of Electrical Resonance). It used the same idea of a coaxial cable progressively shorted by the blast wave. However, instead of using reflectometry, it used a resonant Colpitts oscillator whose frequency was 1/4 wavelength. So as the cable was crushed, the frequency increased. Plotting the frequency vs time showed the progression of the blast wave.
The oscillator itself was a small circuit board in the blast hole, while data was recorded in a separate trailer. To quote the paper: "In the event the recording facility must be located near surface zero, shock mitigation may be required to assure survival of equipment." The paper includes PCB layouts in case you want to make your own SLIFER system :-)
"In this initiative the President invited Mr. Gorbachev to send Soviet experts to the United States to examine our new CORRTEX verification system and to observe a U.S. nuclear test in mid-April at our Nevada test site. The President made it clear that if this meeting leads to an agreement on verification -- incorporating CORRTEX -- which meets our concerns, he is prepared to move forward toward ratification of these two treaties."
White House Statement on the Soviet-United States Nuclear Testing Talks, December 15, 1988
"Under the terms of a U.S.-Soviet agreement negotiated in the previous round of the NTT and signed at the Moscow summit, underground nuclear explosions were conducted at the U.S. test site in Nevada in August and at the Soviet test site at Semipalatinsk in September, with observers from both sides present. The purpose of the JVE was to allow each side to demonstrate its preferred verification method for the TTBT and PNET. The results of the test were discussed during this round. We believe the experiments demonstrated the effectiveness and nonintrusive nature of CORRTEX, our preferred method of on-site measurement."
The smaller PDP systems 11/03's where often used in Labs - DEC did a Realtime operating system RT11 for this use case and there where some exotic expansion cards for experimental use.
Back in my first job we had a custom built 12 bit ADC used for analysing mixing about £3k per channel in early 1980's £
The initial fireball of a nuke is caused by xrays absorbed by air and develops in microseconds. Basically all at once, since the xrays move at the speed of light. A spherical region of air just ionizes.
The expanding fireball moves quite a bit slower and increases 10s of meters (from an initial ~10-100 m) over several milliseconds[1]. After that it slows down even more, and if you measure every millisecond you'll see the fireball expanding by meters.
A DEQNA ethernet controller card can measure to an accuracy of 100ns which is around 20m at the speed of light. Shockwave velocities in the ground are in the order of 1000 to 10000 m/s or 1 to 10 m/ms so sampling at 1ms intervals should be precise enough.
In fact here is a graph produced by CORRTEX https://digital.library.unt.edu/ark:/67531/metadc1200655/m1/... which shows a velocity of ~3 m/ms or 3000 m/s. The sepcialised equipment has much better resolution and samples much faster than every millisecond.
I read a different version of this story many years ago, but have not been able to find it again. In it, the machine did not send measurements to a more distant location, it recorded them in memory: core memory, with each core individually labelled, in case the machine didn't stay in one piece.
(If true, this probably implies the machine was not a QBUS PDP-11, and the reflectometer was not an ethernet card.)
My favorite was an in depth website about farts. It explained how it was impossible to fart while you sleep because your “don’t pee myself” reflex keeps everything sealed shut. This is why you often let a big one rip soon after waking.
I believed that shit for 20 years ... then my girlfriend moved in and lemme tell ya, humans definitely fart in their sleep.
Oh yeah old computers were heavy. I just cleaned out a cabinet in my basement office, and on the bottom shelf were parts of a 1980's computer. It weighed tons! Broke my back carrying it all upstairs to get rid of.
Have you seen a PDP-11? It probably weighs closer to a tank than anything produced by SGI. You wouldn't be lifting a PDP-11 without equipment: it would be the size of a refrigerator or 2.
In the info box photo on that page, only the box at the bottom (with the red and purple switches) is the processor; above it are two blanking plates and a TU-56 tape drive. I suspect that KPS considers the machine to just be the processor, whereas you're looking at the processor and surrounding peripherals.
That said, there were PDP-11's that were desk-sized, such as the DEC Professional (about the size of an IBM 5150), or even smaller, the VT240 (which is largely an embedded PDP-11, and it has about the footprint of a C64, though somewhat thinner)
Ah, yes. I was indeed considering the whole system (processor + peripherals). I guess it shouldn't surprise me that there's a PDP-11 that fits on a desk, because I know at least some MicroVaxes fit on desks, and they're contemporaneous with the PDP-11.
PDT 150 was a desk top model - pdp11/03's where targeted at labs and originally came in a wheeled trolley about half cab height that you placed an VT52 or VT55 on top.
My Dad had one of those PDT-11/150 as his "personal computer". It ran RT-11, had two 8" floppy drives. The CPU box was about the size of a countertop microwave oven. He had a video terminal, and a printing terminal (LA36 DECwriter II) connected to it. I'm gonna guess late 70s.
The "time-domain reflectometer" will send a signal down the line and listen for a reflection from its end.
This happens in much the same way a travelling wave will reflect from the free end of a dangling rope. Even though a jiggling rope and an electrical signal seem different, the underlying mathematics (mismatched impedance at the rope/cable end) is essentially the same.
The time difference between when the signal is sent and the reflected signal received, multiplied by the speed of the signal (over two), gives the distance to the end of the cable.
If the reflectometer can make the measurement quickly-enough, the series of measurements will trace out the decreasing length of the cable as the detonation destroys it.
This doesn't answer the original question: How could the experimenter ensure the electromagnetic pulse from the nuclear denotation wouldn't create false readings in the TDR measurements?
Nuclear reactions don't just make EMPs; it's not like nuclear plants are emitting continuous electromagnetic interference. Nuclear EMPs are created when radiation ionizes susceptible atoms, creating charged particles via Compton scattering. That's why high-altitude nukes create much more intense EMPs; the low-density atmosphere is much easier to ionize.
Gases at low pressure are DRAMATICALLY easier to ionize than anything else- think fluorescent tubes, etc. Dirt will not be highly ionized by an underground explosion, although I can't actually find anything about underground EMPs. It is safe to say that the EMP will be very greatly reduced, though.
The EMP is dangerous to electronics because it creates a voltage gradient over a large area. A 5 volt gradient across a few inches of ground plane will destroy most electronics permanently. A semiconductor is painstakingly embedded with atoms that create an intrinsic voltage difference across a tiny sliver of silicon; a mild voltage in the wrong direction will erase that gap. It will not destroy wires, since the pulse is extremely short.
Forget erroneous measurements. The EMP would kill the computer if it was just a plain wire. You're talking about picking up tens of thousands of volts across any kind of protection circuit. The only possible way this works is with some protection, ideally shielded wire like a coax cable. If that's the case it'll just cause a brief (<10 microsecond, mostly) flash of current to ground. Modern Ethernet is twisted pair, but the first ethernet was coax and the first R58 was sometimes shielded.
There are other types and components of nuclear EMPs but they mostly aren't important in this case. There are several highly questionable things about this story- the PDP-11 would need a pretty skookum power supply to not bottom out, the motivation is... strange, the ethernet wire would need to be incredibly long, etc. etc. EMP is probably not one of them, at least as far as the quality of data. EMP becomes irrelevant if you can access raw data or the ping uses anything but the simplest impulse waveform. Assuming you can actually collect data in the first place, anyway.
It might -- in this context (and always ;) ), I'd guess that experiment is the arbiter of truth. If they set up a few of them, perhaps with differing cable lengths in order to vary the capacitance, the extent to which they all measured similar results would give a measure of how well the method might measure the cable ablation.
There's a chance that there's a subtle systematic, but my guess is that either the method would work or the measuring device would get smoked, with not much in between.
My fluid mechanics professor showed how to measure the yield just by examining a movie of the blast frame by frame, i.e. the size and rate of expansion of the cloud.
A professor did this in the late 1940s and got himself investigated by the military for espionage, until he showed them how to do the calculation.
Nuclear explosions generate massive amount of electromagnetic interference which is likely to fry or at least throw off any regular reflectometer that relies on echo of the signal. Don't want to say it is technically impossible but would probably require especially designed instrument.
