Talk:TMS9900

Curious about X

The main article says there was a rare and uncommon instruction called "X" - used for executing an instruction that is pointed to, by another register. After the instruction, program flow resumes where the Program Counter used to be.

What is the object code for this instruction?

The main article could be improved by explaining which engineers came up with this instruction. Its probable use appears to be fairly obvious. It appears to facilitate distributed processing.

Were there any other microprocessors that use this kind of instruction? 216.99.198.99 (talk) 01:34, 21 August 2009 (UTC)

Execute instructions were well known. The IBM System/360 and DEC PDP-6 and -10 both had them, as did the Varian 620 mini John L (talk) 03:19, 23 August 2009 (UTC)

Thanks, that is very interesting. 216.99.198.97 (talk) 07:54, 9 September 2009 (UTC)

The 360 version of this instruction was called EX, and it ORed some data from a register into the instruction before executing it. I can't find the equivalent instruction in the PDP-10 opcode charts. Some guy in a forum explained that, for the 360, "So you normaly use the EX to modify the length of a mvc,clc,pack,ap or sp instruction." Some other guy somewhere said, "This allows you do a MVC where the length is not known until run time, like the length of your PARM field." (I believe those instructions include a string length in bytes in the instruction itself.)

Another use for the EX instruction on the 360 is apparently to generate a program crash ("abend") by trying to EX an EX.

According to a chapter I found online with the TMS 9900 instruction set, the X instruction was encoded with the opcode 0 0 0 0 0 1 0 0 1 0, followed by two bits of T_S and four bits of S. It says that the instruction executed is "the instruction at SA", but I'm not clear what SA is; perhaps S names a register, and the register points at the instruction in memory.

So it appears that the primary use of instructions like this was to work around (what I would consider) serious brain damage in the rest of the instruction set without actually needing to generate new code in memory.

My original thought was that EX would be a useful instruction for writing a debugger that could single-step machine code, but I can't find any indication that people used it for that. But I guess you don't need to write debuggers as often as you need to copy around variable-length strings.

None of this has anything to do with distributed processing. If you want to ship some mobile code across a network, which is maybe what you were thinking of, you probably want to ship more than one instruction at a time. In that case you'd just call it like any other subroutine. Kragen Javier Sitaker (talk) 03:14, 4 March 2011 (UTC)

I've only seen a few uses of the X instruction. One is to compose an instruction in a register then execute it.

Say you were performing a logical pixel copy. You could use a register to hold an operation such as SZC, SOC, XOR, INV, or simply MOV, before calling a subroutine that will apply it many pixels.

Another is to write a generic loop construct, whose input is one register holding either INCT or DECT or even SLA as the step, and another register holding a conditional jump instruction (JH, JEQ, JOC).

So the theme is that you can use an instruction as a parameter to a subroutine, avoiding a multi-way jump. Speaking of jumps, I've seen X used to pick a JMP instruction out of a table--X @TABLE(R4) .but think that one through! Simpler to do B @TABLE(R4).

The X instruction is no use for a single-step debugger, as it reads just a single-word instruction. The source operand is evaluated to get the effective address of the instruction to fetch, but any additional immediate operand words are taken from the current PC. So you wouldn't use X on an arbitrary code pointer, and anyway the caller can't prevent jumps.

More About Debuggers:

The 9900 family implemented single-step debugger either in 1)software by calculating the next PC address and swapping its contents for a breakpoint (good use of XOP as breakpoint; the 99/4A has one in ROM just for that) or 2) in hardware with a one-shot circuit to assert the LOAD (non-maskable) interrupt after seeing two more instruction fetches. Two instructions could be a RTWP to branch into the code context to execute, then one arbitrary instruction, after which LOAD invokes a breakpoint. The 990 minicomputers worked something like this: at boot, the LOAD interrupt vectors into the top address, which is in the diagnostic/loader ROM. Later, in the context of an operation system, the vector forwards events to a breakpoint handler. The 990/189 University board manual has a student exercise to build such a circuit for single-stepping. FarmerPotato (talk) 03:29, 27 October 2022 (UTC)

Also, added a link to a method of debugging TMS9900 code which helps justify some claims in the main text. Adel314 (talk) 12:31, 15 January 2024 (UTC)

I have added some code to describe the X instruction thus justifying the removal of the "citation needed" requests. Adel314 (talk) 12:27, 15 January 2024 (UTC)

RSET instruction

Without having to download and study the TMS9900 instruction set, can anybody brief me on what the RSET instruction did? Was it a software interrupt like the 6502 BRK, but uninterruptible, like an NMI triggered by software?

The main article could be improved by describing the RSET instruction, and noting whether it could bring about a restart, or was it more like a "clear" the bit instruction, similar to RCLR in some microprocessors like the 68000? 216.99.198.28 (talk) 23:12, 6 September 2009 (UTC)

