The Inside Story of Texas Instruments’ Biggest Blunder: The TMS9900 Micro

[Stuart]

The Inside Story of Texas Instruments’ Biggest Blunder: The TMS9900 Microprocessor

 

http://spectrum.ieee.org/geek-life/history/the-inside-story-of-texas-instruments-biggest-blunder-the-tms9900-microprocessor

 

 

 

 

[+chue]

Fascinating story. IMO Motorola should have won that race. (68K assembly rocks! I have fond memories of doing assembly on my Amiga.) But it was not meant to be...

Edited June 23, 2017 by chue

[+Ksarul]

Here's the section on the 99/4

[jbdigriz]

The gist seems to be that the 9900 failed as a personal computer platform due to lack of peripheral chips, and to some extent the memory-to-memory architecture (which has compensating advantages). Maybe that was true in '76-'77, but by the time IBM was designing the PC, probably not, though I want to look into that. It is true TI would have done better to extend the 9900's address space, add an MMU, hardware floating point, or etc. rather than spend a lot of time developing the 9980, which never really got anywhere. And the 99000 probably should have been 32 bit. I don't think though that it's fair to say that the 9900 was a failure except in marketing terms. 16 bit systems design around the 9900 still scream for the clock speed, especially now that fast RAM is cheap.

 

Was Betamax a "blunder" in anything but marketing terms?

[Andromeda Stardust]

I only loved Texas Instruments for their graphing calculators...

 

Edit. Interesting read. I noticed that Motorola lost the IBM race, but didn't Apple use 68k for a long time before switching to Power?

[Willsy]

The article read (to me) like he had some sort of axe to grind. Agree the 68K is the better CPU. I prefer the instruction set of the 9900 though but that's probably just familiarity bias.

 

However the COC and CZC instructions are WTF's for me!

[mizapf]

However the COC and CZC instructions are WTF's for me!

 

When you have a word whose bits have particular meaning, like the status register, you may want to check if some of the flag bits are set or not. For instance, the status register's leftmost bits are L> and A>, for a positive result of an unsigned and of a signed compare. Maybe you want to check if both are set; the status register would look like 11xxxxxxxxxxxxxx with x being "don't cares". Suppose you have a copy of the status reg in R1, then you can load R2 with C000 = 1100000000000000 and test whether the one bits in R2 have corresponding one bits in R1.

 

If you want to do the opposite, that is, check whether the status register is 00xxxxxxxxxxxxxx, you also set R2=C000 and check whether there are zeros where R2 has ones.

[Asmusr]

 

When you have a word whose bits have particular meaning, like the status register, you may want to check if some of the flag bits are set or not. For instance, the status register's leftmost bits are L> and A>, for a positive result of an unsigned and of a signed compare. Maybe you want to check if both are set; the status register would look like 11xxxxxxxxxxxxxx with x being "don't cares". Suppose you have a copy of the status reg in R1, then you can load R2 with C000 = 1100000000000000 and test whether the one bits in R2 have corresponding one bits in R1.

 

If you want to do the opposite, that is, check whether the status register is 00xxxxxxxxxxxxxx, you also set R2=C000 and check whether there are zeros where R2 has ones.

 

To test a bit in a memory word using COC you have to load the word into a register first, and then I find it's usually easier (and faster?) to use ANDI to test the bit.

[Stuart]

 

To test a bit in a memory word using COC you have to load the word into a register first, and then I find it's usually easier (and faster?) to use ANDI to test the bit.

 

With COC though, by having the 'operand' in a register, it does allow you to (for example) easily check each bit position in a loop. So it all depends what you're trying to do.