As I mentioned in Part 1 of this series, I’ve been around the tech industry for a long, long time and I’ve run into some odd stuff. Here are a few more examples of tech weirdness.
In the category of ‘stuff that doesn’t actually work’ I read a recent article that pointed out something like 90% of the ‘walk’ buttons at intersections in New York City don’t actually do anything. Most of the lights (and ‘Walk/Don’t Walk’ signs) are all on timers so there is no reason to have the buttons – but I guess it makes people feel like they are doing something while they stand there and wait. And oddly enough, according to the people who actually manufacture the buttons, it turns out that if the buttons are ‘live’ then they tend to slow down traffic for both motorists and pedestrians. I’ve also heard that the ‘close door’ buttons on elevators aren’t connected to anything either, but I’m not sure about that rumor.
In the category of ‘why would anyone do that?’ in the early days of personal computers somebody discovered that there were quite a few undocumented instructions built into the 6502 processor (and quite a few other processors) that nobody knew about. Of the 256 possible instructions only 151 were actually documented, but many of the remaining 105 instructions were simply left in the chips (most were removed in later versions). Most of those undocumented instructions weren’t terribly useful since they didn’t actually do anything or they crashed the processor or they didn’t function the way they were supposed to. But some of them triggered strange and occasionally hard-to-predict actions, such as performing two valid instructions consecutively or performing strange mixtures of two instructions. They were doing exactly what they were designed to do – only no one has been able to figure out why the heck you would ever need to do those things. There’s probably some chip designer out there who thought ‘wouldn’t it be cool if there was an instruction to do this?’ so he wrote it.
Along the same lines, when Commodore came out with their ill-fated 128 model it was supposed to be backward compatible with all the old C-64 software and peripherals. Their engineers spent a lot of time making sure the 128’s compatibility mode would run all C-64 software and hardware. But they ran into a problem with one application that controlled an external modem. It took the engineers weeks to discover why the software/hardware combination wouldn’t work on the 128. It turned out that there was a faulty chip in the C-64 that was leaking tiny electric pulses through the port where the modem was connected. The troublesome application was actually using those pulses to synchronize the software with the modems. The Commodore engineers had to add a special chip in the 128 specifically to emulate the pulses of the faulty C-64 chip.
Even though Commodore went to some extraordinary lengths to insure the 128 was backward compatible with the C-64 ironically it also contributed to the demise of the new PC. Since the 128 ran virtually everything that the C-64 could developers had a choice – continue developing for the C-64 (and its installed base of roughly 17 million units – the highest-selling single computer model of all time according to the Guinness Book of World Records) and let the new 128 users run emulation mode, or develop for the new 128 feature set which C-64 users couldn’t use.
The end result was very few companies developed new software for the 128 and it died an early death.
