Musings on 99000 macro code

[pnr]

 

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.

 

In short my assumption is that all of the 99000, 99105 and 99110 actually have macro code support, but only differ in what is inside the macro ROM. So far we have yet to find a true 99105 chip with a blank ROM: so far we have three 99105's that have 99110 ROMs inside, one that most likely has a 99000 ROM inside, and two that are as yet unidentified (one of which is your second chip - which also seems to have the 99000 ROM, the other is JH's chip - which I suspect has a 99110 ROM).

 

The longer answer is that the 99xxx was designed in the closing days of manual mask production, with masks being taped out by hand on huge mylar sheets. In that context it does not make sense to have multiple designs, other than ROM contents.

 

Some two years ago I thought that there perhaps never was a 99000 and that the TI990/10A actually used a 99105 chip. This idea has now reversed: perhaps there never was a 99105 ROM, but all are 99000 or 99110 ROMs. Maybe in the early years 99105's included chips that were fully functional except for an error in the ROM: this would have improved yields and thus reduced cost. On the other hand, the ROM covers only ~10% of the chip surface area, so functional chips with only an error in the ROM would be relatively rare among defects.

 

As time progressed the yield must have gone up, perhaps as high as 80-90% in the second half of the 80's. If TI persisted with having no specific 99105 ROM that would mean that a very large share of 99105's currently floating around have functional 99000 or 99110 ROMs inside (and by 1985 it would have made no sense for TI to put new money into the 99xxx, at that point they were just producing them to recoup the investment). That theory seems to fit with what we observe. Based on findings so far I would say that the odds are 50-50 or perhaps 60-40 in favour of finding a chip with a 99110 ROM.

[speccery]

Thank you Paul, this starts to make sense. I have done a bunch of new tests - and I did read the data sheet more carefully, which also helped a great deal...

 

I enabled the prototyping mode on my second TMS99105, I have a latch that drives both RESET# and APP# pins separately so that was easy to do, only FPGA change. After loading the TMS99110 macro code ROM into address >800 in my macrocode region, I have this second TMS99105 working as a TMS99110. Nearly - it seems there is a minor difference in timing between macro store reads and normal reads, as the system is a little unstable when running from macro store. But occasionally I get it to run the floating point test properly, and that can only happen when the CPU is reading the macro store code from external RAM properly.

 

It is also possible that the FPGA timing variations between different synthesis runs cause this specific run to be unstable, I do not know how much timing margin I have, I haven't placed many timing constraints in there. However, in general I have had no problems making FPGA design changes and coming up with stable synthesis results, and this FPGA load works well as long as I am not running code from macro store, so I think the source of problems is a slightly different timing with macro store accesses.

 

But all in all, I think I now understand better this functionality. It would also appear that with a "real" TMS99105 it only makes sense to run the CPU in prototyping mode, otherwise one cannot locate the vectors at macro store >800 onwards into external memory.

[HackMac]

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.

If you use an Apple Computer, you can use the TI-Disk Manager for disassembling code for nearly all processors of the 99xxx family.

It has an interactive tool (Disassembler Editor) for producing clean source code.

Edited January 20, 2018 by HackMac

[speccery]

If you use an Apple Computer, you can use the TI-Disk Manager for disassembling code for nearly all processors of the 99xxx family.

It has an interactive tool (Disassembler Editor) for producing clean source code.

 

 

Thanks! That's cool, I downloaded and ran it. The file to disassemble is not in any TI Disk format, just a plain 1k binary on my Mac's disk, what would be the steps to get it disassembled with your tool?

[HackMac]

I'll anwer with an PM - don't want hijack this thread... (or we have to switch to the TI-Disk Manager thread )

[pnr]

 

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.

 

 

That's what I thought for a long time as well. However, chips marked TMS99000 (or at least marked TMP99000 and TMX99000) do exist:

http://www.cpu-world.com/forum/viewtopic.php?t=19180&start=0

The coding looks like preproduction samples, but the date codes (1983) suggest that these were much later. Interestingly, one of the pics shows a TMP99000B (not A). If memory serves me right, Ksarul has a chip marked "TMS99000" in his collection, but I'm not 100% sure.

 

When I write having a "99000 ROM" I mean the ROM in the chip that was used in the TI990/10A. The pictures of TI990/10A CPU boards that survived are too low res to read the marking, or have other issues (like glare on the lid) for example here:

http://img11.hostingpics.net/pics/890850tm990_10a.jpg

The TI990/10A board that Dave Pitts has in his collection has a chip with completely faded markings.

 