The book "Fundamentals of TI-99/4A Assembly Language" helps answer this question on page 303. RSET is a control instruction, just like LREX, CKOF, CKON, IDLE, and CRU. The last operation is apparently a hardware operation realized by accessing a particular address in memory without an opcode. That doesn't make sense to me, so maybe someone here at Wiki can explain it, as the only thing that is important is driving the bottom 3 address lines, perhaps by inserting a cartridge that grounds those lines, or raises them up somehow.

If it is helpful, the opcodes are defined in binary as:

RSET ($0360) %0000 0011 0110 0000

IDLE ($0340) %0000 0011 0100 0000

LREX ($03E0) %0000 0011 1110 0000

CKOF ($03C0) %0000 0011 1100 0000

CKON ($03A0) %0000 0011 0110 0000

If the object code looks a little funny to you, or doesn't add up, remember that this is a Big Endian microprocessor. 216.99.198.97 (talk) —Preceding undated comment added 07:22, 9 September 2009 (UTC).

Whenever a control opcode (listed above) is executed, it apparently affects the bottom3 address lines (bits A0, A1, A2). Since this is a Big Endian microprocessor, am I right in concluding this brings about a massive memory shift? Where the 3 bottom bits are actually the 3 highest bits of addressable memory? Sort of like swapping out entire chunks of addressable memory? 216.99.201.217 (talk) 07:44, 10 September 2009 (UTC)

It isn't immediately clear to me that the microprocessor is Big Endian. But it is 16 bits wide, so the opcodes are 16 bits wide, that much is clear. But whether the opcode for RSET is stored in memory as $03 followed by $60, or $60 followed by $03, is a question that hasn't been answered so far; depending on the way the question is answered, determines whether the microprocessor is Big Endian or not. —Preceding unsigned comment added by 216.99.201.35 (talk) 03:39, 13 September 2009 (UTC)

The 5 "control" instructions' behavior are up to the system designer's choice. On the TMS9900, they merely signal a code (temporarily) on the address bus with a single-bit CRU (I/O) instruction (pulsing CRUCLK). An outside circuit must act on that. The code emitted on A0-A2 makes for an otherwise invalid address (for CRU operations at least.)

TI data books on the 9900 use A0 for the most significant bits, A15 for the least. Valid addresses for CRU instructions are 0000-1FFE, which have 0s in the bits A0-A2. So the address emitted by a control instruction is recognizable.

In a 990 minicomputer, the control instructions mostly did what they are named. RSET initialized internal peripherals; IDLE froze the state; LREX restarted the machine (perhaps by causing a LOAD interrupt?) CKON and CKOF controlled a real-time clock. But in the 990/4 minicomputer, these functions were done by external circuitry.

On the TMS99105, these instructions are still mostly user-defined. IDLE does put the CPU in an infinite loop until a RESET or other unmasked interrupt occurs. They appear to the bus as an SBZ (set-bit zero write) to an internal address like 1EC4. In privileged mode, the RSET instruction is used to clear internal CPU status flags. FarmerPotato (talk) 03:46, 27 October 2022 (UTC)

Endianness is one of the most misunderstood things among software developers. The reason is that people get hung up on terminology and lose sight of what is really happening at the hardware level.

First, the TMS9900 is a Big Endian processor. Which bit is called A0 has nothing to do with endianness. There does seem to be some consistency among chip manufacturers regarding this labeling, but that is merely coincidental. For the TMS9900, TI chose A0 to represent the most significant address bit and A14 to be the least significant address bit. They could have labeled them in the reverse order without changing the endianness.

Second, when a RSET instruction executes, the 3 most significant address lines (A0, A1, and A2) are driven Low, High, High, respectively, and the CRUCLK line is pulsed. This combination of signals causes the CRU bus to reset, but does not invoke a memory access. Then the 9900 loads the contents of memory at address 0000 into the Workspace Pointer (WP) register and address 0002 is loaded into the program counter (PC). After this, execution continues at the address loaded into the PC.

If you look at the object code on a Little Endian computer (such as a PC), the RSET instruction may look like 60 03, but on a big endian machine (or with SW that compensates for endianness) you would see 03 60. Because the 9900 is a 16 bit device, the opcode is stored in memory as 0360. Jimwilliams57 (talk) 05:09, 14 September 2009 (UTC)

You should keep in mind that the so called external instructions, with the mnemonics LREX, RSET, CKON, CKOF and IDLE have their names from their use in the TM 990 mini computers. In addition to their meaning inside the CPU, their full function relies on specific hardware to decode these instructions. What happens when they are executed depends upon that hardware. It is for example possible to include hardware that will decode the RSET instruction to also do a hardware reset of chips in the computer, including the CPU itself. Without such hardware, the only thing that happens is that the CPU disables interrupts, by loading zeroes into ST12-ST15, which is equivalent to executing LIMI 0. The IDLE instruction could turn on an indicator LED, to tell the user the CPU is idle (as was done by the Cortex computer). That computer also took benefit from the CKON and CKOF instructions, but used them to enable and disable a memory mapper circuitry. LREX cause a delayed interrupt after two instructions, by clocking a row of flip-flops with the IAQ signal. By loading proper values into R13-R15, then executing LREX RTWP, the computer would "return" to the desired instruction, execute that one, then come back to a debugger by the interrupt.

