From: dnichols@d-and-d.com (DoN. Nichols)
Subject: Re: VCS processor (was Re: Game machine processors)
Organization: D and D Data, Vienna VA
Date: Sat, 9 Jan 1993 20:38:25 GMT

In article <1993Jan7.094705.14127@sol.ctr.columbia.edu> slb22@cunixb.cc.columbia.edu (Seth "the Lesser") writes:
>markz@ssc.wa.com (Mark Zenier) writes:
>>
>>There were several early oddities around in the mid 70's.  One was

	[ ... ]

>Now the TMS-9900...THAT was a microprocessor you could be proud of.  I still
>can't understand how TI started with a great architecture like that and made
>such a wretched computer out of it.

	Two reasons:  One - they were *Control* freaks.  They couldn't bear
for anyone outside their domain to write code for the machines.  The other
thing is that they dragged their feet on pushing the chip at first, because
it executed the instruction set of their *minicomputer* line, and the
minicomputer branch was afraid that it would hurt their sales.

	The first thing that I saw using it was a SBC manufactured by
Technico, which had the CPU, a serial port, 1K of ram, (or was it 4k), and
16-pin dip headers which were to be jumpered to other boards to add more
ram, I/O devices, etc.  The monitor ROM was impressive after working with
the micro-sized ones for the Altair 680b and Mikbug (for the 6800 - in
256-bytes of eprom.)  It even included a line-at-a-time (no labels)
assembler.  When you got far enough ahead to define your target address, you
would go back and patch in the address.

	Of course, it had its weaknesses, too, depending on what you wanted
to do with it.  It had no stack, stored return addresses in one of the
registers, etc.  For non stack-oriented languages, you could get a lot done
with those replacement register sets.  However, having the registers live in
RAM was somewhat of a drawback, since on most cpus, register access was a
speed advantage, because you didn't have to do a memory fetch.  With the
9900, you had to do one or more memory fetches for *everything*, which
slowed the system down quite a bit.  A later version of the chip addressed
this problem in part, by putting registers on the cpu chip, and going to
physical memory only when the contents of the register was modified.

	Also, the bit-adressable I/O looked like a neat idea, and for many
things it was, but when I started trying to design a disk interface for the
system (they didn't have a disk controller chip for the system then, I think
that they came out with one later), I discovered that I couldn't clock a
byte in fast enough for floppy I/O, since each *bit* took its own clock
cycle.  I believe that the floppy controller for the Technico 990 wound up
using memory-mapped I/O to get the speed, and there really wasn't that much
address space - 32k of 16-bit words.  (Same number of bytes as the 8-bit
micros had, but it used them up two at a time. :-)

	I wish that I had had the money to get more memory cards and a disk
card for the beast.  It was a fun assembly language, even if it did have the
sense of "branch" and "jump" inverted compared to the Motorola CPUs. :-)

-- 
 Email:   <dnichols@d-and-d.com>  |  ...!uunet!ceilidh!dnichols 
		 <dnichols@ceilidh.beartrack.com>
 Donald Nichols (DoN.)  |   Voice (Days): (703) 704-2280 (Eves): (703) 938-4564
	--- Black Holes are where God is dividing by zero ---
Newsgroups: alt.folklore.computers