D > DATAPOINT CORPORATION > Datapoint 2200

Long...long but fascinating 'Read more' page...  See also the "Mini-forum" section. New information from Adrian Barnes: I worked in the service department of Datapoint/Intelogic Trace for around eighteen years. I serviced an area Between Holly, Michigan and Sault Ste Marie, Michigan. The 2200 was the most popular in that series. The 1100, 2200, 5500, and 6600 were manufactured in San Antonio, Texas on Dataopint Drive which was just up the road from the Datapoint headquarters. On these models the software is upward compatable. The software when used as a stand alone data collection unit is CTOS (cassette tape operating system). A boot cassette was put in the front tape slot and any data collection cassettes were put in the back slot. Any periferals that were used with these were attached with a fifty pin I/O cable to the the back of the processor. These periferals were 8" floppy drives, Modems, Serial (async) adapters, mulitports, hard drive controllers, and printers. Other equipment was Manufactured, Sold , and Serviced by Datapoint. These products included 1500, 1800, and 3800 processors and a dot-matrix printer called the Freedom Printer. Perifierals from other manufacturers were sold with the Datapoint name on them also. Some of these were GE, Dataproducts, and Centronics Printers, and Diablo, Wangco, Telex, and Memorex Hard Drives with removable disks. The networking that Datapoint used was called ARCNET (Attached Resourse Computer Network). This was done with HUBS (one computer to each port) both passive and active hubs with a maximum of 255 octal addresses per network. From Barney Fleetwood: I worked for Datapoint in the Technical Support Department from 1979 until 1985 and for Intelogic Trace from 1986 until 1994.  Intelogic Trace was a spinoff of the former Datapoint Customer Service Division. Datapoint was indeed the pride of San Antonio and was the undisputed industry leader in networking and distributed data processing in the late 70's and early 80's.  They had more networks installed than all the other computer companies combined, including IBM.  Their network protocol was Arcnet which today is simply known as Arc. Hindsight is a wonderful thing but the demise of Datapoint was created by a few greedy people.  First off they insisted on keeping all of the products proprietary and turned their backs on open archtecture.  Then they started shipping product to warehouses and recording it as sales.  This opened the door for a corporate raider named Asher Edelman to step in and take control of the company and it's dwindling assets.  He had already raided several company's but this was his largest undertaking.  He did make what seemed at least a token effort to rebuild the company instead of destroying it.  It was too little too late and Datapoint is a mere shell of it's former self and now headquartered in Paris, France.  I believe Mr. Edelman is still the CEO. Peter Theune memories: The Datapoint 2200's where in use at my data center at the Naval Air Depot Operations Center, NAS Patuxent River, MD, USA well into the late 80's. BTW, the network used by these systems was called ArcNet, and if I remember correctly, was supported by other systems as well as the Datapoints. As you can imagine, the small CRT was a major 'losing' point on these machines, as well as the somewhat cumbersome networking tools. At the Pax River site, almost all, if not all, programming on these was done in Cobol. They were still in use when I retired from the US Navy in the spring of 1988. I seem to recall that we still had factory maintenance on these at that time as well. Geoffrey Vasiliauskas recalls: I actually owned a Datapoint, it was my first computer, the 2200 if I remember, although mine was manufactured around 1974 I believe. You describe it very accurately, its only sound was a loud beep produced by a speaker within the keyboard if I remember. The screen was very small, green against black. I think the width was a strange number, something like 24 by 16 characters. There was no microprocessor on the "motherboard" (several boards competed for that title), it was implemented discretely. I didn't have a casette interface, my DP used a bay of four 8-plus inch floppy disk drives which sounded like a small airplane warming up for take-off on the tarmac. A friend owned a DP 2200 or at least the same series I had which used these large disks as storage medium. The disks were quite heavy and were encased in sturdy off-white plastic cases which could have held motorcycle tires. The circuitry was something artistic, all the connectors but also all the internal circuitry was wired in gold and some silver I believe. According to my manual, which I still own although it is thousands of miles from here, the Datapoint's 4 bits of processing power was augmented by something novel, "virtual memory" which allowed writes to a disk cache to boost operating memory or something like that. I believe this was the first time the phrase virtual memory was used, and its first implementation. The size you quote isn't correct. It is as far as the CRT unit is concerned, but the datapoint had an equally large power supply (mine ran on 220 volts, not 110 volts as you wrote), and the storage media were even larger. Plus it was a desktop computer in the sense that it came with its own desk! It was built into a table structure made of heavy-duty plastic, metal and bolts. So the power supply was hardly internal, although the terminal/CRT unit may have had its own, and my power supply box was an accessory to feed the disks, printer and the CRT unit. Overall the desk unit measured about 6 feet long by 3 feet wide and stood rather high off the floor. With accessories it occupied a small closet worth of space. The keyboard had on-board chips, it had its own logic. Datapoint offered support via a 1-800 number, but it no longer operated by the time I acquired my machine ca. 1985. Besides machine code, there was COBOL available. Perhaps by cassette-based OS you meant the large hard disks, which were technically cassettes, although "storage drum" is a better description. They certainly weren't tiny. Craig Brown writes to us: I worked in final assembly at Datapoint Corporation from 1978 to 1985. Datapoint continued to manufacture computers into the late 1980s. All manufacturing took place in San Antonio Texas, the coporate headquarters, and the company is still there today although it is a much smaller and different company. Datapoint manufactured many different types of desktop computers as well as an automated telephone switch called "Infoswitch". The models 2200 through the 8600 all used CTOS (casette tape operating system) with a dual casette deck on top of the housing as shown in your photo. Typically the 8600 would be the "Processeor Terminal" and it would have several model 1500 "dumb terminals" connected to it in a small office environment. We also built these huge Daisy wheel printers called the "Freedom Printer" Other models that I remember were the 3600 and all of the 8800 series which were a huge step above the old 2200. The 8800 was refered to internally as "Mesquite". Many other products were produced and Mr. Vasiliauskas is correct in that we built whole work stations where the monitor, keyboard and dick drive were built into a desk. We also did some privite label computer equipment for Honeywell and many european companies. Datapoint was once the pride and joy of San Antonio and had thousands of employees worldwide. It was a great place to work and learn. The copany was "raided" in the 1980's buy two fellows from New York. One was named Asherman the other Edelman. The computer service company called "Interlogic Trace" was a spin-off of Datapoint. Mark Massey reports: I used to manage a small shop that ran with DataPoint systems. If I remember correctly it was called the 4630 and mine had a 6600 series processor and two 10 megabyte disks. One was fixed and was a cartridge. Each disk cartridge was about 14 to 16 inches across and about two inches thick. The machine was amazing. Mine had 128 K of RAM. We used to run the Datashare multi-user interpreter environment and Datashare was also amazing. The thing could seriously run multiple business applications at the same time. Datapoint used to advertise that it could handle up to 24 terminals at one time. Well maybe if many of the terminals were using the same code (it was reentrant code - meaning multiple people could share the same code page). Datashare was so cool! It truly could pretty well service 8 to 12 different users. You could even call out to assembler routines from Datashare. The language that was used was a proprietary one called Databus. I think it eventually reached ANSI standard status. Great language for business data processing! Back then a programmer was not a programmer if you could not optimize your code and bench check it too. And write so people could understand the character based interface! It ran its own DOS and eventually a more fully featured OS called RMS. We ended with other DataPoint gear too. It was reliable, a real business class product. And in the day it was an amazing value too. Truly such a good value as to be an absolute IBM killer if you could make the very narrow minded IT Directors of day look past IBM. IBM products with any kind of similar processing capability cost at least three times as much. I know I did the cost comparisons myself. If I recall correctly the demise of DataPoint started when some sales managers and sales reps overshipped products and that lead to cooking of the books(shades of Enron). This caused the stock to crash and SPLAT that was that. It was very hard to fight IBM et al back then (still is I'm sure) and the one thing you must NOT do back then was to look shady because TRUST was (and is) the critical ingredient to business; so they crashed...I am sure others can tell the story of the demise better then I but when the stock went South management went crazy trying to fix the balance sheet and starting firing people they should not have and just generally the company could no longer compete and SPLAT it was raided and that was that! Joe Dumsha contribution: Actually, it was a man named Asher Edelman who raided InteLogic Trace, not Datapoint. I started with Datapoint in '82, working mostly on 55/6600 systems with Wango drives, one fixed , one removable. Datapoint also had a very innovative product called LiteLink, where you had lin-of-site wireless data communication from building to building. I recall taking whole days to perform index-to-data, MFM and head-alignment checks with my oscilloscope. They truly did "Spark The Revolution", as thier one and only TV commercial claimed in the early '80's as a last gasp. Truly the first shared peripheral and resources networked that would still be on top of the markey had they opened thier architecture. Datapoint in Israel, from Kobi Haron: I programmed Datapoint systems from 1977 to 1983 while working for a service bureau and later for a tour operator in Israel. At that time Datapoint sold plenty of equipment in Israel, including large Instllations in the air force and the navy. My 2200 system had 16K memory and two 5MB removable hard disk drives. It supported 4 dumb terminals. The 5500 had 512K memory and two 67MB crash prone multi platter hard drives. It supported 8 dumb terminals. The big draw of Datapoint was the ability to support those dumb terminals at reasonable cost, and the ability to upgrade to a LAN. Databus programming was a crude affair, as the language, hailed as "COBOL - like" and "Business oriented" was actually rather limited. For example, arrays were not supported. The Datapoint Disk Operating System was used in two modes - in time sharing mode the system console wasn't in use, and the terminals were supported. In the DOS mode I could do system maintenance, sort (which was fast and flexible) and compilations. To sort (or compile) I had to roll out my online users, do the sort and roll them in again. To avoid this disruption my boss had to buy a single user workstation that could run its own DOS. Then I moved on to another company that used VAX - VMS systems which were, technically, much nicer. Major contribution from Gordon Peterson who started working in Datapoint Software Development in 1974 and worked there through 1983. I was responsible for development of the company's Disk Operating System post-DOS 1.2 and (in Advanced Product Development) was the person responsible for the ARC System (LAN) software (which I proposed and wrote). There are a number of errors in your present pages and also in some of the "extra information" page data.  I'll try to set many of those right with this message, as well as adding a little more information that you apparently didn't have before. On the Datapoint 2200 page: You've got the chronology wrong about the birth of the microprocessor. Computer Terminal Corporation started out (as you might imagine) building "glass teletypes" and for a time was the largest third-party manufacturer of CRT-based computer terminals.  One of the keys to their success was a patent for an unusual way of "painting" alphanumeric data to a CRT display... the "diddle scan".  Instead of a television-style "raster scan", the (early) Datapoint displays instead painted each character, column by column, then the next character column by column, and so forth, and then row by row to the bottom of the screen.  This patent allowed them to use (relatively slow, but much simpler and less expensive) CMOS shift-register memories to hold the data on the screen and refresh it at the required rate.  They only needed to access each position in that memory ONCE for each screen refresh, since they only had to check each character cell ONCE per refresh, and then painted all 35 pixels of that character (7 high by 5 wide) before continuing to the next character on the same row. As a result of these terminal sales, Computer Terminal Corporation was at the time the world's largest buyer of MOS memory.  One of their successful products was the 3360 terminal system (which was a clustered system based on a rack-mounted HP minicomputer and the 3360 terminals) which were a successful replacement product for the IBM 2260 clustered CRT display system. At the time, anyhow, all these terminals (as sold by different manufacturers) were chaotic;  there were no real standards for things like cursor positioning, handling of characters displayed past the end of the line, screen scrolling (the 2260 and 3360 didn't even support scrolling at all!), wrap (or not) at end of line, baud rates, parity, how many bits long characters were, or indeed much of anything.  Everyone's terminals were different, and the result for a third-party company building "compatible" CRT terminals was a confusing maze of factory strapping options that had to be specified when the terminals were ordered. It seemed like it would be simpler and better for everyone concerned if these terminals could be configured in SOFTWARE to implement all these kinds of options, and a fellow named Vic Poor (who I think was at Frederick Electronics at the time) decided that it shouldn't be all that difficult to implement the simple instruction set required with few enough gates and parts that it could be implemented on a single and relatively inexpensive silicon chip, and also could use the same kinds of serial shift register memories that the company already was buying in large quantities.  Vic, another fellow Jonathan Schmidt, and a young man named Harry Pyle rapidly evolved the concept (Harry was notably responsible for the use of a hardware stack as the subroutine call return address mechanism).  The use of the shift register memory for programs was the reason for use of LSB-MSB byte order... (which Intel uses to this day!) it allowed readily propagating the carry to the higher order byte of addresses, since the high-order byte was the next byte to come out of the shift register that held the program. [Note that this microprocessor was not "shopped around" to other companies.  It was intended for CTC's "terminals" from the beginning.  Case Western Reserve University was indeed significant in the history of CTC... I think that Harry Pyle attended there (but as a student, not as a professor) and Mike Green (who made a number of contributions to the company's software over the years, including notably writing the STATH (String mATH) package that Databus used) was likewise.  Harry wrote much (most, probably) of the original software for the 2200, including the CTOS, the initial Databus language compilers/interpreters, and the first three releases of the original Disk Operating System (through DOS 1.2, when I took over DOS development).  By the time I arrived in May 1974, there were maybe eight or ten programmers in Datapoint Software Development. The machine (which became the 2200) was prototyped using TTL and MSI parts, and in the end the TTL/MSI implementation was the production version throughout the 2200's lifetime. A number of integrated circuit manufacturers were approached to make the part (which was to become the first general-purpose 8-bit microprocessor on a single chip) and nobody really wanted to make it (Intel, in particular, was convinced that there was no market for a general-purpose microprocessor on a chip... Intel was a memory company... but since Computer Terminal Corporation was the world's largest buyer of MOS memories, it's fair to say CTC had Intel's attention since they saw it as a way to cement CTC's memory business).  In the end, TI delivered a prototype part (but it barely worked, the rumor was that there were but millivolts of difference between signal and noise levels) and Intel's one was significantly better (but was delivered very late).  CTC had meanwhile started shipping the 2200 in the MSI/TTL implementation.  The Intel part (which became the 8008) was enough of a hassle to interface, wasn't as fast as the MSI/TTL version, and was pricey enough that in the end CTC decided to give Intel the rights to the part in exchange for being relieved of the obligation to buy them (of course, don't grieve for Intel, in the meanwhile they had become convinced that maybe, just maybe, there WAS a market for a single-chip, general-purpose microprocessor after all! :-) ) There is a thesis written by a student several years back which went into all this early microprocessor history in great detail, including contacting and getting interviews with most of the key players.  I'll try to locate my copy of that he sent to me and make it available... it's probably the best single historical document about those issues that has been produced to date. Finally, I think the first company to actually implement and ship an 8008-based system for small offices was a company in New York called Q1 as I recall.  For whatever reason, they didn't succeed and that company closed after a few years. Meanwhile, the Datapoint 2200 was amazingly innovative for a whole variety of reasons.  In a day when computers universally used big and heavy transformer-and-capacitor-based power supplies, the 2200 contained an exotic switching regulator power supply (positioned across the back side of the unit).  It was the first complete, general purpose business-oriented computer system in a single, attractive (designed by Jack Frassanito, to give credit where credit is due) desktop enclosure that was the size of an office electric typewriter, and integrating a CRT display (12 rows by 80 columns), office-style keyboard, and digital tape storage.  The traditional row of bit-oriented toggles and blinking lights (found on most all other computers of the era) was replaced by the five keyswitches at the right of the keyboard... (top to bottom:) RESTART, STOP, RUN, KEYBOARD, and DISPLAY.  There were (incandescent bulb) indicator lamps under the lowest four... STOP and RUN reflected the status of the processor, and the KEYBOARD and DISPLAY lamps were software-programmable. The two digital cassette tape drives on top of the unit each held about 150K bytes and could read (and write?) both forwards and backwards, at two speeds (programmable) plus a (faster) rewind speed.  At normal speed they could read or write 350 characters per second (as Vic once pointed out to me, that looked pretty good compared to punched paper tape speeds, which was the standard for minicomputer temporary storage at the time!) The 2200 was delivered with a Cassette-Tape-Operating-System (CTOS) with a tape file structure and directory, keyboard commands, a cassette-based general editor, several cassette-based compilers and an assembler... this machine looked and felt a LOT more like a computer than it did like a "terminal"!!!!  When the RESTART key was pressed, the rear tape would (by a hardware bootstrap process, NOT firmware!) rewind to the beginning, then start moving the tape forward and read the first block of data from the tape into main memory (starting at location zero), then stop the tape deck, and pass control to location zero.  Normally that block would be a bootstrap which would proceed to find and load the next file from the tape, which would be either CTOS or (on a "load-and-go" tape) the editor, compiler, or whatever other program was on the tape. The 2200 came in two versions... Version 1 and Version 2.  Version 1 used serial shift register memories for program storage (which had 'drum-like' timing characteristics, which is where some of the confusion may have come from) and a seven-level subroutine call stack.  Version 2 used random-access memories for program storage and had a larger 15-level subroutine call stack.  Version 1 used one to four memory cards, which had 2K bytes each, for a maximum of 8K.  Version 2 used one to four memory cards, which had 4K bytes each, for a maximum of 16K bytes.  Version 2 supported a programmable timer interrupt which could pass control to location zero every millisecond... the only interrupt supported by the system. The CTOS ran in 8K bytes of RAM (for the Version 1) and ran (better) in 16K bytes.  The system would run, in small configurations, with 4K bytes of RAM (there were several limited versions of the Databus programming language which could run in 4K of RAM). The DOS could run in 8kb and up configurations, although in practice most or all 2200-based disk systems were 16K machines.  The DOS included a simple software-based debug facility which could (among other things) include a real-time program counter display in the last column of the CRT display... so debugging (even on 2200s) wasn't QUITE as bad as has been suggested.  :-) As for mainframes of the era, the other members of the "seven dwarfs" were NCR and RCA.  For a long time the "other" companies besides IBM were referred to collectively as the "BUNCH"... Burroughs, Univac, NCR, Control Data, and Honeywell. It turns out anyhow that Datapoint never bought and used the 8080 either.  By the time it was released, it was "too little and too late" since Datapoint was already well along in developing the 5500 (which was MUCH faster and much more capable, in general).  The 5500 came with 48kB of main memory (3 16Kb memory boards) plus an additional 8Mb of RAM contained on the BIOS ROM card (containing bootstrap code and a BIOS=based software "debugger" tool). I had previously "usurped" the 8K of RAM on the BIOS card for use with my virtual-machine Partition Supervisor, which allowed running multiple independent copies of the DOS within the memory space of a 5500.  (The release version was restricted artificially to just two partitions, one Datashare partition and a DOS partition).  When it came time to develop the ARC System, I used the same 8K of RAM (actually just 7.75K, since one 256-byte page of that 8K was used by the debugger tool) for ARC... 4K for an emulation of the data buffers (normally in the disk controller) and the remaining 3.75K for the ARC System client software, redirector, enqueue/dequeue subsystem, etc. When the ARC System was being developed, I/we initially wanted to call it a "network" but that was not accepted by management, since "networks have the reputation of being complicated and hard to manage".  My initial proposal document referred to it as "DISPDOS" (for Dispersed DOS, "dispersed" being a key part of the company marketing message at the time).  Other names that were kicked around at the time included Datanet (not cool, since Honeywell used "Datanet" as their trademark for their communications controllers, and they were a big OEM customer of Datapoint that we didn't want to annoy), DOSNET, and even (believe it or not) "Internet".  :-)  Eventually we settled on Attached Resource Computer, or ARC, demonstrating that it was a system to attach networked resources together to form a single, cohesive, basically seamless computing system. ARCnet and The ARC System was the first commercially available LAN, and ARCnet (at 2.5 megabits) was faster than the two megabits which was the speed Ethernet (still under development) used at the time (in its clumsy thick-wire implementation, which was never very successful... even at its later 10Mbits 'release' speed.  The second, thin-coax-based version was more successful, but Ethernet didn't really "get it" until they finally adopted ARCnet-style active hubs and ARCnet-style "interconnected stars" cabling topology).  The ARC System was proposed in summer 1976, I started coding shortly thereafter, and the system started coming up in its original release mode (good enough for me to move my development onto the new OS) in early spring 1977.  The first out-of-house installation for the ARC System was at Chase Manhattan Bank in late September 1977, and the product was announced to the public in a press conference on December 1, 1977 at the Plaza (Hotel) in NYC. At the time, I commented privately that we were pushing a big rock over a very tall cliff on that day, and that from that day forward the days of mainframes for business computing were numbered.  Even my friends said, "Gordon, you're crazy... companies will never give up their mainframes and run their processing on networks of little computers!"... My reply was simply, "JUST WAIT AND WATCH!" :-) The 2200 never exceeded 16Kb... although that was augmented (slightly) by very clever use of the "speed buffers" of the disk controller (4 256-byte pages in the 2250-350 disk system, and 16 256-byte pages in later disk controllers) in conjunction with Datashare's "virtual memory" approach, which interpreted compact compiled pseudo-code directly out of the disk controller buffers. The 2200 had very limited ROM... basically just a hardware character generator used for refreshing the CRT screen display, but it was not (in the original version) program-accessible.  A later "RAM display" CRT controller board for the 2200 added program-alterable character generator (which was initialized from the ROM copy, but the ROM was still not program-accessible as such). The 2200 through 6600 systems all used diddle-scan displays and thus did not support any graphic modes (the character rows on the screen were separately scanned and did not meet on the screen) although some limited "graphic" capabilities could be achieved by dynamically loading the character generator under program control. The beep capability on those systems did not use a beeper "in the keyboard". There was a small speaker on the (inner) front panel of the computer, approximately in the 5-o'clock position under the "D" logo.  No speaker grille was present (nor was it required).  The processor supported two interesting instructions to control the speaker... a "Beep" instruction and a "Click" instruction.  Other tones and sounds were later produced by combinations of those two instructions, including "clicking" at a rapid rate which could implement tones at other frequencies. Actual dimensions of the 2200 (and 5500 and 6600) were 9-5/8" high, 18-1/2" wide, and 19-5/8" deep.  The 2200 weighed 47 pounds (I'm not sure how many memory cards that figure includes). The 2200-family processors supported up to 8 serial terminals... 5500 and 6600 systems supported up to 24 terminals.  Initially, the single-user Databus programming language had been upgraded to a timeshared/multiuser mode (called Datashare) to make good use of a bunch of the company's 3360-type terminals which had been coming back in off lease.  Datashare systems ended up being the company's "bread and butter" product, an astonishingly capable and efficient system which mated perfectly with the hardware's capabilities.  Initially it was thought that the reason for Datashare's great success was because it reduced the cost per terminal-hour, but I'm convinced that at least as important was the fact that it allowed multiple users to interact very effectively against a common shared base of data files.  Of course, the ARC System (where suddenly it didn't make much difference where files were physically located within the aggregate system) only enhanced that quality, and really was the enabling springboard that set the company up for unprecedented growth and success from 1978 through the early 1980's. The ONLY I/O connector on the 2200 (/5500/6600) system was the 50-pin I/O connector on the back next to the power supply, which was basically the processor's I/O bus.  Other peripherals (serial, printer, LAN, disks, etc) were daisy-chained using (via external interfaces) that I/O bus.  All I/O was programmed, byte-at-a-time through the accumulator. The 2200 (and subsequent 5500 and 6600) never used a storage drum.  The disk systems used by those systems included: 1A   E  Diablo 2.5Mb cartridge disk (1-4 drives) 1A   E  Wangco 2.5 fixed/2.5Mb removable disk cartridge drive (up to 2 drives supported, 4 disks)    C  F Shugart single sided/single density floppy disk drive (1-4 diskettes supported)   B D   Wangco 10 fixed/10 removable disk cartridge drive (up to 4 drives supported, 8 disks)   B D   Memorex 660 25Mb (2314/2319-type) mainframe-class removable pack drives (up to 8 drives supported)   B D   Telex (also 2314/2319-type) removable pack drives (up to 8 drives supported)   B D   CDC 60Mb "MIDS" removable disk drive (up to 3 drives supported) DOS 1.x  --  2200 instruction set 8-16Kb DOS.A    --  2200 instruction set, 2.5Mb drives DOS.B    --  2200 instruction set, 10 and 25 Mb disk drives (supported MIDS drives too?? no idea). DOS.C    --  2200 instruction set, 1 to 4 8" floppy drives DOS.D    --  5500 instruction set, 10-25-60Mb disk drives DOS.E    --  5500 instruction set, 2.5Mb drives DOS.F    --  5500 instruction set, 1 to 4 floppy drives (DOS.F was never publicly released) There were a variety of variants of the basic 2200/5500/6600 processors. Notable were the cassetteless versions: 1100         2200 instruction set, no cassettes, uses ROM, boots from floppy drive 1150         5500 instruction set, no cassettes, uses ROM, boots from floppy drive 1170         6600 instruction set, no cassettes, uses ROM, boots from floppy drive 6010         6600 instruction set, "64K" RAM, no cassettes, uses advanced ROM, boots from ARCnet 6020         6600 instruction set, "128K" RAM, no cassettes, used advanced ROM, boots from ARCnet Price of the 2200 varied depending on Version 1 or Version 2, and then one added memory cards.  A Type 2 2200 with 16K bytes of memory, as an example, sold for a little over $14,000.  The 2200-350 disk system (desk-mounted controller with one Diablo 2.5Mb disk drive) originally listed at $9800 and an addon 2.5Mb drive (in a floorstanding "tub") was about $8500 more.  These reflect 1974 (US!) prices. (I'm sure I still have a lot of other old price sheets around here). Now let's advance to the "additional information" pages...  Adrian Barnes... While there were a LOT of 2200s shipped, the 5500 and 6600 later substantially surpassed those, and (probably due to the success of the ARC System, and the larger disk systems) those two processor systems were the company's "workhorse machines" which most users eventually adopted. The boot is always done from the REAR tape deck, and not the front one.  Data tapes could occupy either drive but commonly would use the front deck, simply because it was easier to reach and the rear drive usually held a boot tape. The 1500 system was a quite different beast internally, and used a Zilog Z80 microprocessor (whose instruction set and I/O architecture were significantly different from the other Datapoint CPUs).  It was intended as a low-cost, entry-level system or for field offices, etc., and was remarkable because it was a complete, general-purpose, diskette-based system with lots of processing and communications possibilities at an entry-level price of just $6K. The 1800 system (and the similar, diskette-less 3800) used a different processor, designed to be a lower-cost (if significantly slower) machine.  The 3800 was designed to be a cheap[er], processor-based single-user workstation to hang off ARC Systems.  The 1800 was essentially a 3800 with one or two external floppies (and in fact also offered some other cartridge disk hard drives a little later on). Barney Fleetwood While I appreciate Barney's comments, his view was a remote one.  The main reasons why we kept the company based on proprietary stuff was simply because NOBODY ELSE MADE ANYTHING that was really very suitable.  When we first built the ARC System, we were in what was fixing to become a serious fight with SyFA/Computer Automation for our higher-end customers, and their machines were faster than ours at the hardware level.  The ARC System was the "unexpected" "disruptive technology" that hit SyFA like a ton of bricks... and by the time they realized what a significant product the ARC System truly was to our market, it was too late for them to seriously try to respond.  There were other reasons we didn't want to release low-level implementation details.  One of the big ones was because in other areas, people (who had NO business being concerned about really-low-level details) would argue endlessly about ultimately pointless details like register architectures, machine instruction sets, etc., when they in fact would NEVER EVER program the machine at anything remotely approaching that level.  Likewise, they would get caught up in low-level academic trivialities like "does CSMA/CD really work?" rather than dealing with bigger, more important, higher level issues like maintainability, extensibility, diagnosing and isolating faults, file and record locking mechanisms, conceptualization of remote resources, password and remote access security, and stuff like that.  We decided that the best way to eliminate all kinds of ultimately pointless debate about the internal mechanisms was to simply state that ARCnet "worked by a miracle" and let it go at that.  :-) Another reason for keeping stuff proprietary was because Datapoint had always 'given away' all its software for little more than the price of the distribution media.  (Some tentative company steps towards per-system software licensing were, like SyFA, largely derailed by the ARC System, where suddenly where software was installed became largely irrelevant).  Obviously, the development cost of the software was built into the cost of the hardware (and that's NOT a bad system, since it means that everyone gets to use the software, and it makes the hardware more compelling).  A "cherry picker" company who designed and built compatible hardware could have undercut our hardware prices, but that wouldn't have supported ongoing software development... it's not a plan with much of a future. As far as "open architecture", you need to realize that there was NOBODY even prepared to TALK about the stuff we were doing, and waiting for discussions and industry consensus would have taken YEARS and probably resulted in a product that (1) wouldn't have been suited to OUR equipment or customers, and (2) would have been less efficient and innovative.  Now, I do agree that it would have been (in retrospect) interesting to have implemented a version of the ARC System that ran on top of Microsoft MS-DOS (and/or IBM PC-DOS), and would have probably allowed Datapoint to usurp the growth of Novell which finally did the same thing, Datapoint was still hoping to migrate their customer base to still-more-evolved LANs incorporating revolutionary stuff (for the time) like laser printers, interbuilding LightLinks (high-speed optical LAN interconnects), and such.  Trying to support PC-class hardware would have diverted key development personnel off to other projects just when they were needed on more advanced stuff. The ARC System packet protocols were very much keyed to the features integrally provided by ARCnet, and ARCnet's feature set was quite different than the "dumb network" transport envisioned by the then-popular OSI model.  Fault recovery, for one thing, was VERY VERY different, and quite inconsistent with the OSI approach.  The ARC System's network architecture also used a very unusual model for distributing resources and computing throughout the network, including the distribution of rather low-level operating system functions... this was NOT a model designed for heterogeneous computing environments.  While there are other approaches possible (and we've seen them move to the fore over the years since then) I still consider that the approaches I used in The ARC System were the right choices (for a whole variety of reasons) at the time. Security reasons were another reason to not publicize the internal network protocols.  While a lot of effort had been made to make the ARC System secure, there was no valid and compelling reason to hand potential invaders a map, either.  It simply made more sense to force them to start from further back if they were going to try to force their way in. The "diverted product" issue probably ought to be explained.  Salesmen were urged to meet their sales quotas quarter-by-quarter, and the company was running significant order backlogs often reaching six to ten months or more. Salesmen urged customers to sign "tentative" orders, giving them credit for the "sale" and knowing that before the factory was ready to ship it, they'd have a customer for the equipment... either the original customer, or someone else who came in a little later.  In (rare) cases, they'd have the equipment delivered to a "self-storage" miniwarehouse if there was a gap of a few weeks between the time the equipment was ready for delivery (to an original purchaser who changed their mind somehow) and the time they'd found another eager customer for it. This worked for the salespeople as long as there were big production order backlogs, but as the factory ramped up production to meet the great demand they reached the point where salespeople were not able to place the gear as fast as the factory was shipping it, and that's when the "scandal" suddenly showed its head.  This was NOT a corporate headquarters malfeasance... it was salespeople trying to scamper to satisfy their customers, and be able to deliver customer equipment when those customers needed it.  The company got slammed for something they weren't really guilty of. When arb Asher Edelman took over the company, he expected it was golden (and it still was, sorta) but when he found that the treasure trove of rapid cash he expected to find hidden inside wasn't there, he realized that instead of just parting out and flipping the company, he'd have to actually run it (and that wasn't his forte).  Worse, his personality really wasn't compatible with Datapoint's San-Antonio-style entrepreneurial/innovative corporate culture... I actually met with Asher at one point and hoped I could engage him, but sadly there was no charisma or favorable personal chemistry there at all.  Peter Theune By the late 1980's ARCnet had become (for a time) THE standard networking protocol used by Novell PC-based LANs (Novell called it RX-NET but it was exactly the same thing).  Ethernet finally did get released (and in a 10Mbit version instead of the original 2Mbit version that Xerox and Bob Metcalf had developed) but it went through a dismal thick-wire version (requiring ugly and inconvenient 'vampire taps'), than a not-much-nicer "Cheapernet" coax-type version (linear bus, where you had to take the whole network down to add a new node anywhere other than at the ends, and where it was a nightmare to diagnose and isolate faults... and ANY point on the network could take the whole mess down with something no more complicated than a paper clip) before Ethernet finally realized the inherent "rightness" of ARCnet's "interconnected stars" cabling topology based on active hubs.  Once they adopted that key component of the ARCnet design, Ethernet finally became (relatively) practical... even though ARCnet still used its bandwidth far more efficiently and effectively than Ethernet did.  (ARCnet systems typically got about twice the effective throughput for a given bit rate than Ethernet did, and didn't collapse under heavy loading situations). The "small" CRT on the CPUs was an issue on 2200/5500/6600 CPUs but usually those were used as relatively dedicated systems... Datashare central systems or ARC System file servers, and for THAT use the 12-line screen was not a big issue.  Most user apps ran on Datashare terminals (24x80) or 3800-class machines (also 24x80). I don't know what Peter was talking about with the "somewhat cumbersome" networking tools.  In most ways, the tools offered by Datapoint for maintaining and operating the network were more flexible and more powerful than those offered by just about anyone in the networking business at the time.    I know that some users were using COBOL, but that was never a core product at Datapoint.  It was provided (like BASIC) for those customers who wanted to (or insisted on) using it, but the great majority of our key customers were Datashare users, and that was the software applications environment that nearly everything was designed around. Geoffrey Vasiliauskas The 2200 screen was 12 lines by 80 characters... a very "normal" number at the time, especially since the industry-standard IBM punched card (which was still king back then) was exactly the same capacity. The speaker could make a CLICK in addition to a BEEP.  One could CLICK repeatedly to make beeps of other frequencies, under software control. If Geoffrey had four floppies, he didn't probably have a 2200 (ALL real "2200s" had cassette decks).  He probably had an 1100. The white disk cartridges he's referring to are either the IBM-2315-type 2.5Mb cartridge disks (slide in from the front) or top-loading 10Mb cartridges (the one atop the 2200 on this site's main 2200 page is one of the 10Mb toploading disk cartridges).  He must have a small motorcycle.  :-) Geoffrey IS right that these machines were VERY well-built... they were quality in a way that one rarely or never sees anymore.  The heatsink in the back of the 2200 (on which the switching power supply was built) was heavy-duty CAST aluminum.  The whole system (once the cover was popped off) hinged up for easy access to the individual circuit cards.  The cassette drives were assembled by Datapoint onto a heavy, machined, aluminum baseplate.  Datapoint did not invent virtual memory, but Datashare did use virtual memory to astonishingly good effect.  Under Datashare, there were separate code and data spaces.  Compiled code was never modified (so never had to be paged back to disk) and was exceedingly compact... a typical high-level instruction might produce only three or five bytes of pseudocode.  Data space WAS resident in main memory, where it was always available without paging.  During the time that screen or keyboard I/O was being done (often MUCH of the time), there was often NO user application code at all in the system, other than the list of data items being displayed or entered.  When paging IN pseudocode, it was interpreted DIRECTLY out of the disk controller's speed buffers, eliminating the need (on 2200 systems for example) to bring in more than just the few pseudoinstructions actually needed from that sector.  (Datapoint disk drives used 256-byte disk sectors). Geoffrey is wrong about the size of the computer unit.  The "CRT" was in fact the WHOLE computer, power supply, display, and the rest.  The desk contained the disk cartridge drive, disk controller, and the power supply for those parts.  I realize that a lot of people were confused about what was where, and by the time the 6600 was coming to the end of its life as a product some folks within Datapoint argued that keeping everything in the "CRT" was no longer meaningful to our customers.  The result of eliminating that constraint was the (much bigger) 8800 CPU and that had serious implications to the factory regarding testability of the large circuit boards which resulted. The power supplies in the desk or tub powered the disk units and controllers, but not the CRTs or printers (except the Diablo-based daisywheel "servo printer").  Other printers always contained their own internal power supplies. The CPU unit had enough power in addition to internal needs to supply several communications interfaces but large and heavily configured systems could exceed the internal power capacity and so many external devices (such as RIM network interfaces) used auxiliary power supplies within the interface device involved. Programming languages available for Datapoint systems included seven versions of cassette Databus, disk and cassette assemblers (including a relocating assembler and linkage editor), BASIC, RPG II, COBOL, and a number of versions of the company's workhorse applications programming language, Datashare. The cassette-based OS "CTOS" was amazing (given the system it ran on) but ultimately few users were content to forego hard drives (or at least floppy diskettes).  Cassettes in the later years were mostly used for software distribution and as a robust and portable data transfer medium. Craig Brown The 8600 never supported cassettes.  Cassettes were only supported on the 2200, 5500, and 6600 models.  I don't recall if there was ever a model of the 1100 which had cassette drives (although it wouldn't have been hard to have offered that, since in virtually all respects the 1100 was just a rebadged 2200). Most of those systems almost never ran CTOS... the disk systems were far more useful as products.  CTOS was used for DOS generation cassettes when setting up a hard drive from scratch, and other diagnostic software, although in later years the packs were usually built and software installed onto the hard drives at the factory.  LGO (load-and-go) cassettes, where the application usurped the CTOS itself, saved time and were often more popular for users. The 1500 (Z-80 based) was not at all a "dumb terminal" although it was always something of the odd man out since it didn't run quite the same instruction set as most other Datapoint systems. The Freedom Printer was not a daisywheel printer.  The Freedom Printer was a dot-matrix printer (and basically the only printer that Datapoint ever built from the ground up).  Datapoint offered a variety of daisywheel printers, however, and the most popular used the Diablo "servo printer" mechanism. The 3600 was a dumb terminal, designed to be a cheaper replacement for the 3300 and 3360 dumb terminals.  It was the first Datapoint "dumb terminal" with a direct-view CRT (i.e. without the fancier tinted plexiglass over the screen).  That terminal, at least, was hardly "a huge step above the old 2200".  At a list price of under $2K, it was a very cost-effective terminal at the time. The systems where the "monitor, keyboard and disk drive were built into a desk" still used the complete computer system which was contained in the "CRT".  The desk provided space for the disk drive and controller, and (on the back, and in the tub) power strips and mounting locations for other communications, multiport serial, LAN, and other interfaces as well as space to dress the I/O cables more neatly. Datapoint for a time was a "Fortune 500" company with (for a while) more than 10,000 employees worldwide.  The company was THE early leader in local area networking. The "two" raiders Craig refers to was just one... Asher Edelman. Datapoint had built (believing that IBM-quality customer service was part of the key to IBM's success) a VERY good (but expensive) customer service and hardware maintenance operation.  While exceedingly good (and this gave customers confidence when using Datapoint equipment for mission-critical applications) it wasn't cheap, and this combined with the fact that Datapoint leased much of its equipment in use by its customers meant that customers willing to forego the "expensive" maintenance contracts were motivated to replace the Datapoint gear with cheaper PC-class hardware (which, even if not provided with similar service capabilities, at least could usually be replaced if necessary with a 'cheap' new unit).  Instead of trying to cut costs within the maintenance operation, the decision was made to treat it as a profit center and "cash cow" and eventually to spin it off as a separate company. Mark Massey The 4630 was indeed a 6600 series processor with 10/10 (10Mb fixed, 10Mb removable) Wangco disk cartridge drives.  Most of these systems used boot ROMs to allow booting from the hard drive, and many no longer had the cassette drives (which were costly to manufacture). A 4630 could in fact run up to 24 terminals at a time, even if they were running 24 separate application programs.  It would run really amazingly well (presuming well-written code) for such uses.  But Mark is right... Datashare was an astonishingly effective and powerful tool, and VERY well-matched to the Datapoint hardware.  The language is still being used on an everyday basis (although using PC-based implementations, and generally not with 'dumb' serial terminals) today at no small number of business customers... and there are still applications areas where its features are even today "the best solution".  I still support several of my consulting customers happily running such Databus-based applications systems. Joe Dumsha. Asher Edelman took over Datapoint, and one part of what he did to the company was to spin off Intelogic Trace (although I think he remained part of the team controlling Intelogic Trace, too).  "Opening their architecture" is always easier said than done.  Apple Computer has flirted with the idea several times and has retreated each time.  Part of the reason is that there are simply many innovative things you can do when you make BOTH the hardware AND the software that are difficult or practically impossible to do when you do only one side... the ARC System is a good example.   Kobi Haron I don't believe that the 5500 ever supported 512K of main memory... 56K is more like it.  :-)  The 5500 and 6600 still used a 16-bit address space, although one could map a larger physical memory within the smaller address space.  (Even if Kobi had a 512K system cobbled together on a homebrew basis, I'd be surprised if it was still on a 5500 instead of a 6600). It's true that Databus didn't support arrays, although it did offer a workaround in terms of a list of variables where one could load or store a value into a variable from the list selected by a numeric subscript.  While it's true that this isn't QUITE an array, it also offered some unique properties... you didn't HAVE to have the same sizes for the elements of the data list, or even for that matter the same type.  You could remap the individual elements in different lists and orders in different places in the program, if desired.  Like many things in the language, it was DIFFERENT, and programmers who were willing to think "out of the box" and develop innovative approaches based on the unique properties of the language were usually the happiest Datapoint programmers.  :-) The need to roll out to sort or compile could be largely mitigated by using LAN-attached processors or (for non-networked systems) my virtual-machine-like Partition Supervisor, which allowed running a DOS partition concurrently with a Datashare partition.  But as Kobi points out, most users finally decided that it was simply easier and more flexible to just add another processor to the LAN... an approach that more and more users have adopted as LANs have become (as they have today) ubiquitous.  Gordon also sent us this picture along with the following comment: This picture is historically interesting since it was taken in 1980 at a restaurant along San Antonio's famous "River Walk".  The pic shows me (on the right) and a friend Faro.  At the time the picture was taken, the (my!) ARC System was running in almost ten thousand customer locations worldwide, our ARCnet had more commercial installations than all other LAN topologies put together, Datapoint's success worldwide was running high, and the first cassette-based PC (which didn't support any kind of hard drive at all) wasstill about a year away... times were good...!  :-) More information from Germany: Hello to Gordon and all the others having worked for or with Datapoint. It was a real thrill reading the stories about the computer that was the first computer of my life. You did bring back some of the memories I thought forgotten. I worked for the Datapoint subsidiary in Germany from 1979 to 1981, first as a (not so successful) salesman and later as a systems engineer (more successful) for the application SW. Later on I was contracted by a customer as their one-man DP department 1981 to 1984, programming in Databus and the job-stream language called Chain and Chainpls. The latter no one have mentioned In this time I used 2200, 1500, 5500 mostly with disk drives. With the 1500 (32K memory) and the 5500 (256K) we supported 4 workstations, one system printer and one terminal printer (both were Freedom printers). The printers were served by Phantom ports and printed formatted print output from disk. The printing solution that I found was necessary due to the only obvious drawback of the Databus language: Databus' print command would load a print overlay that expected a very fast line printer, which the Freedom wasn't. So after the 1K printer memory was full, it would return a 'Buffer Full' and the overlay would abort. As the multitasking timer returned to the unfinished print job, there were maybe 5-6 characters printed, the overlay would be loaded again, delivering 5-6 more characters to the printer buffer and so forth. This slowed down all other ports for the duration of the print job. We got around this problem by writing print output to file, either by dedicated programming or using the SPOOL and UNSPOOL commands of the Databus language. Then we would use a special very simple print program that I wrote in two versions; one for the system printer and one for the terminal printer (the main difference was using the command PRINT for the system printer and DISPLAY for the terminal printer. These programs ran on phantom ports (that had no screen) and when idling they would access a circular print log about once every 10 seconds to see if there was any print job pending. Practically no overhead. When finding a print job for the printer in question, they would start reading the output file line by line passing them on to the appropriate printer with the PRINT or DISPLAY commands. For each line the program added the value 4 to a one byte numerical field. Whenever this operation made the field run over (result = 10 or more), it would return an 'over' state and a PAUSE of one second would ensue, giving the printer a chance to empty its buffer to paper. Very little overhead. Since most of the print output had to be dedicatedly written to file while the girls at the terminals entered orders that customers would call in, creating Bills, Bills of Loading, Transport Documents, UPS Labels as well as debtor's and inventory postings by and by while they worked, this represented no noticeable strain on the general system performance either. Only the printing of the bookkeeper's ledgers and other batch printing were noticed, but writing to file, it was over much faster than printing directly to paper, and so much less annoying. The owner went along with all this and was happy. Only when I suggested the girls, some of which were unwed mothers, get a modem and take their terminals home and work from there and saving the office space, he said no, they'd have to come to work. I was in the Frankfurt branch of the German Datapoint subsidiary that at first was called GIER and was a spin off from the Danish RC. GIER was first owned by TRW who held the marketing rights for Datapoint computers outside the US and Canada(?). The rights and the German operation was then bought back by Datapoint and Gier was renamed Datapoint Deutschland. By the time Datapoint hooked up with Taylorix and subsequently took Chapter 11, I had hired on as DP manager with a customer, nmc GmbH (nicknamed No Money Company), a smallish private limited company. For some time I saw the Datapoint sign on the former Taylorix building in Frankfurt, then it disappeared. For a while I didn't know what had happened to them, and then I suddenly discovered the Datapoint name tag along with many others on a multi-company building in a little town near Frankfurt. They evidently were making and selling SW solutions that would run on IBM PCs and clones. At one time I also applied for a job with them, as they had an opening advertised in the paper, but they didn't invite me for an interview. PS: Looking at Gordon's picture, I think I met him at a meeting in January '81 in Germany. One of the first laser printers, by Mike Towers: I worked at Datapoint from 1981--1985, as a techwriter in the Bansai laser printer group, and then tech pubs manager in the Datapoint Technology Center, which is what Vic, Jonathan, Harry, et al called R&D at the time. I had nowhere near the creative genius those guys had, but had the priviledge of hanging around with them and learning about what they were doing, albeit on a higher level, and then documenting and translating it into internal communications for the rest of the company. I like Gordon's discussion of Vic, Harry, and Jonathan, but he left out a few other prominent souls: Gene Hughes, the Donzis brothers, Neil Tompkins, Stan Kline, John Murphy, Mac Douglas to name a few, and geniuses everyone. Datapoint not only invented the architecture for the 8008 (and pretty much the microprocessor by extension) and the local area network, but also was one of the first laser printers back in 1980. Unfortunately, corporate hubris sunk the ship. When we suggested that we capitalize on the large investment we had made in the first laser printer by making a desktop version, we were told, "nobody would buy that." When a guy named Dan Price in International put together a skunk-works fax machine that worked on the net (with a little help from R&D), we were told that "fax is a european phonomena; Americans won't buy that." And on and on through video teleconferencing, light-based wireless data transmission, and all kinds of other really cool gee-whiz stuff. The REALLY cool thing is that all the back-office stuff was industrial strength and really worked. In contrast, I find Windows based applications about as reliable as my ex wife. The engineering and software people at datapoint truly were a uniquely gifted bunch who did wonderful and amazing things. Reaction from Ken Whitehead (Houston, Texas, USA) In reading the musings of several old Datapointers (I am certainly one) on the History page, I would like to correct a few errors (or memory lapses) and perhaps add some info as well. Datapoint manufacturing also took place in Waco, Tx and Ft Worth, Tx. I started at 9725 Datapoint Dr (the SA factory, aka “9725”) in 1977, moved to the Waco plant in 1980 thru 1983 when it closed, and Ft Worth 1984 thru when it closed in (iirc) 1985, whereupon I returned to San Antonio thru 1987. I rode the wave at Datapoint until we had less than 500 people left. The Waco plant was started as a response to SA’s highly unstable political climate of the mid-late 70s, and became the “Small Systems” (or depending on the name du-jour “Standalone Systems”, etc) divisions factory. Waco built the 1500 and 1800 systems and the 8200 terminal. We also built all of the 8” floppy drives, most of which were consumed by the 15xx/18xx systems, but also still used in some legacy 11xx systems, service spares, et al. We were the world’s largest manufacturer of the Shugart 8” floppy, taking it all the way to double-sided and double density. We eventually placed a 5 and then a 10 and then a 20(!) mb 5.25 hdd in one of the floppy bays of the 15/18 units. We even had a 10MB removeable (Honeywell “Cynthia”) drive option. The 15xx/18xx systems were truly a PC before the term was ever coined. I was the Mechanical Product Engineer for the Small Systems products, including the 8" floppy disk drive until it was replaced by an OEM 5.25" FDD. After the sales scandal, Waco production was transferred to the newer Ft Worth facility, where the Infoswitch telecom products were made. Since Infoswitch represented the future, and since Infoswitch development was also in the DFW area, Ft Worth became the survivor plant. In 1985 (iirc) the downward spiral finally caught up with that factory and it too was closed. I transferred back to SA where I remained until 1987. After about 1985, the company had retreated into a siege mentality. TV news crews camped out in the parking lot every Friday to catch interviews from those seen carrying boxes of personal belongings home. It was bleak and not much fun. Many of us Ex-Datapointers eventually wound up at Compaq Computer in Houston (where I worked 1987-2000). IMHO, Waco represented the cream of the crop as far as Datapoint Mfg was concerned, always looked upon as somewhat an odd bunch by the old boys’ club at 9725, and could get away with a lot of creative work that would never fly in 9725 simply by being 3 hours away. Waco’s products were THE high volume units of the company, and co-locating Sustaining/Product/Quality Engineering in the factory made them work together or die trying. I base this on 10 years of working in all 3 factories. Poor Ft Worth never stood a chance, it was started just as the carpet was pulled out from under manufacturing and much of the assembly talent from Waco didn’t make the move. Having the can-do go-go folks from Waco move into what amounted to a closed country club craft factory in Ft Worth set up a huge we-they situation that was only made worse by the general imploding of the company. 9725 to this day remains a classic example of how NOT to design a factory. A friend (Archie) once half-jokingly submitted a requisition for 2 cases of dynamite under the “Factory re-layout” project. Would love to hear from Gary Langerhans, Archie Wohlfahrt, and all the gang. It was fun while it lasted. I sure learned a lot!