Musings on 99000 macro code

[jbdigriz]

1 hour ago, dhe said:

So, yea for dfm - it started on the 990's and of course is very similar to TI-Writer/Editor Assembler editors.

I think you have the heritage of later versions of dfm figured out, Gleen took it and made it available for TI and later HPUX systems along with ISAMATION.

Larry Kroeker made a PC version available, at one point, I think Larry had a proto-windows version going.

I also think Larry has passed.

I did see an obit notice for a Larry Kroeker in McKinney, TX ca. 2011. Didn't see the full obit.

1 hour ago, dhe said:

In the past, TI was very pragmatic about licensing. So I imagine it was as easy as say Larry talking to someone in management along the lines of:

   Larry: Do you have any plans of selling dfm in the PC market.

   TI: No

   Larry: Do you mind if I do?

   TI: No, but we get 2% royalties and maintain our original copyright.

Tallies with what I've heard. Still want to nail down what ISSS was, but that's going on the stack for now. I'll be interested to follow Robert's take on DF-[SHOW,EDIT]  for modern OSes. He may be interested to know that 990 dfm supported tape files and encryption. I don't know if any of the DOS versions did. He may want to take a look at Midnight Commander, too, which bears a lot of DOS influences, possibly DF-EDIT and SHOW included. Looks like maybe he's following up an elder relation's project here? Wish him well with it, and maybe it will bear fruit with a new DOS or Windows version as well. Lot of people building retro DOS boxes these days. 

[Michael Anderson]

Strange that the Ten-X cobol accelerator would be discussed this late in Time.  That was my father's (Andy Anderson) and Freddie Walker's idea.  They got financing for the start up from friends and associates of another partner they picked up in the development Darren Appelt.  Ten-X is still around but reformed into another company named Ten-x precision.  Darren Appelt in my view would not be the best contact for questions about the Ten-X cobol accelerator.  Mark Gentry in Austin I think eventually became head of engineering at Ten-X to my understanding.  I can come up with his contact info if needed.  Michael Anderson

[jbdigriz]

On 12/6/2021 at 5:25 AM, Michael Anderson said:

Strange that the Ten-X cobol accelerator would be discussed this late in Time.  That was my father's (Andy Anderson) and Freddie Walker's idea.  They got financing for the start up from friends and associates of another partner they picked up in the development Darren Appelt.  Ten-X is still around but reformed into another company named Ten-x precision.  Darren Appelt in my view would not be the best contact for questions about the Ten-X cobol accelerator.  Mark Gentry in Austin I think eventually became head of engineering at Ten-X to my understanding.  I can come up with his contact info if needed.  Michael Anderson

Sorry I missed this till now, Michael. Appreciate the info!

[Ex-TI]

On 1/18/2018 at 9:26 AM, pnr said:

Hi,

 

Many thanks for that link! It explains why sometimes TI marketing documents refer to the 99120 as having the "Rx kernel" in macro rom and sometimes as having Pascal support instructions in it. In TI's vision for Microprocessor Pascal the two are closely linked topics.

 

 

This would be the manual "990/12 Writeable Control Store Assembler and Language". It describes the details of microprogramming a TI990/12, I understand. As the 990/12 was released in 1979, I would assume that this manual also dates from 1979, possibly with later revisions.

Did you ever locate the Writable Control Store manual?  I worked on that in the 80's and would love a copy.

[pnr2015]

On 1/24/2022 at 9:56 PM, Ex-TI said:

Did you ever locate the Writable Control Store manual?  I worked on that in the 80's and would love a copy.

Sorry for the delay in answering, but no, I have never found a copy of that manual. It must have had pretty limited circulation for no copy to survive. Micro-programming was (and is) a highly specialised occupation, I suppose. 

[apersson850]

7 hours ago, pnr2015 said:

Micro-programming was (and is) a highly specialised occupation, I suppose. 

I did it for a couple of processors back at school, but only then. So I concur.

[+FarmerPotato]

17 hours ago, pnr2015 said:

Sorry for the delay in answering, but no, I have never found a copy of that manual. It must have had pretty limited circulation for no copy to survive.

 

