Jump to content

Photo

Musings on 99000 macro code

99000 ti990/12 macro code

6 replies to this topic

#1 pnr OFFLINE  

pnr

    Space Invader

  • 32 posts

Posted Sat Jan 13, 2018 8:01 AM

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.inf...smRef_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.stuartcon..._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

 

 

 

Attached Files



#2 speccery OFFLINE  

speccery

    Chopper Commander

  • 247 posts

Posted Sun Jan 14, 2018 2:34 PM

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



#3 speccery OFFLINE  

speccery

    Chopper Commander

  • 247 posts

Posted Yesterday, 12:53 PM

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.

TMS99105 (chip 2) running TMS99110 instruction CIR - success
 
While my second TMS99105 CPU did not perform the floating point operation correctly (CRI did seemingly nothing) but LDS (load distant source) worked fine.
TMS99105 (chip 1) running TMS99110 instruction CIR - failure

 


Edited by speccery, Yesterday, 12:55 PM.


#4 Ksarul OFFLINE  

Ksarul

    River Patroller

  • 4,293 posts

Posted Yesterday, 3:30 PM

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).



#5 pnr OFFLINE  

pnr

    Space Invader

  • Topic Starter
  • 32 posts

Posted Yesterday, 4:25 PM

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 by pnr, Yesterday, 4:28 PM.


#6 speccery OFFLINE  

speccery

    Chopper Commander

  • 247 posts

Posted Today, 1:49 AM

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 by speccery, Today, 1:51 AM.


#7 pnr OFFLINE  

pnr

    Space Invader

  • Topic Starter
  • 32 posts

Posted Today, 2:41 AM

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.






1 user(s) are browsing this forum

0 members, 1 guests, 0 anonymous users