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.