I found one title listed in the 1983 accession to the TI Archive, now at DeGolyer Library, SMU:

 

Model 990 Computer MDS990 Microcode Development System Programmer's Guide  2264445-9701

(Also, the stack location / box number.)

 

 I see  it referenced in the 990/12 Assembly Language Programmer's Guide.  
 

 

 

 

17 hours ago, pnr2015 said:

Micro-programming was (and is) a highly specialised occupation, I suppose

At the VCFSW event, I heard a talk on 6809 micro-architecture. The speaker recommended a 1993 textbook, "Microprogrammed State Machine Design". It is pricey.

 

 https://www.routledge.com/Microprogrammed-State-Machine-Design/Lynch/p/book/9780849344640
 

 

 

[apersson850]

I've written microcode for a bit-slice processor based on the very popular Am2900 series of components (Advanced Micro Devices).

The last CPU I wrote microcode for was the DSK 86000, a specialized two-chip CPU for robotics control. The microcode word was 80 bits wide, as far as I remember, in that one.

[+TheBF]

3 hours ago, apersson850 said:

I've written microcode for a bit-slice processor based on the very popular Am2900 series of components (Advanced Micro Devices).

The last CPU I wrote microcode for was the DSK 86000, a specialized two-chip CPU for robotics control. The microcode word was 80 bits wide, as far as I remember, in that one.

I have no experience with this at all.

What is a development system like for microcode?

Is there an instruction set?

How many instructions are in the set? 

[apersson850]

It's kind of the other way around, compared to using assembly (machine) language.

When you use assembly language you don't have too many bits (16 in the 9900) to define you instructions. But they can do powerful things, like MPY and BLWP, to take some of the more complex instructions supported by the TMS 9900.

 

When you do microprogramming you have far less advanced instructions available. If you build your CPU with AMD 2900 slices you have the different instructions the ALU can do, but that's not very much. On the other hand you typically have a much wider instruction word (like 80 bits in one system I programmed), where each bit can control for example setting/clearing a flag, moving a value from one register to another, shift a bit pattern to the left or the right, control if carry should propagate to the next bit, test a value against zero, test a value against another value, make the sequencer jump in the microcode unconditionally or based on a test...

 

What you try to do with the hardware architecture you have at hand is to figure out how many things you can possibly do at the same time, to make assembly instructions run in as few clock cycles as possible. Like read one value from memory, read the next value from memory and then read the next instruction from memory at the same time as you add the two values, since the ALU will not need to do a memory access to add the two values, then write the result back to memory at the same time as you decode the instruction you just read in and so on. Clever use of as much parallel hardware as possible will speed up your CPU.

 

That special robotics controller I was involved in did have an instruction set adapted to the special needs of robotics. Coordinate conversions are common, so it did for example support sine and cosine for 32-bit floating point numbers directly in assembly language. It also had a register file where you could do something similar to BLWP, but the subroutine call shifted the 16 register workspace 12 positions in the register file. Thus if you called a subroutine in high level language (Pascal at that time) with no more than four parameters, they were stored in R12-R15 and when the call was done, they were in the new R0-R3. Results could easily be returned without having to push everything on a stack. Multiple efficient subroutines were possible, as long as you didn't run out of the register file. Returning from the subroutine shifted the registers back, so the results now appeared in R12-R15.

[+TheBF]

Very very interesting. Thanks.

 

Was the 80 bit machine considered VLIW ? (very large instruction word) I had read about those in US military projects or some such thing 40 years ago. 

 

I have encountered something like this before in my reading. 

This bit slicing was used by Chuck Moore in his CPUs. 

They were only 16 bit machines but since the "registers" were actually the data stack there were no bits needed for register encoding.

The machine had < 32 instructions (really RISC)   so he used 5 bit instructions and some of them could be encoded into one instruction.

The last bit was special in that if it was set it triggered an automatic return after the instruction executed. Pretty clever I thought. 

 

There are so many interesting CPU architectures but now I find myself wondering:  What kind of CPU with the AIs will design for themselves? 

 

