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
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
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
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
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
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
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.
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
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
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
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
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
and felt a LOT more like a computer than it did like a
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
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
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
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
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
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
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,
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"
DOS.D -- 5500 instruction set, 10-25-60Mb disk
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
Now let's advance to the "additional information" pages...
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
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).
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
kinds of ultimately pointless debate about the internal mechanisms was to
simply state that ARCnet "worked by a miracle" and let it go at
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
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
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.
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.
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
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
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
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
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
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
(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".
still support several of my consulting customers happily running such
Databus-based applications systems.
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.
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
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.
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
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
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
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
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
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!