News: 1598253304

People nowadays have no idea how sensitive electronics used to be.

Remember when you couldn’t use anything electronic on a plane in case it interfered with the planes control systems.

Remember when audio systems used to make a noise when your phone received a text or phone call.

How about wifi failing when someone turned the microwave on.

In retail it was the tills going wobbly when the fluorescent lights turned on or set up too close to the exit RFID scanners

I remember listening to the radio while my Sinclair ZX81 executed code; distinct patterns of noise depending on what the computer was doing.

I once worked with someone whose MSc project was making music from executing code in a similar manner. He might have been brilliant, but did that really demonstrate his coding skill?

I remember watching a guy[1] toggle in code on the front panel of an Altair 8800 that allowed it to play "Bicycle Built for Two" or "Fool On The Hill" over a transistor radio placed on top of it. Took the guy half an hour or so to program the machine. One of the people in attendance was heard to comment "that's probably the best use I've seen for a personal computer yet ... "[2]. It was late 1975 or early '76, at an early Homebrew Computer Club meeting.

[1] Steve Dompier?

[2] Roger Melen? Has been a LOT of water under the ol' bridge ...

Are you sure it wasn't Roger Mellie? Later a stalwart of Viz!

The Arnolfini Gallery in Bristol had a retrospective exhibition of digital art from 1970s/80s/90s. There was a personal computer programmed to play tunes through a transistor radio placed near it. The output peripheral was actually the CRT monitor - i think the scan coils because medium/long wave. A video 'demo' was looped that had been written to produce the audio in the radio. Quite a nice piece.

> I once worked with someone whose MSc project was making music from executing code in a similar manner. He might have been brilliant, but did that really demonstrate his coding skill?

Learning how to force the machine to run at specific "physical" frequencies for specific periods of time sounds like it requires at least a bit of skill :)

Then too, things like this probably helped to pave the way for the various "airgap" attacks which are based on monitoring EM disturbances when computers are doing things...

My ZX81 was plugged into a 4-way socket, each individually switched. Turning the power on and off on socket 3 (empty) caused the ZX81 on socket 1 to perform an interrupt that stopped programs executing.

Great for hacking games for unlimited lives or removing collision detection from the code.

My screen still flickers when the mobile phone is too close to the USB-C/HDMI adapter.

I used to work on a GEC4000 that could spot lightning 30 miles away, despite being quite far inside building with lots of stuff you would think shielding, though of course it could have been serial line for one of the other computers acting as an aerial. As the summer storms used to come up from France is was often a lot better than the weather forecast as to what was going to happen. Friday afternoon - blank screen. hot humid air, sunny skies? Reboot and see if you can get to a a good save point and then leg it home and down the pub on the docks to have a beer or two while the storm rumbled over the sea full of lighting and eventually a cold wind would spill over the quay which would signal the time to get into the pub and order 4 pints so you could have something to drink in the lightning flashed dark as the power went out.

They still are.

ECL had a noise margin of 150mV. TTL had at least double that (asymmetric) but although the more modern CMOS technologies have twice that noise margin (around 1.45V) at equivalent supply voltages, the move to much lower supply voltages reduces this proportionately. With the now quite common 1.8V supply, the CMOS noise margin falls to 0.52V, which is about the midpoint between the two TTL thresholds (0.3V low, 0.7V high). Given the much higher impedance of CMOS, the chance of noise pickup is much greater, so we're quite a bit worse off than with TTL.

But everything now is surface mounted, double-sided boards or all of the transistors in a single packaged IC. Therefore the tracks (aka antennae) are much shorter and generally routed with some consideration to where the ground plane is, which all reduces the amount of pickup.

(De-)couple that with better understanding and availability of decoupling, twisted pairs, isolating transformers and you have much better immunity.

Elevators, micro waves, fridge generators turning on and off, these stories are very common among older geeks.

Explosion danger was one though, at one company, they sent some project guys to a flour mill to work and the client set them up in the main hall, which had a lot of flour dust hanging in the air, as well as causing breathing difficulties, flour dust can be very explosive. The H&S guy wandered through the hall, saw the computers under a direct flour feed pipe and dust coming out of the pipe joints (normal).