In summary, I don't know for sure what the markings on the CPU chip in a TI990/10A were, and I use "99000" as a best guess.

Edited January 20, 2018 by pnr

[speccery]

 

When I write having a "99000 ROM" I mean the ROM in the chip that was used in the TI990/10A. The pictures of TI990/10A CPU boards that survived are too low res to read the marking, or have other issues (like glare on the lid) for example here:

http://img11.hostingpics.net/pics/890850tm990_10a.jpg

The TI990/10A board that Dave Pitts has in his collection has a chip with completely faded markings.

 

Wow there is a ton of logic on those boards. I suppose there is architecture documentation somewhere? That would be an interesting FPGA project to build the whole thing... I will probably extend my TMS9900 FPGA CPU to TMS99000 at some point.

[kl99]

There are documents showing the schematics of TI-990 machines:

http://www.bitsavers.org/pdf/ti/990/schematics/990-10cpu.pdf
http://www.bitsavers.org/pdf/ti/990/schematics/

[pnr]

My 'new' 99105 arrived from China. It has the 99110 ROM :^)

 

After reading out the ROM, I can confirm that it is byte-for-byte identical to the ROM in speccery's chip.

 

That further supports the theory that - at least later in the chip's lifecycle - fully functional 99110 silicon was put in some of the packages marked 99105.

[+Ksarul]

I have at least one TMS99000 chip here at the house, on a strange little single-board machine that was given to me by a former TI employee in Germany. All I have is the fully-populated board--not the rest of the associated machine.

[pnr]

I have at least one TMS99000 chip here at the house, on a strange little single-board machine that was given to me by a former TI employee in Germany. All I have is the fully-populated board--not the rest of the associated machine.

 

 

Interesting. Could you post a picture of the board and of the chip markings?

[+Ksarul]

I'll look to see where I put it away, as I haven't touched it in about 20 years now. . .

[pnr]

I've done a bit more testing on the 99105 chips that seem to support the TI990 variant of the LDS, LDD and LMF instructions. The theory here is that these chips have silicon inside with the macro ROM that was used for the TI990/10A mini. The further tests support that theory.

 

The TI990 assembler manual

http://bitsavers.informatik.uni-stuttgart.de/pdf/ti/990/assembler/2270509-9701A_AsmRef_Nov82.pdf
documents what LDD, LDS and LMF were supposed to do.

The TI990/10A general description
http://bitsavers.informatik.uni-stuttgart.de/pdf/ti/990/990-10/2302633_990-10A_GenDescr_Sep82.pdf
documents that a 10A has its mapper registers in the parallel CRU area >9F80->9FFF.

(there is table with the CRU address map that has this info on page 1-19).

 

So I set up a test to see if my 99105 chip supported that. The test looks to see if the LDD/LDS/LMF instructions indeed store the map information to parallel CRU addresses in the >9F80->9FFF range. They do:

 

LMF R0,0 loads the 6 words to >9F80 (i.e. this is where map 0 is)

LMF R0,1 loads the 6 words to >9FA0 (i.e. this is where map 1 is)
LDD and LDS both load the 6 words to >9FC0 (i.e. this is where map 2 is)

This means that a sequence LDD-LDS-MOV is of limited use: both the source and destination will use the "map 2" loaded by LDS, as that overwrites the upload by LDD.

 

My conclusion is that the code for LDD/LDS/LMF in the 99000 ROM is simple and easy to factory test. This probably means that there really is no backdoor to its ROM. On the other hand, using the 99110 ROM as a guide, it is now fairly easy to newly write the code for a 99000 ROM. It will of course not be exact, but it will document what is functionally in there.

 

This is my go at recreating that code:

; Macro ROM jump table
;
        AORG >0800

        DATA ILLOP
        DATA ILLOP
        DATA ILLOP
        DATA LMENTR
        DATA ILLOP
        DATA ILLOP
        DATA LDENTR
        DATA ILLOP
        DATA ILLOP
        DATA ILLOP

; LMF
;
LMENTR  MOV R5,R2          ; Is opcode LMF?
        ANDI R2, >FFE0
        CI R2, >0320
        JNE MAP1
        LI R12, >9F80      ; Yes: LMF for map 0
        JMP PRVTST
MAP1    CI R2, >0330
        JNE ILLOP
        LI R12, >9FA0      ; Yes: LMF for map 1

