Musings on 99000 macro code

[pnr]

JH wrote:

 

I initially had some macrostore ram on my 99105 design.

 

But, as far as i could understand it, it was intended for running a small amount of code at zero wait states when main memory was too slow to run zero wait states. Since you can get large rams now that are fast enough to run zero wait states there didn't seem any point to it.

In the case of the TMS99110 it has the floating point routines in the macro rom but i assume there would be no difference in speed running that code from the macrostore rom or from external zero wait state ram.

It may well be that i'm not understanding it correctly though.

 

Your understanding is basically correct, but the design purpose of macro code was not just speed. It was basically a follow-on to the complex instruction set of the TI990/12 mini computer and its user writable micro code. It was also a way to customize interaction with a MMU and a way station when developing co-processors.

 

For a quick description of the 990/12 see the attachement. For a description of the full 990/12 instruction set, see here http://bitsavers.informatik.uni-stuttgart.de/pdf/ti/990/assembler/2270509-9701A_AsmRef_Nov82.pdf It would seem that the micro-code user guide is lost, unfortunately.

 

With external macro rom and ram, it is possible to implement the full 990/12 instruction set on a 99000 CPU and to provide an alternative to user writable micro-code, using normal assembler code (plus a few extra instructions, like 'EVAD').

 

According to the contemporary materials there were 3 versions of the 99xxx: the 99000 with just LDD, LDS and LMF in internal macro rom (for the 990/10A mini), the 99105 without internal macro rom and the 99110 with the 990/12 single precision floating point instructions and LDD/LDS in the internal macro rom. There is a lot of mention of a planned 99120 with parts of the "Rx" micro-kernel of TI's "Microprocessor Pascal" in its internal rom, but this was most likely never produced.

 

In reality it would seem that only 99000 and 99110 silicon was produced and that chips marked "99105" have either 99000 or 99110 silicon inside. We still need to test more 99105 chips to understand this better.

 