He quickly evacuated the project team and had the power to the PCs cut. Luckily, there was no explosion, but the project team were a little white faced, and that was not caused by flour dust!

Another time, I worked for a plastic producer. They had a sulphuric acid store, where tanks of acid were kept. The PC they had was playing up, so I went to look. The motherboard and the drive were both badly corroded. As company policy was no data to be stored locally, I just swapped the PC out.

That was when the user told me the network had stopped working months ago and all the data was local... I managed to recover most of the data off the pitted drive.

"People nowadays have no idea how sensitive electronics used to be."

Or how electronically vicious they could be.

Back in the '50s the Beeb experimented with stereo broadcasts on Saturday mornings. One channel was broadcast over TV sound (don't bother to ask which channel - the Beeb and ITV only had one each) and the other over the Third Programme. Unless you were rich enough to have one of the new-fangled FM radios the Third was a weak signal on medium wave AM.

TVs were CRTs and the EHT was generated by a whacking big transformer driven by the sawtooth (more or less) waveform of the horizontal scan. The harmonics generated by that mess extended will into the medium wave so the sound on that channel was swamped by the howl the interference generated despite being only a couple of miles or so as the signal flies from the transmitter.

"Remember when audio systems used to make a noise when your phone received a text or phone call."

ISTR reading that this no longer happens because the phones have changed frequencies, not that the audio systems are less sensitive - I remember it happening in the pre-smartphone days, but not recently (and there has been commonality in the audio equipment over that time).

We used to have Thanksgiving dinners in the '70s, where everyone would be gathered around the TV watching whatever parade and/or sporting event.

Then grandma would use her electric knife to carve the turkey, which would completely kill TV reception.

yes, put your phone in GSM mode and pop it near the radio/speaker and you should still hear the same interference.

We were convinced that the painfully expensive performance upgrades performed by the grizzled bloke in a lab coat that ICL sent us consisted of 11 hours of tea drinking and sandwich eating concluded by a single wire being cut with a pair of tin snips to remove the performance-slugging circuit.

depending on the system it could be even worse. for 2900 systems an upgrade could require a new CPU,/ main board or just a microcode upgrade. It was standard to re-run the factory trials test though and that did take 10 hours plus, you would normally get a new cabinet door badge as part of the upgrade though.

"you would normally get a new cabinet door badge as part of the upgrade though."

I remember someone discovering that the numbers on the VAX doors could be swapped around so they did the nominal upgrade themselves.

Ah, you forget the most important part - changing the stickers on the outside to the correct colour for the new level of performance (apparently a much harder job than the actual upgrade).

IIRC the machines were too expensive so they did slower versions to recoup the development costs - so the upgrade was just undoing the delay introduced to make the cheaper version. In modern times this has happened with CPUs when there were too few defects to give the cheaper versions so they just fused off some good bits (and it was even possible to undo this on certain Athlon models).

you are absolutely right, rather than design protoype and then build 4 or 5 different machines which would then require swapping out at some point the target design was the highest spec machine which was then 'slugged' through microcode to produce the desired performance level for each machine. Theoretically the tapes with the mircrocode on were unique to each cpu serial number but I'm not sure that was really true.

There were also some marketing limitations on which features you could purchase for each CPU range.

The microcode was absolutely unique to each set of 'cpu's' (pain in the arse when boards were changed). There was also logic built into the systems that could not be circumvented that implemented the slugging. If all was not hunky dory, it would default to the most restrictive slug. Again, a pain in the arse if you had an inquisitive customer.

Intel and Cisco still use that model to gouge their customers for "upgrades".

Tesla does the same with their cars.

I wonder how SpaceX does it.

At school in the 70's a classmate had an early TI scientific calculator.

He had a basic model of course. Opening it up, he noticed there were unused pads on the PCB, the only difference between the basic model and a higher model was the buttons provided. Cue the addition of little button switches to unlock the missing features...