Forgot to mention the 10MHz version of this chip averaged 12MIPS with these encoded instructions.

 

[apersson850]

11 hours ago, TheBF said:

Was the 80 bit machine considered VLIW ? (very large instruction word) I had read about those in US military projects or some such thing 40 years ago.

No, the 80 bit wide instruction word is on the microprogramming level. Once such word is executed for each internal clock cycle. The user sees a narrower instruction, which when invoked executes a sequence of microprogram instructions (usually, some processors of RISC type executes everything in one cycle). In the particular case I don't remember how wide instruction words we had. Many CISC architectures have variable length instruction words. Like the TMS 9900 or the DEC VAX 11. Or, if you go the other way, the TI Programmable 59 calculator, which was different to the Hewlett-Packard 67. The TI 59 stored instructions in 1-6 bytes, the HP 67 always in one byte.

[speccery]

On 10/17/2023 at 12:27 AM, apersson850 said:

That special robotics controller I was involved in did have an instruction set adapted to the special needs of robotics. Coordinate conversions are common, so it did for example support sine and cosine for 32-bit floating point numbers directly in assembly language. It also had a register file where you could do something similar to BLWP, but the subroutine call shifted the 16 register workspace 12 positions in the register file. Thus if you called a subroutine in high level language (Pascal at that time) with no more than four parameters, they were stored in R12-R15 and when the call was done, they were in the new R0-R3. Results could easily be returned without having to push everything on a stack. Multiple efficient subroutines were possible, as long as you didn't run out of the register file. Returning from the subroutine shifted the registers back, so the results now appeared in R12-R15.

Thanks for sharing your experiences, very interesting read. What you explain about the special robotics controller sounds a lot like what SPARC CPUs do, they also have overlapping register windows. Unlike on the TMS9900, there is a massive register file, off-chip memory is not used register storage. The programmer sees 32 registers at a time, 8 of which are a global, and 24 are a window to a larger register file, which could for example have 160 registers in total.

 

@TheBFsome TI DSPs have VLIW architecture. I have programmed professionally some TI DSPs, but unfortunately it was before the VLIW chips like TMS320C6201 became available. The TMS320C6201 packs up to eight 32-bit instructions into one instruction packet, so the DSP fetches 256-bits worth of instructions every clock cycle. In practice it might be able to execute only some of those in a given cycle, as each instruction within a packet needs to use separate functional hardware units to run in parallel. The architecture places a lot of burden on the programmer or compiler to get the best speed out of the system. My understanding is that these DSPs are purely in-order execution engines and they have marker bits in the instruction stream to tell which instructions of a packet can be run simultaneously on a given cycle. For example you might have an instruction packet where three instructions can be executed in a cycle, and the remaining 5 would be merged with 3 instructions from the next packet, and then checked which of those can be run. But it all happens in order, even if there are no data dependencies. It is very interesting stuff. 

 

Contrary to that, from the Pentium Pro onwards the x86 architecture introduced speculative execution, register renaming and out of order execution. The CPUs became more or less data flow machines, requiring a lot of hardware to extract parallelism from non parallel instruction streams. Compared to that the VLIW designs are much simpler and more elegant - hardware wise...

[+TheBF]

6 hours ago, speccery said:

Thanks for sharing your experiences, very interesting read. What you explain about the special robotics controller sounds a lot like what SPARC CPUs do, they also have overlapping register windows. Unlike on the TMS9900, there is a massive register file, off-chip memory is not used register storage. The programmer sees 32 registers at a time, 8 of which are a global, and 24 are a window to a larger register file, which could for example have 160 registers in total.

 

@TheBFsome TI DSPs have VLIW architecture. I have programmed professionally some TI DSPs, but unfortunately it was before the VLIW chips like TMS320C6201 became available. The TMS320C6201 packs up to eight 32-bit instructions into one instruction packet, so the DSP fetches 256-bits worth of instructions every clock cycle. In practice it might be able to execute only some of those in a given cycle, as each instruction within a packet needs to use separate functional hardware units to run in parallel. The architecture places a lot of burden on the programmer or compiler to get the best speed out of the system. My understanding is that these DSPs are purely in-order execution engines and they have marker bits in the instruction stream to tell which instructions of a packet can be run simultaneously on a given cycle. For example you might have an instruction packet where three instructions can be executed in a cycle, and the remaining 5 would be merged with 3 instructions from the next packet, and then checked which of those can be run. But it all happens in order, even if there are no data dependencies. It is very interesting stuff. 

 

