Macros are fun. Having the right macro – especially one you’ve struggled to write yourself – is like a Get Out of Jail Free card. When the software you depend on doesn’t do what it claims to do, or what you need it to do, then sometimes a good macro will provide a way of escape.
Microsoft’s Visual Basic for Applications (VBA) is a good example.
Continue reading “Macros”
Silicon Image eventually came out with a chip which couldn’t be controlled by simple register reads and writes. The chip designers created a device which could accept a video input stream and scale the image to a new resolution. It could also superimpose a message or picture onto the stream: an on-screen display (OSD) message.
To define and modify these OSD messages (text or picture) one had to program a lot of registers for font, color, character strings and image. It was not practical to do this with peek-and-poke instructions.
I saw a problem waiting for a solution!
Continue reading “First Chip Software Tool”
Well, yes, the title is a blatant attempt to squeeze a few keywords into one phrase. But, yes, there was word processing on mainframe computers, even before there were PCs.
This is the story of bending such a text processing system to do my will.
Back in the olden days, there were things called “mainframe computers”. They got that name because they were in mainly big – very big – frames, and computed, and were kept in air-conditioned rooms while human beings lived in the heat and humidity that had been their lot in life for generations. Ah, to be a mainframe technician! It meant staying cool in the weather of the East Coast. But anyway, these massive machines were connected to terminals, each providing typed input and showing the output of programs running on the computer in a time-shared environment. Sounds like client-server? Well, not so far off.
Well, the mainframes had programs which could format text into printed materials. These were text processors. The output was printed on equally massive line printers in the same air-conditioned room as the mainframe. One had to walk down the hall to get one’s “print-out’, and check it for errors. IBM had a very good example of this system with their IBM/370’s and their Script/VS text processing program.
This was the beast that had to be tamed.
Continue reading “Mainframe Word Processing?”
1992 brought a change at IBM Microelectronics. It was a big change. Facing business pressures, and with a stockpile of cool technologies, IBM chose to open their doors and sell their technology capabilities to the rest of the semiconductor-using world! True, those heady days of three-level-metal, 8-inch wafers seem simple now, looking back. But at the time those techniques, and others, were state of the art.
I was working in Program Management, and had gotten a taste of travel, and being in front of customers. I liked it. I wanted more. I signed up and moved to the Field Application Engineering department, serving external (and internal) customers with IBM’s premier ASIC offerings.
The biggest challenge in selling what IBM had was that IBM had different stuff. There were other ASIC companies out there, but IBM had top-end silicon, packaging, tools, sign-off methods, testing, and more. How to convince the customer that those things are worth a bit more, and that their design engineers could make use of it?
Continue reading “Out into the Real World”
Soon after the successes in designing subsystems for a new 20MHz tester, while looking around for more ways to contribute to the team, I came into the office on a Monday morning to see a meeting announcement.
“We have all been given a new mission,” proclaimed our manager. In those days, this was not an uncommon occurrence in IBM, yet my co-workers and I had worried looks.
Continue reading “Back to School”
Yes, indeed, I can write code with one hand and wire-wrap with the other. “Prove it,” you say. Well, I did in the late 80s.
After several years working on test equipment purchased by IBM, I decided it was time to take the plunge. A different department in IBM was developing a new tester in-house, and they needed help. So, an interview or two, and I transferred over there.
I arrived in time to get the assignment to design a “fail buffer” subsystem for the tester. This peripheral would collect fail information as the equipment ran patterns on the prototype memory cards. Software would be needed to count errors in that collected data, analyze patterns in the failures (row or column problems), and output reports. “I can do both – the hardware and the software!” I said. “It’s yours,” replied my new manager.
Continue reading “Ambidextrous”
I see this pattern in the projects I tackle in my professional life:
I enter into a new field – whether a new computer type, a new programming language, a new technology; I learn it; then I write about it and explain it to others; then I find its limits and try to push through those limits.
It began early.
Continue reading “Push the Limits”