zeeglen wrote "This could be an indication that somebody copied somebody else's design."
It wasn't. It was a subtlety in the spec. PCMCIA (expands to Personal Computer Memory Card International Association) was originally formed to standardize the interface to add-on memory cards, hence needing only Card Select, Address lines, Data Lines, and Read and Write strobes.
When it was expanded to support other devices, e.g., modems and LAN adapters, they needed to add I/O read and write capability without disrupting the physical interface. I forget the detail (and the specs are in my office) but the added I/O space by some previously unused (and unnatural combination of control lines. The way it was done was such as to make it easy to make that mistake.
You wouldn't easily catch in those days because a typical test pattern sequence would be
Repeat Write pattern to memory Read it back and check Until enough patterns
Repeat Write pattern to I/O Read it back and check Until enough patterns
Even if you went back and checked memory after this, if the last pattern for both passes were the same the result would pass.
I truly believe it was an innocent error, which occured twice because the specification was misleading. Ever see multiple students make the same mistake on a "trick question?"
Well, this did cause me to recall another interesting problem and solution. In the early 1990s I was responsible for designing a series of PCMCIA devices--the credit-card-sized units that slide into a laptop slot. PCMCIA drivers in the laptop performed configuration steps to set the socket controller chip so our devices (modem and LAN adapters) appeared in the proper location in the laptop's memory and I/O space, guided by a configuration file.
Our company made laptops as well as adapters and I had once inquired why our file listed certain forbidden regions instead of being uniform. I had learned that a particular socket-controller chip our company had produced and shipped had a bug such that under certain circumstances writes to I/O space were directed to memory space, so configuration of memory and I/O to the same numeric address ranges had to be avoided.
One day we learned that a third-party wanted to offer our PCMCIA cards and had received one which wasn't operating correctly. Our lab had a lot of laptops but we didn't have the particular one which was failing. We asked to be sent the laptop and our software guys spent a few days looking at it. Eventually one of tham asked me if it were possible that memory could be corrupted. He handed me a page of dump with one byte highlighted. I immediately recognized the address as one that was commonly configured for I/O in this sort of product. I asked to see the laptop and found that it didn't have our company's chip. It had the chip of another company--who had made the same mistake as our designers. Editing the configuration file to avoid the address overlap solved the problem.
As Curt notes, had I not seen this error before it might have taken weeks to solve the problem.
Yes, that's the one! Must have been kind of hard to operate, standing on the desk of the TTY in front of it.
And he wrote: "As to the rest of the photo, I was 3rd shift operator in the Physics department and responsible for the operation of three Univac 418 computers (Models I, II, and III, pick your level of obsolesence even then) and had to be capable of being two places at once. :-)"
Ahh, yes. In 1968 I had the privilege of being an operator of a cyclotron at the University of Illinois just before it was scrapped. It had been built with Navy funds in 1945 and modified over the years, but the design had apparently never included feedback control systems. I always assumed that less was known about such systems at the time of the design or that the gain of vacuum tubes and early transistors was so low as to prevent sacrificing some gain for stability. Unlike your machine room, the control room consisted of racks and racks of test points and 10-turn helipots, with a VTVM at the top of each rack. On a good day, everything was stable and I just had to monitor one or two meters occasionally. On a bad day I would wear myself out kicking my roller chair back and forth between racks, tweaking helipots while the grad student whose experiment was running screamed "More beam current! More beam current!."
I didn't program it, but it was used to track the status of the Hawkeye I satellite that the University of Iowa (home of Dr. James Van Allen) had launched.
As to the rest of the photo, I was 3rd shift operator in the Physics department and responsible for the operation of three Univac 418 computers (Models I, II, and III, pick your level of obsolesence even then) and had to be capable of being two places at once. :-)
Nancy, that story reminds me of when I was programming a DigiBoard 80188 communications coprocessor. The included software either expected Xenix or MS-DOS. The MS-DOS version emulated a single character I/O, completely ignoring the 256KB of RAM on the card.
In a classic case of miscommunication, the client asked if we could print to more than one printer. My coding buddy and I had planned to wrote a queued report generator and so we said yes, we'd just add another byte to the queue table to denote printer destination.
We installed the software and the report print queuer printed the report to one printer and after finishing, printed a different report to the second printer. No, said the client, we want both to print simultaneously. Oops. The print spooler (as we called it) was not designed to multi-task and we were out of multi-tasker slots in system.
I noted that both printers did print simultaneously at the transition, the printers had 1 KB buffers built into them.
I decided to write a serial buffer program for the DigiBoard and then allocate as much memory as I could spare to the printers.
While writing the code to operate in interrupt mode, I had to set the interrupt enable bits for the interrupt control chip. It wouldn't work, it wouldn't work, I tried several variations on the coding and finally in desperation, I flipped the bits, and it started working. (Insert snarls and foul language)
When installed, the same report generating code would send the first report to one printer and the second report to the other printer. There would be a 15 second delay between both printers from the time it took to send the first report into the buffer card and generating the second report.
The client was happy and we patted ourselves on the back for the smoke and mirrors we had used to solve the problem.
I had made an attempt to be slightly funny about bosses qualifications. Not about top level management, which may not need to have the technical expertise, if they don't attempt to make technical decisions, but about the one-level-up supervisors who really do need to be quite technically competent, in addition to having some management skills. There are lots of them that have neither kind of skills.
Twenty years ago I wrote a terminal emulator for an obscure (Beehive) ASCII terminal, working just from the manual. Like many such terminals all data went to the screen unless it was preceded by an escape code: the ESC character followed by a variable length code/parameter block. Also like many of the terminals of that era, each screen position could contain either a character or an attribute. I only had access to the real terminal on low-traffic Sunday mornings.
I defensively added two items to my code
A message in the status line when an unrecognized escape code had been received, and identifying the screen.
A secret keystroke which replaced the screen contents with the receive buffer ring.
Both of these items paid big dividends. I found out that the application, a Rockwell ACD, was sending malformed escape sequences beginning with ESC ESC from time to time with the unrecognized escape message. The real Beehive terminals treated these as a single ESC and I modified my code to do likewise.
I was informed that the emulator screen scrambled under a heavy traffic load. I managed to get a few minutes during a heavy-traffic weekday and after a few minutes the screen scrambled. I immediately issued the secret keystroke and looked at the buffer. The manual had stated that writing attributes to column 80 of any line was not supported. But the clever Rockwell application programmer had discovered that writing a tab to column 80 jumped the cursor to the next line and relied on that for a proper screen display. I had to insert this undocumented behavior into my emulator which then was rock-solid.
If I hadn't done those two items of defensive programming, it would have taken me hours to find the problems.
Isn't it great when the managers and supervisors have experience and knowledge, and possibly even insight, into the technology that those underthem are working with? A boss who understands the systems functionality, rather than just understanding spreadsheets? The boss who can pass along useful insights is indeed a good leader, and also somewhat rare.
Festo's BionicKangaroo combines pneumatic and electrical drive technology, plus very precise controls and condition monitoring. Like a real kangaroo, the BionicKangaroo robot harvests the kinetic energy of each takeoff and immediately uses it to power the next jump.
Design News and Digi-Key presents: Creating & Testing Your First RTOS Application Using MQX, a crash course that will look at defining a project, selecting a target processor, blocking code, defining tasks, completing code, and debugging.
Focus on Fundamentals consists of 45-minute on-line classes that cover a host of technologies. You learn without leaving the comfort of your desk. All classes are taught by subject-matter experts and all are archived. So if you can't attend live, attend at your convenience.