Back in the late 90s I remember a service shop that would snip the little system speaker wire, when they couldn't fix a driver problem... internal speaker would chirp ever two seconds... I couldn't believe my eyes when a friend showed me.

"... concluded by a single wire being cut with a pair of tin snips to remove the performance-slugging circuit."

Had something similar with a DEC Alpha machine back in the late 1990s. We wanted to max out the RAM, so a smartly besuited engineer arrived and proceeded to cut a couple of jumper wires on the mainboard. It turns out that when you leased such a machine from DEC it came fully loaded, but with certain hardware options disabled if you hadn't paid for them.

When we had a Xerox Desktop Publishing system installed at the engineering company where I worked, the installer came with a huge box of 5¼ floppies to install and configure the software. We were given a list of what functions were available, and the cost of having each one installed, and we picked what we thought would be needed and were billed accordingly.

Some time later, we decided that we needed a couple of extra functions, so a maintenance engineer came along and logged in, ticked the relevant boxes on the installation list, and logged out. I asked how this was possible, to be told that all the necessary software was actually already installed, it just needed a tick in the right box to activate it.

About a year later, I needed another function to be switched on, so I tried to log in using the original password, but it had expired. After quite a bit of cogitation, I realised that, if I were to disconnect my workstation from the server and reset the date to the previous year, the old password would let me in, I could switch on whatever I liked, and then reset the date to the correct year and reconnect to the server.

Over the next couple of years I switched on nearly all of the functions on my particular workstation, and no-one was any the wiser.

40 years or so I had a Suzuki motorbike, can't remember the exact model but it was the lowest spec version that omitted simple things like a brake light switch for the front brake so it only triggered on the back.

Except that the switch was there, the plugs were on the wiring loom, they just only connected them on the higher end bikes! That took all of 5 minutes to fix once I noticed.

What did it predict and how close to the eventual reality was the prediction.

politician won..

voters lost..

Picture a data center in the basement of a tall building in San Francisco's financial district. Card punch up against a wall, near the ancient Otis heavy goods lift. Every now and again, at seemingly random times, the punch generated errors for a couple characters. Nobody could figure out why, not even IBM's field circus dudes.

Until IBM was traipsing in and out one fine weekend, upgrading who knows what hardware, as only IBM could. Someone (ahem) noticed that the gibberish was being generated about ten seconds before the elevator doors opened.

Turned out that the motor for the lift was drawing so much current when it first started that it was inducing errors in the punch on the other side of the wall. Nobody put two and two together prior to this because the lift rarely went into the basement (that level was key-protected) ... until IBM was in and out that morning.

I remember writing code for several PCs with different Matrox frame-grabbers and image processing boards (PIP-1024A or B, and the more powerful MVP-AT/NP boards). In software, the diversity was solved by cordoning off the diversity of hardware platforms in separate libraries that were linked as needed. This worked fine in the medical microbiology lab, where I developed the code. However, once the department of dermatology had got themselves a shiny new MVP-AT/NP in their lab, and wanted to run my code, things constantly crashed, or froze. It turned out, this happened only when using a huge beast of a power supply for their mercury vapour light source for their Leitz fluorescence microscope. Bit of a bummer, as the code was intended to capture and analyse fluorescence microscopy images. The power supply produced so much RFI that the MVP-AT/NP electronics borked if you used any of the hardware image processing accelerator electronics. In microbiology we used Olympus microscopes, with a much smaller, more modern power supply, feeding the same type of mercury lamp with no issues at all. I had to write a separate MVP-AT library that didn't use any of the hardware acceleration to get the code to work in the dermatology lab.

Been there although it was XBOs (xenons) that we used rather than HBOs. It was actually the spike needed to fire them up that was the problem so it was just a matter of switching them on before boting up.

We used to have an office in Woking, next to the trainstation. 4 times an hour, whenever the train left the station, it would send powerspikes into our building. You would see the lights dim and then brighten before getting back to normal. Same powerspike would sometimes take down a computer, which could usually be fixed by a reboot. Even after supplying most machines with a UPS the spike would sometimes be too strong for the spike-limiter (or whatever it was called) in the UPS and take down the machine.