PRVTST  CZC @USER,R15      ; CPU is in supervisor mode?
        JNE PRVERR

        ANDI R5, >000F     ; Fetch map pointer from register W
        ORI R5, >0020      ; by pretending W is *R
        EVAD R5

        LDCR *R8+,11       ; Load six words into MMU
        LDCR *R8+,11
        LDCR *R8+,11
        LDCR *R8+,11
        LDCR *R8+,11
        LDCR *R8, 10
        RTWP               ; Normal exit      

ILLOP   RTWP2              ; Return with ILLOP error

PRVERR  LIMI 0             ; Return with PRIVOP error
        RTWP

; LDS/LDD
;
LDENTR  MOV R5, R2         ; Opcode is LDD or LDS?
        ANDI R2, >FF80
        CI R2, >0780
        JNE ILLOP

        CZC @USER,R15      ; CPU is in supervisor mode?
        JNE PRVERR

        ANDI R5, >003F     ; Mask out src bits
        EVAD R5
        JNE NOINCR         ; Handle auto-increment
        INCT *R10

NOINCR  LI R12, >9FC0      ; Base address of map register 2
        MOV *R8, R2        ; Fetch pointer to new map

        LDCR *R2+,11       ; Load six words into MMU
        LDCR *R2+,11
        LDCR *R2+,11
        LDCR *R2+,11
        LDCR *R2+,11
        LDCR *R2, 10
        RWTP4              ; return, skip interrupt test

USER    DATA >0100

Note that for CRU addresses in parallel space (i.e. R12 has top bit set), that a bit count of 11 means 'transfer a word and post-increment R12 by 2' and a bit count of 10 means 'transfer a word, leave R12 as-is'.

 

I think I have also finally figured out how the TI990/10A mapper can work out that a LDD/LDS is in effect (as the supervisor can use both PSEL=0 and PSEL=1, it is hard to tell when the PSEL/D15 line it is being inverted).

 

However, every change to the PSEL status bit is echoed on the address bus during an ST machine cycle (bus code 1101, see section 2.4.2. and table 2 in the data sheet). The mapper can use this to keep a copy of the PSEL bit in the status register in a flip-flop, and doing a XOR with the bit on the PSEL/D15 line will tell it when the bit is inverted and "map 2" has to be used.

 

 

[speccery]

Very interesting and great work, pnr! If I wanted to test my TMS99105 to see if it behaved similarly, I would just need to watch for those parallel CRU space accesses - is that right?

[pnr]

Yes, that is correct.

[pnr]

I've built a little modification on Stuart's 99110 board to test the copying of status bits ST7 to ST11 to external flip-flops.

 

I'm decoding bus status "ST" (binary 1101) and then clocking the address bus bits 7-11 to an external flip-flop on the rising edge of CLKOUT. This appears to work fine.

 

Copying status bit to external flip-flops makes it possible:

 

(i) to make the non-privileged/privileged status (ST7) available to external hardware

 

(ii) to use the status map select bit (ST8) directly in external hardware and to use the PSEL signal to signify "use another map" to the MMU (as the TI990/10A mini does)

 

I've also found that the unassigned status bit (ST9) is present as a real register bit on 99xxx silicon: it can be set and reset. Like ST7 and ST8, the ST9 bit is reset whenever a reset, interrupt or XOP occurs. On the TI990/12 mini this bit enables error checking by the MMU. Maybe in a new design other creative uses are possible.

 

I'm finding the 99xxx an ever more intriguing design!

 

 

[Opry99er]

https://rover.ebay.com/rover/0/0/0?mpre=https%3A%2F%2Fwww.ebay.com%2Fulk%2Fitm%2F202228801857

 

Pricey but cool

[pnr]

Thanks for that link and that is indeed pricey!

 

The TM990 series are development boards:http://http://www.stuartconner.me.uk/tm990/tm990.htm

 

Although they can be rack mounted, they are very distinct from the TI990 series mini computers. In a way, they are more reminiscent of PEB boards.

 

The board that was sold on eBay is trainer board with a 9981 CPU and a calculator style user interface.

 

