I just finished the disagreeable task of moving my wife's data and applications from her older not very fast quad-core Lenovo to an i7, 16GB Lenovo Yoga 7i. FHD screen and it supports 4K on the HDMI port. This brought back memories of when engineers were bold and risk taking with employer equipment in the pursuit of hotrodding was common.
IBM upped its game with the IBM PC/AT. It was mechanically elegantly simple compared to the PC and its hard disk variant, the PC/XT. There were no ribbon cables holding connections between peripherals and the daughter cards that were plugged into the motherboard. No tools were required to open it up and reduce it to its simplest assemblies. It was a work of design art.
Best of all, it used an Intel 286 processor. No longer was the processor held back by the 8088's byte wide data bus. All 16 bits of data bus were available to fetch 16 bit words in one instruction execution data fetch cycle. (If you do not understand this, beg the old wizards to explain.)
More importantly for the number crunchers, was the 287 numeric coprocessor. The 8088 had an equivalent dedicated floating point coprocessor. These sat on the motherboard and performed blindingly fast (at least to us cave dwellers) floating point processing instructions that would otherwise have taken forever with the standard floating point arithmetic libraries. The ugliness of these integer attempts to do floating point math are things that decent wizards dare not speak. Shall I tell you about the chemical plant in Switzerland that blew up (in simulation mode) from defective floating point libraries that came with our Pascal compiler? Maybe not.
Anyway, we saw that beautiful AT just long enough to ship it to HQ near Munich. Then we got one for the US development lab.
Our beloved head honcho, Elvet (that is not a typo) Moore ended up with it. He had a Lotus spreadsheet that took 45 minutes to recalculate if he changed one cell. (He was our bean counter in chief, and a heckuva nice guy.) So he brought it over on a 5.25" floppy diskette. (Ethernet on PCs? What is this dark magic of which you speak?) We loaded it into this new AT and recalculate now took a fraction of a second.
Somewhere along the way (I worked in the heart of Silicon Valley by now), it was rumored that the AT motherboard and 286 processor could run a lot faster than 6MHz. The trick was replacing the 6MHz clock crystal. This was two leads that plugged into the motherboard; 8MHz worked in most ATs with the corresponding increase in speed. 10MHz usually did. At 12MHz, the successes were only occasional. Soon every maker of AT clones was supplying them prehotrodded.
I bought a Bentley 10MHz clone. It was almost twice as fast as the ATs at work, so I stayed home and wrote the 14,000 lines of C code for the core of the digital loop carrier GUi at home. Those were good times!
I began my IT career (mid '70s) as swing-shift operator on an IBM System/370, DOS/VS operating system. Jobs (all "batch") were started by reading JCL (job control) keypunch cards using the Card Reader/Punch. We had the hot-rod 370 with the 256K magnetic core memory expansion module - roughly the size of a big upright refrigerator. We also had the futuristic magnetic disk drives - 10 megabyte removable platter arrays, that were accessed in washing-machine-sized disk drives. The floor of the computer room was elevated so they could blow cold air underneath, to keep things from overheating.
ReplyDeleteTimes have changed!
Yes. My first formal programming class PL/I was on a System 370 at UCLA. I remember enough JCL to want to forget it.
DeleteBack in the day I wrote my own floating point math package. In assembler. On two different machines.
ReplyDeleteYears later when they were using DWord floating point for a fiscal package I pointed out the limit of significant digits was quite a bit less digits that the amounts of money we were dealing with - especially in the middle of calculations. So I wrote a C package that did the math in ASCII. Two versions actually, one where the buffers were adapted to fit the inputs and one with fixed buffers several digits longer than the max we used. That was the one we used, of course, and last I heard that package had been ported forward through several language changes.