I've modified Stuart's 99110 experimentation PCB (see http://www.stuartconner.me.uk/tms99110_breadboard.htm) to handle external macro ram and to see if we can access the internal macro rom to see what is there. The 99110 offers an extension feature which seems to make this possible. My current 99105 seems to have 99000 silicon and does not appear to have this extension feature. Another 99105 is on its way from China and I hope this will have 99110 silicon (chips marked 99110 seem to be very, very rare).

 

According to contemporary documents, the last 16 words of internal macro rom contain code for factory testing the macro rom. My hope is that this code can be accessed on any 99xxx, which may provide a backdoor to get access to the macro rom as well (so that chips without the extension interface can be read out).

 

Paul

 

 

 

ti990_12.pdf

[speccery]

Paul, thanks for starting the thread. As discussed I will try out my two TMS99105 chips to see what macrostore features they might support. This weekend I did not have time to try them out, but hopefully during next week I can do that.

 

Erik

[speccery]

Now I tested my two TMS99105 CPU chips to see if they behave actually as a TMS99110. I got interesting results while testing two TMS99110 specific instructions. I modified my FPGA design temporarily, so that the PSEL# line (which is normally ignored) is taken into use when loading from address 6000 (i.e. cartridge ROM area) #PSEL is checked. If it is set, the load actually goes to GROM address 6000 (this type of direct GROM load is obviously only possible in the FPGA design).

*     LDS
      DATA >0780  ; LDS opcode
      MOV  @>6000,R0    ; Distant load
      MOV  @>6000,R1    ; close load
      .printNumber R0
      .printNumber R1
      .printCrLf

The two loads above produce different results for R0 and R1 if the CPU supports TMS99110 instruction set.

 

The pictures below were taken before I did the above change, and only show the output of the CIR floating point instruction.

 

 

Test results

My first TMS99105 CPU actually behaves as a TMS99110 and executes CIR and LDS instructions properly.

While my second TMS99105 CPU did not perform the floating point operation correctly (CRI did seemingly nothing) but LDS (load distant source) worked fine.

 

Edited January 15, 2018 by speccery

[+Ksarul]

Sounds like the silicon for both of them is for the 110, with the second one just having a fault in the microcode for the CRI instruction (which would have caused it to fail inspection testing for a TMS 99110 package, but had no effect on it packaged as a TMS 99105).

[pnr]

Those are very interesting results!

 

Sounds like the silicon for both of them is for the 110, with the second one just having a fault in the microcode for the CRI instruction (which would have caused it to fail inspection testing for a TMS 99110 package, but had no effect on it packaged as a TMS 99105).

 

Either that, or the package contains 99000 silicon. Luckily, this can be tested. In the case of 99000 silicon, trying the CIR instruction will leave R0,R1 unchanged, but generate an illegal opcode interrupt (#2) and set the ILLOP flag in the error register (CRU bit >1FDA, see manual section 4.4). A faulty ROM would not necessarily do that. The other test is to try the LMF instruction (opcode >0320) and see if that is illegal. If it is not, the chances of getting those two results just because of an error in the macro rom are not that high, imho.

 

My first TMS99105 CPU actually behaves as a TMS99110 and executes CIR and LDS instructions properly.

 

The markings on that chip are actually very similar to the markings on the chip that JH is using on his board - it would be interesting to see if that chip has 99110 silicon as well (and I suspect it will be). Out of five 99105 chips tested, we now have 3 that appear to be 99110's inside, and two that appear to be 99000's (or faulty, to be determined).

 

I modified my FPGA design temporarily, so that the PSEL# line (which is normally ignored) is taken into use when loading from address 6000 (i.e. cartridge ROM area) #PSEL is checked. If it is set, the load actually goes to GROM address 6000 (this type of direct GROM load is obviously only possible in the FPGA design).

 

I hesitate to ask, but will anyway: how hard would it be to modify the FPGA to emulate a little bit of macro ram at macro address >1000? That would enable testing the extension feature on the chip with 99110 silicon (my 'new' chip will not arrive for another week or so - and may turn out not to have 99110 silicon anyway )

 

If the extension interface of manual section 7.3.6 is present and working, one could add the following macro code (starting at macro address >1000). This would copy out the 1KB of macro rom to normal RAM address >6000 (indirect addressing using R0 references macro space, using R3 references 'normal' space).

>1000 DATA >AAAA
>1002 LI R0,>0800
      LI R3,>6000
LOOP: MOV *R0+,*R3+
      CI R0,>0C00
      JLT LOOP
      RWTP

(By the way, if this would work on the other 99105 you have, it would offer another way to see if it is a 99110 with a faulty rom or something else).

Edited January 15, 2018 by pnr

[speccery]

I hesitate to ask, but will anyway: how hard would it be to modify the FPGA to emulate a little bit of macro ram at macro address >1000? That would enable testing the extension feature on the chip with 99110 silicon (my 'new' chip will not arrive for another week or so - and may turn out not to have 99110 silicon anyway )

 

If the extension interface of manual section 7.3.6 is present and working, one could add the following macro code (starting at macro address >1000). This would copy out the 1KB of macro rom to normal RAM address >6000 (indirect addressing using R0 references macro space, using R3 references 'normal' space).

>1000 DATA >AAAA
>1002 LI R0,>0800
      LI R3,>6000
LOOP: MOV *R0+,*R3+
      CI R0,>0C00
      JLT LOOP
      RWTP

(By the way, if this would work on the other 99105 you have, it would offer another way to see if it is a 99110 with a faulty rom or something else).

 

 

No reason to hesitate asking - I'd be happy to try this out. I only need to know two additional things (which looking at the data sheet seem like follows):

• How to direct execution to >1000 in the macrostore memory. It would appear that I need to execute a MID opcode for that, and that I actually need to have jump table setup in >0800 in macrostore address space. MID 0 opcode >0000 would then jump via >0800 to >1000.
• How can I distinguish externally macrostore accesses from regular memory accesses? This seems to be done with bus status codes BST1,2 and 3 set to 000 (AUMSL) or 001 (AUMS). Table 2 on the data sheet seems to indicate that MEM# is actually high during macrostore accesses, which is a weird scenario for memory accesses. It makes sense for internal macrostore ROM, though.

I have made in my TMS99105 board design such that the BST codes are available to the FPGA, so decoding them should not be a problem. I also have plenty of unused memory space (something like 200K) in my FPGA board's 1MB memory space, so it is easy to take some space for macrostore memory.

 

The coolest feature of the FPGA system in my opinion is that I have a transparent DMA channel from PC over USB to the memory of the TMS99105 (the whole 1MB range), so the tools for writing code to and reading results from RAM are already there.

Edited January 16, 2018 by speccery

[pnr]

Many thanks!

 

I only need to know two additional things (which looking at the data sheet seem like follows):

• How to direct execution to >1000 in the macrostore memory. It would appear that I need to execute a MID opcode for that, and that I actually need to have jump table setup in >0800 in macrostore address space. MID 0 opcode >0000 would then jump via >0800 to >1000.
• How can I distinguish externally macrostore accesses from regular memory accesses? This seems to be done with bus status codes BST1,2 and 3 set to 000 (AUMSL) or 001 (AUMS). Table 2 on the data sheet seems to indicate that MEM# is actually high during macrostore accesses, which is a weird scenario for memory accesses. It makes sense for internal macrostore ROM, though.

 

- Directing macro code execution to location >1000 is indeed achieved by executing an opcode that is not defined in the built-in macro rom on a 99110. Opcode >0000 would be a good choice. This is documented in section 7.3.6 of the data manual. As the chip will be running in standard mode, there is no need to set up the jump table at external location >0800: the internal macro rom already has the required settings. If the chip would be running in prototyping mode, with a user supplied jump table at location >0800, the macro rom would be entirely switched off and inaccessible.

 

- Yes, macro store accesses are defined by bus status code 000 and 001 combined with MEM# being high. I at first also thought that this was rather odd, but if you think of MEM# and BST1-3 as being a 4 bit bus status code it makes sense somewhat. The manual does not say what the address bus will be during internal ALU cycles that share their status codes with macro store accesses. At worst the external macro store chips will be selected (I mean have their CS# low), but with no WR# or RD# pulse occurring. The only ill effect I can see would be to drive up power consumption a bit, but I don't think they were worrying about such things in 1981. You would have to be careful with generating wait states though: if you drive READY low during an ALU cycle it, too, will be extended.

 

I did test prototyping mode on my modified experimentation PCB and it all seemed to work as described in the manual.

[pnr]

 

I did make a quick test yesterday with the macro store. Alas, it did not work yet. But I did not have enough time to debug and think about it, I will hook up next my logic analyzer and see if I can see something.

 

Perhaps it is a good idea to test with prototyping mode first. This mode is enabled by keeping /app grounded during reset and releasing it after that.

 

To set up a simple prototype test do:

 

- place >0880 at macro location >0800; this is the first entry in the jump table and used for macro opcode >0000

 

- at macro location >0880 place some test code, for instance to normal memory location >6000 to >5A5A:

     LI  R0,>5A5A
     LI  R3,>6000
     MOV R0,*R3
     RTWP

- set normal memory location >6000 to >0000, set the next instruction to return to the monitor (e.g. to EVMBUG or EASYBUG).

 

- start execution at location >6000; this will execute opcode >0000, which traps into macro store via the jump address at macro location >0800; the macro code changes the >0000 at location >6000 to >5A5A and returns for the next normal instruction (i.e. returns to the monitor).

[kl99]

Very interesting thread.

I read some thing about this in the Software Development Handbook, Geoff Vincent and Jim Gill, TI 1981.

There will be different versions of the 99000, each supporting an extended instruction set, implemented in the macrostore. These instruction sets will be tailored to particular requirements, eg:

99105 Baseline version, instruction set as 9995, no macrostore
99110 High performance floating point package
99120 Realtime executive (Rx) kernel

 

Reference from Chapter 8, Page 57

Find it here:

http://www.hexbus.com/tibooks/ti/software-development.zip

 

Can you specify which document/book/manual is lost? The more we know about Title, Publisher, release date the better we can search our archives.

[pnr]

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.

 

Can you specify which document/book/manual is lost? The more we know about Title, Publisher, release date the better we can search our archives.

 

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.

[pnr]

I was trying to figure out how many batches of 99000 chip were produced during its lifetime, at least an order of magnitude.

 

First an estimate of how many chips were produced. As far as I know the 99000 had two major applications: the TI990 minicomputer (and its later desktop variant BusinessSystem 200/300/etc.), and industrial applications. Over the years I have come across some models of Siemens PLC's that used them, some Fluke lab equipment and apparently a pair of 99105's was used in the guidance system of an early model of cruise missile.

 

When it moved to the S1500 workstations in the late 80's TI claimed that it had an installed base of over 100,000 TI990 (incl. variants) systems. If half of that was based on the 99000 chip, that makes 50K chips. All the industrial applications seem to be things that sell hundreds to thousands, not ten thousands. Maybe all industrial applications together also 50K chips, for a total of about 100K.

 

I think the die is about 8x8mm; on a 4 inch wafer you get about 100, on a 6 inch wafer about 250 of those. That makes for between 400 and 1000 wafers. Wafers are made in batches (all with the same set of masks), with back in the 80's perhaps 10 wafers per batch (my guesstimate). That's 40 to 100 batches, assuming 100% yield. In reality yield was perhaps 50%, so 100 to 200 batches between 1981 and 1991. That is rather less than I would have thought.

 

Still, 10 to 20 batches per year seems high enough to make specific silicon for each of the 99000, 99105 and 99110.

 

 

[kl99]

So far I found these documents/brochures related to this topic:

http://www.bitsavers.org/components/ti/TMS7000/TMS7000_Family_Microarchitecture_-_Nov_1982.pdf
http://www.computerhistory.org/brochures/doc-437295725f2bf/

[speccery]

So far I found these documents/brochures related to this topic:

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

http://www.computerhistory.org/brochures/doc-437295725f2bf/

 

 

Klaus, those seem to relate to the TMS7000 processor architecture... not the 99000

[speccery]

I did a little more debugging on my FPGA platform. I added three debug counters, one counting macrostore reads, one counting the amount of time the macrostore bus access code is visible on the bus and one counting the amount of the time time the macrostore bus access code is there while RD# is low. Looking at those counters to my delight I could see that my TMS99105 (which behaves as a TMS99110) did exactly one macrostore read with my test program. That meant that my bus decoding logic was correct, and it did not take me long to notice that I had forgotten to add support for macrostore reads to my data multiplexer - the multiplexer deciding what data to present to the CPU. It was giving the CPU always CRU data when MEM# was high. So I corrected that to distinguish between CRU and macrostore accesses - and things worked.

 

Without further ado, ladies and gentlemen (well guess mostly gentlemen here), I give you the dump of the TMS99110 macrostore ROM:

 

err - I will give it to you shortly, once I get this bloody forum system to take an attachment... Well there it is hiding in the full editor.

 

It is a one kilobyte dump, from >800 onwards. I have not disassembled the ROM but it looks correct in hexdump, at least the beginning seems to occupy proper jump table vectors.

 

After having success I also tested my other TMS99105 CPU. To my disappointment the debug counters did not move at all, indicating that this CPU does not support macrostore features at all... Or at least my FPGA logic was not detecting macrocode reads. So no dump from that CPU. I wonder if there are some CRU bits to check? I have to take a better look when I have more time.

 

macrorom.bin

Edited January 19, 2018 by speccery

[pnr]

macrorom.txt

Without further ado, ladies and gentlemen (well guess mostly gentlemen here), I give you the dump of the TMS99110 macrostore ROM:

 

Wow, great! I've been wanting to do that since 1982 or thereabouts.

 

Please find attached a quick disassembly with xda99. It does not handle the extra 99000 instructions and has those as DATA, but that is minor.

 

Most macro instruction groups simply go to location >0BE0, which has:

0BE0 C1E0   MOV  @>1000, R7
0BE2 1000
0BE4 0287   CI   R7, >AAAA
0BE6 AAAA
0BE8 1602   JNE  >0BEE
0BEA 0460   B    @>1002
0BEC 1002
0BEE 0382   DATA >0382 (= RTWP2 = exit macrostore & generate ILLOP interrupt)

Interestingly, 0BE0 is the first word of the 16 bytes reserved for factory test code. I wonder if all 99000 have this code there, perhaps testing for different magic. My 99105 does not respond to placing >AAAA at location >1000, but perhaps it tests for >5A5A or perhaps for >AAAA at location >2000 or some such.

 

 

 

After having success I also tested my other TMS99105 CPU. To my disappointment the debug counters did not move at all, indicating that this CPU does not support macrostore features at all...

 

Hmm... that is indeed an unexpected result. It seems like the CPU is operating in baseline mode, where it simply ignores having macrostore. Any chance that you had the APP# line grounded during that test? (this would place the chip in baseline mode). Another possibility is that this is a true 99105 chip, but that does not quite square with its support for LDD and LDS.

 

[speccery]

macrorom.txt

 

Wow, great! I've been wanting to do that since 1982 or thereabouts.

 

Please find attached a quick disassembly with xda99. It does not handle the extra 99000 instructions and has those as DATA, but that is minor.

Thanks! I took a quick look at the source code, and it seems it would not be hard to add support for the TMS99000 instructions.

I haven't used xda99 much - what command line options did you use?

 

Hmm... that is indeed an unexpected result. It seems like the CPU is operating in baseline mode, where it simply ignores having macrostore. Any chance that you had the APP# line grounded during that test? (this would place the chip in baseline mode). Another possibility is that this is a true 99105 chip, but that does not quite square with its support for LDD and LDS.

This could also be a timing difference between the processors. My FPGA system does not have enough free pins to connect to all of the pin of the TMS99105 (via level shifters), so I have time multiplexed the address/data bus three ways: address, control signals, data. As you might imagine timing is a bit delicate with all of that. The control signals are driven to the bus only for 40 ns. The time I sample control signals, including BST lines, might be too early for this specific CPU. I think I sample the BST lines 20ns after enabling the external buffer, and the buffer is enabled for 40 ns in total. It goes something like this: ALATCH signal is sampled at 100MHz. When ALATCH has been high for two clock cycles, address is sampled. 10 ns later control buffer is enabled and address/data drivers disabled. 20 ns later control signals are sampled. 20 ns after that the address/data drivers are enabled again (this time for data transfer part of the memory cycle) and control buffer is disabled.

Edited January 19, 2018 by speccery

[pnr]

This morning was my first use of xda99, so we're about in the same position. The command line I used was:

 

./xda99.py macrorom.bin -a 0800 -f 0814

 

-a 0800 means assume the bin file is based at 0800, -f 0814 means real code starts at location 0814.

 

The timing issue indeed sounds more likely. If you have a counter for the time that the AUMS and AUMSL bus codes appear, they should count all the time: those bus codes are also used for internal ALU cycles and most instructions include one or more of those. Only the appearance of a simultaneous RD# or WR# makes it a macro store cycle.

[pnr]

This is the macro code for LDD/LDS on a 99110:

0AF6 2560   CZC  @>0B18, R5    ; Is this a 99110 style LDD/LDS instruction?
0AF8 0B18
0AFA 1672   JNE  >0BE0         ; No: test for external macro code & exit

0AFC 27E0   CZC  @>0B1A, R15   ; Are we in supervisor mode?
0AFE 0B1A
0B00 1303   JEQ  >0B08      
0B02 0300   LIMI >0000         ; No: cause a PRIVOP error & return
0B04 0000
0B06 0380   RTWP

0B08 0283   CI   R3, >C000     ; Is this a first LDS?
0B0A C000
0B0C 1303   JEQ  >0B14
0B0E 0283   CI   R3, >6000     ; Is this a first LDD?
0B10 6000
0B12 1601   JNE  >0B16
0B14 C08E   MOV  R14, R2       ; Save address of first LDD/LDS in sequence in R2
0B16 0384   RWTP4              ; Return from macrostore & skip interrupt test

0B18 F83F   DATA >F83F         ; reverse bit pattern of LDD/LDS
0B1A 0100   DATA >0100         ; location of supervisor bit in status register

I'm not sure why it saves the address of the first LDD or LDS in R2 and then seems to do nothing with it.

 

It shows that on a 99110 the code tests specifically for opcodes >0780 and 07C0. On my 99105 the full TI990 range of these instructions seems to be valid. This implies that it has different macrocode (i.e. not 99110 code with a faulty macro rom).

 

[speccery]

Thanks for the command line!

 

The timing issue indeed sounds more likely. If you have a counter for the time that the AUMS and AUMSL bus codes appear, they should count all the time: those bus codes are also used for internal ALU cycles and most instructions include one or more of those. Only the appearance of a simultaneous RD# or WR# makes it a macro store cycle.

 

 

When working on this I looked at the counters only very briefly on the 2nd CPU, I was just happy to get the dump out of the first CPU. I have an old logic analyser, assuming it still boots (need to make a backup of the hard disk), I'll hook it up to the 2nd CPU to look at the signals properly.

Edited January 19, 2018 by speccery

[speccery]

This is the macro code for LDD/LDS on a 99110:

 

Very interesting. I don't know why but I assumed that LDD/LDS would be hardwired instructions - but apparently they are not. I have confirmed that LDS works on my 2nd TMS99105 - or at least it does something that causes the 2nd CPU to show different value. So that would imply that indeed timing is off, and the CPU is macrocode capable.

 

It shows that on a 99110 the code tests specifically for opcodes >0780 and 07C0. On my 99105 the full TI990 range of these instructions seems to be valid. This implies that it has different macrocode (i.e. not 99110 code with a faulty macro rom).

I ordered earlier today another TMS99105 from eBay, as this is now getting into an interesting adventure to different chip versions!

[pnr]

Very interesting. I don't know why but I assumed that LDD/LDS would be hardwired instructions - but apparently they are not.

 

You correctly assumed that because they invert the PSEL bit for one or two memory accesses. That has to be done in hardware. It would seem that LDD and LDS are a mix of hardware and macro code.

 

First, the hardware maintains 3 bits of information about LDD/LDS sequences, see the table on page 107 of the data sheet. If you look at the individual states for LDD and LDS (page 84) you'll see that these bits are updated in cycle #2 of an LDD or LDS. An MID trap follows, which is listed on page 91. In cycle #7 of the trap these bits are then copied to the top of R3, where macro code can inspect them.

 

The hardware bits are also used on the next SOP or DOP bus access, and it is during these two that PSEL is inverted. This why LDD/LDS does not work when accessing registers: those have bus code WS and not SOP or DOP (see page bottom 106 to top page 108). Macro code can generate SOP/DOP cycles by using indirect accesses via R6 and R12 respectively (page 43).

 

I've just read those pages again and the last section on page 107 makes sense for the first time, and explains the copy of R14 to R2 in the LDD/LDS code.

 

====

 

On a 99000 (i.e. for a TI990/10A mini computer) the macro code will be different. This mini does not have a 74LS612 style mapper, but a more complex MMU (physically it is a 64 pin ULA on the CPU board). This MMU is a CRU device and has two base maps, one for when PSEL is 0 and one for when PSEL is 1. Each map is 6 words long.

 

On a TI990 both LDS and LDD take a single argument, which is a third, temporary memory map. My hypothesis is that on a 99000 the macro code will copy out the temporary map to the third MMU map. What I don't understand is how the MMU knows when to use this third map when it only has the single PSEL bit to work with. Perhaps it assumes that LDD/LDS will only be used when PSEL is 0 and that the first SOP/DOP cycle with PSEL=1 after loading the third map must use the third map instead of the second.

 

It gets complicated, because on a 990/10A the sequence LDS-LDD means that the first LDS modifies the LDD to go long distance for its temporary map. To change both source and destination for another instruction one must use the sequence LDD-LDS. Complicated sequences like LDS-LDD-LDS or LDS-LDD-LDS-LDS would all appear valid and have specific meaning.

 

Hopefully I can find a backdoor to my 99105 chip (which I assume has 99000 silicon) and list the actual macro code. This weekend I'll set up a test that works its way through all magic numbers on macro location >1000: maybe there is one that works...

[speccery]

This gets puzzling. I have now repeated my measurements with logic analyser setup something like four times. The results are consistent: the TMS99105 on which my FPGA setup is not able to detect macro code reads on the system bus is showing the same behaviour under logic analyser. The macro code accesses just are not there. I have now swapped between the two CPUs on otherwise the exact same measurement setup (same boards, same probes, etc.). With the TMS99105 behaving as TMS99110 I always get a trigger on the analyser, on the other CPU I never get the logic analyser to trigger on the combination RD#=0 MEM#=1 BST1=0 BST2=0. Bizarre.

Below is the output when the analyser (spellchecker refuses to write that with Z - grr) triggers on the working TMS99110 aka TMS99105.

Edited January 19, 2018 by speccery

[pnr]

This gets puzzling.

 

Maybe not. Internal macro store accesses do not generate RD# signals. What I think you are seeing on 99110 silicon is the single read of external location >1000. If your 2nd chip does not have the extension interface at all, it will not read location >1000 (or apparently any other location) but simply return with an ILLOP exit. If it has no extension interface, there is no obvious way of reading out its macro rom.

 

I've now tested through all macro jump table entries (first instruction for each entry only) and with any possible magic word at location >1000. For my chip I did not find an extension interface this way either.

 

To see if you have 99000 silicon in your second 99105 you could try the LMF instruction (>0320). If I'm not mistaken that instruction should make at least 3 accesses to parallel IO space, which your logical analyzer can trigger on if you add A0 and BST3 as inputs (but perhaps wise to test first that LMF is accepted as a valid instruction on your chip).

 

That leaves the question of how they factory tested a 99000. Maybe they felt that the LDS/LDD/LMF instructions were simple enough that they could check the chip's responses in test scenarios that covered every instruction for these in its macro rom code. That would be the hard way. The easy way would been to have some sort of back door to read out the macro rom and simply test that each word has the data in it that it should have.

 

The easy way ties in with having the last 16 words reserved for factory testing, which suggests those 16 words might have a backdoor. The question then becomes how to trigger this backdoor. Maybe TI implemented an macro instruction that reads and returns a macrostore word, or implemented a macro XOP (i.e. with ST11=1) for that.

 

Maybe I'm just clutching at straws here: maybe the 99000 is simply a locked box.

[speccery]

 

Maybe not. Internal macro store accesses do not generate RD# signals. What I think you are seeing on 99110 silicon is the single read of external location >1000. If your 2nd chip does not have the extension interface at all, it will not read location >1000 (or apparently any other location) but simply return with an ILLOP exit. If it has no extension interface, there is no obvious way of reading out its macro rom.

 

I am not sure if I understood your assumptions correctly - is your working assumption that some 99105 chips are actually 99000 chips without any support for macro code? I thought that we've been lucky with some 99105 chips behaving as 99110, but that a 99105 would still be a 99105 as a minimum.

 

I have not read the data sheet carefully enough to understand how a 99105 would access macro code, but I need to do that.

 

In my logic analyser setup I am not looking for reads from >1000, but for reads from any address. This somehow relates to the logic analyser picture I posted - on the 99110 we can see that before the external macro code read occurs there is a whole bunch of internal cycles. Looking at the disassembly extract you posted, we can understand that during this time we are running from the internal macro code ROM.

 

What I am thinking now is to alter my measurement setup so that the MID 0 (or other MID opcode) occurs very soon after reset. That way I can trigger to reset becoming inactive, and see what happens when the MID opcode is hit. I guess I am interested in understanding if any ROM code gets executed at that point in time.

[Jimhearne]

 

I am not sure if I understood your assumptions correctly - is your working assumption that some 99105 chips are actually 99000 chips without any support for macro code? I thought that we've been lucky with some 99105 chips behaving as 99110, but that a 99105 would still be a 99105 as a minimum.

 

 

 

I didn't think the 99000 existed as a specific chip, i thought it was just a name for the 99xxx series of chips, the 99105, 99110 and the probably never made 99120.

 

Jim