What were the first personal computers that people remember? The Minivac 601 from ca. ~1964 - It cost $135 ordered out of the old Science Newsletter (which became Science News). It had 6 _relays_ and a zillion breadboard plugs with long blue wires, medium red wires, and short yellow wires. Also pushbuttons, slide switches, and a weird i/o rotor thing. A couple of hours of wire-connecting and it played tic-tac-toe, also generated random numbers , and did various other similar stunts. There was the Minivac 601 and a "deluxe" 6010. These were really crude, in comparison to electronic solid state machine.. One of the fun things to do was to wire one (or more) of the relays to oscillate and then get a friend to hold onto a "truth" wire that was connected to the coils. The back EMF would put out quite a jolt. True computing power! The GENIAC from ca ~1955 - (or BRAINIAC -- the founders split and offered competing products). The company was "Oliver Garfield". He wrote a book about 1950 entitled "Electronic Brains and How to Make Them" and sold courses on robotics as well as a telescoping slide rule. The GENIAC was all I could afford. It cost between $15 and $20, was introduced in 1955 and was available at least into the early 60's. I got mine about 1960. The thing didn't work well, it was a major disappointment, but nothing else was available at the time. Real computers were viewed through glass walls -- you couldn't even touch them. It was made of a pegboard (or something similar) with 6 rotary "switchs" also of "pegboard" (and a row of light bulbs) that were programmed by inserting brass jumpers to make the switches run stepped switching.. It also could play tic-tac-toe and nim. Currently in my collection is a SYM-1 SBC. For those unfamiliar with this machine (gee, I dont even know if 'machine' is good in this context!), its a 6502 based system. Produced cira 1976, to compete with the KIM-1. I think the SYM-1 was produced by MOSTEC, the original developors of the 6502, who was later bought out by Commodore. Anyways, the think has 4k of RAM, 1k of ROM, a 16-digit hex keypad, and a 4-digit 7-segment LED display. The unit I have was modified. Out of the box they were 1k RAM. I also have BASIC for it. If anyones familiar with the BASIC from any Commodore, 8-bit Ataris, etc, this is the exact same basic. It also includes an EPROM programmer! I don't know if that was a standard feature, though. Yes, this baby is working! I can hook it into an ASCII terminal to make it easier to use, but thats not half the fun. In another league entirely, I also own a PDP-11/04 and 11/34, both working machines... I still have a 1979 Research Machines 380Z running. It's a hodge-podge of bits put together from prototype boards and the like. Back in those days I did some work for RM and they gave me the machine in return. It was a *big* machine for those days: Z80, 56kRAM, double 8" floppies (so almost a megabyte on-line storage, wow!), high-res graphics, an Algol60 compiler, the second-best text editor available on a micro even now (it was easily the nicest in those days), and so on. It's very long in the tooth these days, but still mostly works, and gets used. One day, real soon now, I'll get round to buying a new machine - something like a 486 system would be the present-day equivalent. What were the most significant computers of the third generation (that is, between 1963 and 1978?)? Ferranti Atlas - a Vax delivered 15 years early IBM 360 - what more can I say... DEC PDP-6, PDP-10 - the first commercially available general purpose timesharing system. Pieces of this hardware and software are still heavily used today. DEC PDP-8 - the first low-cost lab/desktop system. Also still found in bits and pieces of modern systems. DEC PDP-11 - long life (20+ years, it is still sold and supported), general purpose system. Unix! CDC 6000 - The first supercomputer (Cray's last CDC system) (Actually, the 7600 was the last CDC system by Cray to make it to production. It was updated several times over the years to use more modern memory components and to reconcile I/O subsystem differences relative to the earlier 6600. The later 7600's were known as Cyber 76, Cyber 175 (several sub-models), Cyber 176, and Cyber 740, 750, 760, 865, and 875. Those last two offered enlarged system address space and dual CPU. The basic CPU components were manufactured with little change from the late 60's thru the mid 1980's, a very durable engineering job for this industry. Cray also designed the 8600 that was never completed.) Buroughs 5500 - A high level architecture (Algol based) DEC VAX-11/780 - first commercial supermini. SDS 940 (SDS = Scientific Data Systems, later Xerox Data Systems) - the other first commercially available general purpose timesharing system. An upgrade of the SDS 930, it was commercially available before 1968 and ran the Berkeley Timesharing System. As sold, it had: Virtual memory, separate address spaces for each process, multiple processes per user, primitives for relatively secure memory sharing between users and free sharing between processes of one user, a way to construct filters (in what became the UNIX sense), and the interactive text editor QED (ancestor of UNIX ed and ex mode in vi). Two commercial operations bought most of the SDS 940's ever built, Com-Share and (I think) Tymshare. Both are still around today, and I gather both are still quite profitable. What were the advantages/disadvantages of 7 track as opposed to 9 track? No advantages, I think, 7 tracks were probably as many as they could squeeze in when the first tape drives were developed (IBM 727?). They were developed for machines with a 36 bit word length and 6 bit BCD or "Field Code" characters, so 6 bits plus parity made sense anyway. It really had nothing to do with the number of heads which could be spread across the tape. Later, when 8 bit was the standard, it could be written to 7-track tapes with Data Translation and/or Data Conversion. "Data Translation" applied to 7-track tapes on systems with 8-bit bytes: it simply swapped 6-bit vs. 8-bit character codes. Of course, it limited the 8-bit code to only the 64 EBCDIC characters corresponding to the original BCD character set. I don't remember what it did when told to do 8-to-6 for an EBCDIC code outside the nominal map. "Data Conversion" took three 8-bit codes (24 bits) from the system and did them as four 6-bit codes on tape. It was/is possible (at least on IBM drives of the era) to turn on both Translation and Conversion, but I can't recall which was done first or what the real result was. I do remember that most folk regarded the combination as spectacularly unuseful. The 7-track tapes came in 200, 556 and 800 BPI densities. One real pain in 7-track days was having to be able to handle a tape with some records in even parity and some in odd. It was even possible to have a tape with files stored at more than one density on it. I remember an archiving system in use on our CDC 6600 way back in '75 or so on our 7-track 200/556/800 drives that routinely used different densities on a single tape. I think it recorded the directories at high (556) density, while the files themselves were at 200 BPI for greater reliability. It is only with the introduction of the 360 that IBM proclaimed that from that time onward a byte would be 8 bits. For some reason everybody followed. 9-track was designed to accommodate the 8-bit "EBCDIC" character/byte, plus a parity bit. The original 9-track tapes were all 800 bpi, with 1600 bpi and 6250 arriving later. One real advantage of specifying 9-track tape is that the tape drive senses the density of a tape automatically, so you don't have to specify the density when using a drive capable of more than one density. Also, 9-track tape is *always* written in odd parity, so you don't have to specify that option. Our Vax 11/780 with TU-78 drives refused to read tapes with even parity. We also had DECtape tape drives which had 18 tracks and were 3/4 inch wide. Half the tracks were redundant copies of the other half. The tapes were Block-addressable, too. People actually ran RT11 with DECtape (of either vintage) as their system device. Strange but true. Stranger and more rare was the TA11 or TA90 (I think it was the TA90 but can't remember.) It had 96k on an audio cassette. Yes, you could run RT11 with that as your system device (you got two drives in each box). I've actually seen a set of RT11 V1 DECcassettes. These seem to have been packaged with low-end 11/10's for lab stuff. I seem to recall in one manual somewhere, perhaps its the RT-11 docs, that a TU58 is handled in the fashion that a disk is. In other words, it emulates a disk. I don't know about RT-11 and TU58's but the DEC10 had TU55 DECtape drives. Yes, they acted pretty much like disks. These were fat little round plastic reels, descendants of LINCtapes, not those wimpy cartridge things. A DEC10 DECtape was 578 blocks long, each block contained 128 36-bit words. These 578 included a few blocks for boot, and a couple for directory. Recording was redundant, so you could crumple the tape and punch holes in it and still do I/O. Software formatted in real time, so you could get more blocks on the sucker by dragging your finger on the hub while formatting the tape (at your peril). You did I/O to them by mounting them, like a removable disk. The DEC10 monitor (OS) let you store up to 22 files in a DECtape directory, but you could write a "directory swap" program that let you keep multiple directories on a tape, and you could alternate between them. As I recall, the way to use up the whole DEC10 Monitor's PDL (system stack) was to do an extended enter uuo (an open()) of a file in an SFD (a subdirectory, sort of) on a DECtape. Back in the early 60's, there were 1" tapes on 10" aluminum reels. No vacuum columns; instead there were servo arms. They were referred to as Potter-Brumfield (or something like that). The interesting thing about these tapes were that they would be performatted into blocks, just like a disk. Each block was consecutively numbered, and the data portions of the block were rewritable. The controller that went with them could accept a command of the form "Slew forward/backward N blocks", so you could use these as random access devices, albeit with enormous latency times. And we did! The monitor [kernel] was responsible for ensuring that tape motion commands were far enough apart so that you couldn't snap the tape. Does anyone remember the IBM "Data Cell"? It was introduced around the same time as the 360, as I recall. Imagine a cross between flypaper and a tie rack. It used long strips of (maybe) 2" tape and would go fondle the desired strip onto the read/write station on demand (or maybe after being repaired). Standard procedure was to read the full tape set once per shift, or the beast would start sticking with disastrous results. There were 8 "bins" on a data cell, each of which held some large number of tape strips. The bins were shaped and arranged like slices of pie; the "pie" was rotated to bring the correct bin to the "pick" mechanism that (if you were luck) pulled out the tape strip. You couldn't run the data cell without 8 bins; you _could_, however, replace a bin with a dummy bin, filled with sand, to keep the whole mess balanced. The vestiges of the data cell live on in the 8 byte "full disk address" used by MVS: M BB CC HH R | | | | | | | | | +--- record | | | +------ head | | +--------- cylinder | +------------ bin +-------------- extent The successor to the data cell was the 3850 Mass Storage System (MSS). The MSS contained a honeycomb structure filled with spools of tape in containers that look for all the world like beer cans. A "truck" would run around over the honeycomb, pick the right spool and mount it on a read/write mechanism, which "staged" the data onto a 3330 disk. These suckers aren't sold anymore, but I'll bet someone still has one in service. In 1979, when I was an Explorer Sprout at the Gaithersbug IBM Federal Systems Division, we saw (and used) one of these MSS devices. The systems guy who was our chaperone said that the MSS was prone to dropping spools on the floor of the unit, and CEs would draw straws to determine who got to fetch them, since it required ducking the arms. I don't remember ever seeing an "off-line" switch. The MSS had two arms. In its early days, bugs in the controller software reportedly would allow the arms to collide. There are still some of us at SHARE who wear the old data cell strips as badges to show that we support unsupported systems. One point frequently made is that a nice smooth strip cannot be properly called a data cell strip; it must be folded, spindled, and mutilated before it can be considered authentic. One favorite nickname for the Data Cell (officially the "2321") was "noodle picker" because of the way it retrieved the strips from the carrier. That was when it accidentally worked as designed; more commonly (it seemed) it was called the "noodle stuffer" for what it tried to do with the strips when it was finished. The device was IBM's attempt to provide a storage device for massive data bases which could tolerate significant delays in retrieving data. Nice idea, but the hardware would have made Rube Goldberg envious. Perhaps the best summary of the problem was an emergency software fix (PTF) IBM released for the online test procedure (OLTEP) because the diagnostics were destroying the pick finger. Robert Rannie of Nothern Illinois University has a standard spiel when he hands out an old strip: "This strip contains 200 K of official Atomic Energy Commission secrets. (Note that I said 'Atomic Energy Commission', not 'Nuclear Regulatory Commission'.) If you can read them, you deserve to have them." The strips don't really have AEC secrets on them, but the spiel summarizes the frustration of users saddled with the units. Best use I found for one was several years ago when I was at a SHARE meeting in Denver. Several of us went to the Traildust, a steak house in Arapahoe which forbids male customers from wearing ties: if a customer is found wearing one it is cut off and stapled to the walls. The net result is that unless they've taken it down there is a data cell strip attached to the wall there with my business card stapled on it...