In other days, we had dual monitor setups for most of our users, even in the mid-90s ... big 24inch sun monitors that could do 1920x1200. When you turned on both at once, they would both go through their de-gaussing step at the same time, and could happily be bouncing of each other for minutes before one of them would give up and they would both stabilize.

Even more fun after a powerfailure, and you restored power only to remember slightly too late that you hadnt switched off all the monitors. The powersurge of more than a dozen of these beasts starting up would immediately trip the breakers

I had one of those monitors at my first proper programming job, attached to a SparcStation that only had an 8 bit framebuffer. The colour palette used to change as I'd switch application windows, inducing a near weekly migraine.

I've got a huge old 1600x1200 19" CRT monitor in my loft (put there on the basis of 'might still be useful' at some point when I was upgrading), made a lovely chunky noise when powering on and de-gaussing.

Unfortunately a few years ago we had a loft ladder put in, which had the side effect of narrowing the loft entrance...and that monitor is now staying in the loft.

colour palette used to change as I'd switch application windows

There used to be a fix for that, damned if I can remember what it was, though. It involved making all the windows use the same colour table.

I remember some Force(?) 68K VME boards that had over-sensitive RTS/CTS lines. If you left them connected to the modem cable at the card end, but unconnected at the terminal, the voltage generated from cross-talk on long data lines could cause all sorts of weird effects. Terminals would seem to work fine until some pattern of data on Rx/Tx would cause a modem line to drift just far enough to act as an XOFF and everything would seize up. Took a while to figure that one out.

I had exactly that with Rair Supermicros in the late 80s. We would lay out looooong RS232 cable to the terminals and configure the O/S to have a VDU on the end of each port.

The problem was if the customer removed a terminal and left the RS232 cable dangling then we would get crosstalk/interference that would flap the pins on the UART, causing the board to be flooded with interrupts. This caused a slowdown over a five minute period until the machine hung entirely.

Restarting it would mean every display showing the start of the "Welcome to Rair M/PM" message getting displayed and every terminal hanging.

Our solution? To tell the customer over the phone "Remember when it was all working and then you changed something (unplugged a terminal)? Well go back and undo what you did". A technique that still applies 35 years later...

How do you recognise a field engineer with a flat tire? He's the one swapping all the wheels to find out which one is flat.

How do you recognise a field engineer with an empty fuel tank? He's the one swapping all the wheels to find out which one is flat.

A long, long time ago in a land far, far away, a farmer complained that his phone would not ring, except in the early mornings when his dog would bark and then the phone would ring?!?!

Turns out that it was a grounding problem and that when he tied his dog to the phone earth spike over night - the ringer voltage through the dog's chain, would make the dog pee, completing the circuit.

The big clue was that the PDP was downstairs with the operators on the floor above. Long interface cables with unterminated pins can cause havoc, even with decent shielded cable.

Back in the early days of Kilostream leased lines we had problems with the Kilostream modems going into loopback because we had ordered long fully wired X21 cables for some sites but the kit wasn't terminating the loopback pins. They were acting like aerials and any noise would flick the modem into loopback.

I think they (BT) learned a lesson (obviously we weren't going to be the only ones affected) and later modems were fitted with an option to ignore the loopback interface and only act on the front panel (or remotely activated)

It wasn't BT who learned the lesson, it was the manufacturer of the kit - i.e. Marconi Communications, whose R&D department was housed in the little village of Writtle where the first regular wireless broadcasts were once made (2MT). As a very PFY I did my apprenticeship there, and got involved in all sorts of testing. I recall having banks of Trend RS-232 testers running for days thrashing a multiplexer that I'd built up out of 74 Series TTL - four eurocards worth IIRC. They gave me a permanent job afterwards and I became quite the expert on all things serial, even designing a dual UART in a custom gate array. Those were the days ...

Thankfully years of alcohol abuse has dulled the memories...

[1] A story about magic

[1] http://catb.org/jargon/html/magic-story.html