Contrary to that, from the Pentium Pro onwards the x86 architecture introduced speculative execution, register renaming and out of order execution. The CPUs became more or less data flow machines, requiring a lot of hardware to extract parallelism from non parallel instruction streams. Compared to that the VLIW designs are much simpler and more elegant - hardware wise...

Very neat stuff. Yes the out of order machines always "grated" against my real-time mentality for computing. (card carrying member of the old fart society) 

I didn't know about these TI DSPs with VLIW architecture. 

What you describe dove-tails with Chuck's machines in that each bit field managed separate hardware chunks (ALU, memory, stacks) as I understand it.

The approach was about removing the need for pipelining to maintain real-time predictability just as the DSP engines required and also to keep the gate count low.

And as you mentioned the compiler needed extra smarts to know what instructions could be stuffed together into one chunk.

 

[+OLD CS1]

All this discussion reminds me of my systems architecture class.  We were programming in MIPS.  We had a big pass/fail project: complete a set of tasks without stalling the pipeline, you passed; stall the pipeline once, you failed.  I loved that class.

[+TheBF]

28 minutes ago, OLD CS1 said:

All this discussion reminds me of my systems architecture class.  We were programming in MIPS.  We had a big pass/fail project: complete a set of tasks without stalling the pipeline, you passed; stall the pipeline once, you failed.  I loved that class.

Sounds brutal.  What instructions stall the pipeline typically? Branches?

[+OLD CS1]

17 minutes ago, TheBF said:

Sounds brutal.  What instructions stall the pipeline typically? Branches?

Been a long time, but going from memory, the CPU we worked with had a number pipelined operations, like address fetch, data fetch and store, certain maths, register operations, and so on.  Oh, I also remember we had a certain amount of cache to work with, so a certain amount of data fetching could be handled at the same time.

 

A poor example from memory, but as I recall we could fetch an instruction, load registers with data from sequential memory locations stored in the cache, load the next line of cache from memory, perform two register addition (math) operations, and check for a conditional branch all at the same time.  Stalling the pipeline would be attempting to load from two memory blocks at the same time, attempting more than a couple of register operations (move or shift, or math, &c) at the same time, and so on.  Again, not my daily immersion so I am certain someone else can come up with much better examples.

 

(Edit: Oh, and certain operations could flush or attempt to flush cache in the middle of using it, which would cause contention, too.  It was like a logical Tetris.)

 

It was indeed brutal, but so much fun.  It took me a few attempts to get the project right.

 

I actually just uncovered my class book while re-arranging my office.  I put it on my stack of stuff for me to re-familiarize.

[apersson850]

I think I have the data book for that robotics CPU somewhere at home. Now I've got a desire to locate it...

I know one of the first real applications for the robotics CPU was to control a robot playing table tennis.

[pnr]

On 10/14/2023 at 1:36 AM, FarmerPotato said:

 

I found one title listed in the 1983 accession to the TI Archive, now at DeGolyer Library, SMU:

 

Model 990 Computer MDS990 Microcode Development System Programmer's Guide  2264445-9701

(Also, the stack location / box number.)

 

 

Thanks for finding this. How do I learn more about this, is there a link for this document?

[+FarmerPotato]

15 minutes ago, pnr said:

 

Thanks for finding this. How do I learn more about this, is there a link for this document?

It's in-person only.  Box 10 of accession 94-08 .  I might be the only person who's browsed 94-08 since it was shelved. 

 

[matthew180]

On 10/16/2023 at 8:39 AM, TheBF said:

I have no experience with this at all.

What is a development system like for microcode?

Is there an instruction set?

How many instructions are in the set? 

 