But without this external logic, these instructions do nothing, or very little. —Preceding unsigned comment added by 79.102.250.184 (talk) 22:03, 3 January 2010 (UTC)

Neutrality

There's a neutrality disputed tag on the main page, but no discussion of neutrality in the talk page - what's up? At first reading, the article feels like it's been written by an enthusiast of the chip, but it doesn't seem wildly at variance with NPOV. Rob Burbidge (talk) 12:16, 16 September 2009 (UTC)

I believe the issue lies with the fact that there aren't any references cited whatsoever. Which is why you would put a citations needed notice...Most or all of what is said is true, but without citing sources or going into detail, one could dispute the neutrality. For instance, the claim about how it "had the potential to surpass the 8086." It does strike me as rather bad taste to add that "neutrality disputed" notice without any talk. Since there's no talk, I think it should be replaced with a "lacks citation" notices, unless anyone wants to raise any real objections... Sidenote, the citation needed/lacks verification notices are getting far too annoying all over Wikipedia; it seems every other article I look at (I mostly browse technical articles) has them. Sigh. Citations are often just a google away.. pokeme444 (talk) 6:52, 4 May 2010 (UTC)

Major Parts of the page are copied from http://www.cpushack.com/CPU/cpu3.html. Perhaps thats the reason.... —Preceding unsigned comment added by 78.42.111.234 (talk) 10:31, 29 October 2010 (UTC)

Inaccuracies

the page is full of speculation and inaccurate information. coming from someone who owned nearly every micro-processor available in 1978 - 1988 and memorized their instruction sets.

just some examples:

1. the processor is big endian in that the low order address bit, A15 (which did no appear on the address pins of the chip) addressed the rightmost byte of a 16 bit word if 0, and addressed the leftmost byte of a 16 bit word if 1. (and yes, it is confusing at first that TI choose the pin numbers not as 2^N, but as A0=high and A15=low. Same for D0-D15.
2. the instruction set is nearly a complete ripoff of the PDP 11, but with 4 bits of register addressing.
3. the AMD 2901 bit-slice and the National Bit-slice chips are not "microprocessors", they are bit-slice, which meant that any processor built with them was multi-chip by nature (ALU, Instruction decode, address/data buss management were separate chips)
4. the IBM-PC team in Boca Raton seriously consider the TMS9900 for the original PC, but decided on the 8088 based on a variety of reasons including production costs.
5. the TMS9900 was one of very few microprocessors which was available in a radiation hardened version, and it became popular in military hardware for guidance and control systems for missiles and aircraft.
6. I have serious reservations about the statement someone made that "every illegal opcode executes as a NOP" ... that does not agree with my personal experience with the processors used in the TI-99 and the later MyARC Geneve (TMS 9995). There were undocumented instructions in various production runs, and they had various side-effects. One which comes to mind is a buggy and incomplete implemention of MPY (multiply) which was on a 1985 production TMS 9900.
7. I don't understand someone's reference to "distributed computing" in the context of the X (eXecute) instruction. It was useful for debugging and for creating an indexed-opcode table used in a byte-code interpreter. Typical form was "X @BASE+INDEX". The drawback I recall is that the 2nd word (if needed) when the instruction was decoded was pulled from after the X instruction, not from after the target of the X instruction. My recollection may be faulty -- I need to reread the instruction datasheet.
8. discussion below, regarding RSET, LREX, etc. yes, they drove the 3 HIGH order address PINS in a non-memory address cycle along with CRUCLK. If there was no external hardware to detect the non-memory address cycle, then nothing special happened, and the instructions only vectored as documented.

I may take a try at cleanup with cites. Techguru99 (talk) 13:41, 18 June 2010 (UTC)

what is the problem?

what is the neutrality issue? whoever initiated the claim should at least discuss it, or remove it. it is distracting .

also, the list of 'inaccuracies' is really a list of statements, mostly not even addressing any inaccuracies in the article. i don't understand point 2, the 'ripoff' statement. the opcodes are NOT the same as the PDP11. eg; mov is 001 for the PDP, but 110 in the TMS. similarly, 010/100 for com, 011/110 for subtract, etc.

the article IS very sparse for a chip this powerful and popular, though 96.8.145.192 (talk) 09:35, 23 April 2011 (UTC)

Example code

It would be nice to add an example subroutine, such as the strtolower() example used for some of the other microprocessors (e.g., 6502, 80386, 68000, etc.). — Loadmaster (talk) 17:38, 22 May 2018 (UTC)