(there's some pictures of a TI990 here:

http://www.computinghistory.org.uk/det/11554/Texas-Instruments-TI-990-Computer-System/)

[TonyRowell]

I realise this thread is old but there again the 99000 is way older. I used to work for TI  and have worked with 99000s after leaving TI .

From what I can remember (which isn't terribly reliable), TMS & TMP prefixes designate devices produced before the part has completed full qualification (takes months) but are otherwise identical to the TMS part. 99000 devices were only available to the group making the 99/10A, the only devices gennerally available were the 99105 & 99110 (99120 never produced) and were identical silicon. 99110s were hard to come by for a long time and we ran 99105s with external macrostore containing TI supplied code as 99110 equivalents as we needed the floating point instructions. I think the supply issue with 99110s was down to a yeild issue.

[speccery]

On 6/2/2020 at 12:58 PM, TonyRowell said:

I realise this thread is old but there again the 99000 is way older. I used to work for TI  and have worked with 99000s after leaving TI .

From what I can remember (which isn't terribly reliable), TMS & TMP prefixes designate devices produced before the part has completed full qualification (takes months) but are otherwise identical to the TMS part. 99000 devices were only available to the group making the 99/10A, the only devices gennerally available were the 99105 & 99110 (99120 never produced) and were identical silicon. 99110s were hard to come by for a long time and we ran 99105s with external macrostore containing TI supplied code as 99110 equivalents as we needed the floating point instructions. I think the supply issue with 99110s was down to a yeild issue.

Hi Tony, thanks for the comments, very interesting. As is discussed before in this thread, I have three TMS99105 chips, and at least one of them seem to have the TMS99110 floating point macrostore ROM. 

I am curious, what were the systems you were involved in using the TMS99000 series chips outside of TI?

[Jimhearne]

10 minutes ago, speccery said:

Hi Tony, thanks for the comments, very interesting. As is discussed before in this thread, I have three TMS99105 chips, and at least one of them seem to have the TMS99110 floating point macrostore ROM. 

I am curious, what were the systems you were involved in using the TMS99000 series chips outside of TI?

I have 2 TMS99105 chips at the moment, 1 reads as a TMS99110 and the other doesn't.

 

The Fluke 1722A and 1752A Instrumentation controllers use a TMS99105 cpu

I've been trying to get hold of a system at sensible money for quite a while, have just manage to get hold of a cpu and video card.

 

I also just bought a complete Fluke 1720A Instrumentation controller, i couldn't find anything about them on the net so i took a chance. 

Turns out the 1720A is based on a TI 9900 cpu not the TMS99105, not to worry, still interesting, due to get here from the US on Monday.

 

The main issue with getting these doing something seems to be getting hold of the Fluke FDOS floppy discs to boot them.

 

Jim

 

[+dhe]

This is a really good go to book about the 99000 -

The 99000 Microprocessor: Architecture, Software, and Interface Techniques Paperback – February 1, 1984

by Avtar Singh  (Author), Walter Triebel (Author)

 

All the talk about finding tms99110 bits sprinkled in to 99105's - reminds me of many times during this error, you'd get an sx intel chip that was actually a dx, who failed the co-processor test and the factory, so electronically it was disabled and sold (fairly) as an SX chip. And then others where you got say a 12MHZ products, which started out like as a 16MHZ products that failed the tests, and was sold as a slower product for which it passed the tests.

[matthew180]

On 6/2/2020 at 2:58 AM, TonyRowell said:

I realise this thread is old but there again the 99000 is way older.

That is ok, continuing older threads is not a problem on this forum, and IIRC we like this better (at least I do) than starting a new thread with the same or similar topic.  Long-running conversations make the forum, and life, more interesting.

 

On 6/2/2020 at 2:58 AM, TonyRowell said:

I used to work for TI  and have worked with 99000s after leaving TI .

That is very cool; and welcome!  There are a lot of people here, myself included, that really enjoy hearing from the people who were "there" and involved in the history of our retro-computer of choice.

 

12 hours ago, speccery said:

TMS & TMP prefixes designate devices produced before the part has completed full qualification (takes months) but are otherwise identical to the TMS part. 99000 devices were only available to the group making the 99/10A, the only devices gennerally available were the 99105 & 99110 (99120 never produced) and were identical silicon.

That is really fun (and helpful) to know!  I don't know if this information was commonly known (I suspect some people here might know this), but it is new information to me.  Thanks.

 

49 minutes ago, dhe said:

This is a really good go to book about the 99000 -

 

Thanks for the reference, I just ordered one (used) from Amazon.  Walter Triebel seems to have written quite a few books on various CPUs during the 80's and early 90's.

[GDMike]

Oh. I was caught up in the story.. excuse me. Welcome!!

[Jimhearne]

On 6/2/2020 at 10:58 AM, TonyRowell said:

TMS & TMP prefixes designate devices produced before the part has completed full qualification (takes months) but are otherwise identical to the TMS part. 

Did you mean TMX and TMP prefixes ?

 

Jim