Generally an electronic device like a CPU is made up of a bunch of independent circuits that perform specific tasks that make the whole thing work.  These circuits need to be coordinated to get the machine to do useful things like read two values from memory, add them, and store the result back to memory.

 

This coordination of all the internal pieces and circuits of a CPU are generally controlled in one of two main ways, either with microcode, or with hard-wired dedicated logic.

 

Hard-wired logic has the advantage of being faster (generally) and can make the CPU simpler (usually).  However, if there is a bug in the logic, then it is much harder to fix.  Also, as the CPU gets more complex, hard-wired control probably becomes impractical.

For a microcoded CPU, the instructions are much different than programming languages, even assembly language.  The purpose of microcode is to control when various circuits of the CPU are enabled, which internal buses are active, where data is going to be routed, what inputs to the ALU are selected, which register is going to store results, etc..

 

The CPU architecture will dictate how many control signals are needed to manage the CPU's operation, and thus will determine what the microcode "instructions" might look like.

 

For a simple CPU the microcode might be just hand-written and encoded into the microcode-ROM directly.  Sometimes tools similar to assemblers are written to help write microcode.

 

For example, to fetch an opcode from memory for the CPU to execute, the any CPU will need to do some sort of the following steps:

 

Cycle 1. Gate the PC (program counter) to the address bus, set the read pin high, set the memory output high, tri-state the data bus.

- memory cycle, RAM or ROM will decode the address and put the addressed data on the bus for the CPU to read -

 

Cycle 2. Latch the data bus to the IR (instruction register), set the read pin low, gate the PC to input-1 of the ALU, gate a constant "1" to input-2 of the ALU.

- decode cycle, PC increment using the ALU -

 

Cycle 3. Gate the ALU output to the PC, microcode branch to a subroutine based on the now decoded instruction.

- begin execution phase -

 

All the circuits in the CPU operate simultaneously, so while the decode circuits are making sense of the opcode that was just read in, the ALU is busy adding "1" to the program counter for the next memory access, etc..

[apersson850]

As a general observation you can say like this:
Assembly: Rather few bits encoded to make instructions that do pretty complex things, one instruction at a time.

Microcode: A lot of bits that each does a very simple thing, but they can happen simultaneously.

 

The last thing I was involved in microcoding was a 32-bit CPU which had an 80-bit microcode instruction width.

Edited February 11 by apersson850

[+FarmerPotato]

Great explanation by @matthew180 above.  

 

At VCFSW in Dallas last year, I heard a talk about microcoding the 6809 (a new version that went to commercial silicon.) 

 

I found resources to learn more.   Databooks have good detail.   Patents are a source of documentation for microcode of the 99000 and 7000.   The 6809 guy recommended one textbook, Microprogrammed State Machine Design by Michel Lynch, 1993.  It is expensive ($280) .  I found  "<insert title>.pdf" online, covering the AM2900 with rigor. (the parts I read were similar to the AM2900 datebook...)

 

Here is a great survey of bit-slice processors of the 70s:  

Microprogrammable Microprocessor Survey.  ACM. 

https://dl.acm.org/doi/pdf/10.1145/1096525.1096527

 

See my References list below.

TMS7000 Microcode

 

The 7000 is the CPU of the CC-40.  I think the TMS7000 microcode is better documented than 9900 (but I haven't read everything yet).  

 

The TMS7000 Family Data Manual introduces microcoding concepts.   Texas Instruments would manufacture it with customers' own control ROM. This was a way to optimize an application.  In an example, the 8-bit MPY algorithm is expressed in assembler--it runs rather slower than the microcoded MPY.  

 

Much more information is in the TMS7000 Family Microarchitecture User's Guide.  The rationale for certain decisions is in the patents. 

 

There is a Texas Instruments patent for "Strip Chip Architecture" which reduced the die space occupied by microcode. (Which would often require 25% of a chip's area for an enormous PLA or ROM.)  

 

Another patent shows how logic-minimization could save space.  I have a hunch that, once those optimizations were in place, it locked in the "core instructions" that Texas Instruments wouldn't let you omit or modify.

 

SBP0400 - Texas Instruments Microcomputer Training Modules

 

In 1976, you could learn microprocessor architecture from the bottom up, by programming the SBP0400 in the  Microcomputer Training Modules LCM-1001 to LCM-1004.    With LCM-1001, you got a 4-bit-slice CPU and toggle switches to supply the operator plus A and B inputs.  A "clock" button computed the result and set the output LEDs.  The LCM-1002 Controller (Microsequencer) stored sequences of micro-operations in a PROM--the basic instructions--with leftover space to define your own.   Other modules were program memory and I/O.  These were beyond me at the time I saw them--I was barely learning 9900 assembly.  There is, I think, a set of all four in my dad's stuff. 

 

More on LCM-1001 in this thread.

 

For an overview of the SBP0400, I found this "Microprogrammable Microprocessor Survey". (uses excerpts from data sheet?)

https://dl.acm.org/doi/pdf/10.1145/1096525.1096527

It references 4 other sources on the SBP0400.

 

990/12 Control Store

 

The 990/12 was TI's top-of-the-line minicomputer. Its CPU was implemented around TI's 74S481 bit-slice processor.    Each "slice"  operated on 4 bits, and could finish one microinstruction every 90ns.  Four S481s made it a 16-bit machine.  A 482 micro sequencer fed them micro instructions from EPROM or RAM.  Each word of this "Control Store" was 64-bits wide. This word contained a 9-bit operation code for the 481, control signals for the CPU's internal buses and registers, and bits to determine the jump to the next microinstruction. 

 

Many of the control signals work by connecting the A, B, and C buses to the 481's inputs and outputs, to internal registers (Status, WP, PC), or to the external memory interface (one address register and one data word register).  The CPU architecture and microcode format is documented in the LR990/12 Depot Manual. 

 

The 74S481 bit-slice processor and 482 microsequencer are fully documented: see the book Bipolar Microprocessor Components on bitsavers. Read the 481 story on cpushack "A Better Bit Slicer".   The 481 doesn't seem to appear in any other databooks.  By contrast, the older 181 appears continuously up to the 1986 ALS/AS Data Book and 1989 Standard TTL Data Book. 

 

Texas Instruments used four S481 to build the 16-bit 990/12 minicomputer.  Each 481 is a 4-bit ALU, and they are cascaded (for example: the little end's output carries over into the middles, and the big end produces the final status bits.)  

 

The microcode of the 990/12 was stored in EPROM banks, 64 bits wide.  Next to the microcode EPROMs is the Writable Control Store (WCS) which can be programmed to implement the system XOPs with microcode. TI's Microcode Development System (MDS990) provided an assembler to translate mnemonics into the 64-bit words.  I know the MDS990 manual is in DeGolyer's Texas Instruments Archives.

 

The microcode EPROM covers the usual 85 instructions in the 9900 instruction set, plus dozens of new instructions.  Some of those new ones made it into the 99000 chip microcode for the 990/10A, such as BIND, BLSK, STPC, and the 32-bit arithmetic and shift.  The floating point instructions were put into the 99110 Macrocode ROM, as regular assembly code.  (99105 can run an external copy of that.)  (There were many ways for 9900s to emulate the expanded instructions sets of other members.)  The whole 990/12 instruction set included arbitrary-precision integer arithmetic and shift, floating point in IBM 32, 64, and 80 bit precision, bit fields, linked lists, and strings.

 

Instructions on bit fields would have been an ideal fit for the 481, I think?  These instructions were Extract Field (right justified), Insert Field, and Invert Order of Field.  Only the atomic bit-test-and-set instructions made it into the 99000 chips.

 

Attached below: a "Railway Switching Yard" diagram for the CPU architecture of the 990/12.  The Depot Manual provides a great opportunity to study the CPU architecture of the 9900 family at its pinnacle.

 

TM990/1481

 

TI's 481 bit-slice was built into the TM-990/1481 module. I gather that it implemented the 9900 instruction set, and was called the "high performance CPU."   Its list price was $5500 in 1982, while $750 was the price of a TM990/101MA board. $1900 would buy a TM990/102 with 128K DRAM.  Those had less expensive TMS9900 and other common chips. 

 

99000 CPU

 

Whenever Texas Instruments filed a patent claim, they would illustrate it with lots of internal documentation for the "preferred embodiment" -- the TMS7000, 99000, 34010 etc.

 

 

As a result, you can read a lot about the 99000 internal architecture documented nowhere else.  Its internal buses and registers are revealed along with some of the microcode format. You could compare it to the 990/12. 

 

 

 

 

Figures

 

I marked up this schematic for the 990/12 like a "Railway Switching" diagram.  It shows the 481 at the heart of the computer.  Red arrows will show which ways that data CAN be directed during a micro-cycle.   It is all about turning on connections in the right order, to gate a source of  data onto the bus, into a functional unit, and send the output to its destination.  (can be multiple places at once.)  Registers keep the data persistent, otherwise it's just on the wire for one cycle.  When the buses are separated, the units they connect may operate in parallel. 

 

The most familiar things will be the address bus, data bus in and data bus out. The red blocks are the ALU (74S481) and the Status Register.

 

The ALU (481) is the center of it all.  It drives the external address bus.  Data bus in gets latched and can then go onto the C bus. 

Data bus out is one destination of the A bus.   Many sources can drive the A bus.

 

 

A and B buses end up at the A and B inputs to the ALU.  The ALU has a data output port, which connects to the A bus again. (where it can go to the external bus or elsewhere.)  The B port is also sometimes an output, going back onto the B bus. 

 

 

This is our 9900 architecture (at its pinnacle, I guess).  

 

From the 990/12 Depot Maintenance Manual, pages 10-9 to 10-10.  This is just a tiny piece.

 

 

 

 

References

 

General:

https://en.wikipedia.org/wiki/Microcode#

 

Microprogrammable Microprocessor Survey.  ACM.  See SBP0400 section. (uses excerpts from data sheet?)

https://dl.acm.org/doi/pdf/10.1145/1096525.1096527

 

1976, SBP0400 Applications Manual and Guide to Microprogramming, Texas Instruments.
 

1976, LCM-1001 Instruction Manual (SBP0400)

https://archive.org/details/texas-instruments-lcm-1001-instruction-manual

 

1977, Texas Instruments Bipolar Microprocessor Components.  Covers 481. 

http://www.bitsavers.org/components/ti/_dataBooks/1977_TI_Bipolar_Microcomputer_Components_Data_Book.pdf

1978, AM2900 Family DataBook

https://archive.org/details/bitsavers_amdbitslicyDataBook_19946998

 

Inside the AM2901 Bit-Slice Processor. Ken Shirriff looks all the way inside.

http://www.righto.com/2020/04/inside-am2901-amds-1970s-bit-slice.html

 

1981, Texas Instruments Microsystems Designer's Guide, 2nd ed

(posted in linked thread)  (TM990/1481 page attached below. From Stuart's 990 page.)

 

1982, TMS7000 Family Microarchitecture User's Guide

 

http://www.bitsavers.org/components/ti/TMS7000/TMS7000_Family_Microarchitecture_-_Nov_1982.pdf

 

Model 990 Computer Microcode Development System (MDS990).  Texas Instruments Archives, DeGolyer Library, Southern Methodist University. 

 

1983, TMS7000 Family Data Manual. 

 

1986, Texas Instruments LSI Logic Data Book.  Excerpts from 74AS888 User's Guide, an 8-bit slice. 

http://www.bitsavers.org/components/ti/_dataBooks/1986_TI_LSI_Logic_Data_Book.pdf

 

1989. SN74ACT8800 Family 32-Bit CMOS Processor Building Blocks
http://www.bitsavers.org/components/ti/_dataBooks/

 

1990. AM29000 Family Data Book.  A 32-bit processor component. 

http://www.bitsavers.org/components/amd/Am29000/1990_AMD_29K_Family_Data_Book.pdf

 

 

Patents

 

TMS7000 patents

 

TMS99000 patents

 

 

TM990_1481_TexasInstrumentsMicrosystemsDesignersHandbook2ndEdition.pdf